From mircea.pisica@bt.com Sun May 1 06:14:46 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 DCFF5E0782 for ; Sun, 1 May 2011 06:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 doL0uGUoFuQD for ; Sun, 1 May 2011 06:14:46 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 384E3E0771 for ; Sun, 1 May 2011 06:14:44 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Sun, 1 May 2011 14:14:43 +0100 Received: from emv66-ukrd.domain1.systemhost.net ([169.254.2.176]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Sun, 1 May 2011 14:14:43 +0100 From: To: , Date: Sun, 1 May 2011 14:14:40 +0100 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf8QCnxQRFm5ZTY2E9JqQzSMAoQDgeFDQ Message-ID: <83DCCD6631C3C04DA6FD0A9AFC181242995051BCD4@EMV66-UKRD.domain1.systemhost.net> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 01 May 2011 13:14:47 -0000 Yes/Support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: 27 April 2011 04: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 Sun May 1 21:08: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 57712E06C4; Sun, 1 May 2011 21:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.35 X-Spam-Level: X-Spam-Status: No, score=-101.35 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 dmImyFRUEeZe; Sun, 1 May 2011 21:08:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CF765E062A; Sun, 1 May 2011 21:08:05 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Mon, 2 May 2011 12:06:31 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 62927.3228747972; Mon, 2 May 2011 11:55:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4247prh077651; Mon, 2 May 2011 12:07:51 +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: Mon, 2 May 2011 00:07:46 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-02 12:07:53, Serialize complete at 2011-05-02 12:07:53 Content-Type: multipart/alternative; boundary="=_alternative 0016AFD885257884_=" X-MAIL: mse02.zte.com.cn p4247prh077651 Cc: "mpls-bounces@ietf.org" , "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: Mon, 02 May 2011 04:08:12 -0000 This is a multipart message in MIME format. --=_alternative 0016AFD885257884_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eric, Please see in line below, comments marked with [MB]. Regards, Malcolm Eric Gray =20 29/04/2011 11:47 AM To John E Drake , "Malcolm.BETTS@zte.com.cn"=20 cc "mpls@ietf.org" , "mpls-bounces@ietf.org"=20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? I agree with John's interpretation. =20 With a "stiched" LSP, forwarding is done exactly as if the LSP is=20 contiguous. [MB] OK that meets the requirement that OAM and data fate share. =20 If OAM packets are forwarded exactly as data, the difference in=20 the case where an OAM translation needs to occur is minimal.=20 The only difference is the (potential) need for boundary devices=20 to perform translation/adaptation of OAM identifiers. [MB] Two points: 1) How can it be the same if we have a difference in the=20 treatment of OAM and data packets. 2) How are OAM packets identified, is = the boundary node required to examine the bottom of stack label to for the = value 13? This appears to be a deviation from "normal" MPLS forwarding=20 behaviour.=20 =20 With a proper implementation, a translation can be performed=20 with no more impact on OAM messages than would be seen by any data packet that needs to have a CRC modification, or an adaptation from one underlying network layer to another. [MB] In the case of CRC modification the same process is performed on=20 every packet, no difference between OAM and data packets. =20 Since these things also happen, it is difficult to buy the argument=20 that a similar function should not be allowed. =20 If, on the other hand, we were to require equipment that is now purpose built for IP forwarding to be able to map OAM message identifiers to "strange" identifiers (currently used mostly for the "transport layer" in the sense of TDM/optical switching), we may expect all sorts of false indications to occur. [MB] Two points: MPLS-TP forwarding must not rely on the presence of an=20 IP forwarding function. 2) I do not understand (or accept) your assertion=20 that nodes "purpose built for IP forwarding to be able to map OAM message = identifiers to "strange" identifiers". All that "sink" needs to do is to=20 compare the received binary string to the expected binary string to=20 determine if the OAM packet is being received from the expected source. I = agree that in the OSS it may be desirable for the OSS to be able to=20 interpret both identifier formats - but the nodes responsible for=20 forwarding do not need to understand or interpret the identifier. =20 Besides, my point was that there will clearly be an interworking function requirement in any case. [MB] As discussed at the SG15 meeting and documented in TD458/PLEN an=20 interworking function will not be required. Interworking functions create = complexity and should not be used. =20 And piece-wise OAM is often required when interworking is used, and ther is a distinct advantage in terms of divide-and-conquer=20 diagnostics in this case. [MB] Interworking results in piece-wise OAM and prevents end to end=20 integrity checks. =20 The potential impact on OAM PDU fowarding due to translation of identifiers will be nothing in comparison with remapping OAM from RFC-based OAM to ITU-T G8113.1-based OAM. [MB] Please remember the discussion at the last SG15 meeting as documented = in TD458/PLEN. If end to end OAM between regions that run RFC based OAM=20 and G.8113.1 based OAM will use the RFC version. i.e. An interworking=20 function is not required. =20 Surely you are not now going to argue that there should be end-to- end support for both forms of OAM? But these arguments are very similar. [MB] No - please see my previous comment =20 OAM across service provider boundaries is a very strange thing=20 anyway. Most service providers are extremely reluctant to give=20 their competitors the ability to find out what is wrong within their=20 network. [MB] It is common/mandatory in all existing transport networks to be able = to check the end to end integrity of a connection. =20 This is even more likely to be the case with service providers who have fundamentally different operating paradigms. =20 Other than reports from a small number of people (who've already indicated that they will support a different form of OAM for their customers), we've not seen any evidence that there is a real need to support end-to-end, multi-provider OAM - particularly for the=20 case where peered service providers use different forms of OAM and identifiers. =20 The appropriate time to deal with this possible scenario is when it actually comes up. No doubt it will, given that there is going to be two different types of OAM. =20 But perhaps the vendors and service providers that argued that the applications are sufficently different for the two different OAM types that they will not need to mix, will turn out to be correct... [MB] So in your view MPLS-TP will never support multi-operator=20 deployments in the same way the SDH, OTN and PBB-TE do? =20 -- Eric From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Wednesday, April 27, 2011 7: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, =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 0016AFD885257884_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eric,

Please see in line below, comments m= arked with [MB].

Regards,

Malcolm



Eric Gray <eric.gr= ay@ericsson.com>

29/04/2011 11:47 AM

To
John E Drake <jdrake@juniper.net&= gt;, "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>
cc
"mpls@ietf.org" <mpls@i= etf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
Subject
RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





I agree with John's interpre= tation.
 
With a "stiched" L= SP, forwarding is done exactly as if the LSP is
contiguous.

[MB] OK that meets the requirement that O= AM and data fate share.
 
If OAM packets are forwarded= exactly as data, the difference in
the case where an OAM transl= ation needs to occur is minimal.  
The only difference is the (= potential) need for boundary devices
to perform translation/adapt= ation of OAM identifiers.

[MB] Two points: 1) How can it be the same if we have a difference in the treatment of OAM and data packets.   2) How are OAM packets identified, is the boundary node required to examine the bottom of stack label to for the value 13?  This appears to be a deviation from "normal" MPLS forwarding behaviour.
 
With a proper implementation, a translation can be performed
with no more impact on OAM m= essages than would be seen by
any data packet that needs to have a CRC modification, or an
adaptation from one underlyi= ng network layer to another.

[MB]  In the case of CRC modification the same process is performed on every packet, no difference between OAM and data packets.
 
Since these things also happ= en, it is difficult to buy the argument
that a similar function shou= ld not be allowed.
 
If, on the other hand, we we= re to require equipment that is now
purpose built for IP forward= ing to be able to map OAM message
identifiers to "strange= " identifiers (currently used mostly for the
"transport layer" = in the sense of TDM/optical switching), we may
expect all sorts of false in= dications to occur.

[MB] Two points:  MPLS-TP forwarding must not rely on the presence of an IP forwarding function. 2) I do not understand (or accept) your assertion that nodes "purpose built for IP forwarding  to be able to map OAM message identifiers to "stra= nge" identifiers".  All that "sink" needs to do is to compare the received binary string to the expected binary string to determine if the OAM packet is being received from the expected source.  I agree that in the OSS it may be desirable for the OSS to be able to interpret both identifier formats - but the nodes responsible for forwarding do not need to understand or interpret the identifier.
 =
Besides, my point was that t= here will clearly be an interworking
function requirement in any = case.

[MB]  As discussed at the SG15 meeti= ng and documented in TD458/PLEN an interworking function will not be required.  Interworking functions create complexity and should not be used.
 
And piece-wise OAM is often = required when interworking is used,
and ther is a distinct advan= tage in terms of divide-and-conquer
diagnostics in this case.

[MB] Interworking results in piece-wise O= AM and prevents end to end integrity checks.
 
The potential impact on OAM = PDU fowarding due to translation of
identifiers will be nothing = in comparison with remapping OAM from
RFC-based OAM to ITU-T G8113= .1-based OAM.

[MB] Please remember the discussion at the last SG15 meeting as documented in TD458/PLEN.  If end to end OAM between regions that run RFC based OAM and G.8113.1 based OAM will use the RFC version.  i.e. An interworking function is not required.
 
Surely you are not now going= to argue that there should be end-to-
end support for both forms of OAM?  But these arguments are very
similar.

[MB] No - please see my previous comment<= /font>
 
OAM across service provider = boundaries is a very strange thing
anyway.  Most service p= roviders are extremely reluctant to give
their competitors the ability to find out what is wrong within their
network.

[MB]  It is common/mandatory in all existing transport networks to be able to check the end to end integrity of a connection.
 
This is even more likely to = be the case with service providers who
have fundamentally different= operating paradigms.
 
Other than reports from a sm= all number of people (who've already
indicated that they will sup= port a different form of OAM for their
customers), we've not seen a= ny evidence that there is a real need
to support end-to-end, multi= -provider OAM - particularly for the
case where peered service pr= oviders use different forms of OAM
and identifiers.
 
The appropriate time to deal= with this possible scenario is when
it actually comes up.  = No doubt it will, given that there is going
to be two different types of= OAM.
 
But perhaps the vendors and = service providers that argued that
the applications are suffice= ntly different for the two different OAM
types that they will not need to mix, will turn out to be correct...

[MB]  So in your view MPLS-TP will n= ever support multi-operator deployments in the same way the SDH, OTN and PBB-TE do?
 
--
Eric
From: John E Drake [mailto:jdrake= @juniper.net]
Sent: Wednesday, April 27, 2011 7: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̵= 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.org27/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 0016AFD885257884_=-- From N.Leymann@telekom.de Mon May 2 00:44: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 DB9A9E06CF for ; Mon, 2 May 2011 00:44:53 -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 dcifnrYbSsEz for ; Mon, 2 May 2011 00:44:53 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id A9D48E0694 for ; Mon, 2 May 2011 00:44:51 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 02 May 2011 09:44:33 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.131]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 2 May 2011 09:44:32 +0200 From: To: , , Date: Mon, 2 May 2011 09:44:31 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AQHMBH+Q1LfPm0rYjUCTn8xuXgBECpRxpqMQgAeI30A= Message-ID: <9762ACF04FA26B4388476841256BDE020114419CB3BC@HE111543.emea1.cds.t-internal.com> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> <07F7D7DED63154409F13298786A2ADC903E41EBC@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E41EBC@EXRAD5.ad.rad.co.il> 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: 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: Mon, 02 May 2011 07:44:54 -0000 Hi, At the moment the Seamless Architecture draft focusses on a static routing = between access and aggregation network (no IGP at all) in order to keep the= architecture simple. If there is interest in extending the document to add= ress a more dynamic approach between access and aggregation we are happy to= accept input. But from our point of view this can also be done with the do= cument being a WG document. Regards Nic -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von Ya= akov Stein Gesendet: Mittwoch, 27. April 2011 14:50 An: loa@pi.nu; mpls@ietf.org Cc: rcallon@juniper.net Betreff: Re: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 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 network= s to which it is extending MPLS, 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 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 N.Leymann@telekom.de Mon May 2 00:45: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 108F7E06E6 for ; Mon, 2 May 2011 00:45:30 -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 M2t5cfH3QKPa for ; Mon, 2 May 2011 00:45:29 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA24E06CF for ; Mon, 2 May 2011 00:45:28 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 02 May 2011 09:44:33 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.131]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Mon, 2 May 2011 09:43:43 +0200 From: To: , Date: Mon, 2 May 2011 09:43:41 +0200 Thread-Topic: [mpls] poll on draft-leymann-mpls-seamless-mpls-03 Thread-Index: AcwEf/kg3//TiUqwQD+EYtl71VL7cgEHJ7og Message-ID: <9762ACF04FA26B4388476841256BDE020114419CB3BA@HE111543.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="iso-8859-1" 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: Mon, 02 May 2011 07:45:30 -0000 Yes/support (and sorry for the delayed answer) Nic -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von lo= a@pi.nu Gesendet: Mittwoch, 27. April 2011 04:06 An: mpls@ietf.org Cc: rcallon@juniper.net Betreff: [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 stephane.litkowski@orange-ftgroup.com Mon May 2 01:08:47 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 0D0D5E066E for ; Mon, 2 May 2011 01:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.146 X-Spam-Level: ** X-Spam-Status: No, score=2.146 tagged_above=-999 required=5 tests=[AWL=2.980, BAYES_40=-0.185, 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 T7MBy-zjRmce for ; Mon, 2 May 2011 01:08:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC48E06FA for ; Mon, 2 May 2011 01:07:35 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4AA053B41DC; Mon, 2 May 2011 10:07:34 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2E3A1238066; Mon, 2 May 2011 10:07:34 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 May 2011 10:07:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2011 10:07:32 +0200 Message-ID: <31888_1304323654_4DBE6646_31888_13270_1_4FC3556A36EE3646A09DAA60429F5335064CD7DA@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQArFD58A= References: From: To: "Ross Callon" , X-OriginalArrivalTime: 02 May 2011 08:07:34.0284 (UTC) FILETIME=[FE19FCC0:01CC089F] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.2.71226 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, 02 May 2011 08:08:47 -0000 Support =20 -----Message d'origine----- De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part de Ros= s Callon Envoy=E9 : lundi 18 avril 2011 17:16 =C0 : mpls@ietf.org Objet : [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-kom= pella-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 ***************************************************************************= ***** 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 yaacov.weingarten@nsn.com Mon May 2 02:18:46 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 5FCD8E070D for ; Mon, 2 May 2011 02:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[AWL=2.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 8H0FsMyTD+xG for ; Mon, 2 May 2011 02:18:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C2E071A for ; Mon, 2 May 2011 02:18:02 -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 p429I1cc002007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 May 2011 11:18:01 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p429HxRo025833; Mon, 2 May 2011 11:18:01 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 11:17:59 +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_01CC08A9.D485222C" Date: Mon, 2 May 2011 11:17:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on TP-Identifiers for MIP Thread-Index: AcwIqdBmtFposC4rRnywAJLUf1h0Ew== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 02 May 2011 09:17:59.0726 (UTC) FILETIME=[D4A944E0:01CC08A9] Cc: draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] Clarification on TP-Identifiers for MIP 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, 02 May 2011 09:18:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC08A9.D485222C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In reviewing in MPLS-TP Identifiers document it is unclear on the format that is suggested for MIP identification. Just for my clarification - is the intention that the MIP identifier is the same as a MEP identifier except that in-place of the "MEP_Index" we substitute "Node_ID::IF_Num". In other words, if we are using ICC-based identifiers the MIP identifier would be: MEG_ID::Node_ID::IF_Num and if using IP global identification it would be LSP_ID::Node_ID::IF_Num. Is this correct? Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CC08A9.D485222C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarification on TP-Identifiers for MIP

Hi,

In = reviewing in MPLS-TP Identifiers document it is unclear on the format = that is suggested for MIP identification.  Just for my = clarification – is the intention that the MIP identifier is the same as = a MEP identifier except that in-place of the = "MEP_Index" we substitute = "Node_ID::IF_Num".  In other words, = if we are using ICC-based identifiers the MIP identifier = would be:

MEG_ID::Node_ID::IF_Num and if using IP = global = identification it would be = LSP_ID::Node_ID::IF_Num.

Is this = correct?

Best = regards,

Yaacov = Weingarten

Nokia Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 0977

------_=_NextPart_001_01CC08A9.D485222C-- From ehudd@orckit.com Mon May 2 02:53:45 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 C0AF5E065B for ; Mon, 2 May 2011 02:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 iTUlqIVsldjs for ; Mon, 2 May 2011 02:53:44 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C390E069E for ; Mon, 2 May 2011 02:52:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC08AE.CFCD69EC" Date: Mon, 2 May 2011 12:53:38 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306B4DCDB@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Clarification on TP-Identifiers for MIP Thread-Index: AcwIqdBmtFposC4rRnywAJLUf1h0EwAAvwRw References: From: "Ehud Doron" To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , Cc: Rafi Ram , draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: Re: [mpls] Clarification on TP-Identifiers for MIP 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, 02 May 2011 09:53:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC08AE.CFCD69EC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC08AE.CFCD69EC" ------_=_NextPart_002_01CC08AE.CFCD69EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am strongly support Yaacov approach.=20 Because a MIP is provisioned in the context of a MEG (LSP, PW), it identifiers are expected to be in the context of this MEG , i.e. MEG_ID::Node_ID::IF_Num.=20 Nevertheless , the MIP identifier as defined in draft-ietf-mpls-tp-identifiers draft is Node_ID::IF_Num (for per IF MIP approach). =20 Best wishes,=20 =20 Ehud Doron System Architect=20 Orckit - Corrigent ehudd@orckit.com =20 Tel: 972-3-69456327 www.orckit.com =20 =20 =20 Pushing technology to the edge =20 =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon) Sent: Monday, May 02, 2011 12:18 PM To: mpls@ietf.org Cc: draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] Clarification on TP-Identifiers for MIP =20 Hi, In reviewing in MPLS-TP Identifiers document it is unclear on the format that is suggested for MIP identification. Just for my clarification - is the intention that the MIP identifier is the same as a MEP identifier except that in-place of the "MEP_Index" we substitute "Node_ID::IF_Num". In other words, if we are using ICC-based identifiers the MIP identifier would be: MEG_ID::Node_ID::IF_Num and if using IP global identification it would be LSP_ID::Node_ID::IF_Num. Is this correct? Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_002_01CC08AE.CFCD69EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarification on TP-Identifiers for = MIP

Hi,

I am strongly support Yaacov approach.

Because a MIP is provisioned in the context of a MEG (LSP, PW), it = identifiers are expected to be in the context of this MEG , i.e. =  MEG_ID::Node_ID::IF_Num.

Nevertheless , the MIP identifier as defined in = draft-ietf-mpls-tp-identifiers draft is Node_ID::IF_Num (for per IF MIP = approach).

 

Best wishes,

 

Ehud    Doron

System = Architect

Orckit = - Corrigent

= ehudd@orckit.com  

= Tel: 972-3-69456327

www.orckit.com

 

3Dlogo-orckit-corrigent

= Pushing technology to the edge

 

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, = May 02, 2011 12:18 PM
To: mpls@ietf.org
Cc: = draft-ietf-mpls-tp-identifiers@tools.ietf.org
Subject: [mpls] = Clarification on TP-Identifiers for = MIP

 

Hi,

In reviewing = in MPLS-TP Identifiers document it is unclear on the format that is = suggested for MIP identification.  Just for my clarification = – is = the intention that the MIP identifier is the same as a MEP identifier = except that in-place of the "MEP_Ind= ex" we substitute "Node_ID::IF_Num".  In other = words, if we are using = ICC-based identifiers the MIP identifier would = be:

MEG_ID::Node_= ID::IF_Num and if using IP global= identificatio= n it would be LSP_ID::Node_ID::IF_Num.

Is this = correct?

Best = regards,

Yaacov = Weingarten

Nokia = Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 = 0977

------_=_NextPart_002_01CC08AE.CFCD69EC-- ------_=_NextPart_001_01CC08AE.CFCD69EC Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAzAG0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiis vWtZj0mFeN88nEcY5J/Cmk27Imc1CPNLYyde8a2+n3UllagyTx8OQM4PoK5xvHOpJIC6FQegZiM/ piulTw9qOov9qvrwWjvyUt0XcPq3rWPqR02ykNuPFti8nQwXroyn2OOldUZUoqzVzzKtPFVG5Rk0 um3+ZqaJ40hv3ENwpST0PX6j1/nXVKwZQykEEZBHevMtf8Orp1rDrOlzRyWxwZPIfcsbeqn+7muq 8O6/aDTljv7y2tpVxhJZlU4IzjBP+cipqwhy88DXDVaym6Vbfv3OloqOKaKeMSQypIh6MjAg/iKZ d3tpYQma8uYreMfxyuFH5muY9AnorLsvE2hajP5Fnq9nPKeiJMpJ+g71Zi1XT576SwivYHuo8l4F kBdceo696ALdFUn1jTIr9dPe/t1u2xiAyDec/wCz1oj1jTJbma2jv7d5rcFpo1kBaMDqSO2KALtF ZH/CWeHf+g5p/wD4EL/jV6y1Cz1KEzWN1DcxBtpeJwwB9MigCxXCNd/bfiWsc5/dwNtjU9Mhcj9T Xd15l4ugn0jxX9ujyomIljb/AGh1H6V0YdJya7o8/MG401Pomm/QufFbWb62g07RLCY27anIVklB wduQMZ7AlufpWnp/wv8ACtnYLbzact3Jt+eeZjuY9yMHj8Kq63p2n/Ebw/CkdytrqFud8TH+Bu4P sf8ACqdvqvxM0qBbGbQLbUnQbUuhKBuHYnkZ/SsJRcXZndCcZxUovQwrixPgjxwNAtJ3l0jV4sNb u27ZuyAfqCOvpUHhmPw4fF+tHxGtkYQkflm7AxuwM4z3xV240XU7K8l8Q+KLmOXWbhTHaWkJyIcj G449AeAO5rV0HwFcS6lrZ1yzjNhqMKLFhwXBGOcfwkVTi1C5mqkXVcVulqVPCaQQ/Eac+FEn/wCE fMB+04DeRvxxsz74/XtVLw1p4+JnifUdT16V5bSyYLDZhyFAJOB9MDn1Jrr/AApba/4bMmk6zJBP pcRxZ3zTKrheysp/z+FY994M1/w9r82ueDJoXjuSWmspjhTk5IHYjPTkEVBsdOvgLwvHcW9xBpEE E1tIskUkWVIIOR9fxryvVvENz4Z+I3iC/s4RJO4eJGIyIydvzH1xj8672z1n4hX13BDL4ds7CHzF 8+d5t2Fz820Z64+tUrHwZfTfELW73U7BW0m/ikjDF1O/O3HGcjofyoA0fh94Ys7KwXXpbpdR1LUF 8yS7J3YB6qp/nXP+D4o5viz4mikQMjrMrKe4LrkVq+DtD8R+ENcuNLMJvNBlctFP5i7oj67c59iP XmneF/DWrad8Rta1e6tRHZXXmeTJ5indlwRwDkcCgDmPiF4e0fS/FXh+1sdOgt4bhwJURcBxvUc/ ga9Y0zSdP0a2NtptpFawsxcpGMAn1/SuN8eeGtX1rxPod7p9qJYLRwZm8xV2/Op6E88Cu+oAKoax o9prdi1rdLkdVcdUPqKv1SuJbtWIRPl7EU07aoTSaszzu78I6/pFwXtFa5QfdkhOGx7iprdvGsuI Y47tAeMuAoH4mu1M913LflSefdf3mro+sya1SZ5/9nU07wk15JmboPhF7W6Go6vN9qvOqgnKofXn qa6isxJ7zPAJ+oq/A0jJmVQDWM5ubuzspUYUo8sEUruMx6iLqS0a6i8rYoQBjGckng+vHPtUd/8A bhIn2VZkXyx5SxhdofPR8/w4x09/ataioNSi0d4bi7k8x9ojAgQY2528n1zn1pIYrqMWQd3lIBMz vjOSvt7+lX6KAMDTru7nu5IkmleZbdzIsm0xrLkAYxzjr+HvUtuNVbT7gNJKJyFCFkGVb+LB6Efp WwFVSSFAzycDrTqAMiWC82Qh3uHEN5kMpG5o9pAz6jJrXoooAKKKKAEwPSjA9KKKAFooooAKKKKA CiiigAooooAKKKKAP//Z ------_=_NextPart_001_01CC08AE.CFCD69EC-- From nurit.sprecher@nsn.com Mon May 2 02:58: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 28AF4E065F for ; Mon, 2 May 2011 02:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.005 X-Spam-Level: X-Spam-Status: No, score=-5.005 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 nk8W+6ubyOnb for ; Mon, 2 May 2011 02:58:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A4E071D for ; Mon, 2 May 2011 02:57:19 -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 p429vIJs031785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 May 2011 11:57:18 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p429vHcK000587; Mon, 2 May 2011 11:57:18 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 11:57:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC08AF.505BF74C" Date: Mon, 2 May 2011 11:57:10 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403BB521A@DEMUEXC014.nsn-intra.net> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306B4DCDB@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Clarification on TP-Identifiers for MIP Thread-Index: AcwIqdBmtFposC4rRnywAJLUf1h0EwAAvwRwAACczOA= References: <44F4E579A764584EA9BDFD07D0CA081306B4DCDB@tlvmail1> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Ehud Doron" , "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , X-OriginalArrivalTime: 02 May 2011 09:57:15.0103 (UTC) FILETIME=[509346F0:01CC08AF] Cc: Rafi Ram , draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: Re: [mpls] Clarification on TP-Identifiers for MIP 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, 02 May 2011 09:58:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC08AF.505BF74C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC08AF.505BF74C" ------_=_NextPart_002_01CC08AF.505BF74C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not think Yaacov gave a position here. He just asked a question for clarification! =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Ehud Doron Sent: Monday, May 02, 2011 12:54 PM To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); mpls@ietf.org Cc: Rafi Ram; draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: Re: [mpls] Clarification on TP-Identifiers for MIP =20 Hi, =20 I am strongly support Yaacov approach.=20 Because a MIP is provisioned in the context of a MEG (LSP, PW), it identifiers are expected to be in the context of this MEG , i.e. MEG_ID::Node_ID::IF_Num.=20 Nevertheless , the MIP identifier as defined in draft-ietf-mpls-tp-identifiers draft is Node_ID::IF_Num (for per IF MIP approach). =20 Best wishes,=20 =20 Ehud Doron System Architect=20 Orckit - Corrigent ehudd@orckit.com =20 Tel: 972-3-69456327 www.orckit.com =20 =20 =20 Pushing technology to the edge =20 =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon) Sent: Monday, May 02, 2011 12:18 PM To: mpls@ietf.org Cc: draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: [mpls] Clarification on TP-Identifiers for MIP =20 Hi, In reviewing in MPLS-TP Identifiers document it is unclear on the format that is suggested for MIP identification. Just for my clarification - is the intention that the MIP identifier is the same as a MEP identifier except that in-place of the "MEP_Index" we substitute "Node_ID::IF_Num". In other words, if we are using ICC-based identifiers the MIP identifier would be: MEG_ID::Node_ID::IF_Num and if using IP global identification it would be LSP_ID::Node_ID::IF_Num. Is this correct? Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_002_01CC08AF.505BF74C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarification on TP-Identifiers for = MIP

I do not think Yaacov gave a position here. He just asked a question = for clarification!

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Ehud Doron
Sent: Monday, May 02, 2011 12:54 = PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); = mpls@ietf.org
Cc: Rafi Ram; = draft-ietf-mpls-tp-identifiers@tools.ietf.org
Subject: Re: = [mpls] Clarification on TP-Identifiers for = MIP

 

Hi,

 

I am strongly support Yaacov approach.

Because a MIP is provisioned in the context of a MEG (LSP, PW), it = identifiers are expected to be in the context of this MEG , i.e. =  MEG_ID::Node_ID::IF_Num.

Nevertheless , the MIP identifier as defined in = draft-ietf-mpls-tp-identifiers draft is Node_ID::IF_Num (for per IF MIP = approach).

 

Best wishes,

 

Ehud    Doron

System = Architect

Orckit = - Corrigent

= ehudd@orckit.com  

= Tel: 972-3-69456327

www.orckit.com

 

3Dlogo-orckit-corrigent

= Pushing technology to the edge

 

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, = May 02, 2011 12:18 PM
To: mpls@ietf.org
Cc: = draft-ietf-mpls-tp-identifiers@tools.ietf.org
Subject: [mpls] = Clarification on TP-Identifiers for = MIP

 

Hi,

In reviewing = in MPLS-TP Identifiers document it is unclear on the format that is = suggested for MIP identification.  Just for my clarification = – is = the intention that the MIP identifier is the same as a MEP identifier = except that in-place of the "MEP_Ind= ex" we substitute "Node_ID::IF_Num".  In other = words, if we are using = ICC-based identifiers the MIP identifier would = be:

MEG_ID::Node_= ID::IF_Num and if using IP global= identificatio= n it would be LSP_ID::Node_ID::IF_Num.

Is this = correct?

Best = regards,

Yaacov = Weingarten

Nokia = Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 = 0977

------_=_NextPart_002_01CC08AF.505BF74C-- ------_=_NextPart_001_01CC08AF.505BF74C Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAzAG0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiis vWtZj0mFeN88nEcY5J/Cmk27Imc1CPNLYyde8a2+n3UllagyTx8OQM4PoK5xvHOpJIC6FQegZiM/ piulTw9qOov9qvrwWjvyUt0XcPq3rWPqR02ykNuPFti8nQwXroyn2OOldUZUoqzVzzKtPFVG5Rk0 um3+ZqaJ40hv3ENwpST0PX6j1/nXVKwZQykEEZBHevMtf8Orp1rDrOlzRyWxwZPIfcsbeqn+7muq 8O6/aDTljv7y2tpVxhJZlU4IzjBP+cipqwhy88DXDVaym6Vbfv3OloqOKaKeMSQypIh6MjAg/iKZ d3tpYQma8uYreMfxyuFH5muY9AnorLsvE2hajP5Fnq9nPKeiJMpJ+g71Zi1XT576SwivYHuo8l4F kBdceo696ALdFUn1jTIr9dPe/t1u2xiAyDec/wCz1oj1jTJbma2jv7d5rcFpo1kBaMDqSO2KALtF ZH/CWeHf+g5p/wD4EL/jV6y1Cz1KEzWN1DcxBtpeJwwB9MigCxXCNd/bfiWsc5/dwNtjU9Mhcj9T Xd15l4ugn0jxX9ujyomIljb/AGh1H6V0YdJya7o8/MG401Pomm/QufFbWb62g07RLCY27anIVklB wduQMZ7AlufpWnp/wv8ACtnYLbzact3Jt+eeZjuY9yMHj8Kq63p2n/Ebw/CkdytrqFud8TH+Bu4P sf8ACqdvqvxM0qBbGbQLbUnQbUuhKBuHYnkZ/SsJRcXZndCcZxUovQwrixPgjxwNAtJ3l0jV4sNb u27ZuyAfqCOvpUHhmPw4fF+tHxGtkYQkflm7AxuwM4z3xV240XU7K8l8Q+KLmOXWbhTHaWkJyIcj G449AeAO5rV0HwFcS6lrZ1yzjNhqMKLFhwXBGOcfwkVTi1C5mqkXVcVulqVPCaQQ/Eac+FEn/wCE fMB+04DeRvxxsz74/XtVLw1p4+JnifUdT16V5bSyYLDZhyFAJOB9MDn1Jrr/AApba/4bMmk6zJBP pcRxZ3zTKrheysp/z+FY994M1/w9r82ueDJoXjuSWmspjhTk5IHYjPTkEVBsdOvgLwvHcW9xBpEE E1tIskUkWVIIOR9fxryvVvENz4Z+I3iC/s4RJO4eJGIyIydvzH1xj8672z1n4hX13BDL4ds7CHzF 8+d5t2Fz820Z64+tUrHwZfTfELW73U7BW0m/ikjDF1O/O3HGcjofyoA0fh94Ys7KwXXpbpdR1LUF 8yS7J3YB6qp/nXP+D4o5viz4mikQMjrMrKe4LrkVq+DtD8R+ENcuNLMJvNBlctFP5i7oj67c59iP XmneF/DWrad8Rta1e6tRHZXXmeTJ5indlwRwDkcCgDmPiF4e0fS/FXh+1sdOgt4bhwJURcBxvUc/ ga9Y0zSdP0a2NtptpFawsxcpGMAn1/SuN8eeGtX1rxPod7p9qJYLRwZm8xV2/Op6E88Cu+oAKoax o9prdi1rdLkdVcdUPqKv1SuJbtWIRPl7EU07aoTSaszzu78I6/pFwXtFa5QfdkhOGx7iprdvGsuI Y47tAeMuAoH4mu1M913LflSefdf3mro+sya1SZ5/9nU07wk15JmboPhF7W6Go6vN9qvOqgnKofXn qa6isxJ7zPAJ+oq/A0jJmVQDWM5ubuzspUYUo8sEUruMx6iLqS0a6i8rYoQBjGckng+vHPtUd/8A bhIn2VZkXyx5SxhdofPR8/w4x09/ataioNSi0d4bi7k8x9ojAgQY2528n1zn1pIYrqMWQd3lIBMz vjOSvt7+lX6KAMDTru7nu5IkmleZbdzIsm0xrLkAYxzjr+HvUtuNVbT7gNJKJyFCFkGVb+LB6Efp WwFVSSFAzycDrTqAMiWC82Qh3uHEN5kMpG5o9pAz6jJrXoooAKKKKAEwPSjA9KKKAFooooAKKKKA CiiigAooooAKKKKAP//Z ------_=_NextPart_001_01CC08AF.505BF74C-- From agmalis@gmail.com Mon May 2 12:48: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 6C430E06CB for ; Mon, 2 May 2011 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 U6SAparvQkuN for ; Mon, 2 May 2011 12:48:42 -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 BAB79E069B for ; Mon, 2 May 2011 12:48:42 -0700 (PDT) Received: by qwc23 with SMTP id 23so3742810qwc.31 for ; Mon, 02 May 2011 12:48:42 -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:content-transfer-encoding; bh=XJv/kWtEhZ2N/OzA3zovkVtNXBt9+WxpjlR72Kuzusw=; b=LRXC1Kyp6iAyyK2mZtyYfZAYjSUSKMCJxWqBp20wujEVWR6Bqf3BSQNjCoC9F+dhaB 6TKgQwo9W1w240aXALptcqF5jDzSFpFqueBwpnKK5cdzoInFZgdVHBxG8ExxwRsfjLDT npUPEjNFXk9L6otRqiTRqJguGHxUmmcBX1NYE= 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:content-transfer-encoding; b=YJCQZhjqNaxcUGzUAHQXLy5Td6GSula1CkC//aDFBsGXeUiA//cMFQe/9ZOE557NBk guHSTcmVMmyIjtBcBXR4zVDiQwMhadW2X79O7gQkjl01z7jRAGM1W2f5OYI2l1VZzagd GrjIumQOZEzPt4CXbUHAVXRleYLFT9yYcjsvM= Received: by 10.229.129.1 with SMTP id m1mr6467165qcs.205.1304365722162; Mon, 02 May 2011 12:48:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.227.1 with HTTP; Mon, 2 May 2011 12:48:22 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 2 May 2011 15:48:22 -0400 Message-ID: To: George Swallow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 02 May 2011 19:48:43 -0000 George et al, Verizon does not have any requirement for mixed use of Global IDs and ICCs. We are fine with specifications that require both ends of an LSP to use one or the other. Thanks, Andy On Mon, Apr 25, 2011 at 5:16 PM, George Swallow wrote: > 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 e= ach > 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. > > Obtaining an AS Number (from which the Global-ID is derived) is a fairly > trivial procedure. =A0Many organizations if not most already have AS Numb= ers. > Such an addition will add numerous object formats, and test cases. > The 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. > For signaled connections, there is no plan to allow routing based on eith= er > 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 number= s. > > 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 > > From erminio.ottone_69@libero.it Mon May 2 14:54: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 D22B5E06BE for ; Mon, 2 May 2011 14:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 6Bte0yrUH5Tg for ; Mon, 2 May 2011 14:54:13 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E5E06AC for ; Mon, 2 May 2011 14:54:12 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4DBF2803.0001,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D63C9BA058E9AE1 for mpls@ietf.org; Mon, 2 May 2011 23:54:10 +0200 Message-ID: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> Date: Mon, 2 May 2011 23:54:10 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.45.147.23 Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:54:13 -0000 Forwarding the messate to the MPLS WG mailing list ... >----Messaggio originale---- >Da: erminio.ottone_69@libero.it >Data: 2-mag-2011 23.19 >A: >Ogg: R: [mpls] FW: Poll / Final in 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. > >How this is possible? > >Section 6.8.7 of RFC 5880 states that: > > With the exceptions listed in the remainder of this section, a system > MUST NOT transmit BFD Control packets at an interval less than the > larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less > applied jitter (see below). > >If the Poll requires a longer bfd.RemoteMinRxInterval, how can the system >ignore the request? > >>----Messaggio originale---- >>Da: david.i.allan@ericsson.com >>Data: 20-apr-2011 17.29 >>A: "mpls@ietf.org" >>Cc: "Ross Callon" >>Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >> >>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... >> >> >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls >> > > From erminio.ottone_69@libero.it Mon May 2 14:54: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 CB791E06BE for ; Mon, 2 May 2011 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 C6yGxdompdhu for ; Mon, 2 May 2011 14:54:37 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id AF01BE078C for ; Mon, 2 May 2011 14:54:36 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0204.4DBF281C.00B6,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D63C9BA058E9BF5 for mpls@ietf.org; Mon, 2 May 2011 23:54:36 +0200 Message-ID: <3108136.1224781304373276511.JavaMail.defaultUser@defaultHost> Date: Mon, 2 May 2011 23:54:36 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.45.147.23 Subject: [mpls] I: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:54:37 -0000 Forwarding the messate to the MPLS WG mailing list ... ----Messaggio originale---- Da: erminio.ottone_69@libero.it Data: 2-mag-2011 23.41 A: Ogg: R: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? 1) what about the operational burden to manage two different identifiers for the same entities within the same operator's domain? 2) This argument is not fully clear. Let's check the different identifiers that are defined and see if there is any additional implementation complexity: -> Path identifiers: they are not carried by any protocol istance so what is the testing burden? -> MEP identifier: each system should be able to generate its own format of MEP-ID and to receive any format of MEP-ID that is defined today and will be defined in the future because you cannot predict/avoid misconnections between MEPs using different identification schemes. I would suggest to take a look at the following draft to understand todays best-in-class solution for supporting an extensible and future proof solution allowing different types of MEP identification schemes: http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-06 The secret spice is to do a bit-by-bit comparision between the expected MEP-ID and the received MEP-ID and to define a typed encoding for the MEP identifiers. Please note that section 2.1.4 of RFC 5860 requires that the solution must be "extensible to support additional identification schemes". -> MIP identifier: the traceroute should discover the MIP-ID at a given TTL distance and use that identifier for connectivity verification toward that MIP. How can you impose all the MIPs to have the same structure? 3) I understood the objective of the work was to allow inter-domain/inter- provider MPLS-TP deployment with e2e OAM support. When this objective has been changed? 4) Control plane identifiers are separated from data plane and OAM identifier so I think this argument is outside the scope of the draft. ----Messaggio originale---- Da: swallow@cisco.com Data: 25-apr-2011 23.16 A: Ogg: [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. 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. We are looking for input/consensus from the WG. George, Eric, & Matthew From erminio.ottone_69@libero.it Mon May 2 14:55: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 08EE1E06AC for ; Mon, 2 May 2011 14:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 ecQNiF6JfeaQ for ; Mon, 2 May 2011 14:55:01 -0700 (PDT) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFAE0674 for ; Mon, 2 May 2011 14:54:57 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020A.4DBF282F.0072,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out3.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D7F478503FD52D9 for mpls@ietf.org; Mon, 2 May 2011 23:54:55 +0200 Message-ID: <21135535.1224811304373295077.JavaMail.defaultUser@defaultHost> Date: Mon, 2 May 2011 23:54:55 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Subject: [mpls] I: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:55:04 -0000 Forwarding the messate to the MPLS WG mailing list ... ----Messaggio originale---- Da: erminio.ottone_69@libero.it Data: 2-mag-2011 23.43 A: Ogg: R: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Where this work has to be done? =20 What are the specific issues that need further understanding? =20 The ITU-T LS provides a solution: what are the technical issues with the IT= U-T=20 proposal? ----Messaggio originale---- Da: nurit.sprecher@nsn.com Data: 27-apr-2011 7.43 A: , "George Swallow" Cc: Ogg: 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=E2=80=A6 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=20 mixing identifiers.=20 Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= =20 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 ba= sed=20 identifiers. Insisting that both ends of a LSP or PW must use the same sch= eme=20 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,=20 including having independent identifiers. The draft describes the mapping= =20 between the GMPLS identifiers used by the control plane and the data plane= =20 identifiers.=20 >From the perspective of the data plane an identifier is inserted at the sou= rce=20 and received by the sink. Neither the source or sink need to understand th= e=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.=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 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS= =20 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= =20 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 chec= k=20 that it matches the expected string=20 3. The extent inter-provider MPLS-TP is as yet unknown. If mixed mo= des=20 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=20 provider transport network=20 4. For signaled connections, there is no plan to allow routing based= on=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 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=20 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 From erminio.ottone_69@libero.it Mon May 2 14:55: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 3F48AE07B8 for ; Mon, 2 May 2011 14:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 IzWAM+9BbKzf for ; Mon, 2 May 2011 14:55:25 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id 09F03E07BA for ; Mon, 2 May 2011 14:55:18 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4DBF2844.004A,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DBE82150011591A for mpls@ietf.org; Mon, 2 May 2011 23:55:16 +0200 Message-ID: <11249943.1224891304373316224.JavaMail.defaultUser@defaultHost> Date: Mon, 2 May 2011 23:55:16 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Subject: [mpls] I: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:55:26 -0000 Forwarding the messate to the MPLS WG mailing list ... >----Messaggio originale---- >Da: erminio.ottone_69@libero.it >Data: 2-mag-2011 23.49 >A: >Ogg: R: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >If you encode the identifier is a typed structure, the type would be part= =20 of=20 >the ordering key. > >I agree that an ordering convention needs to be defined. > >----Messaggio originale---- >Da: Alexander.Vainshtein@ecitele.com >Data: 27-apr-2011 8.06 >A: "Sprecher, Nurit (NSN - IL/Hod HaSharon)",=20 "Malcolm. >BETTS@zte.com.cn" >Cc: "mpls@ietf.org" >Ogg: 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= =20 in=20 >certain situations these identifiers are treated as an ordered set, i.e., = it=20 is=20 >possible to say when one of these identifiers is =E2=80=9Cless=E2=80=9D th= an the other one.=20 >The typical use case is tie-breaking in various protocols (e.g., for=20 deciding=20 >which request for a protection-related has to be granted). Even if the=20 current=20 >set of MPLS-TP protocols does not use such tie-breakers, I would not=20 preclude=20 >this usage in future. >=20 >It is relatively simple to impose some order on identifiers of the same=20 type.=20 >Imposing an order on a superset of identifiers at least requires some=20 thought. >=20 >Regards, > Sasha > > > From erminio.ottone_69@libero.it Mon May 2 14:57: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 E9C7FE07B8; Mon, 2 May 2011 14:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 yrZLzPRSPNk2; Mon, 2 May 2011 14:57:52 -0700 (PDT) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id DB441E078C; Mon, 2 May 2011 14:57:51 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4DBF28DA.011A,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out3.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D7F478503FD5ABE; Mon, 2 May 2011 23:57:46 +0200 Message-ID: <10646028.1225131304373466821.JavaMail.defaultUser@defaultHost> Date: Mon, 2 May 2011 23:57:46 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.45.147.23 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:57:53 -0000 Section 2.1.4 of RFC5860 states: For certain functions, OAM messages need to incorporate identification information (e.g., of source and/or destination nodes). The protocol solution(s) MUST at least support identification information in the form of an IP addressing structure and MUST also be extensible to support additional identification schemes. If an operator A supports IP-based identifiers and operator B supports ICC- based identifiers, how can we setup a transport path (LSP or PW) between the two operators? ----Messaggio originale---- Da: gregimirsky@gmail.com Data: 28-apr-2011 1.11 A: Cc: "mpls@ietf.org", Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? 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 ToGeorge Swallow , "mpls@ietf.org" ccSubjectRe: [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 From erminio.ottone_69@libero.it Mon May 2 15:04: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 2D0F9E07E7; Mon, 2 May 2011 15:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 HLifP5CEwgO4; Mon, 2 May 2011 15:04:17 -0700 (PDT) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id CA7EBE07E2; Mon, 2 May 2011 15:04:16 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0204.4DBF2A5A.004C,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DBEE74F00053718; Tue, 3 May 2011 00:04:09 +0200 Message-ID: <27854167.1225641304373849966.JavaMail.defaultUser@defaultHost> Date: Tue, 3 May 2011 00:04:09 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 22:04:18 -0000 Are you sure it is a late breaking requirement? I was able to track back this requirement back in the following ITU-T LS on= 12=20 April 2010 (i.e., more than one year ago): https://datatracker.ietf.org/liaison/868/ In particular see the comment m14: Comment [M14]: How is the case of a PW, LSP or tunnel that=20 transits two domains, where one uses ICC format and the other uses IP forma= t=20 addressed. ----Messaggio originale---- Da: jdrake@juniper.net Data: 28-apr-2011 1.25 A: "Malcolm.BETTS@zte.com.cn" Cc: "mpls@ietf.org", "mpls-bounces@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, =20 I interpreted Eric=E2=80=99s use of =E2=80=98stitching=E2=80=99 to be in = the RFC 5150 sense. I=20 think I will let him clarify, but if used in the RFC 5150 sense, a =E2=80= =98stitched=E2=80=99=20 LSP would have end-to-end OAM, and different pieces could use different=20 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 stitch= ing=20 point, this requires a complex interworking function and interrupts the end= to=20 end OAM flow - i.e. data packet can transit without any manipulation (other= =20 than the normal label swap) but OAM packets must be intercepted and manipul= ated=20 in the middle of the connection so it is no longer an end to end construct.= =20 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 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 Malcolm,=20 =20 That=E2=80=99s incorrect. There is a single end-to-end LSP composed of dif= ferent=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=20 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= =20 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 where= =20 there=20 might be an identifier form change and "stitch" them together if that is wh= at=20 the=20 operators want/agree to do. This limits the need-to-know for the mapping o= f=20 one=20 form of identifier to the other to the point at which this occurs, rather t= han=20 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 Geo= rge=20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS= =20 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 mo= des=20 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=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 the providers involved will need to run BGP and have AS numbers.=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=20 From erminio.ottone_69@libero.it Mon May 2 15:13: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 A2278E06D1; Mon, 2 May 2011 15:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 X93HbnS4LH0z; Mon, 2 May 2011 15:13:15 -0700 (PDT) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62EE06BE; Mon, 2 May 2011 15:13:14 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4DBF2C76.000B,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out3.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D7F478503FD7EA7; Tue, 3 May 2011 00:13:09 +0200 Message-ID: <13144777.1226221304374389617.JavaMail.defaultUser@defaultHost> Date: Tue, 3 May 2011 00:13:09 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 22:13:16 -0000 If my name is XYZ and your name is 123, I do want to change my name in orde= r to=20 talk to you. How can a requirement RFC require the interconnection between IP-based and = ICC- based identifiers before these identifiers are defined? I can see requirements for supporting different identifiers schemes and=20 requirements to support multi-domain interconnection. I do not see any=20 requirement that limit inter-domain interconnection only between domains th= at=20 have the same identifiers scheme. Have I missed some requirement? ----Messaggio originale---- Da: jdrake@juniper.net Data: 28-apr-2011 18.22 A: "Malcolm.BETTS@zte.com.cn" Cc: "mpls@ietf.org", "mpls-bounces@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Comments inline. =20 Sent from my iPhone =20 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]=20 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? =20 John,=20 John, if you do not allow mix identifier types how can you have an end to e= nd=20 CV message. JD: The endpoints have to agree on a common format for the data plane. Th= at=E2=80=99 s the whole point of the discussion. If you are using stitching to allow a single identifier type then the=20 identifiers in a CV message must be translated at the stitching point. A v= ery=20 bad idea!=20 JD: I never proposed this. You have a tendency to attribute a silly idea = to=20 someone and then ridicule it. Btw, you might consider reviewing RFC 5150. This is not a "late breaking requirement". The requirements for support of= =20 both ICC and IP identifiers schemes is well documented. As is the expectat= ion=20 of using MPLS-TP in multi-operator transport networks. Hence the need to= =20 support both on a LSP/PW. This comment has been made during previous last= =20 calls on this draft. JD: If it is not in the MPLS-TP requirements RFCs, it is by definition a l= ate=20 breaking requirement. Regards,=20 Malcolm=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 Malcolm,=20 =20 I interpreted Eric=E2=80=99s use of =E2=80=98stitching=E2=80=99 to be in = the RFC 5150 sense. I=20 think I will let him clarify, but if used in the RFC 5150 sense, a =E2=80= =98stitched=E2=80=99=20 LSP would have end-to-end OAM, and different pieces could use different=20 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 stitch= ing=20 point, this requires a complex interworking function and interrupts the end= to=20 end OAM flow - i.e. data packet can transit without any manipulation (other= =20 than the normal label swap) but OAM packets must be intercepted and manipul= ated=20 in the middle of the connection so it is no longer an end to end construct.= =20 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 Malcolm,=20 =20 That=E2=80=99s incorrect. There is a single end-to-end LSP composed of dif= ferent=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=20 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 Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =20 =20 As one of the co-authors on this draft, I support a restriction to using a= =20 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= =20 there=20 might be an identifier form change and "stitch" them together if that is wh= at=20 the=20 operators want/agree to do. This limits the need-to-know for the mapping o= f=20 one=20 form of identifier to the other to the point at which this occurs, rather t= han=20 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 Geo= rge=20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS= =20 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 mo= des=20 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=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 the providers involved will need to run BGP and have AS numbers.=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=20 From erminio.ottone_69@libero.it Mon May 2 15:21: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 AAFAEE07F3 for ; Mon, 2 May 2011 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 mG9QV2l3cVqL for ; Mon, 2 May 2011 15:21:42 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7AFE07F7 for ; Mon, 2 May 2011 15:21:41 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4DBF2E71.0134,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DBE82150011913B; Tue, 3 May 2011 00:21:37 +0200 Message-ID: <12135398.1226781304374897837.JavaMail.defaultUser@defaultHost> Date: Tue, 3 May 2011 00:21:37 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , George Swallow MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Cc: mpls@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 22:21:43 -0000 What type of identifers are you planning to use within your network? ICC or= IP=20 based identifers or both? What about an MS-PW where the two T-PEs are located within two domains that= =20 support different identifier schemes? >----Messaggio originale---- >Da: agmalis@gmail.com >Data: 2-mag-2011 21.48 >A: "George Swallow" >Cc: >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >George et al, > >Verizon does not have any requirement for mixed use of Global IDs and >ICCs. We are fine with specifications that require both ends of an LSP >to use one or the other. > >Thanks, >Andy > >On Mon, Apr 25, 2011 at 5:16 PM, George Swallow wrote: >> 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= =20 each >> end of an LSP. =C2=A0Currently the draft allows a Tunnel, LSP, PW, or ME= G to=20 use >> either the Global-ID for both ends or or the ICC for both ends. =C2=A0Mi= xed use >> is not permitted. >> >> The ITU liaison requests that we allow mixed use. >> >> The authors of the draft are very reluctant to do this. >> >> Obtaining an AS Number (from which the Global-ID is derived) is a fairly >> trivial procedure. =C2=A0Many organizations if not most already have AS= =20 Numbers. >> Such an addition will add numerous object formats, and test cases. >> The extent inter-provider MPLS-TP is as yet unknown. =C2=A0If mixed mode= s of=20 ICC >> and Global-ID identification is required, they can be added later. >> For signaled connections, there is no plan to allow routing based on=20 either >> the Global-ID or ICC. =C2=A0That would be a radical change to how IP wor= ks. >> =C2=A0However for IP routing to work (in order to forward the signaling >> messages), the providers involved will need to run BGP and have AS=20 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 > From gregory.mirsky@ericsson.com Mon May 2 15:31:45 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 3012CE0803 for ; Mon, 2 May 2011 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[AWL=0.635, 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 h5sRgZF3SZyO for ; Mon, 2 May 2011 15:31:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 561E6E06CE for ; Mon, 2 May 2011 15:31:44 -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 p42MVfOb016136; Mon, 2 May 2011 17:31:43 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 2 May 2011 18:31:39 -0400 From: Gregory Mirsky To: "erminio.ottone_69@libero.it" , "Malcolm.BETTS@zte.com.cn" Date: Mon, 2 May 2011 18:31:36 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJFAI496tbn6GRSmaszuOIFmkk2gABDH6g Message-ID: References: <10646028.1225131304373466821.JavaMail.defaultUser@defaultHost> In-Reply-To: <10646028.1225131304373466821.JavaMail.defaultUser@defaultHost> 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] R: Re: 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, 02 May 2011 22:31:45 -0000 Dear Erminio, I don't see an issue with NMS setting an LSP that crosses domains that util= ize different, IP-based and ICC-based, identifiers. The problem, as being i= dentified, in running e2e OAM on such LSP. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Monday, May 02, 2011 2:58 PM To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Section 2.1.4 of RFC5860 states: For certain functions, OAM messages need to incorporate identification information (e.g., of source and/or destination nodes). The protocol solution(s) MUST at least support identification information in the form of an IP addressing structure and MUST also be extensible to support additional identification schemes. If an operator A supports IP-based identifiers and operator B supports ICC-= based identifiers, how can we setup a transport path (LSP or PW) between t= he two operators? ----Messaggio originale---- Da: gregimirsky@gmail.com Data: 28-apr-2011 1.11 A: Cc: "mpls@ietf.org", Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Dear Malcolm, I agree that e2e OAM is one of requirements for MPLS-TP but I cannot find=20 implicit, less explicit requirement to support e2e OAM over MPLS-TP LSP and= PW=20 with heterogeneous addressing (mixed IP and ICC). Regards, Greg On Wed, Apr 27, 2011 at 3:44 PM, wrote: Eric,=20 If you "stitch" the LSP or PW and change identifiers you will not have end = to=20 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 27/04/2011 12:11 PM=20 ToGeorge Swallow , "mpls@ietf.org" =20 ccSubjectRe: [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= =20 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 where= =20 there=20 might be an identifier form change and "stitch" them together if that is wh= at=20 the=20 operators want/agree to do. This limits the need-to-know for the mapping o= f=20 one=20 form of identifier to the other to the point at which this occurs, rather t= han=20 at each=20 node in the LSP or (potentially) MS-PW.=20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge=20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS=20 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 mo= des=20 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=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 the providers involved will need to run BGP and have AS numbers.=20 We are looking for input/consensus from the WG. George, Eric, & Matthew _______________________________________________=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 erminio.ottone_69@libero.it Mon May 2 15:31: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 B7C41E0807 for ; Mon, 2 May 2011 15:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_17=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 nDKkgfg9X7lu for ; Mon, 2 May 2011 15:31:58 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 591BAE07FD for ; Mon, 2 May 2011 15:31:57 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4DBF30DB.0044,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail8.libero.it (172.31.0.77) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D63C9BA058EE8FA; Tue, 3 May 2011 00:31:54 +0200 Message-ID: <32953866.1227541304375514800.JavaMail.defaultUser@defaultHost> Date: Tue, 3 May 2011 00:31:54 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "huubatwork@gmail.com" , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.147.23 Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 22:31:58 -0000 I do not understand how this discussion is related to the OAM debate regard= ing=20 G.8113.1. Nevertheless, I have not seen any supporter of G.8113.1 stating no need for= =20 end-to-end OAM nor the need for an OAM interworking function between G.8113= .1=20 and IETF-OAM domains. Could you provide some reference about this? I might have missed them. ----Messaggio originale---- Da: eric.gray@ericsson.com Data: 28-apr-2011 23.17 A: "huubatwork@gmail.com", "mpls@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Huub, Please see below... --Eric From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huu= b=20 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=20 CV message. If you are using stitching to allow a single identifier type t= hen=20 the identifiers in a CV message must be translated at the stitching point. = A=20 very bad idea!=20 Indeed! Actually I think a fair number of us disagree. It seems obvious (to me at= =20 least) that some sort of OAM interworkingfunction is going to be necessary,= =20 given that there is almost certainlya non-null intersection of operators th= at=20 use ICC format identifiers, whoalso plan to use OAM as specified in G8113.1= and=20 who are now arguing they want end-to-end OAM with operators who will use Gl= obal=20 identifiersand may very well use OAM as specified in IETF RFCs. Given that = such=20 an interworking requirement is likely, it is a far betteruse of time and en= ergy=20 to start thinking about how such an interworkingfunction would work and wou= ld=20 most likely support translation of ICC andGlobal Identifiers. It is certain= ly a=20 better use of time and energy than it is to try to support a presumed mixin= g of=20 the two formats in a single administrative domain.=20 This is not a "late breaking requirement". The requirements for support of= =20 both ICC and IP identifiers schemes is well documented. As is the expectat= ion=20 of using MPLS-TP in multi-operator transport networks. Hence the need to= =20 support both on a LSP/PW. This comment has been made during previous last= =20 calls on this draft.=20 Correct. I fully agree with your assessment. Unfortunately this is an incorrect (or naive) assessment.=20 Many houses have both a furnace and one or more sets of furniture. It is=20 certainly arguable that the need for both is a rigid requirement insome of = the=20 less temperate zones. Should this be formalized as a crystal clear housing= =20 requirement, I'mpretty sure that no one would subsequently interpret it to = mean=20 thatboth the furniture and the furnace need to be able to occupy the samesp= ace=20 in the same house. Since the apparent "requirement" that the same messages= =20 should beable to include either or both of the required identifiers, and th= is=20 is notobvious from the assertion of a requirement to merely allow support= =20 forboth, this is indeed a late-breaking requirement.=20 Best regards, Huub. Sent from my mobile device. John E Drake 27/04/2011 07= :25=20 PM=20 To"Malcolm.BETTS@zte.com.cn" ccEric Gray , "mpls@ietf.org" , "mpls-bounces@ietf.org= "=20 SubjectRE: [mpls] Mixing ICC and Global-IDs in MPLS= -TP=20 Identifiers? Malcolm,=20 =20 I interpreted Eric=E2=80=99s use of =E2=80=98stitching=E2=80=99 to be in = the RFC 5150 sense. I=20 think I will let him clarify, but if used in the RFC 5150 sense, a =E2=80= =98stitched=E2=80=99=20 LSP would have end-to-end OAM, and different pieces could use different=20 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 stitch= ing=20 point, this requires a complex interworking function and interrupts the end= to=20 end OAM flow - i.e. data packet can transit without any manipulation (other= =20 than the normal label swap) but OAM packets must be intercepted and manipul= ated=20 in the middle of the connection so it is no longer an end to end construct.= =20 User data and OAM no longer fully fate share.=20 Regards,=20 Malcolm=20 John E Drake 27/04/2011 06:53 PM=20 To"Malcolm.BETTS@zte.com.cn" , Eric Gray cc"mpls@ietf.org" , "mpls-bounces@ietf.or= g"=20 SubjectRE: [mpls] Mixing ICC and Global-IDs in MPLS= -TP=20 Identifiers? =20 Malcolm,=20 =20 That=E2=80=99s incorrect. There is a single end-to-end LSP composed of dif= ferent=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=20 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 27/04/2011 12:11 PM=20 =20 ToGeorge Swallow , "mpls@ietf.org" cc SubjectRe: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 As one of the co-authors on this draft, I support a restriction to using a= =20 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= =20 there=20 might be an identifier form change and "stitch" them together if that is wh= at=20 the=20 operators want/agree to do. This limits the need-to-know for the mapping o= f=20 one=20 form of identifier to the other to the point at which this occurs, rather t= han=20 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 Geo= rge=20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS= =20 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 mo= des=20 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=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 the providers involved will need to run BGP and have AS numbers.=20 We are looking for input/consensus from the WG. From sriganeshkini@gmail.com Mon May 2 17:50: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 A5282E072D for ; Mon, 2 May 2011 17:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.364, 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 5o7qnZQWiSPc for ; Mon, 2 May 2011 17:50:41 -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 073C0E06F5 for ; Mon, 2 May 2011 17:50:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so3863209qwc.31 for ; Mon, 02 May 2011 17:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=cNxi457xf8FfKPyTBjAqpw5xJiaC9q/Nle/0xTXNTXs=; b=uEGWO9onEKZ2vjgIV7SSGGHu/zEjd8B3HOWkfvzahylVgs4bISdDl4acNy4cNi0/i2 G8yMYe2CM2PCug1igmvvegrArV47vypYWpuobFGdhNlSh18kP+HB1xomEkg3PPhJOn6/ K/jvQiqj8hOZWYye8qlpPk0UNz1OcnpzluI4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=aiJMN+wE9/gk/RnrWSVNjkx8uFP4j9JQ9yovlp/mBPhvAzM49T3wzZ77jg5urtXpOZ TtPPjdZILSpCVZ6eWaCD/1zzsI1x+JeYTKw6ds37W3XUH6YWB+cr+Buoh6aVf9Uz0Yeq XDHLqQ3foLELC7LUBGD6yt87s+MmC734PsZYQ= Received: by 10.229.190.133 with SMTP id di5mr5922691qcb.286.1304383840263; Mon, 02 May 2011 17:50:40 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.75.13 with HTTP; Mon, 2 May 2011 17:50:10 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0978A0555@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0978A0555@EMBX01-HQ.jnpr.net> From: Sriganesh Kini Date: Mon, 2 May 2011 17:50:10 -0700 X-Google-Sender-Auth: KOFnigeApjowbuKvEkUKZzPrLOY Message-ID: To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ross Callon , "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: Tue, 03 May 2011 00:50:41 -0000 inline On Thu, Apr 28, 2011 at 3:38 PM, John E Drake wrote: > > > 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 >> >> Hi Kireeti and other authors, >> >> Need a couple clarification >> 1. This draft seems to apply to the TE LSP (or transport LSP) =A0for 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: =A0You mean figure 7|8 in section 3.4.5? =A0But yes, entropy labels a= pply to 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: =A0It's always bottom of stack, so if it is present, it was placed th= ere by the client. Ok. Since the EL has to be placed by the client, but cannot be placed by the ingress LSR of the Transport LSP (when the packet received from the CE is MPLS), it may be useful to state this explicitly in section 3 para that starts with "EL labels are generated by the ingress LSR <> ..." > >> >> 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 - Sri From neil.2.harrison@bt.com Tue May 3 00:36: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 52BECE06E2 for ; Tue, 3 May 2011 00:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Txwb69SaM4gU for ; Tue, 3 May 2011 00:36:27 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E337CE07A2 for ; Tue, 3 May 2011 00:36:25 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 3 May 2011 08:36:05 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.191]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 3 May 2011 08:36:23 +0100 From: To: Date: Tue, 3 May 2011 08:36:19 +0100 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJAfpPX/77B1LtRG+iMhIxTrCwiAAWzy9g Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44022F2FCFC@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Tue, 03 May 2011 07:36:28 -0000 Hi Andy, 2 points: 1 I agree with your view of only having a single addressing scheme in a sin= gle layer network solely belonging to one party. Though you may need to be= rather careful if you also advocate that one can also have peer layer inte= rworking between different parties, ie E-NNIs (I believe this is something = you may support, eg old MPLSF case?). In such a peer interworking case it = would seem one must allow different addressing schemes (and indeed any othe= r variations in DP/CP functional components) if they exist in the standards= . =20 Of course, having an E-NNI and peer interworking between different parties = in any non-TOS layer network (not just MPLS) is not technically necessary (= this is trivial to prove), and this provides a strong argument for only hav= ing a single addressing scheme in a non-TOS layer network. 2 You should also be aware that in client/server interworking of the co-ps = mode using variable size traffic units, and therefore something rather impo= rtant for MPLS-TP in the role of a transport network (I'll ignore issues of= transparency here), there could be inter-layer misconnectivity (Aside=3D> = This case cannot occur in the co-cs mode). To date, however, we have only = really considered intra-layer misconnectivity, ie between different LSPs be= longing to the same party (note this also includes all cases of nested LSP = sublayer misconnectivity). In the case of inter-layer misconnectivity one may receive traffic units an= d OAM messages from some other party's layer network. The OAM messages may= come from (i) networks using different OAM/addressing solutions or (ii) ne= tworks using the same OAM/addressing solutions. In both cases there are di= fferent issues wrt inter-layer misconnectivity one has to deal with. I'm n= ot aware that these cases have been considered yet. I'd like to hear your comments on both these points, but in particular the = first one.....especially if you also support the notion of E-NNIs in MPLS-T= P, as there seems to a possible logical conflict here. Thanks. regards, 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 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Andrew G. Malis > Sent: 02 May 2011 20:48 > To: George Swallow > Cc: mpls@ietf.org > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > George et al, >=20 > Verizon does not have any requirement for mixed use of Global IDs and > ICCs. We are fine with specifications that require both ends of an LSP > to use one or the other. >=20 > Thanks, > Andy >=20 > On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > wrote: > > 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. =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. > > > > Obtaining an AS Number (from which the Global-ID is derived) is a > fairly > > trivial procedure. =A0Many 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. =A0If 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. =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 > > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Tue May 3 01:48: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 31749E073D for ; Tue, 3 May 2011 01:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 XgS6Wm-2-KLZ for ; Tue, 3 May 2011 01:48:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 08F69E073A for ; Tue, 3 May 2011 01:48:15 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 3 May 2011 09:47:54 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.191]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 3 May 2011 09:48:13 +0100 From: To: , , Date: Tue, 3 May 2011 09:48:07 +0100 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJFAI496tbn6GRSmaszuOIFmkk2gABDH6gABS1VPA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44022F2FE31@EMV62-UKRD.domain1.systemhost.net> References: <10646028.1225131304373466821.JavaMail.defaultUser@defaultHost> 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 Subject: Re: [mpls] R: Re: 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, 03 May 2011 08:48:16 -0000 Hi Greg, A lesson that should have been learned a long time ago is that the most sen= sible/obvious OAM identifier to use in CV-like OAM packets in co-cs/co-ps m= ode layer networks is the actual source address of the layer network connec= tion (in cl-ps mode networks we are forced to place this in each/every traf= fic unit as we cannot take labelling short-cuts here as we have no connecti= on to convey the SA semantic under defect-free conditions). Of course one can choose to have a different OAM identifier instead of the = connection's source address....but so what?...one still must have uniquenes= s in a 1:1 sense wrt the 2 sets. So all one has gained is additional compl= exity via such a mapping. Not a great idea IMO. Aside=3D> A long time ago some operators used to use text-like strings to i= dentify co-cs mode connections....simply because this is what their Operati= ons folks were used to. It's not a good arch solution of course for OAM me= ssage misconnectivity detection purposes. However, you are right in a sense below if you are considering some E-NNI c= ase between 2 different network operators. This however, seems a very stra= nge basis on which to justify allowing different addressing schemes in a si= ngle horizontally partitioned non-TOS layer network, as it is quite trivial= to prove that such peer interworking cases are technically quite unnecessa= ry. Good as a job creation scheme however.....and I have never known a sin= gle technology promoting forum not promote E-NNIs despite their being unnec= essary in all non-TOS cases ;-) regards,=20 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 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Gregory Mirsky > Sent: 02 May 2011 23:32 > To: erminio.ottone_69@libero.it; Malcolm.BETTS@zte.com.cn > Cc: mpls@ietf.org > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? >=20 > Dear Erminio, > I don't see an issue with NMS setting an LSP that crosses domains that > utilize different, IP-based and ICC-based, identifiers. The problem, as > being identified, in running e2e OAM on such LSP. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: Monday, May 02, 2011 2:58 PM > To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? >=20 > Section 2.1.4 of RFC5860 states: >=20 > For certain functions, OAM messages need to incorporate > identification information (e.g., of source and/or destination > nodes). The protocol solution(s) MUST at least support > identification information in the form of an IP addressing structure > and MUST also be extensible to support additional identification > schemes. >=20 > If an operator A supports IP-based identifiers and operator B supports > ICC- based identifiers, how can we setup a transport path (LSP or PW) > between the two operators? >=20 >=20 > ----Messaggio originale---- > Da: gregimirsky@gmail.com > Data: 28-apr-2011 1.11 > A: > Cc: "mpls@ietf.org", > Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > 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). >=20 > Regards, > Greg >=20 > On Wed, Apr 27, 2011 at 3:44 PM, wrote: >=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 >=20 >=20 > Eric Gray > Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM > ToGeorge Swallow , "mpls@ietf.org" > ccSubjectRe: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 >=20 >=20 >=20 > 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. >=20 > 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. >=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? >=20 > 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 > 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. >=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 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=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 Manuel.Paul@telekom.de Tue May 3 02:34:06 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 D291BE06F2 for ; Tue, 3 May 2011 02:34:06 -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=[AWL=0.000, 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 3rkEcaNFVKa6 for ; Tue, 3 May 2011 02:34:05 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id DAE81E06AA for ; Tue, 3 May 2011 02:34:03 -0700 (PDT) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 03 May 2011 11:33:47 +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; Tue, 3 May 2011 11:33:46 +0200 From: To: , , Date: Tue, 3 May 2011 11:33:31 +0200 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFBXYbQnS5CrT4ylyW0UNm7Y0wBUJvjwAB/KQCAAxO2wkA== Message-ID: <9435EDACD941174099E143BCA2BCD615F720F6159D@HE101452.emea1.cds.t-internal.com> References: 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: 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, 03 May 2011 09:34:06 -0000 Q2hhbmdlZCB0byBwbGFpbiB0ZXh0IGFuZCByZXNlbmQgYXMgdGhlIGZpcnN0IHRyeSBoYXNu4oCZ dCBtYWRlIGl0IHRvIHRoZSBsaXN0IGR1ZSB0byBzaXplIGxpbWl0cy4NCg0KUmVnYXJkcywNCk1h bnVlbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBQ YXVsLCBNYW51ZWwNClNlbnQ6IE1vbmRheSwgTWF5IDAyLCAyMDExIDM6NDYgUE0NClRvOiAnRXJp YyBHcmF5JzsgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuOyBHZW9yZ2UgU3dhbGxvdw0KQ2M6IG1w bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlE cyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KDQpEZWFyIEFsbCwNCg0KUGxlYXNlIHNlZSBzb21l IGNvbW1lbnRzIGlubGluZSBtYXJrZWQgd2l0aCBbTVBdLg0KDQpUaGFua3MsDQpNYW51ZWwNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFcmljIEdyYXkNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyOCwgMjAxMSAxMDo1OCBQTQ0KVG86 IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjsgR2VvcmdlIFN3YWxsb3cNCkNjOiBtcGxzQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBM Uy1UUCBJZGVudGlmaWVycz8NCg0KTWFsY29sbSwNCg0KICAgIFRoZXJlIGlzIG5vdGhpbmcgYWJv dXQgbm90IG1peGluZyB0aGUgdHdvIGlkZW50aWZpZXIgZm9ybWF0cyB0aGF0DQpwcmV2ZW50cyBh biBvcGVyYXRvciBmcm9tIGNvbnRpbnVpbmcgdG8gdXNlIElDQyBpZGVudGlmaWVycyB3aXRoaW4N CnRoZWlyIG93biBuZXR3b3JrLiAgVGhlIGltcGxpY2F0aW9uIHRoYXQgaXQgaXMgb2theSB0byBy ZXF1aXJlIGFueQ0Kb3BlcmF0b3IgdGhhdCBkb2VzIG5vdCB1c2UgSUNDIGlkZW50aWZpZXJzIHRv IGJlIGFibGUgdG8gcmVjb2duaXplDQp0aGVtLCBidXQgaXQgaXMgbm90IG9rYXkgZm9yIGFuIG9w ZXJhdG9yIHRoYXQgdXNlIHRoZW0gdG8gYmUgYWJsZSB0bw0KcmVjb2duaXplIHRoZSBHbG9iYWwg SWRlbnRpZmllciBmb3JtYXQsIGlzIGRlY2lkZWRseSBvbmUgc2lkZWQuDQoNCltNUDpdIEFncmVl IHRoYXQgdGhpcyBzaG91bGQgYmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIGFsbCBzaWRlcyBvZiB0 aGUgc3RvcnksIGFsdGhvdWdoIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGNvbnNpZGVyYXRpb25z IChvZnRlbiBzdHJlc3NlZCBhbG9uZyB0aGUgTVBMUyBPQU0gZXh0ZW5zaW9uIGRlYmF0ZSkgYXBw bHkgaGVyZSB0b28uIEl0cyBhbW9uZyBUUOKAmXMgcHJpbWFyeSB0YXJnZXRzIHRvIGZpdCBmb3Ig Y2xhc3NpY2x5IG9wZXJhdGVkIHRyYW5zcG9ydCBuZXR3b3JrcywgdG8gc2F2ZSBlZmZvcnRzIGFu ZCBhdm9pZCAgZGlzcnVwdGl2ZSAocHJpbWFyaWx5IG9wZXJhdGlvbmFsKSBjaGFuZ2VzIGluIHRo aXMgYXJlbmEuIFBsYXRmb3JtcyBhcmVu4oCZdCBtaWdyYXRlZCB3aXRoIG9uZSBzaW5nbGUgc25p cCBvZiB0aGUgZmluZ2VyIChzb21ldGltZXMgbW9yZSBmb3Igb3BlcmF0aW9uYWwgcmF0aGVyIHRo YW4gdGVjaG5pY2FsIGNvbXBsZXhpdHkpLiBJbiBhIHJlYWwgd29ybGQsIG1heSBuZWVkIHRvIGlu dGVyY29ubmVjdCBwbGF0Zm9ybXMgaW4gZGlzdGluY3QgcGhhc2VzIG9mIGV2b2x1dGlvbi4gSW4g Y2FzZSBvZiBuZWVkIGZvciBoYW5kb3ZlcnMsIGFuIG9wZXJhdG9yIHNob3VsZCBoYXZlIHRoZSBm bGV4aWJpbGl0eSB0byBkZWNpZGUgd2hhdCBkZXZpY2UgY2xhc3MgaXMgZWFzaWVzdCB0byBiZSAo ZXZvbHV0aW9uYXJ5KSB0b3VjaGVkIGFuZCB0dW5lZCwgaS5lLiBzdXBwb3J0aW5nIG1peGVkIGlk ZW50aWZpZXJzLiBJIGFkbWl0IHRoaXMgb2NjdXJyZW5jZSBwcm9iYWJseSB3aWxsIG5vdCBiZSBh cyBncmFudWxhciBhcyB0aGUgZ2VuZXJhbCByZXF1aXJlbWVudCBmb3IgRW5kLXRvLUVuZCBPQU0g aW50ZXJvcGVyYWJpbGl0eSBpbiBhIG11bHRpLXZlbmRvciB0cmFuc3BvcnQgbmV0d29yayBlbnZp cm9ubWVudCB3aGVyZSB0aGUgYm91bmRhcmllcyBhcmUgZHJhd24gYWNjb3JkaW5nIHRvIHRoZSBy ZWFjaCBvZiBvcHRpY2FsIHRyYW5zcGFyZW5jeSBkb21haW5zIGFuZC9vciBuZXR3b3JrIG1hbmFn ZW1lbnQgZmVhc2liaWxpdGllcy4NCg0KICAgIEJ1dCwgdG8gYmUgYWJsZSB0byByZWNvZ25pemUg dGhlIEdsb2JhbCBpZGVudGlmaWVyIGZvcm1hdCwgdGhlIElDQw0KdXNlciBoYXMgdG8gZmlyc3Qg YmUgYWJsZSB0byBzdXBwb3J0IHRoaXMgZm9ybWF0LiAgQ29udHJhcnkgdG8geW91cg0KYXNzZXJ0 aW9uLCB0aGUgZm9ybWF0IGFuZCBjb21wYXJpc29uIHNlbWFudGljcyBvZiB0aGUgdHdvIGFyZSBu b3QNCnRoZSBzYW1lLg0KDQpbTVA6XSBJcyBpdCByZWFsbHkgdGhhdCBkaWZmaWN1bHQgdG8gaGFu ZGxlIHdoZW4gd2UgZm9jdXMgb24gdGhlIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgZm9yIG5vdz8g QXMgaW4gY3VycmVudCBzY29wZSBvZiB0aGUgaWRlbnRpZmllcnMgZHJhZnQ/DQoNCiAgICBUaGUg R2xvYmFsIElkZW50aWZpZXIgZm9ybWF0IGNvbnNpc3RzIG9mIGEgcGFpciBvZiAzMi1iaXQgaW50 ZWdlcnMsDQppbiBuZXR3b3JrIGJpdC9ieXRlIG9yZGVyLiAgVGhlIElDQyBpcyBhIGxpdHRlcmFs IHN0cmluZy4gIE1vc3Qgb2YgdXMNCmtub3cgdGhhdCB0aGUgc2FtZSBjb21wYXJpc29uIG9wZXJh dGlvbiBjYW5ub3QgYmUgdXNlZCB3aXRoDQp0aGVzZSB0d28gZm9ybWF0cy4gIEZvciBleGFtcGxl LCBhIHZlcnkgc2lnbmlmaWNhbnQgZnJhY3Rpb24gb2YgYWxsDQpHbG9iYWwgSWRlbnRpZmllcnMg d291bGQgbWF0Y2ggaW4gYSBzdHJpbmcgY29tcGFyZSB3aXRoIHRoZSBlbXB0eQ0Kc3RyaW5nICgi IikuDQoNCg0KICAgIEhlbmNlIHRoZSBzcGVjaWZpYyBpZGVudGlmaWVyIHNlbWFudGljcyBpcyBz aWduaWZpY2FudC4NCg0KW01QOl0gV291bGRu4oCZdCBpdCBiZSBzdWZmaWNpZW50IHRvIHJlY29n bml6ZSBlaXRoZXIgZm9ybWF0IHRvIGtub3cgd2hhdCBzZW1hbnRpY3MgZG8gYXBwbHkgKCBvciBk byBub3QgYXBwbHkgKSB0byBoYW5kbGUgb25lLCBvciB0aGUgb3RoZXIsIG9yIGJvdGhzIGZvcm1h dHMgcHJvcGVybHkgb24gYSBub2RlPw0KV2hhdCBoYXBwZW5zIHRvZGF5IHdoZW4gYSBub2RlIHJl Y2VpdmVzIGFueSBmb3JtYXQgdGhhdCBpdCBkb2VzbuKAmXQgc3VwcG9ydD8gV291bGQgaXQgcmVz dWx0IGluIGEgY29uZnVzaW9uIC8gd3JvbmcgY29tcGFyaXNvbj8NCg0KSU1ITyBzb2x2aW5nIGlu dGVyLXByb3ZpZGVyIGludGVyZmFjZSBpc3N1ZXMgb3IgYXV0b21pemF0aW9uIGluIGFzc2lnbmVt ZW50IG1heSBiZSB0YWNrbGVkIHN1YnNlcXVlbnRseSwgaS5lLiBpbiBhIG5leHQgc3RlcC4NCg0K DQogICAgQXMgZm9yIHRoZSBpbnRlci1wcm92aWRlciBjYXNlLCBkbyB5b3Ugbm93IGFzc2VydCB0 aGF0IHRoZXJlIHdpbGwNCmluIGZhY3QgYmUgYSByZXF1aXJlbWVudCBmb3IgT0FNIGludGVyd29y a2luZywgZ2l2ZW4gdGhhdCBhdCBsZWFzdA0Kc29tZSBzdWJzZXQgb2YgdGhlIGNhcnJpZXJzIHRo YXQgdXNlIElDQyBmb3JtYXQgaWRlbnRpZmllcnMgYXJlIHRoZQ0Kc2FtZSBjYXJyaWVycyB3aG8g YXJndWVkIHRoYXQgdGhlIGFwcGxpY2F0aW9ucyB3ZXJlIG1vcmUgdGhhbg0Kc3VmZmljZW50bHkg ZGlmZmVyZW50IHRvIGp1c3RpZnkgc3BlY2lmaWNhdGlvbiBvZiBkaXN0aW5jdCBPQU0/DQoNCiAg ICBJZiB0aGVyZSBpcyBnb2luZyB0byBiZSBhIHJlcXVpcmVtZW50IGZvciBPQU0gaW50ZXdvcmtp bmcsIHRoZW4NCmxldCdzIGFsbG93IHRoYXQgdGhpcyBpbnRlcndvcmtpbmcgZnVuY3Rpb24gd2ls bCBwcm9iYWJseSBuZWVkIHRvDQpzdXBwb3J0IGlkZW50aWZpZXIgZm9ybWF0IGNvbnZlcnNpb24u ICBDZXJ0YWlubHkgd2Ugc2hvdWxkIG5vdCAtIGF0DQp0aGlzIHBvaW50IC0gcnVsZSB0aGlzIGxp a2VsaWhvb2Qgb3V0Lg0KDQogICAgQWxzbywgc2VlIGluLWxpbmUgcmVzcG9uc2VzIGJlbG93Lg0K DQotLQ0KRXJpYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24NClNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMjcsIDIwMTEgMTI6MDUgQU0NClRvOiBHZW9yZ2UgU3dhbGxvdw0KQ2M6IG1wbHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBN UExTLVRQIElkZW50aWZpZXJzPw0KDQpHZW9yZ2UsDQoNCkkgZG8gbm90IGFncmVlIHRoZSBwcm9w b3NlZCByZXNvbHV0aW9uIG9mIHRoaXMgY29tbWVudC4gIEFzIHN0YXRlZCBpbiB0aGUgZHJhZnQg YWxsb3dzIGFuIG9wZXJhdG9yIGNhbiBzZWxlY3QgdGhlIHVzZSBvZiBlaXRoZXIgR2xvYmFsIChJ UCkgb3IgSUNDIGJhc2VkIGlkZW50aWZpZXJzLiAgSW5zaXN0aW5nIHRoYXQgYm90aCBlbmRzIG9m IGEgTFNQIG9yIFBXIG11c3QgdXNlIHRoZSBzYW1lIHNjaGVtZSByZW1vdmVzIHRoZSBmcmVlZG9t IHRvIHNlbGVjdCB0aGUgYmV0d2VlbiBJQ0MgYW5kIEdsb2JhbCAoSVApIGlkZW50aWZpZXJzLg0K QXJlIHN1Z2dlc3RpbmcgdGhhdCB0aGUgc2FtZSBvcGVyYXRvciBtaWdodCBtYWtlIGRpZmZlcmVu dCBjaG9pY2VzIGluIGRpZmZlcmVudA0KcGFydHMgb2YgdGhlIHNhbWUgbmV0d29yaz8NCg0KW01Q Ol0gTG9va2luZyBhdCB0aGUgcmVhbGl0eSB3aGVyZSBwbGF0Zm9ybXMgYXJlbuKAmXQgbWlncmF0 ZWQgd2l0aCBvbmUgc2luZ2xlIHNuaXAgb2YgdGhlIGZpbmdlciAoc29tZXRpbWVzIGZvciBvcGVy YXRpb25hbCByYXRoZXIgdGhhbiB0ZWNobmljYWwgcmVhc29ucyksIGl0IG1heSBpbmRlZWQgYmUg b2YgcHJhY3RpY2FsIHJlbGV2YW5jZS4gV2FudCB0byBzYXksIGV2ZW4gYW4gaW50cmEtb3BlcmF0 b3IgYnV0IGludGVyLUFTIHNjZW5hcmlvIG1heSBiZSB0aGlua2FibGUuDQoNClRoaXMgc2VlbXMg dmVyeSB1bmxpa2VseSwgZXhjZXB0IHBvc3NpYmx5IGluIHRoZSBjYXNlIHdoZXJlIG9uZSBvcGVy YXRvciB3aG8NCnVzZXMgb25lIGZvcm1hdCBpZGVudGlmaWVyIGlzIGFjcXVpcmVkIGJ5IGFub3Ro ZXIgb3BlcmF0b3Igd2hvIHVzZXMgdGhlIG90aGVyLg0KDQpJbiBhbnkgY2FzZSwgaWYgdGhlIGRl Y2lzaW9uIHRvIHVzZSBhIHBhcnRpY3VsYXIgaWRlbnRpZmllciBpcyBtYWRlIGNvbnNpc3RlbnRs eQ0Kd2l0aGluIGFueSBhZG1pbnN0cmF0aXZlIGRvbWFpbiwgdGhlbiB0aGUgb251cyBpcyBvbiB0 aGUgYm91bmRhcnkgcG9pbnRzIHRvDQptYWtlIHN0dWZmIHdvcmssIG5vdCBvbiBldmVyeSBkZXZp Y2UgaW4gdGhlIG5ldHdvcmsuDQoNCk1QTFMtVFAgcmVxdWlyZXMgdGhhdCB0aGUgZGF0YSBwbGFu ZSBhbmQgY29udHJvbCBwbGFuZSBhcmUgaW5kZXBlbmRlbnQsIGluY2x1ZGluZyBoYXZpbmcgaW5k ZXBlbmRlbnQgaWRlbnRpZmllcnMuICBUaGUgZHJhZnQgZGVzY3JpYmVzIHRoZSBtYXBwaW5nIGJl dHdlZW4gdGhlIEdNUExTIGlkZW50aWZpZXJzIHVzZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmUgYW5k IHRoZSBkYXRhIHBsYW5lIGlkZW50aWZpZXJzLg0KSSBiZWxpZXZlIHlvdSBhcmUgY29ycmVjdCBp biB0ZXJtcyBvZiB3aGF0IHRoZSByZXF1aXJlbWVudHMgYXJlLiAgVGhlcmUgaXMgbm90aGluZw0K SSBhbSBhd2FyZSBvZiB0aGF0IHByZXZlbnRzIGFueSBvcGVyYXRvciBmcm9tIHVzaW5nIGEgZm9y bSBvZiBpZGVudGlmaWVyIHRoYXQgaXMgbm90DQpuZWNlc3NhcmlseSBjb25zaXN0ZW50IHdpdGgg dGhlaXIgY2hvaWNlIG9mIHNpZ25hbGluZyBvciBjb25maWd1cmF0aW9uLg0KDQpJdCBpcyBleGNl ZWRpbmdseSB1bmxpa2VseSB0aGF0IG9wZXJhdG9ycyB0aGF0IHVzZSBleGlzdGluZyAoRylNUExT IHNpZ25hbGluZyB3aWxsDQpiZSBpbiB0aGUgY2FtcCB0aGF0IHdvdWxkIHByZWZlciBub3QgdG8g dXNlIGlkZW50aWZpZXJzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCBJUA0KYWRkcmVzc2luZyBh bmQgcm91dGluZyAtIGJ1dCBpdCBpcyBwb3NzaWJsZS4gIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRo ZW4gdGhleSBhcmUgZnJlZQ0KdG8gZG8gc28gYXMgZmFyIGFzIEkgY2FuIHRlbGwuDQoNCkl0IGlz IChwcm9iYWJseT8pIG11Y2ggbW9yZSBsaWtlbHkgdGhhdCBvcGVyYXRvcnMgdGhhdCB1c2UgY29u ZmlndXJhdGlvbiB3aWxsIHN0aWxsDQplbGVjdCB0byB1c2UgaWRlbnRpZmllcnMgdGhhdCBhcmUg Y29uc2lzdGVudCB3aXRoIElQIGFkZHJlc3NpbmcgYW5kIHJvdXRpbmcuICBUaGV5DQpjYW4gY2Vy dGFpbmx5IGRvIHRoYXQuDQoNCklmIHlvdSBrbm93IG9mIGEgc3BlY2lmaWMgcGxhY2UgaW4gdGhl IHRleHQgdGhhdCBwcmVjdWxkZXMgdGhpcywgcGxlYXNlIHBvaW50IGl0IG91dC4NCg0KRnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGRhdGEgcGxhbmUgYW4gaWRlbnRpZmllciBpcyBpbnNlcnRl ZCBhdCB0aGUgc291cmNlIGFuZCByZWNlaXZlZCBieSB0aGUgc2luay4gIE5laXRoZXIgdGhlIHNv dXJjZSBvciBzaW5rIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2VtYW50aWNzIG9mIHRoZSBpZGVu dGlmaWVyLCBhbGwgYSBzaW5rIG5lZWRzIHRvLCBmb3IgZXhhbXBsZSwgdG8gdmVyaWZ5IGNvbm5l Y3Rpdml0eSBpcyB0byBjaGVjayB0aGF0IHRoZSByZWNlaXZlZCBpZGVudGlmaWVyIHN0cmluZyBt YXRjaGVzIHRoZSBleHBlY3RlZCBpZGVudGlmaWVyIHN0cmluZy4NCkhlcmUgaXMgLSBpbiBwYXJ0 IGF0IGxlYXN0IC0gdGhlIGNydXggb2YgdGhlIG1pc3VuZGVyc3RhbmRpbmcuICBUaGUgR2xvYmFs IElkZW50aWZpZXINCmZvcm1hdCBkb2VzIG5vdCBpbmNsdWRlIHRoZSBub3Rpb24gb2YgYW4gaWRl bnRpZmllciBzdHJpbmcuICBIZW5jZSB0aGUgY29tcGFyaXNvbg0KeW91IGRlc2NyaWJlIGlzIGxl c3MgdGhhbiBhZGVxdWF0ZS4NCg0KUGxlYXNlIHNlZSBpbi1saW5lIGJlbG93Lg0KDQpSZWdhcmRz LA0KDQpNYWxjb2xtDQoNCg0KR2VvcmdlIFN3YWxsb3cgPHN3YWxsb3dAY2lzY28uY29tPg0KU2Vu dCBieTogbXBscy1ib3VuY2VzQGlldGYub3JnDQoyNS8wNC8yMDExIDA1OjE2IFBNDQpUbw0KPG1w bHNAaWV0Zi5vcmc+DQpjYw0KDQpTdWJqZWN0DQpbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFs LUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KDQoNCg0KDQoNCg0KDQpBbGwgLQ0KDQpNYW55 IG9mIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBJVFUgb24gZHJhZnQtaWV0Zi1tcGxz LXRwLWlkZW50aWZpZXJzLTA0IGhhdmUgdG8gZG8gd2l0aCB0aGUgR2xvYmFsIGFuZCBJQ0MgaWRl bnRpZmllcnMuDQoNClRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVH IGluY2x1ZGUgZmllbGRzIHRvIGlkZW50aWZ5IGVhY2ggZW5kIG9mIGFuIExTUC4gIEN1cnJlbnRs eSB0aGUgZHJhZnQgYWxsb3dzIGEgVHVubmVsLCBMU1AsIFBXLCBvciBNRUcgdG8gdXNlIGVpdGhl ciB0aGUgR2xvYmFsLUlEIGZvciBib3RoIGVuZHMgb3Igb3IgdGhlIElDQyBmb3IgYm90aCBlbmRz LiAgTWl4ZWQgdXNlIGlzIG5vdCBwZXJtaXR0ZWQuDQoNClRoZSBJVFUgbGlhaXNvbiByZXF1ZXN0 cyB0aGF0IHdlIGFsbG93IG1peGVkIHVzZS4NCg0KVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IGFy ZSB2ZXJ5IHJlbHVjdGFudCB0byBkbyB0aGlzLg0KDQoxLiAgICAgICAgT2J0YWluaW5nIGFuIEFT IE51bWJlciAoZnJvbSB3aGljaCB0aGUgR2xvYmFsLUlEIGlzIGRlcml2ZWQpIGlzIGEgZmFpcmx5 IHRyaXZpYWwgcHJvY2VkdXJlLiAgTWFueSBvcmdhbml6YXRpb25zIGlmIG5vdCBtb3N0IGFscmVh ZHkgaGF2ZSBBUyBOdW1iZXJzLg0KW01CXSBNYW55IG9yZ2FuaXphdGlvbnMgYWxyZWFkeSBoYXZl IHByb2Nlc3MgaW4gcGxhY2UgdG8gdXNlIElDQyBiYXNlZCBpZGVudGlmaWVycyBmb3IgdGhlIGRh dGEgcGxhbmUgY2hhbmdpbmcgdG8gSVAgYmFzZWQgaWRlbnRpZmllcnMgd291bGQgYmUgYSBtYWpv ciBidXJkZW4uDQoyLiAgICAgICAgU3VjaCBhbiBhZGRpdGlvbiB3aWxsIGFkZCBudW1lcm91cyBv YmplY3QgZm9ybWF0cywgYW5kIHRlc3QgY2FzZXMuDQpbTUJdICBXaHkgLSB0aGUgZGF0YSBwbGFu ZSBkb2VzIG5vdCBuZWVkIHRvIGludGVycHJldCB0aGUgc3RyaW5nLCBqdXN0IGNoZWNrIHRoYXQg aXQgbWF0Y2hlcyB0aGUgZXhwZWN0ZWQgc3RyaW5nDQozLiAgICAgICAgVGhlIGV4dGVudCBpbnRl ci1wcm92aWRlciBNUExTLVRQIGlzIGFzIHlldCB1bmtub3duLiAgSWYgbWl4ZWQgbW9kZXMgb2Yg SUNDIGFuZCBHbG9iYWwtSUQgaWRlbnRpZmljYXRpb24gaXMgcmVxdWlyZWQsIHRoZXkgY2FuIGJl IGFkZGVkIGxhdGVyLg0KW01CXSAgVGhpcyB3b3VsZCBiZSBhIG1ham9yIHJvYWRibG9jayB0byB0 aGUgdXNlIG9mIE1QTFMtVFAgaW4gYW4gaW50ZXIgcHJvdmlkZXIgdHJhbnNwb3J0IG5ldHdvcmsN CjQuICAgICAgICBGb3Igc2lnbmFsZWQgY29ubmVjdGlvbnMsIHRoZXJlIGlzIG5vIHBsYW4gdG8g YWxsb3cgcm91dGluZyBiYXNlZCBvbiBlaXRoZXIgdGhlIEdsb2JhbC1JRCBvciBJQ0MuICBUaGF0 IHdvdWxkIGJlIGEgcmFkaWNhbCBjaGFuZ2UgdG8gaG93IElQIHdvcmtzLiAgSG93ZXZlciBmb3Ig SVAgcm91dGluZyB0byB3b3JrIChpbiBvcmRlciB0byBmb3J3YXJkIHRoZSBzaWduYWxpbmcgbWVz c2FnZXMpLCB0aGUgcHJvdmlkZXJzIGludm9sdmVkIHdpbGwgbmVlZCB0byBydW4gQkdQIGFuZCBo YXZlIEFTIG51bWJlcnMuDQpbTUJdIFRoZSBjb250cm9sIHBsYW5lIGlkZW50aWZpZXJzIG11c3Qg YmUgaW5kZXBlbmRlbnQgb2YgdGhlIGRhdGEgcGxhbmUgaWRlbnRpZmllcnMuDQoNCldlIGFyZSBs b29raW5nIGZvciBpbnB1dC9jb25zZW5zdXMgZnJvbSB0aGUgV0cuDQoNCkdlb3JnZSwgRXJpYywg JiBNYXR0aGV3IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From agmalis@gmail.com Tue May 3 05:38: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 ECD4EE07C5 for ; Tue, 3 May 2011 05:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 c8AISZqElaGT for ; Tue, 3 May 2011 05:38:51 -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 D8378E06D8 for ; Tue, 3 May 2011 05:38:50 -0700 (PDT) Received: by qyk29 with SMTP id 29so1937935qyk.10 for ; Tue, 03 May 2011 05:38:50 -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:content-transfer-encoding; bh=a88baWttuvrrbDMfZuSKPAmeozMWCgTKxyk++pO49yM=; b=Ps7tb7SzNncAIztDOon3Tzc8j8E2WUMh748c1c3XgnJhlR+wrX1pONIW221xKEOKra rbsWJwoywCUsDyQ5CwJAJLmrmvv675nfJnQyBqvSfD+5Uds4dmzTc5WswVR9ateu8iS3 Yr9qdAyaY+yCIc/NaEVX346A6EytI4YioYzm8= 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:content-transfer-encoding; b=nEQRnFS/rekQmbuJMcnUVbFTjUjXt8aKo41B2TdwfeiIH4/TArn0mWF3QpYdFIdRCU CdvB/MH2f9r4B0ugtPPLrIy0TPp5TdO/4HsAEk/mLJuMXDUE7LpHuDQeQQoZBHiWvfzp 1Dm6X5r4VdAAlIg0ixZYl5D+BnvhTZZTjcDTM= Received: by 10.229.24.1 with SMTP id t1mr7003104qcb.225.1304426330131; Tue, 03 May 2011 05:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.248.137 with HTTP; Tue, 3 May 2011 05:38:29 -0700 (PDT) In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E44022F2FCFC@EMV62-UKRD.domain1.systemhost.net> References: <6D3D47CB84BDE349BC23BF1C94E316E44022F2FCFC@EMV62-UKRD.domain1.systemhost.net> From: "Andrew G. Malis" Date: Tue, 3 May 2011 08:38:29 -0400 Message-ID: To: neil.2.harrison@bt.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 03 May 2011 12:38:52 -0000 Neil, To your case 1, we're in complete agreement. We (VZ) don't see at least a short-term need for peer-layer interworking, given where we intend to deploy MPLS-TP in our infrastructure (as an internal server layer in the transport core). If peer layer interworking ever becomes a necessity, then obviously we'll need a well-defined E-NNI which would include LSP identifier mapping/translation at the boundary, for LSP provisioning (whether static or dynamic) and end-to-end OAM. Such an E-NNI definition does not yet exist for MPLS-TP (something else to put on the to-do list). This E-NNI would also include similar identifier mapping/translation for MS-PWs, to answer an earlier question from Erminio that I saw on the list. I also agree that both intra-layer and inter-layer mis-connectivity detection and amelioration are required, but I'm not convinced that the already defined mechanisms can't do that. Do you have some specific analysis on the inter-layer case? Cheers, Andy On Tue, May 3, 2011 at 3:36 AM, wrote: > Hi Andy, > > 2 points: > > 1 =A0 =A0 =A0 I agree with your view of only having a single addressing s= cheme in a single layer network solely belonging to one party. =A0Though yo= u may need to be rather careful if you also advocate that one can also have= peer layer interworking between different parties, ie E-NNIs (I believe th= is is something you may support, eg old MPLSF case?). =A0In such a peer int= erworking case it would seem one must allow different addressing schemes (a= nd indeed any other variations in DP/CP functional components) if they exis= t in the standards. > > Of course, having an E-NNI and peer interworking between different partie= s in any non-TOS layer network (not just MPLS) is not technically necessary= (this is trivial to prove), and this provides a strong argument for only h= aving a single addressing scheme in a non-TOS layer network. > > > 2 =A0 =A0 =A0 You should also be aware that in client/server interworking= of the co-ps mode using variable size traffic units, and therefore somethi= ng rather important for MPLS-TP in the role of a transport network (I'll ig= nore issues of transparency here), there could be inter-layer misconnectivi= ty (Aside=3D> This case cannot occur in the co-cs mode). =A0To date, howeve= r, we have only really considered intra-layer misconnectivity, ie between d= ifferent LSPs belonging to the same party (note this also includes all case= s of nested LSP sublayer misconnectivity). > > In the case of inter-layer misconnectivity one may receive traffic units = and OAM messages from some other party's layer network. =A0The OAM messages= may come from (i) networks using different OAM/addressing solutions or (ii= ) networks using the same OAM/addressing solutions. =A0In both cases there = are different issues wrt inter-layer misconnectivity one has to deal with. = =A0I'm not aware that these cases have been considered yet. > > > I'd like to hear your comments on both these points, but in particular th= e first one.....especially if you also support the notion of E-NNIs in MPLS= -TP, as there seems to a possible logical conflict here. > > Thanks. > > regards, Neil Harrison > > BT Design > > This email contains BT information, which may be privileged or confidenti= al. > It's meant only for the individual(s) or entity named above. If you're no= t the intended > recipient, note that disclosing, copying, distributing or using this info= rmation > 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. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Andrew G. Malis >> Sent: 02 May 2011 20:48 >> To: George Swallow >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> George et al, >> >> Verizon does not have any requirement for mixed use of Global IDs and >> ICCs. We are fine with specifications that require both ends of an LSP >> to use one or the other. >> >> Thanks, >> Andy >> >> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >> wrote: >> > 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. =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. >> > >> > Obtaining an AS Number (from which the Global-ID is derived) is a >> fairly >> > trivial procedure. =A0Many 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. =A0If 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. =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 >> > https://www.ietf.org/mailman/listinfo/mpls >> > >> > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From swallow@cisco.com Tue May 3 08:10: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 CEB3EE0841 for ; Tue, 3 May 2011 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.602 X-Spam-Level: X-Spam-Status: No, score=-108.602 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 3QnVQAD8Y+Us for ; Tue, 3 May 2011 08:10:09 -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 05714E06CF for ; Tue, 3 May 2011 08:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=7197; q=dns/txt; s=iport; t=1304435391; x=1305644991; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tdLvEqnaZM++KX3pYyaNqe972IjvfkGgXc55aGrU2/w=; b=a7t2RqjEUtjUr99j1kWYv5CHaeWa/+P8FRg0PidIresfljOUr1+bpkjj Q62P5lM9n6+B/CIa1IE4m24kJbnNaafwvycAM4pMHoZ/ZtSZQXgodgp0M c67w0cSfMjW9HobHubjG6n25mgWjB8K8dgKmvOsuhwPDymn0ptkc8ABoV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALkZwE2tJXG9/2dsb2JhbAClOGR3iHKfWJx6AoMDgn0EjxiEI4QDhig X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="440853139" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 03 May 2011 15:09:29 +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 p43F9SHY021530; Tue, 3 May 2011 15:09:28 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 10:09:28 -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 ; Tue, 3 May 2011 15:09:27 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 03 May 2011 11:09:25 -0400 From: George Swallow To: "Andrew G. Malis" , Message-ID: Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJpBbgzqKRfirmPUy1tS1lHxbiSg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 May 2011 15:09:28.0061 (UTC) FILETIME=[18B392D0:01CC09A4] 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, 03 May 2011 15:10:11 -0000 Andy - > Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. You are quite correct here! I think much of this debate surrounds a proble= m that is yet to be solved. So there are arguments for pieces of a solution without and overall architecture. Based on all that I am seeing my inclination is to NOT say that we disallow mixed identifiers, but to say that they are for future study. ...George On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > Neil, >=20 > To your case 1, we're in complete agreement. We (VZ) don't see at > least a short-term need for peer-layer interworking, given where we > intend to deploy MPLS-TP in our infrastructure (as an internal server > layer in the transport core). If peer layer interworking ever becomes > a necessity, then obviously we'll need a well-defined E-NNI which > would include LSP identifier mapping/translation at the boundary, for > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. >=20 > I also agree that both intra-layer and inter-layer mis-connectivity > detection and amelioration are required, but I'm not convinced that > the already defined mechanisms can't do that. Do you have some > specific analysis on the inter-layer case? >=20 > Cheers, > Andy >=20 > On Tue, May 3, 2011 at 3:36 AM, wrote: >> Hi Andy, >>=20 >> 2 points: >>=20 >> 1 =A0 =A0 =A0 I agree with your view of only having a single addressing scheme= in a >> single layer network solely belonging to one party. =A0Though you may need= to >> be rather careful if you also advocate that one can also have peer layer >> interworking between different parties, ie E-NNIs (I believe this is >> something you may support, eg old MPLSF case?). =A0In such a peer interwor= king >> case it would seem one must allow different addressing schemes (and inde= ed >> any other variations in DP/CP functional components) if they exist in th= e >> standards. >>=20 >> Of course, having an E-NNI and peer interworking between different parti= es in >> any non-TOS layer network (not just MPLS) is not technically necessary (= this >> is trivial to prove), and this provides a strong argument for only havin= g a >> single addressing scheme in a non-TOS layer network. >>=20 >>=20 >> 2 =A0 =A0 =A0 You should also be aware that in client/server interworking of t= he >> co-ps mode using variable size traffic units, and therefore something ra= ther >> important for MPLS-TP in the role of a transport network (I'll ignore is= sues >> of transparency here), there could be inter-layer misconnectivity (Aside= =3D> >> This case cannot occur in the co-cs mode). =A0To date, however, we have on= ly >> really considered intra-layer misconnectivity, ie between different LSPs >> belonging to the same party (note this also includes all cases of nested= LSP >> sublayer misconnectivity). >>=20 >> In the case of inter-layer misconnectivity one may receive traffic units= and >> OAM messages from some other party's layer network. =A0The OAM messages ma= y >> come from (i) networks using different OAM/addressing solutions or (ii) >> networks using the same OAM/addressing solutions. =A0In both cases there a= re >> different issues wrt inter-layer misconnectivity one has to deal with. =A0= I'm >> not aware that these cases have been considered yet. >>=20 >>=20 >> I'd like to hear your comments on both these points, but in particular t= he >> first one.....especially if you also support the notion of E-NNIs in MPL= S-TP, >> as there seems to a possible logical conflict here. >>=20 >> Thanks. >>=20 >> regards, Neil Harrison >>=20 >> BT Design >>=20 >> This email contains BT information, which may be privileged or confident= ial. >> It's meant only for the individual(s) or entity named above. If you're n= ot >> 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 kno= w >> immediately >> 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 >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Andrew G. Malis >>> Sent: 02 May 2011 20:48 >>> To: George Swallow >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>=20 >>> George et al, >>>=20 >>> Verizon does not have any requirement for mixed use of Global IDs and >>> ICCs. We are fine with specifications that require both ends of an LSP >>> to use one or the other. >>>=20 >>> Thanks, >>> Andy >>>=20 >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>> wrote: >>>> 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. =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. >>>>=20 >>>> The ITU liaison requests that we allow mixed use. >>>>=20 >>>> The authors of the draft are very reluctant to do this. >>>>=20 >>>> Obtaining an AS Number (from which the Global-ID is derived) is a >>> fairly >>>> trivial procedure. =A0Many 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. =A0If 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. =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. >>>>=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 >>>>=20 >>>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 From swallow@cisco.com Tue May 3 08:14:06 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 CA735E06CF for ; Tue, 3 May 2011 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.902 X-Spam-Level: X-Spam-Status: No, score=-108.902 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 IpVrlMC9pWjw for ; Tue, 3 May 2011 08:14:04 -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 8F08CE06B5 for ; Tue, 3 May 2011 08:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=13184; q=dns/txt; s=iport; t=1304435644; x=1305645244; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=IMuANWWQGycRVj40g6bsJQakVDFs1tG4kY8rcAwO5OU=; b=VaCl7oD+QMDb6W/wH1jbWvuzdywkFZC+Vd9WQ2IaFoNFcsob+WSVcdd7 /WVlPFcOF5BIyUaL5aY48oXGzRCUWjJ5NKPDKE/333UQWUqQsQuToaEli XaThQX8wOjSK/hiWKF4NZjwcMneiDO/Y010uWZjqrQwcAwQDYrARH5bsB w=; X-Files: image.jpg : 2067 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAOEawE2tJXG+/2dsb2JhbACCYpUmjTBkd4hyn0qceoMfgmMEjxiEI4or X-IronPort-AV: E=Sophos;i="4.64,309,1301875200"; d="jpg'145?scan'145,208,217,145";a="440857396" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 03 May 2011 15:14:03 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p43FE3Eq020726; Tue, 3 May 2011 15:14:03 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); Tue, 3 May 2011 10:14:02 -0500 Received: from 10.86.246.177 ([10.86.246.177]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2011 15:14:02 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 03 May 2011 11:14:01 -0400 From: George Swallow To: Ehud Doron , "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , Message-ID: Thread-Topic: [mpls] Clarification on TP-Identifiers for MIP Thread-Index: AcwIqdBmtFposC4rRnywAJLUf1h0EwAAvwRwAD37u2U= In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306B4DCDB@tlvmail1> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3387266041_42244690" X-OriginalArrivalTime: 03 May 2011 15:14:02.0842 (UTC) FILETIME=[BC7BD3A0:01CC09A4] Cc: Rafi Ram , draft-ietf-mpls-tp-identifiers@tools.ietf.org Subject: Re: [mpls] Clarification on TP-Identifiers for MIP 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, 03 May 2011 15:14:06 -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_3387266041_42244690 Content-type: multipart/alternative; boundary="B_3387266041_42262321" --B_3387266041_42262321 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ehud - In an IP/MPLS environment, provisioning MIPs is pretty much a non-starter. Generally intermediate nodes respond to all requests (e.g. Ping, MPLS Ping) unless configured to filter on things such a source address. So I actually did intended that the MIP-ID to be node:IF_num, with a IF_Num of zero meaning a MIP not associated with a particular interface. That said, the MEG can be inferred from the label of the received reply. This is what happens in e.g. Y.1731 (I refer to Ethernet here), and fault oam. In cases where more verification is desired, the MEG-ID is carried in the contents of the reply. This is what happens in LSP Ping. ...George On 5/2/11 5:53 AM, "Ehud Doron" wrote: > Hi, > =20 > I am strongly support Yaacov approach. > Because a MIP is provisioned in the context of a MEG (LSP, PW), it identi= fiers > are expected to be in the context of this MEG , i.e. MEG_ID::Node_ID::IF= _Num. > Nevertheless , the MIP identifier as defined in draft-ietf-mpls-tp-identi= fiers > draft is Node_ID::IF_Num (for per IF MIP approach). > =20 > Best wishes,=20 > =20 > Ehud Doron > System Architect=20 > Orckit - Corrigent > ehudd@orckit.com > Tel: 972-3-69456327 > www.orckit.com > =20 > > Pushing technology to the edge > =20 > =20 > =20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Weingarten, Yaacov (NSN - IL/Hod HaSharon) > Sent: Monday, May 02, 2011 12:18 PM > To: mpls@ietf.org > Cc: draft-ietf-mpls-tp-identifiers@tools.ietf.org > Subject: [mpls] Clarification on TP-Identifiers for MIP > =20 > Hi, >=20 > In reviewing in MPLS-TP Identifiers document it is unclear on the format = that > is suggested for MIP identification. Just for my clarification =AD is the > intention that the MIP identifier is the same as a MEP identifier except = that > in-place of the "MEP_Index" we substitute "Node_ID::IF_Num". In other wo= rds, > if we are using ICC-based identifiers the MIP identifier would be: >=20 > MEG_ID::Node_ID::IF_Num and if using IP global identification it would be > LSP_ID::Node_ID::IF_Num. >=20 > Is this correct? >=20 > Best regards, >=20 > Yaacov Weingarten >=20 > Nokia Siemens Networks >=20 > Industry Environment, PTE >=20 > ph#: +972-9-775 1827 >=20 > mob#: +972-54-220 0977 >=20 --B_3387266041_42262321 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] Clarification on TP-Identifiers for MIP Ehud -

In an IP/MPLS environment, provisioning MIPs is pretty much a non-starter. =  Generally intermediate nodes respond to all requests (e.g. Ping, MPLS = Ping) unless configured to filter on things such a source address.  So = I actually did intended that the MIP-ID to be node:IF_num, with a IF_Num of = zero meaning a MIP not associated with a particular interface.

That said, the MEG can be inferred from the label of the received reply. &n= bsp;This is what happens in e.g. Y.1731 (I refer to Ethernet here), and faul= t oam.  In cases where more verification is desired, the MEG-ID is carr= ied in the contents of the reply.  This is what happens in LSP Ping.
...George


On 5/2/11 5:53 AM, "Ehud Doron" <eh= udd@orckit.com> wrote:

<= FONT COLOR=3D"#1F497D">Hi,
 
I am strongly support Yaacov approach.
Because a MIP is provisioned in the context of a MEG (LSP, PW), it identifi= ers are expected to be in the context of this MEG , i.e.  MEG_ID::Node_= ID::IF_Num.
Nevertheless , the MIP identifier as defined in draft-ietf-mpls-tp-identifi= ers draft is Node_ID::IF_Num (for per IF MIP approach).
 
Best wishes,
 
e= hudd@orckit.com <mailto:username= @orckit.com>   
Tel: 972-3-69456327
www.orckit.com <http://www.= orckit.com/>

= &l= t;http://www.orckit.com/>
Pushing technology to the ed= ge
 
 

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.o= rg] On Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, May 02, 2011 12:18 PM
To: mpls@ietf.org
Cc: draft-ie= tf-mpls-tp-identifiers@tools.ietf.org
Subject: [mpls] Clarification on TP-Identifiers for MIP
Hi,
In reviewing in MPLS-TP Identifiers document it i= s unclear on the format that is suggested for MIP identification.  Just= for my clarification – is the intention that the MIP identifier i= s the same as a MEP identifier except that in-place of the "MEP_Ind= ex" we substitute "Node_ID::IF_Num".  In other words, if= we are using ICC-based identifiers the MIP identifier would be:

MEG_ID::Node_ID::IF_Num and if using IP globa= l identification it would be LSP_ID::Node_ID::IF_Num.

Is this correct?

Best regards,

Yaacov Weingarten

Nokia Siemens Networks

Industry Environmen= t, PTE

ph#:  +972-9-7= 75 1827

mob#: +972-54-220 0= 977

--B_3387266041_42262321-- --B_3387266041_42244690 Content-Type: image/jpeg; name="image.jpg" Content-ID: <3387266041_42232263> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR CAAzAG0DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiisvWtZj0mFeN88nEcY5J/Cmk27Imc1 CPNLYyde8a2+n3UllagyTx8OQM4PoK5xvHOpJIC6FQegZiM/piulTw9qOov9qvrwWjvyUt0X cPq3rWPqR02ykNuPFti8nQwXroyn2OOldUZUoqzVzzKtPFVG5Rk0um3+ZqaJ40hv3ENwpST0 PX6j1/nXVKwZQykEEZBHevMtf8Orp1rDrOlzRyWxwZPIfcsbeqn+7muq8O6/aDTljv7y2tpV xhJZlU4IzjBP+cipqwhy88DXDVaym6Vbfv3OloqOKaKeMSQypIh6MjAg/iKZd3tpYQma8uYr eMfxyuFH5muY9AnorLsvE2hajP5Fnq9nPKeiJMpJ+g71Zi1XT576SwivYHuo8l4FkBdceo69 6ALdFUn1jTIr9dPe/t1u2xiAyDec/wCz1oj1jTJbma2jv7d5rcFpo1kBaMDqSO2KALtFZH/C WeHf+g5p/wD4EL/jV6y1Cz1KEzWN1DcxBtpeJwwB9MigCxXCNd/bfiWsc5/dwNtjU9Mhcj9T Xd15l4ugn0jxX9ujyomIljb/AGh1H6V0YdJya7o8/MG401Pomm/QufFbWb62g07RLCY27anI VklBwduQMZ7AlufpWnp/wv8ACtnYLbzact3Jt+eeZjuY9yMHj8Kq63p2n/Ebw/CkdytrqFud 8TH+Bu4Psf8ACqdvqvxM0qBbGbQLbUnQbUuhKBuHYnkZ/SsJRcXZndCcZxUovQwrixPgjxwN AtJ3l0jV4sNbu27ZuyAfqCOvpUHhmPw4fF+tHxGtkYQkflm7AxuwM4z3xV240XU7K8l8Q+KL mOXWbhTHaWkJyIcjG449AeAO5rV0HwFcS6lrZ1yzjNhqMKLFhwXBGOcfwkVTi1C5mqkXVcVu lqVPCaQQ/Eac+FEn/wCEfMB+04DeRvxxsz74/XtVLw1p4+JnifUdT16V5bSyYLDZhyFAJOB9 MDn1Jrr/AApba/4bMmk6zJBPpcRxZ3zTKrheysp/z+FY994M1/w9r82ueDJoXjuSWmspjhTk 5IHYjPTkEVBsdOvgLwvHcW9xBpEEE1tIskUkWVIIOR9fxryvVvENz4Z+I3iC/s4RJO4eJGIy IydvzH1xj8672z1n4hX13BDL4ds7CHzF8+d5t2Fz820Z64+tUrHwZfTfELW73U7BW0m/ikjD F1O/O3HGcjofyoA0fh94Ys7KwXXpbpdR1LUF8yS7J3YB6qp/nXP+D4o5viz4mikQMjrMrKe4 LrkVq+DtD8R+ENcuNLMJvNBlctFP5i7oj67c59iPXmneF/DWrad8Rta1e6tRHZXXmeTJ5ind lwRwDkcCgDmPiF4e0fS/FXh+1sdOgt4bhwJURcBxvUc/ga9Y0zSdP0a2NtptpFawsxcpGMAn 1/SuN8eeGtX1rxPod7p9qJYLRwZm8xV2/Op6E88Cu+oAKoaxo9prdi1rdLkdVcdUPqKv1SuJ btWIRPl7EU07aoTSaszzu78I6/pFwXtFa5QfdkhOGx7iprdvGsuIY47tAeMuAoH4mu1M913L flSefdf3mro+sya1SZ5/9nU07wk15JmboPhF7W6Go6vN9qvOqgnKofXnqa6isxJ7zPAJ+oq/ A0jJmVQDWM5ubuzspUYUo8sEUruMx6iLqS0a6i8rYoQBjGckng+vHPtUd/8AbhIn2VZkXyx5 SxhdofPR8/w4x09/ataioNSi0d4bi7k8x9ojAgQY2528n1zn1pIYrqMWQd3lIBMzvjOSvt7+ lX6KAMDTru7nu5IkmleZbdzIsm0xrLkAYxzjr+HvUtuNVbT7gNJKJyFCFkGVb+LB6EfpWwFV SSFAzycDrTqAMiWC82Qh3uHEN5kMpG5o9pAz6jJrXoooAKKKKAEwPSjA9KKKAFooooAKKKKA CiiigAooooAKKKKAP//Z --B_3387266041_42244690-- From neil.2.harrison@bt.com Tue May 3 08:27: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 6CBAEE07B3 for ; Tue, 3 May 2011 08:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=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 hTDgNJ6ibU29 for ; Tue, 3 May 2011 08:27:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C7E0735 for ; Tue, 3 May 2011 08:27:16 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 3 May 2011 16:26:56 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.191]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 3 May 2011 16:27:15 +0100 From: To: Date: Tue, 3 May 2011 16:27:10 +0100 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJjxU7VNCj7nAhTy262wDZCNtOHQAAWkvw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44022F3037F@EMV62-UKRD.domain1.systemhost.net> References: <6D3D47CB84BDE349BC23BF1C94E316E44022F2FCFC@EMV62-UKRD.domain1.systemhost.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Tue, 03 May 2011 15:27:18 -0000 Thanks Andy. Glad to hear you don't see any need for an E-NNI in MPLS-TP -= at least right now. However, I'm not sure an MPLS-TP E-NNI should go on t= he 'to do' list at any time in the future either. If ones does venture int= o E-NNIs one must consider the DP adaptation functions that interface with = the external message/file/stream applications (and that are always present = in a true TOS layer network in all networking cases) as these essentially d= efine the service. Defining any E-NNIs without this perspective is rather = naive IMO (though it does not seem to stop folks pushing this, and in some = cases even suggesting peer interworking between different non-TOS network t= echnologies/modes!). The problem with non-TOS layer networks is that they = don't have generic external message/file/stream adaptation functions so one= can end up with a whole raft of specific-case E-NNIs for every interworkin= g 'service' scenario. I also saw the mails from Erminio where he had spotted that the same issues= apply to MS PWs. Well, I think most folks know my views on these...but ha= ving E-NNIs in an artificial/unnecessary PW layer network is a wonderful co= ncept...I mean, just how bad can we make this stuff if we really try? Wrt inter-layer misconnectivity. I have not done any deep analysis. Howev= er, I can see a new situation arising here that had not existed in any prev= ious co-ps mode technology. Like MS PWs, MPLS-TP should not have tradition= al sublayering of LSPs...this is an unnecessary behaviour in a transport n= etwork ....and the deeper arch reason harks back to what transparency reall= y means and why this is a very important property of a transport network. The reason I mention this is that in a set of nested LSPs we can have both = layering (of same or different party MPLS-TP layer networks) and sublayerin= g (of the same/single party MPLS-TP layer network) mixed-up, and AFAIK it i= s not obvious which is which in the DP (though I am aware of at least one v= endor who seems may have a solution to this).....and we thus need to be abl= e to detect both intra and inter layer misconnectivity across all these cas= es. The use of different addressing schemes (noting that OAM CV messages s= hould contain proper SA information, and not some arbitrary IDs, eg to just= ify the use of TCM sublayering say, which is a bad OAM idea anyway) creates= an obvious need to be able to recognise/handle different OAM cases in a la= yer network due to inter-layer misconnectivity even with no peer interworki= ng. However, one might also have the use of identical addressing in a clie= nt and server layer network (since these are non-TOS and have no need to pe= er interwork). So now one can have inter layer misconnectivity that might = look like it's intra layer misconnectivity from inspection of CV OAM messag= es.....or put another way one needs to be able to identify instances of int= er-layering misconnectivity of different layer networks belonging to the sa= me party as well as instances inter-layer misconnectivity of different laye= r networks belonging to different parties. Hope that makes sense. regards, Neil 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 =20 > -----Original Message----- > From: Andrew G. Malis [mailto:agmalis@gmail.com] > Sent: 03 May 2011 13:38 > To: Harrison,N,Neil,DKQ7 R > Cc: mpls@ietf.org; swallow@cisco.com > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Neil, >=20 > To your case 1, we're in complete agreement. We (VZ) don't see at > least a short-term need for peer-layer interworking, given where we > intend to deploy MPLS-TP in our infrastructure (as an internal server > layer in the transport core). If peer layer interworking ever becomes > a necessity, then obviously we'll need a well-defined E-NNI which > would include LSP identifier mapping/translation at the boundary, for > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. >=20 > I also agree that both intra-layer and inter-layer mis-connectivity > detection and amelioration are required, but I'm not convinced that > the already defined mechanisms can't do that. Do you have some > specific analysis on the inter-layer case? >=20 > Cheers, > Andy >=20 > On Tue, May 3, 2011 at 3:36 AM, wrote: > > Hi Andy, > > > > 2 points: > > > > 1 =A0 =A0 =A0 I agree with your view of only having a single addressing > scheme in a single layer network solely belonging to one party. =A0Though > you may need to be rather careful if you also advocate that one can > also have peer layer interworking between different parties, ie E-NNIs > (I believe this is something you may support, eg old MPLSF case?). =A0In > such a peer interworking case it would seem one must allow different > addressing schemes (and indeed any other variations in DP/CP functional > components) if they exist in the standards. > > > > Of course, having an E-NNI and peer interworking between different > parties in any non-TOS layer network (not just MPLS) is not technically > necessary (this is trivial to prove), and this provides a strong > argument for only having a single addressing scheme in a non-TOS layer > network. > > > > > > 2 =A0 =A0 =A0 You should also be aware that in client/server interworki= ng > of the co-ps mode using variable size traffic units, and therefore > something rather important for MPLS-TP in the role of a transport > network (I'll ignore issues of transparency here), there could be > inter-layer misconnectivity (Aside=3D> This case cannot occur in the co- > cs mode). =A0To date, however, we have only really considered intra-layer > misconnectivity, ie between different LSPs belonging to the same party > (note this also includes all cases of nested LSP sublayer > misconnectivity). > > > > In the case of inter-layer misconnectivity one may receive traffic > units and OAM messages from some other party's layer network. =A0The OAM > messages may come from (i) networks using different OAM/addressing > solutions or (ii) networks using the same OAM/addressing solutions. =A0In > both cases there are different issues wrt inter-layer misconnectivity > one has to deal with. =A0I'm not aware that these cases have been > considered yet. > > > > > > I'd like to hear your comments on both these points, but in > particular the first one.....especially if you also support the notion > of E-NNIs in MPLS-TP, as there seems to a possible logical conflict > here. > > > > Thanks. > > > > regards, 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. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> Andrew G. Malis > >> Sent: 02 May 2011 20:48 > >> To: George Swallow > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > >> > >> George et al, > >> > >> Verizon does not have any requirement for mixed use of Global IDs > and > >> ICCs. We are fine with specifications that require both ends of an > LSP > >> to use one or the other. > >> > >> Thanks, > >> Andy > >> > >> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> wrote: > >> > 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. =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. > >> > > >> > Obtaining an AS Number (from which the Global-ID is derived) is a > >> fairly > >> > trivial procedure. =A0Many 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. =A0If 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. =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 > >> > https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > From yaakov_s@rad.com Tue May 3 10:26: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 47C11E0752 for ; Tue, 3 May 2011 10:26:02 -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 9vUlrADEWh7y for ; Tue, 3 May 2011 10:26:01 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by ietfa.amsl.com (Postfix) with ESMTP id 60542E0827 for ; Tue, 3 May 2011 10:25:58 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 03 May 2011 20:25: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; Tue, 3 May 2011 20:25: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; Tue, 3 May 2011 20:25:51 +0300 From: Yaakov Stein To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AQHMB1+gV7EkCMrxKE6CdkGCGMp+HpR7X00Q Date: Tue, 3 May 2011 17:25:48 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E46F1A@EXRAD5.ad.rad.co.il> References: <4DBC4D2C.9090901@pi.nu> In-Reply-To: <4DBC4D2C.9090901@pi.nu> 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 Cc: Ross Callon , "draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org" Subject: Re: [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: Tue, 03 May 2011 17:26:02 -0000 support wholeheartedly ! Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Saturday, April 30, 2011 20:56 To: mpls@ietf.org Cc: Ross Callon; draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 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 --=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 loa@pi.nu Tue May 3 10:47: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 018CCE0700 for ; Tue, 3 May 2011 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, 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 n3+7SR8Lzvyc for ; Tue, 3 May 2011 10:47:48 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id DE900E06B1 for ; Tue, 3 May 2011 10:47:47 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id D7C462A8001; Tue, 3 May 2011 19:47:45 +0200 (CEST) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Tue, 3 May 2011 19:47:46 +0200 Message-ID: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Date: Tue, 3 May 2011 19:47:46 +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, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-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, 03 May 2011 17:47:52 -0000 Working Group, this is to start a two week poll on making draft-vkst-mpls-tp-te-mib-00.txt 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 2011-05-18. /Loa From scott.mansfield@ericsson.com Tue May 3 13:20:19 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 C6499E0717 for ; Tue, 3 May 2011 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 Mcnj9wFhKzuc for ; Tue, 3 May 2011 13:20:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 42917E067E for ; Tue, 3 May 2011 13:20:19 -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 p43KKHtn006842; Tue, 3 May 2011 15:20:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 3 May 2011 16:20:11 -0400 From: Scott Mansfield To: "loa@pi.nu" , "mpls@ietf.org" Date: Tue, 3 May 2011 16:19:25 -0400 Thread-Topic: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt Thread-Index: AcwJukLt90bH9lk3Rbi1SQ57qdclBgAFR0Bg Message-ID: References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> In-Reply-To: <833768e1a607dbafe4f3463989757b1a.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" , "draft-vkst-mpls-tp-te-mib@tools.ietf.org" Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-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, 03 May 2011 20:20:19 -0000 Yes/support=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of loa@pi.nu > Sent: Tuesday, May 03, 2011 1:48 PM > To: mpls@ietf.org > Cc: rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org > Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-vkst-mpls-tp-te-mib-00.txt >=20 > an mpls working group document. >=20 > If you support the document becoming a working group document=20 > please respond to this poll with "yes/support" >=20 > If you do not support the document becoming a working group=20 > document please respond to this poll with "no/do not support" > and at the same time give the technical reasons why you are=20 > not supporting the document. >=20 > If you have technical comments or in any other way want to=20 > discuss the document, please send these comments to the mpls=20 > working group mailing list, but with another subject than=20 > what is on this mail. >=20 > The poll ends 2011-05-18. >=20 > /Loa >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From sriganeshkini@gmail.com Tue May 3 13:53: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 7C0CCE0869 for ; Tue, 3 May 2011 13:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.333, 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 OKkMU-+v6on4 for ; Tue, 3 May 2011 13:53:50 -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 D10A4E0831 for ; Tue, 3 May 2011 13:53:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so384266qwc.31 for ; Tue, 03 May 2011 13:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ttZWs9r0WAn3IY1/3qt94BGBwfxeNRkhuwAS8e0h5D0=; b=pXK0x8hcu+bZsExfQ+F+0YKPK3w98x7JHoi5PajbyG1PCMlAwC4Y2uTjRbG05u/DMo 9V6D3EpJvLX6NwL5ktPQK04uV0bx4chqtpkTsqrfL7kXdUNPjBuQncQ9WuWsTVK1efic IV+m9Jh2FBMWa6w8GAhGoK5Zlds8QF6AH6kQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=FLFNJIrKb+tpPtXtelZpB0V0RU62OnKBFKJrkgCAfxKHp9vS3Ssf/i8auPrnEMBepF +tKtso/ABvx48A/kPmE2MmgI3UlT+ZROKCcQ6cTfceeLlMAaHD5SD/oGdFqVK3JeIicO J4vcb3m/NRD8z16X2B4DWV/qH3WcUu3KaaxnA= Received: by 10.229.68.150 with SMTP id v22mr94136qci.172.1304456029228; Tue, 03 May 2011 13:53:49 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.75.13 with HTTP; Tue, 3 May 2011 13:53:19 -0700 (PDT) In-Reply-To: References: <5E893DB832F57341992548CDBB333163A0978A0555@EMBX01-HQ.jnpr.net> From: Sriganesh Kini Date: Tue, 3 May 2011 13:53:19 -0700 X-Google-Sender-Auth: mg3cdgw4PB0rXz6aWv9YQtykX9Y Message-ID: To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ross Callon , "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: Tue, 03 May 2011 20:53:50 -0000 Another comment on the draft - When LDP is used for tunnel LSPs there could be multiple egress LSRs (for a LSP to a FEC). These may have different EL processing capabilities and different ELI values. Section 5.1 should address how such cases are handled. On Mon, May 2, 2011 at 5:50 PM, Sriganesh Kini wrote: > inline > > On Thu, Apr 28, 2011 at 3:38 PM, John E Drake wrote: >> >> >> 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 >>> >>> Hi Kireeti and other authors, >>> >>> Need a couple clarification >>> 1. This draft seems to apply to the TE LSP (or transport LSP) =A0for th= e >>> 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: =A0You mean figure 7|8 in section 3.4.5? =A0But yes, entropy labels = apply to 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: =A0It's always bottom of stack, so if it is present, it was placed t= here by the client. > > Ok. Since the EL has to be placed by the client, but cannot be placed > by the ingress LSR of the Transport LSP (when the packet received from > the CE is MPLS), it may be useful to state this explicitly in section > 3 para that starts with "EL labels are generated by the ingress LSR > <> ..." > > >> >>> >>> 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 >>> _______________________________________________ >>> 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 >> > > > > -- > - Sri > --=20 - Sri From sriganeshkini@gmail.com Tue May 3 14:08: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 E95C0E0830 for ; Tue, 3 May 2011 14:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.308, 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 PdckqsPyxJ2Q for ; Tue, 3 May 2011 14:08:00 -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 3F053E06BB for ; Tue, 3 May 2011 14:08:00 -0700 (PDT) Received: by qyk29 with SMTP id 29so2293073qyk.10 for ; Tue, 03 May 2011 14:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=beZriCa+t4eIX/DtNmDcivTo9FKmGCBp5IDtbvX2Qug=; b=rJhsTJmJFK2y0ezzt9kpe8DaUgX2xZo7b94pVdWIG1QY1susY4n7JTuTY3Gqger3ns /z7Bvb1eJBHCSvGKyZh5akmEJNri3gGx5BO/ONoB7YjKIJZaip6hzgribrPkHU4xOzEv 1fCATIYtFzIvHIok4ec3hih5So1hVb2m3i0ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=hEstRy1t5Iv4qc9k58kwCJ8mebtMIX8u+Q0cWWOMfm6X06nQb4j5WLrFhkjBFooEpJ zenKghQ3MBKrsssaeAtCZjN0MMnjGoLsrhOYSbgZ7ZYj2WH3gab6nEwEN+LrTmKRd8we VQuKmvknxQp6QtfM/xPRMvT9KT4BCubg3zoxo= Received: by 10.229.61.7 with SMTP id r7mr109413qch.20.1304456879132; Tue, 03 May 2011 14:07:59 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.75.13 with HTTP; Tue, 3 May 2011 14:07:29 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Tue, 3 May 2011 14:07:29 -0700 X-Google-Sender-Auth: _wG7Hlr0JygET5cUDv6OUhtZE3Q Message-ID: 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: Tue, 03 May 2011 21:08:01 -0000 Support. 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 david.i.allan@ericsson.com Tue May 3 15:01: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 0C211E072A for ; Tue, 3 May 2011 15:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.178 X-Spam-Level: X-Spam-Status: No, score=-4.178 tagged_above=-999 required=5 tests=[AWL=2.421, 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 MIh7qAQravHF for ; Tue, 3 May 2011 15:01:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD3E06A1 for ; Tue, 3 May 2011 15:01:06 -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 p43M14Of024422; Tue, 3 May 2011 17:01:06 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 3 May 2011 18:01:03 -0400 From: David Allan I To: "erminio.ottone_69@libero.it" , "mpls@ietf.org" Date: Tue, 3 May 2011 18:01:01 -0400 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwJE4MjlaRZg1reSDSGAJiRuo7fpQAySMNg Message-ID: <60C093A41B5E45409A19D42CF7786DFD521B0E5409@EUSAACMS0703.eamcs.ericsson.se> References: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> In-Reply-To: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> 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] I: 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: Tue, 03 May 2011 22:01:08 -0000 Hi Ermino: I stand corrected. I got lots of private feedback to the effect that curren= t implementations see a "final" response as agreement to the parameters in = a poll. Hence changing that semantic is not a good idea. The alternative discussed was what an implementation does when a poll is no= t responded to in a resonable amount of time, which can be interpreted as a= refusal to change by the far end, or non-implementation of P/F in steady s= tate. At which point an implemention's options are to live with the status = quo or take the session down. Feedback welcome! Dave -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Monday, May 02, 2011 2:54 PM To: mpls@ietf.org Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Forwarding the messate to the MPLS WG mailing list ... >----Messaggio originale---- >Da: erminio.ottone_69@libero.it >Data: 2-mag-2011 23.19 >A: >Ogg: R: [mpls] FW: Poll / Final in 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=20 >>once a session is up a compliant implementation does not actually have=20 >>to implement on the fly changes to session paramters. The processing=20 >>of the poll bit can simply be reduced to setting the final bit in the=20 >>next message. >>This would permit implementations to optimize the UP processing loop. > >How this is possible? > >Section 6.8.7 of RFC 5880 states that: > > With the exceptions listed in the remainder of this section, a system > MUST NOT transmit BFD Control packets at an interval less than the > larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less > applied jitter (see below). =20 > >If the Poll requires a longer bfd.RemoteMinRxInterval, how can the=20 >system ignore the request? > >>----Messaggio originale---- >>Da: david.i.allan@ericsson.com >>Data: 20-apr-2011 17.29 >>A: "mpls@ietf.org" >>Cc: "Ross Callon" >>Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >> >>Hi Folks: >>=20 >>We've received a number of comments both formally and informally that=20 >>the current draft has deviated too far from the base BFD spec and thus=20 >>loses backward compatibility with existing code bases. Further,=20 >>discussions with the BFD WG have indicated we have a potential race=20 >>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=20 >>peer MEP prior to changing the detection time to the rx-interval x=20 >>detect mult in >>order to avoid potential flapping. This can result in an=20 >>implementation effectively needing two UP states (UP forward, UP reverse = direction). >>Otherwise the MEP may time out the reverse direction before seeing an=20 >>UP state from the peer MEP. >>=20 >>So we can make this implicit in the specification and require BFD=20 >>changes or >>we can use poll/final discipline on startup as defined in the base=20 >>specification and make the transition to fully UP and the desired rate=20 >>both explicit and exposed in the protocol exchange. This would reduce=20 >>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 respond >>to a poll with a final reply with the session parameters unchanged. So=20 >>once a session is up a compliant implementation does not actually have=20 >>to implement on the fly changes to session paramters. The processing=20 >>of the poll bit can simply be reduced to setting the final bit in the=20 >>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, hence >>we'd look to the WG for comment on this change... >>=20 >>the editors >>Dave, John and George... >> >> >>_______________________________________________ >>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 jdrake@juniper.net Tue May 3 17:39: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 83735E0651; Tue, 3 May 2011 17:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 AH++6aYGIe2F; Tue, 3 May 2011 17:39:51 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 314C9E0618; Tue, 3 May 2011 17:39:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcCgUgOTvsMijkaEwTCu0A9jBMVj3o9W@postini.com; Tue, 03 May 2011 17:39:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 May 2011 17:39:15 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "Malcolm.BETTS@zte.com.cn" Date: Tue, 3 May 2011 17:39:13 -0700 Thread-Topic: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJFN68AAc0d8UPSzC3u0uGu0CrqQA3qGqQ Message-ID: <5E893DB832F57341992548CDBB333163A097C19888@EMBX01-HQ.jnpr.net> References: <27854167.1225641304373849966.JavaMail.defaultUser@defaultHost> In-Reply-To: <27854167.1225641304373849966.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 04 May 2011 00:39:52 -0000 QXMgSSBzYWlkIHRvIE1hbGNvbG0sIGlmIGl0IGlzIG5vdCBpbiB0aGUgTVBMUy1UUCBSZXF1aXJl bWVudHMgUkZDcywgaXQgaXMsIGJ5IGRlZmluaXRpb24sIGEgbGF0ZSBicmVha2luZyByZXF1aXJl bWVudC4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogZXJtaW5pby5vdHRvbmVfNjlAbGliZXJvLml0IFttYWlsdG86ZXJtaW5p by5vdHRvbmVfNjlAbGliZXJvLml0XQ0KPiBTZW50OiBNb25kYXksIE1heSAwMiwgMjAxMSAzOjA0 IFBNDQo+IFRvOiBKb2huIEUgRHJha2U7IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbg0KPiBDYzog bXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnDQo+IFN1YmplY3Q6IFI6IFJlOiBb bXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+IElkZW50aWZpZXJz Pw0KPiANCj4gQXJlIHlvdSBzdXJlIGl0IGlzIGEgbGF0ZSBicmVha2luZyByZXF1aXJlbWVudD8N Cj4gDQo+IEkgd2FzIGFibGUgdG8gdHJhY2sgYmFjayB0aGlzIHJlcXVpcmVtZW50IGJhY2sgaW4g dGhlIGZvbGxvd2luZyBJVFUtVA0KPiBMUyBvbiAxMg0KPiBBcHJpbCAyMDEwIChpLmUuLCBtb3Jl IHRoYW4gb25lIHllYXIgYWdvKToNCj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bGlhaXNvbi84NjgvDQo+IA0KPiBJbiBwYXJ0aWN1bGFyIHNlZSB0aGUgY29tbWVudCBtMTQ6DQo+ IA0KPiAgICAgICAgICAgICAgIENvbW1lbnQgW00xNF06IEhvdyBpcyB0aGUgY2FzZSBvZiBhIFBX LCBMU1Agb3IgdHVubmVsDQo+IHRoYXQNCj4gdHJhbnNpdHMgdHdvIGRvbWFpbnMsIHdoZXJlIG9u ZSB1c2VzIElDQyBmb3JtYXQgYW5kIHRoZSBvdGhlciB1c2VzIElQDQo+IGZvcm1hdA0KPiBhZGRy ZXNzZWQuDQo+IA0KPiAtLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj4gRGE6IGpkcmFrZUBq dW5pcGVyLm5ldA0KPiBEYXRhOiAyOC1hcHItMjAxMSAxLjI1DQo+IEE6ICJNYWxjb2xtLkJFVFRT QHp0ZS5jb20uY24iPE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj4NCj4gQ2M6ICJtcGxzQGlldGYu b3JnIjxtcGxzQGlldGYub3JnPiwgIm1wbHMtYm91bmNlc0BpZXRmLm9yZyI8bXBscy0NCj4gYm91 bmNlc0BpZXRmLg0KPiBvcmc+DQo+IE9nZzogUmU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9i YWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiBNYWxjb2xtLA0KPiANCj4gSSBp bnRlcnByZXRlZCBFcmlj4oCZcyB1c2Ugb2YgIOKAmHN0aXRjaGluZ+KAmSAgdG8gYmUgaW4gdGhl IFJGQyA1MTUwIHNlbnNlLg0KPiBJDQo+IHRoaW5rIEkgd2lsbCBsZXQgaGltIGNsYXJpZnksIGJ1 dCBpZiB1c2VkIGluIHRoZSBSRkMgNTE1MCBzZW5zZSwgYQ0KPiDigJhzdGl0Y2hlZOKAmQ0KPiBM U1Agd291bGQgaGF2ZSBlbmQtdG8tZW5kIE9BTSwgYW5kIGRpZmZlcmVudCBwaWVjZXMgY291bGQg dXNlIGRpZmZlcmVudA0KPiBpZGVudGlmaWVycyBpbiB0aGUgY29udHJvbCBhbmQgbWFuYWdlbWVu dCBwbGFuZXMuDQo+IA0KPiBBbHNvLCBhcyBHcmVnIG5vdGVzLCB0aGlzIGFwcGVhcnMgdG8gYmUg YSBsYXRlIGJyZWFraW5nIHJlcXVpcmVtZW50Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSm9obg0K PiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gRnJvbTogTWFsY29sbS5CRVRUU0B6dGUu Y29tLmNuIFttYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuXQ0KPiBTZW50OiBXZWRuZXNk YXksIEFwcmlsIDI3LCAyMDExIDQ6MTEgUE0NCj4gVG86IEpvaG4gRSBEcmFrZQ0KPiBDYzogRXJp YyBHcmF5OyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmll cnM/DQo+IA0KPiANCj4gSm9obiwNCj4gDQo+IFRoZSBwcm9wb3NhbCBmcm9tIEVyaWMgaXMgdGhh dCB0aGUgaWRlbnRpZmllcnMgYXJlICJzd2l0Y2hlZCIgYXQgdGhlDQo+IHN0aXRjaGluZw0KPiBw b2ludCwgdGhpcyByZXF1aXJlcyBhIGNvbXBsZXggaW50ZXJ3b3JraW5nIGZ1bmN0aW9uIGFuZCBp bnRlcnJ1cHRzIHRoZQ0KPiBlbmQgdG8NCj4gZW5kIE9BTSBmbG93IC0gaS5lLiBkYXRhIHBhY2tl dCBjYW4gdHJhbnNpdCB3aXRob3V0IGFueSBtYW5pcHVsYXRpb24NCj4gKG90aGVyDQo+IHRoYW4g dGhlIG5vcm1hbCBsYWJlbCBzd2FwKSBidXQgT0FNIHBhY2tldHMgbXVzdCBiZSBpbnRlcmNlcHRl ZCBhbmQNCj4gbWFuaXB1bGF0ZWQNCj4gaW4gdGhlIG1pZGRsZSBvZiB0aGUgY29ubmVjdGlvbiBz byBpdCBpcyBubyBsb25nZXIgYW4gZW5kIHRvIGVuZA0KPiBjb25zdHJ1Y3QuDQo+IFVzZXIgZGF0 YSBhbmQgT0FNIG5vIGxvbmdlciBmdWxseSBmYXRlIHNoYXJlLg0KPiANCj4gUmVnYXJkcywNCj4g DQo+IE1hbGNvbG0NCj4gDQo+IA0KPiANCj4gSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5u ZXQ+DQo+IDI3LzA0LzIwMTEgMDY6NTMgUE0NCj4gVG8NCj4gIk1hbGNvbG0uQkVUVFNAenRlLmNv bS5jbiIgPE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj4sIEVyaWMgR3JheSA8ZXJpYy4NCj4gZ3Jh eUBlcmljc3Nvbi5jb20+DQo+IGNjDQo+ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4s ICJtcGxzLWJvdW5jZXNAaWV0Zi5vcmciIDxtcGxzLQ0KPiBib3VuY2VzQGlldGYuDQo+IG9yZz4N Cj4gU3ViamVjdA0KPiBSRTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBM Uy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IA0KPiANCj4gDQo+IE1hbGNvbG0sDQo+IA0KPiBUaGF0 4oCZcyBpbmNvcnJlY3QuICBUaGVyZSBpcyBhIHNpbmdsZSBlbmQtdG8tZW5kIExTUCBjb21wb3Nl ZCBvZg0KPiBkaWZmZXJlbnQNCj4gcGllY2VzLCBlYWNoIHVuZGVyIHRoZSBjb250cm9sIG9mIGEg ZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGVudGl0eS4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IEpv aG4NCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+IEZyb206IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1h bGNvbG0uQkVUVFNAenRlLmNvbS5jbg0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDEx IDM6NDQgUE0NCj4gVG86IEVyaWMgR3JheQ0KPiBDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1ib3Vu Y2VzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFs LUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KPiANCj4gDQo+IEVyaWMsDQo+IA0KPiBJZiB5 b3UgInN0aXRjaCIgdGhlIExTUCBvciBQVyBhbmQgY2hhbmdlIGlkZW50aWZpZXJzIHlvdSB3aWxs IG5vdCBoYXZlDQo+IGVuZCB0bw0KPiBlbmQgT0FNIHdoaWNoIGlzIGEgcmVxdWlyZW1lbnQgZm9y IGEgTVBMUy1UUCB0cmFuc3BvcnQgbmV0d29yay4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBNYWxj b2xtDQo+IEVyaWMgR3JheSA8ZXJpYy5ncmF5QGVyaWNzc29uLmNvbT4NCj4gU2VudCBieTogbXBs cy1ib3VuY2VzQGlldGYub3JnDQo+IDI3LzA0LzIwMTEgMTI6MTEgUE0NCj4gDQo+IFRvDQo+IEdl b3JnZSBTd2FsbG93IDxzd2FsbG93QGNpc2NvLmNvbT4sICJtcGxzQGlldGYub3JnIiA8bXBsc0Bp ZXRmLm9yZz4NCj4gY2MNCj4gU3ViamVjdA0KPiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEds b2JhbC1JRHMgaW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IEFzIG9uZSBvZiB0aGUgY28tYXV0aG9ycyBvbiB0aGlzIGRyYWZ0LCBJIHN1cHBvcnQg YSByZXN0cmljdGlvbiB0bw0KPiB1c2luZyBhDQo+IGNvbW1vbg0KPiBmb3JtIG9mIGlkZW50aWZp ZXIgdGhyb3VnaG91dCBhbiBMU1Agb3IgUFcuDQo+IA0KPiBJbiBteSBvcGluaW9uLCBpdCBpcyBm YXIgYmV0dGVyIHRvIHRlcm1pbmF0ZSBMU1BzIG9yIFBXcyBhdCB0aGUgcG9pbnQNCj4gd2hlcmUN Cj4gdGhlcmUNCj4gbWlnaHQgYmUgYW4gaWRlbnRpZmllciBmb3JtIGNoYW5nZSBhbmQgInN0aXRj aCIgdGhlbSB0b2dldGhlciBpZiB0aGF0DQo+IGlzIHdoYXQNCj4gdGhlDQo+IG9wZXJhdG9ycyB3 YW50L2FncmVlIHRvIGRvLiAgVGhpcyBsaW1pdHMgdGhlIG5lZWQtdG8ta25vdyBmb3IgdGhlDQo+ IG1hcHBpbmcgb2YNCj4gb25lDQo+IGZvcm0gb2YgaWRlbnRpZmllciB0byB0aGUgb3RoZXIgdG8g dGhlIHBvaW50IGF0IHdoaWNoIHRoaXMgb2NjdXJzLA0KPiByYXRoZXIgdGhhbg0KPiBhdCBlYWNo DQo+IG5vZGUgaW4gdGhlIExTUCBvciAocG90ZW50aWFsbHkpIE1TLVBXLg0KPiANCj4gDQo+IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IEdlb3JnZQ0KPiBTd2FsbG93DQo+IFNlbnQ6IE1vbmRheSwgQXByaWwg MjUsIDIwMTEgNToxNyBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10g TWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KPiANCj4g QWxsIC0NCj4gDQo+IE1hbnkgb2YgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhlIElUVSBv biBkcmFmdC1pZXRmLW1wbHMtdHAtDQo+IGlkZW50aWZpZXJzLQ0KPiAwNCBoYXZlIHRvIGRvIHdp dGggdGhlIEdsb2JhbCBhbmQgSUNDIGlkZW50aWZpZXJzLg0KPiANCj4gVGhlIGlkZW50aWZpZXJz IGZvciBUdW5uZWwsIExTUCwgUFcsIGFuZCBNRUcgaW5jbHVkZSBmaWVsZHMgdG8gaWRlbnRpZnkN Cj4gZWFjaA0KPiBlbmQgb2YgYW4gTFNQLiAgQ3VycmVudGx5IHRoZSBkcmFmdCBhbGxvd3MgYSBU dW5uZWwsIExTUCwgUFcsIG9yIE1FRyB0bw0KPiB1c2UNCj4gZWl0aGVyIHRoZSBHbG9iYWwtSUQg Zm9yIGJvdGggZW5kcyBvciBvciB0aGUgSUNDIGZvciBib3RoIGVuZHMuICBNaXhlZA0KPiB1c2Ug aXMNCj4gbm90IHBlcm1pdHRlZC4NCj4gDQo+IFRoZSBJVFUgbGlhaXNvbiByZXF1ZXN0cyB0aGF0 IHdlIGFsbG93IG1peGVkIHVzZS4NCj4gDQo+IFRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBhcmUg dmVyeSByZWx1Y3RhbnQgdG8gZG8gdGhpcy4NCj4gDQo+IDEuICAgICAgICBPYnRhaW5pbmcgYW4g QVMgTnVtYmVyIChmcm9tIHdoaWNoIHRoZSBHbG9iYWwtSUQgaXMgZGVyaXZlZCkNCj4gaXMgYQ0K PiBmYWlybHkgdHJpdmlhbCBwcm9jZWR1cmUuICBNYW55IG9yZ2FuaXphdGlvbnMgaWYgbm90IG1v c3QgYWxyZWFkeSBoYXZlDQo+IEFTDQo+IE51bWJlcnMuDQo+IDIuICAgICAgICBTdWNoIGFuIGFk ZGl0aW9uIHdpbGwgYWRkIG51bWVyb3VzIG9iamVjdCBmb3JtYXRzLCBhbmQgdGVzdA0KPiBjYXNl cy4NCj4gMy4gICAgICAgIFRoZSBleHRlbnQgaW50ZXItcHJvdmlkZXIgTVBMUy1UUCBpcyBhcyB5 ZXQgdW5rbm93bi4gIElmDQo+IG1peGVkIG1vZGVzDQo+IG9mIElDQyBhbmQgR2xvYmFsLUlEIGlk ZW50aWZpY2F0aW9uIGlzIHJlcXVpcmVkLCB0aGV5IGNhbiBiZSBhZGRlZA0KPiBsYXRlci4NCj4g NC4gICAgICAgIEZvciBzaWduYWxlZCBjb25uZWN0aW9ucywgdGhlcmUgaXMgbm8gcGxhbiB0byBh bGxvdyByb3V0aW5nDQo+IGJhc2VkIG9uDQo+IGVpdGhlciB0aGUgR2xvYmFsLUlEIG9yIElDQy4g IFRoYXQgd291bGQgYmUgYSByYWRpY2FsIGNoYW5nZSB0byBob3cgSVANCj4gd29ya3MuDQo+IEhv d2V2ZXIgZm9yIElQIHJvdXRpbmcgdG8gd29yayAoaW4gb3JkZXIgdG8gZm9yd2FyZCB0aGUgc2ln bmFsaW5nDQo+IG1lc3NhZ2VzKSwNCj4gdGhlIHByb3ZpZGVycyBpbnZvbHZlZCB3aWxsIG5lZWQg dG8gcnVuIEJHUCBhbmQgaGF2ZSBBUyBudW1iZXJzLg0KPiANCj4gV2UgYXJlIGxvb2tpbmcgZm9y IGlucHV0L2NvbnNlbnN1cyBmcm9tIHRoZSBXRy4NCj4gDQo+IEdlb3JnZSwgRXJpYywgJiBNYXR0 aGV3IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1w bHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0KPiANCg0K From jdrake@juniper.net Tue May 3 17:51: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 A2A85E06CE; Tue, 3 May 2011 17:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 2MwqHNPGBogO; Tue, 3 May 2011 17:51:17 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 42D94E069F; Tue, 3 May 2011 17:51:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcCi/jy44bJkdeo6rqHaX561eGskNycP@postini.com; Tue, 03 May 2011 17:51:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 May 2011 17:48:19 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "Malcolm.BETTS@zte.com.cn" Date: Tue, 3 May 2011 17:48:17 -0700 Thread-Topic: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJFiCW5uQz9+scRbO6jkCyb/smXwA3cHsw Message-ID: <5E893DB832F57341992548CDBB333163A097C1989A@EMBX01-HQ.jnpr.net> References: <13144777.1226221304374389617.JavaMail.defaultUser@defaultHost> In-Reply-To: <13144777.1226221304374389617.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 04 May 2011 00:51:18 -0000 Q29tbWVudHMgaW5saW5lLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQgW21h aWx0bzplcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXRdDQo+IFNlbnQ6IE1vbmRheSwgTWF5IDAy LCAyMDExIDM6MTMgUE0NCj4gVG86IEpvaG4gRSBEcmFrZTsgTWFsY29sbS5CRVRUU0B6dGUuY29t LmNuDQo+IENjOiBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUjogUmU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4g SWRlbnRpZmllcnM/DQo+IA0KPiBJZiBteSBuYW1lIGlzIFhZWiBhbmQgeW91ciBuYW1lIGlzIDEy MywgSSBkbyB3YW50IHRvIGNoYW5nZSBteSBuYW1lIGluDQo+IG9yZGVyIHRvDQo+IHRhbGsgdG8g eW91Lg0KPiANCj4gSG93IGNhbiBhIHJlcXVpcmVtZW50IFJGQyByZXF1aXJlIHRoZSBpbnRlcmNv bm5lY3Rpb24gYmV0d2VlbiBJUC1iYXNlZA0KPiBhbmQgSUNDLQ0KPiBiYXNlZCBpZGVudGlmaWVy cyBiZWZvcmUgdGhlc2UgaWRlbnRpZmllcnMgYXJlIGRlZmluZWQ/DQoNCkpEOiAgQnkgc2F5aW5n IHNvbWV0aGluZyBsaWtlICJJZiBtdWx0aXBsZSB0eXBlcyBvZiBpZGVudGlmaWVycyBhcmUgZGVm aW5lZCwgdGhlIGVuZHBvaW50cyBvZiBhIGdpdmVuIExTUCBvciBwc2V1ZG93aXJlIE1VU1QgYmUg YWJsZSB0byB1c2UgZGlmZmVyZW50IGlkZW50aWZpZXIgdHlwZXMiPw0KDQo+IA0KPiBJIGNhbiBz ZWUgcmVxdWlyZW1lbnRzIGZvciBzdXBwb3J0aW5nIGRpZmZlcmVudCBpZGVudGlmaWVycyBzY2hl bWVzIGFuZA0KPiByZXF1aXJlbWVudHMgdG8gc3VwcG9ydCBtdWx0aS1kb21haW4gaW50ZXJjb25u ZWN0aW9uLiBJIGRvIG5vdCBzZWUgYW55DQo+IHJlcXVpcmVtZW50IHRoYXQgbGltaXQgaW50ZXIt ZG9tYWluIGludGVyY29ubmVjdGlvbiBvbmx5IGJldHdlZW4NCj4gZG9tYWlucyB0aGF0DQo+IGhh dmUgdGhlIHNhbWUgaWRlbnRpZmllcnMgc2NoZW1lLg0KDQpKRDogSSBkaWRuJ3Qgc2F5IHRoYXQu ICBXaGF0IEkgc2FpZCB3YXM6DQoNCiJKRDogIFRoZSBlbmRwb2ludHMgaGF2ZSB0byBhZ3JlZSBv biBhIGNvbW1vbiBmb3JtYXQgZm9yIHRoZSBkYXRhIHBsYW5lLiINCg0KVGhpcyBpcyBhIHZlcnkg ZGlmZmVyZW50IHN0YXRlbWVudCwgYW5kIHNlZW1zIGVtaW5lbnRseSByZWFzb25hYmxlIHRvIG1l Lg0KDQo+IA0KPiBIYXZlIEkgbWlzc2VkIHNvbWUgcmVxdWlyZW1lbnQ/DQo+IA0KPiAtLS0tTWVz c2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj4gRGE6IGpkcmFrZUBqdW5pcGVyLm5ldA0KPiBEYXRhOiAy OC1hcHItMjAxMSAxOC4yMg0KPiBBOiAiTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIjxNYWxjb2xt LkJFVFRTQHp0ZS5jb20uY24+DQo+IENjOiAibXBsc0BpZXRmLm9yZyI8bXBsc0BpZXRmLm9yZz4s ICJtcGxzLWJvdW5jZXNAaWV0Zi5vcmciPG1wbHMtDQo+IGJvdW5jZXNAaWV0Zi4NCj4gb3JnPg0K PiBPZ2c6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElk ZW50aWZpZXJzPw0KPiANCj4gQ29tbWVudHMgaW5saW5lLg0KPiANCj4gU2VudCBmcm9tIG15IGlQ aG9uZQ0KPiANCj4gRnJvbTogTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIFttYWlsdG86TWFsY29s bS5CRVRUU0B6dGUuY29tLmNuXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDExIDg6 MjUgUE0NCj4gVG86IEpvaG4gRSBEcmFrZQ0KPiBDYzogRXJpYyBHcmF5OyBtcGxzQGlldGYub3Jn OyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBNaXhpbmcgSUND IGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gSm9obiwN Cj4gDQo+IEpvaG4sIGlmIHlvdSBkbyBub3QgYWxsb3cgbWl4IGlkZW50aWZpZXIgdHlwZXMgaG93 IGNhbiB5b3UgaGF2ZSBhbiBlbmQNCj4gdG8gZW5kDQo+IENWIG1lc3NhZ2UuDQo+IEpEOiAgVGhl IGVuZHBvaW50cyBoYXZlIHRvIGFncmVlIG9uIGEgY29tbW9uIGZvcm1hdCBmb3IgdGhlIGRhdGEg cGxhbmUuDQo+IFRoYXTigJkNCj4gcyB0aGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRpc2N1c3Npb24u DQo+ICBJZiB5b3UgYXJlIHVzaW5nIHN0aXRjaGluZyB0byBhbGxvdyBhIHNpbmdsZSBpZGVudGlm aWVyIHR5cGUgdGhlbiB0aGUNCj4gaWRlbnRpZmllcnMgaW4gYSBDViBtZXNzYWdlIG11c3QgYmUg dHJhbnNsYXRlZCBhdCB0aGUgc3RpdGNoaW5nIHBvaW50Lg0KPiBBIHZlcnkNCj4gYmFkIGlkZWEh DQo+IEpEOiAgSSBuZXZlciBwcm9wb3NlZCB0aGlzLiAgWW91IGhhdmUgYSB0ZW5kZW5jeSB0byBh dHRyaWJ1dGUgYSBzaWxseQ0KPiBpZGVhIHRvDQo+IHNvbWVvbmUgYW5kIHRoZW4gcmlkaWN1bGUg aXQuICBCdHcsIHlvdSBtaWdodCBjb25zaWRlciByZXZpZXdpbmcgUkZDDQo+IDUxNTAuDQo+IA0K PiBUaGlzIGlzIG5vdCBhICJsYXRlIGJyZWFraW5nIHJlcXVpcmVtZW50Ii4gIFRoZSByZXF1aXJl bWVudHMgZm9yDQo+IHN1cHBvcnQgb2YNCj4gYm90aCBJQ0MgYW5kIElQIGlkZW50aWZpZXJzIHNj aGVtZXMgaXMgd2VsbCBkb2N1bWVudGVkLiAgQXMgaXMgdGhlDQo+IGV4cGVjdGF0aW9uDQo+IG9m IHVzaW5nIE1QTFMtVFAgaW4gbXVsdGktb3BlcmF0b3IgdHJhbnNwb3J0IG5ldHdvcmtzLiAgSGVu Y2UgdGhlIG5lZWQNCj4gdG8NCj4gc3VwcG9ydCBib3RoIG9uIGEgTFNQL1BXLiAgVGhpcyBjb21t ZW50IGhhcyBiZWVuIG1hZGUgZHVyaW5nIHByZXZpb3VzDQo+IGxhc3QNCj4gY2FsbHMgb24gdGhp cyBkcmFmdC4NCj4gSkQ6ICBJZiBpdCBpcyBub3QgaW4gdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRz IFJGQ3MsIGl0IGlzIGJ5IGRlZmluaXRpb24NCj4gYSBsYXRlDQo+IGJyZWFraW5nIHJlcXVpcmVt ZW50Lg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IE1hbGNvbG0NCj4gDQo+IA0KPiANCj4gSm9obiBF IERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+DQo+IDI3LzA0LzIwMTEgMDc6MjUgUE0NCj4gVG8N Cj4gIk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiIgPE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj4N Cj4gY2MNCj4gRXJpYyBHcmF5IDxlcmljLmdyYXlAZXJpY3Nzb24uY29tPiwgIm1wbHNAaWV0Zi5v cmciIDxtcGxzQGlldGYub3JnPiwNCj4gIm1wbHMtDQo+IGJvdW5jZXNAaWV0Zi5vcmciIDxtcGxz LWJvdW5jZXNAaWV0Zi5vcmc+DQo+IFN1YmplY3QNCj4gUkU6IFttcGxzXSBNaXhpbmcgSUNDIGFu ZCBHbG9iYWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gDQo+IA0KPiBN YWxjb2xtLA0KPiANCj4gSSBpbnRlcnByZXRlZCBFcmlj4oCZcyB1c2Ugb2YgIOKAmHN0aXRjaGlu Z+KAmSAgdG8gYmUgaW4gdGhlIFJGQyA1MTUwIHNlbnNlLg0KPiBJDQo+IHRoaW5rIEkgd2lsbCBs ZXQgaGltIGNsYXJpZnksIGJ1dCBpZiB1c2VkIGluIHRoZSBSRkMgNTE1MCBzZW5zZSwgYQ0KPiDi gJhzdGl0Y2hlZOKAmQ0KPiBMU1Agd291bGQgaGF2ZSBlbmQtdG8tZW5kIE9BTSwgYW5kIGRpZmZl cmVudCBwaWVjZXMgY291bGQgdXNlIGRpZmZlcmVudA0KPiBpZGVudGlmaWVycyBpbiB0aGUgY29u dHJvbCBhbmQgbWFuYWdlbWVudCBwbGFuZXMuDQo+IA0KPiBBbHNvLCBhcyBHcmVnIG5vdGVzLCB0 aGlzIGFwcGVhcnMgdG8gYmUgYSBsYXRlIGJyZWFraW5nIHJlcXVpcmVtZW50Lg0KPiANCj4gVGhh bmtzLA0KPiANCj4gSm9obg0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gRnJvbTog TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIFttYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNu XQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDExIDQ6MTEgUE0NCj4gVG86IEpvaG4g RSBEcmFrZQ0KPiBDYzogRXJpYyBHcmF5OyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGlu IE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gSm9obiwNCj4gDQo+IFRoZSBwcm9wb3Nh bCBmcm9tIEVyaWMgaXMgdGhhdCB0aGUgaWRlbnRpZmllcnMgYXJlICJzd2l0Y2hlZCIgYXQgdGhl DQo+IHN0aXRjaGluZw0KPiBwb2ludCwgdGhpcyByZXF1aXJlcyBhIGNvbXBsZXggaW50ZXJ3b3Jr aW5nIGZ1bmN0aW9uIGFuZCBpbnRlcnJ1cHRzIHRoZQ0KPiBlbmQgdG8NCj4gZW5kIE9BTSBmbG93 IC0gaS5lLiBkYXRhIHBhY2tldCBjYW4gdHJhbnNpdCB3aXRob3V0IGFueSBtYW5pcHVsYXRpb24N Cj4gKG90aGVyDQo+IHRoYW4gdGhlIG5vcm1hbCBsYWJlbCBzd2FwKSBidXQgT0FNIHBhY2tldHMg bXVzdCBiZSBpbnRlcmNlcHRlZCBhbmQNCj4gbWFuaXB1bGF0ZWQNCj4gaW4gdGhlIG1pZGRsZSBv ZiB0aGUgY29ubmVjdGlvbiBzbyBpdCBpcyBubyBsb25nZXIgYW4gZW5kIHRvIGVuZA0KPiBjb25z dHJ1Y3QuDQo+IFVzZXIgZGF0YSBhbmQgT0FNIG5vIGxvbmdlciBmdWxseSBmYXRlIHNoYXJlLg0K PiANCj4gUmVnYXJkcywNCj4gDQo+IE1hbGNvbG0NCj4gSm9obiBFIERyYWtlIDxqZHJha2VAanVu aXBlci5uZXQ+DQo+IDI3LzA0LzIwMTEgMDY6NTMgUE0NCj4gDQo+IFRvDQo+ICJNYWxjb2xtLkJF VFRTQHp0ZS5jb20uY24iIDxNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+LCBFcmljIEdyYXkgPGVy aWMuDQo+IGdyYXlAZXJpY3Nzb24uY29tPg0KPiBjYw0KPiAibXBsc0BpZXRmLm9yZyIgPG1wbHNA aWV0Zi5vcmc+LCAibXBscy1ib3VuY2VzQGlldGYub3JnIiA8bXBscy0NCj4gYm91bmNlc0BpZXRm Lg0KPiBvcmc+DQo+IFN1YmplY3QNCj4gUkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwt SURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0K PiBNYWxjb2xtLA0KPiANCj4gVGhhdOKAmXMgaW5jb3JyZWN0LiAgVGhlcmUgaXMgYSBzaW5nbGUg ZW5kLXRvLWVuZCBMU1AgY29tcG9zZWQgb2YNCj4gZGlmZmVyZW50DQo+IHBpZWNlcywgZWFjaCB1 bmRlciB0aGUgY29udHJvbCBvZiBhIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZSBlbnRpdHkuDQo+ IA0KPiBUaGFua3MsDQo+IA0KPiBKb2huDQo+IA0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+IA0K PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZg0KPiBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24NCj4gU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAyNywgMjAxMSAzOjQ0IFBNDQo+IFRvOiBFcmljIEdyYXkNCj4gQ2M6IG1w bHNAaWV0Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNd IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+ IA0KPiBFcmljLA0KPiANCj4gSWYgeW91ICJzdGl0Y2giIHRoZSBMU1Agb3IgUFcgYW5kIGNoYW5n ZSBpZGVudGlmaWVycyB5b3Ugd2lsbCBub3QgaGF2ZQ0KPiBlbmQgdG8NCj4gZW5kIE9BTSB3aGlj aCBpcyBhIHJlcXVpcmVtZW50IGZvciBhIE1QTFMtVFAgdHJhbnNwb3J0IG5ldHdvcmsuDQo+IA0K PiBSZWdhcmRzLA0KPiANCj4gTWFsY29sbQ0KPiBFcmljIEdyYXkgPGVyaWMuZ3JheUBlcmljc3Nv bi5jb20+DQo+IFNlbnQgYnk6IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiAyNy8wNC8yMDExIDEy OjExIFBNDQo+IA0KPiANCj4gVG8NCj4gR2VvcmdlIFN3YWxsb3cgPHN3YWxsb3dAY2lzY28uY29t PiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KPiBjYw0KPiBTdWJqZWN0DQo+IFJl OiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJz Pw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBBcyBvbmUgb2YgdGhlIGNv LWF1dGhvcnMgb24gdGhpcyBkcmFmdCwgSSBzdXBwb3J0IGEgcmVzdHJpY3Rpb24gdG8NCj4gdXNp bmcgYQ0KPiBjb21tb24NCj4gZm9ybSBvZiBpZGVudGlmaWVyIHRocm91Z2hvdXQgYW4gTFNQIG9y IFBXLg0KPiANCj4gSW4gbXkgb3BpbmlvbiwgaXQgaXMgZmFyIGJldHRlciB0byB0ZXJtaW5hdGUg TFNQcyBvciBQV3MgYXQgdGhlIHBvaW50DQo+IHdoZXJlDQo+IHRoZXJlDQo+IG1pZ2h0IGJlIGFu IGlkZW50aWZpZXIgZm9ybSBjaGFuZ2UgYW5kICJzdGl0Y2giIHRoZW0gdG9nZXRoZXIgaWYgdGhh dA0KPiBpcyB3aGF0DQo+IHRoZQ0KPiBvcGVyYXRvcnMgd2FudC9hZ3JlZSB0byBkby4gIFRoaXMg bGltaXRzIHRoZSBuZWVkLXRvLWtub3cgZm9yIHRoZQ0KPiBtYXBwaW5nIG9mDQo+IG9uZQ0KPiBm b3JtIG9mIGlkZW50aWZpZXIgdG8gdGhlIG90aGVyIHRvIHRoZSBwb2ludCBhdCB3aGljaCB0aGlz IG9jY3VycywNCj4gcmF0aGVyIHRoYW4NCj4gYXQgZWFjaA0KPiBub2RlIGluIHRoZSBMU1Agb3Ig KHBvdGVudGlhbGx5KSBNUy1QVy4NCj4gDQo+IA0KPiANCj4gDQo+IEZyb206IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ IEdlb3JnZQ0KPiBTd2FsbG93DQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjUsIDIwMTEgNToxNyBQ TQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10gTWl4aW5nIElDQyBhbmQg R2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KPiANCj4gQWxsIC0NCj4gDQo+IE1h bnkgb2YgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gdGhlIElUVSBvbiBkcmFmdC1pZXRmLW1w bHMtdHAtDQo+IGlkZW50aWZpZXJzLQ0KPiAwNCBoYXZlIHRvIGRvIHdpdGggdGhlIEdsb2JhbCBh bmQgSUNDIGlkZW50aWZpZXJzLg0KPiANCj4gVGhlIGlkZW50aWZpZXJzIGZvciBUdW5uZWwsIExT UCwgUFcsIGFuZCBNRUcgaW5jbHVkZSBmaWVsZHMgdG8gaWRlbnRpZnkNCj4gZWFjaA0KPiBlbmQg b2YgYW4gTFNQLiAgQ3VycmVudGx5IHRoZSBkcmFmdCBhbGxvd3MgYSBUdW5uZWwsIExTUCwgUFcs IG9yIE1FRyB0bw0KPiB1c2UNCj4gZWl0aGVyIHRoZSBHbG9iYWwtSUQgZm9yIGJvdGggZW5kcyBv ciBvciB0aGUgSUNDIGZvciBib3RoIGVuZHMuICBNaXhlZA0KPiB1c2UgaXMNCj4gbm90IHBlcm1p dHRlZC4NCj4gDQo+IFRoZSBJVFUgbGlhaXNvbiByZXF1ZXN0cyB0aGF0IHdlIGFsbG93IG1peGVk IHVzZS4NCj4gDQo+IFRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBhcmUgdmVyeSByZWx1Y3RhbnQg dG8gZG8gdGhpcy4NCj4gDQo+IDEuICAgICAgICBPYnRhaW5pbmcgYW4gQVMgTnVtYmVyIChmcm9t IHdoaWNoIHRoZSBHbG9iYWwtSUQgaXMgZGVyaXZlZCkNCj4gaXMgYQ0KPiBmYWlybHkgdHJpdmlh bCBwcm9jZWR1cmUuICBNYW55IG9yZ2FuaXphdGlvbnMgaWYgbm90IG1vc3QgYWxyZWFkeSBoYXZl DQo+IEFTDQo+IE51bWJlcnMuDQo+IDIuICAgICAgICBTdWNoIGFuIGFkZGl0aW9uIHdpbGwgYWRk IG51bWVyb3VzIG9iamVjdCBmb3JtYXRzLCBhbmQgdGVzdA0KPiBjYXNlcy4NCj4gMy4gICAgICAg IFRoZSBleHRlbnQgaW50ZXItcHJvdmlkZXIgTVBMUy1UUCBpcyBhcyB5ZXQgdW5rbm93bi4gIElm DQo+IG1peGVkIG1vZGVzDQo+IG9mIElDQyBhbmQgR2xvYmFsLUlEIGlkZW50aWZpY2F0aW9uIGlz IHJlcXVpcmVkLCB0aGV5IGNhbiBiZSBhZGRlZA0KPiBsYXRlci4NCj4gNC4gICAgICAgIEZvciBz aWduYWxlZCBjb25uZWN0aW9ucywgdGhlcmUgaXMgbm8gcGxhbiB0byBhbGxvdyByb3V0aW5nDQo+ IGJhc2VkIG9uDQo+IGVpdGhlciB0aGUgR2xvYmFsLUlEIG9yIElDQy4gIFRoYXQgd291bGQgYmUg YSByYWRpY2FsIGNoYW5nZSB0byBob3cgSVANCj4gd29ya3MuDQo+IEhvd2V2ZXIgZm9yIElQIHJv dXRpbmcgdG8gd29yayAoaW4gb3JkZXIgdG8gZm9yd2FyZCB0aGUgc2lnbmFsaW5nDQo+IG1lc3Nh Z2VzKSwNCj4gdGhlIHByb3ZpZGVycyBpbnZvbHZlZCB3aWxsIG5lZWQgdG8gcnVuIEJHUCBhbmQg aGF2ZSBBUyBudW1iZXJzLg0KPiANCj4gV2UgYXJlIGxvb2tpbmcgZm9yIGlucHV0L2NvbnNlbnN1 cyBmcm9tIHRoZSBXRy4NCj4gDQo+IEdlb3JnZSwgRXJpYywgJiBNYXR0aGV3IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0 DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo+IA0KPiANCg0K From jdrake@juniper.net Tue May 3 17:53: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 A0E99E06D1 for ; Tue, 3 May 2011 17:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 BySalxGP0wTp for ; Tue, 3 May 2011 17:53:37 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1CCE0670 for ; Tue, 3 May 2011 17:53:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcCjjNCInpVEXk6g0LVJDilV5o41A7A1@postini.com; Tue, 03 May 2011 17:53:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 May 2011 17:53:11 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "eric.gray@ericsson.com" , "huubatwork@gmail.com" , "mpls@ietf.org" Date: Tue, 3 May 2011 17:53:09 -0700 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwJGNxNwP65GkkUSCCHoI9JL81+rQA3DvpQ Message-ID: <5E893DB832F57341992548CDBB333163A097C198AD@EMBX01-HQ.jnpr.net> References: <32953866.1227541304375514800.JavaMail.defaultUser@defaultHost> In-Reply-To: <32953866.1227541304375514800.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] R: Re: 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, 04 May 2011 00:53:38 -0000 Q29tbWVudHMgaW5saW5lLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBlcm1pbmlvLm90dG9uZV82OUBs aWJlcm8uaXQNCj4gU2VudDogTW9uZGF5LCBNYXkgMDIsIDIwMTEgMzozMiBQTQ0KPiBUbzogZXJp Yy5ncmF5QGVyaWNzc29uLmNvbTsgaHV1YmF0d29ya0BnbWFpbC5jb207IG1wbHNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1Q TFMtVFANCj4gSWRlbnRpZmllcnM/DQo+IA0KPiBJIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB0aGlz IGRpc2N1c3Npb24gaXMgcmVsYXRlZCB0byB0aGUgT0FNIGRlYmF0ZQ0KPiByZWdhcmRpbmcNCj4g Ry44MTEzLjEuDQoNCkpEOiAgVW0sIHdoYXQgaXMgRy44MTEzLjEsIHdoYXQgaXMgInRoZSBPQU0g ZGViYXRlIHJlZ2FyZGluZyBHLjgxMTMuMSIsIGFuZCB3aGF0IGRvZXMgZWl0aGVyIHRvcGljIGhh dmUgdG8gZG8gd2l0aCB0aGUgaWRlbnRpZmllcnMgZHJhZnQ/DQoNCj4gDQo+IE5ldmVydGhlbGVz cywgSSBoYXZlIG5vdCBzZWVuIGFueSBzdXBwb3J0ZXIgb2YgRy44MTEzLjEgc3RhdGluZyBubyBu ZWVkDQo+IGZvcg0KPiBlbmQtdG8tZW5kIE9BTSBub3IgdGhlIG5lZWQgZm9yIGFuIE9BTSBpbnRl cndvcmtpbmcgZnVuY3Rpb24gYmV0d2Vlbg0KPiBHLjgxMTMuMQ0KPiBhbmQgSUVURi1PQU0gZG9t YWlucy4NCg0KSkQ6ICBUaGlzIGlzIHNpbXBseSBiYWZmbGluZw0KDQo+IA0KPiBDb3VsZCB5b3Ug cHJvdmlkZSBzb21lIHJlZmVyZW5jZSBhYm91dCB0aGlzPyBJIG1pZ2h0IGhhdmUgbWlzc2VkIHRo ZW0uDQo+IA0KPiAtLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0NCj4gRGE6IGVyaWMuZ3JheUBl cmljc3Nvbi5jb20NCj4gRGF0YTogMjgtYXByLTIwMTEgMjMuMTcNCj4gQTogImh1dWJhdHdvcmtA Z21haWwuY29tIjxodXViYXR3b3JrQGdtYWlsLmNvbT4sDQo+ICJtcGxzQGlldGYub3JnIjxtcGxz QGlldGYuDQo+IG9yZz4NCj4gT2dnOiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1J RHMgaW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IEh1dWIsICAgICBQbGVhc2Ugc2VlIGJl bG93Li4uIC0tRXJpYw0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBIdXViDQo+IHZhbiBIZWx2b29ydA0K PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjgsIDIwMTEgNjo0NCBBTQ0KPiBUbzogbXBsc0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4g TVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IEhpIE1hbGNvbG0sDQo+IA0KPiBZb3Ugd3JvdGU6 DQo+IEpvaG4sIGlmIHlvdSBkbyBub3QgYWxsb3cgbWl4IGlkZW50aWZpZXIgdHlwZXMgaG93IGNh biB5b3UgaGF2ZSBhbiBlbmQNCj4gdG8gZW5kDQo+IENWIG1lc3NhZ2UuICBJZiB5b3UgYXJlIHVz aW5nIHN0aXRjaGluZyB0byBhbGxvdyBhIHNpbmdsZSBpZGVudGlmaWVyDQo+IHR5cGUgdGhlbg0K PiB0aGUgaWRlbnRpZmllcnMgaW4gYSBDViBtZXNzYWdlIG11c3QgYmUgdHJhbnNsYXRlZCBhdCB0 aGUgc3RpdGNoaW5nDQo+IHBvaW50LiAgQQ0KPiB2ZXJ5IGJhZCBpZGVhIQ0KPiBJbmRlZWQhDQo+ IA0KPiBBY3R1YWxseSBJIHRoaW5rIGEgZmFpciBudW1iZXIgb2YgdXMgZGlzYWdyZWUuIEl0IHNl ZW1zIG9idmlvdXMgKHRvIG1lDQo+IGF0DQo+IGxlYXN0KSB0aGF0IHNvbWUgc29ydCBvZiBPQU0g aW50ZXJ3b3JraW5nZnVuY3Rpb24gaXMgZ29pbmcgdG8gYmUNCj4gbmVjZXNzYXJ5LA0KPiBnaXZl biB0aGF0IHRoZXJlIGlzIGFsbW9zdCBjZXJ0YWlubHlhIG5vbi1udWxsIGludGVyc2VjdGlvbiBv Zg0KPiBvcGVyYXRvcnMgdGhhdA0KPiB1c2UgSUNDIGZvcm1hdCBpZGVudGlmaWVycywgd2hvYWxz byBwbGFuIHRvIHVzZSBPQU0gYXMgc3BlY2lmaWVkIGluDQo+IEc4MTEzLjEgYW5kDQo+IHdobyBh cmUgbm93IGFyZ3VpbmcgdGhleSB3YW50IGVuZC10by1lbmQgT0FNIHdpdGggb3BlcmF0b3JzIHdo byB3aWxsDQo+IHVzZSBHbG9iYWwNCj4gaWRlbnRpZmllcnNhbmQgbWF5IHZlcnkgd2VsbCB1c2Ug T0FNIGFzIHNwZWNpZmllZCBpbiBJRVRGIFJGQ3MuIEdpdmVuDQo+IHRoYXQgc3VjaA0KPiBhbiBp bnRlcndvcmtpbmcgcmVxdWlyZW1lbnQgaXMgbGlrZWx5LCBpdCBpcyBhIGZhciBiZXR0ZXJ1c2Ug b2YgdGltZQ0KPiBhbmQgZW5lcmd5DQo+IHRvIHN0YXJ0IHRoaW5raW5nIGFib3V0IGhvdyBzdWNo IGFuIGludGVyd29ya2luZ2Z1bmN0aW9uIHdvdWxkIHdvcmsgYW5kDQo+IHdvdWxkDQo+IG1vc3Qg bGlrZWx5IHN1cHBvcnQgdHJhbnNsYXRpb24gb2YgSUNDIGFuZEdsb2JhbCBJZGVudGlmaWVycy4g SXQgaXMNCj4gY2VydGFpbmx5IGENCj4gYmV0dGVyIHVzZSBvZiB0aW1lIGFuZCBlbmVyZ3kgdGhh biBpdCBpcyB0byB0cnkgdG8gc3VwcG9ydCBhIHByZXN1bWVkDQo+IG1peGluZyBvZg0KPiB0aGUg dHdvIGZvcm1hdHMgaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KPiBUaGlzIGlz IG5vdCBhICJsYXRlIGJyZWFraW5nIHJlcXVpcmVtZW50Ii4gIFRoZSByZXF1aXJlbWVudHMgZm9y DQo+IHN1cHBvcnQgb2YNCj4gYm90aCBJQ0MgYW5kIElQIGlkZW50aWZpZXJzIHNjaGVtZXMgaXMg d2VsbCBkb2N1bWVudGVkLiAgQXMgaXMgdGhlDQo+IGV4cGVjdGF0aW9uDQo+IG9mIHVzaW5nIE1Q TFMtVFAgaW4gbXVsdGktb3BlcmF0b3IgdHJhbnNwb3J0IG5ldHdvcmtzLiAgSGVuY2UgdGhlIG5l ZWQNCj4gdG8NCj4gc3VwcG9ydCBib3RoIG9uIGEgTFNQL1BXLiAgVGhpcyBjb21tZW50IGhhcyBi ZWVuIG1hZGUgZHVyaW5nIHByZXZpb3VzDQo+IGxhc3QNCj4gY2FsbHMgb24gdGhpcyBkcmFmdC4N Cj4gQ29ycmVjdC4gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgYXNzZXNzbWVudC4NCj4gDQo+IFVu Zm9ydHVuYXRlbHkgdGhpcyBpcyBhbiBpbmNvcnJlY3QgKG9yIG5haXZlKSBhc3Nlc3NtZW50Lg0K PiBNYW55IGhvdXNlcyBoYXZlIGJvdGggYSBmdXJuYWNlIGFuZCBvbmUgb3IgbW9yZSBzZXRzIG9m IGZ1cm5pdHVyZS4gSXQNCj4gaXMNCj4gY2VydGFpbmx5IGFyZ3VhYmxlIHRoYXQgdGhlIG5lZWQg Zm9yIGJvdGggaXMgYSByaWdpZCByZXF1aXJlbWVudCBpbnNvbWUNCj4gb2YgdGhlDQo+IGxlc3Mg dGVtcGVyYXRlIHpvbmVzLiBTaG91bGQgdGhpcyBiZSBmb3JtYWxpemVkIGFzIGEgY3J5c3RhbCBj bGVhcg0KPiBob3VzaW5nDQo+IHJlcXVpcmVtZW50LCBJJ21wcmV0dHkgc3VyZSB0aGF0IG5vIG9u ZSB3b3VsZCBzdWJzZXF1ZW50bHkgaW50ZXJwcmV0IGl0DQo+IHRvIG1lYW4NCj4gdGhhdGJvdGgg dGhlIGZ1cm5pdHVyZSBhbmQgdGhlIGZ1cm5hY2UgbmVlZCB0byBiZSBhYmxlIHRvIG9jY3VweSB0 aGUNCj4gc2FtZXNwYWNlDQo+IGluIHRoZSBzYW1lIGhvdXNlLiAgU2luY2UgdGhlIGFwcGFyZW50 ICJyZXF1aXJlbWVudCIgdGhhdCB0aGUgc2FtZQ0KPiBtZXNzYWdlcw0KPiBzaG91bGQgYmVhYmxl IHRvIGluY2x1ZGUgZWl0aGVyIG9yIGJvdGggb2YgdGhlIHJlcXVpcmVkIGlkZW50aWZpZXJzLA0K PiBhbmQgdGhpcw0KPiBpcyBub3RvYnZpb3VzIGZyb20gdGhlIGFzc2VydGlvbiBvZiBhIHJlcXVp cmVtZW50IHRvIG1lcmVseSBhbGxvdw0KPiBzdXBwb3J0DQo+IGZvcmJvdGgsIHRoaXMgaXMgaW5k ZWVkIGEgbGF0ZS1icmVha2luZyByZXF1aXJlbWVudC4NCj4gQmVzdCByZWdhcmRzLCBIdXViLg0K PiANCj4gDQo+IA0KPiBTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gSm9obiBFIERyYWtlIDxq ZHJha2VAanVuaXBlci5uZXQ+DQo+IDI3LzA0LzIwMTEgMDc6MjUNCj4gUE0NCj4gVG8iTWFsY29s bS5CRVRUU0B6dGUuY29tLmNuIiA8TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPiBjY0VyaWMgR3Jh eQ0KPiA8ZXJpYy4NCj4gZ3JheUBlcmljc3Nvbi5jb20+LCAibXBsc0BpZXRmLm9yZyIgPG1wbHNA aWV0Zi5vcmc+LCAibXBscy0NCj4gYm91bmNlc0BpZXRmLm9yZyINCj4gPG1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4gU3ViamVjdFJFOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbg0K PiBNUExTLVRQDQo+IElkZW50aWZpZXJzPw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBNYWxj b2xtLA0KPiANCj4gSSBpbnRlcnByZXRlZCBFcmlj4oCZcyB1c2Ugb2YgIOKAmHN0aXRjaGluZ+KA mSAgdG8gYmUgaW4gdGhlIFJGQyA1MTUwIHNlbnNlLg0KPiBJDQo+IHRoaW5rIEkgd2lsbCBsZXQg aGltIGNsYXJpZnksIGJ1dCBpZiB1c2VkIGluIHRoZSBSRkMgNTE1MCBzZW5zZSwgYQ0KPiDigJhz dGl0Y2hlZOKAmQ0KPiBMU1Agd291bGQgaGF2ZSBlbmQtdG8tZW5kIE9BTSwgYW5kIGRpZmZlcmVu dCBwaWVjZXMgY291bGQgdXNlIGRpZmZlcmVudA0KPiBpZGVudGlmaWVycyBpbiB0aGUgY29udHJv bCBhbmQgbWFuYWdlbWVudCBwbGFuZXMuDQo+IA0KPiBBbHNvLCBhcyBHcmVnIG5vdGVzLCB0aGlz IGFwcGVhcnMgdG8gYmUgYSBsYXRlIGJyZWFraW5nIHJlcXVpcmVtZW50Lg0KPiANCj4gVGhhbmtz LA0KPiANCj4gSm9obg0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gRnJvbTogTWFs Y29sbS5CRVRUU0B6dGUuY29tLmNuIFttYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuXQ0K PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDExIDQ6MTEgUE0NCj4gVG86IEpvaG4gRSBE cmFrZQ0KPiBDYzogRXJpYyBHcmF5OyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1Q TFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gSm9obiwNCj4gDQo+IFRoZSBwcm9wb3NhbCBm cm9tIEVyaWMgaXMgdGhhdCB0aGUgaWRlbnRpZmllcnMgYXJlICJzd2l0Y2hlZCIgYXQgdGhlDQo+ IHN0aXRjaGluZw0KPiBwb2ludCwgdGhpcyByZXF1aXJlcyBhIGNvbXBsZXggaW50ZXJ3b3JraW5n IGZ1bmN0aW9uIGFuZCBpbnRlcnJ1cHRzIHRoZQ0KPiBlbmQgdG8NCj4gZW5kIE9BTSBmbG93IC0g aS5lLiBkYXRhIHBhY2tldCBjYW4gdHJhbnNpdCB3aXRob3V0IGFueSBtYW5pcHVsYXRpb24NCj4g KG90aGVyDQo+IHRoYW4gdGhlIG5vcm1hbCBsYWJlbCBzd2FwKSBidXQgT0FNIHBhY2tldHMgbXVz dCBiZSBpbnRlcmNlcHRlZCBhbmQNCj4gbWFuaXB1bGF0ZWQNCj4gaW4gdGhlIG1pZGRsZSBvZiB0 aGUgY29ubmVjdGlvbiBzbyBpdCBpcyBubyBsb25nZXIgYW4gZW5kIHRvIGVuZA0KPiBjb25zdHJ1 Y3QuDQo+IFVzZXIgZGF0YSBhbmQgT0FNIG5vIGxvbmdlciBmdWxseSBmYXRlIHNoYXJlLg0KPiAN Cj4gUmVnYXJkcywNCj4gDQo+IE1hbGNvbG0NCj4gDQo+IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1 bmlwZXIubmV0PiAyNy8wNC8yMDExIDA2OjUzIFBNDQo+IA0KPiBUbyJNYWxjb2xtLkJFVFRTQHp0 ZS5jb20uY24iIDxNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+LCBFcmljIEdyYXkNCj4gPGVyaWMu DQo+IGdyYXlAZXJpY3Nzb24uY29tPiBjYyJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4s ICJtcGxzLQ0KPiBib3VuY2VzQGlldGYub3JnIg0KPiA8bXBscy1ib3VuY2VzQGlldGYub3JnPiBT dWJqZWN0UkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluDQo+IE1QTFMtVFAN Cj4gSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gTWFsY29s bSwNCj4gDQo+IFRoYXTigJlzIGluY29ycmVjdC4gIFRoZXJlIGlzIGEgc2luZ2xlIGVuZC10by1l bmQgTFNQIGNvbXBvc2VkIG9mDQo+IGRpZmZlcmVudA0KPiBwaWVjZXMsIGVhY2ggdW5kZXIgdGhl IGNvbnRyb2wgb2YgYSBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZW50aXR5Lg0KPiANCj4gVGhh bmtzLA0KPiANCj4gSm9obg0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gRnJvbTog bXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YNCj4gTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuDQo+IFNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMjcsIDIwMTEgMzo0NCBQTQ0KPiBUbzogRXJpYyBHcmF5DQo+IENjOiBtcGxzQGlldGYu b3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBNaXhpbmcg SUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAgSWRlbnRpZmllcnM/DQo+IA0KPiANCj4gRXJp YywNCj4gDQo+IElmIHlvdSAic3RpdGNoIiB0aGUgTFNQIG9yIFBXIGFuZCBjaGFuZ2UgaWRlbnRp ZmllcnMgeW91IHdpbGwgbm90IGhhdmUNCj4gZW5kIHRvDQo+IGVuZCBPQU0gd2hpY2ggaXMgYSBy ZXF1aXJlbWVudCBmb3IgYSBNUExTLVRQIHRyYW5zcG9ydCBuZXR3b3JrLg0KPiANCj4gUmVnYXJk cywNCj4gDQo+IE1hbGNvbG0NCj4gRXJpYyBHcmF5IDxlcmljLmdyYXlAZXJpY3Nzb24uY29tPg0K PiBTZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgMjcvMDQvMjAxMSAxMjoxMSBQTQ0KPiAN Cj4gVG9HZW9yZ2UgU3dhbGxvdyA8c3dhbGxvd0BjaXNjby5jb20+LCAibXBsc0BpZXRmLm9yZyIg PG1wbHNAaWV0Zi5vcmc+DQo+IGNjDQo+IFN1YmplY3RSZTogW21wbHNdIE1peGluZyBJQ0MgYW5k IEdsb2JhbC1JRHMgaW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gQXMgb25lIG9mIHRoZSBjby1hdXRob3JzIG9u IHRoaXMgZHJhZnQsIEkgc3VwcG9ydCBhIHJlc3RyaWN0aW9uIHRvDQo+IHVzaW5nIGENCj4gY29t bW9uDQo+IGZvcm0gb2YgaWRlbnRpZmllciB0aHJvdWdob3V0IGFuIExTUCBvciBQVy4NCj4gDQo+ IEluIG15IG9waW5pb24sIGl0IGlzIGZhciBiZXR0ZXIgdG8gdGVybWluYXRlIExTUHMgb3IgUFdz IGF0IHRoZSBwb2ludA0KPiB3aGVyZQ0KPiB0aGVyZQ0KPiBtaWdodCBiZSBhbiBpZGVudGlmaWVy IGZvcm0gY2hhbmdlIGFuZCAic3RpdGNoIiB0aGVtIHRvZ2V0aGVyIGlmIHRoYXQNCj4gaXMgd2hh dA0KPiB0aGUNCj4gb3BlcmF0b3JzIHdhbnQvYWdyZWUgdG8gZG8uICBUaGlzIGxpbWl0cyB0aGUg bmVlZC10by1rbm93IGZvciB0aGUNCj4gbWFwcGluZyBvZg0KPiBvbmUNCj4gZm9ybSBvZiBpZGVu dGlmaWVyIHRvIHRoZSBvdGhlciB0byB0aGUgcG9pbnQgYXQgd2hpY2ggdGhpcyBvY2N1cnMsDQo+ IHJhdGhlciB0aGFuDQo+IGF0IGVhY2gNCj4gbm9kZSBpbiB0aGUgTFNQIG9yIChwb3RlbnRpYWxs eSkgTVMtUFcuDQo+IA0KPiANCj4gDQo+IA0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBHZW9yZ2UNCj4g U3dhbGxvdw0KPiBTZW50OiBNb25kYXksIEFwcmlsIDI1LCAyMDExIDU6MTcgUE0NCj4gVG86IG1w bHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMg aW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gDQo+IEFsbCAtDQo+IA0KPiBNYW55IG9mIHRoZSBj b21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBJVFUgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPiBp ZGVudGlmaWVycy0NCj4gMDQgaGF2ZSB0byBkbyB3aXRoIHRoZSBHbG9iYWwgYW5kIElDQyBpZGVu dGlmaWVycy4NCj4gDQo+IFRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQg TUVHIGluY2x1ZGUgZmllbGRzIHRvIGlkZW50aWZ5DQo+IGVhY2gNCj4gZW5kIG9mIGFuIExTUC4g IEN1cnJlbnRseSB0aGUgZHJhZnQgYWxsb3dzIGEgVHVubmVsLCBMU1AsIFBXLCBvciBNRUcgdG8N Cj4gdXNlDQo+IGVpdGhlciB0aGUgR2xvYmFsLUlEIGZvciBib3RoIGVuZHMgb3Igb3IgdGhlIElD QyBmb3IgYm90aCBlbmRzLiAgTWl4ZWQNCj4gdXNlIGlzDQo+IG5vdCBwZXJtaXR0ZWQuDQo+IA0K PiBUaGUgSVRVIGxpYWlzb24gcmVxdWVzdHMgdGhhdCB3ZSBhbGxvdyBtaXhlZCB1c2UuDQo+IA0K PiBUaGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQgYXJlIHZlcnkgcmVsdWN0YW50IHRvIGRvIHRoaXMu DQo+IA0KPiAxLiAgICAgICAgT2J0YWluaW5nIGFuIEFTIE51bWJlciAoZnJvbSB3aGljaCB0aGUg R2xvYmFsLUlEIGlzIGRlcml2ZWQpDQo+IGlzIGENCj4gZmFpcmx5IHRyaXZpYWwgcHJvY2VkdXJl LiAgTWFueSBvcmdhbml6YXRpb25zIGlmIG5vdCBtb3N0IGFscmVhZHkgaGF2ZQ0KPiBBUw0KPiBO dW1iZXJzLg0KPiAyLiAgICAgICAgU3VjaCBhbiBhZGRpdGlvbiB3aWxsIGFkZCBudW1lcm91cyBv YmplY3QgZm9ybWF0cywgYW5kIHRlc3QNCj4gY2FzZXMuDQo+IDMuICAgICAgICBUaGUgZXh0ZW50 IGludGVyLXByb3ZpZGVyIE1QTFMtVFAgaXMgYXMgeWV0IHVua25vd24uICBJZg0KPiBtaXhlZCBt b2Rlcw0KPiBvZiBJQ0MgYW5kIEdsb2JhbC1JRCBpZGVudGlmaWNhdGlvbiBpcyByZXF1aXJlZCwg dGhleSBjYW4gYmUgYWRkZWQNCj4gbGF0ZXIuDQo+IDQuICAgICAgICBGb3Igc2lnbmFsZWQgY29u bmVjdGlvbnMsIHRoZXJlIGlzIG5vIHBsYW4gdG8gYWxsb3cgcm91dGluZw0KPiBiYXNlZCBvbg0K PiBlaXRoZXIgdGhlIEdsb2JhbC1JRCBvciBJQ0MuICBUaGF0IHdvdWxkIGJlIGEgcmFkaWNhbCBj aGFuZ2UgdG8gaG93IElQDQo+IHdvcmtzLg0KPiBIb3dldmVyIGZvciBJUCByb3V0aW5nIHRvIHdv cmsgKGluIG9yZGVyIHRvIGZvcndhcmQgdGhlIHNpZ25hbGluZw0KPiBtZXNzYWdlcyksDQo+IHRo ZSBwcm92aWRlcnMgaW52b2x2ZWQgd2lsbCBuZWVkIHRvIHJ1biBCR1AgYW5kIGhhdmUgQVMgbnVt YmVycy4NCj4gDQo+IFdlIGFyZSBsb29raW5nIGZvciBpbnB1dC9jb25zZW5zdXMgZnJvbSB0aGUg V0cuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From jdrake@juniper.net Tue May 3 18:01: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 7F6B4E0752 for ; Tue, 3 May 2011 18:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 h896kOg-a8Mc for ; Tue, 3 May 2011 18:01:34 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5C726E0618 for ; Tue, 3 May 2011 18:01:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTcClaHTzaaTeJYDLoJ7RQxVFsAmyDl8z@postini.com; Tue, 03 May 2011 18:01:33 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; Tue, 3 May 2011 18:00:39 -0700 From: John E Drake To: Sriganesh Kini Date: Tue, 3 May 2011 18:00:37 -0700 Thread-Topic: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: AcwJLCDo3UAeyuTgR/SrcaMjdf1+6AAyf2yQ Message-ID: <5E893DB832F57341992548CDBB333163A097C198BC@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0978A0555@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , "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: Wed, 04 May 2011 01:01:34 -0000 Sri, This is related to a comment that Shane made; viz, the term 'LSR' is used c= onsistently throughout the document instead of the correct term 'LER'. An = ingress LER is by definition the node that places the MPLS header on given = packet and it is the one that places the Entropy Label in the MPLS header. Thanks, John =20 Sent from my iPhone > -----Original Message----- > From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On > Behalf Of Sriganesh Kini > Sent: Monday, May 02, 2011 5:50 PM > To: John E Drake > Cc: Ross Callon; mpls@ietf.org > Subject: Re: [mpls] Comments - Re: poll on draft-kompella-mpls-entropy- > label as MPLS WG document >=20 > inline >=20 > On Thu, Apr 28, 2011 at 3:38 PM, John E Drake > wrote: > > > > > > 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 > >> > >> Hi Kireeti and other authors, > >> > >> Need a couple clarification > >> 1. This draft seems to apply to the TE LSP (or transport LSP) =A0for > 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: =A0You mean figure 7|8 in section 3.4.5? =A0But yes, entropy labels > apply to 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: =A0It's always bottom of stack, so if it is present, it was placed > there by the client. >=20 > Ok. Since the EL has to be placed by the client, but cannot be placed > by the ingress LSR of the Transport LSP (when the packet received from > the CE is MPLS), it may be useful to state this explicitly in section > 3 para that starts with "EL labels are generated by the ingress LSR > <> ..." >=20 >=20 > > > >> > >> 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 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > -- > - Sri From jdrake@juniper.net Tue May 3 18:43: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 4377FE0772 for ; Tue, 3 May 2011 18:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 eulag5aO2tZz for ; Tue, 3 May 2011 18:43:33 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 11DBDE0723 for ; Tue, 3 May 2011 18:43:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTcCvPYWk1CMkF/z08GiD3JBUPzpnmdsE@postini.com; Tue, 03 May 2011 18:43:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 May 2011 18:41:55 -0700 From: John E Drake To: David Allan I , "erminio.ottone_69@libero.it" , "mpls@ietf.org" Date: Tue, 3 May 2011 18:41:54 -0700 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwJE4MjlaRZg1reSDSGAJiRuo7fpQAySMNgAAd12AA= Message-ID: <5E893DB832F57341992548CDBB333163A097C198FA@EMBX01-HQ.jnpr.net> References: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> <60C093A41B5E45409A19D42CF7786DFD521B0E5409@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521B0E5409@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jeff Haas , David Ward Subject: Re: [mpls] I: 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, 04 May 2011 01:43:34 -0000 Hi, According to RFC 5880, if a node does not receive a Final in response to a = Poll, it continues to use the current BFD session parameters and MAY send a= dditional Polls (presumably one per second) in hopes of soliciting a Final.= I don't think we need to say anything more about what the sender of a Pol= l needs to do. We need Poll/Final to transition to UP state, so I think what cc-cv-rdi nee= ds to say is that a node which does not support Poll/Final in UP state simp= ly ignores a Poll. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Tuesday, May 03, 2011 3:01 PM > To: erminio.ottone_69@libero.it; mpls@ietf.org > Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >=20 > Hi Ermino: >=20 > I stand corrected. I got lots of private feedback to the effect that > current implementations see a "final" response as agreement to the > parameters in a poll. Hence changing that semantic is not a good idea. >=20 > The alternative discussed was what an implementation does when a poll > is not responded to in a resonable amount of time, which can be > interpreted as a refusal to change by the far end, or non- > implementation of P/F in steady state. At which point an implemention's > options are to live with the status quo or take the session down. >=20 > Feedback welcome! > Dave >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: Monday, May 02, 2011 2:54 PM > To: mpls@ietf.org > Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >=20 > Forwarding the messate to the MPLS WG mailing list ... >=20 > >----Messaggio originale---- > >Da: erminio.ottone_69@libero.it > >Data: 2-mag-2011 23.19 > >A: > >Ogg: R: [mpls] FW: Poll / Final in 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. > > > >How this is possible? > > > >Section 6.8.7 of RFC 5880 states that: > > > > With the exceptions listed in the remainder of this section, a > system > > MUST NOT transmit BFD Control packets at an interval less than the > > larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, > less > > applied jitter (see below). > > > >If the Poll requires a longer bfd.RemoteMinRxInterval, how can the > >system ignore the request? > > > >>----Messaggio originale---- > >>Da: david.i.allan@ericsson.com > >>Data: 20-apr-2011 17.29 > >>A: "mpls@ietf.org" > >>Cc: "Ross Callon" > >>Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi > >> > >>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... > >> > >> > >>_______________________________________________ > >>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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From malcolm.betts@zte.com.cn Tue May 3 22:45: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 96792E06E6; Tue, 3 May 2011 22:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.338 X-Spam-Level: X-Spam-Status: No, score=-101.338 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 Xo+X-n37S+hK; Tue, 3 May 2011 22:45:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 495EDE06FF; Tue, 3 May 2011 22:45:24 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201784411434; Wed, 4 May 2011 13:43:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 37601.6075855291; Wed, 4 May 2011 13:33:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p445jGWs035181; Wed, 4 May 2011 13:45:16 +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, 4 May 2011 01:44:49 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-04 13:45:18, Serialize complete at 2011-05-04 13:45:18 Content-Type: multipart/alternative; boundary="=_alternative 001F968285257886_=" X-MAIL: mse01.zte.com.cn p445jGWs035181 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, 04 May 2011 05:45:27 -0000 This is a multipart message in MIME format. --=_alternative 001F968285257886_= Content-Type: text/plain; charset="US-ASCII" All, I share your concerns and doubts about a multi carrier control plane. However, I think that it is essential that a transport network supports multi carrier data plane interconnection with end to end OAM. In today's transport network this interconnection is supported by SDH and OTN. The objective for MPLS-TP is to allow for packet based interconnection as well. Regards, Malcolm George Swallow Sent by: mpls-bounces@ietf.org 03/05/2011 11:09 AM To "Andrew G. Malis" , cc mpls@ietf.org Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Andy - > Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. You are quite correct here! I think much of this debate surrounds a problem that is yet to be solved. So there are arguments for pieces of a solution without and overall architecture. Based on all that I am seeing my inclination is to NOT say that we disallow mixed identifiers, but to say that they are for future study. ...George On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > Neil, > > To your case 1, we're in complete agreement. We (VZ) don't see at > least a short-term need for peer-layer interworking, given where we > intend to deploy MPLS-TP in our infrastructure (as an internal server > layer in the transport core). If peer layer interworking ever becomes > a necessity, then obviously we'll need a well-defined E-NNI which > would include LSP identifier mapping/translation at the boundary, for > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. > > I also agree that both intra-layer and inter-layer mis-connectivity > detection and amelioration are required, but I'm not convinced that > the already defined mechanisms can't do that. Do you have some > specific analysis on the inter-layer case? > > Cheers, > Andy > > On Tue, May 3, 2011 at 3:36 AM, wrote: >> Hi Andy, >> >> 2 points: >> >> 1 I agree with your view of only having a single addressing scheme in a >> single layer network solely belonging to one party. Though you may need to >> be rather careful if you also advocate that one can also have peer layer >> interworking between different parties, ie E-NNIs (I believe this is >> something you may support, eg old MPLSF case?). In such a peer interworking >> case it would seem one must allow different addressing schemes (and indeed >> any other variations in DP/CP functional components) if they exist in the >> standards. >> >> Of course, having an E-NNI and peer interworking between different parties in >> any non-TOS layer network (not just MPLS) is not technically necessary (this >> is trivial to prove), and this provides a strong argument for only having a >> single addressing scheme in a non-TOS layer network. >> >> >> 2 You should also be aware that in client/server interworking of the >> co-ps mode using variable size traffic units, and therefore something rather >> important for MPLS-TP in the role of a transport network (I'll ignore issues >> of transparency here), there could be inter-layer misconnectivity (Aside=> >> This case cannot occur in the co-cs mode). To date, however, we have only >> really considered intra-layer misconnectivity, ie between different LSPs >> belonging to the same party (note this also includes all cases of nested LSP >> sublayer misconnectivity). >> >> In the case of inter-layer misconnectivity one may receive traffic units and >> OAM messages from some other party's layer network. The OAM messages may >> come from (i) networks using different OAM/addressing solutions or (ii) >> networks using the same OAM/addressing solutions. In both cases there are >> different issues wrt inter-layer misconnectivity one has to deal with. I'm >> not aware that these cases have been considered yet. >> >> >> I'd like to hear your comments on both these points, but in particular the >> first one.....especially if you also support the notion of E-NNIs in MPLS-TP, >> as there seems to a possible logical conflict here. >> >> Thanks. >> >> regards, 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. >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no: 1800000 >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Andrew G. Malis >>> Sent: 02 May 2011 20:48 >>> To: George Swallow >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> >>> George et al, >>> >>> Verizon does not have any requirement for mixed use of Global IDs and >>> ICCs. We are fine with specifications that require both ends of an LSP >>> to use one or the other. >>> >>> Thanks, >>> Andy >>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>> wrote: >>>> 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. >>>> >>>> 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. >>>> >>>> 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 >> _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 001F968285257886_= Content-Type: text/html; charset="US-ASCII"
All,

I share your concerns and doubts about a multi carrier control plane. However, I think that it is essential that a transport network supports multi carrier data plane interconnection with end to end OAM.  In today's transport network this interconnection is supported by SDH and OTN.  The objective for MPLS-TP is to allow for packet based interconnection as well.

Regards,

Malcolm
   


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

03/05/2011 11:09 AM

To
"Andrew G. Malis" <agmalis@gmail.com>, <neil.2.harrison@bt.com>
cc
mpls@ietf.org
Subject
Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





Andy -

> Such
> an E-NNI definition does not yet exist for MPLS-TP (something else to
> put on the to-do list). This E-NNI would also include similar
> identifier mapping/translation for MS-PWs, to answer an earlier
> question from Erminio that I saw on the list.

You are quite correct here!  I think much of this debate surrounds a problem
that is yet to be solved.  So there are arguments for pieces of a solution
without and overall architecture.

Based on all that I am seeing my inclination is to NOT say that we disallow
mixed identifiers, but to say that they are for future study.

...George





On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis@gmail.com> wrote:

> Neil,
>
> To your case 1, we're in complete agreement. We (VZ) don't see at
> least a short-term need for peer-layer interworking, given where we
> intend to deploy MPLS-TP in our infrastructure (as an internal server
> layer in the transport core). If peer layer interworking ever becomes
> a necessity, then obviously we'll need a well-defined E-NNI which
> would include LSP identifier mapping/translation at the boundary, for
> LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> an E-NNI definition does not yet exist for MPLS-TP (something else to
> put on the to-do list). This E-NNI would also include similar
> identifier mapping/translation for MS-PWs, to answer an earlier
> question from Erminio that I saw on the list.
>
> I also agree that both intra-layer and inter-layer mis-connectivity
> detection and amelioration are required, but I'm not convinced that
> the already defined mechanisms can't do that. Do you have some
> specific analysis on the inter-layer case?
>
> Cheers,
> Andy
>
> On Tue, May 3, 2011 at 3:36 AM,  <neil.2.harrison@bt.com> wrote:
>> Hi Andy,
>>
>> 2 points:
>>
>> 1       I agree with your view of only having a single addressing scheme in a
>> single layer network solely belonging to one party.  Though you may need to
>> be rather careful if you also advocate that one can also have peer layer
>> interworking between different parties, ie E-NNIs (I believe this is
>> something you may support, eg old MPLSF case?).  In such a peer interworking
>> case it would seem one must allow different addressing schemes (and indeed
>> any other variations in DP/CP functional components) if they exist in the
>> standards.
>>
>> Of course, having an E-NNI and peer interworking between different parties in
>> any non-TOS layer network (not just MPLS) is not technically necessary (this
>> is trivial to prove), and this provides a strong argument for only having a
>> single addressing scheme in a non-TOS layer network.
>>
>>
>> 2       You should also be aware that in client/server interworking of the
>> co-ps mode using variable size traffic units, and therefore something rather
>> important for MPLS-TP in the role of a transport network (I'll ignore issues
>> of transparency here), there could be inter-layer misconnectivity (Aside=>
>> This case cannot occur in the co-cs mode).  To date, however, we have only
>> really considered intra-layer misconnectivity, ie between different LSPs
>> belonging to the same party (note this also includes all cases of nested LSP
>> sublayer misconnectivity).
>>
>> In the case of inter-layer misconnectivity one may receive traffic units and
>> OAM messages from some other party's layer network.  The OAM messages may
>> come from (i) networks using different OAM/addressing solutions or (ii)
>> networks using the same OAM/addressing solutions.  In both cases there are
>> different issues wrt inter-layer misconnectivity one has to deal with.  I'm
>> not aware that these cases have been considered yet.
>>
>>
>> I'd like to hear your comments on both these points, but in particular the
>> first one.....especially if you also support the notion of E-NNIs in MPLS-TP,
>> as there seems to a possible logical conflict here.
>>
>> Thanks.
>>
>> regards, 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.
>> British Telecommunications plc
>> Registered office: 81 Newgate Street London EC1A 7AJ
>> Registered in England no: 1800000
>>
>>> -----Original Message-----
>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>>> Andrew G. Malis
>>> Sent: 02 May 2011 20:48
>>> To: George Swallow
>>> Cc: mpls@ietf.org
>>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>>
>>> George et al,
>>>
>>> Verizon does not have any requirement for mixed use of Global IDs and
>>> ICCs. We are fine with specifications that require both ends of an LSP
>>> to use one or the other.
>>>
>>> Thanks,
>>> Andy
>>>
>>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow@cisco.com>
>>> wrote:
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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
>>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 001F968285257886_=-- From loa@pi.nu Tue May 3 23:00: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 00643E06F1 for ; Tue, 3 May 2011 23:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 DWvYS8pkA5f5 for ; Tue, 3 May 2011 23:00:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 94745E06E6 for ; Tue, 3 May 2011 23:00:31 -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 10E092A8001; Wed, 4 May 2011 08:00:28 +0200 (CEST) Message-ID: <4DC0EB7A.4000606@pi.nu> Date: Tue, 03 May 2011 23:00:26 -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, "Malcolm.BETTS@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:00:35 -0000 Malcolm, are you saying that operators today allow OAM to control node (MIPs and MEPs) on each others networks? Do we have an operator that can verify this? /Loa On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > > All, > > I share your concerns and doubts about a multi carrier control plane. > However, I think that it is essential that a transport network supports > multi carrier data plane interconnection with end to end OAM. In today's > transport network this interconnection is supported by SDH and OTN. The > objective for MPLS-TP is to allow for packet based interconnection as well. > > Regards, > > Malcolm > > > > *George Swallow * > Sent by: mpls-bounces@ietf.org > > 03/05/2011 11:09 AM > > > To > "Andrew G. Malis" , > cc > mpls@ietf.org > Subject > Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > > > > > Andy - > > > Such > > an E-NNI definition does not yet exist for MPLS-TP (something else to > > put on the to-do list). This E-NNI would also include similar > > identifier mapping/translation for MS-PWs, to answer an earlier > > question from Erminio that I saw on the list. > > You are quite correct here! I think much of this debate surrounds a problem > that is yet to be solved. So there are arguments for pieces of a solution > without and overall architecture. > > Based on all that I am seeing my inclination is to NOT say that we disallow > mixed identifiers, but to say that they are for future study. > > ...George > > > > > > On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > > > Neil, > > > > To your case 1, we're in complete agreement. We (VZ) don't see at > > least a short-term need for peer-layer interworking, given where we > > intend to deploy MPLS-TP in our infrastructure (as an internal server > > layer in the transport core). If peer layer interworking ever becomes > > a necessity, then obviously we'll need a well-defined E-NNI which > > would include LSP identifier mapping/translation at the boundary, for > > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > > an E-NNI definition does not yet exist for MPLS-TP (something else to > > put on the to-do list). This E-NNI would also include similar > > identifier mapping/translation for MS-PWs, to answer an earlier > > question from Erminio that I saw on the list. > > > > I also agree that both intra-layer and inter-layer mis-connectivity > > detection and amelioration are required, but I'm not convinced that > > the already defined mechanisms can't do that. Do you have some > > specific analysis on the inter-layer case? > > > > Cheers, > > Andy > > > > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> Hi Andy, > >> > >> 2 points: > >> > >> 1 I agree with your view of only having a single addressing scheme in a > >> single layer network solely belonging to one party. Though you may > need to > >> be rather careful if you also advocate that one can also have peer layer > >> interworking between different parties, ie E-NNIs (I believe this is > >> something you may support, eg old MPLSF case?). In such a peer > interworking > >> case it would seem one must allow different addressing schemes (and > indeed > >> any other variations in DP/CP functional components) if they exist > in the > >> standards. > >> > >> Of course, having an E-NNI and peer interworking between different > parties in > >> any non-TOS layer network (not just MPLS) is not technically > necessary (this > >> is trivial to prove), and this provides a strong argument for only > having a > >> single addressing scheme in a non-TOS layer network. > >> > >> > >> 2 You should also be aware that in client/server interworking of the > >> co-ps mode using variable size traffic units, and therefore > something rather > >> important for MPLS-TP in the role of a transport network (I'll > ignore issues > >> of transparency here), there could be inter-layer misconnectivity > (Aside=> > >> This case cannot occur in the co-cs mode). To date, however, we have > only > >> really considered intra-layer misconnectivity, ie between different LSPs > >> belonging to the same party (note this also includes all cases of > nested LSP > >> sublayer misconnectivity). > >> > >> In the case of inter-layer misconnectivity one may receive traffic > units and > >> OAM messages from some other party's layer network. The OAM messages may > >> come from (i) networks using different OAM/addressing solutions or (ii) > >> networks using the same OAM/addressing solutions. In both cases > there are > >> different issues wrt inter-layer misconnectivity one has to deal > with. I'm > >> not aware that these cases have been considered yet. > >> > >> > >> I'd like to hear your comments on both these points, but in > particular the > >> first one.....especially if you also support the notion of E-NNIs in > MPLS-TP, > >> as there seems to a possible logical conflict here. > >> > >> Thanks. > >> > >> regards, 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. > >> British Telecommunications plc > >> Registered office: 81 Newgate Street London EC1A 7AJ > >> Registered in England no: 1800000 > >> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >>> Andrew G. Malis > >>> Sent: 02 May 2011 20:48 > >>> To: George Swallow > >>> Cc: mpls@ietf.org > >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >>> > >>> George et al, > >>> > >>> Verizon does not have any requirement for mixed use of Global IDs and > >>> ICCs. We are fine with specifications that require both ends of an LSP > >>> to use one or the other. > >>> > >>> Thanks, > >>> Andy > >>> > >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >>> wrote: > >>>> 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. > >>>> > >>>> 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. > >>>> > >>>> 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 > >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From maarten.vissers@huawei.com Tue May 3 23:45:46 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 DA8DAE0707 for ; Tue, 3 May 2011 23:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 amiVDpdz2-9s for ; Tue, 3 May 2011 23:45:44 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 369C2E068C for ; Tue, 3 May 2011 23:45:44 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00KJVS3ZYO@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 04 May 2011 07:45:36 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LKN004P8S3ZIW@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 04 May 2011 07:45:35 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 04 May 2011 07:45:27 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 04 May 2011 07:45:34 +0100 Date: Wed, 04 May 2011 06:45:33 +0000 From: Maarten vissers In-reply-to: <4DC0EB7A.4000606@pi.nu> X-Originating-IP: [10.200.218.48] To: Loa Andersson , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gFa20YAABi5kYAACo2VgAAFRXOAAB6Sr4AAAIugAAACXPQQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DC0EB7A.4000606@pi.nu> 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, 04 May 2011 06:45:47 -0000 Loa, The connections in the "Transport Service" layers can be multi-operator connections. Examples are the SDH Transport Service layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, ..), ATM Transport Service layer connections (ATM VCs), OTN Transport Service layer connections (LO ODUs), Ethernet Transport Service layer connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport Service layer connections (MS-PW, Service-LSP). These Transport Service layer connections are monitored using pro-active OAM and on-demand OAM between the Service Provider MEG level MEP functions on the UNI-N ports and Service Provider MEG level MIP functions on the E-NNI/IrDI ports. In a multi-operator connection these Service Provider MEG level MEP functions on the UNI-N ports will be located in different operator domains. Also the Service Provider MEG level MIP functions on the E-NNI/IrDI ports will be located in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID MPLS-TP identifiers, then you will have a mixed case. We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. If the answer is "no" then mixed identifier usage will not be a requirement. If the application for MPLS-TP is within an MEF Ethernet Services architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason is that in the MEF architecture the E-NNI/IrDI is defined as an Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. - MPLS-TP Transport Service layer may not be present at all in such MEF Ethernet Services architecture, only the MPLS-TP Transport Path layer could be used (to carry PW-labelled Ethernet Connections) and those MPLS-TP Transport Path connections terminate in the operator domain's edge node (i.e. single operator connections). - For the case a MPLS-TP Transport Service layer is used in an MEF Ethernet Services architecture the MPLS-TP Transport Service connections will be terminated in the operator domain's edge node (i.e. single operator connections). ------ MPLS-TP Transport Path layer connections (transport-LSPs) are connecting a PE with an adjacent PE (via zero or more P nodes). Those transport-LSPs do not cross an E-NNI/IrDI. There is however one exception... when a group of Transport Service layer connections has to be sent from one domain via a second domain to a third domain, this is typically done via a Transport Path layer connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. Domain treats this domain 1-3 transport path layer connection as a transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 may use different identifiers (ICC, Global-ID) and a mixed case is present. If domains 1 and 3 use the same identifier type, then domain 2 may be using a different identifier type in the MIPs on its E-NNI/IrDI ports. ------ MPLS-TP Section layer connections are connecting adjacent MPLS-TP nodes. In 99.9% of the cases those nodes are in one operator domain. For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID based MPLS-TP identifiers there is a mixed case. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: 4 May 2011 08:00 > To: mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Malcolm, > > are you saying that operators today allow OAM to control node (MIPs and > MEPs) on each others networks? > > Do we have an operator that can verify this? > > /Loa > > On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > > > > All, > > > > I share your concerns and doubts about a multi carrier control plane. > > However, I think that it is essential that a transport network > supports > > multi carrier data plane interconnection with end to end OAM. In > today's > > transport network this interconnection is supported by SDH and OTN. > The > > objective for MPLS-TP is to allow for packet based interconnection as > well. > > > > Regards, > > > > Malcolm > > > > > > > > *George Swallow * > > Sent by: mpls-bounces@ietf.org > > > > 03/05/2011 11:09 AM > > > > > > To > > "Andrew G. Malis" , > > cc > > mpls@ietf.org > > Subject > > Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > > > > > > > > > > > > > > Andy - > > > > > Such > > > an E-NNI definition does not yet exist for MPLS-TP (something else > to > > > put on the to-do list). This E-NNI would also include similar > > > identifier mapping/translation for MS-PWs, to answer an earlier > > > question from Erminio that I saw on the list. > > > > You are quite correct here! I think much of this debate surrounds a > problem > > that is yet to be solved. So there are arguments for pieces of a > solution > > without and overall architecture. > > > > Based on all that I am seeing my inclination is to NOT say that we > disallow > > mixed identifiers, but to say that they are for future study. > > > > ...George > > > > > > > > > > > > On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > > > > > Neil, > > > > > > To your case 1, we're in complete agreement. We (VZ) don't see at > > > least a short-term need for peer-layer interworking, given where > we > > > intend to deploy MPLS-TP in our infrastructure (as an internal > server > > > layer in the transport core). If peer layer interworking ever > becomes > > > a necessity, then obviously we'll need a well-defined E-NNI which > > > would include LSP identifier mapping/translation at the boundary, > for > > > LSP provisioning (whether static or dynamic) and end-to-end OAM. > Such > > > an E-NNI definition does not yet exist for MPLS-TP (something else > to > > > put on the to-do list). This E-NNI would also include similar > > > identifier mapping/translation for MS-PWs, to answer an earlier > > > question from Erminio that I saw on the list. > > > > > > I also agree that both intra-layer and inter-layer mis- > connectivity > > > detection and amelioration are required, but I'm not convinced > that > > > the already defined mechanisms can't do that. Do you have some > > > specific analysis on the inter-layer case? > > > > > > Cheers, > > > Andy > > > > > > On Tue, May 3, 2011 at 3:36 AM, wrote: > > >> Hi Andy, > > >> > > >> 2 points: > > >> > > >> 1 I agree with your view of only having a single addressing > scheme in a > > >> single layer network solely belonging to one party. Though you > may > > need to > > >> be rather careful if you also advocate that one can also have > peer layer > > >> interworking between different parties, ie E-NNIs (I believe this > is > > >> something you may support, eg old MPLSF case?). In such a peer > > interworking > > >> case it would seem one must allow different addressing schemes > (and > > indeed > > >> any other variations in DP/CP functional components) if they > exist > > in the > > >> standards. > > >> > > >> Of course, having an E-NNI and peer interworking between > different > > parties in > > >> any non-TOS layer network (not just MPLS) is not technically > > necessary (this > > >> is trivial to prove), and this provides a strong argument for > only > > having a > > >> single addressing scheme in a non-TOS layer network. > > >> > > >> > > >> 2 You should also be aware that in client/server interworking of > the > > >> co-ps mode using variable size traffic units, and therefore > > something rather > > >> important for MPLS-TP in the role of a transport network (I'll > > ignore issues > > >> of transparency here), there could be inter-layer misconnectivity > > (Aside=> > > >> This case cannot occur in the co-cs mode). To date, however, we > have > > only > > >> really considered intra-layer misconnectivity, ie between > different LSPs > > >> belonging to the same party (note this also includes all cases of > > nested LSP > > >> sublayer misconnectivity). > > >> > > >> In the case of inter-layer misconnectivity one may receive > traffic > > units and > > >> OAM messages from some other party's layer network. The OAM > messages may > > >> come from (i) networks using different OAM/addressing solutions > or (ii) > > >> networks using the same OAM/addressing solutions. In both cases > > there are > > >> different issues wrt inter-layer misconnectivity one has to deal > > with. I'm > > >> not aware that these cases have been considered yet. > > >> > > >> > > >> I'd like to hear your comments on both these points, but in > > particular the > > >> first one.....especially if you also support the notion of E-NNIs > in > > MPLS-TP, > > >> as there seems to a possible logical conflict here. > > >> > > >> Thanks. > > >> > > >> regards, 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. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ > > >> Registered in England no: 1800000 > > >> > > >>> -----Original Message----- > > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > > >>> Andrew G. Malis > > >>> Sent: 02 May 2011 20:48 > > >>> To: George Swallow > > >>> Cc: mpls@ietf.org > > >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > >>> > > >>> George et al, > > >>> > > >>> Verizon does not have any requirement for mixed use of Global > IDs and > > >>> ICCs. We are fine with specifications that require both ends of > an LSP > > >>> to use one or the other. > > >>> > > >>> Thanks, > > >>> Andy > > >>> > > >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > > > >>> wrote: > > >>>> 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. > > >>>> > > >>>> 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. > > >>>> > > >>>> 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 > > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: loa.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 maarten.vissers@huawei.com Wed May 4 00:03: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 0B9D0E075B for ; Wed, 4 May 2011 00:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 PXMzEW55-mfy for ; Wed, 4 May 2011 00:03:10 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 68841E075D for ; Wed, 4 May 2011 00:03:10 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00KVPSX9YO@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 04 May 2011 08:03:09 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LKN004DESX8IW@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 04 May 2011 08:03:08 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 04 May 2011 08:03:02 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 04 May 2011 08:03:08 +0100 Date: Wed, 04 May 2011 07:03:07 +0000 From: Maarten vissers In-reply-to: X-Originating-IP: [10.200.218.48] To: George Swallow , "Andrew G. Malis" , "neil.2.harrison@bt.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-GB, en-US Thread-topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gFa20YAABi5kYAACo2VgAAFRXOAACMaf9A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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, 04 May 2011 07:03:12 -0000 George, > Based on all that I am seeing my inclination is to NOT say that we > disallow mixed identifiers, but to say that they are for future study. Transport networks are multi-operator networks and this requires that trans= port network technology developments must support multi-operator networks. = The MPLS-TP architecture and OAM include capabilities to support such multi= -operator networks and associated multi-operator connections at MPLS-TP tra= nsport service, transport path and section layers. With the support of multiple identifier schemes and the support of multi-op= erator connections, we have to describe and support the mixed identifier ca= ses. Only if we remove from the MPLS_TP architecture and OAM architecture t= he support for multi-operator networks we can treat mixed identifier cases = as a for further study item. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > George Swallow > Sent: 3 May 2011 17:09 > To: Andrew G. Malis; neil.2.harrison@bt.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Andy - >=20 > > Such > > an E-NNI definition does not yet exist for MPLS-TP (something else to > > put on the to-do list). This E-NNI would also include similar > > identifier mapping/translation for MS-PWs, to answer an earlier > > question from Erminio that I saw on the list. >=20 > You are quite correct here! I think much of this debate surrounds a > problem > that is yet to be solved. So there are arguments for pieces of a > solution > without and overall architecture. >=20 > Based on all that I am seeing my inclination is to NOT say that we > disallow > mixed identifiers, but to say that they are for future study. >=20 > ...George >=20 >=20 >=20 >=20 >=20 > On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >=20 > > Neil, > > > > To your case 1, we're in complete agreement. We (VZ) don't see at > > least a short-term need for peer-layer interworking, given where we > > intend to deploy MPLS-TP in our infrastructure (as an internal server > > layer in the transport core). If peer layer interworking ever becomes > > a necessity, then obviously we'll need a well-defined E-NNI which > > would include LSP identifier mapping/translation at the boundary, for > > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > > an E-NNI definition does not yet exist for MPLS-TP (something else to > > put on the to-do list). This E-NNI would also include similar > > identifier mapping/translation for MS-PWs, to answer an earlier > > question from Erminio that I saw on the list. > > > > I also agree that both intra-layer and inter-layer mis-connectivity > > detection and amelioration are required, but I'm not convinced that > > the already defined mechanisms can't do that. Do you have some > > specific analysis on the inter-layer case? > > > > Cheers, > > Andy > > > > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> Hi Andy, > >> > >> 2 points: > >> > >> 1 =A0 =A0 =A0 I agree with your view of only having a single addressin= g > scheme in a > >> single layer network solely belonging to one party. =A0Though you may > need to > >> be rather careful if you also advocate that one can also have peer > layer > >> interworking between different parties, ie E-NNIs (I believe this is > >> something you may support, eg old MPLSF case?). =A0In such a peer > interworking > >> case it would seem one must allow different addressing schemes (and > indeed > >> any other variations in DP/CP functional components) if they exist > in the > >> standards. > >> > >> Of course, having an E-NNI and peer interworking between different > parties in > >> any non-TOS layer network (not just MPLS) is not technically > necessary (this > >> is trivial to prove), and this provides a strong argument for only > having a > >> single addressing scheme in a non-TOS layer network. > >> > >> > >> 2 =A0 =A0 =A0 You should also be aware that in client/server interwork= ing > of the > >> co-ps mode using variable size traffic units, and therefore > something rather > >> important for MPLS-TP in the role of a transport network (I'll > ignore issues > >> of transparency here), there could be inter-layer misconnectivity > (Aside=3D> > >> This case cannot occur in the co-cs mode). =A0To date, however, we > have only > >> really considered intra-layer misconnectivity, ie between different > LSPs > >> belonging to the same party (note this also includes all cases of > nested LSP > >> sublayer misconnectivity). > >> > >> In the case of inter-layer misconnectivity one may receive traffic > units and > >> OAM messages from some other party's layer network. =A0The OAM > messages may > >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> networks using the same OAM/addressing solutions. =A0In both cases > there are > >> different issues wrt inter-layer misconnectivity one has to deal > with. =A0I'm > >> not aware that these cases have been considered yet. > >> > >> > >> I'd like to hear your comments on both these points, but in > particular the > >> first one.....especially if you also support the notion of E-NNIs in > MPLS-TP, > >> as there seems to a possible logical conflict here. > >> > >> Thanks. > >> > >> regards, 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. > >> British Telecommunications plc > >> Registered office: 81 Newgate Street London EC1A 7AJ > >> Registered in England no: 1800000 > >> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > >>> Andrew G. Malis > >>> Sent: 02 May 2011 20:48 > >>> To: George Swallow > >>> Cc: mpls@ietf.org > >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > >>> > >>> George et al, > >>> > >>> Verizon does not have any requirement for mixed use of Global IDs > and > >>> ICCs. We are fine with specifications that require both ends of an > LSP > >>> to use one or the other. > >>> > >>> Thanks, > >>> Andy > >>> > >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >>> wrote: > >>>> 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. =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. > >>>> > >>>> Obtaining an AS Number (from which the Global-ID is derived) is a > >>> fairly > >>>> trivial procedure. =A0Many 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. =A0If 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. =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 > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From neil.2.harrison@bt.com Wed May 4 00:21: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 38FC3E0736; Wed, 4 May 2011 00:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=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 oxeRRjoTJ6LG; Wed, 4 May 2011 00:21:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 41A26E0709; Wed, 4 May 2011 00:21:14 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 4 May 2011 08:21:13 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.191]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 4 May 2011 08:21:13 +0100 From: To: , Date: Wed, 4 May 2011 08:21:10 +0100 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwKHn9QfSaAsCJ0RFOEcNUqCO5wOAACDsTQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44022F3053D@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, 04 May 2011 07:21:17 -0000 Thanks Malcolm, I think we need to careful and precise as some folks could be confused by w= hat you wrote unless they have a proper model in their head of what is real= ly needed here. I am sure you understand it Malcolm but I am not sure ever= yone else does. So let me try and step through this.... In all networking scenarios there is always: - a TOS layer network present that interfaces with external message/file/st= ream applications...this is the whole point of *all* networking, including = providing lower layer transport networks - a BOS layer network present that modulates an EM wave on either metallic/= optical/radio media...this is how we ultimately send the information genera= ted by the TOS external interfacing message/file/stream applications over l= arge geographic distance. We do not simply connect any non-TOS layer networks together on their own '= just for the fun of it' ....they MUST ultimately support a TOS layer networ= k and external message/file/stream applications as I noted in the 1st bulle= t above. It seems to me some folks working on transport networks somehow f= orget this crucial point and only think about their lower layer network....= .and this is what can generate lots of unnecessary work and confusion IMO. Now we have to connect all layer networks together at the BOS....that is ju= st a physical fact. However, this does not mean we have an E-NNI here. A= nd I am sure this is why you were careful to differentiate interconnecting = the CP and DP cases Malcolm in your mail below. However there is a little = more to it than just this observation of the facts..... At a lower transport layer network level we cannot (and indeed must not) tr= y and judge the importance of the ultimate TOS message/file/stream applicat= ions. And even more generally we must not try and 'guess/assume' what high= er layer client symbols mean.....the client can change the alphabet and/or = semantics of its symbols and/or encrypt the symbols. All we should be doin= g in transport networks is to treat the conveyance of each client symbol eq= ually....and ultimately this means shipping bits in order (a bit is the ato= mic information unit - see Shannon). If you look at all co-cs mode transpo= rt networks today this is exactly what they do. And this is what is meant = by transparency. So I hope this now clarifies the difference between a BOS physical intercon= nection and what E-NNIs are....proper E-NNIs only apply to TOS layer networ= ks and we should not get carried away with elaborate specification of BOS i= nterconnections...THE key requirement here is transparency. Aside=3D> Ther= e is a whole bunch of stuff that could now follow on how QoS (at least how = some folks think of QoS) is not relevant to transport networks.....another = day maybe. regards, Neil 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 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]=20 Sent: 04 May 2011 06:45 To: George Swallow Cc: Andrew G. Malis; mpls@ietf.org; mpls-bounces@ietf.org; Harrison,N,Neil,= DKQ7 R Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? All,=20 I share your concerns and doubts about a multi carrier control plane. Howev= er, I think that it is essential that a transport network supports multi ca= rrier data plane interconnection with end to end OAM. =A0In today's transpo= rt network this interconnection is supported by SDH and OTN. =A0The objecti= ve for MPLS-TP is to allow for packet based interconnection as well.=20 Regards,=20 Malcolm=20 =A0 =A0=20 George Swallow =20 Sent by: mpls-bounces@ietf.org=20 03/05/2011 11:09 AM=20 To "Andrew G. Malis" , =20 cc mpls@ietf.org=20 Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Andy - > Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. You are quite correct here! =A0I think much of this debate surrounds a prob= lem that is yet to be solved. =A0So there are arguments for pieces of a solutio= n without and overall architecture. Based on all that I am seeing my inclination is to NOT say that we disallow mixed identifiers, but to say that they are for future study. ...George On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > Neil, >=20 > To your case 1, we're in complete agreement. We (VZ) don't see at > least a short-term need for peer-layer interworking, given where we > intend to deploy MPLS-TP in our infrastructure (as an internal server > layer in the transport core). If peer layer interworking ever becomes > a necessity, then obviously we'll need a well-defined E-NNI which > would include LSP identifier mapping/translation at the boundary, for > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > an E-NNI definition does not yet exist for MPLS-TP (something else to > put on the to-do list). This E-NNI would also include similar > identifier mapping/translation for MS-PWs, to answer an earlier > question from Erminio that I saw on the list. >=20 > I also agree that both intra-layer and inter-layer mis-connectivity > detection and amelioration are required, but I'm not convinced that > the already defined mechanisms can't do that. Do you have some > specific analysis on the inter-layer case? >=20 > Cheers, > Andy >=20 > On Tue, May 3, 2011 at 3:36 AM, =A0 wrote: >> Hi Andy, >>=20 >> 2 points: >>=20 >> 1 =A0 =A0 =A0 I agree with your view of only having a single addressing = scheme in a >> single layer network solely belonging to one party. =A0Though you may ne= ed to >> be rather careful if you also advocate that one can also have peer layer >> interworking between different parties, ie E-NNIs (I believe this is >> something you may support, eg old MPLSF case?). =A0In such a peer interw= orking >> case it would seem one must allow different addressing schemes (and inde= ed >> any other variations in DP/CP functional components) if they exist in th= e >> standards. >>=20 >> Of course, having an E-NNI and peer interworking between different parti= es in >> any non-TOS layer network (not just MPLS) is not technically necessary (= this >> is trivial to prove), and this provides a strong argument for only havin= g a >> single addressing scheme in a non-TOS layer network. >>=20 >>=20 >> 2 =A0 =A0 =A0 You should also be aware that in client/server interworkin= g of the >> co-ps mode using variable size traffic units, and therefore something ra= ther >> important for MPLS-TP in the role of a transport network (I'll ignore is= sues >> of transparency here), there could be inter-layer misconnectivity (Aside= =3D> >> This case cannot occur in the co-cs mode). =A0To date, however, we have = only >> really considered intra-layer misconnectivity, ie between different LSPs >> belonging to the same party (note this also includes all cases of nested= LSP >> sublayer misconnectivity). >>=20 >> In the case of inter-layer misconnectivity one may receive traffic units= and >> OAM messages from some other party's layer network. =A0The OAM messages = may >> come from (i) networks using different OAM/addressing solutions or (ii) >> networks using the same OAM/addressing solutions. =A0In both cases there= are >> different issues wrt inter-layer misconnectivity one has to deal with. = =A0I'm >> not aware that these cases have been considered yet. >>=20 >>=20 >> I'd like to hear your comments on both these points, but in particular t= he >> first one.....especially if you also support the notion of E-NNIs in MPL= S-TP, >> as there seems to a possible logical conflict here. >>=20 >> Thanks. >>=20 >> regards, Neil Harrison >>=20 >> BT Design >>=20 >> This email contains BT information, which may be privileged or confident= ial. >> It's meant only for the individual(s) or entity named above. If you're n= ot >> 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 kno= w >> immediately >> 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 >>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Andrew G. Malis >>> Sent: 02 May 2011 20:48 >>> To: George Swallow >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>=20 >>> George et al, >>>=20 >>> Verizon does not have any requirement for mixed use of Global IDs and >>> ICCs. We are fine with specifications that require both ends of an LSP >>> to use one or the other. >>>=20 >>> Thanks, >>> Andy >>>=20 >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>> wrote: >>>> 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. =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. >>>>=20 >>>> The ITU liaison requests that we allow mixed use. >>>>=20 >>>> The authors of the draft are very reluctant to do this. >>>>=20 >>>> Obtaining an AS Number (from which the Global-ID is derived) is a >>> fairly >>>> trivial procedure. =A0Many 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. =A0If 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. =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. >>>>=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 >>>>=20 >>>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From matthew.bocci@alcatel-lucent.com Wed May 4 01:19: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 6B9F5E0707; Wed, 4 May 2011 01:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.298, 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 xb6VftfxonxH; Wed, 4 May 2011 01:19:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3EFE06D4; Wed, 4 May 2011 01:19:14 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p448Emn2027763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 May 2011 10:19:11 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 4 May 2011 10:18:54 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 4 May 2011 10:18:50 +0200 Thread-Topic: draft-boutros-pwe3-mpls-tp-ms-pw-01 to WG draft? Thread-Index: AcwKM+hsLNoO8sLZTdGalGNmximl+A== Message-ID: 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.80 Cc: "mpls@ietf.org" Subject: [mpls] draft-boutros-pwe3-mpls-tp-ms-pw-01 to WG draft? 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, 04 May 2011 08:19:16 -0000 The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01 have asked that this draft be adopted as a PWE3 WG draft. This email starts a two week poll of the list to help us judge if there is consensus to move forward with this draft. Please reply to the PWE3 list only, by Wed May 18th. Regards, Matthew & Andy From tnadeau@lucidvision.com Wed May 4 05:14: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 4B32EE074C; Wed, 4 May 2011 05:14:43 -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.175, 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 tl9bZ94dMopy; Wed, 4 May 2011 05:14:41 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 89127E0748; Wed, 4 May 2011 05:14:41 -0700 (PDT) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C3D3A1B3840E; Wed, 4 May 2011 08:14:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Thomas Nadeau In-Reply-To: <5E893DB832F57341992548CDBB333163A097C1989A@EMBX01-HQ.jnpr.net> Date: Wed, 4 May 2011 08:14:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14231342-1D66-47DD-93FA-5623152722D0@lucidvision.com> References: <13144777.1226221304374389617.JavaMail.defaultUser@defaultHost> <5E893DB832F57341992548CDBB333163A097C1989A@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1084) Cc: "mpls-bounces@ietf.org" , "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, 04 May 2011 12:14:43 -0000 On May 3, 2011, at 8:48 PM, John E Drake wrote: > Comments inline. >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: erminio.ottone_69@libero.it = [mailto:erminio.ottone_69@libero.it] >> Sent: Monday, May 02, 2011 3:13 PM >> To: John E Drake; Malcolm.BETTS@zte.com.cn >> Cc: mpls@ietf.org; mpls-bounces@ietf.org >> Subject: R: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >> Identifiers? >>=20 >> If my name is XYZ and your name is 123, I do want to change my name = in >> order to >> talk to you. >>=20 >> How can a requirement RFC require the interconnection between = IP-based >> and ICC- >> based identifiers before these identifiers are defined? >=20 > JD: By saying something like "If multiple types of identifiers are = defined, the endpoints of a given LSP or pseudowire MUST be able to use = different identifier types"? >=20 >>=20 >> I can see requirements for supporting different identifiers schemes = and >> requirements to support multi-domain interconnection. I do not see = any >> requirement that limit inter-domain interconnection only between >> domains that >> have the same identifiers scheme. >=20 > JD: I didn't say that. What I said was: >=20 > "JD: The endpoints have to agree on a common format for the data = plane." >=20 > This is a very different statement, and seems eminently reasonable to = me. TOM: I agree %100. Specifically, if we separate out the notion of = supporting multiple=20 types at the same time and instead move the discussion to using a single = type once everyone along the path agrees on a type a priori, as you say, then = I=20 think the problem is sorted. --Tom >=20 >>=20 >> Have I missed some requirement? >>=20 >> ----Messaggio originale---- >> Da: jdrake@juniper.net >> Data: 28-apr-2011 18.22 >> A: "Malcolm.BETTS@zte.com.cn" >> Cc: "mpls@ietf.org", "mpls-bounces@ietf.org"> bounces@ietf. >> org> >> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >> Comments inline. >>=20 >> Sent from my iPhone >>=20 >> 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? >>=20 >>=20 >> John, >>=20 >> 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=92 >> s the whole point of the discussion. >> 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! >> 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 >> 5150. >>=20 >> 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. >> JD: If it is not in the MPLS-TP requirements RFCs, it is by = definition >> a late >> breaking requirement. >>=20 >> Regards, >>=20 >> Malcolm >>=20 >>=20 >>=20 >> 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? >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> I interpreted Eric=92s use of =91stitching=92 to be in the RFC 5150 = sense. >> I >> think I will let him clarify, but if used in the RFC 5150 sense, a >> =91stitched=92 >> LSP would have end-to-end OAM, and different pieces could use = 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] >> 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 >> John E Drake >> 27/04/2011 06:53 PM >>=20 >> To >> "Malcolm.BETTS@zte.com.cn" , Eric Gray = > gray@ericsson.com> >> cc >> "mpls@ietf.org" , "mpls-bounces@ietf.org" > bounces@ietf. >> org> >> Subject >> RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> That=92s incorrect. There is a single end-to-end LSP composed of >> different >> pieces, each under the control of a different administrative entity. >>=20 >> Thanks, >>=20 >> John >>=20 >> Sent from my iPhone >>=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 >> Eric Gray >> Sent by: mpls-bounces@ietf.org >> 27/04/2011 12:11 PM >>=20 >>=20 >> To >> George Swallow , "mpls@ietf.org" >> cc >> Subject >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=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? >>=20 >> 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 >> 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. >>=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 >>=20 >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@ietfa.amsl.com Wed May 4 06:29:22 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 4167CE0792; Wed, 4 May 2011 06:29:22 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110504132922.4167CE0792@ietfa.amsl.com> Date: Wed, 4 May 2011 06:29:22 -0700 (PDT) Cc: Huub.van.Helvoort@huawei.com, mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS301 - Last Call review of draft-ietf-mpls-tp-on-demand-cv-03 [ref #053.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:29:22 -0000 Title: LS301 - Last Call review of draft-ietf-mpls-tp-on-demand-cv-03 [ref #053.02] Submission Date: 2011-05-04 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1049 Please reply by 2011-06-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Huub.van.Helvoort@huawei.com Purpose: For action Body: Attachment(s): LS301 - Last Call review of draft-ietf-mpls-tp-on-demand-cv-03 [ref #053.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1230.pdf) From jhaas@juniper.net Wed May 4 08:30:24 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 53498E06E4 for ; Wed, 4 May 2011 08:30:24 -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 EKLKM97K36pg for ; Wed, 4 May 2011 08:30:23 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8CE0684 for ; Wed, 4 May 2011 08:30:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTcFxC77k4+8EhUQkD83cNaQsy6gmQcaM@postini.com; Wed, 04 May 2011 08:30:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 4 May 2011 08:29:29 -0700 From: Jeff Haas To: John E Drake Date: Wed, 4 May 2011 08:29:26 -0700 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKcA7RfVUL2bHjQpeNsnYAOt/KrA== Message-ID: <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.net> References: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> <60C093A41B5E45409A19D42CF7786DFD521B0E5409@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A097C198FA@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A097C198FA@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Ward , "mpls@ietf.org" Subject: Re: [mpls] I: 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, 04 May 2011 15:30:24 -0000 -mpls@ietf On May 3, 2011, at 9:41 PM, John E Drake wrote: > Hi, >=20 > According to RFC 5880, if a node does not receive a Final in response to = a Poll, it continues to use the current BFD session parameters and MAY send= additional Polls (presumably one per second) in hopes of soliciting a Fina= l. I don't think we need to say anything more about what the sender of a P= oll needs to do. >=20 > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi n= eeds to say is that a node which does not support Poll/Final in UP state si= mply ignores a Poll. Why do we need P/F to transition to up? We need it once up to renegotiate = our timers. -- Jeff >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> David Allan I >> Sent: Tuesday, May 03, 2011 3:01 PM >> To: erminio.ottone_69@libero.it; mpls@ietf.org >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >>=20 >> Hi Ermino: >>=20 >> I stand corrected. I got lots of private feedback to the effect that >> current implementations see a "final" response as agreement to the >> parameters in a poll. Hence changing that semantic is not a good idea. >>=20 >> The alternative discussed was what an implementation does when a poll >> is not responded to in a resonable amount of time, which can be >> interpreted as a refusal to change by the far end, or non- >> implementation of P/F in steady state. At which point an implemention's >> options are to live with the status quo or take the session down. >>=20 >> Feedback welcome! >> Dave >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: Monday, May 02, 2011 2:54 PM >> To: mpls@ietf.org >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >>=20 >> Forwarding the messate to the MPLS WG mailing list ... >>=20 >>> ----Messaggio originale---- >>> Da: erminio.ottone_69@libero.it >>> Data: 2-mag-2011 23.19 >>> A: >>> Ogg: R: [mpls] FW: Poll / Final in draft-cc-cv-rdi >>>=20 >>>> 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. >>>=20 >>> How this is possible? >>>=20 >>> Section 6.8.7 of RFC 5880 states that: >>>=20 >>> With the exceptions listed in the remainder of this section, a >> system >>> MUST NOT transmit BFD Control packets at an interval less than the >>> larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, >> less >>> applied jitter (see below). >>>=20 >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can the >>> system ignore the request? >>>=20 >>>> ----Messaggio originale---- >>>> Da: david.i.allan@ericsson.com >>>> Data: 20-apr-2011 17.29 >>>> A: "mpls@ietf.org" >>>> Cc: "Ross Callon" >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >>>>=20 >>>> 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 >> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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... >>>>=20 >>>> the editors >>>> Dave, John and George... >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>=20 >>>=20 >>=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 jdrake@juniper.net Wed May 4 09:13: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 DD7D7E07B3 for ; Wed, 4 May 2011 09:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 c6FSP3TR4KcZ for ; Wed, 4 May 2011 09:13:02 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id C00A4E07B2 for ; Wed, 4 May 2011 09:13:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTcF7BmpLdMeapbDHNgBdr81esWSEWipO@postini.com; Wed, 04 May 2011 09:13:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 4 May 2011 09:11:01 -0700 From: John E Drake To: Jeff Haas Date: Wed, 4 May 2011 09:10:58 -0700 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKcA7RfVUL2bHjQpeNsnYAOt/KrAABYp+A Message-ID: <5E893DB832F57341992548CDBB333163A097D1C618@EMBX01-HQ.jnpr.net> References: <8136766.1224751304373250887.JavaMail.defaultUser@defaultHost> <60C093A41B5E45409A19D42CF7786DFD521B0E5409@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A097C198FA@EMBX01-HQ.jnpr.net> <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.net> In-Reply-To: <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Ward , "mpls@ietf.org" Subject: Re: [mpls] I: 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, 04 May 2011 16:13:04 -0000 Jeff, There was an extended discussion on this topic between Rob Rennison and Dav= e Allan, the details of which escape me. Thanks, John Sent from my iPhone > -----Original Message----- > From: Jeff Haas > Sent: Wednesday, May 04, 2011 8:29 AM > To: John E Drake > Cc: David Allan I; erminio.ottone_69@libero.it; mpls@ietf.org; Nitin > Bahadur; David Ward > Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >=20 > -mpls@ietf >=20 > On May 3, 2011, at 9:41 PM, John E Drake wrote: >=20 > > Hi, > > > > According to RFC 5880, if a node does not receive a Final in response > to a Poll, it continues to use the current BFD session parameters and > MAY send additional Polls (presumably one per second) in hopes of > soliciting a Final. I don't think we need to say anything more about > what the sender of a Poll needs to do. > > > > We need Poll/Final to transition to UP state, so I think what cc-cv- > rdi needs to say is that a node which does not support Poll/Final in UP > state simply ignores a Poll. >=20 > Why do we need P/F to transition to up? We need it once up to > renegotiate our timers. >=20 > -- Jeff >=20 > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> David Allan I > >> Sent: Tuesday, May 03, 2011 3:01 PM > >> To: erminio.ottone_69@libero.it; mpls@ietf.org > >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi > >> > >> Hi Ermino: > >> > >> I stand corrected. I got lots of private feedback to the effect that > >> current implementations see a "final" response as agreement to the > >> parameters in a poll. Hence changing that semantic is not a good > idea. > >> > >> The alternative discussed was what an implementation does when a > poll > >> is not responded to in a resonable amount of time, which can be > >> interpreted as a refusal to change by the far end, or non- > >> implementation of P/F in steady state. At which point an > implemention's > >> options are to live with the status quo or take the session down. > >> > >> Feedback welcome! > >> Dave > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> erminio.ottone_69@libero.it > >> Sent: Monday, May 02, 2011 2:54 PM > >> To: mpls@ietf.org > >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi > >> > >> Forwarding the messate to the MPLS WG mailing list ... > >> > >>> ----Messaggio originale---- > >>> Da: erminio.ottone_69@libero.it > >>> Data: 2-mag-2011 23.19 > >>> A: > >>> Ogg: R: [mpls] FW: Poll / Final in 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. > >>> > >>> How this is possible? > >>> > >>> Section 6.8.7 of RFC 5880 states that: > >>> > >>> With the exceptions listed in the remainder of this section, a > >> system > >>> MUST NOT transmit BFD Control packets at an interval less than the > >>> larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, > >> less > >>> applied jitter (see below). > >>> > >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can the > >>> system ignore the request? > >>> > >>>> ----Messaggio originale---- > >>>> Da: david.i.allan@ericsson.com > >>>> Data: 20-apr-2011 17.29 > >>>> A: "mpls@ietf.org" > >>>> Cc: "Ross Callon" > >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi > >>>> > >>>> 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... > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 rcallon@juniper.net Wed May 4 10:39: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 37B08E078F for ; Wed, 4 May 2011 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.684 X-Spam-Level: X-Spam-Status: No, score=-106.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, 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 DrMd0ypoIVAD for ; Wed, 4 May 2011 10:39:04 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4BE0786 for ; Wed, 4 May 2011 10:39:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTcGPN+LH6RwYHPdny34zbCzeFulaEumu@postini.com; Wed, 04 May 2011 10:39:04 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 4 May 2011 10:36:15 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 4 May 2011 13:36:14 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 4 May 2011 13:36:13 -0400 Thread-Topic: End of poll on draft-kompella-mpls-entropy-label as MPLS WG document Thread-Index: Acud41zqPZ8X13jwTuKh371egYKmixf94yBQAyl1HdA= 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] End of 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, 04 May 2011 17:39:05 -0000 All, this poll has ended. We have accepted a new working group document. Could the authors please publish the document as: draft-ietf-mpls-entropy-label-00 without any other changes than date, file name and version number. Subsequent to the publication of this document as a WG document, the author= s should then consider the various substantive comments received during the= poll as comments received on the WG list on an active MPLS WG document.=20 Ross, Loa, and George=20 mpls wg co-chairs -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Monday, April 18, 2011 11: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 swallow@cisco.com Wed May 4 12:13: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 7624BE079A for ; Wed, 4 May 2011 12:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.977 X-Spam-Level: X-Spam-Status: No, score=-108.977 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, 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 O7yGESbgG5b3 for ; Wed, 4 May 2011 12:13:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 471DDE0795 for ; Wed, 4 May 2011 12:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=16968; q=dns/txt; s=iport; t=1304536403; x=1305746003; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=Cl+oMSktvdBlGwQ8/LhgvDLWoBJQ+AhGJJ1IZG536bU=; b=bSrzsAKZaKcBQ/GH3md9kni2Z6B+nBDVftdgNfN6lPOOVe8yq5lfC2Gd f0GwPeSQtBkvVSvwb25x+6rg7LKfaRAreii1UiFH/DVnZIlix0L58++ua FkeOPPtW3nKEfMqLjnRzzk71ccEFEQ+yibAmx/D1xwAdI5dNA3rYHmjJG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBABqlwU2tJV2a/2dsb2JhbACCYZUsjSlnd4hynjKeOYYHBIIljRCEJYox X-IronPort-AV: E=Sophos;i="4.64,316,1301875200"; d="scan'208,217";a="350425053" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-2.cisco.com with ESMTP; 04 May 2011 19:12:56 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p44JCtID028441; Wed, 4 May 2011 19:12:55 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, 4 May 2011 14:12:55 -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, 4 May 2011 19:12:55 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 04 May 2011 15:12:53 -0400 From: George Swallow To: Jeff Haas , John E Drake Message-ID: Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKcA7RfVUL2bHjQpeNsnYAOt/KrAAHzWFY In-Reply-To: <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3387366773_77489754" X-OriginalArrivalTime: 04 May 2011 19:12:55.0630 (UTC) FILETIME=[45E776E0:01CC0A8F] Cc: mpls@ietf.org, David Ward Subject: Re: [mpls] I: 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, 04 May 2011 19:13:25 -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_3387366773_77489754 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Jeff - This is my view as well. You come up slow, use P/F to get to the rate you want. After that you can ignore P/F. ...George On 5/4/11 11:29 AM, "Jeff Haas" wrote: > -mpls@ietf > > On May 3, 2011, at 9:41 PM, John E Drake wrote: > >> > Hi, >> > >> > According to RFC 5880, if a node does not receive a Final in response to a >> Poll, it continues to use the current BFD session parameters and MAY send >> additional Polls (presumably one per second) in hopes of soliciting a Final. >> I don't think we need to say anything more about what the sender of a Poll >> needs to do. >> > >> > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi >> needs to say is that a node which does not support Poll/Final in UP state >> simply ignores a Poll. > > Why do we need P/F to transition to up? We need it once up to renegotiate our > timers. > > -- Jeff > >> > >> > Thanks, >> > >> > John >> > >> > Sent from my iPhone >> > >> > >>> >> -----Original Message----- >>> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> >> David Allan I >>> >> Sent: Tuesday, May 03, 2011 3:01 PM >>> >> To: erminio.ottone_69@libero.it; mpls@ietf.org >>> >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >>> >> >>> >> Hi Ermino: >>> >> >>> >> I stand corrected. I got lots of private feedback to the effect that >>> >> current implementations see a "final" response as agreement to the >>> >> parameters in a poll. Hence changing that semantic is not a good idea. >>> >> >>> >> The alternative discussed was what an implementation does when a poll >>> >> is not responded to in a resonable amount of time, which can be >>> >> interpreted as a refusal to change by the far end, or non- >>> >> implementation of P/F in steady state. At which point an implemention's >>> >> options are to live with the status quo or take the session down. >>> >> >>> >> Feedback welcome! >>> >> Dave >>> >> >>> >> -----Original Message----- >>> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> >> erminio.ottone_69@libero.it >>> >> Sent: Monday, May 02, 2011 2:54 PM >>> >> To: mpls@ietf.org >>> >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >>> >> >>> >> Forwarding the messate to the MPLS WG mailing list ... >>> >> >>>> >>> ----Messaggio originale---- >>>> >>> Da: erminio.ottone_69@libero.it >>>> >>> Data: 2-mag-2011 23.19 >>>> >>> A: >>>> >>> Ogg: R: [mpls] FW: Poll / Final in 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. >>>> >>> >>>> >>> How this is possible? >>>> >>> >>>> >>> Section 6.8.7 of RFC 5880 states that: >>>> >>> >>>> >>> With the exceptions listed in the remainder of this section, a >>> >> system >>>> >>> MUST NOT transmit BFD Control packets at an interval less than the >>>> >>> larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, >>> >> less >>>> >>> applied jitter (see below). >>>> >>> >>>> >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can the >>>> >>> system ignore the request? >>>> >>> >>>>> >>>> ----Messaggio originale---- >>>>> >>>> Da: david.i.allan@ericsson.com >>>>> >>>> Data: 20-apr-2011 17.29 >>>>> >>>> A: "mpls@ietf.org" >>>>> >>>> Cc: "Ross Callon" >>>>> >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >>>>> >>>> >>>>> >>>> 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... >>>>> >>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> 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 > --B_3387366773_77489754 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] I:  FW: Poll / Final in draft-cc-cv-rdi Jeff -<= BR>
This is my view as well.  You come up slow, use P/F to get to the rate= you want.  After that you can ignore P/F.  

...George

On 5/4/11 11:29 AM, "Jeff Haas" <j= haas@juniper.net> wrote:

-mpls@ietf

On May 3, 2011, at 9:41 PM, John E Drake wrote:

> Hi,
>
> According to RFC 5880, if a node does not receive a Final in response = to a Poll, it continues to use the current BFD session parameters and MAY se= nd additional Polls (presumably one per second) in hopes of soliciting a Fin= al.  I don't think we need to say anything more about what the sender o= f a Poll needs to do.
>
> We need Poll/Final to transition to UP state, so I think what cc-cv-rd= i needs to say is that a node which does not support Poll/Final in UP state = simply ignores a Poll.

Why do we need P/F to transition to up?  We need it once up to renegot= iate our timers.

-- Jeff

>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [<= a href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org] On B= ehalf Of
>> David Allan I
>> Sent: Tuesday, May 03, 2011 3:01 PM
>> To: erminio.ottone_69@libero= .it; mpls@ietf.org
>> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi
>>
>> Hi Ermino:
>>
>> I stand corrected. I got lots of private feedback to the effect th= at
>> current implementations see a "final" response as agreem= ent to the
>> parameters in a poll. Hence changing that semantic is not a good i= dea.
>>
>> The alternative discussed was what an implementation does when a p= oll
>> is not responded to in a resonable amount of time, which can be >> interpreted as a refusal to change by the far end, or non-
>> implementation of P/F in steady state. At which point an implement= ion's
>> options are to live with the status quo or take the session down.<= BR> >>
>> Feedback welcome!
>> Dave
>>
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [<= a href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org] On B= ehalf Of
>> erminio.ottone_69@libero.it<= /a>
>> Sent: Monday, May 02, 2011 2:54 PM
>> To: mpls@ietf.org
>> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi
>>
>> Forwarding the messate to the MPLS WG mailing list ...
>>
>>> ----Messaggio originale----
>>> Da: erminio.ottone_69@li= bero.it
>>> Data: 2-mag-2011 23.19
>>> A: <david.i.allan@eric= sson.com>
>>> Ogg: R: [mpls] FW: Poll / Final in draft-cc-cv-rdi
>>>
>>>> We would also observe that it is permissable in the specif= ication to
>> respond
>>>> to a poll with a final reply with the session parameters u= nchanged.
>> So
>>>> once a session is up a compliant implementation does not a= ctually
>> 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 proce= ssing loop.
>>>
>>> How this is possible?
>>>
>>> Section 6.8.7 of RFC 5880 states that:
>>>
>>>  With the exceptions listed in the remainder of this sect= ion, a
>> system
>>>  MUST NOT transmit BFD Control packets at an interval les= s than the
>>>  larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxIn= terval,
>> less
>>>  applied jitter (see below).
>>>
>>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can= the
>>> system ignore the request?
>>>
>>>> ----Messaggio originale----
>>>> Da: david.i.allan@eri= csson.com
>>>> Data: 20-apr-2011 17.29
>>>> A: "mpls@ietf.o= rg"<mpls@ietf.org>
>>>> Cc: "Ross Callon"<rcallon@juniper.net>
>>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi
>>>>
>>>> Hi Folks:
>>>>
>>>> We've received a number of comments both formally and info= rmally that
>>>> the current draft has deviated too far from the base BFD s= pec and
>> thus
>>>> loses backward compatibility with existing code bases. &nb= sp;Further,
>>>> discussions with the BFD WG have indicated we have a poten= tial race
>>>> condition in the current startup procedures described in d= raft-cc-cv-
>> rdi.
>>>>
>>>> The issue is the transition to UP state requires confirmat= ion by the
>>>> peer MEP prior to changing the detection time to the rx-in= terval x
>>>> detect mult
>> in
>>>> order to avoid potential flapping. This can result in an >>>> implementation effectively needing two UP states (UP forwa= rd, UP
>> reverse direction).
>>>> Otherwise the MEP may time out the reverse direction befor= e seeing an
>>>> UP state from the peer MEP.
>>>>
>>>> So we can make this implicit in the specification and requ= ire 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 w= ould reduce
>>>> the deltas between the base spec (RFC 5880) and draft CC-C= V-RDI.
>>>>
>>>> We would also observe that it is permissable in the specif= ication to
>> respond
>>>> to a poll with a final reply with the session parameters u= nchanged.
>> So
>>>> once a session is up a compliant implementation does not a= ctually
>> 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 proce= ssing loop.
>>>>
>>>> This is a change of direction from what has been in the dr= aft to
>> date,
>> hence
>>>> we'd look to the WG for comment on this change...
>>>>
>>>> the editors
>>>> Dave, John and George...
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https= ://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.i= etf.org/mailman/listinfo/mpls
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.i= etf.org/mailman/listinfo/mpls

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

--B_3387366773_77489754-- From david.i.allan@ericsson.com Wed May 4 12: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 59A6CE07A1 for ; Wed, 4 May 2011 12:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.581 X-Spam-Level: X-Spam-Status: No, score=-4.581 tagged_above=-999 required=5 tests=[AWL=2.017, 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 4AbAKunGUcme for ; Wed, 4 May 2011 12:34:34 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C2806E06B1 for ; Wed, 4 May 2011 12:34:33 -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 p44JYUlH005485; Wed, 4 May 2011 14:34:32 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 4 May 2011 15:34:27 -0400 From: David Allan I To: George Swallow , Jeff Haas , John E Drake Date: Wed, 4 May 2011 15:34:25 -0400 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKcA7RfVUL2bHjQpeNsnYAOt/KrAAHzWFYAAC+2YA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD521B0E5A47@EUSAACMS0703.eamcs.ericsson.se> References: <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.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_60C093A41B5E45409A19D42CF7786DFD521B0E5A47EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , David Ward Subject: Re: [mpls] I: 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, 04 May 2011 19:34:35 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD521B0E5A47EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow Sent: Wednesday, May 04, 2011 12:13 PM To: Jeff Haas; John E Drake Cc: mpls@ietf.org; David Ward Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Jeff - This is my view as well. You come up slow, use P/F to get to the rate you = want. After that you can ignore P/F. ...George On 5/4/11 11:29 AM, "Jeff Haas" wrote: -mpls@ietf On May 3, 2011, at 9:41 PM, John E Drake wrote: > Hi, > > According to RFC 5880, if a node does not receive a Final in response to = a Poll, it continues to use the current BFD session parameters and MAY send= additional Polls (presumably one per second) in hopes of soliciting a Fina= l. I don't think we need to say anything more about what the sender of a P= oll needs to do. > > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi n= eeds to say is that a node which does not support Poll/Final in UP state si= mply ignores a Poll. Why do we need P/F to transition to up? We need it once up to renegotiate = our timers. -- Jeff > > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> David Allan I >> Sent: Tuesday, May 03, 2011 3:01 PM >> To: erminio.ottone_69@libero.it; mpls@ietf.org >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >> >> Hi Ermino: >> >> I stand corrected. I got lots of private feedback to the effect that >> current implementations see a "final" response as agreement to the >> parameters in a poll. Hence changing that semantic is not a good idea. >> >> The alternative discussed was what an implementation does when a poll >> is not responded to in a resonable amount of time, which can be >> interpreted as a refusal to change by the far end, or non- >> implementation of P/F in steady state. At which point an implemention's >> options are to live with the status quo or take the session down. >> >> Feedback welcome! >> Dave >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: Monday, May 02, 2011 2:54 PM >> To: mpls@ietf.org >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >> >> Forwarding the messate to the MPLS WG mailing list ... >> >>> ----Messaggio originale---- >>> Da: erminio.ottone_69@libero.it >>> Data: 2-mag-2011 23.19 >>> A: >>> Ogg: R: [mpls] FW: Poll / Final in 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. >>> >>> How this is possible? >>> >>> Section 6.8.7 of RFC 5880 states that: >>> >>> With the exceptions listed in the remainder of this section, a >> system >>> MUST NOT transmit BFD Control packets at an interval less than the >>> larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, >> less >>> applied jitter (see below). >>> >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can the >>> system ignore the request? >>> >>>> ----Messaggio originale---- >>>> Da: david.i.allan@ericsson.com >>>> Data: 20-apr-2011 17.29 >>>> A: "mpls@ietf.org" >>>> Cc: "Ross Callon" >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >>>> >>>> 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... >>>> >>>> >>>> _______________________________________________ >>>> 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 --_000_60C093A41B5E45409A19D42CF7786DFD521B0E5A47EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] I:  FW: Poll / Final in draft-cc-cv-rdi<= /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=3D762133419-04052011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>+1</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> Wednesday, May 04, 2011 12:13 PM<BR><B>To:</B> Jeff= =20 Haas; John E Drake<BR><B>Cc:</B> mpls@ietf.org; David Ward<BR><B>Subject:</= B>=20 Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi<BR></FONT><BR></DIV> <DIV></DIV><FONT face=3D"Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt">Jeff -<BR><BR>This is my view as well.  You = come up=20 slow, use P/F to get to the rate you want.  After that you can ignore = P/F.=20  <BR><BR>...George<BR><BR>On 5/4/11 11:29 AM, "Jeff Haas" <<A=20 href=3D"jhaas@juniper.net">jhaas@juniper.net</A>> wrote:<BR><BR></SPAN><= /FONT> <BLOCKQUOTE><FONT face=3D"Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt">-mpls@ietf<BR><BR>On May 3, 2011, at 9:41 PM, J= ohn E=20 Drake wrote:<BR><BR>> Hi,<BR>><BR>> According to RFC 5880, if a = node=20 does not receive a Final in response to a Poll, it continues to use the=20 current BFD session parameters and MAY send additional Polls (presumably = one=20 per second) in hopes of soliciting a Final.  I don't think we need t= o say=20 anything more about what the sender of a Poll needs to do.<BR>><BR>>= ; We=20 need Poll/Final to transition to UP state, so I think what cc-cv-rdi need= s to=20 say is that a node which does not support Poll/Final in UP state simply=20 ignores a Poll.<BR><BR>Why do we need P/F to transition to up?  We n= eed=20 it once up to renegotiate our timers.<BR><BR>-- Jeff<BR><BR>><BR>>= =20 Thanks,<BR>><BR>> John<BR>><BR>> Sent from my=20 iPhone<BR>><BR>><BR>>> -----Original Message-----<BR>>>= =20 From: <A href=3D"mpls-bounces@ietf.org">mpls-bounces@ietf.org</A> [<A=20 href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</A>] O= n=20 Behalf Of<BR>>> David Allan I<BR>>> Sent: Tuesday, May 03, 20= 11=20 3:01 PM<BR>>> To: <A=20 href=3D"erminio.ottone_69@libero.it">erminio.ottone_69@libero.it</A>; <A= =20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>>> Subject: Re: [mpls] = I: FW:=20 Poll / Final in draft-cc-cv-rdi<BR>>><BR>>> Hi=20 Ermino:<BR>>><BR>>> I stand corrected. I got lots of private= =20 feedback to the effect that<BR>>> current implementations see a "fi= nal"=20 response as agreement to the<BR>>> parameters in a poll. Hence chan= ging=20 that semantic is not a good idea.<BR>>><BR>>> The alternative= =20 discussed was what an implementation does when a poll<BR>>> is not= =20 responded to in a resonable amount of time, which can be<BR>>>=20 interpreted as a refusal to change by the far end, or non-<BR>>>=20 implementation of P/F in steady state. At which point an=20 implemention's<BR>>> options are to live with the status quo or tak= e the=20 session down.<BR>>><BR>>> Feedback welcome!<BR>>>=20 Dave<BR>>><BR>>> -----Original Message-----<BR>>> From:= <A=20 href=3D"mpls-bounces@ietf.org">mpls-bounces@ietf.org</A> [<A=20 href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</A>] O= n=20 Behalf Of<BR>>> <A=20 href=3D"erminio.ottone_69@libero.it">erminio.ottone_69@libero.it</A><BR>&= gt;>=20 Sent: Monday, May 02, 2011 2:54 PM<BR>>> To: <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>>> Subject: [mpls] I: F= W: Poll=20 / Final in draft-cc-cv-rdi<BR>>><BR>>> Forwarding the messate= to=20 the MPLS WG mailing list ...<BR>>><BR>>>> ----Messaggio=20 originale----<BR>>>> Da: <A=20 href=3D"erminio.ottone_69@libero.it">erminio.ottone_69@libero.it</A><BR>&= gt;>>=20 Data: 2-mag-2011 23.19<BR>>>> A: <<A=20 href=3D"david.i.allan@ericsson.com">david.i.allan@ericsson.com</A>><BR= >>>>=20 Ogg: R: [mpls] FW: Poll / Final in=20 draft-cc-cv-rdi<BR>>>><BR>>>>> We would also observe= that=20 it is permissable in the specification to<BR>>>=20 respond<BR>>>>> to a poll with a final reply with the session= =20 parameters unchanged.<BR>>> So<BR>>>>> once a session i= s up=20 a compliant implementation does not actually<BR>>>=20 have<BR>>>>> to implement on the fly changes to session param= ters.=20 The processing<BR>>>>> of the poll bit can simply be reduced = to=20 setting the final bit in the<BR>>>>> next<BR>>>=20 message.<BR>>>>> This would permit implementations to optimiz= e the=20 UP processing loop.<BR>>>><BR>>>> How this is=20 possible?<BR>>>><BR>>>> Section 6.8.7 of RFC 5880 state= s=20 that:<BR>>>><BR>>>>  With the exceptions listed in= the=20 remainder of this section, a<BR>>> system<BR>>>>  MUS= T NOT=20 transmit BFD Control packets at an interval less than the<BR>>>>= =20  larger of bfd.DesiredMinTxInterval and=20 bfd.RemoteMinRxInterval,<BR>>> less<BR>>>>  applied j= itter=20 (see below).<BR>>>><BR>>>> If the Poll requires a longe= r=20 bfd.RemoteMinRxInterval, how can the<BR>>>> system ignore the=20 request?<BR>>>><BR>>>>> ----Messaggio=20 originale----<BR>>>>> Da: <A=20 href=3D"david.i.allan@ericsson.com">david.i.allan@ericsson.com</A><BR>>= ;>>>=20 Data: 20-apr-2011 17.29<BR>>>>> A: "<A=20 href=3D'mpls@ietf.org"<mpls'>mpls@ietf.org"<mpls</A>@ietf.org><BR>&= gt;>>>=20 Cc: "Ross Callon"<<A=20 href=3D"rcallon@juniper.net">rcallon@juniper.net</A>><BR>>>>&= gt;=20 Ogg: [mpls] FW: Poll / Final in=20 draft-cc-cv-rdi<BR>>>>><BR>>>>> Hi=20 Folks:<BR>>>>><BR>>>>> We've received a number of= =20 comments both formally and informally that<BR>>>>> the curren= t=20 draft has deviated too far from the base BFD spec and<BR>>>=20 thus<BR>>>>> loses backward compatibility with existing code= =20 bases.  Further,<BR>>>>> discussions with the BFD WG hav= e=20 indicated we have a potential race<BR>>>>> condition in the=20 current startup procedures described in draft-cc-cv-<BR>>>=20 rdi.<BR>>>>><BR>>>>> The issue is the transition = to UP=20 state requires confirmation by the<BR>>>>> peer MEP prior to= =20 changing the detection time to the rx-interval x<BR>>>>> dete= ct=20 mult<BR>>> in<BR>>>>> order to avoid potential flapping= .=20 This can result in an<BR>>>>> implementation effectively need= ing=20 two UP states (UP forward, UP<BR>>> reverse=20 direction).<BR>>>>> Otherwise the MEP may time out the revers= e=20 direction before seeing an<BR>>>>> UP state from the peer=20 MEP.<BR>>>>><BR>>>>> So we can make this implicit= in=20 the specification and require BFD<BR>>>>> changes<BR>>>= =20 or<BR>>>>> we can use poll/final discipline on startup as def= ined=20 in the base<BR>>>>> specification and make the transition to = fully=20 UP and the desired<BR>>> rate<BR>>>>> both explicit and= =20 exposed in the protocol exchange. This would reduce<BR>>>>> t= he=20 deltas between the base spec (RFC 5880) and draft=20 CC-CV-RDI.<BR>>>>><BR>>>>> We would also observe = that=20 it is permissable in the specification to<BR>>>=20 respond<BR>>>>> to a poll with a final reply with the session= =20 parameters unchanged.<BR>>> So<BR>>>>> once a session i= s up=20 a compliant implementation does not actually<BR>>>=20 have<BR>>>>> to implement on the fly changes to session param= ters.=20 The processing<BR>>>>> of the poll bit can simply be reduced = to=20 setting the final bit in the<BR>>>>> next<BR>>>=20 message.<BR>>>>> This would permit implementations to optimiz= e the=20 UP processing loop.<BR>>>>><BR>>>>> This is a cha= nge=20 of direction from what has been in the draft to<BR>>> date,<BR>>= >=20 hence<BR>>>>> we'd look to the WG for comment on this=20 change...<BR>>>>><BR>>>>> the=20 editors<BR>>>>> Dave, John and=20 George...<BR>>>>><BR>>>>><BR>>>>>=20 _______________________________________________<BR>>>>> mpls= =20 mailing list<BR>>>>> <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>>>>> <A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR>>>>><BR>>>><BR>>>&g= t;<BR>>><BR>>><BR>>>=20 _______________________________________________<BR>>> mpls mailing= =20 list<BR>>> <A href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>>> = <A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR>>>=20 _______________________________________________<BR>>> mpls mailing= =20 list<BR>>> <A href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>>> = <A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR><BR>__________________________________________= _____<BR>mpls=20 mailing list<BR><A href=3D"mpls@ietf.org">mpls@ietf.org</A><BR><A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR><BR></SPAN></FONT></BLOCKQUOTE></BODY></HTML> --_000_60C093A41B5E45409A19D42CF7786DFD521B0E5A47EUSAACMS0703e_-- From jhaas@juniper.net Wed May 4 13:52:13 2011 Return-Path: <jhaas@juniper.net> 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 548A8E06C3 for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 13:52:13 -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 MUIFDUHjA+Sy for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 13:52:12 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDA3E06B7 for <mpls@ietf.org>; Wed, 4 May 2011 13:52:12 -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 DSNKTcG8etmvlpYdBS6LGTtk3A6gtMr0EE0E@postini.com; Wed, 04 May 2011 13:52:12 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, 4 May 2011 13:51:57 -0700 From: Jeff Haas <jhaas@juniper.net> To: George Swallow <swallow@cisco.com> Date: Wed, 4 May 2011 13:51:55 -0700 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKnRrIkRPT+iXlSFiypvm2F8E+MA== Message-ID: <4B4FF155-0681-4E40-BF93-872B2868E6C0@juniper.net> References: <C9E71D75.3337A%swallow@cisco.com> In-Reply-To: <C9E71D75.3337A%swallow@cisco.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: David Ward <dward@juniper.net>, "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] I: 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 <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, 04 May 2011 20:52:13 -0000 George, On May 4, 2011, at 3:12 PM, George Swallow wrote: This is my view as well. You come up slow, use P/F to get to the rate you = want. After that you can ignore P/F. I'm not a huge fan of generally saying "then you can ignore P/F" but I'm fi= ne with "the application can choose when they respond to polls". Mostly same thing from a practical implementation standpoint for TP. -- Jeff From Internet-Drafts@ietf.org Wed May 4 15:30:03 2011 Return-Path: <Internet-Drafts@ietf.org> 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 3C6C1E0743; Wed, 4 May 2011 15:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 l43U8o0ffAyV; Wed, 4 May 2011 15:30:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF5E0713; Wed, 4 May 2011 15:30: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.53 Message-ID: <20110504223002.31227.1528.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 15:30:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-10.txt 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, 04 May 2011 22:30: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 : Component Link Recording and Resource Control for TE Links Author(s) : A. Zamfir, et al Filename : draft-ietf-mpls-explicit-resource-control-bundle-10.txt Pages : 13 Date : 2011-04-27 Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route object (RRO) is not sufficient to determine the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-10.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-explicit-resource-control-bundle-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-04151839.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Wed May 4 21:31:50 2011 Return-Path: <Alexander.Vainshtein@ecitele.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 78BE8E0697 for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 21:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.461, 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 ucCtLSAiKi6N for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 21:31:49 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC5E06AC for <mpls@ietf.org>; Wed, 4 May 2011 21:31:47 -0700 (PDT) X-AuditID: 93eaf2e8-b7c8fae000000a6f-98-4dc227ce4d6d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 6F.2D.02671.EC722CD4; Thu, 5 May 2011 07:30:06 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 5 May 2011 07:31:44 +0300 From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> To: George Swallow <swallow@cisco.com>, Jeff Haas <jhaas@juniper.net> Date: Thu, 5 May 2011 07:31:45 +0300 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKcA7RfVUL2bHjQpeNsnYAOt/KrAAHzWFYABMvnh4= Message-ID: <A3C5DF08D38B6049839A6F553B331C76E9BD80C918@ILPTMAIL02.ecitele.com> References: <331A814E-1665-4DA4-93F8-9CFE612A914C@juniper.net>, <C9E71D75.3337A%swallow@cisco.com> In-Reply-To: <C9E71D75.3337A%swallow@cisco.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_A3C5DF08D38B6049839A6F553B331C76E9BD80C918ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUgTcRjvv7tt5/TinE3/StS63qiYOS1a5iLQlRViUFL4pc7t73a13cZu mgaRaG9YVtZEm0IvzOh9ZC9E7xtFWZKBWKZWH7TyrQ9aYFHO7nZkQnSffvf8Xp7njuchMHW1 MolgOQ9yc4ydVqjwEwMj33Qv54dyUoJHZhmejB3EDQ3vMg23ag2GzsYLckOXtxyskmd7f16T Z/v9P2TZb8rblRuw/DKQwXCc08N4kNaCeLOR3uBmixlzKa1lLUZaT2tddsaMHIjzGGnG5UKc hV6p0v7zZAgyltMizuy0sJzVSK/dmKszGJYu1+nplfNm69NWqDbZWF6LdA6GtWsdiOcZK9IK lW03MNvjbh/ueuoHJfWvG5RloP4wqARRBKSWwNbRO3IJx8NX7wOKSqAi1NRdAMu7vytFQk3V ALivNl/ECsoImy69U4h4GmWC14MPIgaMqgUweD0QMeDUHNjTdCLSIY5aAV+//YpLhgzYcrkL k3A67B7sigSRVC5sORUW9ITQjIH322aI5ShqMfxY1RyJAcJwo88vy0SMUQmws/eUTBqagv57 rZiENbC/JyyX9BrYfSAAJL0TNjzzy6VWsbD5ZC8u6RNh8HwHfgzE+ybF+iZZfJMsUj0ZdtR4 FRJeBM+dGcQkrIN14RA+uX4aKC8CDWt3eQoc1pTUZGRmPciOks1ORxOQ9qnvNuhqWRACFAHo GDITBXPUcqaYL3WEQCIhozXk7rmhHPXUAqel1Mbwtq3uIjviQwASGD2NvF0lyEkLU7oLuZ1/ KJPw86uxpGizU9hczrM1LSXl/y90Avnt0MMcNWUVdnMHQi7k/pMznSBoSBYI266OdSMrKilk 7Z6/tIyIEseIEccQRyR5F+PgWavEPwezkhLIa6KZEglbETfhFS9pz/j4+ABIED46jqwTVTHC nU24B4RgmRC8ruKRGCzczQSVVAaeTf0VGxvwZQx9mpe+vqyxz9/bnDf4Zej73viza8Njm71b RsYUqt1P576I7myP05jC+3xrsvanDd+pOxvvvbm8+PgORTpatL3C4tWPBAZ+tF/58KG1M29K S/7oGdOvNEsV3dNaszOz7fiyz6uLH0PNzLyjha5DqQ97svpNHbLMkuGrNM7bGP1CzM0zvwE7 lPHqJAQAAA== Cc: "mpls@ietf.org" <mpls@ietf.org>, David Ward <dward@juniper.net> Subject: Re: [mpls] I: 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 <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: Thu, 05 May 2011 04:31:50 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C918ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable George, Jeff, This is exactly the position Rob and I have presented in Maastricht, in Prag= ue and in multiple emil exchanged (off- and on the list): - Unless the desired rate of your session is 1 pps (or slower), you need P/F= to come to the desired rate in a consistent way after the session has been= set up. - If you decide not to manipulate the rate and/or other session parameters o= n the fly you do not need P/F after the first interaction. But this first in= teraction cannot be avoided. I am very happy to hear that the Editors of the cc-cv-rdi draft have decided= to move in this direction. My 2c, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of George Swal= low [swallow@cisco.com] Sent: Wednesday, May 04, 2011 10:12 PM To: Jeff Haas; John E Drake Cc: mpls@ietf.org; David Ward Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Jeff - This is my view as well. You come up slow, use P/F to get to the rate you w= ant. After that you can ignore P/F. ...George On 5/4/11 11:29 AM, "Jeff Haas" <jhaas@juniper.net<https://mail.ecitele.com/= OWA/UrlBlockedError.aspx>> wrote: -mpls@ietf On May 3, 2011, at 9:41 PM, John E Drake wrote: > Hi, > > According to RFC 5880, if a node does not receive a Final in response to a= Poll, it continues to use the current BFD session parameters and MAY send a= dditional Polls (presumably one per second) in hopes of soliciting a Final.= I don't think we need to say anything more about what the sender of a Poll= needs to do. > > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi ne= eds to say is that a node which does not support Poll/Final in UP state simp= ly ignores a Poll. Why do we need P/F to transition to up? We need it once up to renegotiate o= ur timers. -- Jeff > > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: mpls-bounces@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.= aspx> [mailto:mpls-bounces@ietf.org] On Behalf Of >> David Allan I >> Sent: Tuesday, May 03, 2011 3:01 PM >> To: erminio.ottone_69@libero.it<https://mail.ecitele.com/OWA/UrlBlockedEr= ror.aspx>; mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >> >> Hi Ermino: >> >> I stand corrected. I got lots of private feedback to the effect that >> current implementations see a "final" response as agreement to the >> parameters in a poll. Hence changing that semantic is not a good idea. >> >> The alternative discussed was what an implementation does when a poll >> is not responded to in a resonable amount of time, which can be >> interpreted as a refusal to change by the far end, or non- >> implementation of P/F in steady state. At which point an implemention's >> options are to live with the status quo or take the session down. >> >> Feedback welcome! >> Dave >> >> -----Original Message----- >> From: mpls-bounces@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.= aspx> [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it<https://mail.ecitele.com/OWA/UrlBlockedError.= aspx> >> Sent: Monday, May 02, 2011 2:54 PM >> To: mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi >> >> Forwarding the messate to the MPLS WG mailing list ... >> >>> ----Messaggio originale---- >>> Da: erminio.ottone_69@libero.it<https://mail.ecitele.com/OWA/UrlBlockedE= rror.aspx> >>> Data: 2-mag-2011 23.19 >>> A: <david.i.allan@ericsson.com<https://mail.ecitele.com/OWA/UrlBlockedEr= ror.aspx>> >>> Ogg: R: [mpls] FW: Poll / Final in 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. >>> >>> How this is possible? >>> >>> Section 6.8.7 of RFC 5880 states that: >>> >>> With the exceptions listed in the remainder of this section, a >> system >>> MUST NOT transmit BFD Control packets at an interval less than the >>> larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, >> less >>> applied jitter (see below). >>> >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can the >>> system ignore the request? >>> >>>> ----Messaggio originale---- >>>> Da: david.i.allan@ericsson.com<https://mail.ecitele.com/OWA/UrlBlockedE= rror.aspx> >>>> Data: 20-apr-2011 17.29 >>>> A: "mpls@ietf.org"<mpls<https://mail.ecitele.com/OWA/UrlBlockedError.as= px>@ietf.org> >>>> Cc: "Ross Callon"<rcallon@juniper.net<https://mail.ecitele.com/OWA/UrlB= lockedError.aspx>> >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi >>>> >>>> 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... >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>> >>> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> >> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<https://mail.ecitele.com/OWA/UrlBlockedError.aspx> 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_A3C5DF08D38B6049839A6F553B331C76E9BD80C918ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable <html dir=3D"ltr"><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-1= "> <meta content=3D"MSHTML 6.00.6000.17063" name=3D"GENERATOR"> <style id=3D"owaTempEditStyle"></style><style title=3D"owaParaStyle"><!--P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } --></style> </head> <body ocsi=3D"x"> <div style=3D"FONT-SIZE: 16px; COLOR: #000000; DIRECTION: ltr; FONT-FAMILY:= Times New Roman"> <div>George, Jeff,</div> <div><font face=3D"times new roman">This is exactly the position Rob and I h= ave presented in Maastricht, in Prague and in multiple emil<a></a> exch= anged (off- and on the list):</font></div> <div><font face=3D"times new roman">- Unless the desired rate of your sessio= n is 1 pps<a></a> (or slower), you need P/F to come to the desired= rate in a consistent way after the session has been set up.  </fo= nt></div> <div><font face=3D"times new roman">- If you decide not to manipulate the ra= te and/or other session parameters on the fly you do not need P/F <em>after the first interaction</em>. But this first interaction cannot be a= voided.</font></div> <div><font face=3D"times new roman"></font> </div> <div><font face=3D"times new roman">I am very happy to hear that the Editors= of the cc-cv<a></a>-rdi<a></a> draft have decided to move in this direction= .</font></div> <div><font face=3D"times new roman"></font> </div> <div><font face=3D"times new roman">My 2c,</font></div> <div><font face=3D"times new roman">     Sasha</font></d= iv> <div><font face=3D"times new roman"></font> </div> <div><font face=3D"times new roman"></font> </div> <div dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" size=3D"3"= ></font> </div> <div id=3D"divRpF51341" style=3D"DIRECTION: ltr"> <hr tabindex=3D"-1"> <font face=3D"Tahoma" color=3D"#000000" size=3D"2"><b>From:</b> mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of George Swallow [swallow@cisco= .com]<br> <b>Sent:</b> Wednesday, May 04, 2011 10:12 PM<br> <b>To:</b> Jeff Haas; John E Drake<br> <b>Cc:</b> mpls@ietf.org; David Ward<br> <b>Subject:</b> Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi<br> </font><br> </div> <div></div> <div><font face=3D"Verdana, Helvetica, Arial"><span style=3D"FONT-SIZE: 11pt= ">Jeff -<br> <br> This is my view as well.  You come up slow, use P/F to get to the rate= you want.  After that you can ignore P/F.  <br> <br> ...George<br> <br> On 5/4/11 11:29 AM, "Jeff Haas" <<a href=3D"https://mail.ecitel= e.com/OWA/UrlBlockedError.aspx" target=3D"_blank">jhaas@juniper.net</a>>= wrote:<br> <br> </span></font> <blockquote><font face=3D"Verdana, Helvetica, Arial"><span style=3D"FONT-SIZ= E: 11pt">-mpls@ietf<br> <br> On May 3, 2011, at 9:41 PM, John E Drake wrote:<br> <br> > Hi,<br> ><br> > According to RFC 5880, if a node does not receive a Final in response t= o a Poll, it continues to use the current BFD session parameters and MAY sen= d additional Polls (presumably one per second) in hopes of soliciting a Fina= l.  I don't think we need to say anything more about what the sender of a Poll needs to do.<br> ><br> > We need Poll/Final to transition to UP state, so I think what cc-cv-rdi= needs to say is that a node which does not support Poll/Final in UP state s= imply ignores a Poll.<br> <br> Why do we need P/F to transition to up?  We need it once up to renegoti= ate our timers.<br> <br> -- Jeff<br> <br> ><br> > Thanks,<br> ><br> > John<br> ><br> > Sent from my iPhone<br> ><br> ><br> >> -----Original Message-----<br> >> From: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx"= target=3D"_blank"> mpls-bounces@ietf.org</a> [<a href=3D"mailto:mpls-bounces@ietf.org">mailto:m= pls-bounces@ietf.org</a>] On Behalf Of<br> >> David Allan I<br> >> Sent: Tuesday, May 03, 2011 3:01 PM<br> >> To: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" t= arget=3D"_blank"> erminio.ottone_69@libero.it</a>; <a href=3D"https://mail.ecitele.com/OWA/Url= BlockedError.aspx" target=3D"_blank"> mpls@ietf.org</a><br> >> Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi<br> >><br> >> Hi Ermino:<br> >><br> >> I stand corrected. I got lots of private feedback to the effect tha= t<br> >> current implementations see a "final" response as agreeme= nt to the<br> >> parameters in a poll. Hence changing that semantic is not a good id= ea.<br> >><br> >> The alternative discussed was what an implementation does when a po= ll<br> >> is not responded to in a resonable amount of time, which can be<br> >> interpreted as a refusal to change by the far end, or non-<br> >> implementation of P/F in steady state. At which point an implementi= on's<br> >> options are to live with the status quo or take the session down.<b= r> >><br> >> Feedback welcome!<br> >> Dave<br> >><br> >> -----Original Message-----<br> >> From: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx"= target=3D"_blank"> mpls-bounces@ietf.org</a> [<a href=3D"mailto:mpls-bounces@ietf.org">mailto:m= pls-bounces@ietf.org</a>] On Behalf Of<br> >> <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" targe= t=3D"_blank">erminio.ottone_69@libero.it</a><br> >> Sent: Monday, May 02, 2011 2:54 PM<br> >> To: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" t= arget=3D"_blank"> mpls@ietf.org</a><br> >> Subject: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi<br> >><br> >> Forwarding the messate to the MPLS WG mailing list ...<br> >><br> >>> ----Messaggio originale----<br> >>> Da: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.asp= x" target=3D"_blank"> erminio.ottone_69@libero.it</a><br> >>> Data: 2-mag-2011 23.19<br> >>> A: <<a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.= aspx" target=3D"_blank">david.i.allan@ericsson.com</a>><br> >>> Ogg: R: [mpls] FW: Poll / Final in draft-cc-cv-rdi<br> >>><br> >>>> We would also observe that it is permissable in the specifi= cation to<br> >> respond<br> >>>> to a poll with a final reply with the session parameters un= changed.<br> >> So<br> >>>> once a session is up a compliant implementation does not ac= tually<br> >> have<br> >>>> to implement on the fly changes to session paramters. The p= rocessing<br> >>>> of the poll bit can simply be reduced to setting the final= bit in the<br> >>>> next<br> >> message.<br> >>>> This would permit implementations to optimize the UP proces= sing loop.<br> >>><br> >>> How this is possible?<br> >>><br> >>> Section 6.8.7 of RFC 5880 states that:<br> >>><br> >>>  With the exceptions listed in the remainder of this secti= on, a<br> >> system<br> >>>  MUST NOT transmit BFD Control packets at an interval less= than the<br> >>>  larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInt= erval,<br> >> less<br> >>>  applied jitter (see below).<br> >>><br> >>> If the Poll requires a longer bfd.RemoteMinRxInterval, how can= the<br> >>> system ignore the request?<br> >>><br> >>>> ----Messaggio originale----<br> >>>> Da: <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError= .aspx" target=3D"_blank"> david.i.allan@ericsson.com</a><br> >>>> Data: 20-apr-2011 17.29<br> >>>> A: "<a href=3D"https://mail.ecitele.com/OWA/UrlBlocked= Error.aspx" target=3D"_blank">mpls@ietf.org"<mpls</a>@ietf.org><b= r> >>>> Cc: "Ross Callon"<<a href=3D"https://mail.ecit= ele.com/OWA/UrlBlockedError.aspx" target=3D"_blank">rcallon@juniper.net</a>&= gt;<br> >>>> Ogg: [mpls] FW: Poll / Final in draft-cc-cv-rdi<br> >>>><br> >>>> Hi Folks:<br> >>>><br> >>>> We've received a number of comments both formally and infor= mally that<br> >>>> the current draft has deviated too far from the base BFD sp= ec and<br> >> thus<br> >>>> loses backward compatibility with existing code bases. &nbs= p;Further,<br> >>>> discussions with the BFD WG have indicated we have a potent= ial race<br> >>>> condition in the current startup procedures described in dr= aft-cc-cv-<br> >> rdi.<br> >>>><br> >>>> The issue is the transition to UP state requires confirmati= on by the<br> >>>> peer MEP prior to changing the detection time to the rx-int= erval x<br> >>>> detect mult<br> >> in<br> >>>> order to avoid potential flapping. This can result in an<br= > >>>> implementation effectively needing two UP states (UP forwar= d, UP<br> >> reverse direction).<br> >>>> Otherwise the MEP may time out the reverse direction before= seeing an<br> >>>> UP state from the peer MEP.<br> >>>><br> >>>> So we can make this implicit in the specification and requi= re BFD<br> >>>> changes<br> >> or<br> >>>> we can use poll/final discipline on startup as defined in t= he base<br> >>>> specification and make the transition to fully UP and the d= esired<br> >> rate<br> >>>> both explicit and exposed in the protocol exchange. This wo= uld reduce<br> >>>> the deltas between the base spec (RFC 5880) and draft CC-CV= -RDI.<br> >>>><br> >>>> We would also observe that it is permissable in the specifi= cation to<br> >> respond<br> >>>> to a poll with a final reply with the session parameters un= changed.<br> >> So<br> >>>> once a session is up a compliant implementation does not ac= tually<br> >> have<br> >>>> to implement on the fly changes to session paramters. The p= rocessing<br> >>>> of the poll bit can simply be reduced to setting the final= bit in the<br> >>>> next<br> >> message.<br> >>>> This would permit implementations to optimize the UP proces= sing loop.<br> >>>><br> >>>> This is a change of direction from what has been in the dra= ft to<br> >> date,<br> >> hence<br> >>>> we'd look to the WG for comment on this change...<br> >>>><br> >>>> the editors<br> >>>> Dave, John and George...<br> >>>><br> >>>><br> >>>> _______________________________________________<br> >>>> mpls mailing list<br> >>>> <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.asp= x" target=3D"_blank"> mpls@ietf.org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/mpls</a><br> >>>><br> >>><br> >>><br> >><br> >><br> >> _______________________________________________<br> >> mpls mailing list<br> >> <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" targe= t=3D"_blank">mpls@ietf.org</a><br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/mpls</a><br> >> _______________________________________________<br> >> mpls mailing list<br> >> <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" targe= t=3D"_blank">mpls@ietf.org</a><br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/mpls</a><br> <br> _______________________________________________<br> mpls mailing list<br> <a href=3D"https://mail.ecitele.com/OWA/UrlBlockedError.aspx" target=3D"_bla= nk">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/mpls</a><br> <br> </span></font></blockquote> </div> </div> <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. </p> </body> </html> --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C918ILPTMAIL02eci_-- From ice@cisco.com Wed May 4 23:40:55 2011 Return-Path: <ice@cisco.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 8B668E06EC for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 23:40:55 -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 wVQV5UfiTBUW for <mpls@ietfa.amsl.com>; Wed, 4 May 2011 23:40:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AA453E06AF for <mpls@ietf.org>; Wed, 4 May 2011 23:40:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p456erMs019904; Thu, 5 May 2011 08:40:53 +0200 (CEST) Received: from ams-iwijnand-8717.cisco.com (ams-iwijnand-8717.cisco.com [10.55.191.152]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p456elma008346; Thu, 5 May 2011 08:40:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands <ice@cisco.com> X-Priority: 3 (Normal) In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Date: Thu, 5 May 2011 08:40:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: <10F4BDA7-A7D8-44D0-B073-8826E80C1EFA@cisco.com> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> To: loa@pi.nu X-Mailer: Apple Mail (2.1081) 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 <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: Thu, 05 May 2011 06:40:55 -0000 yes/support On 27 Apr 2011, at 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 skraza@cisco.com Thu May 5 09:14:33 2011 Return-Path: <skraza@cisco.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 27A29E08A5; Thu, 5 May 2011 09:14:33 -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 9FHGSgoVhljC; Thu, 5 May 2011 09:14:29 -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 03B6EE0779; Thu, 5 May 2011 09:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=1318; q=dns/txt; s=iport; t=1304612068; x=1305821668; h=date:subject:from:to:cc:message-id:mime-version: content-transfer-encoding; bh=PPqUdXFO5ZCKCzt0qwpTyPcCNzXN9j873PH8Pl1sBIM=; b=F6+MUpmCihYe6GRp4bRIOdFGunBFHKB15n6VvE8pU/23wCS73lfVoy8d hHpuqcFAHWWP4ODv+ucqEU6ncUOhaTHiaGgJmES8F6uH/oDcpFZ4SNKOg APtdXW+C5CwBTAKKpjdZuo818iozjodokBJYO4xOrzgWl1ZHcHxSANSuK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusIAJ7Mwk2tJXHB/2dsb2JhbACYVo1nd6csnjCGBwSPSoQsij8 X-IronPort-AV: E=Sophos;i="4.64,320,1301875200"; d="scan'208";a="232475247" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 05 May 2011 16:14:27 +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 p45GEQdm029509; Thu, 5 May 2011 16:14:26 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 11:14:26 -0500 Received: from 10.86.254.128 ([10.86.254.128]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 May 2011 16:14:26 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 05 May 2011 12:15:28 -0400 From: Kamran Raza <skraza@cisco.com> To: <pwe3@ietf.org> Message-ID: <C9E84560.19AC9%skraza@cisco.com> Thread-Topic: Seeking feedback/comments on I-D "LDP Typed Wildcard PW FEC Elements" Thread-Index: AcwLP6XV1miX2H8qoEK7H055dP9t5w== X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 May 2011 16:14:26.0170 (UTC) FILETIME=[80FB4DA0:01CC0B3F] Cc: Sami Boutros <sboutros@cisco.com>, andrew.g.malis@one.verizon.com, mpls@ietf.org Subject: [mpls] Seeking feedback/comments on I-D "LDP Typed Wildcard PW FEC Elements" 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: Thu, 05 May 2011 16:14:33 -0000 We had presented "LDP Typed Wildcard PW FEC Elements" I-D at IETF79 and IETF80 [http://tools.ietf.org/html/draft-raza-pwe3-pw-typed-wc-fec-00], which defines LDP Typed Wildcard FEC elements for PW FECs types (FEC128 PW-Id, and FEC 129 Generalized PW-Id). We (the authors) are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list. I-D Abstract: An extension to the Label Distribution Protocol (LDP) defines the general notion of a "Typed Wildcard Forwarding Equivalence Class (FEC) Element". This can be used when it is desired to request all label bindings for a given type of FEC Element, or to release or withdraw all label bindings for a given type of FEC element. However, a typed wildcard FEC element must be individually defined for each type of FEC element. This specification defines the typed wildcard FEC elements for the Pseudowire Identifier (PW Id) and Generalized Pseudowire Identifier (Gen. PW Id) FEC types. [P.S: This I-D was previously submitted as L2VPN WG doc http://tools.ietf.org/html/draft-raza-l2vpn-pw-typed-wc-fec-01, but was later resubmitted to PWE3 WG] Thanks. -- Syed Kamran Raza, Sami Boutros Cisco Systems, Inc., http://www.cisco.com From Robert.Rennison@ecitele.com Thu May 5 09:21:25 2011 Return-Path: <Robert.Rennison@ecitele.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 9D8F4E0760 for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 ZDcqsCUnf6Mh for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 09:21:25 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id 01BB3E06D8 for <mpls@ietf.org>; Thu, 5 May 2011 09:21:24 -0700 (PDT) X-AuditID: 3f5e7f87-b7b02ae000002401-b6-4dc2f5419c5b Received: from uspitexch02.ecitele.com ( [10.0.0.72]) by uspitbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 05.60.09217.145F2CD4; Thu, 5 May 2011 15:06:41 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Thu, 5 May 2011 12:21:23 -0400 From: Robert Rennison <Robert.Rennison@ecitele.com> To: Jeff Haas <jhaas@juniper.net>, George Swallow <swallow@cisco.com> Date: Thu, 5 May 2011 12:21:22 -0400 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwKnRrIkRPT+iXlSFiypvm2F8E+MAAn4xug Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7C2892A@USPITMAIL01.ecitele.com> References: <C9E71D75.3337A%swallow@cisco.com> <4B4FF155-0681-4E40-BF93-872B2868E6C0@juniper.net> In-Reply-To: <4B4FF155-0681-4E40-BF93-872B2868E6C0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTURz37G7zOr1yna/j8sO4yQhN2/LRypmGFBqJQoXUh+y6nbaL293Y naIRtJRS1sMHRrisNGZZSD4SS4rSQUGSpGGKWommgZZfzIiMonudmdH59Puf3+P8OfxwTO6R KnCGdSA7S5spqUws8/PLit/z1Zujnq5XaJ/9rBJre65otRMtdyTayfpykCHOqv/RKcnyeL6L ssbK3/jnYUedQEezrNVBO5DSgDh9GpVnZ0pofRmlZAxplIZS2sy0HlkQ60ijaJsNsQZqt0z5 39HxMoZVIlZvNTCsMY3KPpgbr9Um74zXULtVmzWJqbJDJoZTongLzZiVFsRxtBEp+Zvj3Zip 591Ff9v1kNILZ1swJxgnXADHIZkEf5ZHuUAADyPg0Pt2qQvIcDn5AMBrM3P+vuE8gBU1M5ig kpKJsGNpUCKYw8i90L14UrjGyEy43PBEKmAxGQMHWnpX5aFkKhwd/yIWcBipgy/bJjEf3g77 PtesYoLMg9Nd/asaOamHtcNzEgEHkOnQNby8igG/3LeBNpHvrUg4MXtD5FuahJ7HrzAfDofz H36t6cPh28p24NNvhU2PlqQ+HAdvNX9aezcEvmiYFdeACPeGWPcGi3uDxb3B0gTEd0FEMWdj HIUWo1qTgPSMA5lRgt5q6QJ8S9KPna58CKrrY70gChdR4QQa9ObIgwuthjITzZkK7MVmxHmB lv+sWkwRqLfyDWMdBYlq9T8DFUn0Vnly5KSRr04RQjZk/2ONxnEKElNCbIgdGVHpCcbs+EuL 8AAvgHgQFUYcFjQEZ6MtHGP08QMgShFJuASCFAhTMbvuXQCROKBCifQ+ng3iq7/uWuADRXzg /oo+IZCv8zqlcIL7mDs8ZSgm5FxC0sN9LYNHAraNYprmJHdddkdM5tHei/Mf8dbLlmaySrVF Z5/xx7q9GTeDTzl3LEhWqocTnM8vdfZ3LhIrKc8bR8z0yL1dRU+Xk8dv6/KvzuaPqTdN1EVM NXTXRMfUxan6VNm/ctUH8kryzzSqpgLTqW3S1tfllJgz0ZpYzM7RvwHeebdytwMAAA== Cc: "mpls@ietf.org" <mpls@ietf.org>, David Ward <dward@juniper.net> Subject: Re: [mpls] I: 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 <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: Thu, 05 May 2011 16:21:25 -0000 Jeff, Looks like folks are finally on the same page wrt the importance of the P/F= and its necessity in getting from a slow initial rate to the desired rate,= see my prior email for a detailed description of this. I think we are in agreement that once at the non default rate then support= for further/additional rate changes is not necessary. Now that we are in agreement we do not want to lose this subtle understandi= ng. Hence we should tread very carefully regarding giving any latitude to non su= pport for P/F. _If_ any statement is given regarding non support for P/F it will have to be= a conditional statement i.e of the form George states but with additional= qualifications "After an initial P/F exchange to go from an initial rate t= o the one you want _then_ an implementation may choose to ignore further r= ate modification by simple not responding to subsequent Polls" If we go with your proposal of "the application can choose when they respond= to polls" then we have lost the fact that the response to P/F is necessary= in order to get from the slow initial rate to the operators desired rate. = Someone reading this could end up thinking ok, I do not need to implement P= /F which then leads to non-interoperable implementations since we cannot go= from the slow rate to the desired one. Cheers Rob Rennison -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff= Haas Sent: Wednesday, May 04, 2011 4:52 PM To: George Swallow Cc: David Ward; mpls@ietf.org Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi George, On May 4, 2011, at 3:12 PM, George Swallow wrote: This is my view as well. You come up slow, use P/F to get to the rate you w= ant. After that you can ignore P/F. I'm not a huge fan of generally saying "then you can ignore P/F" but I'm fin= e with "the application can choose when they respond to polls". Mostly same thing from a practical implementation standpoint for TP. -- Jeff _______________________________________________ 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 jhaas@juniper.net Thu May 5 10:05:46 2011 Return-Path: <jhaas@juniper.net> 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 1F930E07AB for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 10:05:46 -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 LvAvRq+5pGSe for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 10:05:45 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 49616E07A0 for <mpls@ietf.org>; Thu, 5 May 2011 10:05:45 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTcLY5QZDiTLIJ+9f2qr0QRD+diqN2kqU@postini.com; Thu, 05 May 2011 10:05:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 5 May 2011 10:05:06 -0700 From: Jeff Haas <jhaas@juniper.net> To: Robert Rennison <Robert.Rennison@ecitele.com> Date: Thu, 5 May 2011 10:05:05 -0700 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwLRpUFn9meNAC0Tj2f5Ppu2bnd4Q== Message-ID: <041BB75F-C746-45C4-BC16-244402974489@juniper.net> References: <C9E71D75.3337A%swallow@cisco.com> <4B4FF155-0681-4E40-BF93-872B2868E6C0@juniper.net> <786AD2EC3D80A1428B921CDC9BE9EE546BB7C2892A@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546BB7C2892A@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 Cc: "mpls@ietf.org" <mpls@ietf.org>, David Ward <dward@juniper.net> Subject: Re: [mpls] I: 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 <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: Thu, 05 May 2011 17:05:46 -0000 Rob, On May 5, 2011, at 12:21 PM, Robert Rennison wrote: > _If_ any statement is given regarding non support for P/F it will have to= be a conditional statement i.e of the form George states but with additio= nal qualifications "After an initial P/F exchange to go from an initial ra= te to the one you want _then_ an implementation may choose to ignore furt= her rate modification by simple not responding to subsequent Polls" This was what I had meant. >=20 > If we go with your proposal of "the application can choose when they resp= ond to polls" then we have lost the fact that the response to P/F is necess= ary in order to get from the slow initial rate to the operators desired rat= e. Someone reading this could end up thinking ok, I do not need to impleme= nt P/F which then leads to non-interoperable implementations since we canno= t go from the slow rate to the desired one. Not this. To add a clarification, one possible response to a complete unwanted change= of timer parameters is simply to tear down the BFD session. This complete= ly removes the ambiguity when viewing timer request changes at the protocol= level by reacting quickly rather than leaving a pending request unacknowle= dged. I suspect that this wouldn't be a preferred mode of operation for th= e MPLS-TP case though. -- Jeff From Robert.Rennison@ecitele.com Thu May 5 10:55:28 2011 Return-Path: <Robert.Rennison@ecitele.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 A5725E067F for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 Nv3yJsZW+B+Y for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 10:55:28 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id ED17EE0675 for <mpls@ietf.org>; Thu, 5 May 2011 10:55:26 -0700 (PDT) X-AuditID: 3f5e7f87-b7b02ae000002401-4f-4dc30b4b3ed5 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 78.70.09217.B4B03CD4; Thu, 5 May 2011 16:40:44 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Thu, 5 May 2011 13:55:25 -0400 From: Robert Rennison <Robert.Rennison@ecitele.com> To: Jeff Haas <jhaas@juniper.net> Date: Thu, 5 May 2011 13:55:24 -0400 Thread-Topic: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Thread-Index: AcwLRpUFn9meNAC0Tj2f5Ppu2bnd4QABmymQ Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB7C28935@USPITMAIL01.ecitele.com> References: <C9E71D75.3337A%swallow@cisco.com> <4B4FF155-0681-4E40-BF93-872B2868E6C0@juniper.net> <786AD2EC3D80A1428B921CDC9BE9EE546BB7C2892A@USPITMAIL01.ecitele.com> <041BB75F-C746-45C4-BC16-244402974489@juniper.net> In-Reply-To: <041BB75F-C746-45C4-BC16-244402974489@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WTaUwTQRiGne62bgvVtXIMlR9lPGJUSCsY1wBqDFEkEvGKxh/q0o7txna7 6RbEXzYIUdEEMRigKHhURaMiSvCMYpUYvG8DGAhHRCGKFhKvgG5ZRYzz65353vf5JpNvKEJX o9JTHO/GLp61I5WG1IwZsyR2WcjtdGMpwzQM7iKZuhKGaT5+Ssm0FOeChWRq8Y8aZarP902R +jr35dgMYr0HJLE873SzbmywYNGcjDJcXDZr3oYMnCUZmZBBsLNm7MC8OxmxgoB5C5qvMfy3 kiQbxxswb3ZaON6ajJauWh7LMHPmxZrQ/GmTTfGJmtU2TjTgWAfL2Q0OLIqsFRukk021hK3o 6n6FUDU+523Jd9IDCkMLgJqCdAK8+GxIIesI+KS1WlUANJSOvgTg5eeXSHmzB8Bu7zsy6FLR 8fB84KGyAFBUGB0D257PCx4TNAdvFQ2CoCbpKbC7t08V1BPpRPiqqX84GkYnwQdnWghZz4aP AnnDHi2dAQNlB373agPQUzkwXFDTC2DJ3rxhKJBu9+XeGYXcLBI2d1X+vjUNfdcfE7IOh+87 h5SyPxy+2VkNZP8sePhaQCXrmfDEkV5CbjwBNpZ1kftAhHcU1jsq4h0V8Y6KHAbkaRCRJQqc O9NhNZrisJlzYzuOMzsdF4A0Jgs2bN95GRQWz/CDKEqBwrWo3Z+uG5fptGyzsaJtoyvLjkU/ YKTXKiL0IWanNGK8e2O80fjPBkVqr+zypetoqzQ8WzAWsOtPNJqiENRe7ZSwE1zYinM2c3b3 37KCUvsBpEJRmFbokDxaUWAdImeV6/fAVKp2j6ce6EjeyWN9pPZhEEQHTbYsfoTTAyIpgCbK bUKlfzBC6JHgCgmetqM+CJeGe6Sk94C0m+cafq5jV3wmssm6p42NBeV6/6ujW6Nv9TdWq9W9 awYPbr1+YbGy/nFFVeBQeVNufAJa1KrJicp/1F3HqFY21DQTH+HuFfTg05yY2oGzKYrWgamW Y7bp91/cMH44WRU3pbPDXpqSWfrlYpfw6e7KtrVxX/MnfV2uUff3tVfMZe4gUrSxphmES2R/ AVsV7EDEAwAA Cc: "mpls@ietf.org" <mpls@ietf.org>, David Ward <dward@juniper.net> Subject: Re: [mpls] I: 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 <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: Thu, 05 May 2011 17:55:28 -0000 Jeff, Ok, we are all back in same-page state, so that's good. Re your clarification saying that an application may bring down a session if= the peer tries an unwanted change of parameter; yes you _could_ tear the se= ssion down but I do not think this is a "nice" /desired behavior so do not= recommend we go down this path. Cheers Rob -----Original Message----- From: Jeff Haas [mailto:jhaas@juniper.net] Sent: Thursday, May 05, 2011 1:05 PM To: Robert Rennison Cc: George Swallow; David Ward; mpls@ietf.org Subject: Re: [mpls] I: FW: Poll / Final in draft-cc-cv-rdi Rob, On May 5, 2011, at 12:21 PM, Robert Rennison wrote: > _If_ any statement is given regarding non support for P/F it will have to= be a conditional statement i.e of the form George states but with addition= al qualifications "After an initial P/F exchange to go from an initial rate= to the one you want _then_ an implementation may choose to ignore further= rate modification by simple not responding to subsequent Polls" This was what I had meant. > > If we go with your proposal of "the application can choose when they respo= nd to polls" then we have lost the fact that the response to P/F is necessar= y in order to get from the slow initial rate to the operators desired rate.= Someone reading this could end up thinking ok, I do not need to implement= P/F which then leads to non-interoperable implementations since we cannot g= o from the slow rate to the desired one. Not this. To add a clarification, one possible response to a complete unwanted change= of timer parameters is simply to tear down the BFD session. This completel= y removes the ambiguity when viewing timer request changes at the protocol l= evel by reacting quickly rather than leaving a pending request unacknowledge= d. I suspect that this wouldn't be a preferred mode of operation for the MP= LS-TP case though. -- Jeff 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 Internet-Drafts@ietf.org Thu May 5 11:30:20 2011 Return-Path: <Internet-Drafts@ietf.org> 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 093C3E07D8; Thu, 5 May 2011 11:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 8GKTubKG8hmA; Thu, 5 May 2011 11:30:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7BE094A; Thu, 5 May 2011 11:30:03 -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.53 Message-ID: <20110505183003.11091.93881.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 11:30:03 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-fault-04.txt 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: Thu, 05 May 2011 18:30:20 -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 Fault Management OAM Author(s) : G. Swallow, et al Filename : draft-ietf-mpls-tp-fault-04.txt Pages : 15 Date : 2011-04-26 This draft specifies OAM messages to indicate service disruptive conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-04.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-fault-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05112800.I-D@ietf.org> --NextPart-- From venkatflex@gmail.com Thu May 5 12:21:58 2011 Return-Path: <venkatflex@gmail.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 34CF1E07FD for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 12:21:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzB7IF2fMW6i for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 12:21:57 -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 55213E067C for <mpls@ietf.org>; Thu, 5 May 2011 12:21:57 -0700 (PDT) Received: by qyk29 with SMTP id 29so3824757qyk.10 for <mpls@ietf.org>; Thu, 05 May 2011 12:21:56 -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=Ft6iFU9Kw4jbOHa8ebid7Olfqk2S+7YO9WOVCi+zZIo=; b=CG8N7ci/rG0FKTWTqZY7rFj5vfnm3zWALHATtU/vR2Idsh5bOKtAWZGbv9SRWsSC0o a1UFwJFUvp/IW8phWhP8Jh8jUQfLTEQyF4b2wb3z8+2UBdvi0bBShGWuVlsTeRV+zFal xGzX4GhyneVYTEgxlZHfp+dc+3f2XTzZy3WPA= 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=vDUYliFJRE8klewtkUFFzC0zTwA1ovVY58zPrfvKQJrYaeGca25CKgG/qp+5zpecLr VSmObtbE6BqkEXLId5RGAnvgHb/B6HPMj1mSO4p57+n4665vWl5qAE8/peZjukhKge76 J1UYQTQ8mDZzZ/MabReztEOWPHWH1YkL5w1sY= MIME-Version: 1.0 Received: by 10.52.184.5 with SMTP id eq5mr445683vdc.219.1304623316305; Thu, 05 May 2011 12:21:56 -0700 (PDT) Received: by 10.52.109.9 with HTTP; Thu, 5 May 2011 12:21:56 -0700 (PDT) Date: Thu, 5 May 2011 15:21:56 -0400 Message-ID: <BANLkTi=1_j7PaiAGm3WX9VVVU9FyUX4bPg@mail.gmail.com> From: venkatesan mahalingam <venkatflex@gmail.com> To: loa@pi.nu, mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec5485ac0558cfc04a28c4931 Cc: rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Thu, 05 May 2011 19:21:58 -0000 --bcaec5485ac0558cfc04a28c4931 Content-Type: text/plain; charset=ISO-8859-1 Yes/Support. Regards, Venkat. ________________________________________ From: Scott Mansfield [scott.mansfield@ericsson.com] Sent: Wednesday, May 04, 2011 1:49 AM To: loa@pi.nu; mpls@ietf.org Cc: rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: RE: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt Yes/support > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of loa@pi.nu > Sent: Tuesday, May 03, 2011 1:48 PM > To: mpls@ietf.org > Cc: rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org > Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec5485ac0558cfc04a28c4931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Yes/Support.</div><div><br></div><div>Regards,</div><div>Venkat.</div>= <div>________________________________________</div><div>From: Scott Mansfie= ld [<a href=3D"mailto:scott.mansfield@ericsson.com">scott.mansfield@ericsso= n.com</a>]</div> <div>Sent: Wednesday, May 04, 2011 1:49 AM</div><div>To: <a href=3D"mailto:= loa@pi.nu">loa@pi.nu</a>; <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a= ></div><div>Cc: <a href=3D"mailto:rcallon@juniper.net">rcallon@juniper.net<= /a>; <a href=3D"mailto:draft-vkst-mpls-tp-te-mib@tools.ietf.org">draft-vkst= -mpls-tp-te-mib@tools.ietf.org</a></div> <div>Subject: RE: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt</div><div= ><br></div><div>Yes/support</div><div><br></div><div>> -----Original Mes= sage-----</div><div>> From: <a href=3D"mailto:mpls-bounces@ietf.org">mpl= s-bounces@ietf.org</a> [mailto:<a href=3D"mailto:mpls-bounces@ietf.org">mpl= s-bounces@ietf.org</a>] On</div> <div>> Behalf Of <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a></div><div>&g= t; Sent: Tuesday, May 03, 2011 1:48 PM</div><div>> To: <a href=3D"mailto= :mpls@ietf.org">mpls@ietf.org</a></div><div>> Cc: <a href=3D"mailto:rcal= lon@juniper.net">rcallon@juniper.net</a>; <a href=3D"mailto:draft-vkst-mpls= -tp-te-mib@tools.ietf.org">draft-vkst-mpls-tp-te-mib@tools.ietf.org</a></di= v> <div>> Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt</div><di= v>></div><div>></div><div>> Working Group,</div><div>></div><di= v>> this is to start a two week poll on making</div><div>></div><div> > draft-vkst-mpls-tp-te-mib-00.txt</div><div>></div><div>> an mpls= working group document.</div><div>></div><div>> If you support the d= ocument becoming a working group document</div><div>> please respond to = this poll with "yes/support"</div> <div>></div><div>> If you do not support the document becoming a work= ing group</div><div>> document please respond to this poll with "no= /do not support"</div><div>> and at the same time give the technica= l reasons why you are</div> <div>> not supporting the document.</div><div>></div><div>> If you= have technical comments or in any other way want to</div><div>> discuss= the document, please send these comments to the mpls</div><div>> workin= g group mailing list, but with another subject than</div> <div>> what is on this mail.</div><div>></div><div>> The poll ends= 2011-05-18.</div><div>></div><div>> /Loa</div><div>></div><div>&g= t;</div><div>> _______________________________________________</div> <div>> mpls mailing list</div><div>> <a href=3D"mailto:mpls@ietf.org"= >mpls@ietf.org</a></div><div>> <a href=3D"https://www.ietf.org/mailman/l= istinfo/mpls">https://www.ietf.org/mailman/listinfo/mpls</a></div><div>>= </div> <div><br></div> --bcaec5485ac0558cfc04a28c4931-- From internet-drafts@ietf.org Thu May 5 13:14:09 2011 Return-Path: <internet-drafts@ietf.org> 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 73BC9E08C2; Thu, 5 May 2011 13:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 rO+VbI2AD1TG; Thu, 5 May 2011 13:14:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C5E06A4; Thu, 5 May 2011 13:14:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505201408.3478.35019.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 13:14:08 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-00.txt 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: Thu, 05 May 2011 20:14:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : The Use of Entropy Labels in MPLS Forwarding Author(s) : Kireeti Kompella John Drake Shane Amante Wim Henderickx Lucy Yong Filename : draft-ietf-mpls-entropy-label-00.txt Pages : 25 Date : 2011-05-04 Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defin= es the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-entropy-label-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-entropy-label-00.txt From Internet-Drafts@ietf.org Thu May 5 15:00:03 2011 Return-Path: <Internet-Drafts@ietf.org> 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 0B1DFE076E; Thu, 5 May 2011 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 LGWQWv2MAEPZ; Thu, 5 May 2011 15:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58672E074D; Thu, 5 May 2011 15: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.53 Message-ID: <20110505220002.5418.47661.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 15:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-loss-delay-02.txt 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: Thu, 05 May 2011 22: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 : Packet Loss and Delay Measurement for MPLS Networks Author(s) : D. Frost, et al Filename : draft-ietf-mpls-loss-delay-02.txt Pages : 50 Date : 2011-04-20 Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-loss-delay-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-loss-delay-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05145036.I-D@ietf.org> --NextPart-- From kkoushik@cisco.com Thu May 5 19:50:31 2011 Return-Path: <kkoushik@cisco.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 AF639E0670 for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 19:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_OTHER=0.135] 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 A9kqWPWvct7m for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 19:50:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3AE0663 for <mpls@ietf.org>; Thu, 5 May 2011 19:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkoushik@cisco.com; l=2022; q=dns/txt; s=iport; t=1304650230; x=1305859830; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=r+Cb4c4gQg8sAAE1HhhnH+GlwTDrTVz7GtahhXXZuBM=; b=DBhsL3nCa6W3TLuUHPAYgw8nPTMwm+CRsOCgkGtaslCJMR5L5NCYU3RO Q/mcxdg1QvDUMN1haxgEkz4zrYHJnY3ZKpRfzmxr08wdrGYtjlChmEgTx CS2MeQd2fOSJmrdkOZO7fNEuQ1lmYvA0tVVgH9Fkuc6nzjZsV6KFRYzmS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusBADdhw02Q/khMgWdsb2JhbACYGUCNZhQBARYmJadrnhqGBwSGOIkSjm0 X-IronPort-AV: E=Sophos;i="4.64,324,1301875200"; d="scan'208";a="28899398" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 May 2011 02:50:29 +0000 Received: from bxb-kkoushik-8711.cisco.com (bxb-kkoushik-8711.cisco.com [10.98.73.146]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p462oSEP019389 for <mpls@ietf.org>; Fri, 6 May 2011 02:50:29 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Agrahara Kiran Koushik <kkoushik@cisco.com> In-Reply-To: <12A29AB720570C4BBBBD1BAD0236FD4005E2C90C5A@GUREXMB02.ASIAN.AD.ARICENT.COM> Date: Thu, 5 May 2011 21:54:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B39AC51-2DCA-4A04-A1B8-BFCADFB6E5A8@cisco.com> References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu>, <FDC72027C316A44F82F425284E1C4C320B0F424C1F@EUSAACMS0701.eamcs.ericsson.se> <12A29AB720570C4BBBBD1BAD0236FD4005E2C90C5A@GUREXMB02.ASIAN.AD.ARICENT.COM> To: mpls@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Fri, 06 May 2011 02:50:31 -0000 Support. - Kiran Koushik. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of loa@pi.nu >> Sent: Tuesday, May 03, 2011 1:48 PM >> To: mpls@ietf.org >> Cc: rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org >> Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt >>=20 >>=20 >> Working Group, >>=20 >> this is to start a two week poll on making >>=20 >> draft-vkst-mpls-tp-te-mib-00.txt >>=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 2011-05-18. >>=20 >> /Loa >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=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 privileged 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 message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." From mach.chen@huawei.com Thu May 5 20:16:21 2011 Return-Path: <mach.chen@huawei.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 91DD0E0669 for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 20:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=1.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 obrAoxTGTtxi for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 20:16:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB801E0593 for <mpls@ietf.org>; Thu, 5 May 2011 20:16:20 -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 <0LKR0015O7OM9M@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 06 May 2011 11:14:46 +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 <0LKR00B5M7OMP8@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 06 May 2011 11:14:46 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 06 May 2011 11:14:38 +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; Fri, 06 May 2011 11:14:45 +0800 Date: Fri, 06 May 2011 03:14:12 +0000 From: Mach Chen <mach.chen@huawei.com> In-reply-to: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> X-Originating-IP: [10.110.98.39] To: "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org> Message-id: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2F99F35@SZXEML502-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: zh-CN, en-US Thread-topic: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt Thread-index: AQHMCbqSQ/D7g47zQEWpT2o+xeToTZR/I+mw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Cc: "rcallon@juniper.net" <rcallon@juniper.net>, "draft-vkst-mpls-tp-te-mib@tools.ietf.org" <draft-vkst-mpls-tp-te-mib@tools.ietf.org> Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Fri, 06 May 2011 03:16:21 -0000 Yes/support. Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Wednesday, May 04, 2011 1:48 AM > To: mpls@ietf.org > Cc: rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org > Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Thu May 5 22:16:22 2011 Return-Path: <Alexander.Vainshtein@ecitele.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 15036E0663 for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 22:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 7i7Bam1nlkww for <mpls@ietfa.amsl.com>; Thu, 5 May 2011 22:16:20 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id F1E12E0593 for <mpls@ietf.org>; Thu, 5 May 2011 22:16:18 -0700 (PDT) X-AuditID: 93eaf2e8-b7c8fae000000a6f-db-4dc383bdc03e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id B6.8E.02671.DB383CD4; Fri, 6 May 2011 08:14:37 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 6 May 2011 08:16:16 +0300 From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> To: "rcallon@juniper.net" <rcallon@juniper.net>, Loa Andersson <loa@pi.nu> Date: Fri, 6 May 2011 08:16:13 +0300 Thread-Topic: My WG LC comments on draft-ietf-mpls-tp-fault-03 not addressed in the -04 version Thread-Index: AcwLrLej7FBs9A/lRkigLii91f3Krg== Message-ID: <A3C5DF08D38B6049839A6F553B331C76E9BD6CD839@ILPTMAIL02.ecitele.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_A3C5DF08D38B6049839A6F553B331C76E9BD6CD839ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTQRh2drftWlmzVGpHPLKuVzyKIGKWaNUYjZXYiFFfjIku7dhubLdN txIxRgmKB/jgUQ+qRowIikQjIfFAFItHRGIxgniA0YAE8UUJWo9o3WUFSYzz9M3/Hfln8v8k bijTJZKCGEB+kXezWj1xuLun11yzs86W/DaP4fZcvQG4S+86Me7ez70E9+vUSZxrvdGr4eoK 2gD38twFDffzfBPB3Q/2AO5VMA8s1FvzO2s01uCPKxrr98/NWmtJyTfM2pLXrLOGju3WWvOj xkzd2lwwjxdFb4APIMaBJLuFzfQL2bw9h2UEh4VNYRmfm7cjDxIDFpb3+ZDoYOfrmX/OPFkm iAwS7V6HIDot7LJVK8wcl5ZuTmHnT56QkjpXv9olSAwye3jBzXiQJPFOxMiVDVW461TxA52v hd1y/3u5LheUjisAQ0lIz4Yfj5fjKh4JG19f1hYAPWmgqwE8cmgfpl6OANj17J5WUWlpC6y8 2NaHE+gM+CDc2ifC6dsE7CiMEApB0BNh2aPjfXgEvQ5er2rUqQYetkSOYipOgrtDFzUKpugV sKYwChQM5Dai9RV9Gpw2wZcdpzG1PRqW3Iz8adUI37f/0qh6I2zdcxmoei/s7Lj2JzMePizq IFT9KHjn/HPiAEgIDYoNDbKEBlnU+gxYXN2jVfF0WHrmA96PG2rbscH1YqArB0bB7QtkeZzJ s5KQXQggN0qyez2VQJ2yrmvgVcPUMKBJwMZRQlXYZtDw2VKOJwxGkRhrpBrz6myG4VleR46L l1zr/ZvdSAoDSOJsAkWeleWUg8/ZivzefmqJ/MsH8cRhdq88z2JgfWpy8v8vrInqLbxtM9BO eQY3IeRD/v6cMSTJQipD3gFDvB850ZaNgjvwl8bIoUobcXIbSxUNJfl4jyQ4Vb4ejE80qWZa IVybxQGvsl87YrFYNzDJjx6hquLk7Rtwd8vBmBycsbNWCZb3Y4BKzAUVX6naSWevL/28CbfZ 7r59unzlpbTg2PaFBc02rDL2ofvKyMyvu5YsiK3Z+DhrelF2EG7fb8qPDMOM75qf6LoiDeQj 1DRn0Zey0gPRW/WLT5i2tVXMik8a3YoVpbu9jRe2RtP9ceMydy3i5lS3GQ6mhc3jn1VO0TQt Wz4z9cXJT0PesITk4lOm4X6J/w2ujjPOOgQAAA== Cc: "mpls@ietf.org" <mpls@ietf.org>, "sboutros@cisco.com" <sboutros@cisco.com>, Mishael Wexler <Mishael.Wexler@ecitele.com>, "dward@juniper.net" <dward@juniper.net>, "andrew.g.malis@verizon.com" <andrew.g.malis@verizon.com>, Rotem Cohen <Rotem.Cohen@ecitele.com> Subject: [mpls] My WG LC comments on draft-ietf-mpls-tp-fault-03 not addressed in the -04 version 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: Fri, 06 May 2011 05:16:22 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD6CD839ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Loa, Ross, and all, I've read the -04 version of draft-ietf-mpls-tp-fault, and, to the best of m= y understanding, neither of my WG LC comments sent to the list on March 1,= 2011, (see http://www.ietf.org/mail-archive/web/mpls/current/msg05807.html)= has been addressed (and, by implication, not resolved) in the new version o= f the draft. I also think that after (recent) approval of draft-ietf-pwe3-oam-msg-map for= publication as a PS, it would be helpful to consider correlation between AI= S/LDI indications defined in draft-ietf-mpls-tp-fault with PW defects define= s in the RFC-to-be which, for obvious reasons, does not mention "server LSP= LDI as a potential of PW defect in the receive-from-PSN direction. IMO the= onus of defining such a correlation (if it exists) lies with the Editors an= d authors of this draft. One possible way to resolve these comments would be an Applicability Stateme= nt section that would discuss potential caveats. Regards, Sasha 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_A3C5DF08D38B6049839A6F553B331C76E9BD6CD839ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xm= lns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http://w= ww.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=3D"te= xt/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Wor= d 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vlin= k=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Loa, Ross, and all= ,<o:p></o:p></p><p class=3DMsoNormal>I’ve read the -04 version of draf= t-ietf-mpls-tp-fault, and, to the best of my understanding, neither of my WG=  LC comments sent to the list on March 1, 2011, (see <a href=3D"http:/= /www.ietf.org/mail-archive/web/mpls/current/msg05807.html">http://www.ietf.o= rg/mail-archive/web/mpls/current/msg05807.html</a>) has been addressed (and,= by implication, not resolved) in the new version of the draft.<o:p></o:p></= p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I also thin= k that after (recent) approval of draft-ietf-pwe3-oam-msg-map for publicatio= n as a PS, it would be helpful to consider correlation between AIS/LDI indic= ations defined in draft-ietf-mpls-tp-fault with PW defects defines in the RF= C-to-be which, for obvious reasons, does not mention “server LSP LDI a= s a potential of PW defect in the receive-from-PSN direction. IMO the onus o= f defining such a correlation (if it exists) lies with the Editors and autho= rs of this draft.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p= class=3DMsoNormal>One possible way to resolve these comments would be an Ap= plicability Statement section that would discuss potential caveats. <o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Regard= s,<o:p></o:p></p><p class=3DMsoNormal>     Sasha<o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p></div><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. </p> </body></html> --_000_A3C5DF08D38B6049839A6F553B331C76E9BD6CD839ILPTMAIL02eci_-- From neil.2.harrison@bt.com Fri May 6 00:30:09 2011 Return-Path: <neil.2.harrison@bt.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 4EFA0E0663 for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 00:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 SBhOkDefyp0V for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 00:30:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1AE065A for <mpls@ietf.org>; Fri, 6 May 2011 00:30:08 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 6 May 2011 08:30:07 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.191]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 6 May 2011 08:30:06 +0100 From: <neil.2.harrison@bt.com> To: <Alexander.Vainshtein@ecitele.com>, <rcallon@juniper.net>, <loa@pi.nu> Date: Fri, 6 May 2011 08:30:03 +0100 Thread-Topic: [mpls] My WG LC comments on draft-ietf-mpls-tp-fault-03 not addressed in the -04 version Thread-Index: AcwLrLej7FBs9A/lRkigLii91f3KrgAETzkQ Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44023248D89@EMV62-UKRD.domain1.systemhost.net> References: <A3C5DF08D38B6049839A6F553B331C76E9BD6CD839@ILPTMAIL02.ecitele.com> In-Reply-To: <A3C5DF08D38B6049839A6F553B331C76E9BD6CD839@ILPTMAIL02.ecitele.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, sboutros@cisco.com, dward@juniper.net, Mishael.Wexler@ecitele.com, andrew.g.malis@verizon.com, Rotem.Cohen@ecitele.com Subject: Re: [mpls] My WG LC comments on draft-ietf-mpls-tp-fault-03 not addressed in the -04 version 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: Fri, 06 May 2011 07:30:09 -0000 Folks, I'll say it one more time (though I fully expect it will get ignored yet ag= ain): - we should not be applying AIS/FDI to any packet layer technologies....it = is obvious why IMO for the cl-ps mode (eg IP) but it vis equally true (if l= ess obvious why) for the co-ps mode. AIS is an artefact of the co-cs mode = (regular time-slice of resource labelling/management, ie TDM) and really on= ly makes sense there. - more specifically there should not be OAM mapping between different techn= ologies at non-TOS layer network interfaces. These are NOT peer interfaces= ...we are always dealing with a client/server relationship here. In partic= ular one should never (under any circumstances) map a client defect conditi= on (or a client layer AIS indication) to a server layer OAM message. regards, Neil 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 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 06 May 2011 06:16 To: rcallon@juniper.net; Loa Andersson Cc: mpls@ietf.org; sboutros@cisco.com; Mishael Wexler; dward@juniper.net; a= ndrew.g.malis@verizon.com; Rotem Cohen Subject: [mpls] My WG LC comments on draft-ietf-mpls-tp-fault-03 not addres= sed in the -04 version Loa, Ross, and all, I've read the -04 version of draft-ietf-mpls-tp-fault, and, to the best of = my understanding, neither of my WG =A0LC comments sent to the list on March= 1, 2011, (see http://www.ietf.org/mail-archive/web/mpls/current/msg05807.h= tml) has been addressed (and, by implication, not resolved) in the new vers= ion of the draft. I also think that after (recent) approval of draft-ietf-pwe3-oam-msg-map fo= r publication as a PS, it would be helpful to consider correlation between = AIS/LDI indications defined in draft-ietf-mpls-tp-fault with PW defects def= ines in the RFC-to-be which, for obvious reasons, does not mention "server = LSP LDI as a potential of PW defect in the receive-from-PSN direction. IMO = the onus of defining such a correlation (if it exists) lies with the Editor= s and authors of this draft. One possible way to resolve these comments would be an Applicability Statem= ent section that would discuss potential caveats.=20 Regards, =A0=A0=A0=A0 Sasha 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.=20 From loa@pi.nu Fri May 6 08:48:16 2011 Return-Path: <loa@pi.nu> 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 32778E0691 for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 08:48:16 -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_21=0.6, 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 jrZr5Amv5rwq for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 08:48:15 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id BC856E071B for <mpls@ietf.org>; Fri, 6 May 2011 08:48:11 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 898F42A8001; Fri, 6 May 2011 17:48:09 +0200 (CEST) Message-ID: <4DC41838.9@pi.nu> Date: Fri, 06 May 2011 17:48:08 +0200 From: Loa Andersson <loa@pi.nu> 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: Maarten vissers <maarten.vissers@huawei.com> References: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> In-Reply-To: <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" <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 <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: Fri, 06 May 2011 15:48:16 -0000 Maarten, lots of interesting data and thoughts, however not addressing the question I asked. Let us assume that an LSP go across several operators transport networks, e.g. it starts from operator A, go across operator B, C and D to end up at a different geographical loacation i operator A's network again. Now how likely is operator C, would let operator A, whom he does not really need to have a relationship with (masked by B and D) initiate OAM actions that can cause MIPs in operator A's network take actions that is totally unexpected and uncontrolled by C? Would appreciate input from operators! /Loa On 2011-05-04 08:45, Maarten vissers wrote: > Loa, > > The connections in the "Transport Service" layers can be multi-operator connections. Examples are the SDH Transport Service layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, ..), ATM Transport Service layer connections (ATM VCs), OTN Transport Service layer connections (LO ODUs), Ethernet Transport Service layer connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport Service layer connections (MS-PW, Service-LSP). > > These Transport Service layer connections are monitored using pro-active OAM and on-demand OAM between the Service Provider MEG level MEP functions on the UNI-N ports and Service Provider MEG level MIP functions on the E-NNI/IrDI ports. In a multi-operator connection these Service Provider MEG level MEP functions on the UNI-N ports will be located in different operator domains. Also the Service Provider MEG level MIP functions on the E-NNI/IrDI ports will be located in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID MPLS-TP identifiers, then you will have a mixed case. > > We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. > If the answer is "no" then mixed identifier usage will not be a requirement. > If the application for MPLS-TP is within an MEF Ethernet Services architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason is that in the MEF architecture the E-NNI/IrDI is defined as an Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. > - MPLS-TP Transport Service layer may not be present at all in such MEF Ethernet Services architecture, only the MPLS-TP Transport Path layer could be used (to carry PW-labelled Ethernet Connections) and those MPLS-TP Transport Path connections terminate in the operator domain's edge node (i.e. single operator connections). > - For the case a MPLS-TP Transport Service layer is used in an MEF Ethernet Services architecture the MPLS-TP Transport Service connections will be terminated in the operator domain's edge node (i.e. single operator connections). > > ------ > > MPLS-TP Transport Path layer connections (transport-LSPs) are connecting a PE with an adjacent PE (via zero or more P nodes). Those transport-LSPs do not cross an E-NNI/IrDI. > > There is however one exception... when a group of Transport Service layer connections has to be sent from one domain via a second domain to a third domain, this is typically done via a Transport Path layer connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. Domain treats this domain 1-3 transport path layer connection as a transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 may use different identifiers (ICC, Global-ID) and a mixed case is present. If domains 1 and 3 use the same identifier type, then domain 2 may be using a different identifier type in the MIPs on its E-NNI/IrDI ports. > > ------ > > MPLS-TP Section layer connections are connecting adjacent MPLS-TP nodes. In 99.9% of the cases those nodes are in one operator domain. For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID based MPLS-TP identifiers there is a mixed case. > > Regards, > Maarten > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: 4 May 2011 08:00 >> To: mpls@ietf.org; Malcolm.BETTS@zte.com.cn >> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> Malcolm, >> >> are you saying that operators today allow OAM to control node (MIPs and >> MEPs) on each others networks? >> >> Do we have an operator that can verify this? >> >> /Loa >> >> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >>> >>> All, >>> >>> I share your concerns and doubts about a multi carrier control plane. >>> However, I think that it is essential that a transport network >> supports >>> multi carrier data plane interconnection with end to end OAM. In >> today's >>> transport network this interconnection is supported by SDH and OTN. >> The >>> objective for MPLS-TP is to allow for packet based interconnection as >> well. >>> >>> Regards, >>> >>> Malcolm >>> >>> >>> >>> *George Swallow<swallow@cisco.com>* >>> Sent by: mpls-bounces@ietf.org >>> >>> 03/05/2011 11:09 AM >>> >>> >>> To >>> "Andrew G. Malis"<agmalis@gmail.com>,<neil.2.harrison@bt.com> >>> cc >>> mpls@ietf.org >>> Subject >>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> >>> >>> >>> >>> >>> >>> >>> >>> Andy - >>> >>> > Such >>> > an E-NNI definition does not yet exist for MPLS-TP (something else >> to >>> > put on the to-do list). This E-NNI would also include similar >>> > identifier mapping/translation for MS-PWs, to answer an earlier >>> > question from Erminio that I saw on the list. >>> >>> You are quite correct here! I think much of this debate surrounds a >> problem >>> that is yet to be solved. So there are arguments for pieces of a >> solution >>> without and overall architecture. >>> >>> Based on all that I am seeing my inclination is to NOT say that we >> disallow >>> mixed identifiers, but to say that they are for future study. >>> >>> ...George >>> >>> >>> >>> >>> >>> On 5/3/11 8:38 AM, "Andrew G. Malis"<agmalis@gmail.com> wrote: >>> >>> > Neil, >>> > >>> > To your case 1, we're in complete agreement. We (VZ) don't see at >>> > least a short-term need for peer-layer interworking, given where >> we >>> > intend to deploy MPLS-TP in our infrastructure (as an internal >> server >>> > layer in the transport core). If peer layer interworking ever >> becomes >>> > a necessity, then obviously we'll need a well-defined E-NNI which >>> > would include LSP identifier mapping/translation at the boundary, >> for >>> > LSP provisioning (whether static or dynamic) and end-to-end OAM. >> Such >>> > an E-NNI definition does not yet exist for MPLS-TP (something else >> to >>> > put on the to-do list). This E-NNI would also include similar >>> > identifier mapping/translation for MS-PWs, to answer an earlier >>> > question from Erminio that I saw on the list. >>> > >>> > I also agree that both intra-layer and inter-layer mis- >> connectivity >>> > detection and amelioration are required, but I'm not convinced >> that >>> > the already defined mechanisms can't do that. Do you have some >>> > specific analysis on the inter-layer case? >>> > >>> > Cheers, >>> > Andy >>> > >>> > On Tue, May 3, 2011 at 3:36 AM,<neil.2.harrison@bt.com> wrote: >>> >> Hi Andy, >>> >> >>> >> 2 points: >>> >> >>> >> 1 I agree with your view of only having a single addressing >> scheme in a >>> >> single layer network solely belonging to one party. Though you >> may >>> need to >>> >> be rather careful if you also advocate that one can also have >> peer layer >>> >> interworking between different parties, ie E-NNIs (I believe this >> is >>> >> something you may support, eg old MPLSF case?). In such a peer >>> interworking >>> >> case it would seem one must allow different addressing schemes >> (and >>> indeed >>> >> any other variations in DP/CP functional components) if they >> exist >>> in the >>> >> standards. >>> >> >>> >> Of course, having an E-NNI and peer interworking between >> different >>> parties in >>> >> any non-TOS layer network (not just MPLS) is not technically >>> necessary (this >>> >> is trivial to prove), and this provides a strong argument for >> only >>> having a >>> >> single addressing scheme in a non-TOS layer network. >>> >> >>> >> >>> >> 2 You should also be aware that in client/server interworking of >> the >>> >> co-ps mode using variable size traffic units, and therefore >>> something rather >>> >> important for MPLS-TP in the role of a transport network (I'll >>> ignore issues >>> >> of transparency here), there could be inter-layer misconnectivity >>> (Aside=> >>> >> This case cannot occur in the co-cs mode). To date, however, we >> have >>> only >>> >> really considered intra-layer misconnectivity, ie between >> different LSPs >>> >> belonging to the same party (note this also includes all cases of >>> nested LSP >>> >> sublayer misconnectivity). >>> >> >>> >> In the case of inter-layer misconnectivity one may receive >> traffic >>> units and >>> >> OAM messages from some other party's layer network. The OAM >> messages may >>> >> come from (i) networks using different OAM/addressing solutions >> or (ii) >>> >> networks using the same OAM/addressing solutions. In both cases >>> there are >>> >> different issues wrt inter-layer misconnectivity one has to deal >>> with. I'm >>> >> not aware that these cases have been considered yet. >>> >> >>> >> >>> >> I'd like to hear your comments on both these points, but in >>> particular the >>> >> first one.....especially if you also support the notion of E-NNIs >> in >>> MPLS-TP, >>> >> as there seems to a possible logical conflict here. >>> >> >>> >> Thanks. >>> >> >>> >> regards, 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. >>> >> British Telecommunications plc >>> >> Registered office: 81 Newgate Street London EC1A 7AJ >>> >> Registered in England no: 1800000 >>> >> >>> >>> -----Original Message----- >>> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of >>> >>> Andrew G. Malis >>> >>> Sent: 02 May 2011 20:48 >>> >>> To: George Swallow >>> >>> Cc: mpls@ietf.org >>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >> Identifiers? >>> >>> >>> >>> George et al, >>> >>> >>> >>> Verizon does not have any requirement for mixed use of Global >> IDs and >>> >>> ICCs. We are fine with specifications that require both ends of >> an LSP >>> >>> to use one or the other. >>> >>> >>> >>> Thanks, >>> >>> Andy >>> >>> >>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >> <swallow@cisco.com> >>> >>> wrote: >>> >>>> 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. >>> >>>> >>> >>>> 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. >>> >>>> >>> >>>> 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 >>> >> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> -- >> >> >> Loa Andersson email: loa.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 -- 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 Internet-Drafts@ietf.org Fri May 6 09:00:02 2011 Return-Path: <Internet-Drafts@ietf.org> 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 5A071E067A; Fri, 6 May 2011 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 iyMqAKLIaGAd; Fri, 6 May 2011 09:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CDEE06EA; Fri, 6 May 2011 09:00: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.53 Message-ID: <20110506160001.16952.34864.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 09:00:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-loss-delay-profile-03.txt 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: Fri, 06 May 2011 16: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 : A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks Author(s) : D. Frost, et al Filename : draft-ietf-mpls-tp-loss-delay-profile-03.txt Pages : 5 Date : 2011-04-20 Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC XXXX. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. 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 Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] [RFC Editor, please replace XXXX with the RFC number assigned to draft-ietf-mpls-loss-delay.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-loss-delay-profile-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-loss-delay-profile-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06084824.I-D@ietf.org> --NextPart-- From huubatwork@gmail.com Fri May 6 10:26:07 2011 Return-Path: <huubatwork@gmail.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 BB8FAE0709 for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 QpZcTtU94t6c for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 10:26:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F9E06D0 for <mpls@ietf.org>; Fri, 6 May 2011 10:26:05 -0700 (PDT) Received: by eye13 with SMTP id 13so1225091eye.31 for <mpls@ietf.org>; Fri, 06 May 2011 10:26:04 -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:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WaS7i6ISTncxLbGeA3HMJXaw9YllIaeJt0VbrnzL/Bc=; b=jNpEv9JSp7YRsZNyFU5JiiGUCaaqr2Q8H7N80S3N11eHl/Zhl/AN27+2AchRypBfw9 hS1dVHGks1GEjETgAUzjM7WcsGJweTfU9nLF4WYL5R/nwLzrDBcQlVedv6WUEN86bze5 t6smMUKLiuBgYRb7wRuvkbEsF9dl0YAcV4gmY= 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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; b=q0U0owvKXY18hfzuX9j3HrY/NBCwOHkKisKq4hOWk9N9VbSBFTJHcAIrW4vSTCBS0C 81iplt3mqVl+1BJtq7I5n0zneXJo20IoLOR2t+zJxNDg8RN+M8g7k0xSMvRKEyR8gNZW zrmMmNUP60m9L4885nzWyaVas/LIYTQA58vWs= Received: by 10.213.13.200 with SMTP id d8mr1156819eba.107.1304702764062; Fri, 06 May 2011 10:26:04 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id n55sm1474356een.16.2011.05.06.10.26.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 10:26:02 -0700 (PDT) Message-ID: <4DC42F28.7030607@gmail.com> Date: Fri, 06 May 2011 19:26:00 +0200 From: Huub van Helvoort <huubatwork@gmail.com> 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" <mpls@ietf.org> References: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> In-Reply-To: <4DC41838.9@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 <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: Fri, 06 May 2011 17:26:07 -0000 Hej Loa, You wrote: > lots of interesting data and thoughts, however not addressing the > question I asked. > > Let us assume that an LSP go across several operators transport > networks, e.g. it starts from operator A, go across operator B, C and > D to end up at a different geographical loacation i operator A's > network again. > > Now how likely is operator C, would let operator A, whom he does not > really need to have a relationship with (masked by B and D) initiate > OAM actions that can cause MIPs in operator A's network take actions > that is totally unexpected and uncontrolled by C? > > Would appreciate input from operators! A similar scenario on the use of OAm is described in: http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt or shown in slides 9-12 of the presentation in the RTGA open meeting http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt These figures are taken from ITU-T contribution C-1124 which is signed by several operators. This contribution was supported by other operators as well. It is possible to use the same OAM (PTN or PSN) in all domains (A, B and C in figures 1 and 2). You can see that operator B *cannot* influence the OAM in domains A and C nor in the top layer end-to-end OAM. Regards, Huub. =============== > On 2011-05-04 08:45, Maarten vissers wrote: >> Loa, >> >> The connections in the "Transport Service" layers can be >> multi-operator connections. Examples are the SDH Transport Service >> layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, >> ..), ATM Transport Service layer connections (ATM VCs), OTN Transport >> Service layer connections (LO ODUs), Ethernet Transport Service layer >> connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport >> Service layer connections (MS-PW, Service-LSP). >> >> These Transport Service layer connections are monitored using >> pro-active OAM and on-demand OAM between the Service Provider MEG >> level MEP functions on the UNI-N ports and Service Provider MEG level >> MIP functions on the E-NNI/IrDI ports. In a multi-operator connection >> these Service Provider MEG level MEP functions on the UNI-N ports will >> be located in different operator domains. Also the Service Provider >> MEG level MIP functions on the E-NNI/IrDI ports will be located in >> different operator domains. If one operator deploys ICC and the other >> operator deploys Global-ID MPLS-TP identifiers, then you will have a >> mixed case. >> >> We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. >> If the answer is "no" then mixed identifier usage will not be a >> requirement. >> If the application for MPLS-TP is within an MEF Ethernet Services >> architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason >> is that in the MEF architecture the E-NNI/IrDI is defined as an >> Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. >> - MPLS-TP Transport Service layer may not be present at all in such >> MEF Ethernet Services architecture, only the MPLS-TP Transport Path >> layer could be used (to carry PW-labelled Ethernet Connections) and >> those MPLS-TP Transport Path connections terminate in the operator >> domain's edge node (i.e. single operator connections). >> - For the case a MPLS-TP Transport Service layer is used in an MEF >> Ethernet Services architecture the MPLS-TP Transport Service >> connections will be terminated in the operator domain's edge node >> (i.e. single operator connections). >> >> ------ >> >> MPLS-TP Transport Path layer connections (transport-LSPs) are >> connecting a PE with an adjacent PE (via zero or more P nodes). Those >> transport-LSPs do not cross an E-NNI/IrDI. >> >> There is however one exception... when a group of Transport Service >> layer connections has to be sent from one domain via a second domain >> to a third domain, this is typically done via a Transport Path layer >> connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. >> Domain treats this domain 1-3 transport path layer connection as a >> transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 >> may use different identifiers (ICC, Global-ID) and a mixed case is >> present. If domains 1 and 3 use the same identifier type, then domain >> 2 may be using a different identifier type in the MIPs on its >> E-NNI/IrDI ports. >> >> ------ >> >> MPLS-TP Section layer connections are connecting adjacent MPLS-TP >> nodes. In 99.9% of the cases those nodes are in one operator domain. >> For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different >> operator domains. If one operator deploys ICC and the other operator >> deploys Global-ID based MPLS-TP identifiers there is a mixed case. >> >> Regards, >> Maarten >> >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Loa Andersson >>> Sent: 4 May 2011 08:00 >>> To: mpls@ietf.org; Malcolm.BETTS@zte.com.cn >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> >>> Malcolm, >>> >>> are you saying that operators today allow OAM to control node (MIPs and >>> MEPs) on each others networks? >>> >>> Do we have an operator that can verify this? >>> >>> /Loa >>> >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >>>> >>>> All, >>>> >>>> I share your concerns and doubts about a multi carrier control plane. >>>> However, I think that it is essential that a transport network >>> supports >>>> multi carrier data plane interconnection with end to end OAM. In >>> today's >>>> transport network this interconnection is supported by SDH and OTN. >>> The >>>> objective for MPLS-TP is to allow for packet based interconnection as >>> well. >>>> >>>> Regards, >>>> >>>> Malcolm >>>> >>>> >>>> >>>> *George Swallow<swallow@cisco.com>* >>>> Sent by: mpls-bounces@ietf.org >>>> >>>> 03/05/2011 11:09 AM >>>> >>>> >>>> To >>>> "Andrew G. Malis"<agmalis@gmail.com>,<neil.2.harrison@bt.com> >>>> cc >>>> mpls@ietf.org >>>> Subject >>>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Andy - >>>> >>>> > Such >>>> > an E-NNI definition does not yet exist for MPLS-TP (something else >>> to >>>> > put on the to-do list). This E-NNI would also include similar >>>> > identifier mapping/translation for MS-PWs, to answer an earlier >>>> > question from Erminio that I saw on the list. >>>> >>>> You are quite correct here! I think much of this debate surrounds a >>> problem >>>> that is yet to be solved. So there are arguments for pieces of a >>> solution >>>> without and overall architecture. >>>> >>>> Based on all that I am seeing my inclination is to NOT say that we >>> disallow >>>> mixed identifiers, but to say that they are for future study. >>>> >>>> ...George >>>> >>>> >>>> >>>> >>>> >>>> On 5/3/11 8:38 AM, "Andrew G. Malis"<agmalis@gmail.com> wrote: >>>> >>>> > Neil, >>>> > >>>> > To your case 1, we're in complete agreement. We (VZ) don't see at >>>> > least a short-term need for peer-layer interworking, given where >>> we >>>> > intend to deploy MPLS-TP in our infrastructure (as an internal >>> server >>>> > layer in the transport core). If peer layer interworking ever >>> becomes >>>> > a necessity, then obviously we'll need a well-defined E-NNI which >>>> > would include LSP identifier mapping/translation at the boundary, >>> for >>>> > LSP provisioning (whether static or dynamic) and end-to-end OAM. >>> Such >>>> > an E-NNI definition does not yet exist for MPLS-TP (something else >>> to >>>> > put on the to-do list). This E-NNI would also include similar >>>> > identifier mapping/translation for MS-PWs, to answer an earlier >>>> > question from Erminio that I saw on the list. >>>> > >>>> > I also agree that both intra-layer and inter-layer mis- >>> connectivity >>>> > detection and amelioration are required, but I'm not convinced >>> that >>>> > the already defined mechanisms can't do that. Do you have some >>>> > specific analysis on the inter-layer case? >>>> > >>>> > Cheers, >>>> > Andy >>>> > >>>> > On Tue, May 3, 2011 at 3:36 AM,<neil.2.harrison@bt.com> wrote: >>>> >> Hi Andy, >>>> >> >>>> >> 2 points: >>>> >> >>>> >> 1 I agree with your view of only having a single addressing >>> scheme in a >>>> >> single layer network solely belonging to one party. Though you >>> may >>>> need to >>>> >> be rather careful if you also advocate that one can also have >>> peer layer >>>> >> interworking between different parties, ie E-NNIs (I believe this >>> is >>>> >> something you may support, eg old MPLSF case?). In such a peer >>>> interworking >>>> >> case it would seem one must allow different addressing schemes >>> (and >>>> indeed >>>> >> any other variations in DP/CP functional components) if they >>> exist >>>> in the >>>> >> standards. >>>> >> >>>> >> Of course, having an E-NNI and peer interworking between >>> different >>>> parties in >>>> >> any non-TOS layer network (not just MPLS) is not technically >>>> necessary (this >>>> >> is trivial to prove), and this provides a strong argument for >>> only >>>> having a >>>> >> single addressing scheme in a non-TOS layer network. >>>> >> >>>> >> >>>> >> 2 You should also be aware that in client/server interworking of >>> the >>>> >> co-ps mode using variable size traffic units, and therefore >>>> something rather >>>> >> important for MPLS-TP in the role of a transport network (I'll >>>> ignore issues >>>> >> of transparency here), there could be inter-layer misconnectivity >>>> (Aside=> >>>> >> This case cannot occur in the co-cs mode). To date, however, we >>> have >>>> only >>>> >> really considered intra-layer misconnectivity, ie between >>> different LSPs >>>> >> belonging to the same party (note this also includes all cases of >>>> nested LSP >>>> >> sublayer misconnectivity). >>>> >> >>>> >> In the case of inter-layer misconnectivity one may receive >>> traffic >>>> units and >>>> >> OAM messages from some other party's layer network. The OAM >>> messages may >>>> >> come from (i) networks using different OAM/addressing solutions >>> or (ii) >>>> >> networks using the same OAM/addressing solutions. In both cases >>>> there are >>>> >> different issues wrt inter-layer misconnectivity one has to deal >>>> with. I'm >>>> >> not aware that these cases have been considered yet. >>>> >> >>>> >> >>>> >> I'd like to hear your comments on both these points, but in >>>> particular the >>>> >> first one.....especially if you also support the notion of E-NNIs >>> in >>>> MPLS-TP, >>>> >> as there seems to a possible logical conflict here. >>>> >> >>>> >> Thanks. >>>> >> >>>> >> regards, 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. >>>> >> British Telecommunications plc >>>> >> Registered office: 81 Newgate Street London EC1A 7AJ >>>> >> Registered in England no: 1800000 >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> Behalf Of >>>> >>> Andrew G. Malis >>>> >>> Sent: 02 May 2011 20:48 >>>> >>> To: George Swallow >>>> >>> Cc: mpls@ietf.org >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >>> Identifiers? >>>> >>> >>>> >>> George et al, >>>> >>> >>>> >>> Verizon does not have any requirement for mixed use of Global >>> IDs and >>>> >>> ICCs. We are fine with specifications that require both ends of >>> an LSP >>>> >>> to use one or the other. >>>> >>> >>>> >>> Thanks, >>>> >>> Andy >>>> >>> >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>> <swallow@cisco.com> >>>> >>> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> We are looking for input/consensus from the WG. >>>> >>>> >>>> >>>> George, Eric,& Matthew -- ***************************************************************** ๆˆ‘็ˆฑๅค–็‚นไธ€ไธƒไธ‰ไธ€ From adrian@olddog.co.uk Fri May 6 14:04:11 2011 Return-Path: <adrian@olddog.co.uk> 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 54B70E0824 for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, 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 2SSFx3Epv6qs for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 14:04:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 48BDFE0840 for <mpls@ietf.org>; Fri, 6 May 2011 14:04:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p46Kwpl7015422; Fri, 6 May 2011 21:58:51 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p46Kwn3i015416; Fri, 6 May 2011 21:58:50 +0100 From: "Adrian Farrel" <adrian@olddog.co.uk> To: <huubatwork@gmail.com>, <mpls@ietf.org> References: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> <4DC42F28.7030607@gmail.com> In-Reply-To: <4DC42F28.7030607@gmail.com> Date: Fri, 6 May 2011 22:04:04 +0100 Message-ID: <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQD8OgkbKBty65xHJvZJQlcBoLfQqwJVbvz1AjK0rskCAzrroQDHY/peleVWyqA= 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: adrian@olddog.co.uk 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: Fri, 06 May 2011 21:04:11 -0000 So, I may have understood the import of those figures (specifically = figure 3 in draft-palanivelan-bfd-v2-gr-11.txt) but I read that to mean = that, in the case of mismatched OAM types, one of the OAM types (in the = figure, the PSN type is indicated) would be run end-to-end, and the = local OAM types would be used within the networks according to what they = supported. Now, noting very clearly that OAM types have nothing whatsoever to do = with MPLS-TP Identifiers, you seem to be suggesting that the same = approach holds. That would mean that (to paraphrase Figure 3) network A = might use one form of identifier and network B might use another form of = identifier, but the end-to-end identifiers would be of one form only. Have I misunderstood you? Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Huub van Helvoort > Sent: 06 May 2011 18:26 > To: mpls@ietf.org > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Hej Loa, >=20 > You wrote: >=20 > > lots of interesting data and thoughts, however not addressing the > > question I asked. > > > > Let us assume that an LSP go across several operators transport > > networks, e.g. it starts from operator A, go across operator B, C = and > > D to end up at a different geographical loacation i operator A's > > network again. > > > > Now how likely is operator C, would let operator A, whom he does not > > really need to have a relationship with (masked by B and D) initiate > > OAM actions that can cause MIPs in operator A's network take actions > > that is totally unexpected and uncontrolled by C? > > > > Would appreciate input from operators! >=20 > A similar scenario on the use of OAm is described in: > http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt or > shown in slides 9-12 of the presentation in the RTGA open meeting > http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt >=20 > These figures are taken from ITU-T contribution C-1124 > which is signed by several operators. This contribution > was supported by other operators as well. >=20 > It is possible to use the same OAM (PTN or PSN) in > all domains (A, B and C in figures 1 and 2). > You can see that operator B *cannot* influence the OAM > in domains A and C nor in the top layer end-to-end OAM. >=20 > Regards, Huub. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > > On 2011-05-04 08:45, Maarten vissers wrote: > >> Loa, > >> > >> The connections in the "Transport Service" layers can be > >> multi-operator connections. Examples are the SDH Transport Service > >> layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, = VC-4/STS-3c, > >> ..), ATM Transport Service layer connections (ATM VCs), OTN = Transport > >> Service layer connections (LO ODUs), Ethernet Transport Service = layer > >> connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP = Transport > >> Service layer connections (MS-PW, Service-LSP). > >> > >> These Transport Service layer connections are monitored using > >> pro-active OAM and on-demand OAM between the Service Provider MEG > >> level MEP functions on the UNI-N ports and Service Provider MEG = level > >> MIP functions on the E-NNI/IrDI ports. In a multi-operator = connection > >> these Service Provider MEG level MEP functions on the UNI-N ports = will > >> be located in different operator domains. Also the Service Provider > >> MEG level MIP functions on the E-NNI/IrDI ports will be located in > >> different operator domains. If one operator deploys ICC and the = other > >> operator deploys Global-ID MPLS-TP identifiers, then you will have = a > >> mixed case. > >> > >> We can ask the question if there is a need for an MPLS-TP = E-NNI/IrDI. > >> If the answer is "no" then mixed identifier usage will not be a > >> requirement. > >> If the application for MPLS-TP is within an MEF Ethernet Services > >> architecture, then there is no need for an MPLS-TP E-NNI/IrDI; = reason > >> is that in the MEF architecture the E-NNI/IrDI is defined as an > >> Ethernet E-NNI/IrDI and part of the Ethernet Transport Service = layer. > >> - MPLS-TP Transport Service layer may not be present at all in such > >> MEF Ethernet Services architecture, only the MPLS-TP Transport Path > >> layer could be used (to carry PW-labelled Ethernet Connections) and > >> those MPLS-TP Transport Path connections terminate in the operator > >> domain's edge node (i.e. single operator connections). > >> - For the case a MPLS-TP Transport Service layer is used in an MEF > >> Ethernet Services architecture the MPLS-TP Transport Service > >> connections will be terminated in the operator domain's edge node > >> (i.e. single operator connections). > >> > >> ------ > >> > >> MPLS-TP Transport Path layer connections (transport-LSPs) are > >> connecting a PE with an adjacent PE (via zero or more P nodes). = Those > >> transport-LSPs do not cross an E-NNI/IrDI. > >> > >> There is however one exception... when a group of Transport Service > >> layer connections has to be sent from one domain via a second = domain > >> to a third domain, this is typically done via a Transport Path = layer > >> connection with endpoints in the E-NNI/IrDI ports of domain 1 and = 3. > >> Domain treats this domain 1-3 transport path layer connection as a > >> transport service layer connection. E-NNI/IrDI ports in domain 1 = and 3 > >> may use different identifiers (ICC, Global-ID) and a mixed case is > >> present. If domains 1 and 3 use the same identifier type, then = domain > >> 2 may be using a different identifier type in the MIPs on its > >> E-NNI/IrDI ports. > >> > >> ------ > >> > >> MPLS-TP Section layer connections are connecting adjacent MPLS-TP > >> nodes. In 99.9% of the cases those nodes are in one operator = domain. > >> For the case of an MPLS-TP E-NNI/IrDI the two nodes are in = different > >> operator domains. If one operator deploys ICC and the other = operator > >> deploys Global-ID based MPLS-TP identifiers there is a mixed case. > >> > >> Regards, > >> Maarten > >> > >> > >>> -----Original Message----- > >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of > >>> Loa Andersson > >>> Sent: 4 May 2011 08:00 > >>> To: mpls@ietf.org; Malcolm.BETTS@zte.com.cn > >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP = Identifiers? > >>> > >>> Malcolm, > >>> > >>> are you saying that operators today allow OAM to control node = (MIPs and > >>> MEPs) on each others networks? > >>> > >>> Do we have an operator that can verify this? > >>> > >>> /Loa > >>> > >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >>>> > >>>> All, > >>>> > >>>> I share your concerns and doubts about a multi carrier control = plane. > >>>> However, I think that it is essential that a transport network > >>> supports > >>>> multi carrier data plane interconnection with end to end OAM. In > >>> today's > >>>> transport network this interconnection is supported by SDH and = OTN. > >>> The > >>>> objective for MPLS-TP is to allow for packet based = interconnection as > >>> well. > >>>> > >>>> Regards, > >>>> > >>>> Malcolm > >>>> > >>>> > >>>> > >>>> *George Swallow<swallow@cisco.com>* > >>>> Sent by: mpls-bounces@ietf.org > >>>> > >>>> 03/05/2011 11:09 AM > >>>> > >>>> > >>>> To > >>>> "Andrew G. Malis"<agmalis@gmail.com>,<neil.2.harrison@bt.com> > >>>> cc > >>>> mpls@ietf.org > >>>> Subject > >>>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Andy - > >>>> > >>>> > Such > >>>> > an E-NNI definition does not yet exist for MPLS-TP (something = else > >>> to > >>>> > put on the to-do list). This E-NNI would also include similar > >>>> > identifier mapping/translation for MS-PWs, to answer an earlier > >>>> > question from Erminio that I saw on the list. > >>>> > >>>> You are quite correct here! I think much of this debate surrounds = a > >>> problem > >>>> that is yet to be solved. So there are arguments for pieces of a > >>> solution > >>>> without and overall architecture. > >>>> > >>>> Based on all that I am seeing my inclination is to NOT say that = we > >>> disallow > >>>> mixed identifiers, but to say that they are for future study. > >>>> > >>>> ...George > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 5/3/11 8:38 AM, "Andrew G. Malis"<agmalis@gmail.com> wrote: > >>>> > >>>> > Neil, > >>>> > > >>>> > To your case 1, we're in complete agreement. We (VZ) don't see = at > >>>> > least a short-term need for peer-layer interworking, given = where > >>> we > >>>> > intend to deploy MPLS-TP in our infrastructure (as an internal > >>> server > >>>> > layer in the transport core). If peer layer interworking ever > >>> becomes > >>>> > a necessity, then obviously we'll need a well-defined E-NNI = which > >>>> > would include LSP identifier mapping/translation at the = boundary, > >>> for > >>>> > LSP provisioning (whether static or dynamic) and end-to-end = OAM. > >>> Such > >>>> > an E-NNI definition does not yet exist for MPLS-TP (something = else > >>> to > >>>> > put on the to-do list). This E-NNI would also include similar > >>>> > identifier mapping/translation for MS-PWs, to answer an earlier > >>>> > question from Erminio that I saw on the list. > >>>> > > >>>> > I also agree that both intra-layer and inter-layer mis- > >>> connectivity > >>>> > detection and amelioration are required, but I'm not convinced > >>> that > >>>> > the already defined mechanisms can't do that. Do you have some > >>>> > specific analysis on the inter-layer case? > >>>> > > >>>> > Cheers, > >>>> > Andy > >>>> > > >>>> > On Tue, May 3, 2011 at 3:36 AM,<neil.2.harrison@bt.com> wrote: > >>>> >> Hi Andy, > >>>> >> > >>>> >> 2 points: > >>>> >> > >>>> >> 1 I agree with your view of only having a single addressing > >>> scheme in a > >>>> >> single layer network solely belonging to one party. Though you > >>> may > >>>> need to > >>>> >> be rather careful if you also advocate that one can also have > >>> peer layer > >>>> >> interworking between different parties, ie E-NNIs (I believe = this > >>> is > >>>> >> something you may support, eg old MPLSF case?). In such a peer > >>>> interworking > >>>> >> case it would seem one must allow different addressing schemes > >>> (and > >>>> indeed > >>>> >> any other variations in DP/CP functional components) if they > >>> exist > >>>> in the > >>>> >> standards. > >>>> >> > >>>> >> Of course, having an E-NNI and peer interworking between > >>> different > >>>> parties in > >>>> >> any non-TOS layer network (not just MPLS) is not technically > >>>> necessary (this > >>>> >> is trivial to prove), and this provides a strong argument for > >>> only > >>>> having a > >>>> >> single addressing scheme in a non-TOS layer network. > >>>> >> > >>>> >> > >>>> >> 2 You should also be aware that in client/server interworking = of > >>> the > >>>> >> co-ps mode using variable size traffic units, and therefore > >>>> something rather > >>>> >> important for MPLS-TP in the role of a transport network (I'll > >>>> ignore issues > >>>> >> of transparency here), there could be inter-layer = misconnectivity > >>>> (Aside=3D> > >>>> >> This case cannot occur in the co-cs mode). To date, however, = we > >>> have > >>>> only > >>>> >> really considered intra-layer misconnectivity, ie between > >>> different LSPs > >>>> >> belonging to the same party (note this also includes all cases = of > >>>> nested LSP > >>>> >> sublayer misconnectivity). > >>>> >> > >>>> >> In the case of inter-layer misconnectivity one may receive > >>> traffic > >>>> units and > >>>> >> OAM messages from some other party's layer network. The OAM > >>> messages may > >>>> >> come from (i) networks using different OAM/addressing = solutions > >>> or (ii) > >>>> >> networks using the same OAM/addressing solutions. In both = cases > >>>> there are > >>>> >> different issues wrt inter-layer misconnectivity one has to = deal > >>>> with. I'm > >>>> >> not aware that these cases have been considered yet. > >>>> >> > >>>> >> > >>>> >> I'd like to hear your comments on both these points, but in > >>>> particular the > >>>> >> first one.....especially if you also support the notion of = E-NNIs > >>> in > >>>> MPLS-TP, > >>>> >> as there seems to a possible logical conflict here. > >>>> >> > >>>> >> Thanks. > >>>> >> > >>>> >> regards, 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. > >>>> >> British Telecommunications plc > >>>> >> Registered office: 81 Newgate Street London EC1A 7AJ > >>>> >> Registered in England no: 1800000 > >>>> >> > >>>> >>> -----Original Message----- > >>>> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>> Behalf Of > >>>> >>> Andrew G. Malis > >>>> >>> Sent: 02 May 2011 20:48 > >>>> >>> To: George Swallow > >>>> >>> Cc: mpls@ietf.org > >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > >>> Identifiers? > >>>> >>> > >>>> >>> George et al, > >>>> >>> > >>>> >>> Verizon does not have any requirement for mixed use of Global > >>> IDs and > >>>> >>> ICCs. We are fine with specifications that require both ends = of > >>> an LSP > >>>> >>> to use one or the other. > >>>> >>> > >>>> >>> Thanks, > >>>> >>> Andy > >>>> >>> > >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >>> <swallow@cisco.com> > >>>> >>> wrote: > >>>> >>>> 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. > >>>> >>>> > >>>> >>>> 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. > >>>> >>>> > >>>> >>>> We are looking for input/consensus from the WG. > >>>> >>>> > >>>> >>>> George, Eric,& Matthew >=20 >=20 > -- > ************************************************************** > *** > = =E6=88=91=E7=88=B1=E5=A4=96=E7=82=B9=E4=B8=80=E4=B8=83=E4=B8=89=E4=B8=80 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From adrian@olddog.co.uk Fri May 6 15:10:31 2011 Return-Path: <adrian@olddog.co.uk> 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 826BBE076B for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 15:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] 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 oUbhoXGgCZFF for <mpls@ietfa.amsl.com>; Fri, 6 May 2011 15:10:30 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9C246E0750 for <mpls@ietf.org>; Fri, 6 May 2011 15:10:30 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p46MAOvo016795; Fri, 6 May 2011 23:10:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p46MANs0016788; Fri, 6 May 2011 23:10:23 +0100 From: "Adrian Farrel" <adrian@olddog.co.uk> To: <loa@pi.nu>, <mpls@ietf.org> References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> In-Reply-To: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Date: Fri, 6 May 2011 23:10:23 +0100 Message-ID: <0d5d01cc0c3a$65c27120$31475360$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQE8mPrpUezXFKa5EaqyCsaUanI7RJWfMylg Cc: rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG <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: Fri, 06 May 2011 22:10:31 -0000 [speaking as an individual WG participant] I support the idea of constructing a MIB module for MPLS-TP LSPs and for other elements of MPLS-TP, but I have significant reservations about adopting this document in its current form. I recognise that once adopted, the WG will be able to enforce changes in content, but I am concerned that this document does not correctly reflect the relationship with other MIB modules, and that taking this as a starting point will encourage us to go down the wrong path resulting in a starting direction that will be hard to change. I would be happy to see the authors spend a little more time on this and then adopt it into the WG. In overview my concerns are as follows: mplsGlobalId, mplsIcc and mplsNodeId are node properties that will turn out to be equally applicable for PWs. They should appear in a MIB module dedicated to the LSR not just to the MPLS-TP LSPs. Given that these three objects and mplsNodeConfigTable and mplsNodeIpMapTable are all related to MPLS-TP identifiers, why not have a separate module for them all? A number of objects related to Global IDs and Node IDs appear to be of the wrong max value compared to draft-ietf-mpls-tp-identifiers. You could usefully define TCs for them and for the ICC ID. What will zero Global IDs and Node IDs mean? I see the value of the ICC entries in mplsNodeConfigTable and the use of mplsNodeIccMapTable to generate a unique index to use in defining entries in the various pre-existing tables. (But see my comment on the use of mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I do not see the value of the Global entries in mplsNodeConfigTable and the use of mplsNodeIpMapEntry since you say in the preamble to mplsTunnelExtEntry that Source-Tunnel_Num is mapped with mplsTunnelIndex. Quite possibly there is descriptive text missing. There seems to be some ambiguity about whether the objects in this document refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to sort this out. mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm guessing you actually want a sparse augmentation since in a "mixed" environment you will not want to have all these objects present but unused. So you need to change the way you define this. In mplsTunnelExtTable you do not state what DstTunnelNum is mapped with. This is key and could completely break your augmentation unless you get it right! For mplsTunnelExtEntry you have... Source Global identifier/ICC and Destination Global identifier/ICC are maintained in the mplsNodeConfigTable and mplsNodeConfigLocalNum is used to create an entry in mplsTunnelTable. This is possibly too vague to be actually practical. How will mplsTunnelExtDestTnlIndex actually be used? - What value will it have for unidirecitonal tunnels? (Or for bidriectional associated tunnels where the reverse direction is not present on this LSR) - Is this actually meant to be the object that gives us the DstTunnelNum? If so, what has this to do with the reverse direction? It is completely unclear to me what mplsTunnelExtTnlApp is for! It certainly makes a nonsense of mplsTpTunnelsConfigured and mplsTpTunnelsActive Cheers, Adrian > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa From krbalaji.in@gmail.com Sat May 7 08:20:27 2011 Return-Path: <krbalaji.in@gmail.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 883E5E06E1 for <mpls@ietfa.amsl.com>; Sat, 7 May 2011 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfQTEqRrQS+x for <mpls@ietfa.amsl.com>; Sat, 7 May 2011 08:20:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 880B5E06C5 for <mpls@ietf.org>; Sat, 7 May 2011 08:20:26 -0700 (PDT) Received: by wwa36 with SMTP id 36so3042219wwa.13 for <mpls@ietf.org>; Sat, 07 May 2011 08:20: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:from:date :message-id:subject:to:cc:content-type; bh=ajlYwhoc7qlsB/rUHAITv9GNRr+whDD4W1LY2L2KzwM=; b=OQzXkRNd9xaQY057CAUNN0fHmvstspjlUw4i24BCkR/o8AdNHZh4TeJSntaqTWnYxc /FuAtdUQQGJIw1MAgHSBxjHb7rmajneVCJraAGk320t54iT3H3pzFeGJHZxoLalwVrSB lwPPcwxtFT+rBIFytW2R4HArB6KnPOVuOAotg= 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=dOXo7sOWdbbbFnXzBfhKrpl4Zoy5zo926PjKjevSMqBoEc4V6cZC0gD0yylVNILO/c O7Uk+jHuDdFkf4mUhaSA+5kcrxrR2+PiRGDZYzaeZKveguMcd3hd8wsEoZYJV+ecT/L4 F4IxBseyLEMdsjEHB3pM3NVRkeTyogUGvmP/o= Received: by 10.216.67.15 with SMTP id i15mr788511wed.32.1304781625136; Sat, 07 May 2011 08:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.24.197 with HTTP; Sat, 7 May 2011 08:20:05 -0700 (PDT) In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: Balaji KR <krbalaji.in@gmail.com> Date: Sat, 7 May 2011 17:20:05 +0200 Message-ID: <BANLkTimy+NPr_pbHLBNTxqO+0JjewBxzCg@mail.gmail.com> To: loa@pi.nu Content-Type: multipart/alternative; boundary=000e0ce0a9c44697c204a2b125f9 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 <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: Sat, 07 May 2011 15:20:27 -0000 --000e0ce0a9c44697c204a2b125f9 Content-Type: text/plain; charset=ISO-8859-1 yes/support On Wed, Apr 27, 2011 at 4:06 AM, <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 > --000e0ce0a9c44697c204a2b125f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes/support<br><br><div class=3D"gmail_quote">On Wed, Apr 27, 2011 at 4:06 = AM, <span dir=3D"ltr"><<a href=3D"mailto:loa@pi.nu">loa@pi.nu</a>></= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> Working Group,<br> <br> this is to start a two week poll on making<br> <br> draft-leymann-mpls-seamless-mpls-03<br> <br> an mpls working group document.<br> <br> If you support the document becoming a working group document<br> please respond to this poll with "yes/support"<br> <br> If you do not support the document becoming a working group<br> document please respond to this poll with "no/do not support"<br> and at the same time give the technical reasons why you are<br> not supporting the document.<br> <br> If you have technical comments or in any other way want to<br> discuss the document, please send these comments to the mpls<br> working group mailing list, but with another subject than what<br> is on this mail.<br> <br> The poll ends May 10th.<br> <br> /Loa<br> <br> <br> _______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br> </blockquote></div><br> --000e0ce0a9c44697c204a2b125f9-- From krbalaji.in@gmail.com Sat May 7 09:00:08 2011 Return-Path: <krbalaji.in@gmail.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 A40E1E06BE for <mpls@ietfa.amsl.com>; Sat, 7 May 2011 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 CRhvzW7jGvc9 for <mpls@ietfa.amsl.com>; Sat, 7 May 2011 09:00:07 -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 D20B1E06DA for <mpls@ietf.org>; Sat, 7 May 2011 09:00:06 -0700 (PDT) Received: by wyb29 with SMTP id 29so3505020wyb.31 for <mpls@ietf.org>; Sat, 07 May 2011 09:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=eanPmp25Vns1DTR9C56O0bqDInmbPmLmGdpwBErIUf4=; b=vxAS7WriSeGZP8RNxF/CA3bISkAn+P2MaGlEgDLIsgk4gM8Ly4Ou9ItKwxXGg8MBDV wP8rqVPx37ddj87naF2lq16rKYhrnNw7H8jLrbrYdYatIJBH4FTEshAwoGKG4V0qeHzM gVpaCbDa1yNju1TtT1MAIVufthadviep+zJkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=TrDBHbIcCMEttyRl6uTO16UacTJkW3gV4MrGTjQdLPmoMpgxmeaUt5wGjTJ+W391PV BQAFg3p8TRfqrf+DwLn1/pkmTLUjMpH3jZ6MnbadXEuTk69R4nWpHvZhIrfIUSOq5Qho WbkwciZ6XTe40iCaY40ldng8F1pLRcMXd0pUM= Received: by 10.216.168.82 with SMTP id j60mr812808wel.47.1304783561222; Sat, 07 May 2011 08:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.24.197 with HTTP; Sat, 7 May 2011 08:52:21 -0700 (PDT) From: Balaji KR <krbalaji.in@gmail.com> Date: Sat, 7 May 2011 17:52:21 +0200 Message-ID: <BANLkTinpkBJDYDR4mMzVHC9V13U9F8JGog@mail.gmail.com> To: mpls <mpls@ietf.org> Content-Type: multipart/alternative; boundary=0016e65b40e0acec3204a2b19800 Subject: [mpls] draft-leymann-mpls-seamless-mpls-03 - Query 1) LDP DoD on AN, 2) IGP on AN, 3) MPLS L3 VPN on AN 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: Sat, 07 May 2011 16:00:08 -0000 --0016e65b40e0acec3204a2b19800 Content-Type: text/plain; charset=ISO-8859-1 Hi, Query-1: I am currently referring to this draft for identifying best way to design a Converged Transport Network. The mail limitations comes, when positioning AN nodes at Access where most of the products are capable to hold shared 8K routes (global routing, VRF routing etc). Considering LDP DoD, while AN send DoD request to AG nodes; AN must have routing information of Remote AN before or after that particular LDP DoD - if there is a service needs to be enabled for remote AN. This is for Business service enabling case-2. I am unclear on how this will happen as per draft. Might be I am not understood the LDP DoD procedure - like /32 prefix not required to make LSP between AN's or while LDP DoD request will populate /32 in the routing table automatically... Query-2: There are cases, service providers planned to have multiple ANs in ring connects ring end to any two AGN1x node. This will surely need a IGP (like OSPF), for dynamic routing nature. This means, we should have a controlled redistribution of Remote AN networks into AN ring IGP - so required /32 prefix only will be able in the RIB. I was thinking of, why AN IGP can request for a /32 prefix update from AGN1x either automatically while a services needs to be enabled between Local AN and Remote AN at another Domain. Or The provisioning tool need to have a option to update Control Redistribution prefix-list/access-list as and when Services are enabled between local AN and Remote AN. Query-3: Please note, I have not found this draft is discussed how we can enable MPLS L3 VPN between local and remote AN's. Or as per this draft, AN is only positioned for PW services? MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the size of VRF table. In case multiple spoke need to communicate between, regional AN's L3 VPN can receive one/two default routes from a central location (part of same regional VRF), and there should be a routing nodes to enable interconnecting regional VPN's. Regards, Balaji K R --0016e65b40e0acec3204a2b19800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,<br><br>Query-1:<br>I am currently referring to this draft for identifyi= ng best way to design a Converged Transport Network. The mail limitations c= omes, when positioning AN nodes at Access where most of the products are ca= pable to hold shared 8K routes (global routing, VRF routing etc).<br> <br>Considering LDP DoD, while AN send DoD request to AG nodes; AN must hav= e routing information of Remote AN before or after that particular LDP DoD = - if there is a service needs to be enabled for remote AN. This is for Busi= ness service enabling case-2.<br> <br>I am unclear on how this will happen as per draft. Might be I am not un= derstood the LDP DoD procedure - like /32 prefix not required to make LSP b= etween AN's or while LDP DoD request will populate /32 in the routing t= able automatically...<br> <br>Query-2:<br>There are cases, service providers planned to have multiple= ANs in ring connects ring end to any two AGN1x node. This will surely need= a IGP (like OSPF), for dynamic routing nature.<br>This means, we should ha= ve a controlled redistribution of Remote AN networks into AN ring IGP - so = required /32 prefix only will be able in the RIB.<br> <br>I was thinking of, why AN IGP can request for a /32 prefix update from = AGN1x either automatically while a services needs to be enabled between Loc= al AN and Remote AN at another Domain.<br>Or <br>The provisioning tool need= to have a option to update Control Redistribution prefix-list/access-list = as and when Services are enabled between local AN and Remote AN.<br> <br>Query-3:<br>Please note, I have not found this draft is discussed how w= e can enable MPLS L3 VPN between local and remote AN's. Or as per this = draft, AN is only positioned for PW services?<br><br>MPLS L3 VPN nodes most= ly prefer to configure Hub and Spoke to limit the size of VRF table. In cas= e multiple spoke need to communicate between, regional AN's L3 VPN can = receive one/two default routes from a central location (part of same region= al VRF), and there should be a routing nodes to enable interconnecting regi= onal VPN's.<br> <br>Regards,<br><br>Balaji K R<br><br><br><br><br><br><br><br><br> --0016e65b40e0acec3204a2b19800-- From krbalaji.in@gmail.com Sun May 8 00:29:33 2011 Return-Path: <krbalaji.in@gmail.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 B9095E06F4 for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 00:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 SESJ2kxIH2OZ for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 00:29:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF13E0675 for <mpls@ietf.org>; Sun, 8 May 2011 00:29:31 -0700 (PDT) Received: by wwa36 with SMTP id 36so3267048wwa.13 for <mpls@ietf.org>; Sun, 08 May 2011 00:29: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:from:date :message-id:subject:to:content-type; bh=CkCVFJ++CTxU+jLMX3vxagrXHb0frj0Wjh3mqoVFZrA=; b=elVyIwnA4V3QwI7Ae9FaCoWEnR9pOmLRZdHPhbIF5igl+j5Dhyz1G4qRReEd5dN+iB 0KLmT2QezzATE0VMXPwctAIWVMtLga5pmAhSZLWZJUDUb+tyWiOkmcACBR0OTyCiCfKO 1mXF8olWnfdE4+f+2V+ozBtLxfUkRBdqbeSWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=RvyDx86t8RccfbNE2ObKtdH47j+PYwYWjaG9ZT2it2iCRuGUQLc6NRuGCsJ3hQVJPs 3zaTl3S7BvWVbocbMEqULzbDKuEBQ5cZXiNiDur/WPwZ2vOvWhITqtY1HrlR4Dvev5uW YX5hUaSa8tGHBlW9DFCKQXjLbKWeTI8DqstrE= Received: by 10.216.136.89 with SMTP id v67mr2666515wei.47.1304839771130; Sun, 08 May 2011 00:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.24.197 with HTTP; Sun, 8 May 2011 00:29:11 -0700 (PDT) In-Reply-To: <BANLkTinpkBJDYDR4mMzVHC9V13U9F8JGog@mail.gmail.com> References: <BANLkTinpkBJDYDR4mMzVHC9V13U9F8JGog@mail.gmail.com> From: Balaji KR <krbalaji.in@gmail.com> Date: Sun, 8 May 2011 09:29:11 +0200 Message-ID: <BANLkTinVCMJCEvAGY059N7O=jEfVYoWNJA@mail.gmail.com> To: mpls <mpls@ietf.org> Content-Type: multipart/alternative; boundary=0016e6deddff0c0a5304a2beafad Subject: [mpls] draft-leymann-mpls-seamless-mpls-03 - Query 1) LDP DoD on AN, 2) IGP on AN, 3) MPLS L3 VPN on AN 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: Sun, 08 May 2011 07:29:33 -0000 --0016e6deddff0c0a5304a2beafad Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Query-1: > I am currently referring to this draft for identifying best way to design a > Converged Transport Network. The mail limitations comes, when positioning AN > nodes at Access where most of the products are capable to hold shared 8K > routes (global routing, VRF routing etc). > > Considering LDP DoD, while AN send DoD request to AG nodes; AN must have > routing information of Remote AN before or after that particular LDP DoD - > if there is a service needs to be enabled for remote AN. This is for > Business service enabling case-2. > > I am unclear on how this will happen as per draft. Might be I am not > understood the LDP DoD procedure - like /32 prefix not required to make LSP > between AN's or while LDP DoD request will populate /32 in the routing table > automatically... > > Query-2: > There are cases, service providers planned to have multiple ANs in ring > connects ring end to any two AGN1x node. This will surely need a IGP (like > OSPF), for dynamic routing nature. > This means, we should have a controlled redistribution of Remote AN > networks into AN ring IGP - so required /32 prefix only will be able in the > RIB. > > I was thinking of, why AN IGP can request for a /32 prefix update from > AGN1x either automatically while a services needs to be enabled between > Local AN and Remote AN at another Domain. > Or > The provisioning tool need to have a option to update Control > Redistribution prefix-list/access-list as and when Services are enabled > between local AN and Remote AN. > > Query-3: > Please note, I have not found this draft is discussed how we can enable > MPLS L3 VPN between local and remote AN's. Or as per this draft, AN is only > positioned for PW services? > > MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the > size of VRF table. In case multiple spoke need to communicate between, > regional AN's L3 VPN can receive one/two default routes from a central > location (part of same regional VRF), and there should be a routing nodes to > enable interconnecting regional VPN's. > > Regards, > > Balaji K R > > > > > > > > > --0016e6deddff0c0a5304a2beafad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le= ft: 1ex;">Hi,<br><br>Query-1:<br>I am currently referring to this draft for= identifying best way to design a Converged Transport Network. The mail lim= itations comes, when positioning AN nodes at Access where most of the produ= cts are capable to hold shared 8K routes (global routing, VRF routing etc).= <br> <br>Considering LDP DoD, while AN send DoD request to AG nodes; AN must hav= e routing information of Remote AN before or after that particular LDP DoD = - if there is a service needs to be enabled for remote AN. This is for Busi= ness service enabling case-2.<br> <br>I am unclear on how this will happen as per draft. Might be I am not un= derstood the LDP DoD procedure - like /32 prefix not required to make LSP b= etween AN's or while LDP DoD request will populate /32 in the routing t= able automatically...<br> <br>Query-2:<br>There are cases, service providers planned to have multiple= ANs in ring connects ring end to any two AGN1x node. This will surely need= a IGP (like OSPF), for dynamic routing nature.<br>This means, we should ha= ve a controlled redistribution of Remote AN networks into AN ring IGP - so = required /32 prefix only will be able in the RIB.<br> <br>I was thinking of, why AN IGP can request for a /32 prefix update from = AGN1x either automatically while a services needs to be enabled between Loc= al AN and Remote AN at another Domain.<br>Or <br>The provisioning tool need= to have a option to update Control Redistribution prefix-list/access-list = as and when Services are enabled between local AN and Remote AN.<br> <br>Query-3:<br>Please note, I have not found this draft is discussed how w= e can enable MPLS L3 VPN between local and remote AN's. Or as per this = draft, AN is only positioned for PW services?<br><br>MPLS L3 VPN nodes most= ly prefer to configure Hub and Spoke to limit the size of VRF table. In cas= e multiple spoke need to communicate between, regional AN's L3 VPN can = receive one/two default routes from a central location (part of same region= al VRF), and there should be a routing nodes to enable interconnecting regi= onal VPN's.<br> <br>Regards,<br><br>Balaji K R<br><br><br><br><br><br><br><br><br> </blockquote></div><br> --0016e6deddff0c0a5304a2beafad-- From wwwrun@rfc-editor.org Sun May 8 05:16:52 2011 Return-Path: <wwwrun@rfc-editor.org> 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 6BB61E06ED for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 05:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.453 X-Spam-Level: X-Spam-Status: No, score=-104.453 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 2ERDnIhjhs61 for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 05:16:52 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 07F36E06E5 for <mpls@ietf.org>; Sun, 8 May 2011 05:16:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E2BC6E074E; Sun, 8 May 2011 05:16:51 -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 <rfc-editor@rfc-editor.org> Message-Id: <20110508121651.E2BC6E074E@rfc-editor.org> Date: Sun, 8 May 2011 05:16:51 -0700 (PDT) Cc: mpls@ietf.org, maligree@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3031 (2803) 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: Sun, 08 May 2011 12:16:52 -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=2803 -------------------------------------- Type: Editorial Reported by: maligree <maligree@gmail.com> Section: 3.1 Original Text ------------- Ru will label with packet with label value L Corrected Text -------------- Ru will label the packet with label value L Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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 jcucchiara@mindspring.com Sun May 8 15:41:15 2011 Return-Path: <jcucchiara@mindspring.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 B96D7E06BB for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 15:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, STOX_REPLY_TYPE=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 doii3y1Z-QAk for <mpls@ietfa.amsl.com>; Sun, 8 May 2011 15:41:15 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E97BFE069E for <mpls@ietf.org>; Sun, 8 May 2011 15:41:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cohHsKaK9SRjtdZzjKzUL1x7XcAmurB4x7w9CJ6q/1vFXjIcgOVzAoXTG5+lgANy; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1QJBZ5-00010l-Hm; Sun, 08 May 2011 17:30:59 -0400 Message-ID: <00bf01cc0dc7$3820fa00$6701a8c0@JoanPC> From: "Joan Cucchiara" <jcucchiara@mindspring.com> To: <loa@pi.nu>, <mpls@ietf.org> References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Date: Sun, 8 May 2011 17:30:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654314313beb07d330f3cbc53c42e98782e58ce75fe477930ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] Comments: poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Sun, 08 May 2011 22:41:15 -0000 Hi, While there seems to be a benefit to keeping all the "mpls" tunnels in one table (i.e. the mplsTunnelTable in RFC3812). I have a concern about what seems to be a redefinition of the indexes for the mplsTunnelTable. This draft contains a table: mplsTunnelExtTable which AUGMENTS the mplsTunnelTable in RFC3812. The indexes are: INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } The above indexes seem to be redefined in this draft (quoting from the DESCRIPTION clause): "As per MPLS-TP Identifiers draft, LSP_ID is Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID:: Dst-Tunnel_Num::LSP_Num for IP operator and Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num for ICC operator, mplsTunnelTable is reused for forming the LSP_ID as follows, Source Tunnel_Num is mapped with mplsTunnelIndex, Source node identifier is mapped with mplsTunnelIngressLSRId, Destination node identifier is mapped with mplsTunnelEgressLSRId LSP_Num is mapped with mplsTunnelInstance. Source Global identifier/ICC and Destination Global identifier/ICC are maintained in the mplsNodeConfigTable and mplsNodeConfigLocalNum is used to create an entry in mplsTunnelTable." Additionally, one now needs to first configure an entry in the mplsNodeConfigTable in this draft, then one can create an entry in the mplsTunnelTable (RFC3812). Adrian Farrel suggested that the mplsTunnelExtTable in this draft was probably meant to have sparse-augments relationship to the mplsTunnelTable. While I would agree that this is probably the case, even with a sparse-augments relationship, would the indexes redefined for TP be acceptable? I think not, although (as mentioned at the beginning), I do see an advantage for having all mpls-based Tunnels in one table. Would definitely like to see this discussed prior to accepting this draft was a WG group document. Thank you, -Joan ----- Original Message ----- From: <loa@pi.nu> To: <mpls@ietf.org> Cc: <rcallon@juniper.net>; <draft-vkst-mpls-tp-te-mib@tools.ietf.org> Sent: Tuesday, May 03, 2011 1:47 PM Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Mon May 9 06:58:18 2011 Return-Path: <stbryant@cisco.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 4CA9CE0659 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 06:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.275 X-Spam-Level: X-Spam-Status: No, score=-109.275 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 ovfQKCooIN82 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 06:58:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E950E075C for <mpls@ietf.org>; Mon, 9 May 2011 06:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3814; q=dns/txt; s=iport; t=1304949496; x=1306159096; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=MCQ1y+DJ9A4Ukx33VBFykQkrHceLeG9N0LqKOp7jHz8=; b=cZyYBv6jqHBoRevBDbCMyMAWdBNfeaYZdYKgET6mF/h1SJoyQC/jPcjq Evw8/tctaOLJ0bhwslP3lRs/FUaUZMRLd6exH3X8Oc3WLYSi8LLuFmlQc fK/sk9wLRJUdWmdz8rQ9+fBSZF/WWQ9cqO560M6Hjj7Rc0Zn7ICtgNlso c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoDANXxx02Q/khNgWdsb2JhbAClfBQBARYmJahpgngPAZpOhgwEj2WOXg X-IronPort-AV: E=Sophos;i="4.64,340,1301875200"; d="scan'208";a="87519543" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 May 2011 13:58:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p49DwA8d024614; Mon, 9 May 2011 13:58:15 GMT Received: from dhcp-bdlk10-vlan301-data-64-103-109-79.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p49Dw9U07220; Mon, 9 May 2011 14:58:09 +0100 (BST) Message-ID: <4DC7F2F1.4000203@cisco.com> Date: Mon, 09 May 2011 14:58:09 +0100 From: Stewart Bryant <stbryant@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mpls@ietf.org" <mpls@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org> Subject: [mpls] Disposition of ITU-T LC comments on draft-ietf-mpls-loss-delay and draft-ietf-mpls-tp-loss-delay-profile X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG <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: Mon, 09 May 2011 13:58:18 -0000 The following is the disposition of Last Call comments received from ITU-T SG15 on draft-ietf-mpls-loss-delay and draft-ietf-mpls-tp-loss-delay-profile. Stewart & Dan ===== Comments received from ITU in : 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) LS497 draft-ietf-mpls-loss-delay-01, section 2.7.3, Please add at the end the paragraph "These concerns don't arise in MPLS-TP, because ECMP doesn't apply there." This was been added to draft-ietf-mpls-tp-loss-delay-Profile LS497 draft-ietf-mpls-loss-delay-01, section 2.7.6, parag 4, Please add at the end of this paragraph: "There is no limitation of direct LM in MPLS-TP, as PHP is disabled and we cannot presume a control plane, which is the case of LDP." Text to address this has been added to draft-ietf-mpls-tp-loss-delay-profile LS497 draft-ietf-mpls-loss-delay-01, section 2.7.7, There must be a clear definition of which frames integrate the loss measurement scope, for MPLS- TP. Please clarify. This is explicitly stated in Section 4.2.8 of draft-ietf-mpls-loss-delay-02 LS497 draft-ietf-mpls-loss-delay-01, section 3.1, The need of 4 counters is not clear: after the xLM message does A->B->A, the last (4th) measurement is done at reception, so why writing the results into the PDU? The 4th counter isn't really needed. Technically this is correct provided the lifetime of the packet has ended after the fourth TS or counter has been updated and for example the packet is not being forwarded on for external post processing. Even in that case however having the space in the packet for the fourth record may be convenient for some implementations and does no harm. LS497 draft-ietf-mpls-loss-delay-01, section 3.5.2, The addressing should be aligned with the identifiers draft and not have a different implementation for these PDUs. The addressing TLVs specified in the draft-ietf-mpls-loss-delay are generic. The address families defined in the IANA Address Families Registry are sufficient for MPLS networks using IP addressing. If a new address type is required this may be added to the registry through the normal standards action process, and is outside the scope of this draft. LS497 draft-ietf-mpls-loss-delay-01, section 3.5.3, "Session Query Interval" is useless in an NMS environment. Thus, please add to the end of this section "Not applicable to MPLS-TP". It is not obvious that that this field is unless in perpetuity in an NMS controlled environment, but none the less the field is optional. LS497 draft-ietf-mpls-loss-delay-01, section ..., Please consider a new PDU: let's name it PRO-xLM+DM for now. The format could be the same as DLM+DM (with correction suggested in section 3.1). Each time a frame is transmitted, A writes into the PDU counters -A_TxP[n] the number of packets Tx by A at the time this PDU is sent -A_RxP[n] the number of packets Rx at A at the time it got a PDU from B -B_TxP[n] the number of packets Tx by B the last time it Tx a PDU to A We can thus do LM calculations both ways with half the PDUs. Loss measurement @A would be: A_TxLoss = A_TxP[n] - A_TxP[n-1] - (B_RxP[n] - B_RxP[n-1]) A_RxLoss = B_TxP[n] - B_TxP[n-1] - (A_RxP[n] - A_RxP[n-1]) (A_RxP is a counter internally kept @A) For unidireccional applications (say B->A), A_TxLoss has no meaning and A only cares about B_TxP. We have been aware of this possibility from the outset, but took the view that the reduction in PDU frequency did not justify the increased complexity of the protocols. Text has been added to the draft (section 2.7) to explain the issues and describe a method of making the measurement you request. From eosborne@cisco.com Mon May 9 09:24:54 2011 Return-Path: <eosborne@cisco.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 11768E0765 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:24:54 -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 LfvvoFki6I8i for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:24:53 -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 51554E0692 for <mpls@ietf.org>; Mon, 9 May 2011 09:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1554; q=dns/txt; s=iport; t=1304958293; x=1306167893; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EXZChlHy9GIzwpEMTuC2PkUgQ4EDO9COtThmvPxFEA4=; b=W8EJUvtXbe8hL19wonqW9e/aXl53fsS5WHAankSMW0LqsYZLR8ryByPM E/dJRllhZjmSIOyep17ShP8mzYc8uyqjDElRpt3+nCAtLn/0REigHhAsg EZFMHkxcrtWCAWYx6l/izhYIJ78cRixxtGwKgi71q6P6gm15vwZK5ctZI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAE8UyE2tJXG8/2dsb2JhbACXUY4ud6kpnXYChgoEhkCNVopK X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="444312538" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 16:24:52 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49GOqM6021833; Mon, 9 May 2011 16:24:52 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 11:24:52 -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: Mon, 9 May 2011 11:24:49 -0500 Message-ID: <D29E470202D67745B61059870F433B540577BFC7@XMB-RCD-202.cisco.com> In-Reply-To: <4DBC4D2C.9090901@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwHX+mN9iu+12+GR/iSlibRNWYrLgHBbD1w References: <4DBC4D2C.9090901@pi.nu> From: "Eric Osborne (eosborne)" <eosborne@cisco.com> To: "Loa Andersson" <loa@pi.nu>, <mpls@ietf.org> X-OriginalArrivalTime: 09 May 2011 16:24:52.0441 (UTC) FILETIME=[9FEBAC90:01CC0E65] Cc: Ross Callon <rcallon@juniper.net>, draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org Subject: Re: [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 <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: Mon, 09 May 2011 16:24:54 -0000 Yes/support eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 30, 2011 1:56 PM > To: mpls@ietf.org > Cc: Ross Callon; draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-gtsm-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 14th. >=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 loa@pi.nu Mon May 9 09:25:31 2011 Return-Path: <loa@pi.nu> 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 81CD3E0849 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:25: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 H6qWE588sHam for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:25:30 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5417AE0765 for <mpls@ietf.org>; Mon, 9 May 2011 09:25:30 -0700 (PDT) Received: from [109.58.2.233] (109.58.2.233.bredband.tre.se [109.58.2.233]) (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 6B5A32A8002 for <mpls@ietf.org>; Mon, 9 May 2011 18:25:27 +0200 (CEST) Message-ID: <4DC81575.4020704@pi.nu> Date: Mon, 09 May 2011 18:25:25 +0200 From: Loa Andersson <loa@pi.nu> 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" <mpls@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: 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 <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: Mon, 09 May 2011 16:25:31 -0000 Working group, we have a poll going on this draft, but so far the number of responses has been low. Can you please review the draft and see if it ready to become a working group document. /Loa -------- Original Message -------- Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Date: Sat, 30 Apr 2011 10:55:56 -0700 From: Loa Andersson <loa@pi.nu> To: mpls@ietf.org <mpls@ietf.org> CC: Ross Callon <rcallon@juniper.net>, draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org 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 _______________________________________________ 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 Mon May 9 09:56:26 2011 Return-Path: <loa@pi.nu> 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 55B48E06F5 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:56:26 -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 SIgF4Xoe5CRm for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 09:56:20 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3DE06EF for <mpls@ietf.org>; Mon, 9 May 2011 09:56:20 -0700 (PDT) Received: from [109.58.2.233] (109.58.2.233.bredband.tre.se [109.58.2.233]) (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 106752A8001; Mon, 9 May 2011 18:37:36 +0200 (CEST) Message-ID: <4DC8184F.9080402@pi.nu> Date: Mon, 09 May 2011 18:37:35 +0200 From: Loa Andersson <loa@pi.nu> 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" <mpls@ietf.org> References: <4DB1706B.3050602@pi.nu> In-Reply-To: <4DB1706B.3050602@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, draft-asati-pignataro-mpls-ldp-iana@tools.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 <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: Mon, 09 May 2011 16:56:26 -0000 All, this poll has concluded and we have a new working group draft. Could the authors please follow normal procedures and publish a copy of the draft we did the poll on (with exception of dates and filename) as draft-ietf-mpls-ldp-iana-00.txt. /Loa On 2011-04-22 14: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 -- 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 geraldine.calvignac@orange-ftgroup.com Mon May 2 01:46:18 2011 Return-Path: <geraldine.calvignac@orange-ftgroup.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 04115E0655 for <mpls@ietfa.amsl.com>; Mon, 2 May 2011 01:46:18 -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_FR=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 65aWQ1y7bCUn for <mpls@ietfa.amsl.com>; Mon, 2 May 2011 01:46:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF80E0716 for <mpls@ietf.org>; Mon, 2 May 2011 01:46:16 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D32D68B8006; Mon, 2 May 2011 10:46:51 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id CB7DC8B8005; Mon, 2 May 2011 10:46:51 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 10:46:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2011 10:46:14 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102CFA0B8@ftrdmel0.rd.francetelecom.fr> 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: AcwEf9Hp839xVVpZT3emAF6OaOCZAgEIOZ6g References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: <geraldine.calvignac@orange-ftgroup.com> To: <loa@pi.nu>, <mpls@ietf.org> X-OriginalArrivalTime: 02 May 2011 08:46:15.0317 (UTC) FILETIME=[658B8450:01CC08A5] X-Mailman-Approved-At: Mon, 09 May 2011 10:28:34 -0700 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 <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: Mon, 02 May 2011 08:46:18 -0000 yes/support. Geraldine=20 -----Message d'origine----- De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part de = loa@pi.nu Envoy=E9 : mercredi 27 avril 2011 04:06 =C0 : mpls@ietf.org Cc : rcallon@juniper.net Objet : [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 eric.gray@ericsson.com Mon May 9 10:41:34 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 50EFFE0698 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.201, 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 8ixrEeh4TmRx for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:41:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 33B93E067E for <mpls@ietf.org>; Mon, 9 May 2011 10:41:31 -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 p49HfTV3001983 for <mpls@ietf.org>; Mon, 9 May 2011 12:41:31 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 9 May 2011 13:41:30 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Importance: high X-Priority: 1 Date: Mon, 9 May 2011 13:41:23 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwMBAa3Opr/jpaqRcSQhqp8Ckz/MQCbCyXA Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B074A7163@EUSAACMS0701.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 Subject: [mpls] FW: 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: Mon, 09 May 2011 17:41:34 -0000 Forwarding in plain text... ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Friday, May 06, 2011 11:40 AM To: Eric Gray Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Hi Eric, Pleased to say that I am enjoying my vacation ;) On your comments: 1) I agree, we need more open technical discussion. 2) & 3) I agree with some of your comments. I think that the major point w= here I disagree is that I see a significant difference between the need to = "understand" both identifier formats and the need to administer both identi= fier formats. If we allow mixed types then for both operators will need to "understand" t= he "other" format to be able to enter the expected identifier for CV. This= can be achieved by several means; For example, a simple GUI application ca= n aid the input of the expected "foreign" identifier type. Note that when = an identifier is inserted into a CV message the "native" format is always u= sed therefore neither operator has to administer the "foreign" identifier t= ype. If we only allow a single identifier type then one operator must administer= the "foreign" identifier type since this must be inserted into the CV mess= age that is sent. On this basis I suggest that allowing mixed identifiers causes less change = and complexity in the operational processes of the network operators. Regards, Malcolm Eric Gray <eric.gray@ericsson.com> 04/05/2011 12:44 PM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn> cc John E Drake <jdrake@juniper.net>, "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? Hi Malcolm, Hopefully you're enjoying your vacation. To address your specific comments below: 1) I guess the discussion you refer to (on precisely how to avoid the necessity for OAM interworking) was less public than it maybe should have been. That's okay, now that it has been brought up in a broader context. 2) it isn't possible for the operators you refer to avoid administering IP-based identifiers, since inter-operator OAM is not a one-way process. They will need to administer the IP-based identifiers the other carrier uses, if they expect to be able to recognize those identifiers in OAM messages they receive, or include them in OAM messages they send. Entering these identifiers as a "binary string" via a craft interface will be horrendous, hence each vendor will need to help them by providing the user-interfaces to support this. Once they've done this - as they MUST - the need to administer different identifiers for different peering relationships will quickly become more cumbersome than complex - assuming it is not a complete non-starter from the first. This equates in my opinion not only to an argument to prohibit identifier type mixing, but also to only allow one identifier type. The initial requirement - however - was to support two types. If this requirement still applies, then we should at least preclude needless complexity associated with arbitrary mixing of identifier types. I believe this addresses at least some aspect of several of your comments (related to complexity of identifier types, administration etc.). 3) I do not follow your logic on mixing identifiers. The way I would interpret the requirement - based on your own argument - is that there is a requirement for operators to agree on the identifiers they will use (which would not result in mixing them). The reason for this conclusion/interpretation is that either we're formally requiring IP-based operators to recognize and support either identifer type, we're asking ICC-based operators to recognize and support either identifier, or (as seems likely based on discussion) we're requiring both to recognize either. If we're asking both to recognize either, then it is quite likely that either operator could use either identifie= r type and that further means there should be no issue with both of the operators using the same identifier type. It is not conceivable that any inter-carrier OAM would occur without prior agreement on several issues relating to how this OAM would work. This being the case, it is needlessly complex to require support for mixing identifiers. Based on this reasoning, I don't see how a requirement to support mixing of identifiers is anything other than a new requirement. -- Eric ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, May 04, 2011 1:35 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Thank you for your reply, I am currently on vacation with limited access to= email. A few quick comments in line below: Malcolm Eric Gray <eric.gray@ericsson.com> 02/05/2011 10:06 AM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn> cc John E Drake <jdrake@juniper.net>, "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, Thanks for your reply. While it raises some additional questions in my mind, it does make some good points. We will probably get back to you in a few days with a more thorough response, but I want to get back to you on (what I consider) your most significant point, as well as a few of your other points. Perhaps the most significant point you make is that (apparently) SG-15 has recorded discussion that goes into more detail about why an interworking function will not be required. Although I definitely recal= l the assertion that OAM interworking would not be required, I don't recall a specific statement to the effect that - if end-to-end OAM will be used between a domain that uses G.8113.1 OAM and one or more other domains using RFC-based OAM - that RFC-based OAM will be used exclusively for this purpose. But I am prepared to accept your assertion that this is the case. [MB] This was discussed in detail by the group who support the standardizat= ion of both G.8113 (Y.1731 OAM) and "BFD" based OAM for MPLS-TP The creation of G.8113.1 OAM is something that was not expected during the requirements development phase, and it may very well be the case that - since G.8113.1 has been created at this point - some of the requirements we've attempted to address have actually been overcome by events. For example, if - as you've asserted - the intention is that operators that use G.8113.1 OAM will use RFC-based OAM for end-to-end OAM, then possibly the best way to eliminate the complexity associated with having two different identifier types is to remove all references to ICC based identifiers in the current identifiers draft. [MB] I do not follow your logic here. The main point is that if an operat= or that normally runs G.8113.1 with ICC based identifiers has to run "BFD" = based OAM for end to end inter operator connections then we do not want to = impose the additional burden of also having to administer IP based identifi= ers. This is one of the possibilties we should consider. If - again, as you assert - users of G.8113.1 OAM will use RFC-based OAM where there would otherwise be an interworking requirement, then RFC-based OAM should exclusively define Global identifiers as the simplest approach. Another issue in some of your comments is that you seem to be looking at the complexity associated with comparing identifiers, and ignorng complexity associated with producing them. This is the factor I am more concerned about, since it means that the OAM sender has to know more about who will be receiving the OAM message than would otherwise be the case. [MB] That is exactly my point. The sender of the message defines the forma= t of the identifier and must understand how to administer the addresses. T= he receiver only has to know the value of the binary string being received. I also want to address your last comment, as well as some of the implications of several of your other comments. Even if we retain the ICC identifiers, and do not define how to support both identifiers in the same OAM exchange in this version, this does not mean we will - as you say - "never support multi-operator deployments." There is always the potential for a new version to be written to address new requirements. [MB] This is not a "new requirement". When the requirements draft was bein= g developed it was agreed to keep the requirements at a high level to allow= more rapid approval. This is one of the many more detailed requirements t= hat was never documented. However, I must again point out that we have a r= equirement to allow an operator to select the use of either an IP or ICC ba= sed identifier. We must also support multi operator deployments. This cle= arly implies that mixed identifier types must be supported. Finally, it would not be the case - even if we did add the functionality we are discussing - that we would support multiple-operator deployments "in the same way the SDH, OTN and PBB-TE do" - since these do not include both ICC and Global identifiers either. -- Eric PS - bottom-of-stack peeking is not unusual at boundary devices; some operators do it already in order to make sure their services are not being used in any way that is inconsistent with the SLA that is in-place. I am also curious as to how OAM works in scenarios where court-ordered wire tapping or data mirroring is going on. But these are different topics about which I am just curious. I am even more curious as to what the process is for getting an ICC. Can I get one myself? Can jusy anyone get one? ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Monday, May 02, 2011 12:08 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Please see in line below, comments marked with [MB]. Regards, Malcolm Eric Gray <eric.gray@ericsson.com> 29/04/2011 11:47 AM To John E Drake <jdrake@juniper.net>, "Malcolm.BETTS@zte.com.cn" <Malc= olm.BETTS@zte.com.cn> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@ietf.org> Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? I agree with John's interpretation. With a "stiched" LSP, forwarding is done exactly as if the LSP is contiguous. [MB] OK that meets the requirement that OAM and data fate share. If OAM packets are forwarded exactly as data, the difference in the case where an OAM translation needs to occur is minimal. The only difference is the (potential) need for boundary devices to perform translation/adaptation of OAM identifiers. [MB] Two points: 1) How can it be the same if we have a difference in the t= reatment of OAM and data packets. 2) How are OAM packets identified, is t= he boundary node required to examine the bottom of stack label to for the v= alue 13? This appears to be a deviation from "normal" MPLS forwarding beha= viour. With a proper implementation, a translation can be performed with no more impact on OAM messages than would be seen by any data packet that needs to have a CRC modification, or an adaptation from one underlying network layer to another. [MB] In the case of CRC modification the same process is performed on ever= y packet, no difference between OAM and data packets. Since these things also happen, it is difficult to buy the argument that a similar function should not be allowed. If, on the other hand, we were to require equipment that is now purpose built for IP forwarding to be able to map OAM message identifiers to "strange" identifiers (currently used mostly for the "transport layer" in the sense of TDM/optical switching), we may expect all sorts of false indications to occur. [MB] Two points: MPLS-TP forwarding must not rely on the presence of an IP= forwarding function. 2) I do not understand (or accept) your assertion tha= t nodes "purpose built for IP forwarding to be able to map OAM message ide= ntifiers to "strange" identifiers". All that "sink" needs to do is to comp= are the received binary string to the expected binary string to determine i= f the OAM packet is being received from the expected source. I agree that = in the OSS it may be desirable for the OSS to be able to interpret both ide= ntifier formats - but the nodes responsible for forwarding do not need to u= nderstand or interpret the identifier. Besides, my point was that there will clearly be an interworking function requirement in any case. [MB] As discussed at the SG15 meeting and documented in TD458/PLEN an inte= rworking function will not be required. Interworking functions create comp= lexity and should not be used. And piece-wise OAM is often required when interworking is used, and ther is a distinct advantage in terms of divide-and-conquer diagnostics in this case. [MB] Interworking results in piece-wise OAM and prevents end to end integri= ty checks. The potential impact on OAM PDU fowarding due to translation of identifiers will be nothing in comparison with remapping OAM from RFC-based OAM to ITU-T G8113.1-based OAM. [MB] Please remember the discussion at the last SG15 meeting as documented = in TD458/PLEN. If end to end OAM between regions that run RFC based OAM an= d G.8113.1 based OAM will use the RFC version. i.e. An interworking functi= on is not required. Surely you are not now going to argue that there should be end-to- end support for both forms of OAM? But these arguments are very similar. [MB] No - please see my previous comment OAM across service provider boundaries is a very strange thing anyway. Most service providers are extremely reluctant to give their competitors the ability to find out what is wrong within their network. [MB] It is common/mandatory in all existing transport networks to be able = to check the end to end integrity of a connection. This is even more likely to be the case with service providers who have fundamentally different operating paradigms. Other than reports from a small number of people (who've already indicated that they will support a different form of OAM for their customers), we've not seen any evidence that there is a real need to support end-to-end, multi-provider OAM - particularly for the case where peered service providers use different forms of OAM and identifiers. The appropriate time to deal with this possible scenario is when it actually comes up. No doubt it will, given that there is going to be two different types of OAM. But perhaps the vendors and service providers that argued that the applications are sufficently different for the two different OAM types that they will not need to mix, will turn out to be correct... [MB] So in your view MPLS-TP will never support multi-operator deployments= in the same way the SDH, OTN and PBB-TE do? -- Eric ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 27, 2011 7: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 <jdrake@juniper.net> 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Eric Gray <e= ric.gray@ericsson.com> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@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 <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 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 From eric.gray@ericsson.com Mon May 9 10:50:03 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 73F04E0830 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 CWTwC-jJHVDn for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:50:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5EE0817 for <mpls@ietf.org>; Mon, 9 May 2011 10:50: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 p49HnveG003817 for <mpls@ietf.org>; Mon, 9 May 2011 12:50:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 May 2011 13:50:00 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Importance: high X-Priority: 1 Date: Mon, 9 May 2011 13:49:51 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFBXYbQnS5CrT4ylyW0UNm7Y0wBUJvjwAB/KQCACBDCtEA== Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B074A7180@EUSAACMS0701.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 Subject: [mpls] FW: 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: Mon, 09 May 2011 17:50:03 -0000 Forwarding in plain text... ________________________________ From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de]=20 Sent: Monday, May 02, 2011 9:46 AM To: Eric Gray; Malcolm.BETTS@zte.com.cn; swallow@cisco.com Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Dear All, Please see some comments inline marked with [MP]. Thanks, Manuel ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Gray Sent: Thursday, April 28, 2011 10:58 PM To: Malcolm.BETTS@zte.com.cn; George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, There is nothing about not mixing the two identifier formats that=20 prevents an operator from continuing to use ICC identifiers within=20 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. =20 [MP:] Agree that this should be equally applicable to all sides of the stor= y, although backwards compatibility considerations (often stressed along th= e MPLS OAM extension debate) apply here too. Its among TP's primary targets= to fit for classicly operated transport networks, to save efforts and avoi= d disruptive (primarily operational) changes in this arena. Platforms aren= 't migrated with one single snip of the finger (sometimes more for operatio= nal rather than technical complexity). In a real world, may need to interco= nnect platforms in distinct phases of evolution. In case of need for handov= ers, an operator should have the flexibility to decide what device class is= easiest to be (evolutionary) touched and tuned, i.e. supporting mixed iden= tifiers. I admit this occurrence probably will not be as granular as the ge= neral requirement for End-to-End OAM interoperability in a multi-vendor tra= nsport network environment where the boundaries are drawn according to the = reach of optical transparency domains and/or network management feasibiliti= es. 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. =20 [MP:] Is it really that difficult to handle when we focus on the data plane= perspective for now? As in current scope of the identifiers draft? =20 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=20 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. [MP:] Wouldn't it be sufficient to recognize either format to know what sem= antics do apply ( or do not apply ) to handle one, or the other, or boths f= ormats properly on a node? What happens today when a node receives any format that it doesn't support?= Would it result in a confusion / wrong comparison? IMHO solving inter-provider interface issues or automization in assignement= may be tackled subsequently, i.e. in a next step. 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=20 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=20 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,=20 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.=20 Are suggesting that the same operator might make different choices in diffe= rent=20 parts of the same network? =20 [MP:] Looking at the reality where platforms aren't migrated with one singl= e snip of the finger (sometimes for operational rather than technical reaso= ns), it may indeed be of practical relevance. Want to say, even an intra-op= erator but inter-AS scenario may be thinkable.=20 =20 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.=20 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.=20 I believe you are correct in terms of what the requirements are. There is = nothing=20 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.=20 >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.=20 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.=20 Please see in-line below.=20 Regards,=20 Malcolm=20 George Swallow <swallow@cisco.com>=20 Sent by: mpls-bounces@ietf.org=20 25/04/2011 05:16 PM=20 To <mpls@ietf.org>=20 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. =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 iden= tifiers for the data plane changing to IP based identifiers would be a majo= r 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 chec= k that it matches the expected string=20 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.=20 [MB] This would be a major roadblock to the use of MPLS-TP in an inter pro= vider 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 m= essages), 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 id= entifiers.=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 From eric.gray@ericsson.com Mon May 9 10:54:17 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 627F3E0925 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 UR7u4OinrMVB for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:54:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9B227E0891 for <mpls@ietf.org>; Mon, 9 May 2011 10:54:15 -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 p49Hs5PL004777 for <mpls@ietf.org>; Mon, 9 May 2011 12:54:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 May 2011 13:54:12 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Date: Mon, 9 May 2011 13:53:57 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwKHRHA4vCdtLs9S2KgwlnrY2hPugAV0wdgAP9oftA= Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B074A718F@EUSAACMS0701.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 Subject: [mpls] FW: 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: Mon, 09 May 2011 17:54:17 -0000 Forwarding in plain text... ________________________________ From: Eric Gray Sent: Wednesday, May 04, 2011 12:44 PM To: 'Malcolm.BETTS@zte.com.cn' Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, Hopefully you're enjoying your vacation. To address your specific comments below: 1) I guess the discussion you refer to (on precisely how to avoid the necessity for OAM interworking) was less public than it maybe should have been. That's okay, now that it has been brought up in a broader context. 2) it isn't possible for the operators you refer to avoid administering IP-based identifiers, since inter-operator OAM is not a one-way process. They will need to administer the IP-based identifiers the other carrier uses, if they expect to be able to recognize those identifiers in OAM messages they receive, or include them in OAM messages they send. Entering these identifiers as a "binary string" via a craft interface will be horrendous, hence each vendor will need to help them by providing the user-interfaces to support this. Once they've done this - as they MUST - the need to administer different identifiers for different peering relationships will quickly become more cumbersome than complex - assuming it is not a complete non-starter from the first. This equates in my opinion not only to an argument to prohibit identifier type mixing, but also to only allow one identifier type. The initial requirement - however - was to support two types. If this requirement still applies, then we should at least preclude needless complexity associated with arbitrary mixing of identifier types. I believe this addresses at least some aspect of several of your comments (related to complexity of identifier types, administration etc.). 3) I do not follow your logic on mixing identifiers. The way I would interpret the requirement - based on your own argument - is that there is a requirement for operators to agree on the identifiers they will use (which would not result in mixing them). The reason for this conclusion/interpretation is that either we're formally requiring IP-based operators to recognize and support either identifer type, we're asking ICC-based operators to recognize and support either identifier, or (as seems likely based on discussion) we're requiring both to recognize either. If we're asking both to recognize either, then it is quite likely that either operator could use either identifie= r type and that further means there should be no issue with both of the operators using the same identifier type. It is not conceivable that any inter-carrier OAM would occur without prior agreement on several issues relating to how this OAM would work. This being the case, it is needlessly complex to require support for mixing identifiers. Based on this reasoning, I don't see how a requirement to support mixing of identifiers is anything other than a new requirement. -- Eric ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, May 04, 2011 1:35 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Thank you for your reply, I am currently on vacation with limited access to= email. A few quick comments in line below: Malcolm Eric Gray <eric.gray@ericsson.com> 02/05/2011 10:06 AM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn> cc John E Drake <jdrake@juniper.net>, "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, Thanks for your reply. While it raises some additional questions in my mind, it does make some good points. We will probably get back to you in a few days with a more thorough response, but I want to get back to you on (what I consider) your most significant point, as well as a few of your other points. Perhaps the most significant point you make is that (apparently) SG-15 has recorded discussion that goes into more detail about why an interworking function will not be required. Although I definitely recal= l the assertion that OAM interworking would not be required, I don't recall a specific statement to the effect that - if end-to-end OAM will be used between a domain that uses G.8113.1 OAM and one or more other domains using RFC-based OAM - that RFC-based OAM will be used exclusively for this purpose. But I am prepared to accept your assertion that this is the case. [MB] This was discussed in detail by the group who support the standardizat= ion of both G.8113 (Y.1731 OAM) and "BFD" based OAM for MPLS-TP The creation of G.8113.1 OAM is something that was not expected during the requirements development phase, and it may very well be the case that - since G.8113.1 has been created at this point - some of the requirements we've attempted to address have actually been overcome by events. For example, if - as you've asserted - the intention is that operators that use G.8113.1 OAM will use RFC-based OAM for end-to-end OAM, then possibly the best way to eliminate the complexity associated with having two different identifier types is to remove all references to ICC based identifiers in the current identifiers draft. [MB] I do not follow your logic here. The main point is that if an operat= or that normally runs G.8113.1 with ICC based identifiers has to run "BFD" = based OAM for end to end inter operator connections then we do not want to = impose the additional burden of also having to administer IP based identifi= ers. This is one of the possibilties we should consider. If - again, as you assert - users of G.8113.1 OAM will use RFC-based OAM where there would otherwise be an interworking requirement, then RFC-based OAM should exclusively define Global identifiers as the simplest approach. Another issue in some of your comments is that you seem to be looking at the complexity associated with comparing identifiers, and ignorng complexity associated with producing them. This is the factor I am more concerned about, since it means that the OAM sender has to know more about who will be receiving the OAM message than would otherwise be the case. [MB] That is exactly my point. The sender of the message defines the forma= t of the identifier and must understand how to administer the addresses. T= he receiver only has to know the value of the binary string being received. I also want to address your last comment, as well as some of the implications of several of your other comments. Even if we retain the ICC identifiers, and do not define how to support both identifiers in the same OAM exchange in this version, this does not mean we will - as you say - "never support multi-operator deployments." There is always the potential for a new version to be written to addres= s new requirements. [MB] This is not a "new requirement". When the requirements draft was bein= g developed it was agreed to keep the requirements at a high level to allow= more rapid approval. This is one of the many more detailed requirements t= hat was never documented. However, I must again point out that we have a r= equirement to allow an operator to select the use of either an IP or ICC ba= sed identifier. We must also support multi operator deployments. This cle= arly implies that mixed identifier types must be supported. Finally, it would not be the case - even if we did add the functionalit= y we are discussing - that we would support multiple-operator deployments "in the same way the SDH, OTN and PBB-TE do" - since these do not include both ICC and Global identifiers either. -- Eric PS - bottom-of-stack peeking is not unusual at boundary devices; some operators do it already in order to make sure their services are not being used in any way that is inconsistent with the SLA that is in-place. I am also curious as to how OAM works in scenarios where court-ordered wire tapping or data mirroring is going on. But these are different topics about which I am just curious. I am even more curious as to what the process is for getting an ICC. Can I get one myself? Can jusy anyone get one? ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Monday, May 02, 2011 12:08 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Please see in line below, comments marked with [MB]. Regards, Malcolm Eric Gray <eric.gray@ericsson.com> 29/04/2011 11:47 AM To John E Drake <jdrake@juniper.net>, "Malcolm.BETTS@zte.com.cn" <Malc= olm.BETTS@zte.com.cn> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@ietf.org> Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? I agree with John's interpretation. With a "stiched" LSP, forwarding is done exactly as if the LSP is contiguous. [MB] OK that meets the requirement that OAM and data fate share. If OAM packets are forwarded exactly as data, the difference in the case where an OAM translation needs to occur is minimal. The only difference is the (potential) need for boundary devices to perform translation/adaptation of OAM identifiers. [MB] Two points: 1) How can it be the same if we have a difference in the t= reatment of OAM and data packets. 2) How are OAM packets identified, is t= he boundary node required to examine the bottom of stack label to for the v= alue 13? This appears to be a deviation from "normal" MPLS forwarding beha= viour. With a proper implementation, a translation can be performed with no more impact on OAM messages than would be seen by any data packet that needs to have a CRC modification, or an adaptation from one underlying network layer to another. [MB] In the case of CRC modification the same process is performed on ever= y packet, no difference between OAM and data packets. Since these things also happen, it is difficult to buy the argument that a similar function should not be allowed. If, on the other hand, we were to require equipment that is now purpose built for IP forwarding to be able to map OAM message identifiers to "strange" identifiers (currently used mostly for the "transport layer" in the sense of TDM/optical switching), we may expect all sorts of false indications to occur. [MB] Two points: MPLS-TP forwarding must not rely on the presence of an IP= forwarding function. 2) I do not understand (or accept) your assertion tha= t nodes "purpose built for IP forwarding to be able to map OAM message ide= ntifiers to "strange" identifiers". All that "sink" needs to do is to comp= are the received binary string to the expected binary string to determine i= f the OAM packet is being received from the expected source. I agree that = in the OSS it may be desirable for the OSS to be able to interpret both ide= ntifier formats - but the nodes responsible for forwarding do not need to u= nderstand or interpret the identifier. Besides, my point was that there will clearly be an interworking function requirement in any case. [MB] As discussed at the SG15 meeting and documented in TD458/PLEN an inte= rworking function will not be required. Interworking functions create comp= lexity and should not be used. And piece-wise OAM is often required when interworking is used, and ther is a distinct advantage in terms of divide-and-conquer diagnostics in this case. [MB] Interworking results in piece-wise OAM and prevents end to end integri= ty checks. The potential impact on OAM PDU fowarding due to translation of identifiers will be nothing in comparison with remapping OAM from RFC-based OAM to ITU-T G8113.1-based OAM. [MB] Please remember the discussion at the last SG15 meeting as documented = in TD458/PLEN. If end to end OAM between regions that run RFC based OAM an= d G.8113.1 based OAM will use the RFC version. i.e. An interworking functi= on is not required. Surely you are not now going to argue that there should be end-to- end support for both forms of OAM? But these arguments are very similar. [MB] No - please see my previous comment OAM across service provider boundaries is a very strange thing anyway. Most service providers are extremely reluctant to give their competitors the ability to find out what is wrong within their network. [MB] It is common/mandatory in all existing transport networks to be able = to check the end to end integrity of a connection. This is even more likely to be the case with service providers who have fundamentally different operating paradigms. Other than reports from a small number of people (who've already indicated that they will support a different form of OAM for their customers), we've not seen any evidence that there is a real need to support end-to-end, multi-provider OAM - particularly for the case where peered service providers use different forms of OAM and identifiers. The appropriate time to deal with this possible scenario is when it actually comes up. No doubt it will, given that there is going to be two different types of OAM. But perhaps the vendors and service providers that argued that the applications are sufficently different for the two different OAM types that they will not need to mix, will turn out to be correct... [MB] So in your view MPLS-TP will never support multi-operator deployments= in the same way the SDH, OTN and PBB-TE do? -- Eric ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 27, 2011 7: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 <jdrake@juniper.net> 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Eric Gray <e= ric.gray@ericsson.com> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@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 <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 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 From eric.gray@ericsson.com Mon May 9 10:54:18 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 3A813E0891 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 oANt3HbiLN5E for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 10:54:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 26DCBE0922 for <mpls@ietf.org>; Mon, 9 May 2011 10:54:15 -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 p49Hs5PJ004777 for <mpls@ietf.org>; Mon, 9 May 2011 12:54:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 May 2011 13:54:08 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Date: Mon, 9 May 2011 13:53:03 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwMBAa3Opr/jpaqRcSQhqp8Ckz/MQACKpsQAJlKlUA= Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B074A718E@EUSAACMS0701.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 Subject: [mpls] FW: 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: Mon, 09 May 2011 17:54:18 -0000 Forwarding in plain text... ________________________________ From: Eric Gray Sent: Friday, May 06, 2011 1:38 PM To: 'Malcolm.BETTS@zte.com.cn' Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, I don't think anyone is objecting to use of mixed identifiers in a subs= equent set of specifications. Where the strongest objections are coming up is in = the question of why this is needed for the current version(s). However convenient some may feel it is, to be able to use mixed identif= iers in uncommon cases involving inter-carrier OAM, it's non-trivial to work thr= ough the implications. And there is little point in doing a thing if there are serious and leg= itimate concerns about the implications. One thing that is a problem (and this is just one thing), is that the f= olks who use IP-based identifiers also tend to use signaling. It is for this reason= that it is important that IP-based identifiers can be predictably derived from info= rmation known to signaling entities. The paradigm associated with ICC identifier use appears to be significa= ntly different. ICC identifiers apparently need to be configured in every case,= either by an operator, or by an OSS. If there is signaling involved, it is clearl= y not of the sort that a peering IP-based carrier would be participating in. There are a number of issues that need to be worked through in order to= be able to understand all of the implications of having to configure ICC infor= mation in devices that may be part of a service in one instance and not part of it= in the next (as a result of dynamic changes) - or vice versa. There is also the issue that we've previously discussed in gory detail = with just how much - and what kinds - of OAM will be allowed between carriers. I am not sure that you (or many others involved in this discussion) wou= ld be familiar with this previous discussion, as it took place on IETF mailing li= sts as much as a decade ago. It is certainly not clear that there is any reason why a carrier would = want to expose their network devices to potential OAM-based attack by a competing carrier. In fact, it does not seem too likely that any carrier would be wi= lling to allow even legitimate exploration of their network internals by another car= rier. Chances are good that an IP-based service provider would be willing onl= y to expose the devices that provide ingress/egress to/from their network to ano= ther carrier. For this case, since these points are very likely to be relativel= y static, it seems much more likely that the IP-based carrier could be persuaded to configure whatever ICC identifiers the other carrier wants them to use - fo= r just these devices - than that they would be willing to configure ICC identifier= s in a much larger subset of their network. Two things to note about this: 1) If the IP-based carrier is unwilling or unable to do this, then there is= no basis for assuming they would be able to support the mixed identifier case ei= ther. 2) This approach works equally well for the intra-carrier case (where a car= rier is transitioning their network from devices that natively use one ident= ifier type to network devices that natively use the other). From what I understand, this is a frequently used operating model alrea= dy. Taking these (and other) factors into account, support for the mixed id= entifier case doesn't appear to be immediately necessary, would (at best) be conveni= ent in what appears to be a very uncommon case, and would only serve to delay t= he progress of work on identifiers for the much more common cases. -- Eric ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Friday, May 06, 2011 11:40 AM To: Eric Gray Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Hi Eric, Pleased to say that I am enjoying my vacation ;) On your comments: 1) I agree, we need more open technical discussion. 2) & 3) I agree with some of your comments. I think that the major point w= here I disagree is that I see a significant difference between the need to = "understand" both identifier formats and the need to administer both identi= fier formats. If we allow mixed types then for both operators will need to "understand" t= he "other" format to be able to enter the expected identifier for CV. This= can be achieved by several means; For example, a simple GUI application ca= n aid the input of the expected "foreign" identifier type. Note that when = an identifier is inserted into a CV message the "native" format is always u= sed therefore neither operator has to administer the "foreign" identifier t= ype. If we only allow a single identifier type then one operator must administer= the "foreign" identifier type since this must be inserted into the CV mess= age that is sent. On this basis I suggest that allowing mixed identifiers causes less change = and complexity in the operational processes of the network operators. Regards, Malcolm Eric Gray <eric.gray@ericsson.com> 04/05/2011 12:44 PM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn> cc John E Drake <jdrake@juniper.net>, "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? Hi Malcolm, Hopefully you're enjoying your vacation. To address your specific comments below: 1) I guess the discussion you refer to (on precisely how to avoid the necessity for OAM interworking) was less public than it maybe should have been. That's okay, now that it has been brought up in a broader context. 2) it isn't possible for the operators you refer to avoid administering IP-based identifiers, since inter-operator OAM is not a one-way process. They will need to administer the IP-based identifiers the other carrier uses, if they expect to be able to recognize those identifiers in OAM messages they receive, or include them in OAM messages they send. Entering these identifiers as a "binary string" via a craft interface will be horrendous, hence each vendor will need to help them by providing the user-interfaces to support this. Once they've done this - as they MUST - the need to administer different identifiers for different peering relationships will quickly become more cumbersome than complex - assuming it is not a complete non-starter from the first. This equates in my opinion not only to an argument to prohibit identifier type mixing, but also to only allow one identifier type. The initial requirement - however - was to support two types. If this requirement still applies, then we should at least preclude needless complexity associated with arbitrary mixing of identifier types. I believe this addresses at least some aspect of several of your comments (related to complexity of identifier types, administration etc.). 3) I do not follow your logic on mixing identifiers. The way I would interpret the requirement - based on your own argument - is that there is a requirement for operators to agree on the identifiers they will use (which would not result in mixing them). The reason for this conclusion/interpretation is that either we're formally requiring IP-based operators to recognize and support either identifer type, we're asking ICC-based operators to recognize and support either identifier, or (as seems likely based on discussion) we're requiring both to recognize either. If we're asking both to recognize either, then it is quite likely that either operator could use either identifie= r type and that further means there should be no issue with both of the operators using the same identifier type. It is not conceivable that any inter-carrier OAM would occur without prior agreement on several issues relating to how this OAM would work. This being the case, it is needlessly complex to require support for mixing identifiers. Based on this reasoning, I don't see how a requirement to support mixing of identifiers is anything other than a new requirement. -- Eric ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, May 04, 2011 1:35 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Thank you for your reply, I am currently on vacation with limited access to= email. A few quick comments in line below: Malcolm Eric Gray <eric.gray@ericsson.com> 02/05/2011 10:06 AM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn> cc John E Drake <jdrake@juniper.net>, "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, Thanks for your reply. While it raises some additional questions in my mind, it does make some good points. We will probably get back to you in a few days with a more thorough response, but I want to get back to you on (what I consider) your most significant point, as well as a few of your other points. Perhaps the most significant point you make is that (apparently) SG-15 has recorded discussion that goes into more detail about why an interworking function will not be required. Although I definitely recal= l the assertion that OAM interworking would not be required, I don't recall a specific statement to the effect that - if end-to-end OAM will be used between a domain that uses G.8113.1 OAM and one or more other domains using RFC-based OAM - that RFC-based OAM will be used exclusively for this purpose. But I am prepared to accept your assertion that this is the case. [MB] This was discussed in detail by the group who support the standardizat= ion of both G.8113 (Y.1731 OAM) and "BFD" based OAM for MPLS-TP The creation of G.8113.1 OAM is something that was not expected during the requirements development phase, and it may very well be the case that - since G.8113.1 has been created at this point - some of the requirements we've attempted to address have actually been overcome by events. For example, if - as you've asserted - the intention is that operators that use G.8113.1 OAM will use RFC-based OAM for end-to-end OAM, then possibly the best way to eliminate the complexity associated with having two different identifier types is to remove all references to ICC based identifiers in the current identifiers draft. [MB] I do not follow your logic here. The main point is that if an operat= or that normally runs G.8113.1 with ICC based identifiers has to run "BFD" = based OAM for end to end inter operator connections then we do not want to = impose the additional burden of also having to administer IP based identifi= ers. This is one of the possibilties we should consider. If - again, as you assert - users of G.8113.1 OAM will use RFC-based OAM where there would otherwise be an interworking requirement, then RFC-based OAM should exclusively define Global identifiers as the simplest approach. Another issue in some of your comments is that you seem to be looking at the complexity associated with comparing identifiers, and ignorng complexity associated with producing them. This is the factor I am more concerned about, since it means that the OAM sender has to know more about who will be receiving the OAM message than would otherwise be the case. [MB] That is exactly my point. The sender of the message defines the forma= t of the identifier and must understand how to administer the addresses. T= he receiver only has to know the value of the binary string being received. I also want to address your last comment, as well as some of the implications of several of your other comments. Even if we retain the ICC identifiers, and do not define how to support both identifiers in the same OAM exchange in this version, this does not mean we will - as you say - "never support multi-operator deployments." There is always the potential for a new version to be written to address new requirements. [MB] This is not a "new requirement". When the requirements draft was bein= g developed it was agreed to keep the requirements at a high level to allow= more rapid approval. This is one of the many more detailed requirements t= hat was never documented. However, I must again point out that we have a r= equirement to allow an operator to select the use of either an IP or ICC ba= sed identifier. We must also support multi operator deployments. This cle= arly implies that mixed identifier types must be supported. Finally, it would not be the case - even if we did add the functionality we are discussing - that we would support multiple-operator deployments "in the same way the SDH, OTN and PBB-TE do" - since these do not include both ICC and Global identifiers either. -- Eric PS - bottom-of-stack peeking is not unusual at boundary devices; some operators do it already in order to make sure their services are not being used in any way that is inconsistent with the SLA that is in-place. I am also curious as to how OAM works in scenarios where court-ordered wire tapping or data mirroring is going on. But these are different topics about which I am just curious. I am even more curious as to what the process is for getting an ICC. Can I get one myself? Can jusy anyone get one? ________________________________ From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Monday, May 02, 2011 12:08 AM To: Eric Gray Cc: John E Drake; mpls@ietf.org; mpls-bounces@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Eric, Please see in line below, comments marked with [MB]. Regards, Malcolm Eric Gray <eric.gray@ericsson.com> 29/04/2011 11:47 AM To John E Drake <jdrake@juniper.net>, "Malcolm.BETTS@zte.com.cn" <Malc= olm.BETTS@zte.com.cn> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@ietf.org> Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? I agree with John's interpretation. With a "stiched" LSP, forwarding is done exactly as if the LSP is contiguous. [MB] OK that meets the requirement that OAM and data fate share. If OAM packets are forwarded exactly as data, the difference in the case where an OAM translation needs to occur is minimal. The only difference is the (potential) need for boundary devices to perform translation/adaptation of OAM identifiers. [MB] Two points: 1) How can it be the same if we have a difference in the t= reatment of OAM and data packets. 2) How are OAM packets identified, is t= he boundary node required to examine the bottom of stack label to for the v= alue 13? This appears to be a deviation from "normal" MPLS forwarding beha= viour. With a proper implementation, a translation can be performed with no more impact on OAM messages than would be seen by any data packet that needs to have a CRC modification, or an adaptation from one underlying network layer to another. [MB] In the case of CRC modification the same process is performed on ever= y packet, no difference between OAM and data packets. Since these things also happen, it is difficult to buy the argument that a similar function should not be allowed. If, on the other hand, we were to require equipment that is now purpose built for IP forwarding to be able to map OAM message identifiers to "strange" identifiers (currently used mostly for the "transport layer" in the sense of TDM/optical switching), we may expect all sorts of false indications to occur. [MB] Two points: MPLS-TP forwarding must not rely on the presence of an IP= forwarding function. 2) I do not understand (or accept) your assertion tha= t nodes "purpose built for IP forwarding to be able to map OAM message ide= ntifiers to "strange" identifiers". All that "sink" needs to do is to comp= are the received binary string to the expected binary string to determine i= f the OAM packet is being received from the expected source. I agree that = in the OSS it may be desirable for the OSS to be able to interpret both ide= ntifier formats - but the nodes responsible for forwarding do not need to u= nderstand or interpret the identifier. Besides, my point was that there will clearly be an interworking function requirement in any case. [MB] As discussed at the SG15 meeting and documented in TD458/PLEN an inte= rworking function will not be required. Interworking functions create comp= lexity and should not be used. And piece-wise OAM is often required when interworking is used, and ther is a distinct advantage in terms of divide-and-conquer diagnostics in this case. [MB] Interworking results in piece-wise OAM and prevents end to end integri= ty checks. The potential impact on OAM PDU fowarding due to translation of identifiers will be nothing in comparison with remapping OAM from RFC-based OAM to ITU-T G8113.1-based OAM. [MB] Please remember the discussion at the last SG15 meeting as documented = in TD458/PLEN. If end to end OAM between regions that run RFC based OAM an= d G.8113.1 based OAM will use the RFC version. i.e. An interworking functi= on is not required. Surely you are not now going to argue that there should be end-to- end support for both forms of OAM? But these arguments are very similar. [MB] No - please see my previous comment OAM across service provider boundaries is a very strange thing anyway. Most service providers are extremely reluctant to give their competitors the ability to find out what is wrong within their network. [MB] It is common/mandatory in all existing transport networks to be able = to check the end to end integrity of a connection. This is even more likely to be the case with service providers who have fundamentally different operating paradigms. Other than reports from a small number of people (who've already indicated that they will support a different form of OAM for their customers), we've not seen any evidence that there is a real need to support end-to-end, multi-provider OAM - particularly for the case where peered service providers use different forms of OAM and identifiers. The appropriate time to deal with this possible scenario is when it actually comes up. No doubt it will, given that there is going to be two different types of OAM. But perhaps the vendors and service providers that argued that the applications are sufficently different for the two different OAM types that they will not need to mix, will turn out to be correct... [MB] So in your view MPLS-TP will never support multi-operator deployments= in the same way the SDH, OTN and PBB-TE do? -- Eric ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, April 27, 2011 7: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 <jdrake@juniper.net> 27/04/2011 06:53 PM To "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Eric Gray <e= ric.gray@ericsson.com> cc "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-boun= ces@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 <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 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 From venkatflex@gmail.com Mon May 9 11:58:12 2011 Return-Path: <venkatflex@gmail.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 C3012E071F for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 slD8FapGHhXp for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 11:58:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDAE8E070E for <mpls@ietf.org>; Mon, 9 May 2011 11:58:10 -0700 (PDT) Received: by vxg33 with SMTP id 33so394084vxg.31 for <mpls@ietf.org>; Mon, 09 May 2011 11:58:10 -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=plaopwmF6HOTJyUcsSedKtOUEq9nDUNN5EGaKmMCzcI=; b=CYPySwJhOBgjtNMCQDoSjmOxms5se7qXCjXRYGkx3OjJbvP78u+KLKYVkGJLr4p7sj oOWtUzW6S25tecVWbkwu4nEQZyLVgJNN3B6oYn5+3EPClFMuFVlN1arRO2nAUQsT3XBK WfCRc3XEdELYGB7O28XXl+TUDDkQpPic/W7cE= 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=R3QzJtfJM1G32aFqO72ZPrMy/JV/5qJJ/llFFVdtx4wyjvuHL9UWxjTsWz+MJVo5/j wtT8uC09Yz08C5MRMTtmY/8X2qfmZZgwLG2ZvLOH3Ivhej2Hq+7ilfYZ+ycFdbuTzhrI /Fdufgtcdwgm4ZmZphOyk0Qj5QDkNBxHf+274= MIME-Version: 1.0 Received: by 10.52.96.234 with SMTP id dv10mr3514978vdb.19.1304967490300; Mon, 09 May 2011 11:58:10 -0700 (PDT) Received: by 10.52.109.9 with HTTP; Mon, 9 May 2011 11:58:10 -0700 (PDT) Date: Mon, 9 May 2011 14:58:10 -0400 Message-ID: <BANLkTik0Hb4_3NM3G9-KZKM9KHVERowG_Q@mail.gmail.com> From: venkatesan mahalingam <venkatflex@gmail.com> To: jcucchiara@mindspring.com, mpls <mpls@ietf.org> Content-Type: multipart/alternative; boundary=20cf307f3188b3e9c504a2dc6bf3 Cc: draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] Comments: poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Mon, 09 May 2011 18:58:12 -0000 --20cf307f3188b3e9c504a2dc6bf3 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Yes, the mplsTunnelExtTable is meant for Sparse augmenting the mplsTunnelTable. i.e. Entries will exist in the mplsTunnelExtTable only for MPLS_TP tunnels that are based on global ID and Node ID and/or ICC-ID. This mplsTunnelExtTable is similar to gmplsTunnelEntry specified in RFC4802. We understand that gmplsTunnelTable is also sparse augmented only for gmpls Tunnels. We understand that RFC4802 is not doing any redefinition of the indices. Similarly, mplsTunnelExtTable is not meant for redefining the indices. mplsTunnelExtTable uses the same indices as mplsTunnelTable. Only the meaning of them is interpreted based on mpls-tp-identifier. Is it possible to explain the reason behind your question "would the indexes redefined for TP be acceptable" ? Cheers, Venkat. ------------------------------ - *To*: <loa at pi.nu <loa@DOMAIN.HIDDEN>>, <mpls at ietf.org<mpls@DOMAIN.HIDDEN> > - *Subject*: Re: [mpls] Comments: poll on draft-vkst-mpls-tp-te-mib-00.txt - *From*: "Joan Cucchiara" <jcucchiara at mindspring.com<jcucchiara@DOMAIN.HIDDEN> > - *Date*: Sun, 8 May 2011 17:30:57 -0400 - *Cc*: rcallon at juniper.net <rcallon@DOMAIN.HIDDEN>, draft-vkst-mpls-tp-te-mib at tools.ietf.org <draft-vkst-mpls-tp-te-mib@DOMAIN.HIDDEN> - *Delivered-to*: mpls at ietfa.amsl.com <mpls@DOMAIN.HIDDEN> - *Domainkey-signature*: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d= mindspring.com; b=cohHsKaK9SRjtdZzjKzUL1x7XcAmurB4x7w9CJ6q/1vFXjIcgOVzAoXTG5+lgANy; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; - *List-archive*: <http://www.ietf.org/mail-archive/web/mpls> - *List-help*: <mailto:mpls-request@ietf.org?subject=help<mpls-request@ietf.org?subject=help> > - *List-id*: Multi-Protocol Label Switching WG <mpls.ietf.org> - *List-post*: <mailto:mpls@ietf.org <mpls@ietf.org>> - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/mpls>, < mailto:mpls-request@ietf.org?subject=subscribe<mpls-request@ietf.org?subject=subscribe> > - *List-unsubscribe*: <https://www.ietf.org/mailman/options/mpls>, < mailto:mpls-request@ietf.org?subject=unsubscribe<mpls-request@ietf.org?subject=unsubscribe> > - *References*: <833768e1a607dbafe4f3463989757b1a.squirrel at pi.nu<833768e1a607dbafe4f3463989757b1a.squirrel@DOMAIN.HIDDEN> > ------------------------------ Hi, While there seems to be a benefit to keeping all the "mpls" tunnels in one table (i.e. the mplsTunnelTable in RFC3812). I have a concern about what seems to be a redefinition of the indexes for the mplsTunnelTable. This draft contains a table: mplsTunnelExtTable which AUGMENTS the mplsTunnelTable in RFC3812. The indexes are: INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } The above indexes seem to be redefined in this draft (quoting from the DESCRIPTION clause): "As per MPLS-TP Identifiers draft, LSP_ID is Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID:: Dst-Tunnel_Num::LSP_Num for IP operator and Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num for ICC operator, mplsTunnelTable is reused for forming the LSP_ID as follows, Source Tunnel_Num is mapped with mplsTunnelIndex, Source node identifier is mapped with mplsTunnelIngressLSRId, Destination node identifier is mapped with mplsTunnelEgressLSRId LSP_Num is mapped with mplsTunnelInstance. Source Global identifier/ICC and Destination Global identifier/ICC are maintained in the mplsNodeConfigTable and mplsNodeConfigLocalNum is used to create an entry in mplsTunnelTable." Additionally, one now needs to first configure an entry in the mplsNodeConfigTable in this draft, then one can create an entry in the mplsTunnelTable (RFC3812). Adrian Farrel suggested that the mplsTunnelExtTable in this draft was probably meant to have sparse-augments relationship to the mplsTunnelTable. While I would agree that this is probably the case, even with a sparse-augments relationship, would the indexes redefined for TP be acceptable? I think not, although (as mentioned at the beginning), I do see an advantage for having all mpls-based Tunnels in one table. Would definitely like to see this discussed prior to accepting this draft was a WG group document. Thank you, -Joan ----- Original Message ----- From: <loa at pi.nu> To: <mpls at ietf.org> Cc: <rcallon at juniper.net>; <draft-vkst-mpls-tp-te-mib at tools.ietf.org> Sent: Tuesday, May 03, 2011 1:47 PM Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt Working Group, this is to start a two week poll on making draft-vkst-mpls-tp-te-mib-00.txt 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 2011-05-18. /Loa _______________________________________________ mpls mailing list mpls at ietf.org https://www.ietf.org/mailman/listinfo/mpls --20cf307f3188b3e9c504a2dc6bf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span class=3D"Apple-style-span" style=3D"font-family: monospace; font-size= : 13px; ">Hi All,<br><br>Yes, the mplsTunnelExtTable is meant for Sparse au= gmenting the mplsTunnelTable. i.e. Entries will exist in</span><div><span c= lass=3D"Apple-style-span" style=3D"font-family: monospace; font-size: 13px;= ">the mplsTunnelExtTable only for MPLS_TP tunnels=A0that are based on glob= al ID and Node ID and/or ICC-ID.<br> This mplsTunnelExtTable is similar to gmplsTunnelEntry specified in RFC4802= .<br><br>We understand that gmplsTunnelTable is also sparse augmented only = for gmpls Tunnels.</span></div><div><span class=3D"Apple-style-span" style= =3D"font-family: monospace; font-size: 13px; ">We understand that RFC4802 i= s not doing any redefinition of the indices.=A0<br> Similarly, mplsTunnelExtTable is not meant for redefining the indices.<br>m= plsTunnelExtTable uses the same indices as mplsTunnelTable. Only the meanin= g of them is interpreted based on mpls-tp-identifier.<br>Is it possible to = explain the reason behind your question "would the indexes redefined f= or TP be acceptable" ?<br> <br>Cheers,<br>Venkat.</span><br><hr style=3D"font-family: 'Times New R= oman'; font-size: medium; "><ul style=3D"font-family: 'Times New Ro= man'; font-size: medium; "><li><em>To</em>: <<a href=3D"mailto:loa@D= OMAIN.HIDDEN">loa at pi.nu</a>>, <<a href=3D"mailto:mpls@DOMAIN.HIDDE= N">mpls at ietf.org</a>></li> <li><em>Subject</em>: Re: [mpls] Comments: poll on draft-vkst-mpls-tp-te-mi= b-00.txt</li><li><em>From</em>: "Joan Cucchiara" <<a href=3D"m= ailto:jcucchiara@DOMAIN.HIDDEN">jcucchiara at mindspring.com</a>></li> <li><em>Date</em>: Sun, 8 May 2011 17:30:57 -0400</li><li><em>Cc</em>:=A0<a= href=3D"mailto:rcallon@DOMAIN.HIDDEN">rcallon at juniper.net</a>,=A0<a hre= f=3D"mailto:draft-vkst-mpls-tp-te-mib@DOMAIN.HIDDEN">draft-vkst-mpls-tp-te-= mib at tools.ietf.org</a></li> <li><em>Delivered-to</em>:=A0<a href=3D"mailto:mpls@DOMAIN.HIDDEN">mpls at = ietfa.amsl.com</a></li><li><em>Domainkey-signature</em>: a=3Drsa-sha1; q=3D= dns; c=3Dnofws; s=3Ddk20050327; d=3D<a href=3D"http://mindspring.com">minds= pring.com</a>; b=3DcohHsKaK9SRjtdZzjKzUL1x7XcAmurB4x7w9CJ6q/1vFXjIcgOVzAoXT= G5+lgANy; h=3DReceived:Message-ID:From:To:Cc:References:Subject:Date:MIME-V= ersion:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:= X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;</li> <li><em>List-archive</em>: <<a href=3D"http://www.ietf.org/mail-archive/= web/mpls">http://www.ietf.org/mail-archive/web/mpls</a>></li><li><em>Lis= t-help</em>: <<a href=3D"mailto:mpls-request@ietf.org?subject=3Dhelp">ma= ilto:mpls-request@ietf.org?subject=3Dhelp</a>></li> <li><em>List-id</em>: Multi-Protocol Label Switching WG <<a href=3D"http= ://mpls.ietf.org">mpls.ietf.org</a>></li><li><em>List-post</em>: <<a = href=3D"mailto:mpls@ietf.org">mailto:mpls@ietf.org</a>></li><li><em>List= -subscribe</em>: <<a href=3D"https://www.ietf.org/mailman/listinfo/mpls"= >https://www.ietf.org/mailman/listinfo/mpls</a>>, <<a href=3D"mailto:= mpls-request@ietf.org?subject=3Dsubscribe">mailto:mpls-request@ietf.org?sub= ject=3Dsubscribe</a>></li> <li><em>List-unsubscribe</em>: <<a href=3D"https://www.ietf.org/mailman/= options/mpls">https://www.ietf.org/mailman/options/mpls</a>>, <<a hre= f=3D"mailto:mpls-request@ietf.org?subject=3Dunsubscribe">mailto:mpls-reques= t@ietf.org?subject=3Dunsubscribe</a>></li> <li><em>References</em>: <<a href=3D"mailto:833768e1a607dbafe4f346398975= 7b1a.squirrel@DOMAIN.HIDDEN">833768e1a607dbafe4f3463989757b1a.squirrel at p= i.nu</a>></li></ul><hr style=3D"font-family: 'Times New Roman'; = font-size: medium; "> <span class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman= '; font-size: medium; "><pre style=3D"white-space: pre-wrap; word-wrap:= break-word; width: 1122px; margin-top: 0em; margin-right: 0em; margin-bott= om: 0em; margin-left: 0em; "> Hi, </pre></span><span class=3D"Apple-style-span" style=3D"font-family: 'Ti= mes New Roman'; font-size: medium; "><tt>While there seems to be a bene= fit to keeping all the "mpls" tunnels in one=A0</tt></span><span = class=3D"Apple-style-span" style=3D"font-family: 'Times New Roman';= font-size: medium; "><tt>table</tt></span><span class=3D"Apple-style-span"= style=3D"font-family: 'Times New Roman'; font-size: medium; "><pre= style=3D"white-space: pre-wrap; word-wrap: break-word; width: 1122px; marg= in-top: 0em; margin-right: 0em; margin-bottom: 0em; margin-left: 0em; "> (i.e. the mplsTunnelTable in RFC3812). I have a concern about what seems to be a redefinition of the indexes for the mplsTunnelTable. This draft contains a table: mplsTunnelExtTable which AUGMENTS the mplsTunnelTable in RFC3812. The indexes are: INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } The above indexes seem to be redefined in this draft (quoting from the DESCRIPTION clause): "As per MPLS-TP Identifiers draft, LSP_ID is Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID:: Dst-Tunnel_Num::LSP_Num for IP operator and Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num for ICC operator, mplsTunnelTable is reused for forming the LSP_ID as follows, Source Tunnel_Num is mapped with mplsTunnelIndex, Source node identifier is mapped with mplsTunnelIngressLSRId, Destination node identifier is mapped with mplsTunnelEgressLSRId LSP_Num is mapped with mplsTunnelInstance. Source Global identifier/ICC and Destination Global identifier/ICC are maintained in the mplsNodeConfigTable and mplsNodeConfigLocalNum is used to create an entry in mplsTunnelTable." Additionally, one now needs to first configure an entry in the mplsNodeConfigTable in this draft, then one can create an entry in the mplsTunnelTable (RFC3812). </pre></span><span class=3D"Apple-style-span" style=3D"font-family: 'Ti= mes New Roman'; font-size: medium; "><tt>Adrian Farrel suggested that t= he mplsTunnelExtTable in this draft was=A0</tt></span><span class=3D"Apple-= style-span" style=3D"font-family: 'Times New Roman'; font-size: med= ium; "><tt>probably meant to have=A0</tt></span><span class=3D"Apple-style-= span" style=3D"font-family: 'Times New Roman'; font-size: medium; "= ><tt>sparse-augments relationship to the mplsTunnelTable. While I would agr= ee=A0</tt></span><span class=3D"Apple-style-span" style=3D"font-family: = 9;Times New Roman'; font-size: medium; "><tt>that</tt></span><span clas= s=3D"Apple-style-span" style=3D"font-family: 'Times New Roman'; fon= t-size: medium; "><pre style=3D"white-space: pre-wrap; word-wrap: break-wor= d; width: 1122px; margin-top: 0em; margin-right: 0em; margin-bottom: 0em; m= argin-left: 0em; "> this is probably the case, even with a sparse-augments relationship, would the indexes redefined for TP be acceptable? I think not, although (as mentioned at the beginning), I do see an advantage for having all mpls-based Tunnels in one table. </pre></span><span class=3D"Apple-style-span" style=3D"font-family: 'Ti= mes New Roman'; font-size: medium; "><tt>Would definitely like to see t= his discussed prior to accepting this draft=A0</tt></span><span class=3D"Ap= ple-style-span" style=3D"font-family: 'Times New Roman'; font-size:= medium; "><tt>was</tt></span><span class=3D"Apple-style-span" style=3D"fon= t-family: 'Times New Roman'; font-size: medium; "><pre style=3D"whi= te-space: pre-wrap; word-wrap: break-word; width: 1122px; margin-top: 0em; = margin-right: 0em; margin-bottom: 0em; margin-left: 0em; "> a WG group document. Thank you, -Joan </pre></span><span class=3D"Apple-style-span" style=3D"font-family: 'Ti= mes New Roman'; font-size: medium; "><tt>----- Original Message -----= =A0</tt></span><span class=3D"Apple-style-span" style=3D"font-family: '= Times New Roman'; font-size: medium; "><tt>From: <loa at <a href=3D"= http://pi.nu">pi.nu</a>></tt></span><span class=3D"Apple-style-span" sty= le=3D"font-family: 'Times New Roman'; font-size: medium; "><pre sty= le=3D"white-space: pre-wrap; word-wrap: break-word; width: 1122px; margin-t= op: 0em; margin-right: 0em; margin-bottom: 0em; margin-left: 0em; "> To: <mpls at <a href=3D"http://ietf.org">ietf.org</a>> Cc: <rcallon at <a href=3D"http://juniper.net">juniper.net</a>>; <= draft-vkst-mpls-tp-te-mib at <a href=3D"http://tools.ietf.org">tools.ietf.o= rg</a>> Sent: Tuesday, May 03, 2011 1:47 PM Subject: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt </pre></span><blockquote style=3D"border-left-color: rgb(85, 85, 238); bord= er-left-style: solid; border-left-width: 0.2em; margin-top: 0em; margin-rig= ht: 0em; margin-bottom: 0em; margin-left: 0em; padding-left: 0.85em; font-f= amily: 'Times New Roman'; font-size: medium; "> <pre style=3D"white-space: pre-wrap; word-wrap: break-word; width: 1107px; = margin-top: 0em; margin-right: 0em; margin-bottom: 0em; margin-left: 0em; "= >Working Group, this is to start a two week poll on making draft-vkst-mpls-tp-te-mib-00.txt 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 2011-05-18. /Loa _______________________________________________ mpls mailing list mpls at <a href=3D"http://ietf.org">ietf.org</a> </pre><tt><a rel=3D"nofollow" href=3D"https://www.ietf.org/mailman/listinfo= /mpls">https://www.ietf.org/mailman/listinfo/mpls</a></tt></blockquote></di= v> --20cf307f3188b3e9c504a2dc6bf3-- From eric.gray@ericsson.com Mon May 9 13:19:12 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 A1B2DE0856 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 RaLCuzs-8c+P for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 13:19:11 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 342E5E0771 for <mpls@ietf.org>; Mon, 9 May 2011 13:19:10 -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 p49I3Z3k027022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mpls@ietf.org>; Mon, 9 May 2011 13:03:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 May 2011 14:03:34 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Date: Mon, 9 May 2011 14:03:32 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwEkFBXYbQnS5CrT4ylyW0UNm7Y0wBUJvjwAB/KQCAAnnNMsAFmEkpw Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B074A71A6@EUSAACMS0701.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 Subject: [mpls] FW: 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: Mon, 09 May 2011 20:19:12 -0000 Forwarding in plain text... ________________________________ From: Eric Gray=20 Sent: Monday, May 02, 2011 11:56 AM To: 'Manuel.Paul@telekom.de'; Malcolm.BETTS@zte.com.cn; swallow@cisco.com Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Manuel, =20 There's at least two polar models for new equipment deployment in this = case: =20 1) folks who have both IP/MPLS equipment and transport service equipment wh= o view their existing deployment as consisting mostly of IP/MPLS and are = looking=20 to buy new equipment (or add features to existing equipment) to allow t= hem to=20 phase out aging transport equipment in favor of an all IP/MPLS network. 2) folks who have a network that they view as being dominated by transport = and who want to buy IP equipment to (gradually?) replace this equipment and inc= rease the compatibility of their network with what they see as a growing demand f= or IP and MPLS. =20 It's tempting to add a third deployment model for the folks who have acquir= ed pre- standard equipment and want all standards to be compatible with this equipm= ent. However, we've been assured that there will not be an interworking requirem= ent to support deployment of standards-based equipment and pre-standard deployment - so this case seems to be irrelevant. =20 In the first deployment model, we replace the transport equipment and m= ove=20 transport applications over to MPLS-TP. Since transport equipment is being= end- of-lifed in any case, the capital investment we want to protect is the exis= ting IP and MPLS deployment. =20 In the second deployment model, we seem to want to protect the existing= network throughout the transformation process, by front-loading additional function= ality into the new equipment to be installed. While this facilitates the first phase of t= ransformation, it does so by adding features and capabilities that we can be pretty sure w= e will not need after the transformation is complete. =20 While I refer to these two scenarios as separate, they are in fact the = result of=20 network operators at different points in a transformation from packet based= services provided by a predominantly transport network to a predominantly packet net= work that provides support for a small minority of applications that require tra= nsport-like services. =20 Clearly the further a network operator is along in the process, the mor= e reluctant they will be to find additional complexity in new capital investment that i= s important only for a diminishingly small part of their network and will be obsolete i= n fairly short order. =20 Please see additional comments below... =20 -- Eric ________________________________ From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de]=20 Sent: Monday, May 02, 2011 9:46 AM To: Eric Gray; Malcolm.BETTS@zte.com.cn; swallow@cisco.com Cc: mpls@ietf.org Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Importance: High Dear All, Please see some comments inline marked with [MP]. Thanks, Manuel ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Gray Sent: Thursday, April 28, 2011 10:58 PM To: Malcolm.BETTS@zte.com.cn; George Swallow Cc: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, There is nothing about not mixing the two identifier formats that=20 prevents an operator from continuing to use ICC identifiers within=20 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. [MP:] Agree that this should be equally applicable to all sides of the stor= y, although backwards compatibility considerations (often stressed along th= e MPLS OAM extension debate) apply here too. Its among TP's primary targets= to fit for classicly operated transport networks, to save efforts and avoi= d disruptive (primarily operational) changes in this arena. Platforms aren= 't migrated with one single snip of the finger (sometimes more for operatio= nal rather than technical complexity). In a real world, may need to interco= nnect platforms in distinct phases of evolution. In case of need for handov= ers, an operator should have the flexibility to decide what device class is= easiest to be (evolutionary) touched and tuned, i.e. supporting mixed iden= tifiers. I admit this occurrence probably will not be as granular as the ge= neral requirement for End-to-End OAM interoperability in a multi-vendor tra= nsport network environment where the boundaries are drawn according to the = reach of optical transparency domains and/or network management feasibiliti= es. 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. [MP:] Is it really that difficult to handle when we focus on the data plane= perspective for now? As in current scope of the identifiers draft? EG> Focus on the data plane is an one way to look at this. Unfortunately it does not help us much since we have to figure out how this stuff is supposed to get into the data plane, and how a maintenance entity is supposed to be configured to recognize it once it arrives from the=20 data-plane. Simply looking at this as data-plane "stuff" would quickly get us in trouble with our colleagues that have to handle the related needs to get it there and recover it once it has arrived. 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=20 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. [MP:] Wouldn't it be sufficient to recognize either format to know what sem= antics do apply ( or do not apply ) to handle one, or the other, or boths f= ormats properly on a node? EG> It would be sufficient, but non-trivial to specify in a standard. It i= s=20 also not particularly trivial to implement. [MP:] What happens today when a node receives any format that it doesn't su= pport?=20 Would it result in a confusion / wrong comparison? EG> I don't think specifying that an unsupported format will be discarded (perhaps with an error report) - which is the way that unsupported=20 objects and formats are dealt with generally (as long as it's possible to detect this) - is what we want to do. IMHO solving inter-provider interface issues or automization in assignement= may be tackled subsequently, i.e. in a next step. 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=20 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=20 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,=20 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.=20 Are suggesting that the same operator might make different choices in diffe= rent=20 parts of the same network? [MP:] Looking at the reality where platforms aren't migrated with one singl= e snip of the finger (sometimes for operational rather than technical reaso= ns), it may indeed be of practical relevance. Want to say, even an intra-op= erator but inter-AS scenario may be thinkable.=20 EG> In the inter-AS case generally, the best form of identifier is a Global= =20 Identifier, simply because - by definition - you have a different AS fo= r the two (or more) portions of the 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.=20 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.=20 I believe you are correct in terms of what the requirements are. There is = nothing=20 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.=20 >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.=20 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.=20 Please see in-line below.=20 Regards,=20 Malcolm=20 George Swallow <swallow@cisco.com>=20 Sent by: mpls-bounces@ietf.org=20 25/04/2011 05:16 PM=20 To <mpls@ietf.org>=20 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. =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 iden= tifiers for the data plane changing to IP based identifiers would be a majo= r 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 chec= k that it matches the expected string=20 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.=20 [MB] This would be a major roadblock to the use of MPLS-TP in an inter pro= vider 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 m= essages), 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 id= entifiers.=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 From Internet-Drafts@ietf.org Mon May 9 14:15:01 2011 Return-Path: <Internet-Drafts@ietf.org> 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 DE3CBE067B; Mon, 9 May 2011 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 RFZqGwnSTpdT; Mon, 9 May 2011 14:15:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682CDE0682; Mon, 9 May 2011 14:15: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.53 Message-ID: <20110509211501.16530.90683.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 14:15:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mldp-recurs-fec-02.txt 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: Mon, 09 May 2011 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Using Multipoint LDP when the Backbone has no Route to the Root Author(s) : I. Wijnands, et al. Filename : draft-ietf-mpls-mldp-recurs-fec-02.txt Pages : 12 Date : 2011-05-09 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 that is known to the intermediate nodes and is on the path to the true root node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-recurs-fec-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-mldp-recurs-fec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09140118.I-D@ietf.org> --NextPart-- From venkatflex@gmail.com Mon May 9 14:29:51 2011 Return-Path: <venkatflex@gmail.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 6828AE0908 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.150, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA4mCZxkvj6a for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 14:29:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51820E090B for <mpls@ietf.org>; Mon, 9 May 2011 14:29:48 -0700 (PDT) Received: by vxg33 with SMTP id 33so539075vxg.31 for <mpls@ietf.org>; Mon, 09 May 2011 14:29:48 -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=IWaf+nFUmzxcTApbFPS+j2a+594lF3nlI+X392xeYZs=; b=DBUZ9Dv8ndda+KVx6D/i2mjjpMHpb5QTabB9yNXf8kTRdk1L/JU9/0GEay2LuXV9cI qhEag8PLph/c7vWjALdFc0s6ZgiU3O9ULAF0oHoPYIRcrRB1SNKf/g7PBpBFMXkobUSl EjuMNZr6Sb3tPmKfxBLAn0Gh4LLzW7C4Zm4/I= 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=b6SNz8o6rSKpfLZPtGp7bb+gFsawZnNplXyWpnftm6jFDOa+/n/WTbonwVBTMc/F4n D3RXw+G4RhIfDE5TyFh9ZXj28VpBySD9L4sZK1T+pgCwrcA2NywK+xl5kqpznZjt693D nioCVYoV7fkGnc3f41CyvMQs0W/MrU+K5dzn4= MIME-Version: 1.0 Received: by 10.52.96.234 with SMTP id dv10mr3685940vdb.19.1304976588233; Mon, 09 May 2011 14:29:48 -0700 (PDT) Received: by 10.52.109.9 with HTTP; Mon, 9 May 2011 14:29:48 -0700 (PDT) Date: Mon, 9 May 2011 17:29:48 -0400 Message-ID: <BANLkTikjNxxWKjhxdTqtJmt5KhzxWMbt8w@mail.gmail.com> From: venkatesan mahalingam <venkatflex@gmail.com> To: adrian@olddog.co.uk, loa@pi.nu, mpls <mpls@ietf.org> Content-Type: multipart/alternative; boundary=20cf307f3188fb5d2f04a2de8943 Cc: rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt 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: Mon, 09 May 2011 21:29:51 -0000 --20cf307f3188fb5d2f04a2de8943 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian and all, Please find the responses inlined with the tag <<TP-MIB-Authors>> Thanks, TP-MIB-Authors. ________________________________________ From: Adrian Farrel [adrian@olddog.co.uk] Sent: Saturday, May 07, 2011 3:40 AM To: loa@pi.nu; mpls@ietf.org Cc: swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt >[speaking as an individual WG participant] >I support the idea of constructing a MIB module for MPLS-TP LSPs and for other >elements of MPLS-TP, but I have significant reservations about adopting this >document in its current form. I recognise that once adopted, the WG will be able >to enforce changes in content, but I am concerned that this document does not >correctly reflect the relationship with other MIB modules, and that taking this >as a starting point will encourage us to go down the wrong path resulting in a >starting direction that will be hard to change. >I would be happy to see the authors spend a little more time on this and then >adopt it into the WG. >In overview my concerns are as follows: > mplsGlobalId, mplsIcc and mplsNodeId are node properties that will turn out > to > be equally applicable for PWs. They should appear in a MIB module dedicated > to > the LSR not just to the MPLS-TP LSPs. Given that these three objects and > mplsNodeConfigTable and mplsNodeIpMapTable are all related to MPLS-TP > identifiers, why not have a separate module for them all? <<TP-MIB-Authors>> We agree that mplsGlobalId, mplsIcc and mplsNodeId can be kept in a common mib module. mplsNodeConfigTable is created specifically to map the [Global-id_Node-id] and Icc-id into Local-Num. This Local-Num will be used as the tunnel source/destination identifier. This idea has been followed to retain the MPLS tunnel table for MPLS-TP TE extensions also. We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable for PWs. The reason is that we already have the 129 FEC PWs with variable length of SAII & TAII. And the SAII & TAII already includes the Global-Id and Node-Id (or ICC Id) Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibility in SAII & TAII can be used to configure Global-id/Node-id or ICC id. > A number of objects related to Global IDs and Node IDs appear to be of the > wrong > max value compared to draft-ietf-mpls-tp-identifiers. You could usefully > define > TCs for them and for the ICC ID. What will zero Global IDs and Node IDs > mean? <<TP-MIB-Authors>> Yes, the Max value of Global-Id and Node-id are wrong. Max value should be max of 4 bytes value. We will correct them. Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a seperate mib module. 1) A Global_ID of zero means that no Global_ID is present. 2) A Node_ID of zero is the default value that indicates the Node_ID is invalid. > I see the value of the ICC entries in mplsNodeConfigTable and the use of > mplsNodeIccMapTable to generate a unique index to use in defining entries in > the > various pre-existing tables. (But see my comment on the use of > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below). I do not see the value > of > the Global entries in mplsNodeConfigTable and the use of mplsNodeIpMapEntry > since you say in the preamble to mplsTunnelExtEntry that Source-Tunnel_Num > is > mapped with mplsTunnelIndex. Quite possibly there is descriptive text > missing. <<TP-MIB-Authors>> mplsNodeConfigTable is the configuration table that is used to configure Global-id/Node-id and/or ICC-id with the local map number. i.e. This table is used to configure the global-id/Node-id and/or ICC-id for the given local map number. The other two tables mplsNodeIpMapEntry and mplsNodeIccMapTable are just READ-ONLY tables. These read only tables are meant for users who want to view the reverse mapping of Global-id/Node-id or ICC-id to the LocalNum. > There seems to be some ambiguity about whether the objects in this document > refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to > sort > this out. <<TP-MIB-Authors>> This document is created to address the requirements of TE extensions for MPLS-TP and this will also be applicable for MPLS TE and hence the mib modules are named generically. Since we are augmenting the TE mib, we named it as TE extension. If many others prefer to name this as TP extension, we can change the names accordingly. > mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm guessing > you > actually want a sparse augmentation since in a "mixed" environment you will > not > want to have all these objects present but unused. So you need to change the > way > you define this. <<TP-MIB-Authors>> Yes, we actually meant sparse augmentation. This mplsTunnelExtEntry will have entries only when required. For example, this table will have entries for the MPLS-TP tunnels, but not for MPLS tunnels. Does it answer your question? Do you expect few more description to be added to this table? Also, do you foresee any issue of augmentation? Is it possible to explain the same? > In mplsTunnelExtTable you do not state what DstTunnelNum is mapped with. > This is > key and could completely break your augmentation unless you get it right! <<TP-MIB-Authors>> There are two ways to look at this problem. One way is to force the DstTunnelNum as key. Other way is NOT to force it as key. Let us take an example to demonstrate this. Let us say that we have a forward LSP with SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200. Option1: Force DstTunnelNum as key: If we mandate DstTunnelNum as key, then the following combination is theoretically valid. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300. Even though the LSP2 is theoretically valid, it is not correct to have same indices for the forward LSP. i.e Treating the LSP2 as separate independent LSP is not looking correct. Hence, the Option1 is dropped. Option2: Do not force DstTunnelNum as key: This is the option that we choose. i.e User can configure DstTunnelNum as read-write column, but it is not part of indices to mplsTunnelTable. If we try to include that as key, even the existing MPLS based mplsTunnelTable will have problems in interpretation. Also, we do not see a real need to force that as index/key. According to this option, the LSP1 is a valid combination. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_200 If user wants to use a different reverse LSP, they can modify the DstTunnel value as 300. But, it will still be called as LSP1. LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5, DstTunnel_300 (modified). If required, we can discuss with mpls-tp-identifiers authors to confirm whether this approach is fine. > For mplsTunnelExtEntry you have... > Source Global identifier/ICC and Destination > Global identifier/ICC are maintained in the > mplsNodeConfigTable and mplsNodeConfigLocalNum is used to > create an entry in mplsTunnelTable. > This is possibly too vague to be actually practical. <<TP-MIB-Authors>> We created a word document to explain the various options that were considered before taking this option. We will share the same with you. In principle, the idea is to reuse the mplsTunnelTable without disturbing its existing meaning for MPLS based tunnels. Even though we can think of alternate designs based on separate new table for MPLS_TP tunnels, we thought that reusing the existing table is a better option since MPLS_TP is just an extension of existing MPLS. You can go through our document and provide your comments. > How will mplsTunnelExtDestTnlIndex actually be used? > - What value will it have for unidirecitonal tunnels? > (Or for bidriectional associated tunnels where the reverse > direction is not present on this LSR) <<TP-MIB-Authors>> A zero value will be held by this (mplsTunnelExtDestTnlIndex) object when the unidirectional tunnel is desired. This object contains the source tunnel index value incase of co-routed bidirectional tunnel and for associated bidirectional tunnel this object contains the reverse direction tunnel index and reverse lsp index object will be added in the next version of this draft. > - Is this actually meant to be the object that gives us the > DstTunnelNum? If so, what has this to do with the reverse > direction? <<TP-MIB-Authors>> Yes, this helps to associate the forward/reverse direction tunnels for associated bi-directional tunnel. For co-routed bidirectional case, SrcTunnelNum = DstTunnelNum and SrcTunnelLspNum = DstTunnelLspNum, this is because we use same tunnel entry with two different XC entries for both forward and reverse direction LSPs. > It is completely unclear to me what mplsTunnelExtTnlApp is for! <<TP-MIB-Authors>> This object provides the information on whether the tunnel entry is MPLS tunnel or the MPLS-TP tunnel (tunnel application is either MPLS or MPLS-TP). > It certainly makes a nonsense of mplsTpTunnelsConfigured and > mplsTpTunnelsActive <<TP-MIB-Authors>> This is to keep the tunnel count for MPLS-TP specific tunnels which are configured as mplsTp in mplsTunnelExtTnlApp object. If the object is not going to be useful for users, this can be removed. >Cheers, >Adrian > -----Original Message----- > From: loa@pi.nu [mailto:loa@pi.nu] > Sent: 03 May 2011 18:48 > To: mpls@ietf.org > Cc: Adrian Farrel; swallow@cisco.com; rcallon@juniper.net; draft-vkst-mpls-tp- > te-mib@tools.ietf.org > Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt > > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa --20cf307f3188fb5d2f04a2de8943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Adrian and all,</div><div>Please find the responses inlined with th= e tag <<TP-MIB-Authors>></div><div><br></div><div>Thanks,</div>= <div>TP-MIB-Authors.</div><div>________________________________________</di= v> <div>From: Adrian Farrel [<a href=3D"mailto:adrian@olddog.co.uk">adrian@old= dog.co.uk</a>]</div><div>Sent: Saturday, May 07, 2011 3:40 AM</div><div>To:= <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a>; <a href=3D"mailto:mpls@ietf.or= g">mpls@ietf.org</a></div> <div>Cc: <a href=3D"mailto:swallow@cisco.com">swallow@cisco.com</a>; <a hre= f=3D"mailto:rcallon@juniper.net">rcallon@juniper.net</a>; <a href=3D"mailto= :draft-vkst-mpls-tp-te-mib@tools.ietf.org">draft-vkst-mpls-tp-te-mib@tools.= ietf.org</a></div> <div>Subject: RE: poll on draft-vkst-mpls-tp-te-mib-00.txt</div><div><br></= div><div>>[speaking as an individual WG participant]</div><div><br></div= ><div>>I support the idea of constructing a MIB module for MPLS-TP LSPs = and for other</div> <div>>elements of MPLS-TP, but I have significant reservations about ado= pting this</div><div>>document in its current form. I recognise that onc= e adopted, the WG will be able</div><div>>to enforce changes in content,= but I am concerned that this document does not</div> <div>>correctly reflect the relationship with other MIB modules, and tha= t taking this</div><div>>as a starting point will encourage us to go dow= n the wrong path resulting in a</div><div>>starting direction that will = be hard to change.</div> <div><br></div><div>>I would be happy to see the authors spend a little = more time on this and then</div><div>>adopt it into the WG.</div><div><b= r></div><div>>In overview my concerns are as follows:</div><div><br> </div><div>> mplsGlobalId, mplsIcc and mplsNodeId are node properties th= at will turn out</div><div>> to</div><div>> be equally applicable for= PWs. They should appear in a MIB module dedicated</div><div>> to</div> <div>> the LSR not just to the MPLS-TP LSPs. Given that these three obje= cts and</div><div>> mplsNodeConfigTable and mplsNodeIpMapTable are all r= elated to MPLS-TP</div><div>> identifiers, why not have a separate modul= e for them all?</div> <div><br></div><div>=A0</div><div><<TP-MIB-Authors>> We agree t= hat mplsGlobalId, mplsIcc and mplsNodeId can be kept in a common mib module= .</div><div>mplsNodeConfigTable is created specifically to map the [Global-= id_Node-id]</div> <div>and Icc-id into Local-Num. This Local-Num will be used as the tunnel s= ource/destination identifier.</div><div><br></div><div>This idea has been f= ollowed to retain the MPLS tunnel table for MPLS-TP TE extensions also.</di= v> <div>We think that mplsNodeConfigTable/mplsNodeIpMapTable is not applicable= for PWs.</div><div>The reason is that we already have the 129 FEC PWs with= variable length of SAII & TAII.</div><div>And the SAII & TAII alre= ady includes the Global-Id and Node-Id (or ICC Id)</div> <div>Since the MPLS-TP PWs are always FEC129 Type2 based PWs, the flexibili= ty in SAII & TAII=A0</div><div>can be used to configure Global-id/Node-= id or ICC id.</div><div>=A0</div><div><br></div><div>> A number of objec= ts related to Global IDs and Node IDs appear to be of the</div> <div>> wrong</div><div>> max value compared to draft-ietf-mpls-tp-ide= ntifiers. You could usefully</div><div>> define</div><div>> TCs for t= hem and for the ICC ID. =A0What will zero Global IDs and Node IDs</div><div= > > mean?</div><div>=A0</div><div><br></div><div><<TP-MIB-Authors>= ;> Yes, the Max value of Global-Id and Node-id are wrong. Max value shou= ld be max</div><div>of 4 bytes value. We will correct them.</div><div><br> </div><div>Yes, we can keep the TCs for Global-id/Node-id and ICC-id in a s= eperate mib</div><div>module.</div><div>1) A Global_ID of zero means that n= o Global_ID is present.</div><div>2) A Node_ID of zero is the default value= that indicates the Node_ID is</div> <div>invalid.</div><div><br></div><div><br></div><div>> I see the value = of the ICC entries in mplsNodeConfigTable and the use of</div><div>> mpl= sNodeIccMapTable to generate a unique index to use in defining entries in</= div> <div>> the</div><div>> various pre-existing tables. (But see my comme= nt on the use of</div><div>> mplsNodeConfigLocalNum in mplsTunnelExtEntr= y, below). I do not see the value</div><div>> of</div><div>> the Glob= al entries in mplsNodeConfigTable and the use of mplsNodeIpMapEntry</div> <div>> since you say in the preamble to mplsTunnelExtEntry that Source-T= unnel_Num</div><div>> is</div><div>> mapped with mplsTunnelIndex. Qui= te possibly there is descriptive text</div><div>> missing.</div><div> <br></div><div><<TP-MIB-Authors>>=A0mplsNodeConfigTable is the = configuration table that is used to configure Global-id/Node-id and/or ICC-= id with</div><div>the local map number. i.e. This table is used to configur= e the global-id/Node-id and/or ICC-id for the</div> <div>given local map number.</div><div>=A0</div><div>The other two tables m= plsNodeIpMapEntry and mplsNodeIccMapTable are just READ-ONLY tables.</div><= div>These read only tables are meant for users who want to view the reverse= mapping of Global-id/Node-id=A0</div> <div>or ICC-id to the LocalNum.</div><div>=A0</div><div>> There seems to= be some ambiguity about whether the objects in this document</div><div>>= ; refer to MPLS-TP or to extensions to MPLS-TE. it would be really nice to<= /div> <div>> sort</div><div>> this out.</div><div><br></div><div><<TP= -MIB-Authors>> This document is created to address the requirements o= f TE extensions</div><div>for MPLS-TP and this will also be applicable for = MPLS TE and hence the mib modules are</div> <div>named generically. Since we are augmenting the TE mib, we named it as = TE extension.</div><div>If many others prefer to name this as TP extension,= we can change the names accordingly.</div><div>=A0</div><div><br></div><di= v> > mplsTunnelExtEntry is defined as augmenting mplsTunnelEntry. I'm g= uessing</div><div>> you</div><div>> actually want a sparse augmentati= on since in a "mixed" environment you will</div><div>> not</di= v> <div>> want to have all these objects present but unused. So you need to= change the</div><div>> way</div><div>> you define this.</div><div><b= r></div><div><<TP-MIB-Authors>> Yes, we actually meant sparse a= ugmentation. This mplsTunnelExtEntry=A0</div> <div>will have entries only when required.</div><div>For example, this tabl= e will have entries for the MPLS-TP tunnels, but not for MPLS tunnels.</div= ><div>Does it answer your question?</div><div>Do you expect few more descri= ption to be added to this table?</div> <div>Also, do you foresee any issue of augmentation? Is it possible to expl= ain the same?</div><div><br></div><div>> In mplsTunnelExtTable you do no= t state what DstTunnelNum is mapped with.</div><div>> This is</div><div> > key and could completely break your augmentation unless you get it rig= ht!</div><div><br></div><div><<TP-MIB-Authors>> There are two w= ays to look at this problem. One way is to force the DstTunnelNum as key.= =A0</div> <div>Other way is NOT to force it as key. Let us take an example to demonst= rate this.</div><div>Let us say that we have a forward LSP with SrcTunnel_1= 00, Instance_1, Source_R1, Destination_R5, DstTunnel_200.</div><div>Option1= : Force DstTunnelNum as key:</div> <div>If we mandate DstTunnelNum as key, then the following combination is t= heoretically valid.</div><div>LSP1: SrcTunnel_100, Instance_1, Source_R1, D= estination_R5, DstTunnel_200</div><div>LSP2: SrcTunnel_100, Instance_1, Sou= rce_R1, Destination_R5, DstTunnel_300. Even though the LSP2 is theoreticall= y valid,</div> <div>it is not correct to have same indices for the forward LSP. i.e Treati= ng the LSP2 as separate=A0</div><div>independent LSP is not looking correct= . Hence, the Option1 is dropped.</div><div>=A0</div><div>Option2: Do not fo= rce DstTunnelNum as key:</div> <div>This is the option that we choose. i.e User can configure DstTunnelNum= as read-write column,=A0</div><div>but it is not part of indices to mplsTu= nnelTable. If we try to include that as key,</div><div>even the existing MP= LS based mplsTunnelTable will have problems in interpretation.=A0</div> <div>Also, we do not see a real need to force that as index/key. According = to this option, the LSP1 is a valid combination.</div><div>LSP1: SrcTunnel_= 100, Instance_1, Source_R1, Destination_R5, DstTunnel_200</div><div>If user= wants to use a different reverse LSP, they can modify the DstTunnel value = as 300.</div> <div>But, it will still be called as LSP1.</div><div>LSP1: SrcTunnel_100, I= nstance_1, Source_R1, Destination_R5, DstTunnel_300 (modified).</div><div>I= f required, we can discuss with mpls-tp-identifiers authors to confirm whet= her this approach is fine.</div> <div>=A0</div><div>=A0</div><div>> For mplsTunnelExtEntry you have...</d= iv><div>> =A0 =A0 =A0 =A0 =A0 =A0 Source Global identifier/ICC and Desti= nation</div><div>> =A0 =A0 =A0 =A0 =A0 =A0 Global identifier/ICC are mai= ntained in the</div><div> > =A0 =A0 =A0 =A0 =A0 =A0 mplsNodeConfigTable and mplsNodeConfigLocalNum= is used to</div><div>> =A0 =A0 =A0 =A0 =A0 =A0 create an entry in mplsT= unnelTable.</div><div>> This is possibly too vague to be actually practi= cal.</div><div><br></div> <div><<TP-MIB-Authors>> We created a word document to explain t= he various options that were considered</div><div>before taking this option= . We will share the same with you.=A0</div><div>In principle, the idea is t= o reuse the mplsTunnelTable without disturbing its existing meaning for MPL= S based tunnels.=A0</div> <div>Even though we can think of alternate designs based on separate new ta= ble for MPLS_TP tunnels,</div><div>we thought that reusing the existing tab= le is a better option since MPLS_TP is just an extension of existing MPLS.<= /div> <div>You can go through our document and provide your comments.</div><div>= =A0</div><div><br></div><div>> How will mplsTunnelExtDestTnlIndex actual= ly be used?</div><div>> - What value will it have for unidirecitonal tun= nels?</div> <div>> =A0 (Or for bidriectional associated tunnels where the reverse</d= iv><div>> =A0 =A0direction is not present on this LSR)</div><div><br></d= iv><div><<TP-MIB-Authors>> A zero value will be held by this (m= plsTunnelExtDestTnlIndex) object</div> <div>when the unidirectional tunnel is desired.</div><div>This object conta= ins the source tunnel index value incase of co-routed</div><div>bidirection= al tunnel and for associated bidirectional</div><div>tunnel this object con= tains the reverse direction tunnel index and</div> <div>reverse lsp index object will be added in the next version of this dra= ft.</div><div><br></div><div>=A0</div><div>> - Is this actually meant to= be the object that gives us the</div><div>> =A0 =A0DstTunnelNum? If so,= what has this to do with the reverse</div> <div>> =A0 =A0direction?</div><div><br></div><div><<TP-MIB-Authors= >> Yes, this helps to associate the forward/reverse direction tunnels= for</div><div>associated bi-directional tunnel.</div><div>For co-routed bi= directional case, SrcTunnelNum =3D DstTunnelNum and</div> <div>SrcTunnelLspNum =3D DstTunnelLspNum,</div><div>this is because we use = same tunnel entry with two different XC entries for</div><div>both forward = and reverse direction LSPs.</div><div><br></div><div>> It is completely = unclear to me what mplsTunnelExtTnlApp is for!</div> <div><br></div><div><<TP-MIB-Authors>> This object provides the= information on whether the tunnel entry is</div><div>MPLS tunnel or the MP= LS-TP tunnel (tunnel application is either MPLS</div><div>or MPLS-TP).</div= > <div>=A0</div><div><br></div><div>> It certainly makes a nonsense of mpl= sTpTunnelsConfigured and</div><div>> mplsTpTunnelsActive</div><div><br><= /div><div><<TP-MIB-Authors>> This is to keep the tunnel count f= or MPLS-TP specific tunnels which are</div> <div>configured as mplsTp in mplsTunnelExtTnlApp object. If the object is n= ot going</div><div>to be useful for users, this can be removed.</div><div><= br></div><div><br></div><div>>Cheers,</div><div>>Adrian</div><div> <br></div><div><br></div><div>> -----Original Message-----</div><div>>= ; From: <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a> [mailto:<a href=3D"mailt= o:loa@pi.nu">loa@pi.nu</a>]</div><div>> Sent: 03 May 2011 18:48</div><di= v> > To: <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a></div><div>> = Cc: Adrian Farrel; <a href=3D"mailto:swallow@cisco.com">swallow@cisco.com</= a>; <a href=3D"mailto:rcallon@juniper.net">rcallon@juniper.net</a>; draft-v= kst-mpls-tp-</div> <div>> <a href=3D"mailto:te-mib@tools.ietf.org">te-mib@tools.ietf.org</a= ></div><div>> Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt</div><di= v>></div><div>></div><div>> Working Group,</div><div>></div><di= v> > this is to start a two week poll on making</div><div>></div><div>&g= t; draft-vkst-mpls-tp-te-mib-00.txt</div><div>></div><div>> an mpls w= orking group document.</div><div>></div><div>> If you support the doc= ument becoming a working group document</div> <div>> please respond to this poll with "yes/support"</div><di= v>></div><div>> If you do not support the document becoming a working= group</div><div>> document please respond to this poll with "no/do= not support"</div> <div>> and at the same time give the technical reasons why you are</div>= <div>> not supporting the document.</div><div>></div><div>> If you= have technical comments or in any other way want to</div><div>> discuss= the document, please send these comments to the mpls</div> <div>> working group mailing list, but with another subject than what</d= iv><div>> is on this mail.</div><div>></div><div>> The poll ends 2= 011-05-18.</div><div>></div><div>> /Loa</div><div><br></div> --20cf307f3188fb5d2f04a2de8943-- From sriganeshkini@gmail.com Mon May 9 17:20:51 2011 Return-Path: <sriganeshkini@gmail.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 DC2EFE06B7 for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 17:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.286, 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 re5GzPC7AujQ for <mpls@ietfa.amsl.com>; Mon, 9 May 2011 17:20:51 -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 10726E065D for <mpls@ietf.org>; Mon, 9 May 2011 17:20:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so4347432qwc.31 for <mpls@ietf.org>; Mon, 09 May 2011 17:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=MQYdkq29htaJ0k189j/AJpcmYo5jG5eSAbcN+ethvc8=; b=VFyw2zgR68KQ/dUm5nf3cIKto68T56arvo/bhOhhMtAntv1Q/1M5kgLTdLi4Q0zXLj aP/PzDRbOsnM2JKljbesCLzj1KxNEsKK49RM9dnvSrlD8WCu2xWthvfxjIjLljkxlkPO bHg7JyohJlYwY5KWRYQACI7jod8KLUDACcL9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ShIyxnoWVmj7NqCFV5vImaYSSNyNnoeivnYQfRX0IIuKV5PQdGAC6fdeh3QJWffjAb M2ZrZYgr55wlGBSzg9EAbKx6s2CWA+ShSAp4pGSdQm4/6gTPR1K7WmVyqIsyE/OlOFJL v15ZeLx5LAX4c3x7UfCTcClBlfYluHumFmGFU= Received: by 10.229.67.221 with SMTP id s29mr5621070qci.210.1304986849876; Mon, 09 May 2011 17:20:49 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.74.210 with HTTP; Mon, 9 May 2011 17:20:19 -0700 (PDT) In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> From: Sriganesh Kini <sriganesh.kini@ericsson.com> Date: Mon, 9 May 2011 17:20:19 -0700 X-Google-Sender-Auth: q0kHEZ-aP_r3ddm4DekL6Fo6_UM Message-ID: <BANLkTimOMu3g20RJHB6LuBYpr79J7XyQ_w@mail.gmail.com> To: loa@pi.nu 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 <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: Tue, 10 May 2011 00:20:52 -0000 Yes/Support. On Tue, Apr 26, 2011 at 7:06 PM, <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 > -- - Sri From huubatwork@gmail.com Tue May 10 00:35:51 2011 Return-Path: <huubatwork@gmail.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 35CCEE069A for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 00:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 MVjlPDwSRyTC for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 00:35:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37C02E07B4 for <mpls@ietf.org>; Tue, 10 May 2011 00:35:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so4505484wwa.13 for <mpls@ietf.org>; Tue, 10 May 2011 00:35:48 -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=k2OOWr/ym8Y7G/iSsAt1gwoaWjrBPjRkkHi0ljtSve4=; b=jmSdJkCUgNVBoHgzgdOuezMEjkkhdD0WP53xrSZhn2EE7k4MiWPMH7XKC7tTNDdO0v WwytTvBr5L5WDsYhDrav/o5KSouZTpRDQ61tSJ9jVm4tIn9qrLthzIJ5w6ypE8WnBDeU W9huqgsJqAOPqGgHufXa4mv4q8ihZ13ptnReM= 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=gdB/XQB9UDc+WIfs23jXC3O6dC5P2mPXXwZmFaqSGiehyA08zFZ9zfdWByP2zP9Gnw olq8wYyVZAoYDNf2KRD1LhMInKVb6P6564UlL86xVaxiPgeWoRRWQFLjyUxjp+HpROWR 50r4FY+myyCHBk9PTrF/zdIgrnYmMsq0xebFc= Received: by 10.227.183.76 with SMTP id cf12mr8250215wbb.66.1305012948230; Tue, 10 May 2011 00:35:48 -0700 (PDT) Received: from McAsterix.local ([217.41.237.43]) by mx.google.com with ESMTPS id ca12sm4214246wbb.19.2011.05.10.00.35.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 00:35:46 -0700 (PDT) Message-ID: <4DC8EAD1.3090003@gmail.com> Date: Tue, 10 May 2011 09:35:45 +0200 From: Huub van Helvoort <huubatwork@gmail.com> 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: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> <4DC42F28.7030607@gmail.com> <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> In-Reply-To: <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 <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: Tue, 10 May 2011 07:35:51 -0000 Hello Adrian, You replied: > So, I may have understood the import of those figures (specifically > figure 3 in draft-palanivelan-bfd-v2-gr-11.txt) Just to avoid confusion I was refering to the figures in draft-tsb-mpls-tp-ach-ptn-00.txt and looking at the text below you may be refering to that draft too. > but I read that to mean that, in the case of mismatched OAM types, > one of the OAM types (in the figure, the PSN type is indicated) > would be run end-to-end, and the local OAM types would be used > within the networks according to what they supported. Indeed. > Now, noting very clearly that OAM types have nothing whatsoever to > do with MPLS-TP Identifiers, you seem to be suggesting that the > same approach holds. The OAM types are independent of the used identifiers. > That would mean that (to paraphrase Figure 3) network A might use > one form of identifier and network B might use another form of identifier, yes. > but the end-to-end identifiers would be of one form only. Indeed, and the identifier that is used end-to-end can be either form A or form B. The actual form has to be agreed between the operators of network A and B. > Have I misunderstood you? I don't think so. Regards, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub van Helvoort >> Sent: 06 May 2011 18:26 >> To: mpls@ietf.org >> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> Hej Loa, >> >> You wrote: >> >>> lots of interesting data and thoughts, however not addressing the >>> question I asked. >>> >>> Let us assume that an LSP go across several operators transport >>> networks, e.g. it starts from operator A, go across operator B, C and >>> D to end up at a different geographical loacation i operator A's >>> network again. >>> >>> Now how likely is operator C, would let operator A, whom he does not >>> really need to have a relationship with (masked by B and D) initiate >>> OAM actions that can cause MIPs in operator A's network take actions >>> that is totally unexpected and uncontrolled by C? >>> >>> Would appreciate input from operators! >> >> A similar scenario on the use of OAm is described in: >> http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt or >> shown in slides 9-12 of the presentation in the RTGA open meeting >> http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt >> >> These figures are taken from ITU-T contribution C-1124 >> which is signed by several operators. This contribution >> was supported by other operators as well. >> >> It is possible to use the same OAM (PTN or PSN) in >> all domains (A, B and C in figures 1 and 2). >> You can see that operator B *cannot* influence the OAM >> in domains A and C nor in the top layer end-to-end OAM. >> >> Regards, Huub. >> =============== >> >> >>> On 2011-05-04 08:45, Maarten vissers wrote: >>>> Loa, >>>> >>>> The connections in the "Transport Service" layers can be >>>> multi-operator connections. Examples are the SDH Transport Service >>>> layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, >>>> ..), ATM Transport Service layer connections (ATM VCs), OTN Transport >>>> Service layer connections (LO ODUs), Ethernet Transport Service layer >>>> connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport >>>> Service layer connections (MS-PW, Service-LSP). >>>> >>>> These Transport Service layer connections are monitored using >>>> pro-active OAM and on-demand OAM between the Service Provider MEG >>>> level MEP functions on the UNI-N ports and Service Provider MEG level >>>> MIP functions on the E-NNI/IrDI ports. In a multi-operator connection >>>> these Service Provider MEG level MEP functions on the UNI-N ports will >>>> be located in different operator domains. Also the Service Provider >>>> MEG level MIP functions on the E-NNI/IrDI ports will be located in >>>> different operator domains. If one operator deploys ICC and the other >>>> operator deploys Global-ID MPLS-TP identifiers, then you will have a >>>> mixed case. >>>> >>>> We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. >>>> If the answer is "no" then mixed identifier usage will not be a >>>> requirement. >>>> If the application for MPLS-TP is within an MEF Ethernet Services >>>> architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason >>>> is that in the MEF architecture the E-NNI/IrDI is defined as an >>>> Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. >>>> - MPLS-TP Transport Service layer may not be present at all in such >>>> MEF Ethernet Services architecture, only the MPLS-TP Transport Path >>>> layer could be used (to carry PW-labelled Ethernet Connections) and >>>> those MPLS-TP Transport Path connections terminate in the operator >>>> domain's edge node (i.e. single operator connections). >>>> - For the case a MPLS-TP Transport Service layer is used in an MEF >>>> Ethernet Services architecture the MPLS-TP Transport Service >>>> connections will be terminated in the operator domain's edge node >>>> (i.e. single operator connections). >>>> >>>> ------ >>>> >>>> MPLS-TP Transport Path layer connections (transport-LSPs) are >>>> connecting a PE with an adjacent PE (via zero or more P nodes). Those >>>> transport-LSPs do not cross an E-NNI/IrDI. >>>> >>>> There is however one exception... when a group of Transport Service >>>> layer connections has to be sent from one domain via a second domain >>>> to a third domain, this is typically done via a Transport Path layer >>>> connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. >>>> Domain treats this domain 1-3 transport path layer connection as a >>>> transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 >>>> may use different identifiers (ICC, Global-ID) and a mixed case is >>>> present. If domains 1 and 3 use the same identifier type, then domain >>>> 2 may be using a different identifier type in the MIPs on its >>>> E-NNI/IrDI ports. >>>> >>>> ------ >>>> >>>> MPLS-TP Section layer connections are connecting adjacent MPLS-TP >>>> nodes. In 99.9% of the cases those nodes are in one operator domain. >>>> For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different >>>> operator domains. If one operator deploys ICC and the other operator >>>> deploys Global-ID based MPLS-TP identifiers there is a mixed case. >>>> >>>> Regards, >>>> Maarten >>>> >>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>>>> Loa Andersson >>>>> Sent: 4 May 2011 08:00 >>>>> To: mpls@ietf.org; Malcolm.BETTS@zte.com.cn >>>>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>>> >>>>> Malcolm, >>>>> >>>>> are you saying that operators today allow OAM to control node (MIPs and >>>>> MEPs) on each others networks? >>>>> >>>>> Do we have an operator that can verify this? >>>>> >>>>> /Loa >>>>> >>>>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> I share your concerns and doubts about a multi carrier control plane. >>>>>> However, I think that it is essential that a transport network >>>>> supports >>>>>> multi carrier data plane interconnection with end to end OAM. In >>>>> today's >>>>>> transport network this interconnection is supported by SDH and OTN. >>>>> The >>>>>> objective for MPLS-TP is to allow for packet based interconnection as >>>>> well. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Malcolm >>>>>> >>>>>> >>>>>> >>>>>> *George Swallow<swallow@cisco.com>* >>>>>> Sent by: mpls-bounces@ietf.org >>>>>> >>>>>> 03/05/2011 11:09 AM >>>>>> >>>>>> >>>>>> To >>>>>> "Andrew G. Malis"<agmalis@gmail.com>,<neil.2.harrison@bt.com> >>>>>> cc >>>>>> mpls@ietf.org >>>>>> Subject >>>>>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Andy - >>>>>> >>>>>>> Such >>>>>>> an E-NNI definition does not yet exist for MPLS-TP (something else >>>>> to >>>>>>> put on the to-do list). This E-NNI would also include similar >>>>>>> identifier mapping/translation for MS-PWs, to answer an earlier >>>>>>> question from Erminio that I saw on the list. >>>>>> >>>>>> You are quite correct here! I think much of this debate surrounds a >>>>> problem >>>>>> that is yet to be solved. So there are arguments for pieces of a >>>>> solution >>>>>> without and overall architecture. >>>>>> >>>>>> Based on all that I am seeing my inclination is to NOT say that we >>>>> disallow >>>>>> mixed identifiers, but to say that they are for future study. >>>>>> >>>>>> ...George >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 5/3/11 8:38 AM, "Andrew G. Malis"<agmalis@gmail.com> wrote: >>>>>> >>>>>>> Neil, >>>>>>> >>>>>>> To your case 1, we're in complete agreement. We (VZ) don't see at >>>>>>> least a short-term need for peer-layer interworking, given where >>>>> we >>>>>>> intend to deploy MPLS-TP in our infrastructure (as an internal >>>>> server >>>>>>> layer in the transport core). If peer layer interworking ever >>>>> becomes >>>>>>> a necessity, then obviously we'll need a well-defined E-NNI which >>>>>>> would include LSP identifier mapping/translation at the boundary, >>>>> for >>>>>>> LSP provisioning (whether static or dynamic) and end-to-end OAM. >>>>> Such >>>>>>> an E-NNI definition does not yet exist for MPLS-TP (something else >>>>> to >>>>>>> put on the to-do list). This E-NNI would also include similar >>>>>>> identifier mapping/translation for MS-PWs, to answer an earlier >>>>>>> question from Erminio that I saw on the list. >>>>>>> >>>>>>> I also agree that both intra-layer and inter-layer mis- >>>>> connectivity >>>>>>> detection and amelioration are required, but I'm not convinced >>>>> that >>>>>>> the already defined mechanisms can't do that. Do you have some >>>>>>> specific analysis on the inter-layer case? >>>>>>> >>>>>>> Cheers, >>>>>>> Andy >>>>>>> >>>>>>> On Tue, May 3, 2011 at 3:36 AM,<neil.2.harrison@bt.com> wrote: >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> 2 points: >>>>>>>> >>>>>>>> 1 I agree with your view of only having a single addressing >>>>> scheme in a >>>>>>>> single layer network solely belonging to one party. Though you >>>>> may >>>>>> need to >>>>>>>> be rather careful if you also advocate that one can also have >>>>> peer layer >>>>>>>> interworking between different parties, ie E-NNIs (I believe this >>>>> is >>>>>>>> something you may support, eg old MPLSF case?). In such a peer >>>>>> interworking >>>>>>>> case it would seem one must allow different addressing schemes >>>>> (and >>>>>> indeed >>>>>>>> any other variations in DP/CP functional components) if they >>>>> exist >>>>>> in the >>>>>>>> standards. >>>>>>>> >>>>>>>> Of course, having an E-NNI and peer interworking between >>>>> different >>>>>> parties in >>>>>>>> any non-TOS layer network (not just MPLS) is not technically >>>>>> necessary (this >>>>>>>> is trivial to prove), and this provides a strong argument for >>>>> only >>>>>> having a >>>>>>>> single addressing scheme in a non-TOS layer network. >>>>>>>> >>>>>>>> >>>>>>>> 2 You should also be aware that in client/server interworking of >>>>> the >>>>>>>> co-ps mode using variable size traffic units, and therefore >>>>>> something rather >>>>>>>> important for MPLS-TP in the role of a transport network (I'll >>>>>> ignore issues >>>>>>>> of transparency here), there could be inter-layer misconnectivity >>>>>> (Aside=> >>>>>>>> This case cannot occur in the co-cs mode). To date, however, we >>>>> have >>>>>> only >>>>>>>> really considered intra-layer misconnectivity, ie between >>>>> different LSPs >>>>>>>> belonging to the same party (note this also includes all cases of >>>>>> nested LSP >>>>>>>> sublayer misconnectivity). >>>>>>>> >>>>>>>> In the case of inter-layer misconnectivity one may receive >>>>> traffic >>>>>> units and >>>>>>>> OAM messages from some other party's layer network. The OAM >>>>> messages may >>>>>>>> come from (i) networks using different OAM/addressing solutions >>>>> or (ii) >>>>>>>> networks using the same OAM/addressing solutions. In both cases >>>>>> there are >>>>>>>> different issues wrt inter-layer misconnectivity one has to deal >>>>>> with. I'm >>>>>>>> not aware that these cases have been considered yet. >>>>>>>> >>>>>>>> >>>>>>>> I'd like to hear your comments on both these points, but in >>>>>> particular the >>>>>>>> first one.....especially if you also support the notion of E-NNIs >>>>> in >>>>>> MPLS-TP, >>>>>>>> as there seems to a possible logical conflict here. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> regards, 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. >>>>>>>> British Telecommunications plc >>>>>>>> Registered office: 81 Newgate Street London EC1A 7AJ >>>>>>>> Registered in England no: 1800000 >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>> Behalf Of >>>>>>>>> Andrew G. Malis >>>>>>>>> Sent: 02 May 2011 20:48 >>>>>>>>> To: George Swallow >>>>>>>>> Cc: mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >>>>> Identifiers? >>>>>>>>> >>>>>>>>> George et al, >>>>>>>>> >>>>>>>>> Verizon does not have any requirement for mixed use of Global >>>>> IDs and >>>>>>>>> ICCs. We are fine with specifications that require both ends of >>>>> an LSP >>>>>>>>> to use one or the other. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>>>> <swallow@cisco.com> >>>>>>>>> wrote: >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> We are looking for input/consensus from the WG. >>>>>>>>>> >>>>>>>>>> George, Eric,& Matthew -- ***************************************************************** ๆˆ‘็ˆฑๅค–็‚นไธ€ไธƒไธ‰ไธ€ From michelg@upperside.fr Tue May 10 01:32:37 2011 Return-Path: <michelg@upperside.fr> 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 49D75E06D3 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 GYlp9Kl5gdVi for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 01:32:36 -0700 (PDT) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id 47160E0675 for <mpls@ietf.org>; Tue, 10 May 2011 01:32:35 -0700 (PDT) Received: from MichelGosseDel (AAubervilliers-752-1-10-235.w90-35.abo.wanadoo.fr [90.35.157.235]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id p4A8WWKB018673 for <mpls@ietf.org>; Tue, 10 May 2011 10:32:32 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" <michelg@upperside.fr> To: <mpls@ietf.org> Date: Tue, 10 May 2011 10:32:29 +0200 Message-ID: <002301cc0eec$cd10c200$67324600$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CC0EFD.909A2E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwO7K5Y0NhOn3mOREmkxwrm0j6WsA== Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.10.81217 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World 2012 - Call for proposals 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: Tue, 10 May 2011 08:32:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01CC0EFD.909A2E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 14th edition of the MPLS & Ethernet World Congress will take place in Marriott Paris Rive Gauche, next 7 to 10 February, 2012. The call for proposals is open until June 15 at: <http://www.upperside.fr/mplsworld2012/mplsworld2012cfp.html> http://www.upperside.fr/mplsworld2012/mplsworld2012cfp.html ------=_NextPart_000_0024_01CC0EFD.909A2E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif"; mso-fareast-language:EN-US;} @page WordSection1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DFR link=3Dblue = vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span = lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>The 14th = edition of the <strong><span = style=3D'font-family:"Arial","sans-serif";color:black'>MPLS & = Ethernet World Congress</span></strong> will take place in Marriott = Paris Rive Gauche,<strong><span = style=3D'font-family:"Arial","sans-serif";color:black'> next 7 to 10 = February, 2012</span></strong>. <o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>  <o= :p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>The call for = proposals is open until June 15 at:<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'> <o:p></o= :p></span></p><p class=3DMsoNormal><span = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'><a = href=3D"http://www.upperside.fr/mplsworld2012/mplsworld2012cfp.html"><spa= n = lang=3DEN-US>http://www.upperside.fr/mplsworld2012/mplsworld2012cfp.html<= /span></a></span><span lang=3DEN-US = style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p></o:p></s= pan></p><p class=3DMsoNormal><span lang=3DEN-US = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> = </o:p></span></p></div></body></html> ------=_NextPart_000_0024_01CC0EFD.909A2E40-- From loa@pi.nu Tue May 10 06:56:21 2011 Return-Path: <loa@pi.nu> 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 CBD7DE0684 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 06:56:21 -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 2YsgjIEw5kyB for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 06:56:21 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD4E0593 for <mpls@ietf.org>; Tue, 10 May 2011 06:56:20 -0700 (PDT) Received: from [10.154.12.139] (unknown [192.165.126.77]) (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 5E68E2A8001; Tue, 10 May 2011 15:49:29 +0200 (CEST) Message-ID: <4DC94269.1060300@pi.nu> Date: Tue, 10 May 2011 15:49:29 +0200 From: Loa Andersson <loa@pi.nu> 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 <rcallon@juniper.net>, draft-ietf-mpls-mldp-recurs-fec@tools.ietf.org Subject: [mpls] working group lst call on draft-ietf-mpls-mldp-recurs-fec-02.txt 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: Tue, 10 May 2011 13:56:21 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-mldp-recurs-fec-02.txt Please send your comments to the mpls@ietf.org mailing list. This working group last call ends on May 25th. /Loa for 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 loa@pi.nu Tue May 10 08:43:17 2011 Return-Path: <loa@pi.nu> 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 A62F9E0740 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 08:43:17 -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 xjp8b3Gtrnmo for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 08:43:11 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id BB53DE0711 for <mpls@ietf.org>; Tue, 10 May 2011 08:43:10 -0700 (PDT) Received: from [109.58.191.124] (unknown [109.58.191.124]) (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 249232A8001; Tue, 10 May 2011 17:43:07 +0200 (CEST) Message-ID: <4DC95D08.7060305@pi.nu> Date: Tue, 10 May 2011 17:43:04 +0200 From: Loa Andersson <loa@pi.nu> 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" <mpls@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Tue, 10 May 2011 15:43:17 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-li-lb-01.txt Please send your comments to the mpls@ietf.org mailing list. This working group last call ends on May 25th. /Loa for 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 wwwrun@ietfa.amsl.com Tue May 10 09:07:20 2011 Return-Path: <wwwrun@ietfa.amsl.com> X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id A8F2FE0696; Tue, 10 May 2011 09:07:20 -0700 (PDT) From: Loa Andersson(IETF MPLS WG) <loa@pi.nu> To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110510160720.A8F2FE0696@ietfa.amsl.com> Date: Tue, 10 May 2011 09:07:20 -0700 (PDT) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, mpls-tp@ietf.org, loa.andersson@ericsson.com, yoichi.maeda@ttc.or.jp, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, elisa.bellagamba@ericsson.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "The IETF MPLS working group last call on "MPLS Transport Profile Lock Instruct and Loopback Functions" (ref #054.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: loa.andersson@ericsson.com 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: Tue, 10 May 2011 16:07:20 -0000 Title: The IETF MPLS working group last call on "MPLS Transport Profile Lock Instruct and Loopback Functions" (ref #054.01) Submission Date: 2011-05-10 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1050 From: Loa Andersson(IETF MPLS WG) <loa@pi.nu> To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@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 paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com rcallon@juniper.net Purpose: For information Body: The MPLS working group would like to inform you that we have started a working group last call on "MPLS Transport Profile Lock Instruct and Loopback Functions" (draft-ietf-mpls-tp-li-lb-01.txt). Please send your comemnts to the mpls@ietf.org mailing list before May 24, 2011. Loa Andersson George Swallow Ross Callon MPLS Working Group co-chairs Attachment(s): No document has been attached From stbryant@cisco.com Tue May 10 09:32:43 2011 Return-Path: <stbryant@cisco.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 9BCC9E082B for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 09:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.541 X-Spam-Level: X-Spam-Status: No, score=-109.541 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 qZbte3zc6KJ9 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 09:32:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF6E082A for <mpls@ietf.org>; Tue, 10 May 2011 09:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1129; q=dns/txt; s=iport; t=1305045162; x=1306254762; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=32m2jPrapzE+PeUxic4xMM0s0KNfh9QNcL+vsLmdsXs=; b=Qs+9FmZKJ41jVMoLLJgS6RBgu4rHs75LQAa2008JO485VnodA92K2nZN HVw+oo3qzRvBUPRZd3mB8cw4vm7/4up+eo4FAA9WulBg7D4WAGRN/84O1 62LRe/PZmni5VxO0apUjWU40bsPnK7ay0E1r6UpTyOAIKc/RbEHIu9Wrd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAKtnyU2Q/khMgWdsb2JhbACmChQBARYmJah1gngPAZs9hg8Ej3COXw X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="87753551" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 16:32:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4AGWa4Z025168; Tue, 10 May 2011 16:32:41 GMT Received: from dhcp-gpk02-vlan300-64-103-65-19.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4AGWVU23084; Tue, 10 May 2011 17:32:32 +0100 (BST) Message-ID: <4DC9689F.1050208@cisco.com> Date: Tue, 10 May 2011 17:32:31 +0100 From: Stewart Bryant <stbryant@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Loa Andersson <loa@pi.nu> References: <4DC95D08.7060305@pi.nu> In-Reply-To: <4DC95D08.7060305@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG <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: Tue, 10 May 2011 16:32:43 -0000 However, to remove a MEP from Loopback mode, the sending MEP MUST set the TTL to the exact number of hops required to reach the MEP (if the TTL were set higher, the Loopback removal message would be looped back toward the sender). It is RECOMMENDED that the TTL be set to the exact number of hops required to reach the MEP. SB> Surely that MUST be a MUST not a RECOMMENDED, since any other SB> value would not work. SB> I am surprised that we don't have a timer that gets you out of SB> jail by removing the LB if you can't get an unloopback command SB> to the MEP/MIP SB> The data section should emphasis that everything on the LSP SB> including OAM gets looped back (you have this as a side remark SB> above but it warrants emphasizing. SB> Can you remind me what happens when protection switching SB> occurs? Does LB at a MEP continue on the protected path? If SB> so how does the new TTL get learned? SB> What is the state of the TTL learning work that we proposed SB> right at the start of the project? i.e. how do we know SB> the exact TTL to use? - Stewart From loa@pi.nu Tue May 10 09:51:23 2011 Return-Path: <loa@pi.nu> 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 A9E9DE079B; Tue, 10 May 2011 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.107 X-Spam-Level: X-Spam-Status: No, score=-100.107 tagged_above=-999 required=5 tests=[AWL=-2.492, BAYES_00=-2.599, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492, 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 Udj48h8PRqlA; Tue, 10 May 2011 09:51:22 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 621A9E0744; Tue, 10 May 2011 09:51:19 -0700 (PDT) Received: from [109.58.191.124] (unknown [109.58.191.124]) (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 817D62A8001; Tue, 10 May 2011 18:44:20 +0200 (CEST) Message-ID: <4DC96B62.5080403@pi.nu> Date: Tue, 10 May 2011 18:44:18 +0200 From: Loa Andersson <loa@pi.nu> 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: The IESG <iesg-secretary@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, George Swallow <swallow@cisco.com>, draft-ietf-mpls-ldp-p2mp@tools.ietf.org, "mpls@ietf.org" <mpls@ietf.org> Content-Type: multipart/mixed; boundary="------------090100050307070907090609" Subject: [mpls] Request for publication of draft-ietf-mpls-ldp-p2mp 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: Tue, 10 May 2011 16:51:23 -0000 This is a multi-part message in MIME format. --------------090100050307070907090609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG, the MPLS working group requests that the draft-ietf-mpls-ldp-p2mp-13 is published as an RFC on the standards track. The shepherd write-up is included. /Loa for the MPLS wg -- 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 --------------090100050307070907090609 Content-Type: text/plain; name="mLDP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mLDP.txt" The MPLS WG requests that: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths draft-ietf-mpls-ldp-p2mp-13 is published as an RFC on the standards track. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. We know of implementations both drafts. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? Yes the has had good review from key people. The document shepherd has no concerns about the quality of the review. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Supported by the working group. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The nits tool does report one nit (unused reference), suggest that we fix that together with the comments form the AD rev. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. But one informative is unused! > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There is a correctly documented IANA section in the draft, setting up three new registries and requesting code points from these as well as existing registries. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary This document specifies 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. LDP with these extensions are also referred to as Multipoint LDP (mLDP). Runing mLDP will result in estgablishing 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 several applications for P2MP/MP2MP LSPs, but these are outside the scope of this document. Working Group Summary The document has been reviewed by the MPLS working group. This document has also been reviewed by a Rtg Area Directorate revieweriand all comments have been resolved. Document Quality The document is well reviewed by the MPLS working group. --------------090100050307070907090609-- From sboutros@cisco.com Tue May 10 17:40:55 2011 Return-Path: <sboutros@cisco.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 82D24E06C0 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 17:40:55 -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 LiUJIo3q1GZN for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 17:40:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1DE0681 for <mpls@ietf.org>; Tue, 10 May 2011 17:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=1903; q=dns/txt; s=iport; t=1305074454; x=1306284054; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=6pg6qJJ0nyk35fvyU1dnfsZ6IW4cAmtHhbWGMT12TCo=; b=ZSbr226WbXSxJbQotNoS/EjlYxqV2n02h69W+dUyMVWoqb2v2/HZ5eWN gho0yINxKI0fWeh0wnxHj5rmEAbELVdPxJDLCjtxa/OUcSzF0ss9Kj+Gi H48koKketMhOE/9KlyONmAW3QS2EX/uUs9giwHVo4LOLJze6BAMXtlWGL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANbZyU2rRDoG/2dsb2JhbACHaJ4jd6lbniGGDwSGQo1cilE X-IronPort-AV: E=Sophos;i="4.64,349,1301875200"; d="scan'208";a="312837529" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 00:40:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4B0esjL004086; Wed, 11 May 2011 00:40:54 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 17:40:54 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.145.133]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 17:40:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 May 2011 17:40:16 -0700 To: stbryant@cisco.com, Loa Andersson <loa@pi.nu> From: Sami Boutros <sboutros@cisco.com> In-Reply-To: <4DC9689F.1050208@cisco.com> References: <4DC95D08.7060305@pi.nu> <4DC9689F.1050208@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <XFE-SJC-2316Ci6nx8d00000051@xfe-sjc-231.amer.cisco.com> X-OriginalArrivalTime: 11 May 2011 00:40:53.0599 (UTC) FILETIME=[155DBEF0:01CC0F74] Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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, 11 May 2011 00:40:55 -0000 At 09:32 AM 5/10/2011, Stewart Bryant wrote: >However, to remove a MEP from Loopback mode, the sending MEP MUST set > the TTL to the exact number of hops required to reach the MEP (if the > TTL were set higher, the Loopback removal message would be looped > back toward the sender). It is RECOMMENDED that the TTL be set to the > exact number of hops required to reach the MEP. > >SB> Surely that MUST be a MUST not a RECOMMENDED, since any other >SB> value would not work. Sami: Will update the text as follow and remove the last sentence. "However, to remove a MEP from Loopback mode, the sending MEP MUST set the TTL to the exact number of hops required to reach the MEP (if the TTL were set higher, the Loopback removal message would be looped back toward the sender). " >SB> I am surprised that we don't have a timer that gets you out of >SB> jail by removing the LB if you can't get an unloopback command >SB> to the MEP/MIP Sami: But for how long will that timer run? are you thinking to put in the request for how long you stay in loopback to the MEP/MIP? >SB> The data section should emphasis that everything on the LSP >SB> including OAM gets looped back (you have this as a side remark >SB> above but it warrants emphasizing. Sami: Will clarify that OAM packets not intercepted by TTL expiry will be looped back >SB> Can you remind me what happens when protection switching >SB> occurs? Does LB at a MEP continue on the protected path? If >SB> so how does the new TTL get learned? > >SB> What is the state of the TTL learning work that we proposed >SB> right at the start of the project? i.e. how do we know >SB> the exact TTL to use? > Sami: This proposal is no longer progressing, the exact TTL to use will be set by the operator before and after protection switching. Thanks, Sami >- Stewart > From liu.guoman@zte.com.cn Tue May 10 19:55:01 2011 Return-Path: <liu.guoman@zte.com.cn> 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 1E895E070C for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 19:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.752 X-Spam-Level: X-Spam-Status: No, score=-94.752 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.001, 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 TCCyPP4+fC5A for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 19:55:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB7E06E6 for <mpls@ietf.org>; Tue, 10 May 2011 19:54:59 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 1834806486374; Wed, 11 May 2011 10:50:03 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 88213.806486374; Wed, 11 May 2011 10:54:47 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p4B2sh07040602 for <mpls@ietf.org>; Wed, 11 May 2011 10:54:43 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4B2BsTM088430; Wed, 11 May 2011 10:11:54 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201105110254.p4B2sh07040602@mse02.zte.com.cn> In-Reply-To: <4DC95D08.7060305@pi.nu> To: Loa Andersson <loa@pi.nu> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Wed, 11 May 2011 10:11:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-11 10:11:56, Serialize complete at 2011-05-11 10:11:56 Content-Type: multipart/alternative; boundary="=_alternative 000C244B4825788D_=" X-MAIL: mse02.zte.com.cn p4B2sh07040602 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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, 11 May 2011 02:55:01 -0000 This is a multipart message in MIME format. --=_alternative 000C244B4825788D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksIGFsbA0KZm9yIHRoaXMgZHJhZnQsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBMb29wYmFjayBm dW5jdGlvbi4NCmluIGxhc3QgaWV0ZiBtZWV0aW5nLCBJTU8sIHRoZSBhdXRob3Igc2FtaSBzYWlk IHRoaXMgDQpMb29wYmFjayBmdW5jdGlvbiBpcyB0byBsb29wYmFjayBhbnl0aGluZy4gZm9yIE1F UCBwb2ludCBvZiANCmEgTFNQLCBpZiBpdCBpcyBzZXQgdG8gTG9vcGJhY2sgc3RhdGUsIGl0IHdp bGwgbG9vcGJhY2sgYWxsIHJlY2VpdmVkDQpwYWNrZXRzIGluY2x1ZGluZyBhbnkgT0FNIHBhY2tl dC4gaWYgc28sIGhvdyB0byBkZXRlY3QgbWlzLWNvbm5lY3Rpdml0eSBvcg0KbWlzLWNvbmZpZ3Vy YXRpb24gZm9yIHRoZSBMU1A/DQppbiBhZGR0aW9uLCBpZiBpdCBoYXBwZW4gbWlzLWNvbm5lY3Rp dml0eSwgbWF5YmUgb3RoZXIgTFNQIHBhY2tldCBiZSANCnRyYW5zcG9ydGVkIHRvIA0KdGhlIE1F UCAsIGFuZCB0aGUgbWVwIHBvaW50IHdpbGwgc3RpbGwgTG9vcGJhY2sgdGhlIHdyb25nIHBhY2tl dCB0byBwZWVyIA0KbWVwIHBvaW50LA0KY2FuIGl0IGFmZmVjdCBwZXJmb3JtYW5jZSBzdGF0aXN0 aWNzIG9yIG1lYXN1cmVtZW50IG9uIHRoZSBwZWVyIG1lcCBwb2ludD8NCg0KQi5SLg0KbGl1DQoN Cg0KDQoNCg0KDQoNCg0KDQpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IA0Kt6K8/sjLOiAgbXBs cy1ib3VuY2VzQGlldGYub3JnDQoyMDExLTA1LTEwIDIzOjQzDQoNCsrVvP7Iyw0KIm1wbHNAaWV0 Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0KUm9zcyBDYWxsb24gPHJjYWxsb25AanVuaXBl ci5uZXQ+LCBNUExTLVRQIGFkIGhvYyB0ZWFtIA0KPGFobXBscy10cEBsaXN0cy5pdHUuaW50Piwg ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRvb2xzLmlldGYub3JnDQrW98ziDQpbbXBsc10gd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiLTAxLnR4dA0K DQoNCg0KDQoNCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVr IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQoNCmRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0w MS50eHQNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBsc0BpZXRmLm9yZyBt YWlsaW5nIGxpc3QuDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBNYXkg MjV0aC4NCg0KL0xvYQ0KDQpmb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzDQoNCi0tIA0KDQoNCkxv YSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25A ZXJpY3Nzb24uY29tDQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAg ICBsb2FAcGkubnUNCkVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6 ICs0NiAxMCA3MTcgNTIgMTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000C244B4825788D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLCBhbGw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvciB0aGlzIGRyYWZ0LCBJIGhhdmUgYSBx dWVzdGlvbiBmb3INCkxvb3BiYWNrIGZ1bmN0aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+aW4gbGFzdCBpZXRmIG1lZXRpbmcsIElNTywgdGhlIGF1dGhvcg0K c2FtaSBzYWlkIHRoaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Mb29wYmFjayBmdW5jdGlvbiBpcyB0byBsb29wYmFjayBhbnl0aGluZy4NCmZvciBNRVAgcG9p bnQgb2YgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hIExTUCwg aWYgaXQgaXMgc2V0IHRvIExvb3BiYWNrIHN0YXRlLA0KaXQgd2lsbCBsb29wYmFjayBhbGwgcmVj ZWl2ZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnBhY2tldHMg aW5jbHVkaW5nIGFueSBPQU0gcGFja2V0LiBpZg0Kc28sIGhvdyB0byBkZXRlY3QgbWlzLWNvbm5l Y3Rpdml0eSBvcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bWlz LWNvbmZpZ3VyYXRpb24gZm9yIHRoZSBMU1A/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5pbiBhZGR0aW9uLCBpZiBpdCBoYXBwZW4gbWlzLWNvbm5lY3Rpdml0eSwN Cm1heWJlIG90aGVyIExTUCBwYWNrZXQgYmUgdHJhbnNwb3J0ZWQgdG8gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUgTUVQICwgYW5kIHRoZSBtZXAgcG9pbnQg d2lsbCBzdGlsbA0KTG9vcGJhY2sgdGhlIHdyb25nIHBhY2tldCB0byBwZWVyIG1lcCBwb2ludCw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNhbiBpdCBhZmZlY3Q8 L2ZvbnQ+PGEgaHJlZj1hcHA6ZHM6cGVyZm9ybWFuY2UgdGFyZ2V0PV9zZWxmPjxmb250IHNpemU9 MT4NCnBlcmZvcm1hbmNlPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48YSBocmVmPWFwcDpkczpzdGF0aXN0aWNzIHRhcmdldD1fc2VsZj48Zm9udCBzaXpl PTE+c3RhdGlzdGljczwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPg0K b3IgbWVhc3VyZW1lbnQgb24gdGhlIHBlZXIgbWVwIHBvaW50PzwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Qi5SLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb2EgQW5k ZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA1LTEwIDIzOjQzPC9m b250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5Sb3NzIENhbGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDssDQpNUExTLVRQ IGFkIGhvYyB0ZWFtICZsdDthaG1wbHMtdHBAbGlzdHMuaXR1LmludCZndDssIGRyYWZ0LWlldGYt bXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHNdIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQ8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0 PldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLWxp LWxiLTAxLnR4dDxicj4NCjxicj4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1w bHNAaWV0Zi5vcmcgbWFpbGluZyBsaXN0Ljxicj4NCjxicj4NClRoaXMgd29ya2luZyBncm91cCBs YXN0IGNhbGwgZW5kcyBvbiBNYXkgMjV0aC48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KZm9y IHRoZSBtcGxzIHdnIGNvLWNoYWlyczxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxv YSBBbmRlcnNzb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiBsb2EuYW5kZXJz c29uQGVyaWNzc29uLmNvbTxicj4NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5udTxicj4NCkVy aWNzc29uIEluYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0NiAx MCA3MTcgNTIgMTM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7KzQ2IDc2NyA3MiA5MiAxMzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGll dGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJy Pg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJz cDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNw O2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJz cDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3Ro ZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5i c3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7 cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5i c3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7 YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVt Lg0KPC9wcmU+ --=_alternative 000C244B4825788D_=-- From huubatwork@gmail.com Tue May 10 23:52:38 2011 Return-Path: <huubatwork@gmail.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 9D998E0766 for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 23:52:38 -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 krL1A1bGeu6W for <mpls@ietfa.amsl.com>; Tue, 10 May 2011 23:52:37 -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 50FC4E066A for <mpls@ietf.org>; Tue, 10 May 2011 23:52:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so161623wyb.31 for <mpls@ietf.org>; Tue, 10 May 2011 23:52:35 -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=VTkmQwGq37UHB1a1EWCtbQFUUrw95ZLXCnI8aG+b4DM=; b=BOKjJ8E/hM1+y2/0GOU3p02QZQ4qMPYAUfB9KA4kpklZnrSBKAiqyls8wbDSLrf+jN Ng5Pu/15s+MayYir7MUddzRmAw7juGJzJZ/Rd61ZTvxRQKreK3govs838YNedaM8FGq6 51akpJRGr7sXOyc6MiLFzIpbsVsFdUzuEYUQg= 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=XFl442W6a2IbCQbSnlhzsF8PC78q/I5CH1EZYiyrsGI72tf1I2kmSvyEGDIz/4/pA9 BUmFceXVhEtP4bGSdQ+I+7vPWlHM9aZUBsg7khZBEg/9pQmYiRt3BqdfNW66nJzfNiD2 NUUiAoOEJ/0uk3Dm+jgak/JRB/6UiCTC1YnGg= Received: by 10.216.61.135 with SMTP id w7mr101134wec.19.1305096755367; Tue, 10 May 2011 23:52:35 -0700 (PDT) Received: from McAsterix.local ([217.41.232.34]) by mx.google.com with ESMTPS id z9sm4825776wbx.51.2011.05.10.23.52.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 23:52:34 -0700 (PDT) Message-ID: <4DCA322F.2040908@gmail.com> Date: Wed, 11 May 2011 08:52:31 +0200 From: Huub van Helvoort <huubatwork@gmail.com> 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: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> <4DC42F28.7030607@gmail.com> <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> <4DC8EAD1.3090003@gmail.com> In-Reply-To: <4DC8EAD1.3090003@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 <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, 11 May 2011 06:52:38 -0000 All, Please let me add some clarification: I wrote: >> That would mean that (to paraphrase Figure 3) network A might use > > one form of identifier and network B might use another form of > identifier, > > yes. > >> but the end-to-end identifiers would be of one form only. > > Indeed, and the identifier that is used end-to-end can be either > form A or form B. The actual form has to be agreed between the > operators of network A and B. This can mean that in the direction A --> B one form can be used (i.e. the form that operator A uses in his whole network) and that in direction B --> A of the same LSP/PW form B can be used (the form that operator B uses in his network). At the sink MEP the identifier has to be verified, the form can be independent of the form used in the network. Operators A and B inform each other about the "value" of the expected identifier. Regards, Huub. >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Huub van Helvoort >>> Sent: 06 May 2011 18:26 >>> To: mpls@ietf.org >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> >>> Hej Loa, >>> >>> You wrote: >>> >>>> lots of interesting data and thoughts, however not addressing the >>>> question I asked. >>>> >>>> Let us assume that an LSP go across several operators transport >>>> networks, e.g. it starts from operator A, go across operator B, C and >>>> D to end up at a different geographical loacation i operator A's >>>> network again. >>>> >>>> Now how likely is operator C, would let operator A, whom he does not >>>> really need to have a relationship with (masked by B and D) initiate >>>> OAM actions that can cause MIPs in operator A's network take actions >>>> that is totally unexpected and uncontrolled by C? >>>> >>>> Would appreciate input from operators! >>> >>> A similar scenario on the use of OAm is described in: >>> http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt or >>> shown in slides 9-12 of the presentation in the RTGA open meeting >>> http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt >>> >>> These figures are taken from ITU-T contribution C-1124 >>> which is signed by several operators. This contribution >>> was supported by other operators as well. >>> >>> It is possible to use the same OAM (PTN or PSN) in >>> all domains (A, B and C in figures 1 and 2). >>> You can see that operator B *cannot* influence the OAM >>> in domains A and C nor in the top layer end-to-end OAM. >>> >>> Regards, Huub. >>> =============== >>> >>> >>>> On 2011-05-04 08:45, Maarten vissers wrote: >>>>> Loa, >>>>> >>>>> The connections in the "Transport Service" layers can be >>>>> multi-operator connections. Examples are the SDH Transport Service >>>>> layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, >>>>> ..), ATM Transport Service layer connections (ATM VCs), OTN Transport >>>>> Service layer connections (LO ODUs), Ethernet Transport Service layer >>>>> connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport >>>>> Service layer connections (MS-PW, Service-LSP). >>>>> >>>>> These Transport Service layer connections are monitored using >>>>> pro-active OAM and on-demand OAM between the Service Provider MEG >>>>> level MEP functions on the UNI-N ports and Service Provider MEG level >>>>> MIP functions on the E-NNI/IrDI ports. In a multi-operator connection >>>>> these Service Provider MEG level MEP functions on the UNI-N ports will >>>>> be located in different operator domains. Also the Service Provider >>>>> MEG level MIP functions on the E-NNI/IrDI ports will be located in >>>>> different operator domains. If one operator deploys ICC and the other >>>>> operator deploys Global-ID MPLS-TP identifiers, then you will have a >>>>> mixed case. >>>>> >>>>> We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. >>>>> If the answer is "no" then mixed identifier usage will not be a >>>>> requirement. >>>>> If the application for MPLS-TP is within an MEF Ethernet Services >>>>> architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason >>>>> is that in the MEF architecture the E-NNI/IrDI is defined as an >>>>> Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. >>>>> - MPLS-TP Transport Service layer may not be present at all in such >>>>> MEF Ethernet Services architecture, only the MPLS-TP Transport Path >>>>> layer could be used (to carry PW-labelled Ethernet Connections) and >>>>> those MPLS-TP Transport Path connections terminate in the operator >>>>> domain's edge node (i.e. single operator connections). >>>>> - For the case a MPLS-TP Transport Service layer is used in an MEF >>>>> Ethernet Services architecture the MPLS-TP Transport Service >>>>> connections will be terminated in the operator domain's edge node >>>>> (i.e. single operator connections). >>>>> >>>>> ------ >>>>> >>>>> MPLS-TP Transport Path layer connections (transport-LSPs) are >>>>> connecting a PE with an adjacent PE (via zero or more P nodes). Those >>>>> transport-LSPs do not cross an E-NNI/IrDI. >>>>> >>>>> There is however one exception... when a group of Transport Service >>>>> layer connections has to be sent from one domain via a second domain >>>>> to a third domain, this is typically done via a Transport Path layer >>>>> connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. >>>>> Domain treats this domain 1-3 transport path layer connection as a >>>>> transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 >>>>> may use different identifiers (ICC, Global-ID) and a mixed case is >>>>> present. If domains 1 and 3 use the same identifier type, then domain >>>>> 2 may be using a different identifier type in the MIPs on its >>>>> E-NNI/IrDI ports. >>>>> >>>>> ------ >>>>> >>>>> MPLS-TP Section layer connections are connecting adjacent MPLS-TP >>>>> nodes. In 99.9% of the cases those nodes are in one operator domain. >>>>> For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different >>>>> operator domains. If one operator deploys ICC and the other operator >>>>> deploys Global-ID based MPLS-TP identifiers there is a mixed case. >>>>> >>>>> Regards, >>>>> Maarten -- ***************************************************************** ๆˆ‘็ˆฑๅค–็‚นไธ€ไธƒไธ‰ไธ€ From stbryant@cisco.com Wed May 11 04:04:21 2011 Return-Path: <stbryant@cisco.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 927F2E0720 for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 04:04:21 -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 usP9zVaRoS+q for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 04:04:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 965C2E069B for <mpls@ietf.org>; Wed, 11 May 2011 04:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2525; q=dns/txt; s=iport; t=1305111860; x=1306321460; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pvtw1qg9q10TmDt0FgGBrc3EsgCTfAf8AmSxY7w4BRs=; b=ZeLsfLtsFDn37mkf+cC84edLlz7rEoOUS9aWzdAw65qQPDk8rlT3aV61 vpaTOOrcWtcv4ceHaQpE3X0/W5omP4YppggqTgfgVQns8cicRORQ4Htb3 /sW3NHMwkXhIr9ySvMNdcrnsBMhYf5FEjmp5yRdKWbLvUYhOMFakpAIvM k=; X-IronPort-AV: E=Sophos;i="4.64,352,1301875200"; d="scan'208";a="87909114" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 11 May 2011 10:57:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4BAvCdh015579; Wed, 11 May 2011 10:57:12 GMT Received: from dhcp-gpk02-vlan300-64-103-65-125.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4BAv7U21927; Wed, 11 May 2011 11:57:10 +0100 (BST) Message-ID: <4DCA6B82.8010802@cisco.com> Date: Wed, 11 May 2011 11:57:06 +0100 From: Stewart Bryant <stbryant@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sami Boutros <sboutros@cisco.com> References: <4DC95D08.7060305@pi.nu> <4DC9689F.1050208@cisco.com> <XFE-SJC-2316Ci6nx8d00000051@xfe-sjc-231.amer.cisco.com> In-Reply-To: <XFE-SJC-2316Ci6nx8d00000051@xfe-sjc-231.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG <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, 11 May 2011 11:04:21 -0000 On 11/05/2011 01:40, Sami Boutros wrote: > At 09:32 AM 5/10/2011, Stewart Bryant wrote: >> However, to remove a MEP from Loopback mode, the sending MEP MUST set >> the TTL to the exact number of hops required to reach the MEP (if the >> TTL were set higher, the Loopback removal message would be looped >> back toward the sender). It is RECOMMENDED that the TTL be set to the >> exact number of hops required to reach the MEP. >> >> SB> Surely that MUST be a MUST not a RECOMMENDED, since any other >> SB> value would not work. > > Sami: Will update the text as follow and remove the last sentence. > "However, to remove a MEP from Loopback mode, the sending MEP MUST set > the TTL to the exact number of hops required to reach the MEP (if the > TTL were set higher, the Loopback removal message would be looped > back toward the sender). " > > >> SB> I am surprised that we don't have a timer that gets you out of >> SB> jail by removing the LB if you can't get an unloopback command >> SB> to the MEP/MIP > > Sami: But for how long will that timer run? are you thinking to put in > the request for how long you stay in loopback to the MEP/MIP? Yes, I was thinking of a 32bit timer (in say ms), refreshed before expiry (i.e. up to 100 days) The condition that you are guarding against is that the TTL number gets screwed up and you can't get an unloop delivered. Remember that there are situations where the LSP itself may be the only way to communicate at the control plane and by going into lookback you may have sawn off the branch you are sitting on. >> SB> The data section should emphasis that everything on the LSP >> SB> including OAM gets looped back (you have this as a side remark >> SB> above but it warrants emphasizing. > > Sami: Will clarify that OAM packets not intercepted by TTL expiry will > be looped back > >> SB> Can you remind me what happens when protection switching >> SB> occurs? Does LB at a MEP continue on the protected path? If >> SB> so how does the new TTL get learned? >> >> SB> What is the state of the TTL learning work that we proposed >> SB> right at the start of the project? i.e. how do we know >> SB> the exact TTL to use? >> > > Sami: This proposal is no longer progressing, the exact TTL to use > will be set by the operator before and after protection switching. Ah, but remember this all needs to work for MPLS and MPLS-TP, and with MPLS you may know TTL a priori. - Stewart From adrian@olddog.co.uk Wed May 11 10:57:08 2011 Return-Path: <adrian@olddog.co.uk> 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 20883E0887 for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 10:57: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 cNJPARRWrnSh for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 10:57:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 569F8E072B for <mpls@ietf.org>; Wed, 11 May 2011 10:57:07 -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 p4BHv3FE011574; Wed, 11 May 2011 18:57:03 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p4BHv25J011565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 18:57:02 +0100 From: "Adrian Farrel" <adrian@olddog.co.uk> To: <huubatwork@gmail.com>, <mpls@ietf.org> References: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> <4DC42F28.7030607@gmail.com> <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> <4DC8EAD1.3090003@gmail.com> In-Reply-To: <4DC8EAD1.3090003@gmail.com> Date: Wed, 11 May 2011 18:57:01 +0100 Message-ID: <023101cc1004$d4ed0b00$7ec72100$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQD8OgkbKBty65xHJvZJQlcBoLfQqwJVbvz1AjK0rskCAzrroQDHY/peAWbocSkBhghJVZXVlZYw 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: adrian@olddog.co.uk 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, 11 May 2011 17:57:08 -0000 Hi Huub, Converging your two emails... > > So, I may have understood the import of those figures (specifically > > figure 3 in draft-palanivelan-bfd-v2-gr-11.txt) >=20 > Just to avoid confusion I was refering to the figures in > draft-tsb-mpls-tp-ach-ptn-00.txt and looking at the text below > you may be refering to that draft too. Yeah! Sorry about that. Sloppy cut and paste. So many I-Ds and so little = time. > > but I read that to mean that, in the case of mismatched OAM types, > > one of the OAM types (in the figure, the PSN type is indicated) > > would be run end-to-end, and the local OAM types would be used > > within the networks according to what they supported. >=20 > Indeed. >=20 > > Now, noting very clearly that OAM types have nothing whatsoever to > > do with MPLS-TP Identifiers, you seem to be suggesting that the > > same approach holds. >=20 > The OAM types are independent of the used identifiers. >=20 > > That would mean that (to paraphrase Figure 3) network A might use > > one form of identifier and network B might use another form of > >identifier, >=20 > yes. >=20 > > but the end-to-end identifiers would be of one form only. >=20 > Indeed, and the identifier that is used end-to-end can be either > form A or form B. The actual form has to be agreed between the > operators of network A and B. | This can mean that in the direction A --> B one form can be used | (i.e. the form that operator A uses in his whole network) and | that in direction B --> A of the same LSP/PW form B can be used | (the form that operator B uses in his network). | At the sink MEP the identifier has to be verified, the form can | be independent of the form used in the network. Operators A and B | inform each other about the "value" of the expected identifier. I'm not clear about this. It is true that this *could* be done, but it also seems that it would be = a bit odd to mix and match like this for a bidirectional LSP. However, I = can see that for individual LSPs the behavior could be one of: - always be configured so "A runs over B" or - always depend on the initiating network or - one mechanism always runs over the other My interpretation of the OAM discussion was that "once the IETF OAM = mechanism was standardised, all edge nodes would need to support it" so = that we would have to have a case where the third option was the only = one available.=20 Now, regardless of all that, it seems that we have reached agreement = that, while the end points might need to support both identifier = formats, there would never be a case where mixed identifier formats were = used. Cheers, Adrian > > Have I misunderstood you? >=20 > I don't think so. From huubatwork@gmail.com Wed May 11 15:46:51 2011 Return-Path: <huubatwork@gmail.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 478D0E07F0 for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 15:46:51 -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 O8OA5nk3lH9I for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 15:46: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 78598E07D4 for <mpls@ietf.org>; Wed, 11 May 2011 15:46:50 -0700 (PDT) Received: by wyb29 with SMTP id 29so877315wyb.31 for <mpls@ietf.org>; Wed, 11 May 2011 15:46:49 -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=9YnUIR1uttQH1Xk8LaUj43fdJca4gmZQyY2C8U0TB60=; b=X+kJO+DEah7e+TRaczRVX2rqOADDQ3cuVOith8NkAyEp8UdrpZcPN9RlWrl0luEJAv 5PxBkEHr+j+nMu5DQg0zQpMEMNg/W3e0BWDYHXhsZYhRfQlcawgfSntmuPrg5k70JzCV isBNiJAT+3Ge0zxWodFszkABwjbwbcNbAj2PM= 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=bdTbg5bagmygnG+E8Q0j68QJ7dw/CQFbUEs1OCp2GqnyHMkPykCf4MjgBxSqrzZPCV 3YxXcUkoJAOTpSjfHmrVh4DayveKHW6B7BfJL8Qgq2oMVryLXXNHcCMgER/0eVHxYRKg vwovkg0iKLyk63BmhJ842VAy2fFrx7JYcYaWs= Received: by 10.216.27.67 with SMTP id d45mr2064060wea.21.1305154009618; Wed, 11 May 2011 15:46:49 -0700 (PDT) Received: from McAsterix.local ([217.41.237.178]) by mx.google.com with ESMTPS id c54sm324823wer.30.2011.05.11.15.46.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 15:46:48 -0700 (PDT) Message-ID: <4DCB11D7.9080002@gmail.com> Date: Thu, 12 May 2011 00:46:47 +0200 From: Huub van Helvoort <huubatwork@gmail.com> 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: <OF67E42AA7.6792F7C3-ON85257886.001F25E8-85257886.001F9684@zte.com.cn> <4DC0EB7A.4000606@pi.nu> <D62E6669B3621943B7632961308F8F9E0DC52C4A@LHREML503-MBX.china.huawei.com> <4DC41838.9@pi.nu> <4DC42F28.7030607@gmail.com> <0d1401cc0c31$22223620$6666a260$@olddog.co.uk> <4DC8EAD1.3090003@gmail.com> <023101cc1004$d4ed0b00$7ec72100$@olddog.co.uk> In-Reply-To: <023101cc1004$d4ed0b00$7ec72100$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed 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 <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, 11 May 2011 22:46:51 -0000 Hello Adrian, You replied: > Converging your two emails... > >>> but the end-to-end identifiers would be of one form only. >> >> Indeed, and the identifier that is used end-to-end can be either >> form A or form B. The actual form has to be agreed between the >> operators of network A and B. > > | This can mean that in the direction A --> B one form can be used > | (i.e. the form that operator A uses in his whole network) and > | that in direction B --> A of the same LSP/PW form B can be used > | (the form that operator B uses in his network). > | At the sink MEP the identifier has to be verified, the form can > | be independent of the form used in the network. Operators A and B > | inform each other about the "value" of the expected identifier. > > I'm not clear about this. OK, I will try to be more clear: > It is true that this *could* be done, but it also seems that it > would be a bit odd to mix and match like this for a bidirectional LSP. I did mean to write that this *MUST* be done. This will allow each operator to use his own identifier form for all MEPs and MIPs in the forward direction. The rrsponses from these MEPs and MIPs will contain the identifiers that he is used to, because in their responses they copy the received identifier. > However, I can see that for individual LSPs the behavior could be one of: > - always be configured so "A runs over B" > or > - always depend on the initiating network > or > - one mechanism always runs over the other What you describe can be valid for the OAM because in this case the forward and backward direction have to use the same mechanisms. > My interpretation of the OAM discussion was that "once the IETF OAM > mechanism was standardised, all edge nodes would need to support it" > so that we would have to have a case where the third option was the > only one available. As you write: this is OAM discussion. The identifier discussion is something else. > Now, regardless of all that, it seems that we have reached agreement > that, while the end points might need to support both identifier > formats, there would never be a case where mixed identifier formats > were used. Apparently we don't agree. I still have the opinion that mixed identifier formats *must* be supported as I described in my initial response. Best regards, Huub. From sboutros@cisco.com Wed May 11 22:03:22 2011 Return-Path: <sboutros@cisco.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 67B94E06AB for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 22:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 UyJiOG9bqb3j for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 22:03:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A7E06A7 for <mpls@ietf.org>; Wed, 11 May 2011 22:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=7693; q=dns/txt; s=iport; t=1305176601; x=1306386201; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=00XRigIDUpOGZl3CcmtVhjb6+gd88EATLWsANRtdAXg=; b=gDeIiffPy1w3FJqaj286EuogMjPK+6KDpb4wkwiR9zss32+hbjXTgn/I kkfkxN0KP3Yzgut9071RHL32NH3yy+dFZVgsMZEZGDW4YxSdh20sM8Gtq 6ZvgFTJgYI3RAqOKnQcbv0UMV12v+UaxaEQ/dw4cDljE1XawU20qS1VYS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG1py02rRDoG/2dsb2JhbACHaJ0lZHerPp40AoYRBIZFh2WFfIpW X-IronPort-AV: E=Sophos;i="4.64,357,1301875200"; d="scan'208,217";a="313833433" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 12 May 2011 05:03:20 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4C53KVY026617; Thu, 12 May 2011 05:03:20 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 22:03:20 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.145.133]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 22:03:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 May 2011 22:03:17 -0700 To: liu.guoman@zte.com.cn, Loa Andersson <loa@pi.nu> From: Sami Boutros <sboutros@cisco.com> In-Reply-To: <201105110254.p4B2sl0o040707@mse02.zte.com.cn> References: <4DC95D08.7060305@pi.nu> <201105110254.p4B2sl0o040707@mse02.zte.com.cn> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_140632906==.ALT" Message-ID: <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> X-OriginalArrivalTime: 12 May 2011 05:03:20.0157 (UTC) FILETIME=[E97590D0:01CC1061] Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Thu, 12 May 2011 05:03:22 -0000 --=====================_140632906==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable To check for mis-connectivity/mis-configuration,=20 you need a cc-cv function not a loopback function. The loopback function can be used for loss/delay=20 measurements, and this will be addressed in the delay/loss draft. Thanks, Sami At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote: >hi, all >for this draft, I have a question for Loopback function. >in last ietf meeting, IMO, the author sami said this >Loopback function is to loopback anything. for MEP point of >a LSP, if it is set to Loopback state, it will loopback all received >packets including any OAM packet. if so, how to detect mis-connectivity or >mis-configuration for the LSP? >in addtion, if it happen mis-connectivity, maybe=20 >other LSP packet be transported to >the MEP , and the mep point will still Loopback=20 >the wrong packet to peer mep point, >can it affect<app:ds:performance> performance=20 ><app:ds:statistics>statistics or measurement on the peer mep point? > >B.R. >liu > > > > > > >Loa Andersson <loa@pi.nu> >=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > >2011-05-10 23:43 >=CA=D5=BC=FE=C8=CB >"mpls@ietf.org" <mpls@ietf.org> >=B3=AD=CB=CD >Ross Callon <rcallon@juniper.net>, MPLS-TP ad=20 >hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org >=D6=F7=CC=E2 >[mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt > > > > >Working Group, > >this is to start a two week working group last call on > >draft-ietf-mpls-tp-li-lb-01.txt > >Please send your comments to the mpls@ietf.org mailing list. > >This working group last call ends on May 25th. > >/Loa > >for 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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > > > > >-------------------------------------------------------- >ZTE Information Security Notice: The information=20 >contained in this mail is solely property of the=20 >sender's organization. This mail communication=20 >is confidential. Recipients named above are=20 >obligated to maintain secrecy and are not=20 >permitted to disclose the contents of this communication to others. >This email and any files transmitted with it are=20 >confidential and intended solely for the use of=20 >the individual or entity to whom they are=20 >addressed. If you have received this email in=20 >error please notify the originator of the=20 >message. Any views expressed in this message are=20 >those of the individual sender. >This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=====================_140632906==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <body> To check for mis-connectivity/mis-configuration, you need a cc-cv function not a loopback function.<br><br> The loopback function can be used for loss/delay measurements, and this will be addressed in the delay/loss draft.<br><br> Thanks,<br><br> Sami<br> At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote:<br><br> <blockquote type=3Dcite class=3Dcite cite=3D""><font size=3D2>hi, all</font> <br> <font size=3D2>for this draft, I have a question for Loopback function.</font> <br> <font size=3D2>in last ietf meeting, IMO, the author sami said this </font><br> <font size=3D2>Loopback function is to loopback anything. for MEP point of </font><br> <font size=3D2>a LSP, if it is set to Loopback state, it will loopback all received</font> <br> <font size=3D2>packets including any OAM packet. if so, how to detect mis-connectivity or</font> <br> <font size=3D2>mis-configuration for the LSP?</font> <br> <font size=3D2>in addtion, if it happen mis-connectivity, maybe other LSP packet be transported to </font><br> <font size=3D2>the MEP , and the mep point will still Loopback the wrong packet to peer mep point,</font> <br> <font size=3D2>can it affect</font><a href=3D"app:ds:performance"><font size=3D1> performance</a></font><font size=3D2> </font><a href=3D"app:ds:statistics"><font size=3D1>statistics</a></font> <font size=3D2> or measurement on the peer mep point?</font> <br><br> <font size=3D2>B.R.</font> <br> <font size=3D2>liu</font> <br><br> <br><br> <br><br> <br> <font size=3D1><b>Loa Andersson <loa@pi.nu></b> </font><br> <font size=3D1>=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org</font>= <br><br> <font size=3D1>2011-05-10 23:43</font> <br> <div align=3D"right"><font size=3D1>=CA=D5=BC=FE=C8=CB<br> </div> "mpls@ietf.org" <mpls@ietf.org></font> <br> <div align=3D"right"><font size=3D1>=B3=AD=CB=CD<br> </div> Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org</font> <br> <div align=3D"right"><font size=3D1>=D6=F7=CC=E2<br> </div> [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt</font> <br><br> <br><br> <br> <tt>Working Group,<br><br> this is to start a two week working group last call on<br><br> draft-ietf-mpls-tp-li-lb-01.txt<br><br> Please send your comments to the mpls@ietf.org mailing list.<br><br> This working group last call ends on May 25th.<br><br> /Loa<br><br> for the mpls wg co-chairs<br><br> -- <br><br> <br> Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.com<br> Sr Strategy and Standards Manager            loa@pi.nu<br> Ericsson Inc            &= nbsp;            = ; phone: +46 10 717 52 13<br>             &nbs= p;            &n= bsp;            =        +46 767 72 92 13<br> _______________________________________________<br> mpls mailing list<br> mpls@ietf.org<br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" eudora=3D"autourl"> https://www.ietf.org/mailman/listinfo/mpls</a><br><br> </tt><br><br> <br> <pre> -------------------------------------------------------- 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. </pre><font face=3D"Courier New, Courier"></font></blockquote></body> <br> </html> --=====================_140632906==.ALT-- From yaacov.weingarten@nsn.com Wed May 11 22:36:49 2011 Return-Path: <yaacov.weingarten@nsn.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 C5C23E06A4 for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 22:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2nQl7A8TzsU for <mpls@ietfa.amsl.com>; Wed, 11 May 2011 22:36: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 3C2CCE0689 for <mpls@ietf.org>; Wed, 11 May 2011 22:36: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 p4C5ab1d010557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2011 07:36:37 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4C5ab4W006441; Thu, 12 May 2011 07:36:37 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 07:36:36 +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_01CC1066.8FAE0322" Date: Thu, 12 May 2011 07:36:33 +0200 Message-ID: <E4873516F3FC7547BCFE792C7D94039C326505@DEMUEXC013.nsn-intra.net> In-Reply-To: <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt Thread-Index: AcwQYfa87BTMKVNmRz27p04krea4mQAA4yVQ References: <4DC95D08.7060305@pi.nu><201105110254.p4B2sl0o040707@mse02.zte.com.cn> <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com> To: "ext Sami Boutros" <sboutros@cisco.com>, <liu.guoman@zte.com.cn>, "Loa Andersson" <loa@pi.nu> X-OriginalArrivalTime: 12 May 2011 05:36:36.0576 (UTC) FILETIME=[8F6AEE00:01CC1066] Cc: Ross Callon <rcallon@juniper.net>, mpls@ietf.org, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Thu, 12 May 2011 05:36:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1066.8FAE0322 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sami, hi =20 My understanding is that the question that was asked is how do you use = the cc-cv function to check for mis-connectivity if it is being = looped-back. =20 Truth be told that during the period of loopback you apparently cannot = check the e2e path for mis-connectivity, and the operator needs to take = this into consideration. But since the path is not transferring data = e2e (it is looping everything back) it is by definition not connected = e2e. =20 What is true is what Sami states this functionality should be used to = setup a loss/delay measurement on a segment of a path, and it should be = used only for limited periods. =20 Just my 2cents, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Sami Boutros Sent: Thursday, May 12, 2011 8:03 AM To: liu.guoman@zte.com.cn; Loa Andersson Cc: Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team; = draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on = draft-ietf-mpls-tp-li-lb-01.txt =20 To check for mis-connectivity/mis-configuration, you need a cc-cv = function not a loopback function. The loopback function can be used for loss/delay measurements, and this = will be addressed in the delay/loss draft. Thanks, Sami At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote: hi, all=20 for this draft, I have a question for Loopback function.=20 in last ietf meeting, IMO, the author sami said this=20 Loopback function is to loopback anything. for MEP point of=20 a LSP, if it is set to Loopback state, it will loopback all received=20 packets including any OAM packet. if so, how to detect mis-connectivity = or=20 mis-configuration for the LSP?=20 in addtion, if it happen mis-connectivity, maybe other LSP packet be = transported to=20 the MEP , and the mep point will still Loopback the wrong packet to peer = mep point,=20 can it affect performance <app:ds:performance> statistics = <app:ds:statistics> or measurement on the peer mep point?=20 B.R.=20 liu=20 Loa Andersson <loa@pi.nu>=20 =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org=20 2011-05-10 23:43=20 =CA=D5=BC=FE=C8=CB "mpls@ietf.org" <mpls@ietf.org>=20 =B3=AD=CB=CD Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team = <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org=20 =D6=F7=CC=E2 [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt=20 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-li-lb-01.txt Please send your comments to the mpls@ietf.org mailing list. This working group last call ends on May 25th. /Loa for the mpls wg co-chairs --=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 =20 -------------------------------------------------------- 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. =20 ------_=_NextPart_001_01CC1066.8FAE0322 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Microsoft Word = 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"Comic Sans MS"; panose-1:3 15 7 2 3 3 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} tt {mso-style-priority:99; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Consolas","serif";} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Comic Sans MS"; color:#365F91;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue = vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Comic Sans = MS";color:#365F91'>Sami, hi<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'>My understanding is that the question that was = asked is how do you use the cc-cv function to check for mis-connectivity = if it is being looped-back.<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'>Truth be told that during the period of loopback = you apparently cannot check the e2e path for mis-connectivity, and the = operator needs to take this into consideration.=A0 But since the path is = not transferring data e2e (it is looping everything back) it is by = definition not connected e2e.<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'>What is true is what Sami states this = functionality should be used to setup a loss/delay measurement on a = segment of a path, and it should be used only for limited = periods.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:10.0pt;font-family:"Comic Sans = MS";color:#365F91'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'>Just my 2cents,<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'>yaacov<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Comic = Sans MS";color:#365F91'><o:p> </o:p></span></p><div><div = style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm'><p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <b>On Behalf Of = </b>ext Sami Boutros<br><b>Sent:</b> Thursday, May 12, 2011 8:03 = AM<br><b>To:</b> liu.guoman@zte.com.cn; Loa Andersson<br><b>Cc:</b> Ross = Callon; mpls@ietf.org; MPLS-TP ad hoc team; = draft-ietf-mpls-tp-li-lb@tools.ietf.org<br><b>Subject:</b> Re: [mpls] = working group last call on = draft-ietf-mpls-tp-li-lb-01.txt<o:p></o:p></span></p></div></div><p = class=3DMsoNormal style=3D'margin-left:36.0pt'><o:p> </o:p></p><p = class=3DMsoNormal style=3D'margin-left:36.0pt'>To check for = mis-connectivity/mis-configuration, you need a cc-cv function not a = loopback function.<br><br>The loopback function can be used for = loss/delay measurements, and this will be addressed in the delay/loss = draft.<br><br>Thanks,<br><br>Sami<br>At 07:11 PM 5/10/2011, = liu.guoman@zte.com.cn wrote:<br><br><br><o:p></o:p></p><p = class=3DMsoNormal style=3D'margin-left:36.0pt'><span = style=3D'font-size:10.0pt'>hi, all</span> <br><span = style=3D'font-size:10.0pt'>for this draft, I have a question for = Loopback function.</span> <br><span style=3D'font-size:10.0pt'>in last = ietf meeting, IMO, the author sami said this </span><br><span = style=3D'font-size:10.0pt'>Loopback function is to loopback anything. = for MEP point of </span><br><span style=3D'font-size:10.0pt'>a LSP, if = it is set to Loopback state, it will loopback all received</span> = <br><span style=3D'font-size:10.0pt'>packets including any OAM packet. = if so, how to detect mis-connectivity or</span> <br><span = style=3D'font-size:10.0pt'>mis-configuration for the LSP?</span> = <br><span style=3D'font-size:10.0pt'>in addtion, if it happen = mis-connectivity, maybe other LSP packet be transported to = </span><br><span style=3D'font-size:10.0pt'>the MEP , and the mep point = will still Loopback the wrong packet to peer mep point,</span> <br><span = style=3D'font-size:10.0pt'>can it affect</span><a = href=3D"app:ds:performance"><span style=3D'font-size:7.5pt'> = performance</span></a><span style=3D'font-size:10.0pt'> </span><a = href=3D"app:ds:statistics"><span = style=3D'font-size:7.5pt'>statistics</span></a> <span = style=3D'font-size:10.0pt'>or measurement on the peer mep point?</span> = <br><br><span style=3D'font-size:10.0pt'>B.R.</span> <br><span = style=3D'font-size:10.0pt'>liu</span> = <br><br><br><br><br><br><br><b><span style=3D'font-size:7.5pt'>Loa = Andersson <loa@pi.nu></span></b><span style=3D'font-size:7.5pt'> = </span><br><span style=3D'font-size:7.5pt'>=B7=A2=BC=FE=C8=CB:  = mpls-bounces@ietf.org</span> <br><br><span = style=3D'font-size:7.5pt'>2011-05-10 23:43</span> <o:p></o:p></p><p = class=3DMsoNormal align=3Dright = style=3D'margin-left:36.0pt;text-align:right'><span = style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB<o:p></o:p></span></p><p = class=3DMsoNormal style=3D'margin-left:36.0pt'><span = style=3D'font-size:7.5pt'>"mpls@ietf.org" = <mpls@ietf.org></span> <o:p></o:p></p><p class=3DMsoNormal = align=3Dright style=3D'margin-left:36.0pt;text-align:right'><span = style=3D'font-size:7.5pt'>=B3=AD=CB=CD<o:p></o:p></span></p><p = class=3DMsoNormal style=3D'margin-left:36.0pt'><span = style=3D'font-size:7.5pt'>Ross Callon <rcallon@juniper.net>, = MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, = draft-ietf-mpls-tp-li-lb@tools.ietf.org</span> <o:p></o:p></p><p = class=3DMsoNormal align=3Dright = style=3D'margin-left:36.0pt;text-align:right'><span = style=3D'font-size:7.5pt'>=D6=F7=CC=E2<o:p></o:p></span></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;mar= gin-left:36.0pt'><span style=3D'font-size:7.5pt'>[mpls] working group = last call on draft-ietf-mpls-tp-li-lb-01.txt</span> = <br><br><br><br><br><tt><span style=3D'font-size:10.0pt'>Working = Group,</span></tt><span style=3D'font-size:10.0pt;font-family:"Courier = New"'><br><br><tt>this is to start a two week working group last call = on</tt><br><br><tt>draft-ietf-mpls-tp-li-lb-01.txt</tt><br><br><tt>Please= send your comments to the mpls@ietf.org mailing = list.</tt><br><br><tt>This working group last call ends on May = 25th.</tt><br><br><tt>/Loa</tt><br><br><tt>for the mpls wg = co-chairs</tt><br><br><tt>-- </tt><br><br><br><tt>Loa = Andersson          &nbs= p;            = ;  email: loa.andersson@ericsson.com</tt><br><tt>Sr Strategy and = Standards = Manager           = loa@pi.nu</tt><br><tt>Ericsson = Inc           &nbs= p;            = ;  phone: +46 10 717 52 = 13</tt><br><tt>         &nbs= p;            = ;            =            +46 767 72 = 92 = 13</tt><br><tt>_______________________________________________</tt><br><t= t>mpls mailing list</tt><br><tt>mpls@ietf.org</tt><br><tt><a = href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</a></tt><br><br></span><br><br><o:p></o:p></p><pre = style=3D'margin-left:36.0pt'><o:p> </o:p></pre><pre = style=3D'margin-left:36.0pt'>--------------------------------------------= ------------<o:p></o:p></pre><pre style=3D'margin-left:36.0pt'>ZTE = Information Security Notice: The information contained in this = mail<o:p></o:p></pre><pre style=3D'margin-left:36.0pt'>is solely = property of the sender's organization. This mail = communication<o:p></o:p></pre><pre style=3D'margin-left:36.0pt'>is = confidential. Recipients named above are obligated to maintain = secrecy<o:p></o:p></pre><pre style=3D'margin-left:36.0pt'>and are not = permitted to disclose the contents of this communication = to<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>others.<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>This email and any files transmitted with = it are confidential and<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>intended solely for the use of the = individual or entity to whom they are<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>addressed. If you have received this email = in error please notify the<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>originator of the message. Any views = expressed in this message are those<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>of the individual = sender.<o:p></o:p></pre><pre style=3D'margin-left:36.0pt'>This message = has been scanned for viruses and Spam by ZTE = Anti-Spam<o:p></o:p></pre><pre = style=3D'margin-left:36.0pt'>system.<o:p></o:p></pre><p = class=3DMsoNormal = style=3D'margin-left:36.0pt'><o:p> </o:p></p></div></body></html> ------_=_NextPart_001_01CC1066.8FAE0322-- From stbryant@cisco.com Thu May 12 01:01:43 2011 Return-Path: <stbryant@cisco.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 7F4BBE0745 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 01:01:43 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uEAf2xlsHRBO for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 01:01:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3737AE0723 for <mpls@ietf.org>; Thu, 12 May 2011 01:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=14249; q=dns/txt; s=iport; t=1305187298; x=1306396898; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=Wv3S0x2aBffupPRB6U6+s9exdO/iMeJKGqLT61Lw0Ss=; b=cvgcLRJIzTFRBcBoXw+jIC8XNBfZDZcCYFPGBfIlty90+USFZXt+6Gkg u2barioZOTE0c4gvmS48443hq0oMmdMkOcU41I7MuY71lAYeOYM1roMHS WpZuKvwk83y78GMwj83/H9mdBDw90+u3qS+GQ3+DItb5hwFceYKpqkfKI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUDAFiTy02Q/khNgWdsb2JhbAClcRQBARYmJatigngPAZsgAoMggnEEgiyLfoFMjmc X-IronPort-AV: E=Sophos;i="4.64,357,1301875200"; d="scan'208,217";a="88101190" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 12 May 2011 08:01:37 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4C81W3O010046 for <mpls@ietf.org>; Thu, 12 May 2011 08:01:37 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4C81VU09217; Thu, 12 May 2011 09:01:32 +0100 (BST) Message-ID: <4DCB93DB.3070900@cisco.com> Date: Thu, 12 May 2011 09:01:31 +0100 From: Stewart Bryant <stbryant@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: mpls@ietf.org References: <4DC95D08.7060305@pi.nu> <201105110254.p4B2sl0o040707@mse02.zte.com.cn> <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> In-Reply-To: <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> Content-Type: multipart/alternative; boundary="------------070604010607050506060809" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG <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: Thu, 12 May 2011 08:01:43 -0000 This is a multi-part message in MIME format. --------------070604010607050506060809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit What is the test that needs to be made and exactly when? Let's talk MEPs first. You could get a cc-cv pkt to the remote end by sending it with the right TTL, and you can receive any cc-cv pkt from the remote end by examining all received pkts. To do cc-cv during a LB any diagnostics you run in LB need to take that into account and that will complicate the diagnostics. I do not see how you could ever do it with MIPs. I would think that most users would be content to verify the LSP using traceroute/ping/cc-cv then to set LB and run the tests then clear LB and re-verify as above. The above procedure is an applications issue and not a protocol issue, and thus does not belong in this document. The only case that does not seem to be covered is a problem that occurs during the LB, but that is a low probability event, and since there is no user data being carried on the LSP under LB user service will not be disrupted. In the case of data in the LSP under LB leaking as a result of a problem, that is the responsibility of the other LSP to police. Note that by examining the data received during a LB text the initiator of the LB is able to verify that it is their data that is being looped back which is equivalent to running a cc-cv. Thus I do not think that there is any practical problem that needs to be addressed in the protocol. - Stewart On 12/05/2011 06:03, Sami Boutros wrote: > To check for mis-connectivity/mis-configuration, you need a cc-cv > function not a loopback function. > > The loopback function can be used for loss/delay measurements, and > this will be addressed in the delay/loss draft. > > Thanks, > > Sami > At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote: > >> hi, all >> for this draft, I have a question for Loopback function. >> in last ietf meeting, IMO, the author sami said this >> Loopback function is to loopback anything. for MEP point of >> a LSP, if it is set to Loopback state, it will loopback all received >> packets including any OAM packet. if so, how to detect >> mis-connectivity or >> mis-configuration for the LSP? >> in addtion, if it happen mis-connectivity, maybe other LSP packet be >> transported to >> the MEP , and the mep point will still Loopback the wrong packet to >> peer mep point, >> can it affectperformance <app:ds:performance>statistics >> <app:ds:statistics> or measurement on the peer mep point? >> >> B.R. >> liu >> >> >> >> >> >> >> *Loa Andersson <loa@pi.nu>* >> ทขผศห: mpls-bounces@ietf.org >> >> 2011-05-10 23:43 >> สีผศห >> "mpls@ietf.org" <mpls@ietf.org> >> ณญหอ >> Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team >> <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org >> ึ๗ฬโ >> [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt >> >> >> >> >> Working Group, >> >> this is to start a two week working group last call on >> >> draft-ietf-mpls-tp-li-lb-01.txt >> >> Please send your comments to the mpls@ietf.org mailing list. >> >> This working group last call ends on May 25th. >> >> /Loa >> >> for 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> >> -------------------------------------------------------- >> 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. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070604010607050506060809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> What is the test that needs to be made and exactly when?<br> <br> Let's talk MEPs first.<br> <br> You could get a cc-cv pkt to the remote end by sending it with the right TTL, and you can receive any cc-cv pkt from the remote end by examining all received pkts.<br> <br> To do cc-cv during a LB any diagnostics you run in LB need to take that into account and that will complicate the diagnostics.<br> <br> I do not see how you could ever do it with MIPs.<br> <br> I would think that most users would be content to verify the LSP using traceroute/ping/cc-cv then to set LB and run the tests then clear LB and re-verify as above.<br> <br> The above procedure is an applications issue and not a protocol issue, and thus does not belong in this document.<br> <br> The only case that does not seem to be covered is a problem that occurs during the LB, but that is a low probability event, and since there is no user data being carried  on the LSP under LB user service will not be disrupted. In the case of data in the LSP under LB leaking as a result of a problem, that is the responsibility of the other LSP to police.<br> <br> Note that by examining the data received during a LB text the initiator of the LB is able to verify that it is their data that is being looped back which is equivalent to running a cc-cv.<br> <br> Thus I do not think that there is any practical problem that needs to be addressed in the protocol.<br> <br> - Stewart<br> <br> <br> On 12/05/2011 06:03, Sami Boutros wrote: <blockquote cite="mid:XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com" type="cite"> To check for mis-connectivity/mis-configuration, you need a cc-cv function not a loopback function.<br> <br> The loopback function can be used for loss/delay measurements, and this will be addressed in the delay/loss draft.<br> <br> Thanks,<br> <br> Sami<br> At 07:11 PM 5/10/2011, <a class="moz-txt-link-abbreviated" href="mailto:liu.guoman@zte.com.cn">liu.guoman@zte.com.cn</a> wrote:<br> <br> <blockquote type="cite" class="cite" cite=""><font size="2">hi, all</font> <br> <font size="2">for this draft, I have a question for Loopback function.</font> <br> <font size="2">in last ietf meeting, IMO, the author sami said this </font><br> <font size="2">Loopback function is to loopback anything. for MEP point of </font><br> <font size="2">a LSP, if it is set to Loopback state, it will loopback all received</font> <br> <font size="2">packets including any OAM packet. if so, how to detect mis-connectivity or</font> <br> <font size="2">mis-configuration for the LSP?</font> <br> <font size="2">in addtion, if it happen mis-connectivity, maybe other LSP packet be transported to </font><br> <font size="2">the MEP , and the mep point will still Loopback the wrong packet to peer mep point,</font> <br> <font size="2">can it affect</font><a moz-do-not-send="true" href="app:ds:performance"><font size="1"> performance</font></a><font size="2"> </font><a moz-do-not-send="true" href="app:ds:statistics"><font size="1">statistics</font></a> <font size="2"> or measurement on the peer mep point?</font> <br> <br> <font size="2">B.R.</font> <br> <font size="2">liu</font> <br> <br> <br> <br> <br> <br> <br> <font size="1"><b>Loa Andersson <a class="moz-txt-link-rfc2396E" href="mailto:loa@pi.nu"><loa@pi.nu></a></b> </font><br> <font size="1">·¢¼þÈË:  <a class="moz-txt-link-abbreviated" href="mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org</a></font> <br> <br> <font size="1">2011-05-10 23:43</font> <br> <div align="right"><font size="1">ÊÕ¼þÈË<br> </font></div> <font size="1"><a class="moz-txt-link-rfc2396E" href="mailto:mpls@ietf.org">"mpls@ietf.org"</a> <a class="moz-txt-link-rfc2396E" href="mailto:mpls@ietf.org"><mpls@ietf.org></a></font> <br> <div align="right"><font size="1">³­ËÍ<br> </font></div> <font size="1">Ross Callon <a class="moz-txt-link-rfc2396E" href="mailto:rcallon@juniper.net"><rcallon@juniper.net></a>, MPLS-TP ad hoc team <a class="moz-txt-link-rfc2396E" href="mailto:ahmpls-tp@lists.itu.int"><ahmpls-tp@lists.itu.int></a>, <a class="moz-txt-link-abbreviated" href="mailto:draft-ietf-mpls-tp-li-lb@tools.ietf.org">draft-ietf-mpls-tp-li-lb@tools.ietf.org</a></font> <br> <div align="right"><font size="1">Ö÷Ìâ<br> </font></div> <font size="1">[mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt</font> <br> <br> <br> <br> <br> <tt>Working Group,<br> <br> this is to start a two week working group last call on<br> <br> draft-ietf-mpls-tp-li-lb-01.txt<br> <br> Please send your comments to the <a class="moz-txt-link-abbreviated" href="mailto:mpls@ietf.org">mpls@ietf.org</a> mailing list.<br> <br> This working group last call ends on May 25th.<br> <br> /Loa<br> <br> for the mpls wg co-chairs<br> <br> -- <br> <br> <br> Loa Andersson                         email: <a class="moz-txt-link-abbreviated" href="mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com</a><br> Sr Strategy and Standards Manager            <a class="moz-txt-link-abbreviated" href="mailto:loa@pi.nu">loa@pi.nu</a><br> Ericsson Inc                          phone: +46 10 717 52 13<br>                                              +46 767 72 92 13<br> _______________________________________________<br> mpls mailing list<br> <a class="moz-txt-link-abbreviated" href="mailto:mpls@ietf.org">mpls@ietf.org</a><br> <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/mpls" eudora="autourl"> https://www.ietf.org/mailman/listinfo/mpls</a><br> <br> </tt><br> <br> <br> <pre>-------------------------------------------------------- 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. </pre> </blockquote> <br> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ mpls mailing list <a class="moz-txt-link-abbreviated" href="mailto:mpls@ietf.org">mpls@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/mailman/listinfo/mpls</a> </pre> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- For corporate legal information go to: <a class="moz-txt-link-freetext" href="http://www.cisco.com/web/about/doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html</a> </pre> </body> </html> --------------070604010607050506060809-- From internet-drafts@ietf.org Thu May 12 03:24:37 2011 Return-Path: <internet-drafts@ietf.org> 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 231E5E071B; Thu, 12 May 2011 03:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 hYp7gVPBtM4A; Thu, 12 May 2011 03:24:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C24E06D0; Thu, 12 May 2011 03:24:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110512102432.16037.9314.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 03:24:32 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mp-ldp-reqs-07.txt 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: Thu, 12 May 2011 10:24:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Requirements for Point-To-Multipoint Extensions to the L= abel Distribution Protocol Author(s) : Jean-Louis Le Roux Thomas Morin Filename : draft-ietf-mpls-mp-ldp-reqs-07.txt Pages : 20 Date : 2011-05-12 This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-07.txt From iesg-secretary@ietf.org Thu May 12 04:36:34 2011 Return-Path: <iesg-secretary@ietf.org> 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 ECF97E0796; Thu, 12 May 2011 04:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 FkfDX+33siiA; Thu, 12 May 2011 04:36:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987FAE077A; Thu, 12 May 2011 04:36:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110512113630.20282.27552.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 04:36:30 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: <draft-ietf-mpls-mp-ldp-reqs-07.txt> (Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol) to Historic X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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: Thu, 12 May 2011 11:36:35 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol' <draft-ietf-mpls-mp-ldp-reqs-07.txt> as a Historic The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-mp-ldp-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-mp-ldp-reqs/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu May 12 05:42:50 2011 Return-Path: <internet-drafts@ietf.org> 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 4A324E0670; Thu, 12 May 2011 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 T+DqlStnPiu1; Thu, 12 May 2011 05:42:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C89E067A; Thu, 12 May 2011 05:42:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110512124245.6421.79966.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 05:42:45 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-iana-00.txt 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: Thu, 12 May 2011 12:42:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Label Distribution Protocol (LDP) Internet Assigned Numb= ers Authority (IANA) Considerations Update Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-iana-00.txt Pages : 5 Date : 2011-05-10 This document augments the Internet Assigned Numbers Authority (IANA) considerations for the Label Distribution Protocol (LDP), for protocol fields that are Reserved in the LDP Specification but for which there are no IANA allocation policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-iana-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-iana-00.txt From loa@pi.nu Thu May 12 06:56:37 2011 Return-Path: <loa@pi.nu> 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 1C67EE06E0 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 06:56:37 -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 oehvZ7coPZK8 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 06:56:33 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 00C34E0680 for <mpls@ietf.org>; Thu, 12 May 2011 06:56:32 -0700 (PDT) Received: from [10.154.12.139] (unknown [192.165.126.77]) (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 043E72A8001; Thu, 12 May 2011 15:56:30 +0200 (CEST) Message-ID: <4DCBE711.50700@pi.nu> Date: Thu, 12 May 2011 15:56:33 +0200 From: Loa Andersson <loa@pi.nu> 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 References: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> In-Reply-To: <75f7a5be945f01786d058ef17aae837d.squirrel@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rcallon@juniper.net, draft-leymann-mpls-seamless-mpls@tools.ietf.org Subject: [mpls] Poll concluded: 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: Thu, 12 May 2011 13:56:37 -0000 All, this poll has concluded and we have a new working group draft. Could the authors please follow normal procedures and publish a copy of the draft we did the poll on (with exception of dates and filename) as draft-ietf-mpls-seamless-mpls-00.txt. /Loa On 2011-04-27 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 -- 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 Thu May 12 06:59:25 2011 Return-Path: <loa@pi.nu> 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 944C8E06EC for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAesQyLV9gZ7 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 06:59:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id F38E8E06E0 for <mpls@ietf.org>; Thu, 12 May 2011 06:59:24 -0700 (PDT) Received: from [10.154.12.139] (unknown [192.165.126.77]) (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 CC4832A8001; Thu, 12 May 2011 15:59:23 +0200 (CEST) Message-ID: <4DCBE7BE.5010708@pi.nu> Date: Thu, 12 May 2011 15:59:26 +0200 From: Loa Andersson <loa@pi.nu> 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, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org, Ross Callon <rcallon@juniper.net>, George Swallow <swallow@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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: Thu, 12 May 2011 13:59:25 -0000 Working Group, this is to start a two week poll on making draft-raggarwa-mpls-seamless-mcast-03.txt 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 on May 27th. /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 sboutros@cisco.com Thu May 12 14:05:29 2011 Return-Path: <sboutros@cisco.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 C835BE07FF for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 14:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Fk30n8iGigB5 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 14:05:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C24FCE07FA for <mpls@ietf.org>; Thu, 12 May 2011 14:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=11130; q=dns/txt; s=iport; t=1305234328; x=1306443928; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=NZXaeG5XxgJQnX0gw1N3f2BLgO8tvf5sKckzf7aaK8U=; b=AwiuJCStOyluv01q041PjdxSTwEiQmf3mrzsJ4PKZ9S2BCkUUIXoOLJf Q5h7OzBMoINp3QdTSMdx67VZtNl1NjpB7GxZN7kWWaCflsNQold+v6J4k 0Thkkh9FkU3rUQ5vmNYlU/qrY9ydJXu+2YusIklBVzoJP3KO/OCLXPRs9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAHdKzE2tJXG8/2dsb2JhbACHaY9YjVRkd6pinicChhMEhkmHZoV9ilg X-IronPort-AV: E=Sophos;i="4.64,360,1301875200"; d="scan'208,217";a="314471840" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 12 May 2011 21:05:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4CL5QWk012952; Thu, 12 May 2011 21:05:27 GMT Received: from xfe-rcd-302.cisco.com ([72.163.63.13]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 16:05:26 -0500 Received: from sboutros-wxp02.ciswco.com ([10.82.250.64]) by xfe-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 16:05:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 May 2011 14:05:20 -0700 To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com>, <liu.guoman@zte.com.cn>, "Loa Andersson" <loa@pi.nu> From: Sami Boutros <sboutros@cisco.com> In-Reply-To: <E4873516F3FC7547BCFE792C7D94039C326505@DEMUEXC013.nsn-intr a.net> References: <4DC95D08.7060305@pi.nu> <201105110254.p4B2sl0o040707@mse02.zte.com.cn> <XFE-SJC-221l7dIj7j100000009@xfe-sjc-221.amer.cisco.com> <E4873516F3FC7547BCFE792C7D94039C326505@DEMUEXC013.nsn-intra.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6636640==.ALT" Message-ID: <XFE-RCD-302agj5BbHk0000001a@xfe-rcd-302.cisco.com> X-OriginalArrivalTime: 12 May 2011 21:05:26.0216 (UTC) FILETIME=[50DF2480:01CC10E8] Cc: Ross Callon <rcallon@juniper.net>, mpls@ietf.org, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Thu, 12 May 2011 21:05:29 -0000 --=====================_6636640==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Agreed Yaacov, during the period of loopback the=20 cc-cv function can't be performed, and yes the=20 main benefit is of loopback is to measure=20 loss/delay on a segment of a path as you stated. Thanks, Sami At 10:36 PM 5/11/2011, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: >Sami, hi > >My understanding is that the question that was=20 >asked is how do you use the cc-cv function to=20 >check for mis-connectivity if it is being looped-back. > >Truth be told that during the period of loopback=20 >you apparently cannot check the e2e path for=20 >mis-connectivity, and the operator needs to take=20 >this into consideration. But since the path is=20 >not transferring data e2e (it is looping=20 >everything back) it is by definition not connected e2e. > >What is true is what Sami states this=20 >functionality should be used to setup a=20 >loss/delay measurement on a segment of a path,=20 >and it should be used only for limited periods. > >Just my 2cents, >yaacov > >From: mpls-bounces@ietf.org=20 >[mailto:mpls-bounces@ietf.org] On Behalf Of ext Sami Boutros >Sent: Thursday, May 12, 2011 8:03 AM >To: liu.guoman@zte.com.cn; Loa Andersson >Cc: Ross Callon; mpls@ietf.org; MPLS-TP ad hoc=20 >team; draft-ietf-mpls-tp-li-lb@tools.ietf.org >Subject: Re: [mpls] working group last call on= draft-ietf-mpls-tp-li-lb-01.txt > >To check for mis-connectivity/mis-configuration,=20 >you need a cc-cv function not a loopback function. > >The loopback function can be used for loss/delay=20 >measurements, and this will be addressed in the delay/loss draft. > >Thanks, > >Sami >At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote: > > >hi, all >for this draft, I have a question for Loopback function. >in last ietf meeting, IMO, the author sami said this >Loopback function is to loopback anything. for MEP point of >a LSP, if it is set to Loopback state, it will loopback all received >packets including any OAM packet. if so, how to detect mis-connectivity or >mis-configuration for the LSP? >in addtion, if it happen mis-connectivity, maybe=20 >other LSP packet be transported to >the MEP , and the mep point will still Loopback=20 >the wrong packet to peer mep point, >can it affect<app:ds:performance> performance=20 ><app:ds:statistics>statistics or measurement on the peer mep point? > >B.R. >liu > > > > > > >Loa Andersson <loa@pi.nu> >=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > >2011-05-10 23:43 >=CA=D5=BC=FE=C8=CB >"mpls@ietf.org" <mpls@ietf.org> >=B3=AD=CB=CD >Ross Callon <rcallon@juniper.net>, MPLS-TP ad=20 >hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org >=D6=F7=CC=E2 >[mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt > > > > >Working Group, > >this is to start a two week working group last call on > >draft-ietf-mpls-tp-li-lb-01.txt > >Please send your comments to the mpls@ietf.org mailing list. > >This working group last call ends on May 25th. > >/Loa > >for 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 >_______________________________________________ >mpls mailing list >mpls@ietf.org ><https://www.ietf.org/mailman/listinfo/mpls>https://www.ietf.org/mailman/li= stinfo/mpls > > > > > > > >-------------------------------------------------------- > >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. --=====================_6636640==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <body> Agreed Yaacov, during the period of loopback the cc-cv function can't be performed, and yes the main benefit is of loopback is to measure loss/delay on a segment of a path as you stated.<br><br> Thanks,<br><br> Sami<br> At 10:36 PM 5/11/2011, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:<br> <blockquote type=3Dcite class=3Dcite cite=3D"">Sami, hi<br>  <br> My understanding is that the question that was asked is how do you use the cc-cv function to check for mis-connectivity if it is being looped-back.<br>  <br> Truth be told that during the period of loopback you apparently cannot check the e2e path for mis-connectivity, and the operator needs to take this into consideration.  But since the path is not transferring data e2e (it is looping everything back) it is by definition not connected e2e.<br>  <br> What is true is what Sami states this functionality should be used to setup a loss/delay measurement on a segment of a path, and it should be used only for limited periods.<br>  <br> Just my 2cents,<br> yaacov<br>  <br> <b>From:</b> mpls-bounces@ietf.org [<a href=3D"mailto:mpls-bounces@ietf.org" eudora=3D"autourl"> mailto:mpls-bounces@ietf.org</a>] <b>On Behalf Of </b>ext Sami Boutros<br> <b>Sent:</b> Thursday, May 12, 2011 8:03 AM<br> <b>To:</b> liu.guoman@zte.com.cn; Loa Andersson<br> <b>Cc:</b> Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-li-lb@tools.ietf.org<br> <b>Subject:</b> Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt<br>  <br> To check for mis-connectivity/mis-configuration, you need a cc-cv function not a loopback function.<br><br> The loopback function can be used for loss/delay measurements, and this will be addressed in the delay/loss draft.<br><br> Thanks,<br><br> Sami<br> At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote:<br><br> <br> hi, all <br> for this draft, I have a question for Loopback function. <br> in last ietf meeting, IMO, the author sami said this <br> Loopback function is to loopback anything. for MEP point of <br> a LSP, if it is set to Loopback state, it will loopback all received <br> packets including any OAM packet. if so, how to detect mis-connectivity or <br> mis-configuration for the LSP? <br> in addtion, if it happen mis-connectivity, maybe other LSP packet be transported to <br> the MEP , and the mep point will still Loopback the wrong packet to peer mep point, <br> can it affect<a href=3D"app:ds:performance"> performance</a> <a href=3D"app:ds:statistics">statistics</a> or measurement on the peer mep point? <br><br> B.R. <br> liu <br><br> <br><br> <br><br> <br> <b>Loa Andersson <loa@pi.nu></b> <br> =B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org <br><br> 2011-05-10 23:43 <br> <div align=3D"right">=CA=D5=BC=FE=C8=CB<br> </div> "mpls@ietf.org" <mpls@ietf.org> <br> <div align=3D"right">=B3=AD=CB=CD<br> </div> Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org <br> <div align=3D"right">=D6=F7=CC=E2<br> </div> [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt <br><br> <br><br> <br> <tt>Working Group,</tt><br><br> <tt>this is to start a two week working group last call on</tt><br><br> <tt>draft-ietf-mpls-tp-li-lb-01.txt</tt><br><br> <tt>Please send your comments to the mpls@ietf.org mailing list.</tt><br><br> <tt>This working group last call ends on May 25th.</tt><br><br> <tt>/Loa</tt><br><br> <tt>for the mpls wg co-chairs</tt><br><br> <tt>-- </tt><br><br> <br> <tt>Loa Andersson           &= nbsp;            = ; email: loa.andersson@ericsson.com</tt><br> <tt>Sr Strategy and Standards Manager            loa@pi.nu</tt><br> <tt>Ericsson Inc            &= nbsp;            = ; phone: +46 10 717 52 13</tt><br> <tt>             &nbs= p;            &n= bsp;            =        +46 767 72 92 13</tt><br> <tt>_______________________________________________</tt><br> <tt>mpls mailing list</tt><br> <tt>mpls@ietf.org</tt><br> <tt><a href=3D"https://www.ietf.org/mailman/listinfo/mpls"> https://www.ietf.org/mailman/listinfo/mpls</a></tt><br><br> <br><br> <br><br> <pre> </pre><font face=3D"Courier New, Courier"></font><br><br> <pre>--------------------------------------------------------</pre> <font face=3D"Courier New, Courier"></font><br><br> <pre>ZTE Information Security Notice: The information contained in this mail</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>is solely property of the sender's organization. This mail communication</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>is confidential. Recipients named above are obligated to maintain secrecy</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>and are not permitted to disclose the contents of this communication to</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>others.</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>This email and any files transmitted with it are confidential and</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>intended solely for the use of the individual or entity to whom they are</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>addressed. If you have received this email in error please notify the</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>originator of the message. Any views expressed in this message are those</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>of the individual sender.</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>This message has been scanned for viruses and Spam by ZTE Anti-Spam</pre><font face=3D"Courier New, Courier"></font><br><br> <pre>system.</pre><font face=3D"Courier New, Courier"></font>  </blockquote></body> <br> </html> --=====================_6636640==.ALT-- From liu.guoman@zte.com.cn Thu May 12 18:37:11 2011 Return-Path: <liu.guoman@zte.com.cn> 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 A8A6FE0711 for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 18:37:11 -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 JBRYHBeoJt5e for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 18:37:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAEE0593 for <mpls@ietf.org>; Thu, 12 May 2011 18:37:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12520806486374; Fri, 13 May 2011 09:34:58 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 88213.806486374; Fri, 13 May 2011 09:36:56 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p4D1aune035715 for <mpls@ietf.org>; Fri, 13 May 2011 09:36:56 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4D1YfU3033486; Fri, 13 May 2011 09:34:41 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201105130136.p4D1aune035715@mse02.zte.com.cn> In-Reply-To: <4DCB93DB.3070900@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Fri, 13 May 2011 09:34:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-13 09:34:41, Serialize complete at 2011-05-13 09:34:41 Content-Type: multipart/alternative; boundary="=_alternative 0008BDD74825788F_=" X-MAIL: mse02.zte.com.cn p4D1aune035715 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Fri, 13 May 2011 01:37:11 -0000 This is a multipart message in MIME format. --=_alternative 0008BDD74825788F_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3Rld2FydCxoaQ0KbWlzLWNvbm5lY3Rpdml0eSBvciBtaXMtY29uZmlndXJhdGlvbiB3aWxsIGdl bmVyYXRlIHR3byByZXN1bHRzOiB0aGUgZmlyc3QgDQpyZXN1bHQgaXMganVzdCBhcyB3aGF0IHlv dSBzYWlkLCBvdGhlciBMU1AgZGF0YSBwa3Qgd2lsbCBiZSANCmxlYWtlZCB0byB0aGUgTFNQIHBh dGguIGl0IGlzIHRydWx5IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBvdGhlciB0byBwb2xpY2UuIA0K DQp0aGUgc2Vjb25kIHJlc3VsdCBtYXkgbm90IGJlIG1lbnRpb25lZCBpbiB5b3VyIGVtYWlsLCB0 aGUgTFNQIGRhdGEgcGt0IA0Kd2lsbCBiZSBsZWFrZWQgdG8gb3RoZXIgTFNQIHBhdGguIGlmIHNv LCBob3cgdG8gcHJvY2VzcyB0aGlzIHByb2JsZW0/DQoNCmluIGFkZHRpb24sIGNhbiB0aGUgaW5p dGlhdG9yIG9mIHRoZSBMQiBwcm9jZXNzIGFuZCBhbmFseXNpcyBkZWVwbHkgYWxsIA0KZGF0YSBw YWNrZXQgd2hpY2ggaXMgYmVpbmcgbG9vcGJhY2tlZD8gaWYgc28gLCBpdCBpcyBtb3N0IHRhc2sg YW5kIA0KZGlmZmN1bHQgZm9yIHRoZSBpbml0aWF0b3Igb2YgdGhlIExCIHRvIGRvIGl0Pw0KDQpC LlIuDQpMaXUNCg0KDQoNCg0KDQoNCg0KU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNv bT4gDQrlj5Hku7bkuro6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDUtMTIgMTY6MDEN Cuivt+etlOWkjSDnu5kNCnN0YnJ5YW50QGNpc2NvLmNvbQ0KDQoNCuaUtuS7tuS6ug0KbXBsc0Bp ZXRmLm9yZw0K5oqE6YCBDQoNCuS4u+mimA0KUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiAgIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQNCg0KDQoNCg0KDQoNCldo YXQgaXMgdGhlIHRlc3QgdGhhdCBuZWVkcyB0byBiZSBtYWRlIGFuZCBleGFjdGx5IHdoZW4/DQoN CkxldCdzIHRhbGsgTUVQcyBmaXJzdC4NCg0KWW91IGNvdWxkIGdldCBhIGNjLWN2IHBrdCB0byB0 aGUgcmVtb3RlIGVuZCBieSBzZW5kaW5nIGl0IHdpdGggdGhlIHJpZ2h0IA0KVFRMLCBhbmQgeW91 IGNhbiByZWNlaXZlIGFueSBjYy1jdiBwa3QgZnJvbSB0aGUgcmVtb3RlIGVuZCBieSBleGFtaW5p bmcgDQphbGwgcmVjZWl2ZWQgcGt0cy4NCg0KVG8gZG8gY2MtY3YgZHVyaW5nIGEgTEIgYW55IGRp YWdub3N0aWNzIHlvdSBydW4gaW4gTEIgbmVlZCB0byB0YWtlIHRoYXQgDQppbnRvIGFjY291bnQg YW5kIHRoYXQgd2lsbCBjb21wbGljYXRlIHRoZSBkaWFnbm9zdGljcy4NCg0KSSBkbyBub3Qgc2Vl IGhvdyB5b3UgY291bGQgZXZlciBkbyBpdCB3aXRoIE1JUHMuDQoNCkkgd291bGQgdGhpbmsgdGhh dCBtb3N0IHVzZXJzIHdvdWxkIGJlIGNvbnRlbnQgdG8gdmVyaWZ5IHRoZSBMU1AgdXNpbmcgDQp0 cmFjZXJvdXRlL3BpbmcvY2MtY3YgdGhlbiB0byBzZXQgTEIgYW5kIHJ1biB0aGUgdGVzdHMgdGhl biBjbGVhciBMQiBhbmQgDQpyZS12ZXJpZnkgYXMgYWJvdmUuDQoNClRoZSBhYm92ZSBwcm9jZWR1 cmUgaXMgYW4gYXBwbGljYXRpb25zIGlzc3VlIGFuZCBub3QgYSBwcm90b2NvbCBpc3N1ZSwgYW5k IA0KdGh1cyBkb2VzIG5vdCBiZWxvbmcgaW4gdGhpcyBkb2N1bWVudC4NCg0KVGhlIG9ubHkgY2Fz ZSB0aGF0IGRvZXMgbm90IHNlZW0gdG8gYmUgY292ZXJlZCBpcyBhIHByb2JsZW0gdGhhdCBvY2N1 cnMgDQpkdXJpbmcgdGhlIExCLCBidXQgdGhhdCBpcyBhIGxvdyBwcm9iYWJpbGl0eSBldmVudCwg YW5kIHNpbmNlIHRoZXJlIGlzIG5vIA0KdXNlciBkYXRhIGJlaW5nIGNhcnJpZWQgIG9uIHRoZSBM U1AgdW5kZXIgTEIgdXNlciBzZXJ2aWNlIHdpbGwgbm90IGJlIA0KZGlzcnVwdGVkLiBJbiB0aGUg Y2FzZSBvZiBkYXRhIGluIHRoZSBMU1AgdW5kZXIgTEIgbGVha2luZyBhcyBhIHJlc3VsdCBvZiAN CmEgcHJvYmxlbSwgdGhhdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIG90aGVyIExTUCB0 byBwb2xpY2UuDQoNCk5vdGUgdGhhdCBieSBleGFtaW5pbmcgdGhlIGRhdGEgcmVjZWl2ZWQgZHVy aW5nIGEgTEIgdGV4dCB0aGUgaW5pdGlhdG9yIG9mIA0KdGhlIExCIGlzIGFibGUgdG8gdmVyaWZ5 IHRoYXQgaXQgaXMgdGhlaXIgZGF0YSB0aGF0IGlzIGJlaW5nIGxvb3BlZCBiYWNrIA0Kd2hpY2gg aXMgZXF1aXZhbGVudCB0byBydW5uaW5nIGEgY2MtY3YuDQoNClRodXMgSSBkbyBub3QgdGhpbmsg dGhhdCB0aGVyZSBpcyBhbnkgcHJhY3RpY2FsIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSANCmFk ZHJlc3NlZCBpbiB0aGUgcHJvdG9jb2wuDQoNCi0gU3Rld2FydA0KDQoNCk9uIDEyLzA1LzIwMTEg MDY6MDMsIFNhbWkgQm91dHJvcyB3cm90ZTogDQpUbyBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0 eS9taXMtY29uZmlndXJhdGlvbiwgeW91IG5lZWQgYSBjYy1jdiBmdW5jdGlvbiANCm5vdCBhIGxv b3BiYWNrIGZ1bmN0aW9uLg0KDQpUaGUgbG9vcGJhY2sgZnVuY3Rpb24gY2FuIGJlIHVzZWQgZm9y IGxvc3MvZGVsYXkgbWVhc3VyZW1lbnRzLCBhbmQgdGhpcyANCndpbGwgYmUgYWRkcmVzc2VkIGlu IHRoZSBkZWxheS9sb3NzIGRyYWZ0Lg0KDQpUaGFua3MsDQoNClNhbWkNCkF0IDA3OjExIFBNIDUv MTAvMjAxMSwgbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KDQpoaSwgYWxsIA0KZm9yIHRo aXMgZHJhZnQsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBMb29wYmFjayBmdW5jdGlvbi4gDQppbiBs YXN0IGlldGYgbWVldGluZywgSU1PLCB0aGUgYXV0aG9yIHNhbWkgc2FpZCB0aGlzIA0KTG9vcGJh Y2sgZnVuY3Rpb24gaXMgdG8gbG9vcGJhY2sgYW55dGhpbmcuIGZvciBNRVAgcG9pbnQgb2YgDQph IExTUCwgaWYgaXQgaXMgc2V0IHRvIExvb3BiYWNrIHN0YXRlLCBpdCB3aWxsIGxvb3BiYWNrIGFs bCByZWNlaXZlZCANCnBhY2tldHMgaW5jbHVkaW5nIGFueSBPQU0gcGFja2V0LiBpZiBzbywgaG93 IHRvIGRldGVjdCBtaXMtY29ubmVjdGl2aXR5IG9yIA0KDQptaXMtY29uZmlndXJhdGlvbiBmb3Ig dGhlIExTUD8gDQppbiBhZGR0aW9uLCBpZiBpdCBoYXBwZW4gbWlzLWNvbm5lY3Rpdml0eSwgbWF5 YmUgb3RoZXIgTFNQIHBhY2tldCBiZSANCnRyYW5zcG9ydGVkIHRvIA0KdGhlIE1FUCAsIGFuZCB0 aGUgbWVwIHBvaW50IHdpbGwgc3RpbGwgTG9vcGJhY2sgdGhlIHdyb25nIHBhY2tldCB0byBwZWVy IA0KbWVwIHBvaW50LCANCmNhbiBpdCBhZmZlY3QgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcyBvciBt ZWFzdXJlbWVudCBvbiB0aGUgcGVlciBtZXAgcG9pbnQ/IA0KDQoNCkIuUi4gDQpsaXUgDQoNCg0K DQoNCg0KDQpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IA0KwrfCosK8w77DiMOLOiAgbXBscy1i b3VuY2VzQGlldGYub3JnIA0KDQoyMDExLTA1LTEwIDIzOjQzIA0Kw4rDlcK8w77DiMOLDQoibXBs c0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+IA0KwrPCrcOLw40NClJvc3MgQ2FsbG9uIDxyY2Fs bG9uQGp1bmlwZXIubmV0PiwgTVBMUy1UUCBhZCBob2MgdGVhbSANCjxhaG1wbHMtdHBAbGlzdHMu aXR1LmludD4sIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZyANCsOWw7fD jMOiDQpbbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRw LWxpLWxiLTAxLnR4dCANCg0KDQoNCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0byBzdGFy dCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQoNCmRyYWZ0LWlldGYtbXBs cy10cC1saS1sYi0wMS50eHQNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBs c0BpZXRmLm9yZyBtYWlsaW5nIGxpc3QuDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwg ZW5kcyBvbiBNYXkgMjV0aC4NCg0KL0xvYQ0KDQpmb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzDQoN Ci0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxv YS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFn ZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAg ICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0bw0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZQ0KYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlDQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2UNCm9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0NCnN5c3RlbS4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCi0tIA0KRm9yIGNvcnBvcmF0 ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCg0KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fi b3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBs c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 0008BDD74825788F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXdhcnQsaGk8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm1pcy1jb25uZWN0aXZpdHkgb3IgbWlz LWNvbmZpZ3VyYXRpb24NCndpbGwgZ2VuZXJhdGUgdHdvIHJlc3VsdHM6IHRoZSBmaXJzdCByZXN1 bHQgaXMganVzdCBhcyB3aGF0IHlvdSBzYWlkLCBvdGhlcg0KTFNQIGRhdGEgcGt0IHdpbGwgYmUg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5sZWFrZWQgdG8gdGhl IExTUCBwYXRoLiBpdCBpcyB0cnVseQ0KcmVzcG9uc2liaWxpdHkgb2YgdGhlIG90aGVyIHRvIHBv bGljZS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUgc2Vj b25kIHJlc3VsdCBtYXkgbm90IGJlIG1lbnRpb25lZA0KaW4geW91ciBlbWFpbCwgdGhlIExTUCBk YXRhIHBrdCB3aWxsIGJlIGxlYWtlZCB0byBvdGhlciBMU1AgcGF0aC4gaWYgc28sDQpob3cgdG8g cHJvY2VzcyB0aGlzIHByb2JsZW0/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5pbiBhZGR0aW9uLCBjYW4gdGhlIGluaXRpYXRvciBvZiB0aGUNCkxCIHBy b2Nlc3MgYW5kIGFuYWx5c2lzIGRlZXBseSBhbGwgZGF0YSBwYWNrZXQgd2hpY2ggaXMgYmVpbmcg bG9vcGJhY2tlZD8NCmlmIHNvICwgaXQgaXMgbW9zdCB0YXNrIGFuZCA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRpZmZjdWx0IGZvciB0aGUgaW5pdGlhdG9yIG9m IHRoZSBMQg0KdG8gZG8gaXQ/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5CLlIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5MaXU8YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNlbnRl cj48L2Rpdj4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPlN0ZXdhcnQgQnJ5YW50ICZsdDtzdGJyeWFudEBjaXNjby5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7lj5Hk u7bkuro6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA1LTEyIDE2OjAxPC9mb250Pg0KPHRhYmxlIGJvcmRl cj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRl cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+6K+3562U5aSNIOe7mTxicj4NCnN0YnJ5 YW50QGNpc2NvLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 5Li76aKYPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGItMDEudHh0PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPldoYXQgaXMgdGhlIHRlc3QgdGhh dCBuZWVkcyB0byBiZSBtYWRlIGFuZCBleGFjdGx5IHdoZW4/PGJyPg0KPGJyPg0KTGV0J3MgdGFs ayBNRVBzIGZpcnN0Ljxicj4NCjxicj4NCllvdSBjb3VsZCBnZXQgYSBjYy1jdiBwa3QgdG8gdGhl IHJlbW90ZSBlbmQgYnkgc2VuZGluZyBpdCB3aXRoIHRoZSByaWdodA0KVFRMLCBhbmQgeW91IGNh biByZWNlaXZlIGFueSBjYy1jdiBwa3QgZnJvbSB0aGUgcmVtb3RlIGVuZCBieSBleGFtaW5pbmcN CmFsbCByZWNlaXZlZCBwa3RzLjxicj4NCjxicj4NClRvIGRvIGNjLWN2IGR1cmluZyBhIExCIGFu eSBkaWFnbm9zdGljcyB5b3UgcnVuIGluIExCIG5lZWQgdG8gdGFrZSB0aGF0DQppbnRvIGFjY291 bnQgYW5kIHRoYXQgd2lsbCBjb21wbGljYXRlIHRoZSBkaWFnbm9zdGljcy48YnI+DQo8YnI+DQpJ IGRvIG5vdCBzZWUgaG93IHlvdSBjb3VsZCBldmVyIGRvIGl0IHdpdGggTUlQcy48YnI+DQo8YnI+ DQpJIHdvdWxkIHRoaW5rIHRoYXQgbW9zdCB1c2VycyB3b3VsZCBiZSBjb250ZW50IHRvIHZlcmlm eSB0aGUgTFNQIHVzaW5nDQp0cmFjZXJvdXRlL3BpbmcvY2MtY3YgdGhlbiB0byBzZXQgTEIgYW5k IHJ1biB0aGUgdGVzdHMgdGhlbiBjbGVhciBMQiBhbmQNCnJlLXZlcmlmeSBhcyBhYm92ZS48YnI+ DQo8YnI+DQpUaGUgYWJvdmUgcHJvY2VkdXJlIGlzIGFuIGFwcGxpY2F0aW9ucyBpc3N1ZSBhbmQg bm90IGEgcHJvdG9jb2wgaXNzdWUsDQphbmQgdGh1cyBkb2VzIG5vdCBiZWxvbmcgaW4gdGhpcyBk b2N1bWVudC48YnI+DQo8YnI+DQpUaGUgb25seSBjYXNlIHRoYXQgZG9lcyBub3Qgc2VlbSB0byBi ZSBjb3ZlcmVkIGlzIGEgcHJvYmxlbSB0aGF0IG9jY3Vycw0KZHVyaW5nIHRoZSBMQiwgYnV0IHRo YXQgaXMgYSBsb3cgcHJvYmFiaWxpdHkgZXZlbnQsIGFuZCBzaW5jZSB0aGVyZSBpcw0Kbm8gdXNl ciBkYXRhIGJlaW5nIGNhcnJpZWQgJm5ic3A7b24gdGhlIExTUCB1bmRlciBMQiB1c2VyIHNlcnZp Y2Ugd2lsbA0Kbm90IGJlIGRpc3J1cHRlZC4gSW4gdGhlIGNhc2Ugb2YgZGF0YSBpbiB0aGUgTFNQ IHVuZGVyIExCIGxlYWtpbmcgYXMgYQ0KcmVzdWx0IG9mIGEgcHJvYmxlbSwgdGhhdCBpcyB0aGUg cmVzcG9uc2liaWxpdHkgb2YgdGhlIG90aGVyIExTUCB0byBwb2xpY2UuPGJyPg0KPGJyPg0KTm90 ZSB0aGF0IGJ5IGV4YW1pbmluZyB0aGUgZGF0YSByZWNlaXZlZCBkdXJpbmcgYSBMQiB0ZXh0IHRo ZSBpbml0aWF0b3INCm9mIHRoZSBMQiBpcyBhYmxlIHRvIHZlcmlmeSB0aGF0IGl0IGlzIHRoZWly IGRhdGEgdGhhdCBpcyBiZWluZyBsb29wZWQNCmJhY2sgd2hpY2ggaXMgZXF1aXZhbGVudCB0byBy dW5uaW5nIGEgY2MtY3YuPGJyPg0KPGJyPg0KVGh1cyBJIGRvIG5vdCB0aGluayB0aGF0IHRoZXJl IGlzIGFueSBwcmFjdGljYWwgcHJvYmxlbSB0aGF0IG5lZWRzIHRvIGJlDQphZGRyZXNzZWQgaW4g dGhlIHByb3RvY29sLjxicj4NCjxicj4NCi0gU3Rld2FydDxicj4NCjxicj4NCjxicj4NCk9uIDEy LzA1LzIwMTEgMDY6MDMsIFNhbWkgQm91dHJvcyB3cm90ZTogPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz5UbyBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0eS9taXMtY29uZmlndXJhdGlvbiwgeW91 IG5lZWQNCmEgY2MtY3YgZnVuY3Rpb24gbm90IGEgbG9vcGJhY2sgZnVuY3Rpb24uPGJyPg0KPGJy Pg0KVGhlIGxvb3BiYWNrIGZ1bmN0aW9uIGNhbiBiZSB1c2VkIGZvciBsb3NzL2RlbGF5IG1lYXN1 cmVtZW50cywgYW5kIHRoaXMNCndpbGwgYmUgYWRkcmVzc2VkIGluIHRoZSBkZWxheS9sb3NzIGRy YWZ0Ljxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpTYW1pPGJyPg0KQXQgMDc6MTEgUE0g NS8xMC8yMDExLCA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGl1Lmd1b21hbkB6dGUuY29tLmNuPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmxpdS5ndW9tYW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9Mz4NCndyb3RlOjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ aGksIGFsbDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KZm9y IHRoaXMgZHJhZnQsIEkgaGF2ZSBhIHF1ZXN0aW9uIGZvciBMb29wYmFjayBmdW5jdGlvbi48L2Zv bnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQppbiBsYXN0IGlldGYg bWVldGluZywgSU1PLCB0aGUgYXV0aG9yIHNhbWkgc2FpZCB0aGlzIDxicj4NCkxvb3BiYWNrIGZ1 bmN0aW9uIGlzIHRvIGxvb3BiYWNrIGFueXRoaW5nLiBmb3IgTUVQIHBvaW50IG9mIDxicj4NCmEg TFNQLCBpZiBpdCBpcyBzZXQgdG8gTG9vcGJhY2sgc3RhdGUsIGl0IHdpbGwgbG9vcGJhY2sgYWxs IHJlY2VpdmVkPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0K cGFja2V0cyBpbmNsdWRpbmcgYW55IE9BTSBwYWNrZXQuIGlmIHNvLCBob3cgdG8gZGV0ZWN0IG1p cy1jb25uZWN0aXZpdHkNCm9yPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9 Mj48YnI+DQptaXMtY29uZmlndXJhdGlvbiBmb3IgdGhlIExTUD88L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCmluIGFkZHRpb24sIGlmIGl0IGhhcHBlbiBtaXMt Y29ubmVjdGl2aXR5LCBtYXliZSBvdGhlciBMU1AgcGFja2V0IGJlIHRyYW5zcG9ydGVkDQp0byA8 YnI+DQp0aGUgTUVQICwgYW5kIHRoZSBtZXAgcG9pbnQgd2lsbCBzdGlsbCBMb29wYmFjayB0aGUg d3JvbmcgcGFja2V0IHRvIHBlZXINCm1lcCBwb2ludCw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yPjxicj4NCmNhbiBpdCBhZmZlY3Q8L2ZvbnQ+PGEgaHJlZj1hcHA6ZHM6 cGVyZm9ybWFuY2U+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWU+PHU+DQpwZXJmb3JtYW5jZTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9Mj4gPC9mb250PjxhIGhyZWY9YXBwOmRzOnN0YXRpc3RpY3M+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWU+PHU+c3RhdGlzdGljczwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+b3IgbWVhc3VyZW1lbnQgb24gdGhlIHBlZXIg bWVwIHBvaW50PzwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y Pjxicj4NCkIuUi48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4N CmxpdTwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTE+PGI+PGJyPg0KTG9hIEFuZGVyc3NvbiA8L2I+PC9mb250 PjxhIGhyZWY9bWFpbHRvOmxvYUBwaS5udT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZT48Yj48dT4m bHQ7bG9hQHBpLm51Jmd0OzwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTE+DQo8YnI+DQrC t8KiwrzDvsOIw4s6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZT48dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xPjxi cj4NCjIwMTEtMDUtMTAgMjM6NDM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pg0KPGJyPjxmb250IHNpemU9MT7DisOVwrzDvsOIw4s8L2ZvbnQ+PC9kaXY+DQo8 YnI+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZT48 dT4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xPg0K PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs dWU+PHU+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0K PC9mb250Pg0KPGRpdiBhbGlnbj1yaWdodD4NCjxicj48Zm9udCBzaXplPTE+wrPCrcOLw408L2Zv bnQ+PC9kaXY+DQo8YnI+PGZvbnQgc2l6ZT0xPlJvc3MgQ2FsbG9uIDwvZm9udD48YSBocmVmPW1h aWx0bzpyY2FsbG9uQGp1bmlwZXIubmV0Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlPjx1PiZsdDty Y2FsbG9uQGp1bmlwZXIubmV0Jmd0OzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MT4sDQpNUExT LVRQIGFkIGhvYyB0ZWFtIDwvZm9udD48YSBocmVmPSJtYWlsdG86YWhtcGxzLXRwQGxpc3RzLml0 dS5pbnQiPjxmb250IHNpemU9MSBjb2xvcj1ibHVlPjx1PiZsdDthaG1wbHMtdHBAbGlzdHMuaXR1 LmludCZndDs8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTE+LA0KPC9mb250PjxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGJAdG9vbHMuaWV0Zi5vcmciPjxmb250IHNpemU9 MSBjb2xvcj1ibHVlPjx1PmRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjxkaXYgYWxpZ249cmlnaHQ+DQo8 YnI+PGZvbnQgc2l6ZT0xPsOWw7fDjMOiPC9mb250PjwvZGl2Pg0KPGJyPjxmb250IHNpemU9MT5b bXBsc10gd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxi LTAxLnR4dDwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQpXb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbjxicj4NCjxi cj4NCmRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQ8YnI+DQo8YnI+DQpQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSA8L3R0PjwvZm9udD48YSBocmVmPW1haWx0bzptcGxzQGll dGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5tcGxzQGlldGYub3JnPC91Pjwv dHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PHR0Pg0KbWFpbGluZyBsaXN0Ljxicj4NCjxicj4N ClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBNYXkgMjV0aC48YnI+DQo8YnI+ DQovTG9hPGJyPg0KPGJyPg0KZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlyczxicj4NCjxicj4NCi0t IDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGVtYWlsOiA8L3R0PjwvZm9udD48YSBocmVmPW1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNz c29uLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+bG9hLmFuZGVyc3NvbkBlcmlj c3Nvbi5jb208L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KU3IgU3Ry YXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PC90dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bG9hQHBpLm51Pjxmb250IHNp emU9MyBjb2xvcj1ibHVlPjx0dD48dT5sb2FAcGkubnU8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250 IHNpemU9Mz48dHQ+PGJyPg0KRXJpY3Nzb24gSW5jICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyArNDYgNzY3IDcyIDkyIDEzPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlz dDwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90 dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dHQ+PHU+bXBsc0BpZXRmLm9yZzwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWU+PHR0Pjx1Pjxicj4NCjwvdT48L3R0PjwvZm9udD48YSBocmVmPWh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC91Pjwv dHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PHR0Pjxicj4NCjwvdHQ+PC9mb250Pjxmb250IHNp emU9Mz48YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsPGJyPg0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uPGJyPg0KaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eTxicj4NCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvPGJyPg0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kPGJyPg0KaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlPGJyPg0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlPGJyPg0Kb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlPGJyPg0K b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW08YnI+DQpzeXN0ZW0uPGJy Pg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMg bWFpbGluZyBsaXN0PGJyPg0KPC90dD48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9y Zz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+bXBsc0BpZXRmLm9yZzwvdT48L3R0Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQo8L3R0PjwvZm9udD48YSBocmVmPWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC91 PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PHR0Pjxicj4NCjwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4tLSA8YnI+ DQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOjxicj4NCjxicj4NCjwvdHQ+ PC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2lu ZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5o dHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2lu ZGV4Lmh0bWw8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPGJyPg0K PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4N CjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 0008BDD74825788F_=-- From liu.guoman@zte.com.cn Thu May 12 19:03:32 2011 Return-Path: <liu.guoman@zte.com.cn> 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 8B96113001F for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 19:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=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 RUI2ZED5P8fn for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 19:03:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 593FC13001A for <mpls@ietf.org>; Thu, 12 May 2011 19:03:26 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12520806486374; Fri, 13 May 2011 10:01:26 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 88213.806486374; Fri, 13 May 2011 10:03:24 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p4D23NQb065607 for <mpls@ietf.org>; Fri, 13 May 2011 10:03:23 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4D1kbc1048163; Fri, 13 May 2011 09:46:38 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201105130203.p4D23NQb065607@mse02.zte.com.cn> In-Reply-To: <XFE-RCD-302agj5BbHk0000001a@xfe-rcd-302.cisco.com> To: Sami Boutros <sboutros@cisco.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Fri, 13 May 2011 09:46:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-13 09:46:38, Serialize complete at 2011-05-13 09:46:38 Content-Type: multipart/alternative; boundary="=_alternative 0009D5DC4825788F_=" X-MAIL: mse02.zte.com.cn p4D23NQb065607 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: Ross Callon <rcallon@juniper.net>, mpls@ietf.org, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Fri, 13 May 2011 02:03:32 -0000 This is a multipart message in MIME format. --=_alternative 0009D5DC4825788F_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 c2FtaSwgeWFjY292LGhpDQpmaXJzdGx5IGkgc2F5IHNvcnJ5IGZvciBub3QgY2xlYXJseSBkZXNj cmlibGluZyBteSBxdWVzdGlvbi4gDQpmb3IgdGhlIGZpcnN0IHF1ZXN0aW9uLCBtYXliZSB5YWFj b3YncyB1bmRlcnN0YW5kaW5nIGJlIHJpZ2h0LiBpZiBhIG1lcCBpcyANCg0Kb24gbG9vcGJhY2sg c3RhdGUsIGl0IGNhbid0IGNoZWNrIHRoZSBlMmUgcGF0aCBmb3IgbWlzLWNvbm5lY3Rpdml0eSAN CmJlY2F1c2UNCnRoZSBtZXAgcG9pbnQgbG9vcGJhY2sgZXZlcnl0aGluZyBpbmNsdWRpbmcgYW55 IE9BTSBwYWNrZXQoY2MmY3YgZXRjKTsNCg0KZm9yIHRoZSBzZWNvbmQgcXVlc3Rpb24sIEkga25v dyBsb3NzL2RlbGF5IG1lYXN1cmVtZW50IHNob3VsZCB1c2UgTE0vRE0gDQpmdWN0aW9uIHRvIA0K aW1wbGVtZW50IGl0LiBidXQgZm9yIGxvb3BiYWNrIGZ1bmN0aW9uLCB0aGVyZSBhcmUgdGhlIGZv bGxvd2luZyB0d28gDQphcHBsaWNhdGlvbjoNCiAgMSBUbyB2ZXJpZnkgYmlkaXJlY3Rpb25hbCBj b25uZWN0aXZpdHkgb2YgYSBNRVAgd2l0aCBhIE1JUCBvciBhIHBlZXIgTUVQDQo7DQogIDIgVG8g cGVyZm9ybSBhIGJpZGlyZWN0aW9uYWwgaW4tc2VydmljZSBvciBvdXQtb2Ytc2VydmljZSBkaWFn bm9zdGljcyANCnRlc3QgYmV0d2VlbiBhIHBhaXIgb2YgcGVlciBNRVBzLiBUaGlzIGluY2x1ZGVz IHZlcmlmeWluZyBiYW5kd2lkdGggDQp0aHJvdWdocHV0LCBkZXRlY3RpbmcgYml0IGVycm9ycywg ZXRjOw0KIA0Kc28gZm9yIGFwcGxpY2F0aW9uIDEsIGxvb3BiYWNrIGFueXRoaW5nIHdpbGwgbm90 IGFmZmVjdCB2ZXJpZnkgDQpiaWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eTsgYnV0IGl0IG1heSBh ZmZlY3QgZGlhZ25vc3RpY3MgdGVzdC4NCmZvciBleGFtcGxlLCBpZiBtaXMtY29ubmVjdGl2aXR5 IG9yIG1pcy1jb25maWd1cmF0aW9uIGhhcHBlbmVkIG9uIGEgTFNQIA0KcGF0aCwgc2luY2UgdGhl IG1lcCBvZiB0aGUgbHNwIGlzIHVuZGVyIGxvb3BiYWNrIHN0YXRlLCBpdCBjYW4ndCBjaGVjayAN Cm1pcy1jb25uZWN0aXZpdHksDQpzbyB0aGUgbWVwIG9mIHRoZSBsc3AgbWF5YmUgbG9vcGJhY2sg b3RoZXIgZGF0YSBwYWNrZXQgb2YgYW5vdGhlciBsc3AgdG8gDQp0aGUgcGVlciBtZXAub3IgdGhl IGRhdGEgcGt0IG9mIHRoZSBMU1Agd2lsbCBiZSBsZWFrZWQgdG8gb3RoZXIgTFNQIHBhdGgsIA0K c28gaXQgbXVzdCBhZmZlY3QgdGhlIHJlc3VsdCBvZiBkaWFnbm9zdGljcyB0ZXN0IGluY2x1ZGlu ZyBiYW5kd2lkdGggDQp0aHJvdWdocHV0LCBiaXQgZXJyb3JzLg0KDQptYXliZSBpIG1pc3Mgc29t ZXRoaW5nIGltcG9ydGFudD8NCg0KdGhhbmsgc2FtaSBhbmQgeWFhY292IGZvciBwcm9tcHQgcmVw bHlpbmcgaXQuDQoNCkIuUi4NCkxpdQ0KDQoNCg0KDQoNCg0KDQpTYW1pIEJvdXRyb3MgPHNib3V0 cm9zQGNpc2NvLmNvbT4gDQoyMDExLTA1LTEzIDA1OjA1DQoNCuaUtuS7tuS6ug0KIldlaW5nYXJ0 ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSIgPHlhYWNvdi53ZWluZ2FydGVuQG5z bi5jb20+LCANCjxsaXUuZ3VvbWFuQHp0ZS5jb20uY24+LCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBw aS5udT4NCuaKhOmAgQ0KIlJvc3MgQ2FsbG9uIiA8cmNhbGxvbkBqdW5pcGVyLm5ldD4sIDxtcGxz QGlldGYub3JnPiwgIk1QTFMtVFAgYWQgaG9jIA0KdGVhbSIgPGFobXBscy10cEBsaXN0cy5pdHUu aW50PiwgPGRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZz4NCuS4u+mimA0K UkU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiAgZHJhZnQtaWV0Zi1tcGxzLXRw LWxpLWxiLTAxLnR4dA0KDQoNCg0KDQoNCg0KQWdyZWVkIFlhYWNvdiwgZHVyaW5nIHRoZSBwZXJp b2Qgb2YgbG9vcGJhY2sgdGhlIGNjLWN2IGZ1bmN0aW9uIGNhbid0IGJlIA0KcGVyZm9ybWVkLCBh bmQgeWVzIHRoZSBtYWluIGJlbmVmaXQgaXMgb2YgbG9vcGJhY2sgaXMgdG8gbWVhc3VyZSANCmxv c3MvZGVsYXkgb24gYSBzZWdtZW50IG9mIGEgcGF0aCBhcyB5b3Ugc3RhdGVkLg0KDQpUaGFua3Ms DQoNClNhbWkNCkF0IDEwOjM2IFBNIDUvMTEvMjAxMSwgV2VpbmdhcnRlbiwgWWFhY292IChOU04g LSBJTC9Ib2QgSGFTaGFyb24pIHdyb3RlOg0KU2FtaSwgaGkNCiANCk15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGUgcXVlc3Rpb24gdGhhdCB3YXMgYXNrZWQgaXMgaG93IGRvIHlvdSB1c2UgdGhl IA0KY2MtY3YgZnVuY3Rpb24gdG8gY2hlY2sgZm9yIG1pcy1jb25uZWN0aXZpdHkgaWYgaXQgaXMg YmVpbmcgbG9vcGVkLWJhY2suDQogDQpUcnV0aCBiZSB0b2xkIHRoYXQgZHVyaW5nIHRoZSBwZXJp b2Qgb2YgbG9vcGJhY2sgeW91IGFwcGFyZW50bHkgY2Fubm90IA0KY2hlY2sgdGhlIGUyZSBwYXRo IGZvciBtaXMtY29ubmVjdGl2aXR5LCBhbmQgdGhlIG9wZXJhdG9yIG5lZWRzIHRvIHRha2UgDQp0 aGlzIGludG8gY29uc2lkZXJhdGlvbi4gIEJ1dCBzaW5jZSB0aGUgcGF0aCBpcyBub3QgdHJhbnNm ZXJyaW5nIGRhdGEgZTJlIA0KKGl0IGlzIGxvb3BpbmcgZXZlcnl0aGluZyBiYWNrKSBpdCBpcyBi eSBkZWZpbml0aW9uIG5vdCBjb25uZWN0ZWQgZTJlLg0KIA0KV2hhdCBpcyB0cnVlIGlzIHdoYXQg U2FtaSBzdGF0ZXMgdGhpcyBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSB1c2VkIHRvIA0Kc2V0dXAg YSBsb3NzL2RlbGF5IG1lYXN1cmVtZW50IG9uIGEgc2VnbWVudCBvZiBhIHBhdGgsIGFuZCBpdCBz aG91bGQgYmUgDQp1c2VkIG9ubHkgZm9yIGxpbWl0ZWQgcGVyaW9kcy4NCiANCkp1c3QgbXkgMmNl bnRzLA0KeWFhY292DQogDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgWyBtYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpleHQgU2FtaSBCb3V0cm9zDQpTZW50 OiBUaHVyc2RheSwgTWF5IDEyLCAyMDExIDg6MDMgQU0NClRvOiBsaXUuZ3VvbWFuQHp0ZS5jb20u Y247IExvYSBBbmRlcnNzb24NCkNjOiBSb3NzIENhbGxvbjsgbXBsc0BpZXRmLm9yZzsgTVBMUy1U UCBhZCBob2MgdGVhbTsgDQpkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGJAdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gDQpkcmFmdC1p ZXRmLW1wbHMtdHAtbGktbGItMDEudHh0DQogDQpUbyBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0 eS9taXMtY29uZmlndXJhdGlvbiwgeW91IG5lZWQgYSBjYy1jdiBmdW5jdGlvbiANCm5vdCBhIGxv b3BiYWNrIGZ1bmN0aW9uLg0KDQpUaGUgbG9vcGJhY2sgZnVuY3Rpb24gY2FuIGJlIHVzZWQgZm9y IGxvc3MvZGVsYXkgbWVhc3VyZW1lbnRzLCBhbmQgdGhpcyANCndpbGwgYmUgYWRkcmVzc2VkIGlu IHRoZSBkZWxheS9sb3NzIGRyYWZ0Lg0KDQpUaGFua3MsDQoNClNhbWkNCkF0IDA3OjExIFBNIDUv MTAvMjAxMSwgbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KDQoNCmhpLCBhbGwgDQpmb3Ig dGhpcyBkcmFmdCwgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIExvb3BiYWNrIGZ1bmN0aW9uLiANCmlu IGxhc3QgaWV0ZiBtZWV0aW5nLCBJTU8sIHRoZSBhdXRob3Igc2FtaSBzYWlkIHRoaXMgDQpMb29w YmFjayBmdW5jdGlvbiBpcyB0byBsb29wYmFjayBhbnl0aGluZy4gZm9yIE1FUCBwb2ludCBvZiAN CmEgTFNQLCBpZiBpdCBpcyBzZXQgdG8gTG9vcGJhY2sgc3RhdGUsIGl0IHdpbGwgbG9vcGJhY2sg YWxsIHJlY2VpdmVkIA0KcGFja2V0cyBpbmNsdWRpbmcgYW55IE9BTSBwYWNrZXQuIGlmIHNvLCBo b3cgdG8gZGV0ZWN0IG1pcy1jb25uZWN0aXZpdHkgb3IgDQoNCm1pcy1jb25maWd1cmF0aW9uIGZv ciB0aGUgTFNQPyANCmluIGFkZHRpb24sIGlmIGl0IGhhcHBlbiBtaXMtY29ubmVjdGl2aXR5LCBt YXliZSBvdGhlciBMU1AgcGFja2V0IGJlIA0KdHJhbnNwb3J0ZWQgdG8gDQp0aGUgTUVQICwgYW5k IHRoZSBtZXAgcG9pbnQgd2lsbCBzdGlsbCBMb29wYmFjayB0aGUgd3JvbmcgcGFja2V0IHRvIHBl ZXIgDQptZXAgcG9pbnQsIA0KY2FuIGl0IGFmZmVjdCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzIG9y IG1lYXN1cmVtZW50IG9uIHRoZSBwZWVyIG1lcCBwb2ludD8gDQoNCg0KQi5SLiANCmxpdSANCg0K DQoNCg0KDQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gDQrCt8KiwrzDvsOIw4s6ICBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMTEtMDUtMTAgMjM6NDMgDQrDisOVwrzDvsOIw4sNCiJt cGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4gDQrCs8Ktw4vDjQ0KUm9zcyBDYWxsb24gPHJj YWxsb25AanVuaXBlci5uZXQ+LCBNUExTLVRQIGFkIGhvYyB0ZWFtIA0KPGFobXBscy10cEBsaXN0 cy5pdHUuaW50PiwgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRvb2xzLmlldGYub3JnIA0Kw5bD t8OMw6INClttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMt dHAtbGktbGItMDEudHh0IA0KDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0 YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCg0KZHJhZnQtaWV0Zi1t cGxzLXRwLWxpLWxiLTAxLnR4dA0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBt cGxzQGlldGYub3JnIG1haWxpbmcgbGlzdC4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBlbmRzIG9uIE1heSAyNXRoLg0KDQovTG9hDQoNCmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnMN Cg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDog bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFu YWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAg ICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoN Cg0KDQogDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwNCg0KDQppcyBzb2xlbHkgcHJvcGVydHkg b2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsDQpjb21tdW5pY2F0aW9uDQoN Cg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4NCnNlY3JlY3kNCg0KDQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbg0KdG8NCg0KDQpvdGhlcnMuDQoN Cg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbA0KYW5kDQoNCg0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkNCmFyZQ0KDQoNCmFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5DQp0aGUNCg0K DQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUNCnRob3NlDQoNCg0Kb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci4NCg0KDQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUN CkFudGktU3BhbQ0KDQoNCnN5c3RlbS4NCiANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNv bGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNj bG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMg ZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2Fn ZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBp bmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0009D5DC4825788F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNhbWksIHlhY2NvdixoaTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Zmlyc3RseSBpIHNheSBzb3Jy eSBmb3Igbm90IGNsZWFybHkNCmRlc2NyaWJsaW5nIG15IHF1ZXN0aW9uLiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvciB0aGUgZmlyc3QgcXVlc3Rpb24sIG1h eWJlIHlhYWNvdidzDQp1bmRlcnN0YW5kaW5nIGJlIHJpZ2h0LiBpZiBhIG1lcCBpcyA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9uIGxvb3BiYWNrIHN0YXRlLCBp dCBjYW4ndCBjaGVjayB0aGUNCmUyZSBwYXRoIGZvciBtaXMtY29ubmVjdGl2aXR5IGJlY2F1c2U8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBtZXAgcG9pbnQg bG9vcGJhY2sgZXZlcnl0aGluZyBpbmNsdWRpbmcNCmFueSBPQU0gcGFja2V0KGNjJmFtcDtjdiBl dGMpOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Zm9y IHRoZSBzZWNvbmQgcXVlc3Rpb24sIEkga25vdyBsb3NzL2RlbGF5DQptZWFzdXJlbWVudCBzaG91 bGQgdXNlIExNL0RNIGZ1Y3Rpb24gdG8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5pbXBsZW1lbnQgaXQuIGJ1dCBmb3IgbG9vcGJhY2sgZnVuY3Rpb24sDQp0aGVy ZSBhcmUgdGhlIGZvbGxvd2luZyB0d28gYXBwbGljYXRpb246PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgMSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+VG8NCnZlcmlmeSBiaWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eSBv ZiBhIE1FUCB3aXRoIGEgTUlQIG9yIGEgcGVlciBNRVA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAyIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Ubw0K cGVyZm9ybSBhIGJpZGlyZWN0aW9uYWwgaW4tc2VydmljZSBvciBvdXQtb2Ytc2VydmljZSBkaWFn bm9zdGljcyB0ZXN0IGJldHdlZW4NCmEgcGFpciBvZiBwZWVyIE1FUHMuIFRoaXMgaW5jbHVkZXMg dmVyaWZ5aW5nIGJhbmR3aWR0aCB0aHJvdWdocHV0LCBkZXRlY3RpbmcNCmJpdCBlcnJvcnMsIGV0 YzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+OzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5zbyBmb3IgYXBwbGljYXRpb24gMSwgbG9vcGJhY2sgYW55dGhp bmcNCndpbGwgbm90IGFmZmVjdCB2ZXJpZnkgYmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHk7IGJ1 dCBpdCBtYXkgYWZmZWN0IGRpYWdub3N0aWNzDQp0ZXN0LjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Zm9yIGV4YW1wbGUsIGlmIG1pcy1jb25uZWN0aXZpdHkgb3IN Cm1pcy1jb25maWd1cmF0aW9uIGhhcHBlbmVkIG9uIGEgTFNQIHBhdGgsIHNpbmNlIHRoZSBtZXAg b2YgdGhlIGxzcCBpcyB1bmRlcg0KbG9vcGJhY2sgc3RhdGUsIGl0IGNhbid0IGNoZWNrIG1pcy1j b25uZWN0aXZpdHksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5z byB0aGUgbWVwIG9mIHRoZSBsc3AgbWF5YmUgbG9vcGJhY2sNCm90aGVyIGRhdGEgcGFja2V0IG9m IGFub3RoZXIgbHNwIHRvIHRoZSBwZWVyIG1lcC5vciB0aGUgZGF0YSBwa3Qgb2YgdGhlDQpMU1Ag d2lsbCBiZSBsZWFrZWQgdG8gb3RoZXIgTFNQIHBhdGgsIHNvIGl0IG11c3QgYWZmZWN0IHRoZSBy ZXN1bHQgb2YgZGlhZ25vc3RpY3MNCnRlc3QgaW5jbHVkaW5nIGJhbmR3aWR0aCB0aHJvdWdocHV0 LCBiaXQgZXJyb3JzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+bWF5YmUgaSBtaXNzIHNvbWV0aGluZyBpbXBvcnRhbnQ/PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFuayBzYW1pIGFuZCB5YWFjb3YgZm9y IHByb21wdCByZXBseWluZw0KaXQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5CLlIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5MaXU8YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNl bnRlcj48L2Rpdj4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPlNhbWkgQm91dHJvcyAmbHQ7c2JvdXRyb3NAY2lzY28uY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEx LTA1LTEzIDA1OjA1PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O1dlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kDQpI YVNoYXJvbikmcXVvdDsgJmx0O3lhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20mZ3Q7LCAmbHQ7bGl1 Lmd1b21hbkB6dGUuY29tLmNuJmd0OywNCiZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0O2xv YUBwaS5udSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Um9zcyBDYWxsb24mcXVvdDsg Jmx0O3JjYWxsb25AanVuaXBlci5uZXQmZ3Q7LA0KJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCAmcXVv dDtNUExTLVRQIGFkIGhvYyB0ZWFtJnF1b3Q7ICZsdDthaG1wbHMtdHBAbGlzdHMuaXR1LmludCZn dDssDQombHQ7ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRvb2xzLmlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+5Li76aKYPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SRTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQom bmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGItMDEudHh0PC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkFncmVlZCBZYWFjb3YsIGR1cmluZyB0 aGUgcGVyaW9kIG9mIGxvb3BiYWNrIHRoZSBjYy1jdg0KZnVuY3Rpb24gY2FuJ3QgYmUgcGVyZm9y bWVkLCBhbmQgeWVzIHRoZSBtYWluIGJlbmVmaXQgaXMgb2YgbG9vcGJhY2sgaXMNCnRvIG1lYXN1 cmUgbG9zcy9kZWxheSBvbiBhIHNlZ21lbnQgb2YgYSBwYXRoIGFzIHlvdSBzdGF0ZWQuPGJyPg0K PGJyPg0KVGhhbmtzLDxicj4NCjxicj4NClNhbWk8YnI+DQpBdCAxMDozNiBQTSA1LzExLzIwMTEs IFdlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSB3cm90ZTo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPlNhbWksIGhpPGJyPg0KIDxicj4NCk15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGUgcXVlc3Rpb24gdGhhdCB3YXMgYXNrZWQgaXMgaG93IGRvIHlvdSB1c2UNCnRo ZSBjYy1jdiBmdW5jdGlvbiB0byBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0eSBpZiBpdCBpcyBi ZWluZyBsb29wZWQtYmFjay48YnI+DQogPGJyPg0KVHJ1dGggYmUgdG9sZCB0aGF0IGR1cmluZyB0 aGUgcGVyaW9kIG9mIGxvb3BiYWNrIHlvdSBhcHBhcmVudGx5IGNhbm5vdA0KY2hlY2sgdGhlIGUy ZSBwYXRoIGZvciBtaXMtY29ubmVjdGl2aXR5LCBhbmQgdGhlIG9wZXJhdG9yIG5lZWRzIHRvIHRh a2UNCnRoaXMgaW50byBjb25zaWRlcmF0aW9uLiAmbmJzcDtCdXQgc2luY2UgdGhlIHBhdGggaXMg bm90IHRyYW5zZmVycmluZyBkYXRhDQplMmUgKGl0IGlzIGxvb3BpbmcgZXZlcnl0aGluZyBiYWNr KSBpdCBpcyBieSBkZWZpbml0aW9uIG5vdCBjb25uZWN0ZWQgZTJlLjxicj4NCiA8YnI+DQpXaGF0 IGlzIHRydWUgaXMgd2hhdCBTYW1pIHN0YXRlcyB0aGlzIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJl IHVzZWQgdG8gc2V0dXANCmEgbG9zcy9kZWxheSBtZWFzdXJlbWVudCBvbiBhIHNlZ21lbnQgb2Yg YSBwYXRoLCBhbmQgaXQgc2hvdWxkIGJlIHVzZWQNCm9ubHkgZm9yIGxpbWl0ZWQgcGVyaW9kcy48 YnI+DQogPGJyPg0KSnVzdCBteSAyY2VudHMsPGJyPg0KeWFhY292PGJyPg0KIDxiPjxicj4NCkZy b206PC9iPiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgWzwvZm9udD48YSBocmVmPSJtYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT4NCm1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+XSA8Yj5PbiBC ZWhhbGYgT2YNCjwvYj5leHQgU2FtaSBCb3V0cm9zPGI+PGJyPg0KU2VudDo8L2I+IFRodXJzZGF5 LCBNYXkgMTIsIDIwMTEgODowMyBBTTxiPjxicj4NClRvOjwvYj4gbGl1Lmd1b21hbkB6dGUuY29t LmNuOyBMb2EgQW5kZXJzc29uPGI+PGJyPg0KQ2M6PC9iPiBSb3NzIENhbGxvbjsgbXBsc0BpZXRm Lm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRvb2xz LmlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbbXBsc10gd29ya2luZyBncm91cCBs YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiLTAxLnR4dDxicj4NCiA8YnI+DQpU byBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0eS9taXMtY29uZmlndXJhdGlvbiwgeW91IG5lZWQg YSBjYy1jdiBmdW5jdGlvbg0Kbm90IGEgbG9vcGJhY2sgZnVuY3Rpb24uPGJyPg0KPGJyPg0KVGhl IGxvb3BiYWNrIGZ1bmN0aW9uIGNhbiBiZSB1c2VkIGZvciBsb3NzL2RlbGF5IG1lYXN1cmVtZW50 cywgYW5kIHRoaXMNCndpbGwgYmUgYWRkcmVzc2VkIGluIHRoZSBkZWxheS9sb3NzIGRyYWZ0Ljxi cj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpTYW1pPGJyPg0KQXQgMDc6MTEgUE0gNS8xMC8y MDExLCBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KaGksIGFs bCA8YnI+DQpmb3IgdGhpcyBkcmFmdCwgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIExvb3BiYWNrIGZ1 bmN0aW9uLiA8YnI+DQppbiBsYXN0IGlldGYgbWVldGluZywgSU1PLCB0aGUgYXV0aG9yIHNhbWkg c2FpZCB0aGlzIDxicj4NCkxvb3BiYWNrIGZ1bmN0aW9uIGlzIHRvIGxvb3BiYWNrIGFueXRoaW5n LiBmb3IgTUVQIHBvaW50IG9mIDxicj4NCmEgTFNQLCBpZiBpdCBpcyBzZXQgdG8gTG9vcGJhY2sg c3RhdGUsIGl0IHdpbGwgbG9vcGJhY2sgYWxsIHJlY2VpdmVkIDxicj4NCnBhY2tldHMgaW5jbHVk aW5nIGFueSBPQU0gcGFja2V0LiBpZiBzbywgaG93IHRvIGRldGVjdCBtaXMtY29ubmVjdGl2aXR5 DQpvciA8YnI+DQptaXMtY29uZmlndXJhdGlvbiBmb3IgdGhlIExTUD8gPGJyPg0KaW4gYWRkdGlv biwgaWYgaXQgaGFwcGVuIG1pcy1jb25uZWN0aXZpdHksIG1heWJlIG90aGVyIExTUCBwYWNrZXQg YmUgdHJhbnNwb3J0ZWQNCnRvIDxicj4NCnRoZSBNRVAgLCBhbmQgdGhlIG1lcCBwb2ludCB3aWxs IHN0aWxsIExvb3BiYWNrIHRoZSB3cm9uZyBwYWNrZXQgdG8gcGVlcg0KbWVwIHBvaW50LCA8YnI+ DQpjYW4gaXQgYWZmZWN0PC9mb250PjxhIGhyZWY9YXBwOmRzOnBlcmZvcm1hbmNlPjxmb250IHNp emU9MyBjb2xvcj1ibHVlPjx1Pg0KcGVyZm9ybWFuY2U8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+IDwvZm9udD48YSBocmVmPWFwcDpkczpzdGF0aXN0aWNzPjxmb250IHNpemU9MyBjb2xvcj1i bHVlPjx1PnN0YXRpc3RpY3M8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQpvciBtZWFzdXJl bWVudCBvbiB0aGUgcGVlciBtZXAgcG9pbnQ/IDxicj4NCjxicj4NCkIuUi4gPGJyPg0KbGl1IDxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxiPjxicj4NCkxvYSBBbmRlcnNzb24g Jmx0O2xvYUBwaS5udSZndDs8L2I+IDxicj4NCsK3wqLCvMO+w4jDizogJm5ic3A7bXBscy1ib3Vu Y2VzQGlldGYub3JnIDxicj4NCjxicj4NCjIwMTEtMDUtMTAgMjM6NDMgPC9mb250Pg0KPGRpdiBh bGlnbj1yaWdodD4NCjxicj48Zm9udCBzaXplPTM+w4rDlcK8w77DiMOLPC9mb250PjwvZGl2Pg0K PGJyPjxmb250IHNpemU9Mz4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYu b3JnJmd0OyA8L2ZvbnQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pg0KPGJyPjxmb250IHNpemU9Mz7Cs8Kt w4vDjTwvZm9udD48L2Rpdj4NCjxicj48Zm9udCBzaXplPTM+Um9zcyBDYWxsb24gJmx0O3JjYWxs b25AanVuaXBlci5uZXQmZ3Q7LCBNUExTLVRQIGFkIGhvYw0KdGVhbSAmbHQ7YWhtcGxzLXRwQGxp c3RzLml0dS5pbnQmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGJAdG9vbHMuaWV0Zi5vcmcN CjwvZm9udD4NCjxkaXYgYWxpZ249cmlnaHQ+DQo8YnI+PGZvbnQgc2l6ZT0zPsOWw7fDjMOiPC9m b250PjwvZGl2Pg0KPGJyPjxmb250IHNpemU9Mz5bbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNh bGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiLTAxLnR4dA0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KV29ya2luZyBHcm91cCw8L3R0Pjwv Zm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KdGhp cyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPC90dD48 L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NCmRy YWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQ8L3R0PjwvZm9udD48Zm9udCBzaXplPTM+PGJy Pg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbXBsc0BpZXRmLm9yZyBtYWlsaW5nIGxpc3QuPC90dD48L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PHR0Pjxicj4NClRoaXMgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgZW5kcyBvbiBNYXkgMjV0aC48L3R0PjwvZm9udD48Zm9udCBzaXplPTM+PGJy Pg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KL0xvYTwvdHQ+PC9mb250Pjxmb250IHNp emU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQpmb3IgdGhlIG1wbHMgd2cg Y28tY2hhaXJzPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXpl PTM+PHR0Pjxicj4NCi0tIDwvdHQ+PC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQpMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJh dGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmljc3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAgNzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICs0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFp bGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBjb2xv cj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90dD48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0 Pjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvdT48L3R0Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5aVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkDQppbiB0 aGlzPGJyPg0KbWFpbDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5pcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcw0KbWFpbDxicj4NCmNvbW11bmljYXRpb248L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+aXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQNCnRvIG1h aW50YWluPGJyPg0Kc2VjcmVjeTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5hbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mDQp0aGlzIGNvbW11bmljYXRpb248YnI+DQp0bzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0 dD5vdGhlcnMuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+PHR0PlRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWw8YnI+DQphbmQ8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+aW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eQ0KdG8gd2hvbSB0aGV5PGJy Pg0KYXJlPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+PHR0PmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvcg0KcGxlYXNlIG5vdGlmeTxicj4NCnRoZTwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5vcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluDQp0aGlzIG1lc3NhZ2UgYXJlPGJy Pg0KdGhvc2U8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz48dHQ+b2YgdGhlIGluZGl2aWR1YWw8YnI+DQpzZW5kZXIuPC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0 PlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtDQpieSBa VEU8YnI+DQpBbnRpLVNwYW08L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+c3lzdGVtLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0009D5DC4825788F_=-- From stbryant@cisco.com Fri May 13 03:15:17 2011 Return-Path: <stbryant@cisco.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 87150E0744 for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 03:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 F9oERc22+tmx for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 03:15:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 69BA0E0731 for <mpls@ietf.org>; Fri, 13 May 2011 03:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1329; q=dns/txt; s=iport; t=1305281716; x=1306491316; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Us8z6ODvWKft8isK1yIdVSFfi8Qd1sv2Q6JItjjeo9E=; b=BwW7ZKQdap+QPM5BAAba54Cfu9mgMaMM9+5Hk7YwwwVwFugP+aIkBfaA 1JiJ9L8l/357R/oCCmeR16L35tkuoubPV46ByuhzFPNYBMH71LQoiWBeU gpkFEYmb8l3uol7IK3zTJw5dQOQQf7OAdxgvvVQNRHNwZoip9s9LqPnOu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIFAH8EzU2Q/khLgWdsb2JhbACEVZMsjgAUAQEWJiWoS4J5DwGJepEghQ6BBwSQBo5z X-IronPort-AV: E=Sophos;i="4.64,363,1301875200"; d="scan'208,217";a="88325791" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 May 2011 10:15:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4DAFFmK011653; Fri, 13 May 2011 10:15:15 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4DAFDU21484; Fri, 13 May 2011 11:15:13 +0100 (BST) Message-ID: <4DCD04B1.4070405@cisco.com> Date: Fri, 13 May 2011 11:15:13 +0100 From: Stewart Bryant <stbryant@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <4DCB93DB.3070900@cisco.com> <201105130136.p4D1aune035715@mse02.zte.com.cn> <6D3D47CB84BDE349BC23BF1C94E316E4402434E016@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4402434E016@EMV62-UKRD.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------090800020205090605090501" Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG <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: Fri, 13 May 2011 10:15:17 -0000 This is a multi-part message in MIME format. --------------090800020205090605090501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit It therefore only really makes sense to use OAM of a request/response nature, such as loopback, on co-ps mode connections where one assumes there is no misconnectivity defect, eg to do RTD measurements say. Neil I agree with you on this. Stewart --------------090800020205090605090501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <span style="font-family: "Verdana","sans-serif"; color: rgb(99, 36, 35);">It therefore only really makes sense to use OAM of a request/response nature, such as loopback, on co-ps mode connections where one assumes there is no misconnectivity defect, eg to do RTD measurements say.<br> <br> Neil<br> <br> I agree with you on this.<br> <br> Stewart<br> <br> <o:p></o:p></span> </body> </html> --------------090800020205090605090501-- From bruno.decraene@orange-ftgroup.com Fri May 13 06:01:36 2011 Return-Path: <bruno.decraene@orange-ftgroup.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 602EDE06EE for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 06:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, 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 Bb7mIP9NRIJF for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 06:01:35 -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 829BEE06B0 for <mpls@ietf.org>; Fri, 13 May 2011 06:01:35 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A19D85802A; Fri, 13 May 2011 15:08:25 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B93C68580C6; Fri, 13 May 2011 15:01:56 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 14:55:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2011 14:55:04 +0200 Message-ID: <FE8F6A65A433A744964C65B6EDFDC2400230BDD3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <BANLkTinVCMJCEvAGY059N7O=jEfVYoWNJA@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-leymann-mpls-seamless-mpls-03 - Query 1) LDP DoD on AN, 2) IGP on AN, 3) MPLS L3 VPN on AN Thread-Index: AcwNUbrjRVPslv9PSByJZ0DnERFfLQEF669w References: <BANLkTinpkBJDYDR4mMzVHC9V13U9F8JGog@mail.gmail.com> <BANLkTinVCMJCEvAGY059N7O=jEfVYoWNJA@mail.gmail.com> From: <bruno.decraene@orange-ftgroup.com> To: <krbalaji.in@gmail.com>, <mpls@ietf.org> X-OriginalArrivalTime: 13 May 2011 12:55:05.0594 (UTC) FILETIME=[FB3A3DA0:01CC116C] Subject: Re: [mpls] draft-leymann-mpls-seamless-mpls-03 - Query 1) LDP DoD on AN, 2) IGP on AN, 3) MPLS L3 VPN on AN 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: Fri, 13 May 2011 13:01:36 -0000 Hi, Thanks for your interest and comments. More inline. >From: Balaji KR > >Hi, > >Query-1: >I am currently referring to this draft for identifying best way to = design a Converged Transport >Network. The mail limitations comes, when positioning AN nodes at = Access where most of the products >are capable to hold shared 8K routes (global routing, VRF routing etc). > >Considering LDP DoD, while AN send DoD request to AG nodes; AN must = have routing information of Remote >AN before or after that particular LDP DoD - if there is a service = needs to be enabled for remote AN. >This is for Business service enabling case-2. > >I am unclear on how this will happen as per draft. Might be I am not = understood the LDP DoD procedure >- like /32 prefix not required to make LSP between AN's or while LDP = DoD request will populate /32 in >the routing table automatically... On the AN, you can either provision the /32 static IP route or use an = aggregated / default route as per RFC 5283. Cf =A7 "5.1.5. Access" of = the draft. (As a reminder, RFC 5283 relax the need for LDP to find in the RIB an = exact match for the FEC.) >Query-2: >There are cases, service providers planned to have multiple ANs in ring = connects ring end to any two >AGN1x node. This will surely need a IGP (like OSPF), for dynamic = routing nature. >This means, we should have a controlled redistribution of Remote AN = networks into AN ring IGP - so >required /32 prefix only will be able in the RIB. That's indeed an option. Another would be for the AGN1x to advertise an aggregate / default route = in the IGP of the AN rings and enable RFC 5283 on AN. In that case, an = AN can dynamically setup MPLS LSP using LDP DoD with no need to request = / change anything in the IGP. >I was thinking of, why AN IGP can request for a /32 prefix update from = AGN1x either automatically >while a services needs to be enabled between Local AN and Remote AN at = another Domain. >Or >The provisioning tool need to have a option to update Control = Redistribution prefix-list/access-list >as and when Services are enabled between local AN and Remote AN. > >Query-3: >Please note, I have not found this draft is discussed how we can enable = MPLS L3 VPN between local and >remote AN's. Or as per this draft, AN is only positioned for PW = services? This draft mostly focus on setting up the MPLS LSP. MPLS services using = these LSP are not discussed in details. They are not restricted to PW = services. E.g. "=A73 Requirements" refers to L3 VPN, =A7 "2.3. Use Case = #2" refers to 6PE. >MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the = size of VRF table. In case >multiple spoke need to communicate between, regional AN's L3 VPN can = receive one/two default routes >from a central location (part of same regional VRF), and there should = be a routing nodes to enable >interconnecting regional VPN's. Regards, Bruno > >Regards, > >Balaji K R > > > > > > > From internet-drafts@ietf.org Fri May 13 07:47:17 2011 Return-Path: <internet-drafts@ietf.org> 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 CA250E06EE; Fri, 13 May 2011 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 oAR5DlIX2umC; Fri, 13 May 2011 07:47:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F12E065A; Fri, 13 May 2011 07:47:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513144717.20353.34762.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 07:47:17 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-iana-01.txt 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: Fri, 13 May 2011 14:47:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Label Distribution Protocol (LDP) Internet Assigned Numb= ers Authority (IANA) Considerations Update Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-iana-01.txt Pages : 5 Date : 2011-05-13 This document augments the Internet Assigned Numbers Authority (IANA) considerations for the Label Distribution Protocol (LDP), for protocol fields that are Reserved in the LDP Specification but for which there are no IANA allocation policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-iana-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-iana-01.txt From internet-drafts@ietf.org Fri May 13 07:47:19 2011 Return-Path: <internet-drafts@ietf.org> 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 D70A1E076B; Fri, 13 May 2011 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 DR77ZRXM+lKH; Fri, 13 May 2011 07:47:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7AE065A; Fri, 13 May 2011 07:47:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513144719.20353.3234.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 07:47:19 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-03.txt 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: Fri, 13 May 2011 14:47:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Updates to LDP for IPv6 Author(s) : Vishwas Manral Rajiv Papneja Rajiv Asati Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-03.txt Pages : 13 Date : 2011-05-13 The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-03.txt From Internet-Drafts@ietf.org Fri May 13 09:45:03 2011 Return-Path: <Internet-Drafts@ietf.org> 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 33647E06BE; Fri, 13 May 2011 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 606nfNoG620C; Fri, 13 May 2011 09:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3CE07DD; Fri, 13 May 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.54 Message-ID: <20110513164502.20462.91773.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 09:45:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt 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: Fri, 13 May 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 : Mechanism for performing LSP-Ping over MPLS tunnels Author(s) : N. Bahadur, et al. Filename : draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt Pages : 23 Date : 2011-05-13 This document describes methods for performing LSP Ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS label-switched-paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for a LSP that goes over other MPLS tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-13093542.I-D@ietf.org> --NextPart-- From carloss@cisco.com Fri May 13 14:31:23 2011 Return-Path: <carloss@cisco.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 94A8FE07E4 for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 14:31:23 -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 5x+GP-u9ytbu for <mpls@ietfa.amsl.com>; Fri, 13 May 2011 14:31:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 00687E07CC for <mpls@ietf.org>; Fri, 13 May 2011 14:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=carloss@cisco.com; l=1113; q=dns/txt; s=iport; t=1305322282; x=1306531882; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7wHNmZ5IT8d4/YsoKz8ES5K1a9IYP98e2lxqdRl0G90=; b=hfKf8Tyg9BedVjWm7JdQwB40mPco62ktao7/dN9FobSjWbmXPX+56rNv jsCITxv3fI/pmJGTvZtpd+swGG0UjvrbYMQuwhCsP6dDMvrMR6t9eeqYj +NgTjx5+TNvpJr/K/wrpoYV0zPxkfhDZxXcLaeoZS+Hdi3wp6HdmDUPWw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIIAMqhzU2tJXHB/2dsb2JhbACYDo4Bd6c3nXyGFQSGTY1xilg X-IronPort-AV: E=Sophos;i="4.64,366,1301875200"; d="scan'208";a="285054225" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 13 May 2011 21:31:22 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4DLVMYX017779 for <mpls@ietf.org>; Fri, 13 May 2011 21:31:22 GMT Received: from xmb-rcd-208.cisco.com ([72.163.62.215]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 16:31:21 -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, 13 May 2011 16:31:21 -0500 Message-ID: <790790B0CD472040A317184A2410679904233C01@XMB-RCD-208.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C04EACE4D@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwQxnSY7GIMnfpFSFymkIIgJlAAdgA7m4Ag References: <067E6CE33034954AAC05C9EC85E2577C04EACE4D@XMB-RCD-111.cisco.com> From: "Carlos Sanchez (carloss)" <carloss@cisco.com> To: <mpls@ietf.org> X-OriginalArrivalTime: 13 May 2011 21:31:21.0670 (UTC) FILETIME=[1A685660:01CC11B5] Subject: Re: [mpls] Fwd: 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 <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: Fri, 13 May 2011 21:36:34 -0000 yes/support -------- Original Message -------- Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Date: Sat, 30 Apr 2011 10:55:56 -0700 From: Loa Andersson <loa@pi.nu> <mailto:loa@pi.nu>=20 To: mpls@ietf.org <mpls@ietf.org> <mailto:mpls@ietf.org>=20 CC: Ross Callon <rcallon@juniper.net> <mailto:rcallon@juniper.net> ,=20 draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org 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 -- From loa@pi.nu Sun May 15 11:37:30 2011 Return-Path: <loa@pi.nu> 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 709E3E06D8 for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 11:37:30 -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 oNvjws-MxJFa for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 11:37:30 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D13CDE06AF for <mpls@ietf.org>; Sun, 15 May 2011 11:37:29 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 7FFC22A8001; Sun, 15 May 2011 20:37:26 +0200 (CEST) Message-ID: <4DD01D5F.1080100@pi.nu> Date: Sun, 15 May 2011 20:37:19 +0200 From: Loa Andersson <loa@pi.nu> 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" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, draft-fang-mpls-tp-security-framework@tools.ietf.org Subject: [mpls] poll on draft-fang-mpls-tp-security-framework-05.txt 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: Sun, 15 May 2011 18:37:30 -0000 Working Group, this is to start a two week poll on making draft-fang-mpls-tp-security-framework-05.txt 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 on May 30th. /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 lufang@cisco.com Sun May 15 18:31:17 2011 Return-Path: <lufang@cisco.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 93463E06FC for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 18:31:17 -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 skwHuX6i-Nvz for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 18:31:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2289EE06EE for <mpls@ietf.org>; Sun, 15 May 2011 18:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1832; q=dns/txt; s=iport; t=1305509477; x=1306719077; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8ay016wqyVy503p+cO1No+bVZKW/FDPLkPR83QrvgVY=; b=V4Gs5QNUmDnPX+VrgPAGMGp7d16PKYurBRUroBuYIK7LanIsmw8JhUfO 8fSWW6BREj31shG8BMWK95HuCymQou58r0w5DKQSucNlPDVnN5XIvj6fP qE0hP5r3zoP4RpkjwWUMR3FsHkypo/qlFG+3BCdiKzA0NIe2P0Djw8gs/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMh90E2tJXG9/2dsb2JhbACmEneoV5x7AoYXBIZQjXmKWw X-IronPort-AV: E=Sophos;i="4.64,372,1301875200"; d="scan'208";a="357542170" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 16 May 2011 01:31:16 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4G1VGu1019105; Mon, 16 May 2011 01:31:16 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 May 2011 20:31:15 -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, 15 May 2011 20:31:14 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2505B63467@XMB-RCD-201.cisco.com> In-Reply-To: <4DC81575.4020704@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwOZc9GJJtv+U8uS/mtahFqeXwaNgFAw8sg References: <4DC81575.4020704@pi.nu> From: "Luyuan Fang (lufang)" <lufang@cisco.com> To: "Loa Andersson" <loa@pi.nu>, <mpls@ietf.org> X-OriginalArrivalTime: 16 May 2011 01:31:15.0767 (UTC) FILETIME=[F2C8BC70:01CC1368] Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 01:31:17 -0000 Yes/support. Luyuan -------- Original Message -------- Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Date: Sat, 30 Apr 2011 10:55:56 -0700 From: Loa Andersson <loa@pi.nu> To: mpls@ietf.org <mpls@ietf.org> CC: Ross Callon <rcallon@juniper.net>,=20 draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org 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 --=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 --=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 rpiaseck@cisco.com Sun May 15 21:11:19 2011 Return-Path: <rpiaseck@cisco.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 C7B98E0724 for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 21:11: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9aYN942xmXr for <mpls@ietfa.amsl.com>; Sun, 15 May 2011 21:11:18 -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 397DBE071B for <mpls@ietf.org>; Sun, 15 May 2011 21:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rpiaseck@cisco.com; l=2469; q=dns/txt; s=iport; t=1305519078; x=1306728678; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=wpQS0Tq0F4uX6mIhH692F5AyZo+L8795ScO5+pbYYRQ=; b=Z6jwZl8e/IwUrevr6d8fM8Ukv2qW9QuRcIGQd3vO+JSOKqFbHlw6+tEv Tu/QNWdxXcBHdoEr1XbDqWc3IpDM/qDGDb5hUf1HeFnhI/PRfWEOGvyqL 6oKnptFVWkP5olPZnRnCYWY8UyCiLmqhpSoMmcawEux/aeYWL7hfozXgR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAHSj0E2tJV2d/2dsb2JhbACYC44Hd6cXgR2dDQKDLIJrBJARhDiKWQ X-IronPort-AV: E=Sophos;i="4.64,372,1301875200"; d="scan'208";a="233107475" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 16 May 2011 04:11:13 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4G4BDYB020000 for <mpls@ietf.org>; Mon, 16 May 2011 04:11:13 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 May 2011 23:11:13 -0500 Received: from 10.82.235.80 ([10.82.235.80]) by XMB-RCD-113.cisco.com ([72.163.62.155]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 May 2011 04:11:13 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 16 May 2011 00:11:12 -0400 From: Rob Piasecki <rpiaseck@cisco.com> To: <mpls@ietf.org> Message-ID: <C9F61C20.AFBF%rpiaseck@cisco.com> Thread-Topic: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwQxnSY7GIMnfpFSFymkIIgJlAAdgCuNX+S In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C04EACE4D@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 May 2011 04:11:13.0056 (UTC) FILETIME=[4B36D200:01CC137F] Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 04:11:19 -0000 Yes/support Robert Piasecki Network Consulting Engineer IP NGN Foundation Practice rpiaseck@cisco.com Phone: +1 919 392 4388 Mobile: +1 703 939 0259 CCIE =AD R&S Cisco Systems, Inc. 7200-12 Kit Creek Road RTP, NC 27709 United States Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by repl= y email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -------- Original Message -------- > Subject: [mpls] Fwd: poll on > draft-asati-pignataro-mpls-ldp-gtsm-01=20 > Date: Mon, 09 May 2011 18:25:25 +0200=20 > From: Loa Andersson <loa@pi.nu> <mailto:loa@pi.nu> =20 > To: mpls@ietf.org <mpls@ietf.org> <mailto:mpls@ietf.org> =20 >=20 >=20 > Working group, >=20 > we have a poll going on this draft, but so far the number of responses > has been low. Can you please review the draft and see if it ready to > become a working group document. >=20 > /Loa >=20 > -------- Original Message -------- > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > Date: Sat, 30 Apr 2011 10:55:56 -0700 > From: Loa Andersson <loa@pi.nu> <mailto:loa@pi.nu> > To: mpls@ietf.org <mpls@ietf.org> <mailto:mpls@ietf.org> > CC: Ross Callon <rcallon@juniper.net> <mailto:rcallon@juniper.net> , > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-gtsm-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 14th. >=20 > /Loa > -- From agmalis@gmail.com Mon May 16 00:35:58 2011 Return-Path: <agmalis@gmail.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 DC87EE070B for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 00:35:58 -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 vrq8jiV+IR0A for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 00:35:58 -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 520C0E0679 for <mpls@ietf.org>; Mon, 16 May 2011 00:35:58 -0700 (PDT) Received: by qyk29 with SMTP id 29so1423885qyk.10 for <mpls@ietf.org>; Mon, 16 May 2011 00:35: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:content-transfer-encoding; bh=CoDQs+vn0BLSfsneYgqEJhjDTzGEvUT309n+M4Z66ww=; b=LgZfcAgOgo80Pw7xsKYiFaz4ffAe6/nFxLTR6FzI2rPToDTJFIkvMl+W2ldA+Sr5Op pzjCR2RSALiFoMXUrIV6BxLqDi0DjwNpY9dxcVCC+xbA8FUsyxcy7YpSx0yF98Klyb4T w/opfLX+5h8r/sBYA8WeYr1bqrHNwAc3J9T9E= 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:content-transfer-encoding; b=TrVF6rF6iWg2FEPAlfpZ9v5OxYWQ13Lb1doJNnk3FSJl3aecMtFuM+Gb+sOK/ZWhww uE+6PuDPcOKlo4yETC9q3AYlwUpHCoHm+70s2iG7rYbV+0MIA4A53dmu2VZDFze2Vxph x7GYBhfyVe/4PNnz3H/0hfoo6B7XCzUtPzlCo= Received: by 10.229.13.210 with SMTP id d18mr2982599qca.76.1305531357378; Mon, 16 May 2011 00:35:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.248.137 with HTTP; Mon, 16 May 2011 00:35:37 -0700 (PDT) In-Reply-To: <4DD01D5F.1080100@pi.nu> References: <4DD01D5F.1080100@pi.nu> From: "Andrew G. Malis" <agmalis@gmail.com> Date: Mon, 16 May 2011 09:35:37 +0200 Message-ID: <BANLkTi=VREGKMA11nEJzeUq+eBfOR5A5Jg@mail.gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-fang-mpls-tp-security-framework@tools.ietf.org Subject: Re: [mpls] poll on draft-fang-mpls-tp-security-framework-05.txt 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: Mon, 16 May 2011 07:35:59 -0000 Loa, I'm confused .... draft-fang-mpls-tp-security-framework-04 was polled on January 25 2011 and accepted on February 9, and subsequently draft-ietf-mpls-tp-security-framework-00.txt was uploaded on February 17. So why was there a -05 on the individual draft, and why is it being re-poll= ed? Thanks, Andy On Sun, May 15, 2011 at 8:37 PM, Loa Andersson <loa@pi.nu> wrote: > Working Group, > > this is to start a two week poll on making > > draft-fang-mpls-tp-security-framework-05.txt > > 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 on May 30th. > > /Loa > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From scott.mansfield@ericsson.com Mon May 16 01:02:40 2011 Return-Path: <scott.mansfield@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 81FC6E06E9 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:02:40 -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 XPkxdI8ZncnF for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:02:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id DDC1EE062B for <mpls@ietf.org>; Mon, 16 May 2011 01:02:39 -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 p4G82YN5009008; Mon, 16 May 2011 03:02:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 16 May 2011 04:02:28 -0400 From: Scott Mansfield <scott.mansfield@ericsson.com> To: "Andrew G. Malis" <agmalis@gmail.com>, Loa Andersson <loa@pi.nu> Date: Mon, 16 May 2011 04:01:33 -0400 Thread-Topic: [mpls] poll on draft-fang-mpls-tp-security-framework-05.txt Thread-Index: AcwTm+754KyYrtSdTeeGbUpYKF99FwAAtw7Q Message-ID: <FDC72027C316A44F82F425284E1C4C320B0F6125E4@EUSAACMS0701.eamcs.ericsson.se> References: <4DD01D5F.1080100@pi.nu> <BANLkTi=VREGKMA11nEJzeUq+eBfOR5A5Jg@mail.gmail.com> In-Reply-To: <BANLkTi=VREGKMA11nEJzeUq+eBfOR5A5Jg@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, "draft-fang-mpls-tp-security-framework@tools.ietf.org" <draft-fang-mpls-tp-security-framework@tools.ietf.org> Subject: Re: [mpls] poll on draft-fang-mpls-tp-security-framework-05.txt 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: Mon, 16 May 2011 08:02:40 -0000 Andy, You are correct. We received a "draft expiration" notice and Luyuan asked = me to spin a new version. I had completely forgotten that we had already c= reated a working group draft for the mpls-tp-security-framework. The only = differences between -04 and -05 (the new one) and the -00 working group dra= ft are related to authors and postal addresses. Regards, -scott.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Andrew G. Malis > Sent: Monday, May 16, 2011 3:36 AM > To: Loa Andersson > Cc: Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team;=20 > draft-fang-mpls-tp-security-framework@tools.ietf.org > Subject: Re: [mpls] poll on=20 > draft-fang-mpls-tp-security-framework-05.txt >=20 > Loa, >=20 > I'm confused .... draft-fang-mpls-tp-security-framework-04=20 > was polled on January 25 2011 and accepted on February 9, and=20 > subsequently draft-ietf-mpls-tp-security-framework-00.txt was=20 > uploaded on February 17. >=20 > So why was there a -05 on the individual draft, and why is it=20 > being re-polled? >=20 > Thanks, > Andy >=20 > On Sun, May 15, 2011 at 8:37 PM, Loa Andersson <loa@pi.nu> wrote: > > Working Group, > > > > this is to start a two week poll on making > > > > draft-fang-mpls-tp-security-framework-05.txt > > > > an mpls working group document. > > > > If you support the document becoming a working group=20 > document please=20 > > respond to this poll with "yes/support" > > > > If you do not support the document becoming a working group=20 > 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=20 > discuss the=20 > > document, please send these comments to the mpls working=20 > group mailing=20 > > list, but with another subject than what is on this mail. > > > > The poll ends on May 30th. > > > > /Loa > > > > -- > > > > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 > > loa.andersson@ericsson.com Sr Strategy and Standards=20 > Manager =A0 =A0 =A0 =A0 =A0 =A0 > > loa@pi.nu Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0phone: +46=20 > 10 717 52=20 > > 13 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 +46 767 72 92 13=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 loa@pi.nu Mon May 16 01:12:33 2011 Return-Path: <loa@pi.nu> 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 CC05FE0679 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twaQvd-62OFX for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:12:33 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id AB716E062B for <mpls@ietf.org>; Mon, 16 May 2011 01:12:31 -0700 (PDT) Received: from [10.154.12.139] (unknown [192.165.126.77]) (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 12B102A8001; Mon, 16 May 2011 10:12:27 +0200 (CEST) Message-ID: <4DD0DC6A.5040506@pi.nu> Date: Mon, 16 May 2011 10:12:26 +0200 From: Loa Andersson <loa@pi.nu> 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: Scott Mansfield <scott.mansfield@ericsson.com> References: <4DD01D5F.1080100@pi.nu> <BANLkTi=VREGKMA11nEJzeUq+eBfOR5A5Jg@mail.gmail.com> <FDC72027C316A44F82F425284E1C4C320B0F6125E4@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <FDC72027C316A44F82F425284E1C4C320B0F6125E4@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, "draft-fang-mpls-tp-security-framework@tools.ietf.org" <draft-fang-mpls-tp-security-framework@tools.ietf.org> Subject: [mpls] CANCELED: Re: [AHMPLS-TP] RE: poll on draft-fang-mpls-tp-security-framework-05.txt 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: Mon, 16 May 2011 08:12:33 -0000 Andy, no you are not confused I am :( ! And you are correct. Tod do this correct! 1. The poll on draft-fang-mpls-tp-security-framework-05.txt is canceled! 2. The authors should work the updates between the working group document version -00 and individual -05 into a new working group draft -01. /Loa On 2011-05-16 10:01, Scott Mansfield wrote: > > Andy, > > You are correct. We received a "draft expiration" notice and Luyuan asked me to spin a new version. I had completely forgotten that we had already created a working group draft for the mpls-tp-security-framework. The only differences between -04 and -05 (the new one) and the -00 working group draft are related to authors and postal addresses. > > Regards, > -scott. > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Andrew G. Malis >> Sent: Monday, May 16, 2011 3:36 AM >> To: Loa Andersson >> Cc: Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team; >> draft-fang-mpls-tp-security-framework@tools.ietf.org >> Subject: Re: [mpls] poll on >> draft-fang-mpls-tp-security-framework-05.txt >> >> Loa, >> >> I'm confused .... draft-fang-mpls-tp-security-framework-04 >> was polled on January 25 2011 and accepted on February 9, and >> subsequently draft-ietf-mpls-tp-security-framework-00.txt was >> uploaded on February 17. >> >> So why was there a -05 on the individual draft, and why is it >> being re-polled? >> >> Thanks, >> Andy >> >> On Sun, May 15, 2011 at 8:37 PM, Loa Andersson<loa@pi.nu> wrote: >>> Working Group, >>> >>> this is to start a two week poll on making >>> >>> draft-fang-mpls-tp-security-framework-05.txt >>> >>> 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 on May 30th. >>> >>> /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 >>> >> _______________________________________________ >> 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 agmalis@gmail.com Mon May 16 01:12:55 2011 Return-Path: <agmalis@gmail.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 EC484E073E for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:12:55 -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 fQO684C3Prue for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:12:55 -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 E8E95E0739 for <mpls@ietf.org>; Mon, 16 May 2011 01:12:54 -0700 (PDT) Received: by qyk29 with SMTP id 29so1440472qyk.10 for <mpls@ietf.org>; Mon, 16 May 2011 01:12:54 -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:content-transfer-encoding; bh=ew/F8upnRBVzttJ1oS0t7SuRPYGS0iiCNord9JLwKT4=; b=uVWT/E9WYks9tEm61whS9G7COr53J56caUFYW6rP+MZUC0LYhJZr3ev7aNLCKx5ZV3 cIFEUHrIaFca+TmLhHAbbmBuoap4Ng0sYexrz1//r8hwNYtFOYtwoUyDIheDYk5KkpvJ udonC18A/Q2RqhWm4n70V+PoY7IUcdwzaJNo0= 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:content-transfer-encoding; b=EAopcEaLRmWeTTTNX1NFRyRHKCjIEM2X7hW2E0KnEpqJYdUMrSQ4mHPJJPliLxQCX5 ChdeMfru4ahXEpi4QqtY9IpMwNm4LOIurupY6DxpU55Opu6ZwKG0nPDfTRd4jTjHFnIq N+a13Z6q+2aHJAuyp8XuY/r/PaJINYbm+WfQQ= Received: by 10.224.135.211 with SMTP id o19mr3187179qat.19.1305533574078; Mon, 16 May 2011 01:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.248.137 with HTTP; Mon, 16 May 2011 01:12:34 -0700 (PDT) In-Reply-To: <FDC72027C316A44F82F425284E1C4C320B0F6125E4@EUSAACMS0701.eamcs.ericsson.se> References: <4DD01D5F.1080100@pi.nu> <BANLkTi=VREGKMA11nEJzeUq+eBfOR5A5Jg@mail.gmail.com> <FDC72027C316A44F82F425284E1C4C320B0F6125E4@EUSAACMS0701.eamcs.ericsson.se> From: "Andrew G. Malis" <agmalis@gmail.com> Date: Mon, 16 May 2011 10:12:34 +0200 Message-ID: <BANLkTi=t65BJfW3yofvEEHqvYZOB_q0-tA@mail.gmail.com> To: Scott Mansfield <scott.mansfield@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "draft-fang-mpls-tp-security-framework@tools.ietf.org" <draft-fang-mpls-tp-security-framework@tools.ietf.org> Subject: Re: [mpls] poll on draft-fang-mpls-tp-security-framework-05.txt 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: Mon, 16 May 2011 08:12:56 -0000 Scott, I would suggest that you update the WG draft to match and ask internet-drafts@ietf.org to remove the individual draft and update the replaced-by information, which is missing on the tools page. Cheers, Andy On Mon, May 16, 2011 at 10:01 AM, Scott Mansfield <scott.mansfield@ericsson.com> wrote: > > Andy, > > You are correct. =A0We received a "draft expiration" notice and Luyuan as= ked me to spin a new version. =A0I had completely forgotten that we had alr= eady created a working group draft for the mpls-tp-security-framework. =A0T= he only differences between -04 and -05 (the new one) and the -00 working g= roup draft are related to authors and postal addresses. > > Regards, > -scott. > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Andrew G. Malis >> Sent: Monday, May 16, 2011 3:36 AM >> To: Loa Andersson >> Cc: Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team; >> draft-fang-mpls-tp-security-framework@tools.ietf.org >> Subject: Re: [mpls] poll on >> draft-fang-mpls-tp-security-framework-05.txt >> >> Loa, >> >> I'm confused .... draft-fang-mpls-tp-security-framework-04 >> was polled on January 25 2011 and accepted on February 9, and >> subsequently draft-ietf-mpls-tp-security-framework-00.txt was >> uploaded on February 17. >> >> So why was there a -05 on the individual draft, and why is it >> being re-polled? >> >> Thanks, >> Andy >> >> On Sun, May 15, 2011 at 8:37 PM, Loa Andersson <loa@pi.nu> wrote: >> > Working Group, >> > >> > this is to start a two week poll on making >> > >> > draft-fang-mpls-tp-security-framework-05.txt >> > >> > 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 on May 30th. >> > >> > /Loa >> > >> > -- >> > >> > >> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: >> > loa.andersson@ericsson.com Sr Strategy and Standards >> Manager >> > loa@pi.nu Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0phone: +46 >> 10 717 52 >> > 13 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13 >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> From agmalis@gmail.com Mon May 16 01:27:23 2011 Return-Path: <agmalis@gmail.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 3A41CE06AB for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:27:23 -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 JSmPXpRGm4w3 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 01:27:21 -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 B7DB1E065D for <mpls@ietf.org>; Mon, 16 May 2011 01:27:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so2877591qwc.31 for <mpls@ietf.org>; Mon, 16 May 2011 01:27:21 -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:content-transfer-encoding; bh=ihYuObjgTXRLIG4m6MUZt1lPzjcaG6qeM/zKpU55hkM=; b=uZ/x1iRg/rqfXVVzJJ8c1T8WAqyELldvdW1NXPo1eeMGXq0DGhknsFbGXJxvBuAm/W E5u8YzLY2yWvZeziHm1guiTVHIGGD3lA/vwJcKXnyhyT6RxoyBpQic9RDtSCLT843iKs wZqS79wBjpyELjEKJSAnbaWcJ7Rl/XWiR98X4= 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:content-transfer-encoding; b=JhSQlawhupgOTs1sO4yftLExycmJ9pHbzFAhd85lQU3420mgrEGAdF5Nyt0D4PbZkp 2UNtdvaGqaRZ25DSac5xg8Oi7Y+oogagWCPgxWuADQ6EGBWPTVBZESzSTdLKnE2dxIds +6sxx2chDsj/Pg1SABU0jELefxej9EzeMeoOQ= Received: by 10.229.141.69 with SMTP id l5mr1860277qcu.225.1305534441127; Mon, 16 May 2011 01:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.248.137 with HTTP; Mon, 16 May 2011 01:27:00 -0700 (PDT) In-Reply-To: <4DC81575.4020704@pi.nu> References: <4DC81575.4020704@pi.nu> From: "Andrew G. Malis" <agmalis@gmail.com> Date: Mon, 16 May 2011 10:27:00 +0200 Message-ID: <BANLkTimz7C_EOuOON2BQzqCHm-bHEbr0+Q@mail.gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 08:27:23 -0000 I support. Cheers, Andy On Mon, May 9, 2011 at 6:25 PM, Loa Andersson <loa@pi.nu> wrote: > Working group, > > we have a poll going on this draft, but so far the number of responses > has been low. Can you please review the draft and see if it ready to > become a working group document. > > /Loa > > -------- Original Message -------- > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > Date: Sat, 30 Apr 2011 10:55:56 -0700 > From: Loa Andersson <loa@pi.nu> > To: mpls@ietf.org <mpls@ietf.org> > CC: Ross Callon <rcallon@juniper.net>, > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org > > > 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From internet-drafts@ietf.org Mon May 16 01:49:27 2011 Return-Path: <internet-drafts@ietf.org> 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 7CC7EE075C; Mon, 16 May 2011 01:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 71+jCVMCTL5R; Mon, 16 May 2011 01:49:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14850E070B; Mon, 16 May 2011 01:49:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516084927.9828.5472.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 01:49:27 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-01.txt 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: Mon, 16 May 2011 08:49:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Filename : draft-ietf-mpls-tp-security-framework-01.txt Pages : 25 Date : 2011-05-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. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0= 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-01= .txt From verozheng@huawei.com Mon May 16 02:52:06 2011 Return-Path: <verozheng@huawei.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 43303E06BD for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 02:52:06 -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 aA9ZPGLrnh5P for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 02:52:05 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7A41AE06AC for <mpls@ietf.org>; Mon, 16 May 2011 02:52:05 -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 <0LLA00MN68QOUF@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 16 May 2011 17:52:00 +0800 (CST) Received: from Z50128Z ([10.110.98.58]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLA005148QI6Q@szxga05-in.huawei.com> for mpls@ietf.org; Mon, 16 May 2011 17:52:00 +0800 (CST) Date: Mon, 16 May 2011 17:51:54 +0800 From: Vero Zheng <verozheng@huawei.com> In-reply-to: <4DC81575.4020704@pi.nu> To: 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org Message-id: <005301cc13ae$e4299770$ac7cc650$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcwOZp7E2pbZG/4kQhOnwIBR1YeUXAFRlC/g References: <4DC81575.4020704@pi.nu> Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 09:52:06 -0000 I support the working group looking into the LDP Hello security problem. GTSM is only good for one hop, thus can protect the Basic Hello to some extent. But the Remote Hello is relatively more vulnerable to attacks and deserves security mechanisms. Draft-zheng-mpls-ldp-hello-crypto-auth (http://tools.ietf.org/html/draft-zheng-mpls-ldp-hello-crypto-auth-01 ) introduces a optional Cryptographic Authentication TLV which is used in LDP Hello message against spoofing attack, and an LSR can be configured to only accept Hello messages from specific peers when authentication is in use. We believe it's simple, it's backward compatible and it's secure. We would like ask the WG to read the draft and give constructive comments. BR, Vero > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Tuesday, May 10, 2011 12:25 AM > To: mpls@ietf.org > Subject: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > > Working group, > > we have a poll going on this draft, but so far the number of responses > has been low. Can you please review the draft and see if it ready to > become a working group document. > > /Loa > > -------- Original Message -------- > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > Date: Sat, 30 Apr 2011 10:55:56 -0700 > From: Loa Andersson <loa@pi.nu> > To: mpls@ietf.org <mpls@ietf.org> > CC: Ross Callon <rcallon@juniper.net>, > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org > > > 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 > _______________________________________________ > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Mon May 16 05:53:01 2011 Return-Path: <cpignata@cisco.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 58319E06A1 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 05:53:01 -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=[AWL=0.000, 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 ubVCJs9UC6XO for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 05:52:57 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9185FE06A2 for <mpls@ietf.org>; Mon, 16 May 2011 05:52:57 -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 p4GCqqe4025009; Mon, 16 May 2011 08:52:52 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4GCqnv1004409; Mon, 16 May 2011 08:52:51 -0400 (EDT) Message-ID: <4DD11E21.1030607@cisco.com> Date: Mon, 16 May 2011 08:52:49 -0400 From: Carlos Pignataro <cpignata@cisco.com> 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: Vero Zheng <verozheng@huawei.com> References: <4DC81575.4020704@pi.nu> <005301cc13ae$e4299770$ac7cc650$@com> In-Reply-To: <005301cc13ae$e4299770$ac7cc650$@com> 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: mpls@ietf.org Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 12:53:01 -0000 Hi Vero, Please find one technical comment inline. On 5/16/2011 5:51 AM, Vero Zheng wrote: > I support the working group looking into the LDP Hello security problem. > GTSM is only good for one hop, thus can protect the Basic Hello to some > extent. But the Remote Hello is relatively more vulnerable to attacks and > deserves security mechanisms. > > Draft-zheng-mpls-ldp-hello-crypto-auth > (http://tools.ietf.org/html/draft-zheng-mpls-ldp-hello-crypto-auth-01 ) > introduces a optional Cryptographic Authentication TLV which is used in LDP One quote from <http://tools.ietf.org/html/rfc5082>: In particular, while cryptographic techniques can protect the router- based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note So the techniques in this I-D are based on a high protection ROI (cheap check, strong protection) for a given set of scenarios only. And: Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets from outside the network. Note, however, that GTSM is not a substitute for authentication mechanisms. Thanks, -- Carlos. > Hello message against spoofing attack, and an LSR can be configured to only > accept Hello messages from specific peers when authentication is in use. We > believe it's simple, it's backward compatible and it's secure. We would like > ask the WG to read the draft and give constructive comments. > > BR, > Vero > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa >> Andersson >> Sent: Tuesday, May 10, 2011 12:25 AM >> To: mpls@ietf.org >> Subject: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >> >> Working group, >> >> we have a poll going on this draft, but so far the number of responses >> has been low. Can you please review the draft and see if it ready to >> become a working group document. >> >> /Loa >> >> -------- Original Message -------- >> Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >> Date: Sat, 30 Apr 2011 10:55:56 -0700 >> From: Loa Andersson <loa@pi.nu> >> To: mpls@ietf.org <mpls@ietf.org> >> CC: Ross Callon <rcallon@juniper.net>, >> draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org >> >> >> 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 >> _______________________________________________ >> 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 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From cpignata@cisco.com Mon May 16 06:05:25 2011 Return-Path: <cpignata@cisco.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 B694CE0772 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 06:05: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=[AWL=0.000, 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 Pc52aOI0TN+E for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 06:05:25 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 016D5E06A4 for <mpls@ietf.org>; Mon, 16 May 2011 06:05:24 -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 p4GD5MTr026238; Mon, 16 May 2011 09:05:22 -0400 (EDT) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4GD5Mu1015011; Mon, 16 May 2011 09:05:22 -0400 (EDT) Message-ID: <4DD12111.3090709@cisco.com> Date: Mon, 16 May 2011 09:05:21 -0400 From: Carlos Pignataro <cpignata@cisco.com> 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: Vero Zheng <verozheng@huawei.com> References: <4DC81575.4020704@pi.nu> <005301cc13ae$e4299770$ac7cc650$@com> <4DD11E21.1030607@cisco.com> In-Reply-To: <4DD11E21.1030607@cisco.com> 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: mpls@ietf.org Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 13:05:25 -0000 On 5/16/2011 8:52 AM, Carlos Pignataro wrote: > Hi Vero, > > Please find one technical comment inline. > > On 5/16/2011 5:51 AM, Vero Zheng wrote: >> I support the working group looking into the LDP Hello security problem. >> GTSM is only good for one hop, thus can protect the Basic Hello to some >> extent. But the Remote Hello is relatively more vulnerable to attacks and >> deserves security mechanisms. >> >> Draft-zheng-mpls-ldp-hello-crypto-auth >> (http://tools.ietf.org/html/draft-zheng-mpls-ldp-hello-crypto-auth-01 ) >> introduces a optional Cryptographic Authentication TLV which is used in LDP > > One quote from <http://tools.ietf.org/html/rfc5082>: > > In particular, while cryptographic techniques can protect the router- > based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide > variety of attacks, many attacks based on CPU overload can be > prevented by the simple mechanism described in this document. Note > > So the techniques in this I-D are based on a high protection ROI (cheap > check, strong protection) for a given set of scenarios only. And: > > Since TTL spoofing is considered nearly > impossible, a mechanism based on an expected TTL value can provide a > simple and reasonably robust defense from infrastructure attacks > based on forged protocol packets from outside the network. Note, > however, that GTSM is not a substitute for authentication mechanisms. > [sorry inadvertently hit Send, meant to add:] So this provides complementary (and orthogonal) security protection where, conversely, cryptographic mechanisms are not substitute for GTSM for where it is applicable. Thanks, -- Carlos. > Thanks, > > -- Carlos. > >> Hello message against spoofing attack, and an LSR can be configured to only >> accept Hello messages from specific peers when authentication is in use. We >> believe it's simple, it's backward compatible and it's secure. We would like >> ask the WG to read the draft and give constructive comments. >> >> BR, >> Vero >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Loa >>> Andersson >>> Sent: Tuesday, May 10, 2011 12:25 AM >>> To: mpls@ietf.org >>> Subject: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >>> >>> Working group, >>> >>> we have a poll going on this draft, but so far the number of responses >>> has been low. Can you please review the draft and see if it ready to >>> become a working group document. >>> >>> /Loa >>> >>> -------- Original Message -------- >>> Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >>> Date: Sat, 30 Apr 2011 10:55:56 -0700 >>> From: Loa Andersson <loa@pi.nu> >>> To: mpls@ietf.org <mpls@ietf.org> >>> CC: Ross Callon <rcallon@juniper.net>, >>> draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org >>> >>> >>> 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 >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> 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 rpapneja@isocore.com Mon May 16 07:06:31 2011 Return-Path: <rpapneja@isocore.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 D498EE06B1 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ0I29MSrvui for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 07:06:31 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65FE067E for <mpls@ietf.org>; Mon, 16 May 2011 07:06:30 -0700 (PDT) Received: from [65.213.193.38] (helo=adminPCR) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.69) (envelope-from <rpapneja@isocore.com>) id 1QLyRJ-0002xQ-Qe; Mon, 16 May 2011 10:06:29 -0400 From: "Rajiv Papneja" <rpapneja@isocore.com> To: "'Loa Andersson'" <loa@pi.nu> References: <4DC81575.4020704@pi.nu> <BANLkTimz7C_EOuOON2BQzqCHm-bHEbr0+Q@mail.gmail.com> In-Reply-To: <BANLkTimz7C_EOuOON2BQzqCHm-bHEbr0+Q@mail.gmail.com> Date: Mon, 16 May 2011 10:06:06 -0400 Message-ID: <0bc201cc13d2$6616ec60$3244c520$@isocore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDvoDGFBYHyQBD0caXGfa9Ii7DJLwJVmXH5ljW3aGA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Cc: mpls@ietf.org Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 14:06:31 -0000 Yes/Support. /Rajiv > > -------- Original Message -------- > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > Date: Sat, 30 Apr 2011 10:55:56 -0700 > From: Loa Andersson <loa@pi.nu> > To: mpls@ietf.org <mpls@ietf.org> > CC: Ross Callon <rcallon@juniper.net>,=20 > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org > > > 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=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 = > 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 > loa.andersson@ericsson.com Sr Strategy and Standards Manager =A0 =A0 = =A0 =A0 =A0 =A0 > loa@pi.nu Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0phone: +46 10 717 52=20 > 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 > loa.andersson@ericsson.com Sr Strategy and Standards Manager =A0 =A0 = =A0 =A0 =A0 =A0 > loa@pi.nu Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0phone: +46 10 717 52=20 > 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13=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 vishwas.ietf@gmail.com Mon May 16 11:57:52 2011 Return-Path: <vishwas.ietf@gmail.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 4874FE07A3 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2etSpLtOcKW for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 11:57:51 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7A420E07AA for <mpls@ietf.org>; Mon, 16 May 2011 11:57:31 -0700 (PDT) Received: by wwk4 with SMTP id 4so2895399wwk.1 for <mpls@ietf.org>; Mon, 16 May 2011 11:57:30 -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=hszHVST66thOvQ4GAa5xhCx1eqn3ZgzdBVjv/t5gcSA=; b=Uti9ZFnjBdF5d/9Tbv8Jocsj2jpweyyPj1v9X1cB9bVEHNx3RjsAafs3k0vm+GeKRc dQghCa28VL0dzTEimHYIZDqH+K2CTwtJozFt4WC/IN0yQCpSbseUe9k4tYdv8uEVuld5 qNy6ip8KWd3uUGih1b4FjnrirpHOMvNny3e4k= 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=koH6qTFej4ALyq8Ynaj5rzmNwqSWocHEzcL1wh7r6+uBASvia/Y5W38PVNB9sC0OBr L4s+lNgrexd/h2hClnTpRiZLaxg4f4XD1lRHZ2u6/YqlMLD7yfroFLZEuW1iuWYlAKNH xGlHb2FGSs6MRLWAudgqn025ccXNtcODMAENY= MIME-Version: 1.0 Received: by 10.216.236.157 with SMTP id w29mr2833752weq.18.1305572250086; Mon, 16 May 2011 11:57:30 -0700 (PDT) Received: by 10.216.85.198 with HTTP; Mon, 16 May 2011 11:57:29 -0700 (PDT) In-Reply-To: <0bc201cc13d2$6616ec60$3244c520$@isocore.com> References: <4DC81575.4020704@pi.nu> <BANLkTimz7C_EOuOON2BQzqCHm-bHEbr0+Q@mail.gmail.com> <0bc201cc13d2$6616ec60$3244c520$@isocore.com> Date: Mon, 16 May 2011 11:57:29 -0700 Message-ID: <BANLkTi=JQ1K8ercQ-Z2aHrDpLEdRr8s7Hw@mail.gmail.com> From: Vishwas Manral <vishwas.ietf@gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: multipart/alternative; boundary=000e0cd4849e31ef0004a3693ae5 Cc: mpls@ietf.org Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 18:57:52 -0000 --000e0cd4849e31ef0004a3693ae5 Content-Type: text/plain; charset=ISO-8859-1 Support. -Vishwas On Mon, May 16, 2011 at 7:06 AM, Rajiv Papneja <rpapneja@isocore.com> wrote: > Yes/Support. > > /Rajiv > > > > -------- Original Message -------- > > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > > Date: Sat, 30 Apr 2011 10:55:56 -0700 > > From: Loa Andersson <loa@pi.nu> > > To: mpls@ietf.org <mpls@ietf.org> > > CC: Ross Callon <rcallon@juniper.net>, > > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org > > > > > > 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 > > _______________________________________________ > > 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 > > _______________________________________________ > > 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 > --000e0cd4849e31ef0004a3693ae5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Support.</div> <div>=A0</div> <div>-Vishwas<br><br></div> <div class=3D"gmail_quote">On Mon, May 16, 2011 at 7:06 AM, Rajiv Papneja <= span dir=3D"ltr"><<a href=3D"mailto:rpapneja@isocore.com">rpapneja@isoco= re.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Yes/Support.<br><font color=3D"#= 888888"><br>/Rajiv<br></font> <div> <div></div> <div class=3D"h5">><br>> -------- Original Message --------<br>> S= ubject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01<br>> Date:= Sat, 30 Apr 2011 10:55:56 -0700<br>> From: Loa Andersson <<a href=3D= "mailto:loa@pi.nu">loa@pi.nu</a>><br> > To: <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a> <<a href=3D"= mailto:mpls@ietf.org">mpls@ietf.org</a>><br>> CC: Ross Callon <<a = href=3D"mailto:rcallon@juniper.net">rcallon@juniper.net</a>>,<br>> <a= href=3D"mailto:draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org">draft-a= sati-pignataro-mpls-ldp-gtsm@tools.ietf.org</a><br> ><br>><br>> Working Group,<br>><br>> this is to start a two = week poll on making<br>><br>> draft-asati-pignataro-mpls-ldp-gtsm-01<= br>><br>> an mpls working group document.<br>><br>> If you supp= ort the document becoming a working group document please<br> > respond to this poll with "yes/support"<br>><br>> If y= ou do not support the document becoming a working group document<br>> pl= ease respond to this poll with "no/do not support"<br>> and at= the same time give the technical reasons why you are not<br> > supporting the document.<br>><br>> If you have technical comment= s or in any other way want to discuss the<br>> document, please send the= se comments to the mpls working group mailing<br>> list, but with anothe= r subject than what is on this mail.<br> ><br>> The poll ends May 14th.<br>><br>> /Loa<br>> --<br>>= ;<br>><br>> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 email:<br>> <a href=3D"mailto:loa.andersson@ericsson.com">loa.ander= sson@ericsson.com</a> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0= =A0<br> > <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a> Ericsson Inc =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 10 717 52<br>> 13<br>&= gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 <a href=3D"tel:%2B46%20767%2072%2092%2013" value=3D"+46767= 729213">+46 767 72 92 13</a><br> > _______________________________________________<br>> mpls mailing l= ist<br>> <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br>> <a h= ref=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">https:= //www.ietf.org/mailman/listinfo/mpls</a><br> ><br>> --<br>><br>><br>> Loa Andersson =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:<br>> <a href=3D"mailto:loa.andersson@= ericsson.com">loa.andersson@ericsson.com</a> Sr Strategy and Standards Mana= ger =A0 =A0 =A0 =A0 =A0 =A0<br>> <a href=3D"mailto:loa@pi.nu">loa@pi.nu<= /a> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: = +46 10 717 52<br> > 13<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"tel:%2B46%20767%2072%2092%2013" val= ue=3D"+46767729213">+46 767 72 92 13</a><br>> __________________________= _____________________<br>> mpls mailing list<br> > <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br>> <a href=3D"= https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">https://www.i= etf.org/mailman/listinfo/mpls</a><br>><br>______________________________= _________________<br> mpls mailing list<br><a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br>= <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br><br><br>___________________= ____________________________<br> mpls mailing list<br><a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br>= <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br></div></div></blockquote></= div> <br> --000e0cd4849e31ef0004a3693ae5-- From gregory.mirsky@ericsson.com Mon May 16 11:59:12 2011 Return-Path: <gregory.mirsky@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 E8129E07A7 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 11:59:12 -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 0YUrw4IHEe1s for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 11:59:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2BE0793 for <mpls@ietf.org>; Mon, 16 May 2011 11:59:02 -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 p4GIx0s5029421 for <mpls@ietf.org>; Mon, 16 May 2011 13:59:02 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 16 May 2011 14:58:56 -0400 From: Gregory Mirsky <gregory.mirsky@ericsson.com> To: "mpls@ietf.org" <mpls@ietf.org> Date: Mon, 16 May 2011 14:58:55 -0400 Thread-Topic: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwOZp7E2pbZG/4kQhOnwIBR1YeUXAFRlC/gABORiCA= Message-ID: <FE60A4E52763E84B935532D7D9294FF1218E5335E8@EUSAACMS0715.eamcs.ericsson.se> References: <4DC81575.4020704@pi.nu> <005301cc13ae$e4299770$ac7cc650$@com> In-Reply-To: <005301cc13ae$e4299770$ac7cc650$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Fwd: 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 <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: Mon, 16 May 2011 18:59:13 -0000 Yes/support Regards, Greg > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Loa > Andersson > Sent: Tuesday, May 10, 2011 12:25 AM > To: mpls@ietf.org > Subject: [mpls] Fwd: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 >=20 > Working group, >=20 > we have a poll going on this draft, but so far the number of responses=20 > has been low. Can you please review the draft and see if it ready to=20 > become a working group document. >=20 > /Loa >=20 > -------- Original Message -------- > Subject: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 > Date: Sat, 30 Apr 2011 10:55:56 -0700 > From: Loa Andersson <loa@pi.nu> > To: mpls@ietf.org <mpls@ietf.org> > CC: Ross Callon <rcallon@juniper.net>,=20 > draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org >=20 >=20 > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-asati-pignataro-mpls-ldp-gtsm-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 14th. >=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=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > -- >=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=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 iesg-secretary@ietf.org Mon May 16 12:04:45 2011 Return-Path: <iesg-secretary@ietf.org> 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 E3470E07B9; Mon, 16 May 2011 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 fzc0yjNkdmJ5; Mon, 16 May 2011 12:04:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2CE07C8; Mon, 16 May 2011 12:04:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516190402.9824.24302.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 12:04:02 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: <draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt> (Mechanism for performing LSP-Ping over MPLS tunnels) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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: Mon, 16 May 2011 19:04:46 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Mechanism for performing LSP-Ping over MPLS tunnels' <draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes methods for performing LSP Ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS label-switched-paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for a LSP that goes over other MPLS tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-enhanced-dsmap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-enhanced-dsmap/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1084/ http://datatracker.ietf.org/ipr/1053/ From iesg-secretary@ietf.org Mon May 16 12:05:53 2011 Return-Path: <iesg-secretary@ietf.org> 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 4A4A6E07DD; Mon, 16 May 2011 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 4IM2ajgIOB6J; Mon, 16 May 2011 12:05:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D27E07AA; Mon, 16 May 2011 12:05:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516190522.9835.40164.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 12:05:22 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: <draft-ietf-mpls-p2mp-lsp-ping-16.txt> (Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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: Mon, 16 May 2011 19:05:53 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping' <draft-ietf-mpls-p2mp-lsp-ping-16.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 4379. Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-lsp-ping/ No IPR declarations have been submitted directly on this I-D. From gregimirsky@gmail.com Mon May 16 18:05:12 2011 Return-Path: <gregimirsky@gmail.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 9D9E4E06DA for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 18:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cShFfCV1UVxA for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 18:05:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D767E0696 for <mpls@ietf.org>; Mon, 16 May 2011 18:05:11 -0700 (PDT) Received: by vws12 with SMTP id 12so15073vws.31 for <mpls@ietf.org>; Mon, 16 May 2011 18:05:11 -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=T6tKzEymF/bfXs2hhB1m57DUoXwdtg7HyfAaPt7EMjA=; b=opiJ/gGemBI4EDBlbOyeuLJ9HX514VpC+plIHQc/4tChacpOwIzyEcL/EyBPB/jP7y 6rYZAz1OYLZgi82ZESvbg8zjZ8Um6Mb9Ezo+2InCy3Qhq0ItBjY24ZvrirPf4q4VHY1v 1hRny+jSyRrIkldQq01f3co/RS3c1FZFCNJ6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=r9ug6IHmOZPqZdH7zD8Id1KEh/3nRRYV0RkXS4H7G3EwqSWW3Hf/T7tSx5g/5L1TBT ahL85f+Dfy7sv4gtYXkIZSWo/DHtt+6eSgCrdC/9FeWskySL6oW7pclBPs1oY+2IjxyJ dkTK67B8qy2m2kTbWsm6E8/xRqNjvbK2eJ0DI= MIME-Version: 1.0 Received: by 10.52.116.10 with SMTP id js10mr40713vdb.256.1305594310976; Mon, 16 May 2011 18:05:10 -0700 (PDT) Received: by 10.52.156.228 with HTTP; Mon, 16 May 2011 18:05:10 -0700 (PDT) Date: Mon, 16 May 2011 18:05:10 -0700 Message-ID: <BANLkTinN9045ThVkEyGpmHk66hsOh50CPg@mail.gmail.com> From: Greg Mirsky <gregimirsky@gmail.com> To: Sami Boutros <sboutros@cisco.com>, "Siva Sivabalan(msiva)" <msiva@cisco.com>, Rahul Aggarwal <rahul@juniper.net>, martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn, swallow@cisco.com, David Ward <dward@juniper.net>, stbryant@cisco.com, cpignata@cisco.com, "Bitar, Nabil N" <nabil.bitar@verizon.com>, BUSI ITALO <italo.busi@alcatel-lucent.com>, "LEVRAU, LIEVEN (LIEVEN)" <lieven.levrau@alcatel-lucent.com>, laurent.ciavaglia@alcatel-lucent.com, wu.bo@zte.com.cn, yang_jian@zte.com.cn, mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec548668e2064fb04a36e5dab Subject: [mpls] LC comments to draft-ietf-mpls-tp-li-lb-01 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: Tue, 17 May 2011 01:05:12 -0000 --bcaec548668e2064fb04a36e5dab Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, please find my LC comments to the document below (hope I'm not too late). - section 3.2 I think that there are mandatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional, e.g. Authentication TLV. - section 3.3.5 describes Return Code in Return TLV for LSP-ping option of LI-LB signaling. For in-band option Return Code has different values and values listed in this section are for field Cause Code. I think it would be beneficial to have some uniformity across LI-LB signalling options and in Return TLV have both Return Code and Cause Code fields with values identical for in-band and LSP-Ping options. - section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentication of LB request but in-band option doesn't have provision to indicate that Authentication is in use. I propose to allocate MSB of Reserved field as Authentication flag. - section 6.3 mentions that Authentication may be used both in Lock request and Lock response. I think that if Authentication was present in Lock request and accepted by remote MEP, then Lock response must have Authentication. Similar is applicable to use of Authentication in Unlock request/response, and Setting/Removing LB . - section 6.5.b I think that there's no guarantee that sender of LI request will not generate false positive after remote MEP locks the LSP. Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply but it might stop sending OAM messages after 3*TxPeriod interval. Regards, Greg --bcaec548668e2064fb04a36e5dab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,<br>please find my LC comments to the document below (= hope I'm not too late).<br><ul><li>section 3.2 I think that there are m= andatory TLVs for LI-LB and optional. Mandatory TLV for LI might be Source = MEP-ID, Destination MEP-ID, while for LB Source MEP-ID and MIP-ID. Optional= , e.g. Authentication TLV.<br> </li><li>section 3.3.5 describes Return Code in Return TLV for LSP-ping opt= ion of LI-LB signaling. For in-band option Return Code has different values= and values listed in this section are for field Cause Code. I think it wou= ld be beneficial to have some uniformity across LI-LB signalling options an= d in Return TLV have both Return Code and Cause Code fields with values ide= ntical for in-band and LSP-Ping options.</li> <li>section 3.3.6 defines Authentication TLV for LSP-Ping option. Authentic= ation of LB request but in-band option doesn't have provision to indica= te that Authentication is in use. I propose to allocate MSB of Reserved fie= ld as Authentication flag.</li> <li>section 6.3 mentions that Authentication may be used both in Lock reque= st and Lock response. I think that if Authentication was present in Lock re= quest and accepted by remote MEP, then Lock response must have Authenticati= on. Similar is applicable to use of Authentication in Unlock request/respon= se, and Setting/Removing LB .<br> </li><li>section 6.5.b I think that there's no guarantee that sender of= LI request will not generate false positive after remote MEP locks the LSP= . Perhaps, if proactive OAM is enabled, the remote MEP should send LI reply= but it might stop sending OAM messages after 3*TxPeriod interval. <br> </li></ul>Regards,<br>Greg<br> --bcaec548668e2064fb04a36e5dab-- From yaacov.weingarten@nsn.com Mon May 16 21:03:21 2011 Return-Path: <yaacov.weingarten@nsn.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 5D6CBE07A8 for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 21:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=0.6, 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 NkkOv1C0WmBu for <mpls@ietfa.amsl.com>; Mon, 16 May 2011 21:03:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF9E079F for <mpls@ietf.org>; Mon, 16 May 2011 21:03:18 -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 p4H43EAs003034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 May 2011 06:03:14 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4H43DiS010853; Tue, 17 May 2011 06:03:13 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 06:03:13 +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_01CC1447.57C24D8A" Date: Tue, 17 May 2011 06:03:09 +0200 Message-ID: <E4873516F3FC7547BCFE792C7D94039C326FBB@DEMUEXC013.nsn-intra.net> In-Reply-To: <201105130203.p4D23KEd065500@mse02.zte.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt Thread-Index: AcwREfuJYP9A8sgAQkiALKyA8apmMgDNFYpg References: <XFE-RCD-302agj5BbHk0000001a@xfe-rcd-302.cisco.com> <201105130203.p4D23KEd065500@mse02.zte.com.cn> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com> To: <liu.guoman@zte.com.cn>, "Sami Boutros" <sboutros@cisco.com> X-OriginalArrivalTime: 17 May 2011 04:03:13.0813 (UTC) FILETIME=[57F9E450:01CC1447] Cc: Ross Callon <rcallon@juniper.net>, mpls@ietf.org, draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 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: Tue, 17 May 2011 04:03:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1447.57C24D8A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCiANCg0KQWdhaW4gSSBhbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB0aGUgY29u ZnVzaW9uIOKAkyBpZiB0aGUgc2VnbWVudCBvZiB0aGUgTFNQIGlzIGluIGxvb3BiYWNrIG1vZGUg dGhlbiBpdCBzaG91bGQgYmUgZWFzeSBmb3IgdGhlIHNvdXJjZSBMRVIgdG8gZGV0ZWN0IGVpdGhl ciBvZiB0aGUgbWlzY29ubmVjdGl2aXR5IGNvbmRpdGlvbnMgdGhhdCB5b3UgZGVzY3JpYmUg4oCT DQoNCjEuIEZvciB0aGUgY2FzZSBvZiBtZXNzYWdlcyB0aGF0IGFyZSBsb3N0IGR1ZSB0byBhIG1p c2Nvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZSBzb3VyY2UgTEVSIGFuZCB0aGUgTUlQIHRoYXQgaXMg bG9vcGluZyBiYWNrIOKAkyB0aGUgbWVzc2FnZXMgdGhhdCBhcmUgbG9zdCB3aWxsIG5vdCBiZSBs b29wZWQtYmFjaywgd2hpY2ggY2FuIGJlIGRldGVjdGVkIGJ5IHRoZSBzb3VyY2UgTEVSDQoNCjIu IEZvciB0aGUgY2FzZSBvZiBtZXNzYWdlcyB0aGF0IGFyZSBsZWFraW5nIGludG8gdGhlIHNlZ21l bnQgZnJvbSBhIGRpZmZlcmVudCBMU1Ag4oCTIHRoaXMgbWVzc2FnZSB3aWxsIGJlIGxvb3BlZCBi YWNrIGJ5IHRoZSBNSVAgYW5kIHRoZSBzb3VyY2UgTEVSIGNvdWxkIGRldGVjdCBhbiBleGNlc3Np dmUgbWVzc2FnZSBpbiB0aGUgc3RyZWFtLg0KDQogDQoNCkhvd2V2ZXIsIGFzIHdhcyBwb2ludGVk IG91dCBpbiBhIHNlcGFyYXRlIHRocmVhZCDigJMgaXQgaXMgYWR2aXNhYmxlIHRvIG9ubHkgZW50 ZXIgbG9vcGJhY2sgb24gYW4gTFNQIHRoYXQgdGhlcmUgYXJlIG5vIHN1c3BlY3RlZCBtaXNjb25u ZWN0aXZpdGllcyENCg0KIA0KDQpIb3BlIHRoaXMgaGVscHMsDQoNCnlhYWNvdg0KDQogDQoNCkZy b206IGV4dCBsaXUuZ3VvbWFuQHp0ZS5jb20uY24gW21haWx0bzpsaXUuZ3VvbWFuQHp0ZS5jb20u Y25dIA0KU2VudDogRnJpZGF5LCBNYXkgMTMsIDIwMTEgNDo0NyBBTQ0KVG86IFNhbWkgQm91dHJv cw0KQ2M6IGRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZzsgTG9hIEFuZGVy c3NvbjsgbXBsc0BpZXRmLm9yZzsgUm9zcyBDYWxsb247IFdlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNO IC0gSUwvSG9kIEhhU2hhcm9uKQ0KU3ViamVjdDogUkU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGItMDEudHh0DQoNCiANCg0KDQpzYW1p LCB5YWNjb3YsaGkgDQpmaXJzdGx5IGkgc2F5IHNvcnJ5IGZvciBub3QgY2xlYXJseSBkZXNjcmli bGluZyBteSBxdWVzdGlvbi4gDQpmb3IgdGhlIGZpcnN0IHF1ZXN0aW9uLCBtYXliZSB5YWFjb3Yn cyB1bmRlcnN0YW5kaW5nIGJlIHJpZ2h0LiBpZiBhIG1lcCBpcyANCm9uIGxvb3BiYWNrIHN0YXRl LCBpdCBjYW4ndCBjaGVjayB0aGUgZTJlIHBhdGggZm9yIG1pcy1jb25uZWN0aXZpdHkgYmVjYXVz ZSANCnRoZSBtZXAgcG9pbnQgbG9vcGJhY2sgZXZlcnl0aGluZyBpbmNsdWRpbmcgYW55IE9BTSBw YWNrZXQoY2MmY3YgZXRjKTsgDQoNCmZvciB0aGUgc2Vjb25kIHF1ZXN0aW9uLCBJIGtub3cgbG9z cy9kZWxheSBtZWFzdXJlbWVudCBzaG91bGQgdXNlIExNL0RNIGZ1Y3Rpb24gdG8gDQppbXBsZW1l bnQgaXQuIGJ1dCBmb3IgbG9vcGJhY2sgZnVuY3Rpb24sIHRoZXJlIGFyZSB0aGUgZm9sbG93aW5n IHR3byBhcHBsaWNhdGlvbjogDQogIDEgVG8gdmVyaWZ5IGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2 aXR5IG9mIGEgTUVQIHdpdGggYSBNSVAgb3IgYSBwZWVyIE1FUDsgDQogIDIgVG8gcGVyZm9ybSBh IGJpZGlyZWN0aW9uYWwgaW4tc2VydmljZSBvciBvdXQtb2Ytc2VydmljZSBkaWFnbm9zdGljcyB0 ZXN0IGJldHdlZW4gYSBwYWlyIG9mIHBlZXIgTUVQcy4gVGhpcyBpbmNsdWRlcyB2ZXJpZnlpbmcg YmFuZHdpZHRoIHRocm91Z2hwdXQsIGRldGVjdGluZyBiaXQgZXJyb3JzLCBldGM7IA0KICANCnNv IGZvciBhcHBsaWNhdGlvbiAxLCBsb29wYmFjayBhbnl0aGluZyB3aWxsIG5vdCBhZmZlY3QgdmVy aWZ5IGJpZGlyZWN0aW9uYWwgY29ubmVjdGl2aXR5OyBidXQgaXQgbWF5IGFmZmVjdCBkaWFnbm9z dGljcyB0ZXN0LiANCmZvciBleGFtcGxlLCBpZiBtaXMtY29ubmVjdGl2aXR5IG9yIG1pcy1jb25m aWd1cmF0aW9uIGhhcHBlbmVkIG9uIGEgTFNQIHBhdGgsIHNpbmNlIHRoZSBtZXAgb2YgdGhlIGxz cCBpcyB1bmRlciBsb29wYmFjayBzdGF0ZSwgaXQgY2FuJ3QgY2hlY2sgbWlzLWNvbm5lY3Rpdml0 eSwgDQpzbyB0aGUgbWVwIG9mIHRoZSBsc3AgbWF5YmUgbG9vcGJhY2sgb3RoZXIgZGF0YSBwYWNr ZXQgb2YgYW5vdGhlciBsc3AgdG8gdGhlIHBlZXIgbWVwLm9yIHRoZSBkYXRhIHBrdCBvZiB0aGUg TFNQIHdpbGwgYmUgbGVha2VkIHRvIG90aGVyIExTUCBwYXRoLCBzbyBpdCBtdXN0IGFmZmVjdCB0 aGUgcmVzdWx0IG9mIGRpYWdub3N0aWNzIHRlc3QgaW5jbHVkaW5nIGJhbmR3aWR0aCB0aHJvdWdo cHV0LCBiaXQgZXJyb3JzLiANCg0KbWF5YmUgaSBtaXNzIHNvbWV0aGluZyBpbXBvcnRhbnQ/IA0K DQp0aGFuayBzYW1pIGFuZCB5YWFjb3YgZm9yIHByb21wdCByZXBseWluZyBpdC4gDQoNCkIuUi4g DQpMaXUNCg0KCQkNCg0KDQoNCg0KDQoNClNhbWkgQm91dHJvcyA8c2JvdXRyb3NAY2lzY28uY29t PiANCg0KMjAxMS0wNS0xMyAwNTowNSANCg0K5pS25Lu25Lq6DQoNCiJXZWluZ2FydGVuLCBZYWFj b3YgKE5TTiAtIElML0hvZCBIYVNoYXJvbikiIDx5YWFjb3Yud2VpbmdhcnRlbkBuc24uY29tPiwg PGxpdS5ndW9tYW5AenRlLmNvbS5jbj4sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiANCg0K 5oqE6YCBDQoNCiJSb3NzIENhbGxvbiIgPHJjYWxsb25AanVuaXBlci5uZXQ+LCA8bXBsc0BpZXRm Lm9yZz4sICJNUExTLVRQIGFkIGhvYyB0ZWFtIiA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+LCA8 ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRvb2xzLmlldGYub3JnPiANCg0K5Li76aKYDQoNClJF OiBbbXBsc10gd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gIGRyYWZ0LWlldGYtbXBscy10cC1s aS1sYi0wMS50eHQNCg0KIA0KDQoJCQ0KDQoNCg0KDQpBZ3JlZWQgWWFhY292LCBkdXJpbmcgdGhl IHBlcmlvZCBvZiBsb29wYmFjayB0aGUgY2MtY3YgZnVuY3Rpb24gY2FuJ3QgYmUgcGVyZm9ybWVk LCBhbmQgeWVzIHRoZSBtYWluIGJlbmVmaXQgaXMgb2YgbG9vcGJhY2sgaXMgdG8gbWVhc3VyZSBs b3NzL2RlbGF5IG9uIGEgc2VnbWVudCBvZiBhIHBhdGggYXMgeW91IHN0YXRlZC4NCg0KVGhhbmtz LA0KDQpTYW1pDQpBdCAxMDozNiBQTSA1LzExLzIwMTEsIFdlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNO IC0gSUwvSG9kIEhhU2hhcm9uKSB3cm90ZTogDQpTYW1pLCBoaQ0KDQpNeSB1bmRlcnN0YW5kaW5n IGlzIHRoYXQgdGhlIHF1ZXN0aW9uIHRoYXQgd2FzIGFza2VkIGlzIGhvdyBkbyB5b3UgdXNlIHRo ZSBjYy1jdiBmdW5jdGlvbiB0byBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0eSBpZiBpdCBpcyBi ZWluZyBsb29wZWQtYmFjay4NCg0KVHJ1dGggYmUgdG9sZCB0aGF0IGR1cmluZyB0aGUgcGVyaW9k IG9mIGxvb3BiYWNrIHlvdSBhcHBhcmVudGx5IGNhbm5vdCBjaGVjayB0aGUgZTJlIHBhdGggZm9y IG1pcy1jb25uZWN0aXZpdHksIGFuZCB0aGUgb3BlcmF0b3IgbmVlZHMgdG8gdGFrZSB0aGlzIGlu dG8gY29uc2lkZXJhdGlvbi4gIEJ1dCBzaW5jZSB0aGUgcGF0aCBpcyBub3QgdHJhbnNmZXJyaW5n IGRhdGEgZTJlIChpdCBpcyBsb29waW5nIGV2ZXJ5dGhpbmcgYmFjaykgaXQgaXMgYnkgZGVmaW5p dGlvbiBub3QgY29ubmVjdGVkIGUyZS4NCg0KV2hhdCBpcyB0cnVlIGlzIHdoYXQgU2FtaSBzdGF0 ZXMgdGhpcyBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSB1c2VkIHRvIHNldHVwIGEgbG9zcy9kZWxh eSBtZWFzdXJlbWVudCBvbiBhIHNlZ21lbnQgb2YgYSBwYXRoLCBhbmQgaXQgc2hvdWxkIGJlIHVz ZWQgb25seSBmb3IgbGltaXRlZCBwZXJpb2RzLg0KDQpKdXN0IG15IDJjZW50cywNCnlhYWNvdg0K DQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgWyBtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIDxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBdIE9uIEJlaGFsZiBPZiBleHQgU2Ft aSBCb3V0cm9zDQpTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDExIDg6MDMgQU0NClRvOiBsaXUu Z3VvbWFuQHp0ZS5jb20uY247IExvYSBBbmRlcnNzb24NCkNjOiBSb3NzIENhbGxvbjsgbXBsc0Bp ZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IG9uIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQNCg0KVG8gY2hlY2sgZm9yIG1pcy1j b25uZWN0aXZpdHkvbWlzLWNvbmZpZ3VyYXRpb24sIHlvdSBuZWVkIGEgY2MtY3YgZnVuY3Rpb24g bm90IGEgbG9vcGJhY2sgZnVuY3Rpb24uDQoNClRoZSBsb29wYmFjayBmdW5jdGlvbiBjYW4gYmUg dXNlZCBmb3IgbG9zcy9kZWxheSBtZWFzdXJlbWVudHMsIGFuZCB0aGlzIHdpbGwgYmUgYWRkcmVz c2VkIGluIHRoZSBkZWxheS9sb3NzIGRyYWZ0Lg0KDQpUaGFua3MsDQoNClNhbWkNCkF0IDA3OjEx IFBNIDUvMTAvMjAxMSwgbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KDQoNCmhpLCBhbGwg DQpmb3IgdGhpcyBkcmFmdCwgSSBoYXZlIGEgcXVlc3Rpb24gZm9yIExvb3BiYWNrIGZ1bmN0aW9u LiANCmluIGxhc3QgaWV0ZiBtZWV0aW5nLCBJTU8sIHRoZSBhdXRob3Igc2FtaSBzYWlkIHRoaXMg DQpMb29wYmFjayBmdW5jdGlvbiBpcyB0byBsb29wYmFjayBhbnl0aGluZy4gZm9yIE1FUCBwb2lu dCBvZiANCmEgTFNQLCBpZiBpdCBpcyBzZXQgdG8gTG9vcGJhY2sgc3RhdGUsIGl0IHdpbGwgbG9v cGJhY2sgYWxsIHJlY2VpdmVkIA0KcGFja2V0cyBpbmNsdWRpbmcgYW55IE9BTSBwYWNrZXQuIGlm IHNvLCBob3cgdG8gZGV0ZWN0IG1pcy1jb25uZWN0aXZpdHkgb3IgDQptaXMtY29uZmlndXJhdGlv biBmb3IgdGhlIExTUD8gDQppbiBhZGR0aW9uLCBpZiBpdCBoYXBwZW4gbWlzLWNvbm5lY3Rpdml0 eSwgbWF5YmUgb3RoZXIgTFNQIHBhY2tldCBiZSB0cmFuc3BvcnRlZCB0byANCnRoZSBNRVAgLCBh bmQgdGhlIG1lcCBwb2ludCB3aWxsIHN0aWxsIExvb3BiYWNrIHRoZSB3cm9uZyBwYWNrZXQgdG8g cGVlciBtZXAgcG9pbnQsIA0KY2FuIGl0IGFmZmVjdCBwZXJmb3JtYW5jZSA8YXBwOmRzOnBlcmZv cm1hbmNlPiAgc3RhdGlzdGljcyA8YXBwOmRzOnN0YXRpc3RpY3M+ICBvciBtZWFzdXJlbWVudCBv biB0aGUgcGVlciBtZXAgcG9pbnQ/IA0KDQpCLlIuIA0KbGl1IA0KDQoNCg0KDQoNCg0KTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51PiANCsK3wqLCvMO+w4jDizogIG1wbHMtYm91bmNlc0BpZXRmLm9y ZyANCg0KMjAxMS0wNS0xMCAyMzo0MyANCg0KDQrDisOVwrzDvsOIw4sNCg0KDQoibXBsc0BpZXRm Lm9yZyIgPG1wbHNAaWV0Zi5vcmc+IA0KDQoNCsKzwq3Di8ONDQoNCg0KUm9zcyBDYWxsb24gPHJj YWxsb25AanVuaXBlci5uZXQ+LCBNUExTLVRQIGFkIGhvYyB0ZWFtIDxhaG1wbHMtdHBAbGlzdHMu aXR1LmludD4sIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9yZyANCg0KDQrD lsO3w4zDog0KDQoNClttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW1wbHMtdHAtbGktbGItMDEudHh0IA0KDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlz IHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCg0KZHJhZnQt aWV0Zi1tcGxzLXRwLWxpLWxiLTAxLnR4dA0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRv IHRoZSBtcGxzQGlldGYub3JnIG1haWxpbmcgbGlzdC4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBlbmRzIG9uIE1heSAyNXRoLg0KDQovTG9hDQoNCmZvciB0aGUgbXBscyB3ZyBjby1j aGFpcnMNCg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBl bWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFy ZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAg ICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1w bHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPiANCg0KDQoNCg0KDQog IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIA0KDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcw0KbWFpbCANCg0KDQppcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsDQpjb21tdW5pY2F0aW9uIA0KDQoN CmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluDQpzZWNyZWN5IA0KDQoNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uDQp0byANCg0KDQpvdGhlcnMuIA0K DQoNClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwNCmFuZCANCg0KDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleQ0KYXJlIA0KDQoNCmFkZHJlc3NlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5DQp0aGUg DQoNCg0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlDQp0aG9zZSANCg0KDQpvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLiAN Cg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBi eSBaVEUNCkFudGktU3BhbSANCg0KDQpzeXN0ZW0uIA0KICANCg0KDQoNCiANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== ------_=_NextPart_001_01CC1447.57C24D8A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNv bWljIFNhbnMgTVMiOw0KCXBhbm9zZS0xOjMgMTUgNyAyIDMgMyAyIDIgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWlu Z0xpVSI7DQoJcGFub3NlLTE6MiAyIDMgOSAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7DQoJY29sb3I6IzM2NUY5 MTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxk aXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6IzM2NUY5MSc+ SGksPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6IzM2NUY5 MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6 IzM2NUY5MSc+QWdhaW4gSSBhbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB0aGUgY29uZnVz aW9uIOKAkyBpZiB0aGUgc2VnbWVudCBvZiB0aGUgTFNQIGlzIGluIGxvb3BiYWNrIG1vZGUgdGhl biBpdCBzaG91bGQgYmUgZWFzeSBmb3IgdGhlIHNvdXJjZSBMRVIgdG8gZGV0ZWN0IGVpdGhlciBv ZiB0aGUgbWlzY29ubmVjdGl2aXR5IGNvbmRpdGlvbnMgdGhhdCB5b3UgZGVzY3JpYmUg4oCTPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6IzM2NUY5MSc+MS4g Rm9yIHRoZSBjYXNlIG9mIG1lc3NhZ2VzIHRoYXQgYXJlIGxvc3QgZHVlIHRvIGEgbWlzY29ubmVj dGl2aXR5IGJldHdlZW4gdGhlIHNvdXJjZSBMRVIgYW5kIHRoZSBNSVAgdGhhdCBpcyBsb29waW5n IGJhY2sg4oCTIHRoZSBtZXNzYWdlcyB0aGF0IGFyZSBsb3N0IHdpbGwgbm90IGJlIGxvb3BlZC1i YWNrLCB3aGljaCBjYW4gYmUgZGV0ZWN0ZWQgYnkgdGhlIHNvdXJjZSBMRVI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb21pYyBTYW5zIE1TIjtjb2xvcjojMzY1RjkxJz4yLiBGb3IgdGhlIGNh c2Ugb2YgbWVzc2FnZXMgdGhhdCBhcmUgbGVha2luZyBpbnRvIHRoZSBzZWdtZW50IGZyb20gYSBk aWZmZXJlbnQgTFNQIOKAkyB0aGlzIG1lc3NhZ2Ugd2lsbCBiZSBsb29wZWQgYmFjayBieSB0aGUg TUlQIGFuZCB0aGUgc291cmNlIExFUiBjb3VsZCBkZXRlY3QgYW4gZXhjZXNzaXZlIG1lc3NhZ2Ug aW4gdGhlIHN0cmVhbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb21pYyBTYW5zIE1TIjtj b2xvcjojMzY1RjkxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb21pYyBTYW5z IE1TIjtjb2xvcjojMzY1RjkxJz5Ib3dldmVyLCBhcyB3YXMgcG9pbnRlZCBvdXQgaW4gYSBzZXBh cmF0ZSB0aHJlYWQg4oCTIGl0IGlzIGFkdmlzYWJsZSB0byBvbmx5IGVudGVyIGxvb3BiYWNrIG9u IGFuIExTUCB0aGF0IHRoZXJlIGFyZSBubyBzdXNwZWN0ZWQgbWlzY29ubmVjdGl2aXRpZXMhPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6IzM2NUY5MSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7Y29sb3I6IzM2NUY5 MSc+SG9wZSB0aGlzIGhlbHBzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvbWljIFNhbnMg TVMiO2NvbG9yOiMzNjVGOTEnPnlhYWNvdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvbWlj IFNhbnMgTVMiO2NvbG9yOiMzNjVGOTEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGV4dCBsaXUuZ3Vv bWFuQHp0ZS5jb20uY24gW21haWx0bzpsaXUuZ3VvbWFuQHp0ZS5jb20uY25dIDxicj48Yj5TZW50 OjwvYj4gRnJpZGF5LCBNYXkgMTMsIDIwMTEgNDo0NyBBTTxicj48Yj5Ubzo8L2I+IFNhbWkgQm91 dHJvczxicj48Yj5DYzo8L2I+IGRyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5pZXRmLm9y ZzsgTG9hIEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzsgUm9zcyBDYWxsb247IFdlaW5nYXJ0ZW4s IFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtt cGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGIt MDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5zYW1pLCB5YWNjb3Ys aGk8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+Zmlyc3RseSBpIHNheSBzb3JyeSBmb3Igbm90IGNsZWFybHkg ZGVzY3JpYmxpbmcgbXkgcXVlc3Rpb24uIDwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmZvciB0aGUgZmlyc3Qg cXVlc3Rpb24sIG1heWJlIHlhYWNvdidzIHVuZGVyc3RhbmRpbmcgYmUgcmlnaHQuIGlmIGEgbWVw IGlzIDwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPm9uIGxvb3BiYWNrIHN0YXRlLCBpdCBjYW4ndCBjaGVjayB0 aGUgZTJlIHBhdGggZm9yIG1pcy1jb25uZWN0aXZpdHkgYmVjYXVzZTwvc3Bhbj4gPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz50aGUgbWVwIHBvaW50IGxvb3BiYWNrIGV2ZXJ5dGhpbmcgaW5jbHVkaW5nIGFueSBPQU0gcGFj a2V0KGNjJmFtcDtjdiBldGMpOzwvc3Bhbj4gPGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Zm9yIHRoZSBzZWNvbmQg cXVlc3Rpb24sIEkga25vdyBsb3NzL2RlbGF5IG1lYXN1cmVtZW50IHNob3VsZCB1c2UgTE0vRE0g ZnVjdGlvbiB0byA8L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5pbXBsZW1lbnQgaXQuIGJ1dCBmb3IgbG9vcGJh Y2sgZnVuY3Rpb24sIHRoZXJlIGFyZSB0aGUgZm9sbG93aW5nIHR3byBhcHBsaWNhdGlvbjo8L3Nw YW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+Jm5ic3A7IDEgPC9zcGFuPlRvIHZlcmlmeSBiaWRpcmVjdGlvbmFsIGNv bm5lY3Rpdml0eSBvZiBhIE1FUCB3aXRoIGEgTUlQIG9yIGEgcGVlciBNRVA8c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Ozwvc3Bh bj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz4mbmJzcDsgMiA8L3NwYW4+VG8gcGVyZm9ybSBhIGJpZGlyZWN0aW9uYWwg aW4tc2VydmljZSBvciBvdXQtb2Ytc2VydmljZSBkaWFnbm9zdGljcyB0ZXN0IGJldHdlZW4gYSBw YWlyIG9mIHBlZXIgTUVQcy4gVGhpcyBpbmNsdWRlcyB2ZXJpZnlpbmcgYmFuZHdpZHRoIHRocm91 Z2hwdXQsIGRldGVjdGluZyBiaXQgZXJyb3JzLCBldGM8c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Ozwvc3Bhbj4gPGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+c28gZm9yIGFwcGxpY2F0aW9uIDEsIGxvb3BiYWNr IGFueXRoaW5nIHdpbGwgbm90IGFmZmVjdCB2ZXJpZnkgYmlkaXJlY3Rpb25hbCBjb25uZWN0aXZp dHk7IGJ1dCBpdCBtYXkgYWZmZWN0IGRpYWdub3N0aWNzIHRlc3QuPC9zcGFuPiA8YnI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn PmZvciBleGFtcGxlLCBpZiBtaXMtY29ubmVjdGl2aXR5IG9yIG1pcy1jb25maWd1cmF0aW9uIGhh cHBlbmVkIG9uIGEgTFNQIHBhdGgsIHNpbmNlIHRoZSBtZXAgb2YgdGhlIGxzcCBpcyB1bmRlciBs b29wYmFjayBzdGF0ZSwgaXQgY2FuJ3QgY2hlY2sgbWlzLWNvbm5lY3Rpdml0eSw8L3NwYW4+IDxi cj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+c28gdGhlIG1lcCBvZiB0aGUgbHNwIG1heWJlIGxvb3BiYWNrIG90aGVyIGRhdGEg cGFja2V0IG9mIGFub3RoZXIgbHNwIHRvIHRoZSBwZWVyIG1lcC5vciB0aGUgZGF0YSBwa3Qgb2Yg dGhlIExTUCB3aWxsIGJlIGxlYWtlZCB0byBvdGhlciBMU1AgcGF0aCwgc28gaXQgbXVzdCBhZmZl Y3QgdGhlIHJlc3VsdCBvZiBkaWFnbm9zdGljcyB0ZXN0IGluY2x1ZGluZyBiYW5kd2lkdGggdGhy b3VnaHB1dCwgYml0IGVycm9ycy48L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPm1heWJlIGkgbWlzcyBz b21ldGhpbmcgaW1wb3J0YW50Pzwvc3Bhbj4gPGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dGhhbmsgc2FtaSBhbmQg eWFhY292IGZvciBwcm9tcHQgcmVwbHlpbmcgaXQuPC9zcGFuPiA8YnI+PGJyPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5CLlIu PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPkxpdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9 TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MzYuMHB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48 L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PC90ZD48L3Ry PjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNt O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0 Jz48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUg Ym9yZGVyPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSIgc3R5bGU9J3dpZHRoOjEwMC4wJTtt YXJnaW4tbGVmdDozNi4wcHQnPjx0cj48dGQgd2lkdGg9IjM1JSIgdmFsaWduPXRvcCBzdHlsZT0n d2lkdGg6MzUuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPlNhbWkgQm91dHJvcyAmbHQ7c2JvdXRyb3NAY2lzY28uY29tJmd0Ozwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4yMDExLTA1LTEz IDA1OjA1PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB3aWR0aD0iNjMlIiB2YWxpZ249 dG9wIHN0eWxlPSd3aWR0aDo2My45OCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+ PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9 IjEwMCUiIHN0eWxlPSd3aWR0aDoxMDAuMCUnPjx0cj48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJp Z2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7mlLbku7bkuro8L3NwYW4+PG86cD48L286cD48L3A+ PC90ZD48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw dCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1dlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNO IC0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7eWFhY292LndlaW5nYXJ0ZW5AbnNuLmNvbSZn dDssICZsdDtsaXUuZ3VvbWFuQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1 b3Q7ICZsdDtsb2FAcGkubnUmZ3Q7PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRy Pjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48 cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaKhOmA gTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5n Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+JnF1b3Q7 Um9zcyBDYWxsb24mcXVvdDsgJmx0O3JjYWxsb25AanVuaXBlci5uZXQmZ3Q7LCAmbHQ7bXBsc0Bp ZXRmLm9yZyZndDssICZxdW90O01QTFMtVFAgYWQgaG9jIHRlYW0mcXVvdDsgJmx0O2FobXBscy10 cEBsaXN0cy5pdHUuaW50Jmd0OywgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1saS1sYkB0b29scy5p ZXRmLm9yZyZndDs8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIHZhbGln bj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1z b05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiTVMgR290aGljIic+5Li7PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6TWluZ0xpVSc+6aKYPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5SRTogW21wbHNdIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uICZuYnNwO2RyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50 eHQ8L3NwYW4+PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3Jk ZXI9MCBjZWxscGFkZGluZz0wPjx0cj48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCc+PC90ZD48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3RyPjwvdGFi bGU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxicj48YnI+ PGJyPkFncmVlZCBZYWFjb3YsIGR1cmluZyB0aGUgcGVyaW9kIG9mIGxvb3BiYWNrIHRoZSBjYy1j diBmdW5jdGlvbiBjYW4ndCBiZSBwZXJmb3JtZWQsIGFuZCB5ZXMgdGhlIG1haW4gYmVuZWZpdCBp cyBvZiBsb29wYmFjayBpcyB0byBtZWFzdXJlIGxvc3MvZGVsYXkgb24gYSBzZWdtZW50IG9mIGEg cGF0aCBhcyB5b3Ugc3RhdGVkLjxicj48YnI+VGhhbmtzLDxicj48YnI+U2FtaTxicj5BdCAxMDoz NiBQTSA1LzExLzIwMTEsIFdlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9u KSB3cm90ZTogPGJyPlNhbWksIGhpPGJyPjxicj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhl IHF1ZXN0aW9uIHRoYXQgd2FzIGFza2VkIGlzIGhvdyBkbyB5b3UgdXNlIHRoZSBjYy1jdiBmdW5j dGlvbiB0byBjaGVjayBmb3IgbWlzLWNvbm5lY3Rpdml0eSBpZiBpdCBpcyBiZWluZyBsb29wZWQt YmFjay48YnI+PGJyPlRydXRoIGJlIHRvbGQgdGhhdCBkdXJpbmcgdGhlIHBlcmlvZCBvZiBsb29w YmFjayB5b3UgYXBwYXJlbnRseSBjYW5ub3QgY2hlY2sgdGhlIGUyZSBwYXRoIGZvciBtaXMtY29u bmVjdGl2aXR5LCBhbmQgdGhlIG9wZXJhdG9yIG5lZWRzIHRvIHRha2UgdGhpcyBpbnRvIGNvbnNp ZGVyYXRpb24uICZuYnNwO0J1dCBzaW5jZSB0aGUgcGF0aCBpcyBub3QgdHJhbnNmZXJyaW5nIGRh dGEgZTJlIChpdCBpcyBsb29waW5nIGV2ZXJ5dGhpbmcgYmFjaykgaXQgaXMgYnkgZGVmaW5pdGlv biBub3QgY29ubmVjdGVkIGUyZS48YnI+PGJyPldoYXQgaXMgdHJ1ZSBpcyB3aGF0IFNhbWkgc3Rh dGVzIHRoaXMgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgdXNlZCB0byBzZXR1cCBhIGxvc3MvZGVs YXkgbWVhc3VyZW1lbnQgb24gYSBzZWdtZW50IG9mIGEgcGF0aCwgYW5kIGl0IHNob3VsZCBiZSB1 c2VkIG9ubHkgZm9yIGxpbWl0ZWQgcGVyaW9kcy48YnI+PGJyPkp1c3QgbXkgMmNlbnRzLDxicj55 YWFjb3Y8YnI+PGI+PGJyPkZyb206PC9iPiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgWzxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPiBtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgU2FtaSBCb3V0cm9zPGI+PGJyPlNlbnQ6 PC9iPiBUaHVyc2RheSwgTWF5IDEyLCAyMDExIDg6MDMgQU08Yj48YnI+VG86PC9iPiBsaXUuZ3Vv bWFuQHp0ZS5jb20uY247IExvYSBBbmRlcnNzb248Yj48YnI+Q2M6PC9iPiBSb3NzIENhbGxvbjsg bXBsc0BpZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLWxp LWxiQHRvb2xzLmlldGYub3JnPGI+PGJyPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQ8YnI+PGJy PlRvIGNoZWNrIGZvciBtaXMtY29ubmVjdGl2aXR5L21pcy1jb25maWd1cmF0aW9uLCB5b3UgbmVl ZCBhIGNjLWN2IGZ1bmN0aW9uIG5vdCBhIGxvb3BiYWNrIGZ1bmN0aW9uLjxicj48YnI+VGhlIGxv b3BiYWNrIGZ1bmN0aW9uIGNhbiBiZSB1c2VkIGZvciBsb3NzL2RlbGF5IG1lYXN1cmVtZW50cywg YW5kIHRoaXMgd2lsbCBiZSBhZGRyZXNzZWQgaW4gdGhlIGRlbGF5L2xvc3MgZHJhZnQuPGJyPjxi cj5UaGFua3MsPGJyPjxicj5TYW1pPGJyPkF0IDA3OjExIFBNIDUvMTAvMjAxMSwgbGl1Lmd1b21h bkB6dGUuY29tLmNuIHdyb3RlOjxicj48YnI+PGJyPmhpLCBhbGwgPGJyPmZvciB0aGlzIGRyYWZ0 LCBJIGhhdmUgYSBxdWVzdGlvbiBmb3IgTG9vcGJhY2sgZnVuY3Rpb24uIDxicj5pbiBsYXN0IGll dGYgbWVldGluZywgSU1PLCB0aGUgYXV0aG9yIHNhbWkgc2FpZCB0aGlzIDxicj5Mb29wYmFjayBm dW5jdGlvbiBpcyB0byBsb29wYmFjayBhbnl0aGluZy4gZm9yIE1FUCBwb2ludCBvZiA8YnI+YSBM U1AsIGlmIGl0IGlzIHNldCB0byBMb29wYmFjayBzdGF0ZSwgaXQgd2lsbCBsb29wYmFjayBhbGwg cmVjZWl2ZWQgPGJyPnBhY2tldHMgaW5jbHVkaW5nIGFueSBPQU0gcGFja2V0LiBpZiBzbywgaG93 IHRvIGRldGVjdCBtaXMtY29ubmVjdGl2aXR5IG9yIDxicj5taXMtY29uZmlndXJhdGlvbiBmb3Ig dGhlIExTUD8gPGJyPmluIGFkZHRpb24sIGlmIGl0IGhhcHBlbiBtaXMtY29ubmVjdGl2aXR5LCBt YXliZSBvdGhlciBMU1AgcGFja2V0IGJlIHRyYW5zcG9ydGVkIHRvIDxicj50aGUgTUVQICwgYW5k IHRoZSBtZXAgcG9pbnQgd2lsbCBzdGlsbCBMb29wYmFjayB0aGUgd3JvbmcgcGFja2V0IHRvIHBl ZXIgbWVwIHBvaW50LCA8YnI+Y2FuIGl0IGFmZmVjdDxhIGhyZWY9ImFwcDpkczpwZXJmb3JtYW5j ZSI+IHBlcmZvcm1hbmNlPC9hPiA8YSBocmVmPSJhcHA6ZHM6c3RhdGlzdGljcyI+c3RhdGlzdGlj czwvYT4gb3IgbWVhc3VyZW1lbnQgb24gdGhlIHBlZXIgbWVwIHBvaW50PyA8YnI+PGJyPkIuUi4g PGJyPmxpdSA8YnI+PGJyPjxicj48YnI+PGJyPjxicj48Yj48YnI+TG9hIEFuZGVyc3NvbiAmbHQ7 bG9hQHBpLm51Jmd0OzwvYj4gPGJyPsK3wqLCvMO+w4jDizogJm5ic3A7bXBscy1ib3VuY2VzQGll dGYub3JnIDxicj48YnI+MjAxMS0wNS0xMCAyMzo0MyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWFsaWdu OnJpZ2h0Jz48YnI+w4rDlcK8w77DiMOLPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxicj4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7 ICZsdDttcGxzQGlldGYub3JnJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249cmlnaHQgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWFsaWduOnJpZ2h0Jz48 YnI+wrPCrcOLw408bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjM2LjBwdCc+PGJyPlJvc3MgQ2FsbG9uICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0 OywgTVBMUy1UUCBhZCBob2MgdGVhbSAmbHQ7YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQmZ3Q7LCBk cmFmdC1pZXRmLW1wbHMtdHAtbGktbGJAdG9vbHMuaWV0Zi5vcmcgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQ7dGV4 dC1hbGlnbjpyaWdodCc+PGJyPsOWw7fDjMOiPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Jz48YnI+W21wbHNdIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1saS1sYi0wMS50eHQgPGJyPjxicj48 YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxicj48dHQ+V29ya2luZyBHcm91cCw8L3R0Pjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD50aGlz IGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248L3R0Pjwv c3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PGJyPjx0dD5kcmFmdC1pZXRmLW1wbHMtdHAtbGktbGItMDEudHh0PC90dD48L3Nw YW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxicj48dHQ+UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBsc0BpZXRm Lm9yZyBtYWlsaW5nIGxpc3QuPC90dD48L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+VGhpcyB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBlbmRzIG9uIE1heSAyNXRoLjwvdHQ+PC9zcGFuPjxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0Pi9M b2E8L3R0Pjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD5mb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzPC90dD48 L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxicj48dHQ+LS0gPC90dD48L3NwYW4+PGJyPjxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PkxvYSBBbmRl cnNzb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJp Y3Nzb24uY29tPC90dD48YnI+PHR0PlNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5udTwvdHQ+PGJy Pjx0dD5Fcmljc3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6 ICs0NiAxMCA3MTcgNTIgMTM8L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICs0NiA3NjcgNzIgOTIgMTM8L3R0Pjxicj48dHQ+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj48dHQ+bXBscyBtYWlsaW5n IGxpc3Q8L3R0Pjxicj48dHQ+bXBsc0BpZXRmLm9yZzwvdHQ+PHU+PHNwYW4gc3R5bGU9J2NvbG9y OmJsdWUnPjxicj48L3NwYW4+PC91Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwvdHQ+ PC9hPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48YnI+PGJyPjx0dD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L3NwYW4+PC90dD4gPGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5aVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXM8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0Pm1haWw8L3R0Pjwv c3Bhbj4gPGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5pcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PGJyPjx0dD5jb21tdW5pY2F0aW9uPC90dD48L3NwYW4+IDxicj48YnI+PGJyPjx0 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+aXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW48L3NwYW4+PC90dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+ PHR0PnNlY3JlY3k8L3R0Pjwvc3Bhbj4gPGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz5hbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+dG88L3R0Pjwvc3Bh bj4gPGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5vdGhlcnMu PC9zcGFuPjwvdHQ+IDxicj48YnI+PGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+YW5kPC90dD48L3NwYW4+IDxicj48YnI+PGJyPjx0 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+aW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXk8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 YnI+PHR0PmFyZTwvdHQ+PC9zcGFuPiA8YnI+PGJyPjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciBwbGVhc2Ugbm90aWZ5PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD50aGU8L3R0Pjwvc3Bhbj4g PGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5vcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmU8 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48YnI+PHR0PnRob3NlPC90dD48L3NwYW4+IDxicj48YnI+PGJyPjx0dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+b2YgdGhlIGluZGl2aWR1YWw8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 YnI+PHR0PnNlbmRlci48L3R0Pjwvc3Bhbj4gPGJyPjxicj48YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5UaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEU8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PkFudGktU3BhbTwvdHQ+PC9zcGFu PiA8YnI+PGJyPjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPnN5c3RlbS48 L3NwYW4+PC90dD4gPGJyPiZuYnNwOyA8YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwcmUgc3R5bGU9 J21hcmdpbi1sZWZ0OjM2LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlIHN0eWxlPSdt YXJnaW4tbGVmdDozNi4wcHQnPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPlpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6 Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3Ro aXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21h aWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVj aXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJz cDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25v dCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250 ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290 aGVycy48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+VGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuPG86cD48 L286cD48L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPlRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CC1447.57C24D8A-- From hideki.endo.es@hitachi.com Tue May 17 02:52:19 2011 Return-Path: <hideki.endo.es@hitachi.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 EF78AE080C for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 02:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.663 X-Spam-Level: ** X-Spam-Status: No, score=2.663 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=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 Lu-rWNvQfj9V for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 02:52:17 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 09B65E07EC for <mpls@ietf.org>; Tue, 17 May 2011 02:52:16 -0700 (PDT) Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id CCF0C33CC4; Tue, 17 May 2011 18:52:14 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id p4H9qEwC026832; Tue, 17 May 2011 18:52:14 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p4H9peLD013228; Tue, 17 May 2011 18:52:14 +0900 Received: from vshuts3.hitachi.co.jp ([vshuts3.hitachi.co.jp [10.201.6.72]]) by mfilter1.hitachi.co.jp with RELAY id p4H9qDeY013429 ; Tue, 17 May 2011 18:52:14 +0900 X-AuditID: b753bd60-a50caba000003bac-3a-4dd2454d1d79 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 425BD7741AE; Tue, 17 May 2011 18:52:13 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p4H9qDl20033790; Tue, 17 May 2011 18:52:13 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: <XNM1$7$0$0$$6$1$2$A$5001320U4dd2452b@hitachi.com> Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110517185209" To: <eric.gray@ericsson.com> From: <hideki.endo.es@hitachi.com> Date: Tue, 17 May 2011 18:52:07 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C7563@EUSAACMS0701.eamcs.er> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C756D@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001118U4d907aaa@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C759B@EUSAACMS0701.eamcs.er> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> <XNM1$7$0$0$$6$1$2$A$5001140U4d934d10@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B06679157@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001143U4d93a3de@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B0667959B@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001145U4d941dcc@hitachi.com> <A3C5DF08D38B6049839A6F553B331C76D722D074F7@ILPTMAIL02.ecitele.co> <C0AC8FAB6849AB4FADACCC70A949E2F10B066795AF@EUSAACMS0701.eamcs.er> Priority: normal Importance: normal X400-Content-Identifier: X4DD2452B00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml281105171851392GM] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Last_Call_ondraft-ietf-mpls-t?= =?iso-8859-1?q?p-on-demand-cv-?= 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: Tue, 17 May 2011 09:52:20 -0000 --GMAILSMTPBOUND01110517185209 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KSXQgd2FzIGdvb2Qgb3Bwb3J0dW5pdHkgZm9yIHVzIHRvIGRpc2N1c3Mg YWJvdXQgUGVyLUlGIE1JUCBhdCBQYXJndWUuDQpJbiB0aGF0IHdlZWssIHlvdSBwdXQgcmVw bHkgdG8gbWUgb24gTUwgYXMgYmVsb3c7DQoNCj4gPj4gICAgICAgIElmIHlvdSB3YW50IHRv IGluY2x1ZGUgc3BlY2lmaWMgaW50ZXJmYWNlIGluZm9ybWF0aW9uLA0KPiA+PnlvdSBjYW4g aW5jbHVkZSBhIERTTUFQIChvciBERE1BUCkgVExWIGFzIGRlZmluZWQgYnkgUkZDDQo+ID4+ NDM3OSwgYW5kIGV4dGVuZGVkIGJ5IHRoaXMgZHJhZnQgKGluIGNvbWJpbmF0aW9uIHdpdGgg dGhlDQo+ID4+ZHJhZnQgImRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1lbmhhbmNlZC1kc21h cCIgZm9yIERETUFQKS4NCg0KQWZ0ZXIgdGhhdCwgSSd2IHJlYWQgYm90aCBvZiBSRkMgNDM3 OSBhbmQgZHJhZnQtaWV0Zi1tcGxzLW9uLWRlbWFuZC1jdiBpbiBkZXRhaWwuDQpBcyB0aGUg cmVzdWx0LCBJJ2QgbGlrZSB0byBjbGFyaWZ5IHNvbWUgcG9pbnRzIGFzIGJlbG93Ow0KDQoo MSlkcmFmdC1vbi1kZW1hbmQtY3Ygc2F5cyBpbiAyLjEuMS4gdGhhdA0KICAiV2hlbiBzZW5k aW5nIE9uLWRlbWFuZCBDViBwYWNrZXRzIHVzaW5nIEFDSCwgd2l0aG91dCBJUA0KICAgZW5j YXBzdWxhdGlvbiwgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBNVVNUIGJlIGluY2x1ZGVk IGluIGFueQ0KICAgKHNvdXJjZS9kZXN0aW5hdGlvbikgVExWIHRoYXQgaXMgaW5jbHVkZWQg aW4gdGhlIHBhY2tldC4iLg0KICBIZXJlLCAidGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiIg aXMgRFNNQVAvRERNQVAgYWRkcmVzcyBUTFYNCiAgd2hpY2ggaGFzIGFkZHJlc3MgdHlwZSAi NSIuDQoNCiAgRnVydGhlcm1vcmUsIHRoZSBkcmFmdCBhbHNvIGRlc2NyaWJlcyBpbiAyLjEu IHRoYXQNCiAgIldoZW4gdGhpcyBhZGRyZXNzIHR5cGUgaXMgdXNlZCwgb24gcmVjZWlwdCBv ZiBhIExTUC1QaW5nIGVjaG8NCiAgIHJlcXVlc3QsIGludGVyZmFjZSB2ZXJpZmljYXRpb24g TVVTVCBiZSBieXBhc3NlZC4gIFRodXMgdGhlIHJlY2VpdmluZw0KICAgbm9kZSBTSE9VTEQg b25seSBwZXJmb3JtIG1wbHMgbGFiZWwgY29udHJvbC1wbGFuZS9kYXRhLXBsYW5lDQogICBj b25zaXN0ZW5jeSBjaGVja3MuDQogIEhlcmUsICJ0aGlzIGFkZHJlc3MgdHlwZSIgaXMgIjUi Lg0KDQogIEluIG15IHVuZGVyc3RhbmRpbmcgZnJvbSB0aGVzZSB0d28gZGVzY3JpcHRpb25z LA0KICBhIERTTUFQL0RETUFQIE1VU1QgYmUgaW5jbHVkZWQgaW4gYW4gZWNobyByZXF1ZXN0 LA0KICB3aGVuIHVzaW5nIEFDSCB3aXRob3V0IElQL1VEUC4NCiAgSG93ZXZlciwgb24gcmVj ZWlwdCBvZiB0aGUgZWNobyByZXF1ZXN0LA0KICB0aGUgRFNNQVAvRERNQVAgTVVTVCBiZSBp Z25vcmVkLg0KICANCiAgaXMgdGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNCigyKUlm IGFib3ZlIGlzIHllcywgaXMgaXQgcG9zc2libGUgdG8gYWNoaWV2ZSBQZXItSUYgTUlQDQog ICBieSBzaW5nbGUgcm91dGUtdHJhY2UgYXMgeW91IHNhaWQ/DQoNCkJSLA0KSGlkZWtpDQoN Cg0KPlNhc2hhLA0KPg0KPiAgICAgICAgSXQgaXMgbm90IHByZWNsdWRlZC4gIEFzIEhpZGVr aSBjb3JyZWN0bHkgcG9pbnRzIG91dCwgaW5ncmVzcw0KPnRvIG1pZC1wb2ludCBjb25uZWN0 aXZpdHkgdmVyaWZpY2F0aW9uIGlzIGEgcmVxdWlyZW1lbnQgaW4gUkZDIDU4NjAuDQo+DQo+ ICAgICAgICBTaW5jZSB0aGUgc2FtZSBtZXNzYWdlIGlzIHVzZWQgaW4gYm90aCBUcmFjZXJv dXRlIGFuZCBDViwgaW4NCj50aGUgY2FzZSB3aGVyZSB5b3Ugd2FudCB0byBkbyBhIGNvbnRp bnVpdHkgY2hlY2sgZnJvbSBMU1AgaW5ncmVzcyB0bw0KPnNvbWUgZGV2aWNlIGJldHdlZW4g dGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBmb3IgdGhlIExTUCAoaS5lLiAtIGEgTUlQKSwNCj5p bXBsZW1lbnRhdGlvbnMgd291bGQgZG8gaXQgaW4gdGhlIHNhbWUgd2F5IHRoYXQgeW91IGRv IFRyYWNlcm91dGUgLQ0KPndpdGggdGhlIGV4Y2VwdGlvbiB0aGF0IHlvdSB3b3VsZCBkbyBp dCBvbmx5IHdpdGggdGhlIGludGVuZGVkIFRUTA0KPihhcyBvcHBvc2VkIHRvIHN0YXJ0aW5n IHdpdGggMSBhbmQgaW5jcmVtZW50aW5nIGl0IHVudGlsIHlvdSBnZXQgYQ0KPigiUGluZyIp IHJlc3BvbnNlIGZyb20gdGhlIGludGVuZGVkIExTUCBlZ3Jlc3MuDQo+DQo+ICAgICAgICBB cyBJIGV4cGxhaW5lZCB0byBIaWRla2ksIGl0IGlzIGxhcmdlbHkgYSBtYXR0ZXIgb2YgcGVy c29uYWwNCj5wcmVmZXJlbmNlIHdoZXRoZXIgeW91IHRoaW5rIG9mIHRoaXMgYXMgYSBUcmFj ZXJvdXRlIG9yIFRUTC1saW1pdGVkDQo+Q1YgbWVzc2FnZS4NCj4NCj4gICAgICAgIE5vdGUg dGhhdCBDViBpcyBleHBsaWNpdGx5IG5vdCBpbmNsdWRlZCBpbiByZXF1aXJlbWVudHMgZm9y DQo+dGhlIGNhc2Ugd2hlcmUgb25lIG1pZ2h0IHdhbnQgdG8gdGVzdCBNSVAtdG8tTUVQLg0K Pg0KPi0tDQo+RXJpYw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTog QWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbV0NCj5TZW50OiBUaHVyc2RheSwgTWFyY2ggMzEsIDIwMTEgMjo0NCBBTQ0KPlRv OiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbTsgRXJpYyBHcmF5DQo+Q2M6IE1hbnVlbC5Q YXVsQHRlbGVrb20uZGU7IFJvbGYuV2ludGVyQG5lY2xhYi5ldTsgbXBsc0BpZXRmLm9yZzsg YWxkcmluLmlldGZAZ21haWwuY29tDQo+U3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdy b3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LQ0KPklt cG9ydGFuY2U6IEhpZ2gNCj4NCj5IaWRla2ksIEVyaWMsIGFuZCBhbGwsDQo+SSBiZWxpZXZl IHRoYXQgYWJpbGl0eSB0byBkbyBwaW5nIE1FUC10by1NSVAgc2hvdWxkIG5vdCBiZSBwcmVj bHVkZWQgKGF0IGxlYXN0IGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzKS4NCj4N Cj4NCj5SZWdhcmRzLA0KPiAgICAgU2FzaGENCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gaGlkZWtpLmVuZG8uZXNAaGl0 YWNoaS5jb20NCj4+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAzMSwgMjAxMSA4OjI0IEFNDQo+ PiBUbzogbXBsc0BpZXRmLm9yZzsgZXJpYy5ncmF5QGVyaWNzc29uLmNvbTsgYWxkcmluLmll dGZAZ21haWwuY29tDQo+PiBDYzogTWFudWVsLlBhdWxAdGVsZWtvbS5kZTsgUm9sZi5XaW50 ZXJAbmVjbGFiLmV1DQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFz Q2FsbG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gZGVtYW5kLWN2LQ0KPj4NCj4+IEhp IEVyaWMgYW5kIFNhbSwNCj4+DQo+PiBJJ20gc29ycnkgZm9yIG15IGluY29ycmVjdCB1bmRl cnN0YW5kaW5nIG9uIERTTUFQIFRMVi4NCj4+IEFjY29yZGluZyB0byBTYW0sIFdlIGNhbiB1 c2UgRFNNQVAgaW4gYm90aCBvZiBwaW5nIGFuZCB0cmFjZSByb3V0ZS4NCj4+DQo+PiBIb3dl dmVyLCBJIGhhdmUgYSBjb25jZXJuLg0KPj4gRXJpYywgeW91IHNhaWQ7DQo+PiA+ICAgICAg ICBQaW5nIG1vZGUgd291bGQgYmUgc3RyaWN0bHkgTUVQLXRvLU1FUC4gIEF0IGxlYXN0LCB0 aGF0DQo+PiA+aXMgdGhlIHdheSBpdCBpcyBpbnRlbmRlZCB0byB3b3JrIGluIG91ciBkcmFm dC4NCj4+DQo+PiBPbiB0aGUgb3RoZXIgaGFuZCwgUkZDNTg2MCwgTVBMUy1UUCBPQU0gcmVx cywgc2F5czsNCj4+IDIuMi4zLiAgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbnMNCj4+ICAg IDxzbmlwcGVkPg0KPj4gICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQgYmUgcGVyZm9ybWVkIG9u LWRlbWFuZCBiZXR3ZWVuIEVuZCBQb2ludHMgYW5kDQo+PiAgICBJbnRlcm1lZGlhdGUgUG9p bnRzIG9mIFBXcyBhbmQgTFNQcywgYW5kIGJldHdlZW4gRW5kIFBvaW50cyBvZiBQV3MsDQo+ PiAgICBMU1BzLCBhbmQgU2VjdGlvbnMuDQo+Pg0KPj4gYW5kOw0KPj4NCj4+IDIuMi40LiAg Um91dGUgVHJhY2luZw0KPj4gICAgPHNuaXBwZWQ+DQo+PiAgICBUaGlzIGZ1bmN0aW9uIFNI T1VMRCBiZSBwZXJmb3JtZWQgb24tZGVtYW5kLg0KPj4NCj4+ICAgIFRoaXMgZnVuY3Rpb24g U0hPVUxEIGJlIHBlcmZvcm1lZCBiZXR3ZWVuIEVuZCBQb2ludHMgYW5kDQo+PiBJbnRlcm1l ZGlhdGUNCj4+ICAgIFBvaW50cyBvZiBQV3MgYW5kIExTUHMsIGFuZCBiZXR3ZWVuIEVuZCBQ b2ludHMgb2YgUFdzLCBMU1BzLCBhbmQNCj4+ICAgIFNlY3Rpb25zLg0KPj4NCj4+IFdoeSBk byB5b3UgcmVzdHJpY3QgcGluZyBtb2RlIHRvIG9ubHkgZm9yIGJldHdlZW4gTUVQcz8NCj4+ IERvIHlvdSBtZWFuIHRoYXQgT24tZGVtYW5kIENWIGRvZXNuJ3Qgc2F0aXNmeSBhbGwgb2Yg T0FNIHJlcXM/DQo+Pg0KPj4gQlIsDQo+PiBIaWRla2kNCj4+DQo+PiA+SGlkZWtpLA0KPj4g Pg0KPj4gPiAgICAgICAgUGluZyBtb2RlIHdvdWxkIGJlIHN0cmljdGx5IE1FUC10by1NRVAu ICBBdCBsZWFzdCwgdGhhdA0KPj4gPmlzIHRoZSB3YXkgaXQgaXMgaW50ZW5kZWQgdG8gd29y ayBpbiBvdXIgZHJhZnQuDQo+PiA+DQo+PiA+ICAgICAgICBXaHkgd291bGQgeW91IG5lZWQg cGVyLWludGVyZmFjZSBNSVAgaW5mb3JtYXRpb24gaW4gdGhpcw0KPj4gPmNhc2U/DQo+PiA+ DQo+PiA+ICAgICAgICBJZiBzb21lb25lIHdhbnRlZCB0byBkbyBMU1AtUGluZyB0byBhIHNw ZWNpZmljIGludGVyZmFjZSwNCj4+ID5JIGFtIHVuY2VydGFpbiB3aHkgaXQgd291bGQgYmUg aW5jb3JyZWN0IHRvIHVzZSB0aGUgRFNNQVAgVExWLg0KPj4gPg0KPj4gPi0tDQo+PiA+RXJp Yw0KPj4gPg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogaGlk ZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRla2kuZW5kby5lc0BoaXRhY2hp LmNvbV0NCj4+ID5TZW50OiBXZWRuZXNkYXksIE1hcmNoIDMwLCAyMDExIDU6NDMgUE0NCj4+ ID5UbzogRXJpYyBHcmF5OyBtcGxzQGlldGYub3JnDQo+PiA+Q2M6IFJvbGYuV2ludGVyQG5l Y2xhYi5ldTsgTWFudWVsLlBhdWxAdGVsZWtvbS5kZQ0KPj4gPlN1YmplY3Q6IFJlWzJdOiBS ZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGxvbmRyYWZ0LWlldGYtbXBscy0N Cj4+IHRwLW9uLWRlbWFuZC1jdi0wMw0KPj4gPkltcG9ydGFuY2U6IEhpZ2gNCj4+ID4NCj4+ ID5FcmljLA0KPj4gPg0KPj4gPkluIG15IHVuZGVyc3RhbmRpbmcsIERTTUFQIFRMViBpcyBv bmx5IGZvciB0cmFjZSByb3V0ZSwgaXNuJ3QgaXQ/DQo+PiA+V2UgbmVlZCBzcGVjaWZpYyBp bnRlcmZhY2UgaW5mb3JtYXRpb24gZm9yIHBpbmcgbW9kZSBvZiBvbi1kZW1hbmQgQ1YuDQo+ PiA+DQo+PiA+QlIsDQo+PiA+SGlkZWtpDQo+PiA+DQo+PiA+PkhpZGVraSwNCj4+ID4+DQo+ PiA+PiAgICAgICAgSWYgeW91IHdhbnQgdG8gaW5jbHVkZSBzcGVjaWZpYyBpbnRlcmZhY2Ug aW5mb3JtYXRpb24sDQo+PiA+PnlvdSBjYW4gaW5jbHVkZSBhIERTTUFQIChvciBERE1BUCkg VExWIGFzIGRlZmluZWQgYnkgUkZDDQo+PiA+PjQzNzksIGFuZCBleHRlbmRlZCBieSB0aGlz IGRyYWZ0IChpbiBjb21iaW5hdGlvbiB3aXRoIHRoZQ0KPj4gPj5kcmFmdCAiZHJhZnQtaWV0 Zi1tcGxzLWxzcC1waW5nLWVuaGFuY2VkLWRzbWFwIiBmb3IgRERNQVApLg0KPj4gPj4NCj4+ ID4+ICAgICAgICBXb3VsZCB0aGlzIG5vdCBkbyB3aGF0IHlvdSdyZSBsb29raW5nIGZvcj8N Cj4+ID4+DQo+PiA+Pi0tDQo+PiA+PkVyaWMNCj4+ID4+DQo+PiA+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+PkZyb206IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tIFtt YWlsdG86aGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb21dDQo+PiA+PlNlbnQ6IFdlZG5lc2Rh eSwgTWFyY2ggMzAsIDIwMTEgMTE6MzMgQU0NCj4+ID4+VG86IFJvbGYuV2ludGVyQG5lY2xh Yi5ldTsgRXJpYyBHcmF5OyBtcGxzQGlldGYub3JnOw0KPj4gTWFudWVsLlBhdWxAdGVsZWtv bS5kZQ0KPj4gPj5TdWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENh bGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtDQo+PiBvbi1kZW1hbmQtY3YtMDMNCj4+ID4+SW1w b3J0YW5jZTogSGlnaA0KPj4gPj4NCj4+ID4+SGksDQo+PiA+Pg0KPj4gPj5JIGhhdmUgb25l IGNvbW1lbnQgb24gSURzIGluIGRyYWZ0LW9uLWRlbWFuZC1jdi4NCj4+ID4+VGhlIGludGVy ZmFjZS1EIGlzIG1pc3NpbmcgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIHRoZXJlIGlzIG9ubHkg Tm9kZS0NCj4+IElELg0KPj4gPj5Zb3UgbmVlZCBhdCBsZWFzdCB0aGUgaW50ZXJmYWNlIElE IHRvIHN1cHBvcnQgcGVyLWludGVyZmFjZSBNSVAuDQo+PiA+Pg0KPj4gPj5CUiwNCj4+ID4+ SGlkZWtpDQo+PiA+Pg0KPj4gPj4+DQo+PiA+Pj5EZWFyIEFsbCwNCj4+ID4+Pg0KPj4gPj4+ SSByZWFsbHkgYXBwcmVjaWF0ZSB0aGUgY29uc2lkZXJhdGlvbiBvbiB0aGUgcGVyLWludGVy ZmFjZSBNSVANCj4+IHN1cHBvcnQgYW5kIHRoZSBkaXNjdXNzaW9uIG1vdmluZyBmb3J3YXJk Lg0KPj4gPj4+DQo+PiA+Pj4NCj4+ID4+PkZyb20gYW4gb3BlcmF0b3IncyBwZXJzcGVjdGl2 ZSwgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdGhhdCB0aGUNCj4+IHN1cHBvcnQgZm9yIHBlci1p bnRlcmZhY2UgTUlQcyBpcyBjb3ZlcmVkIGJ5IHRoZSBkZWZpbml0aW9ucy4NCj4+ID4+Pg0K Pj4gPj4+TG9va2luZyBhdCBlYXJsaWVyIHZlcnNpb25zIG9mIGRyYWZ0LWZhcnJlbC1tcGxz LXRwLW1pcC1tZXAtbWFwLA0KPj4gdGhlcmUgd2FzIGFscmVhZHkgYSBzb2x1dGlvbiBwcm9w b3NhbCwgdXNpbmcgdGhlIFRUTC4gRW5oYW5jZWQNCj4+IHNvbHV0aW9ucyBoYXZlIGJlZW4g dGhvcm91Z2x5IGRpc2N1c3NlZCBkdXJpbmcgdGhpcyBJRVRGIG1lZXRpbmcuIEl0IGl0DQo+ PiB0byBiZSBleHBlY3RlZCB0aGF0IHRoZXJlIHdpbGwgYmUgd2F5cyB0byBzb2x2ZSBib3Ro IHRoZSBmYXN0IHBhdGggYW5kDQo+PiBmYXRlLXNoYXJpbmcgcmVxdWlyZW1lbnQuDQo+PiA+ Pj4NCj4+ID4+Pg0KPj4gPj4+SSBzZWNvbmQgdGhlIHByb3Bvc2FsIGluaXRpYWxseSBtYWRl IGJ5IFJvbGYsIHRvIGluY2x1ZGUgYWRkaXRpb25hbA0KPj4gdGV4dCB0byBkb2N1bWVudCB0 aGUgcGVyLWludGVyZmFjZSBNSVAgYWRkcmVzc2luZyBmb3IgdGhlIG9uLWRlbWFuZC1jdg0K Pj4gYW5kIGZvciBvdGhlciBPQU0gdG9vbHMuDQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+QmVz dCByZWdhcmRzLA0KPj4gPj4+TWFudWVsDQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+RGV1dHNj aGUgVGVsZWtvbSBBRw0KPj4gPj4+R3JvdXAgVGVjaG5vbG9neQ0KPj4gPj4+TWFudWVsIFBh dWwNCj4+ID4+PlNBMy0xMQ0KPj4gPj4+R29zbGFyZXIgVWZlciAzNS0zNywgMTA1ODkgQmVy bGluDQo+PiA+Pj4rNDkgMzAgMzQ5NyAtIDQzOTQgKFRlbC4pDQo+PiA+Pj4rNDkgMzAgMzQ5 NyAtIDQ5NTYgKEZheCkNCj4+ID4+Pis0OSAxNzEgIDg2MzQwMzIgKE1vYmlsKQ0KPj4gPj4+ RS1NYWlsOiBtYWlsdG86bWFudWVsLnBhdWxAdGVsZWtvbS5kZQ0KPj4gPj4+aHR0cDovL3d3 dy50ZWxla29tLmNvbQ0KPj4gPj4+DQo+PiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiA+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZiBPZg0KPj4gPj4+PiBSb2xmIFdpbnRl cg0KPj4gPj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDM6MDMgUE0NCj4+ID4+ Pj4gVG86IEVyaWMgR3JheTsgaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20NCj4+ID4+Pj4g Q2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5n IEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPj4gb24tZGVtYW5kLQ0K Pj4gPj4+PiBjdi0wMw0KPj4gPj4+Pg0KPj4gPj4+PiBFcmljLA0KPj4gPj4+Pg0KPj4gPj4+ PiBJIGdlbmVyYWxseSBhZ3JlZSBidXQgSSB0aGluayB0aGVyZSBpcyBvbmUgY2FzZSBhY3R1 YWxseSB3aGljaA0KPj4gbmVlZHMgYQ0KPj4gPj4+PiBjbG9zZXIgbG9vayBpbiB0aGlzIHJl Z2FyZCAod2hpY2ggSSBoaW50ZWQgYXQgZWFybGllciksIHdoaWNoIGFyZQ0KPj4gdGhlIHBl ci0NCj4+ID4+Pj4gaW50ZXJmYWNlIE1JUHMuIFlvdXIgVFRMIGV4cGlyZXMgKHRoZSBhY3R1 YWwgYWRkcmVzc2luZyBiaXQgaGVyZSksDQo+PiB0aGUNCj4+ID4+Pj4gaWRlbnRpZmllciB0 ZWxscyB5b3UgaXQgaXMgbm90IGludGVuZGVkIGZvciB0aGUgaW5ncmVzcyBNSVAsIHNvIGl0 DQo+PiBuZWVkcw0KPj4gPj4+PiB0byBiZSBmb3J3YXJkZWQgdG8gdGhlIGVncmVzcyBNSVAg dGhyb3VnaCB0aGUgZm9yd2FyZGluZyBlbmdpbmUuDQo+PiBOb3cgaWYNCj4+ID4+Pj4geW91 IHB1bGwgdGhlIHBhY2tldCBvdXQgb2YgdGhlIGZhc3QgcGF0aCBhbmQgaW5qZWN0IGl0IGJh Y2sgaW4sIGlzDQo+PiB0aGUgT0FNDQo+PiA+Pj4+IHBhY2tldCBzdGlsbCBmYXRlIHNoYXJp bmc/IElmIHlvdSBjYW4gZG8gdGhpcyBpbiBIVyBvbiB0aGUgbGluZQ0KPj4gY2FyZCwgdGhl bg0KPj4gPj4+PiBpdCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUgZm9yd2FyZGVkIGFzIG5v cm1hbC4gSSBrbm93IHRoaXMgaXMgYQ0KPj4gPj4+PiBkaWZmZXJlbnQgZHJhZnQsIGJ1dCB0 aGlzIHdpbGwgYmUgaW4gcGFydGljdWxhciBpbXBvcnRhbnQgZm9yDQo+PiBwZXJmb3JtYW5j ZQ0KPj4gPj4+PiBtb25pdG9yaW5nLg0KPj4gPj4+Pg0KPj4gPj4+PiBCZXN0LA0KPj4gPj4+ Pg0KPj4gPj4+PiBSb2xmDQo+PiA+Pj4+DQo+PiA+Pj4+DQo+PiA+Pj4+DQo+PiA+Pj4+IE5F QyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmlj dG9yaWENCj4+IFJvYWQsIExvbmRvbg0KPj4gPj4+PiBXMyA2QkwgfCBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgMjgzMjAxNA0KPj4gPj4+Pg0KPj4gPj4+Pg0KPj4gPj4+PiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+Pj4+ID4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86 ZXJpYy5ncmF5QGVyaWNzc29uLmNvbV0NCj4+ID4+Pj4gPiBTZW50OiBNb250YWcsIDI4LiBN 5HJ6IDIwMTEgMTQ6NDUNCj4+ID4+Pj4gPiBUbzogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5j b207IFJvbGYgV2ludGVyDQo+PiA+Pj4+ID4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4+Pj4g PiBTdWJqZWN0OiBSRTogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9u ZHJhZnQtaWV0Zi0NCj4+IG1wbHMtdHAtDQo+PiA+Pj4+ID4gb24tZGVtYW5kLWN2LTAzDQo+ PiA+Pj4+ID4NCj4+ID4+Pj4gPiBIaWRla2ksDQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiAgICBX aGF0IHlvdSdyZSBzYXlpbmcgaXMgdHJ1ZSwgYnV0IG5vdCByZWxldmFudCBpbiB0aGlzDQo+ PiA+Pj4+ID4gY2FzZS4gIFRoZSAiYWRkcmVzc2VzIiBpbiB0aGlzIGRpc2N1c3Npb24gYXJl IG5vdCB1c2VkIHRvDQo+PiA+Pj4+ID4gZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJkIE9BTSBw YWNrZXRzLiAgVGhleSBhcmUgdXNlZCBvbmx5DQo+PiA+Pj4+ID4gYnkgdGhlIHJlY2lwaWVu dCBNSVAvTUVQIHRvIHZlcmlmeSB0aGF0IHRoZSBPQU0gcGFja2V0IHdhcw0KPj4gPj4+PiA+ IHByb3Blcmx5IGRlbGl2ZXJlZC4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+ICAgIEJ5IHRoZSB3 YXksIHRoaXMgZGlzY3Vzc2lvbiBpcyBhbiBpbmRpY2F0aW9uIG9mIHRoZQ0KPj4gPj4+PiA+ IGNvbmZ1c2luZyBpbmplY3RlZCBieSBjYWxsaW5nIHRoZXNlIHRoaW5ncyBhZGRyZXNzZXMu ICBNeQ0KPj4gPj4+PiA+IG1pc3Rha2UgYW5kIEkgYnJpbmcgaXQgdXAgbm93IHRvIGhlbHAg dG8gc3RlbSB0aGUgdGlkZSBvZg0KPj4gPj4+PiA+IGZ1cnRoZXIgY29tbWVudHMgcmVzdWx0 aW5nIGZyb20gdGhhdCBjb25mdXNpb24uDQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiAgICBJbiB0 aGUgdmVyc2lvbiB3ZSBwb3N0IGFmdGVyIGxhc3QgY2FsbCBpcyBjb21wbGV0ZSwNCj4+ID4+ Pj4gPiB3ZSB3aWxsIGJlIGNoYW5naW5nIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uICJh ZGRyZXNzIg0KPj4gPj4+PiA+IFRMVnMgdG8gc291cmNlIGFuZCBkZXN0aW5hdGlvbiAiaWRl bnRpZmllciIgVExWcy4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+ICAgIFdlIHdpbGwgYWxzbyBi ZSBjb3JyZWN0aW5nIHRoZSByZWZlcmVuY2UgdG8gRFNNQVAsDQo+PiA+Pj4+ID4gYW5kIERE TUFQLCBhZGRyZXNzIFRMVnMgKHdoaWNoIGlzIGluY29ycmVjdCwgYmVjYXVzZSB0aGUNCj4+ ID4+Pj4gPiBmb3JtYXQgZm9yIERTTUFQL0RETUFQIGRvZXNuJ3QgaW5jbHVkZSBhICJsZW5n dGgiIGZpZWxkKS4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+ICAgIFRoZSBmb3JtYXQgb2YgdGhl IERvd25zdHJlYW0gTWFwcGluZyAoRFNNQVApIFRMViBpcw0KPj4gPj4+PiA+IGRlZmluZWQg aW4gUkZDIDQzNzksIGFuZCB3ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBmb3JtYXQNCj4+ID4+ Pj4gPiBvZiB0aGF0IFRMVi4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+ICAgIFRoZXNlIGNoYW5n ZXMgYXJlIGRyaXZlbiBieSBsYXN0IGNhbGwgY29tbWVudHMgd2UNCj4+ID4+Pj4gPiBoYXZl IGFscmVhZHkgcmVjZWl2ZWQgKHNlZSBKb2VsIEhhbHBlcm4ncyBjb21tZW50cyBvbiB0aGUN Cj4+ID4+Pj4gPiBtYWlsaW5nIGxpc3QpIGFuZCBhcmUgLSBpbiBwYXJ0IC0gdG8gY29ycmVj dCBhY2NpZGVudGFsDQo+PiA+Pj4+ID4gdXNlIG9mIHRoZSB3b3JkICJhZGRyZXNzIiBmb3Ig c291cmNlIGFuZCBkZXN0aW5hdGlvbg0KPj4gPj4+PiA+IGlkZW50aWZpZXIgVExWcyAod2hp Y2ggaXMgd2hhdCB3ZSBoYWQgZGlzY3Vzc2VkIGJlZm9yZQ0KPj4gPj4+PiA+IEkgZ2VuZXJh dGVkIHRoZSAtMDMgdmVyc2lvbiBhbW9uZyB0aGUgYXV0aG9ycyBvZiBzZXZlcmFsDQo+PiA+ Pj4+ID4gb2YgdGhlIGN1cnJlbnQgc2V0IG9mIE1QTFMtVFAgZHJhZnRzKS4NCj4+ID4+Pj4g Pg0KPj4gPj4+PiA+ICAgIEluIHRoZSBjYXNlIG9mIHNvdXJjZSBhbmQgZGVzdGluYXRpb24g aWRlbnRpZmllcnMsDQo+PiA+Pj4+ID4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5 IHRvIHZlcmlmeSB0aGF0IGFuIE9BTSBQRFUNCj4+ID4+Pj4gPiBoYXMgYmVlbiBjb3JyZWN0 bHkgcmVjZWl2ZWQgYnkgaXRzIGludGVuZGVkIHJlY2lwaWVudC4NCj4+ID4+Pj4gPiBCZWNh dXNlIHRoaXMgaXMgYW4gb24tZGVtYW5kIGNvbm5lY3Rpdml0eSB2ZXJpZmljYXRpb24NCj4+ ID4+Pj4gPiBwcm90b2NvbCwgdGhhdCBpcyBleHBlY3RlZCB0byBiZSB1c2VkIG9ubHkgb24g dGhvc2UNCj4+ID4+Pj4gPiBvY2Nhc2lvbnMgd2hlbiB0aGVyZSBpcyBhIG5ldHdvcmsgcHJv YmxlbSB0aGF0IG5lZWRzIHRvDQo+PiA+Pj4+ID4gYmUgZGlhZ25vc2VkLCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGlzIG5vdCBzZWVuIChhbmQgbm90DQo+PiA+Pj4+ID4gdmlzaWJsZSAtIHdp dGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXppbmcgdGhlc2UNCj4+ID4+Pj4gPiBv YmplY3RzIGZvciBzb2Z0d2FyZSBtYWtlcyBzZW5zZS4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+ ICAgIEluIGFkZGl0aW9uLCBzaW5jZSBlaXRoZXIgbWF5IGJlIGluY2x1ZGVkICh3aGljaA0K Pj4gPj4+PiA+IGluY2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSBvZiBpbmNsdWRpbmcgYm90aCks IGl0IGlzIHRoZQ0KPj4gPj4+PiA+IGNhc2UgYWxyZWFkeSB0aGF0IHdlIHdvdWxkIHRoZW4g bmVlZCB0byBkZWNpZGUgd2hpY2ggaXMNCj4+ID4+Pj4gPiB0byBnbyBmaXJzdCAtIGFzc3Vt aW5nIHdlIHdhbnRlZCB0byBkbyB0aGlzICh3aGljaCB3ZQ0KPj4gPj4+PiA+IGRvIG5vdCku DQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiAtLQ0KPj4gPj4+PiA+IEVyaWMNCj4+ID4+Pj4gPg0K Pj4gPj4+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+Pj4+ID4gRnJvbTog aGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20NCj4+IFttYWlsdG86aGlkZWtpLmVuZG8uZXNA aGl0YWNoaS5jb21dDQo+PiA+Pj4+ID4gU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA4 OjExIEFNDQo+PiA+Pj4+ID4gVG86IEVyaWMgR3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1 DQo+PiA+Pj4+ID4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4+Pj4gPiBTdWJqZWN0OiBSZVsy XTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRmLW1wbHMtDQo+ PiB0cC1vbi0NCj4+ID4+Pj4gPiBkZW1hbmQtY3YtMDMNCj4+ID4+Pj4gPiBJbXBvcnRhbmNl OiBIaWdoDQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPiBIaSBFcmljIGFuZCBSb2xmLA0KPj4gPj4+ PiA+DQo+PiA+Pj4+ID4gSSdtIHNvcnJ5IGZvciBpbnRlcnJ1cHRpbmcuDQo+PiA+Pj4+ID4N Cj4+ID4+Pj4gPiBJIGFncmVlIHdpdGggUm9sZiByZWdhcmRpbmcgdGhlIHBlci1pbnRlcmZh Y2UgTUlQIGRpc2N1c3Npb24uDQo+PiA+Pj4+ID4gV2UgaGF2ZSB0byBjb25zaWRlciB0aGUg SFcgaW1wbGVtZW50YXRpb24gYXNwZWN0LA0KPj4gPj4+PiA+IGJlY2F1c2UgdHJhcHBpbmcg b2YgYW4gT0FNIHBhY2tldCBpcyBIVyBydWxlL2Z1bmN0aW9uYWxpdHkgZXZlbg0KPj4gaW4N Cj4+ID4+Pj4gPiByb3V0ZXJzLg0KPj4gPj4+PiA+DQo+PiA+Pj4+ID4gSWYgZXZlcnkgT0FN IHBhY2tldCBpcyB0cmFwcGVkIHRvIENQVQ0KPj4gPj4+PiA+IGFuZCB0aGUgT0FNIHBhY2tl dHMgd2hpY2ggc2hvdWxkIE5PVCBiZSBwcm9jZXNzZWQgaW4gdGhlDQo+PiBJbnRlcmZhY2UN Cj4+ID4+Pj4gPiBhcmUgcmV0dXJuZWQgdG8gRGF0YS1wbGFuZSwNCj4+ID4+Pj4gPiBpdCBp cyBkaWZmZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZyb20gdXNlciBwYWNrZXRzLA0KPj4gPj4+ PiA+IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUg dXNlciBwYXRoLg0KPj4gPj4+PiA+DQo+PiA+Pj4+ID4gVGhlcmVmb3JlLCB3ZSBzaG91bGQg dGFrZSB0aGUgSFcgYXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8NCj4+IGFjY291bnQNCj4+ ID4+Pj4gPiBjb25jdXJyZW50bHkuDQo+PiA+Pj4+ID4gSWYgYW4gYWRkcmVzcyBUTFYgTVVT VCBiZSB0aGUgZmlyc3QgaW4gVExWcywNCj4+ID4+Pj4gPiBpdCBpcyBlbm91Z2ggdG8gbWFr ZSBIVyBpbXBsZW1lbnRhdGlvbiBlYXN5Lg0KPj4gPj4+PiA+DQo+PiA+Pj4+ID4gQlIsDQo+ PiA+Pj4+ID4gSGlkZWtpDQo+PiA+Pj4+ID4NCj4+ID4+Pj4gPg0KPj4gPj4+PiA+DQo+PiA+ Pj4+ID4gPlJvbGYsDQo+PiA+Pj4+ID4gPg0KPj4gPj4+PiA+ID4gIFRoZSB3b3JkcyB5b3Ug cHJvcG9zZSBhcmUgb2theSB3aXRoIG1lLg0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+ICBJ IHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFkZHJlc3MgbG9jYXRpb24gaXNzdWVz DQo+PiA+Pj4+ID4gPndlcmUgc2VwYXJhdGUuDQo+PiA+Pj4+ID4gPg0KPj4gPj4+PiA+ID4g IEkndmUgcGVyc29uYWxseSBoYWQgcHJvYmxlbXMgd2l0aCBwcm90b2NvbCBzcGVjaWZpY2F0 aW9ucw0KPj4gPj4+PiA+ID50aGF0IHJlcXVpcmUgb3JkZXJpbmcgb2YgVExWcy4gIEluIHBh cnRpY3VsYXIsIHRoaXMgaXMgbm90IHZlcnkNCj4+ID4+Pj4gPiA+cm9idXN0IGluIHRlcm1z IG9mICJmdXR1cmUtcHJvb2ZpbmcuIiAgV2hhdCBoYXBwZW5zIGlmIG5ldyBUTFZzDQo+PiA+ Pj4+ID4gPmFyZSBhZGRlZCBsYXRlciBvbjsgZm9yIGluc3RhbmNlLCBzdXBwb3NlIGF0IHNv bWUgcG9pbnQgd2UgaGF2ZQ0KPj4gPj4+PiA+ID5tdWx0aXBsZSAiYWRkcmVzcyIgVExWcz8N Cj4+ID4+Pj4gPiA+DQo+PiA+Pj4+ID4gPiAgQWxzbywgdGhlIGZhY3QgdGhhdCBpbXBsZW1l bnRhdGlvbnMgYXJlIGFsbG93ZWQgdG8gYXR0YWNoDQo+PiA+Pj4+ID4gPlRMVnMgaW4gYW55 IGFyYml0cmFyeSBvcmRlciBhbGxvd3MgY29uc2lkZXJhYmxlIGZsZXhpYmlsdHkgaW4NCj4+ ID4+Pj4gPiA+aW1wbGVtZW50YXRpb24uICBNZXNzYWdlcyBjYW4gYmUgYnVpbHQgaW4gYXJi aXRyYXJpbHkgbWFueQ0KPj4gd2F5cy4NCj4+ID4+Pj4gPiA+VGhpcyB0b28gY2FuIGJlIGEg ZnV0dXJlLXByb29maW5nIGlzc3VlLg0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+ICBJIHdv dWxkIHByZWZlciBub3QgdG8gc3RhcnQgZG93biB0aGUgcm9hZCBvZiByZXF1aXJpbmcgYQ0K Pj4gPj4+PiA+ID5zdWJzZXQgb2YgVExWcyB0byBhcHBlYXIgaW4gYSBjZXJ0YWluIG9yZGVy LCBhbmQgc2F5aW5nIHdlIGhhdmUNCj4+ID4+Pj4gPiA+b25lIFRMViB0aGF0IG5lZWRzIHRv IGJlIGZpcnN0IGlzIGRvaW5nIGp1c3QgdGhhdC4NCj4+ID4+Pj4gPiA+DQo+PiA+Pj4+ID4g Pi0tDQo+PiA+Pj4+ID4gPkVyaWMNCj4+ID4+Pj4gPiA+DQo+PiA+Pj4+ID4gPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+Pj4+ID4gPkZyb206IFJvbGYgV2ludGVyIFttYWls dG86Um9sZi5XaW50ZXJAbmVjbGFiLmV1XQ0KPj4gPj4+PiA+ID5TZW50OiBNb25kYXksIE1h cmNoIDI4LCAyMDExIDY6MTkgQU0NCj4+ID4+Pj4gPiA+VG86IEVyaWMgR3JheQ0KPj4gPj4+ PiA+ID5DYzogbXBsc0BpZXRmLm9yZw0KPj4gPj4+PiA+ID5TdWJqZWN0OiBSRTogW21wbHNd IFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLQ0KPj4gdHAtb24t DQo+PiA+Pj4+ID4gZGVtYW5kLWN2LTAzDQo+PiA+Pj4+ID4gPkltcG9ydGFuY2U6IEhpZ2gN Cj4+ID4+Pj4gPiA+DQo+PiA+Pj4+ID4gPkhpLA0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+ SSBzdGlsbCB0aGluayB0aGVyZSBpcyBhIGxvZ2ljYWwgZXJyb3IuIExldCBtZSBleHBsYWlu LiBJbiBjYXNlDQo+PiB0aGVyZQ0KPj4gPj4+PiA+IGlzIG5vIElQIHlvdSBzaW1wbHkgY2Fu bm90IHVzZSBpdC4gWW91IHNheSB5b3UgY291bGQgZW5hYmxlIElQDQo+PiBidXQgdGhlbg0K Pj4gPj4+PiA+IHRoYXQgaXMgbm90IGEgY2FzZSB3aGVyZSB0aGVyZSBpcyBubyBJUC4gSW4g b3JkZXIgdG8gYmUNCj4+IGNvbnN0cnVjdGl2ZQ0KPj4gPj4+PiA+IGhlcmUgaXMgYSB0ZXh0 IGNoYW5nZSBzdWdnZXN0aW9uOg0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+IkluIGNlcnRh aW4gTVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUCBhZGRyZXNzaW5nIG1pZ2h0DQo+ PiBub3QgYmUNCj4+ID4+Pj4gPiBhdmFpbGFibGUuIEluIHRob3NlIGNhc2VzIE9uLWRlbWFu ZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBNVVNUDQo+PiBiZSBydW4NCj4+ID4+Pj4gPiB3 aXRob3V0IElQIGFkZHJlc3NpbmcsIHVzaW5nIHRoZSBBQ0ggY2hhbm5lbCB0eXBlIHNwZWNp ZmllZCBpbg0KPj4gU2VjdGlvbg0KPj4gPj4+PiA+IDMuIEluIG90aGVyIGNhc2VzIGl0IG1p Z2h0IGJlIGF2YWlsYWJsZSwgaG93ZXZlciwgaXQgbWF5IGJlDQo+PiBwcmVmZXJyZWQNCj4+ ID4+Pj4gPiB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUCBlbmNhcHN1bGF0aW9uLiBJbiB0 aG9zZSBjYXNlcywgdGhlDQo+PiA+Pj4+ID4gcHJvY2VkdXJlcyBhcyBvdXRsaW5lZCBpbiBz ZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUgdXNlZC4iDQo+PiA+Pj4+ID4gPg0KPj4gPj4+PiA+ ID5SZWdhcmRpbmcgdGhlIHBlci1pbnRlcmZhY2UgTUlQIGRpc2N1c3Npb24uIFRoZSBIVyBh c3BlY3QgYWxzbw0KPj4gcG9wcGVkDQo+PiA+Pj4+ID4gdXAgaW4gdGhlIFBXRTMgc2Vzc2lv biBhbmQgSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudA0KPj4gY29uc2lkZXJhdGlvbiwN Cj4+ID4+Pj4gPiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYgd2UgdGFsayBhYm91 dCBUTFZzLCB3ZSBjb3VsZCBtYWtlDQo+PiBpdCBhDQo+PiA+Pj4+ID4gTVVTVCB0aGF0IGFu IEFkZHJlc3MgVExWIGlzIGFsd2F5cyB0aGUgZmlyc3Qgb25lIHRvIGFwcGVhci4gSWYNCj4+ IHlvdSBjYW4NCj4+ID4+Pj4gPiBmYWNpbGl0YXRlIGFuIGVhc3kgaW1wbGVtZW50YXRpb24g aW4gaGFyZHdhcmUsIEkgc2VlIG5vIHJlYXNvbg0KPj4gdG8NCj4+ID4+Pj4gPiBkZWxpYmVy YXRlbHkgbm90IGRvIGl0Lg0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+QmVzdCwNCj4+ID4+ Pj4gPiA+DQo+PiA+Pj4+ID4gPlJvbGYNCj4+ID4+Pj4gPiA+DQo+PiA+Pj4+ID4gPg0KPj4g Pj4+PiA+ID5ORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhv dXNlLCAxIFZpY3RvcmlhDQo+PiBSb2FkLA0KPj4gPj4+PiA+IExvbmRvbiBXMyA2QkwgfCBS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KPj4gPj4+PiA+ID4NCj4+ID4+Pj4gPiA+ DQo+PiA+Pj4+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+Pj4gPiA+ PiBGcm9tOiBFcmljIEdyYXkgW21haWx0bzplcmljLmdyYXlAZXJpY3Nzb24uY29tXQ0KPj4g Pj4+PiA+ID4+IFNlbnQ6IE1vbnRhZywgMjguIE3kcnogMjAxMSAxMTo0Mw0KPj4gPj4+PiA+ ID4+IFRvOiBSb2xmIFdpbnRlcg0KPj4gPj4+PiA+ID4+IENjOiBsb2FAcGkubnU7IG1wbHNA aWV0Zi5vcmcNCj4+ID4+Pj4gPiA+PiBTdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3Jv dXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi0NCj4+IG1wbHMtdHAtb24tDQo+PiA+Pj4+ID4g Pj4gZGVtYW5kLWN2LTAzDQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiBSb2xmLA0KPj4g Pj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gICAgICAgICBXaXRoIHJlZ2FyZCB0byB0aGUgdXNl IG9mIFNIT1VMRCAodmVyc2VzIE1VU1QpIC0gdGhlDQo+PiBpbnRlbnQNCj4+ID4+Pj4gPiA+ PiAoYWNjb3JkaW5nIHRvIFJGQyAyMTE5IC0gc2VlIHRoZSBxdW90ZSBiZWxvdykgaXMgY29u c2lzdGVudA0KPj4gd2l0aA0KPj4gPj4+PiA+ID4+IHRoaXMgY2FzZS4gIElmIC0gZm9yIHNv bWUgcmVhc29uIC0gb25lIGhhZCBhIHJlYWxseSBnb29kDQo+PiByZWFzb24gdG8NCj4+ID4+ Pj4gPiA+PiB1c2UgSVAgYWRkcmVzc2luZyBpbiBzb21lIHNwZWNpZmljIGNhc2UsIG9uZSBj b3VsZCB0YWtlIHN0ZXBzDQo+PiB0bw0KPj4gPj4+PiA+ID4+IG1ha2UgSVAgYWRkcmVzc2lu ZyBhdmFpbGFibGUuDQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiAgICAgICAgIFRoaXMg Y291bGQgYmUgc2FpZCB0byBpbnRyb2R1Y2UgYSBsb2dpY2FsIGRpc2Nvbm5lY3QsDQo+PiBi dXQgd2UNCj4+ID4+Pj4gPiA+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRoYXQgcGF0 aCBieSB0aGUgZmFjdCB0aGF0IHRoZQ0KPj4gc3RhdGVtZW50DQo+PiA+Pj4+ID4gPj4gYWxz byBpbmNsdWRlcyB0aGUgY2FzZSB3aGVyZSAoZm9yIHNvbWUgcmVhc29uKSB0aGVyZSBpcyBh DQo+PiBjYXNlIGluDQo+PiA+Pj4+ID4gPj4gd2hpY2ggc29tZSBvdGhlciBhZGRyZXNzaW5n IHNjaGVtZSBtaWdodCBiZSBwcmVmZXJyZWQuICBJbg0KPj4gbWFueSBvZg0KPj4gPj4+PiA+ ID4+IHRoZSBjYXNlcyB3aGVyZSBhbm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBw cmVmZXJyZWQsDQo+PiBpdCBpcw0KPj4gPj4+PiA+ID4+IHN0aWxsIHBvc3NpYmxlIChpbiBm YWN0IGxpa2VseSkgdGhhdCBJUCBhZGRyZXNzaW5nIGlzDQo+PiBhdmFpbGFibGUuDQo+PiA+ Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiAgICAgICAgIE90aGVyd2lzZSwgaXQgd291bGQgbm90 IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8NCj4+IGRpc3Rpbmd1aXNoDQo+PiA+Pj4+ID4gPj4g dGhpcyBjYXNlIGZyb20gdGhlIG9uZSBpbiB3aGljaCBJUCBhZGRyZXNzaW5nIGlzIG5vdA0K Pj4gYXZhaWxhYmxlLg0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gICAgICAgICBGb3Ig dGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVzc2luZyBpcyBub3QgdGhlIHByZWZlcnJlZA0KPj4g bW9kZSwNCj4+ID4+Pj4gPiA+PiB3ZSBhcmUgcmVjb21tZW5kaW5nIGEgbW9kZSBpbiB3aGlj aCBpdCBpcyBub3QgbmVjZXNzYXJ5Lg0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gICAg ICAgICBXaXRoIHJlZ2FyZCB0byBoYXZpbmcgYWRkcmVzc2VzIGxvY2F0ZWQgaW4gdGhlIHNh bWUNCj4+IHBsYWNlLA0KPj4gPj4+PiA+ID4+IHRoaXMgcHJvdG9jb2wgaXMgbWVhbnQgZm9y IGNvbm5lY3Rpdml0eSB0ZXN0aW5nIG9uIGFuIG9uLQ0KPj4gZGVtYW5kDQo+PiA+Pj4+ID4g Pj4gYmFzaXMgYW5kIGlzIHRoZXJlZm9yZSBub3Qgb3B0aW1pemVkIGZvciBwcm9jZXNzaW5n IGluDQo+PiBoYXJkd2FyZS4NCj4+ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+ICAgICAgICAg V2hldGhlciBhZGRyZXNzZXMgb3IgaWRlbnRpZmllcnMsIGlmIHdlIGFyZSB0YWxraW5nDQo+ PiBhYm91dA0KPj4gPj4+PiA+ID4+IFRMViBjb250ZW50cywgdGhlcmUgYXJlIGlzc3VlcyB3 aXRoIHRyeWluZyB0byBndWFyYW50ZWUNCj4+IGxvY2F0aW9uDQo+PiA+Pj4+ID4gPj4gb2Yg c3BlY2lmaWMgY29udGVudCwgYmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4N Cj4+IHF1ZXN0aW9uDQo+PiA+Pj4+ID4gPj4gd2lsbCBwcm9iYWJseSBmb2xsb3cgb3RoZXIg VExWcyAtIHRodXMgbWFraW5nIGxvY2F0aW9ucw0KPj4gZGlmZmljdWx0DQo+PiA+Pj4+ID4g Pj4gdG8gcHJlZGljdCBpbiBhbnkgY2FzZS4NCj4+ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+ ICAgICAgICAgV2l0aCByZWdhcmQgdG8gbmVlZGluZyBtb3JlIHRleHQgb24gcGVyLWludGVy ZmFjZQ0KPj4gTUlQcywgZG8NCj4+ID4+Pj4gPiA+PiB5b3UgaGF2ZSBzcGVjaWZpYyBzdWdn ZXN0aW9ucyBhcyB0byB3aGF0IHRleHQgd2UgbWlnaHQgYWRkPw0KPj4gPj4+PiA+ID4+DQo+ PiA+Pj4+ID4gPj4gICAgICAgICBJIHVuZGVyc3RhbmQgKGZyb20gZGlzY3Vzc2lvbiB3aXRo IFdHIGNoYWlycykgdGhhdCB3ZQ0KPj4gYXJlDQo+PiA+Pj4+ID4gPj4gbm90IGFsbG93ZWQg dG8gZXhwbGljaXRseSBhZGRyZXNzIGxhc3QgY2FsbCBjb21tZW50cyBkdXJpbmcNCj4+IHRo ZQ0KPj4gPj4+PiA+ID4+IElFVEYgbWVldGluZyBpbiBQcmFndWUsIGJlY2F1c2UgdGhlIGxh c3QgY2FsbCBpcyBzdGlsbA0KPj4gb25nb2luZw0KPj4gPj4+PiA+ID4+IGF0IHRoYXQgdGlt ZS4NCj4+ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+IC0tDQo+PiA+Pj4+ID4gPj4gRXJpYw0K Pj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gUFMgLQ0KPj4gPj4+PiA+ID4+IEZyb20gUkZD IDIxMTkgLQ0KPj4gPj4+PiA+ID4+ICdTSE9VTEQgICBUaGlzIHdvcmQsIG9yIHRoZSBhZGpl Y3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbg0KPj4gdGhhdCB0aGVyZQ0KPj4gPj4+PiA+ID4+ ICAgICAgICAgICBtYXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1 bXN0YW5jZXMNCj4+IHRvDQo+PiA+Pj4+ID4gPj4gICAgICAgICAgIGlnbm9yZSBhIHBhcnRp Y3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucw0KPj4gbXVzdA0KPj4gPj4+ PiA+ID4+ICAgICAgICAgICBiZSB1bmRlcnN0b29kIGFuZCBjYXJlZnVsbHkgd2VpZ2hlZCBi ZWZvcmUgY2hvb3NpbmcNCj4+IGENCj4+ID4+Pj4gPiA+PiAgICAgICAgICAgZGlmZmVyZW50 IGNvdXJzZS4nDQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPj4+PiA+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZg0KPj4gPj4+PiA+ IE9mDQo+PiA+Pj4+ID4gPj4gUm9sZiBXaW50ZXINCj4+ID4+Pj4gPiA+PiBTZW50OiBUdWVz ZGF5LCBNYXJjaCAyMiwgMjAxMSA0OjU3IEFNDQo+PiA+Pj4+ID4gPj4gVG86IGxvYUBwaS5u dTsgbXBsc0BpZXRmLm9yZw0KPj4gPj4+PiA+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29y a2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLQ0KPj4gbXBscy10cC1vbi0NCj4+ ID4+Pj4gPiA+PiBkZW1hbmQtY3YtMDMNCj4+ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+IEhp LA0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gc29tZSBjb21tZW50cyBiZWxvdzoNCj4+ ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFp biBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zDQo+PiBJUA0KPj4gPj4+PiA+ID4+IGFk ZHJlc3NpbmcgbWlnaHQgbm90IGJlDQo+PiA+Pj4+ID4gPj4gICAgYXZhaWxhYmxlIG9yIGl0 IG1heSBiZSBwcmVmZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tDQo+PiBJUA0KPj4g Pj4+PiA+ID4+ICAgIGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJh Y2luZyBhbmQgQkZEDQo+PiBwYWNrZXRzLg0KPj4gPj4+PiA+IEluDQo+PiA+Pj4+ID4gPj4g ICAgc3VjaCBzY2VuYXJpb3MsIE9uLWRlbWFuZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBT SE9VTEQNCj4+IGJlIHJ1bg0KPj4gPj4+PiA+ID4+ICAgIHdpdGhvdXQgSVAgYWRkcmVzc2lu Zy4uLiINCj4+ID4+Pj4gPiA+Pg0KPj4gPj4+PiA+ID4+IEkgYW0gbm90IHN1cmUgdGhlICJT SE9VTEQiIGlzIHJpZ2h0IGhlcmUuIElmIG5vIElQIGFkZHJlc3NpbmcNCj4+IGlzDQo+PiA+ Pj4+ID4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhvdXQgSVAg YWRkcmVzc2luZywNCj4+IG11c3RuJ3QgaXQ/DQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+ PiBJIHRoaW5rIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHJlZ2FyZGluZyBwZXItaW50ZXJmYWNl IE1JUA0KPj4gYWRkcmVzc2luZw0KPj4gPj4+PiA+ID4+IHdvdWxkIGJlIG5pY2UuIEFzIGZh ciBhcyBJIHVuZGVyc3RhbmQgdGhlIGRvY3VtZW50LCBhbGwgVExWcw0KPj4gd2lsbCBiZQ0K Pj4gPj4+PiA+ID4+IGluc2lkZSB0aGUgTFNQIHBpbmcgcGFja2V0IChyYXRoZXIgdGhhbiBh cyBBQ0ggVExWcykuDQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiBTb21lIHBlb3BsZSBo YWQgY29uY2VybnMgZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9ybWF0aW9uDQo+PiBz aG91bGQNCj4+ID4+Pj4gPiBiZQ0KPj4gPj4+PiA+ID4+IGluIGEgZml4ZWQgbG9jYXRpb24g Zm9yIGVhc2llciBwcm9jZXNzaW5nLiBJcyB0aGlzIHRoZSBjYXNlDQo+PiBoZXJlIEkNCj4+ ID4+Pj4gPiA+PiB3b25kZXI/DQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiBJdCB3b3Vs ZCBiZSBuaWNlIGlmIHlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgaW4geW91cg0KPj4gcHJlc2Vu dGF0aW9uIGluDQo+PiA+Pj4+ID4gPj4gUHJhZ3VlLg0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ ID4gPj4gVGhhbmtzLA0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4gUm9sZg0KPj4gPj4+ PiA+ID4+DQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiBORUMgRXVyb3BlIExpbWl0ZWQg fCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhDQo+PiBSb2FkLA0K Pj4gPj4+PiA+ID4+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgz MjAxNA0KPj4gPj4+PiA+ID4+DQo+PiA+Pj4+ID4gPj4NCj4+ID4+Pj4gPiA+PiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+Pj4+ID4gPj4gPiBGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+PiBPbg0KPj4g Pj4+PiA+IEJlaGFsZg0KPj4gPj4+PiA+ID4+IE9mDQo+PiA+Pj4+ID4gPj4gPiBsb2FAcGku bnUNCj4+ID4+Pj4gPiA+PiA+IFNlbnQ6IE1pdHR3b2NoLCAxNi4gTeRyeiAyMDExIDAwOjI2 DQo+PiA+Pj4+ID4gPj4gPiBUbzogbXBsc0BpZXRmLm9yZw0KPj4gPj4+PiA+ID4+ID4gQ2M6 IE1QTFMtVFAgYWQgaG9jIHRlYW0NCj4+ID4+Pj4gPiA+PiA+IFN1YmplY3Q6IFttcGxzXSBX b3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBscy0NCj4+IHRwLW9uLQ0K Pj4gPj4+PiA+ID4+IGRlbWFuZC0NCj4+ID4+Pj4gPiA+PiA+IGN2LTAzDQo+PiA+Pj4+ID4g Pj4gPg0KPj4gPj4+PiA+ID4+ID4gV29ya2luZyBHcm91cCwNCj4+ID4+Pj4gPiA+PiA+DQo+ PiA+Pj4+ID4gPj4gPiB0aGlzIGlzIHRvIHN0YXJ0IGEgMyB3ZWVrIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIG9uDQo+PiA+Pj4+ID4gPj4gPg0KPj4gPj4+PiA+ID4+ID4gZHJhZnQtaWV0 Zi1tcGxzLXRwLW9uLWRlbWFuZC1jdi0wMw0KPj4gPj4+PiA+ID4+ID4NCj4+ID4+Pj4gPiA+ PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdA0KPj4gPj4+PiA+ID4+ID4gbXBsc0BpZXRmLm9yZw0KPj4gPj4+PiA+ID4+ID4NCj4+ ID4+Pj4gPiA+PiA+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEFwcmls IDgsIDIwMTEuDQo+PiA+Pj4+ID4gPj4gPg0KPj4gPj4+PiA+ID4+ID4gL0xvYQ0KPj4gPj4+ PiA+ID4+ID4NCj4+ID4+Pj4gPiA+PiA+DQo+PiA+Pj4+ID4gPj4gPg0KPj4gPj4+PiA+ID4+ ID4NCj4+ID4+Pj4gPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+Pj4+ID4gPj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPj4gPj4+ PiA+ID4+ID4gbXBsc0BpZXRmLm9yZw0KPj4gPj4+PiA+ID4+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiA+Pj4+ID4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+Pj4gPiA+PiBtcGxz IG1haWxpbmcgbGlzdA0KPj4gPj4+PiA+ID4+IG1wbHNAaWV0Zi5vcmcNCj4+ID4+Pj4gPiA+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ID4+Pj4g PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+Pj4gPiA+bXBscyBtYWlsaW5nIGxpc3QNCj4+ID4+Pj4gPiA+bXBsc0BpZXRmLm9yZw0K Pj4gPj4+PiA+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4+ID4+Pj4gPiA+DQo+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiA+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+PiA+Pj4+IG1w bHNAaWV0Zi5vcmcNCj4+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo+PiA+Pj4NCj4+ID4+DQo+PiA+DQo+DQo= --GMAILSMTPBOUND01110517185209-- From DanielC@orckit.com Tue May 17 06:14:07 2011 Return-Path: <DanielC@orckit.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 59AE8E073E for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 06:14:07 -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=[AWL=0.001, 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 mhKPvYfAEJhB for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 06:14:06 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40F46E076B for <mpls@ietf.org>; Tue, 17 May 2011 06:14:05 -0700 (PDT) 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, 17 May 2011 16:14:01 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0CE11@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwLP6XV1miX2H8qoEK7H055dP9t5wJU/z+A X-Priority: 1 priority: Urgent Importance: high From: "Daniel Cohn" <DanielC@orckit.com> To: "mpls" <mpls@ietf.org> Subject: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" 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: Tue, 17 May 2011 13:14:07 -0000 Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel From eric.gray@ericsson.com Tue May 17 07:13:01 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 D9A1DE0816 for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 07:13:01 -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 hU8lDNp9C8av for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 07:12:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CE87DE076D for <mpls@ietf.org>; Tue, 17 May 2011 07:12:58 -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 p4HECkXx021301; Tue, 17 May 2011 09:12:47 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 17 May 2011 10:12:42 -0400 From: Eric Gray <eric.gray@ericsson.com> To: "hideki.endo.es@hitachi.com" <hideki.endo.es@hitachi.com> Date: Tue, 17 May 2011 10:12:39 -0400 Thread-Topic: Re[2]: [mpls] Working Group Last Call ondraft-ietf-mpls-tp-on-demand-cv- Thread-Index: AcwUeB0cwfrdPhJjQiakjCRYcHrvLwAHl+Wg Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F10B0755212D@EUSAACMS0701.eamcs.ericsson.se> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C7563@EUSAACMS0701.eamcs.er> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C756D@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001118U4d907aaa@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C759B@EUSAACMS0701.eamcs.er> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> <XNM1$7$0$0$$6$1$2$A$5001140U4d934d10@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B06679157@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001143U4d93a3de@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B0667959B@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001145U4d941dcc@hitachi.com> <A3C5DF08D38B6049839A6F553B331C76D722D074F7@ILPTMAIL02.ecitele.co> <C0AC8FAB6849AB4FADACCC70A949E2F10B066795AF@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001320U4dd2452b@hitachi.com> In-Reply-To: <XNM1$7$0$0$$6$1$2$A$5001320U4dd2452b@hitachi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] Working Group Last Call ondraft-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 <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: Tue, 17 May 2011 14:13:02 -0000 Hideki, Thanks for your detailed review and comments on this text. The wording you refer to needs to be clarified. But then this section (section 2) is modified to accommodate comments we received during the last call in any case. I believe the intention is either a destination identifier or downstream mapping TLV will be used. A source identifier may also be included. Note that both destination identifier and DSMAP/DDMAP TLVs could be included, but this seems a recipe for a forced failure as a result of inconsistency in possibly redundant information. Inclusion of any or all of these meams that they SHOULD be used for verification by the receiver. For the case where the DSMAP/DDMAP TLV is used, the state- ment to which you refer applies. To clarify this, we should add some text to the effect that "when the DSMAP/DDMAP TLV is used, ..." This results in a pile-up of qualifiers, since we already say "When sending On-demand CV packets using ACH, without IP en- capsulation, ..." - but it is clear from your question that the additional qualifier may also be needed. Note that - in many RFCs written previously - the text in any section of the RFC is not meant to be applied except in the context of that section. Hence we could say that the qualifier I describe adding above is implicit from context. As far as ignoring it, it is not clear how you came to this conclusion based on the text. But I think we can clarify this a little bit by again making it clear that - control plane checks include information included in either identifier or DSMAP/DDMAP TLVs in the non-IP case. Note that it's not obvious what else we might refer to as a "control plane" - for verification purposes - in the non-IP case, otherwise. How does one do "signaling" (in the sense that we mean to apply in the "MPLS control plane") if it is not IP-based? In this case, the "control entity" is the entity identified by either an identifier or a DSMAP/DDMAP TLV. -- Eric -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Tuesday, May 17, 2011 5:52 AM To: Eric Gray Cc: Alexander.Vainshtein@ecitele.com; Manuel.Paul@telekom.de; Rolf.Winter@n= eclab.eu; mpls@ietf.org; aldrin.ietf@gmail.com Subject: Re[2]: [mpls] Working Group Last Call ondraft-ietf-mpls-tp-on-dema= nd-cv- Importance: High Hi Eric, It was good opportunity for us to discuss about Per-IF MIP at Pargue. In that week, you put reply to me on ML as below; > >> 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). After that, I'v read both of RFC 4379 and draft-ietf-mpls-on-demand-cv in d= etail. As the result, I'd like to clarify some points as below; (1)draft-on-demand-cv says in 2.1.1. that "When sending On-demand CV packets using ACH, without IP encapsulation, the following information MUST be included in any (source/destination) TLV that is included in the packet.". Here, "the following information" is DSMAP/DDMAP address TLV which has address type "5". Furthermore, the draft also describes in 2.1. that "When this address type is used, on receipt of a LSP-Ping echo request, interface verification MUST be bypassed. Thus the receiving node SHOULD only perform mpls label control-plane/data-plane consistency checks. Here, "this address type" is "5". In my understanding from these two descriptions, a DSMAP/DDMAP MUST be included in an echo request, when using ACH without IP/UDP. However, on receipt of the echo request, the DSMAP/DDMAP MUST be ignored. is this understanding correct? (2)If above is yes, is it possible to achieve Per-IF MIP by single route-trace as you said? BR, Hideki >Sasha, > > It is not precluded. As Hideki correctly points out, ingress >to mid-point connectivity verification is a requirement in RFC 5860. > > Since the same message is used in both Traceroute and CV, in >the case where you want to do a continuity check from LSP ingress to >some device between the ingress and egress for the LSP (i.e. - a MIP), >implementations would do it in the same way that you do Traceroute - >with the exception that you would do it only with the intended TTL >(as opposed to starting with 1 and incrementing it until you get a >("Ping") response from the intended LSP egress. > > As I explained to Hideki, it is largely a matter of personal >preference whether you think of this as a Traceroute or TTL-limited >CV message. > > Note that CV is explicitly not included in requirements for >the case where one might want to test MIP-to-MEP. > >-- >Eric > >-----Original Message----- >From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >Sent: Thursday, March 31, 2011 2:44 AM >To: hideki.endo.es@hitachi.com; Eric Gray >Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu; mpls@ietf.org; aldrin.i= etf@gmail.com >Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-deman= d-cv- >Importance: High > >Hideki, Eric, and all, >I believe that ability to do ping MEP-to-MIP should not be precluded (at l= east for co-routed bidirectional LSPs). > > >Regards, > Sasha > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf 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 route. >> >> 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 >> <snipped> >> 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 >> <snipped> >> 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, and >> 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-demand 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-map, >> 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 path and >> fate-sharing requirement. >> >>> >> >>> >> >>>I second the proposal initially made by Rolf, to include additional >> text to document the per-interface MIP addressing for the on-demand-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] On >> 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 which >> needs a >> >>>> closer look in this regard (which I hinted at earlier), which 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 engine. >> 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 line >> 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 for >> performance >> >>>> monitoring. >> >>>> >> >>>> Best, >> >>>> >> >>>> Rolf >> >>>> >> >>>> >> >>>> >> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> 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 discussion. >> >>>> > 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 path. >> >>>> > >> >>>> > Therefore, we should take the HW aspect and flexibilty into >> 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 specifications >> >>>> > >that require ordering of TLVs. In particular, this is not very >> >>>> > >robust in terms of "future-proofing." What happens if new TLVs >> >>>> > >are added later on; for instance, suppose at some point we have >> >>>> > >multiple "address" TLVs? >> >>>> > > >> >>>> > > Also, the fact that implementations are allowed to attach >> >>>> > >TLVs in any arbitrary order allows considerable flexibilty in >> >>>> > >implementation. Messages can be built in arbitrarily many >> 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 we 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. In case >> there >> >>>> > is no IP you simply cannot use it. You say you could enable 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 might >> not be >> >>>> > available. In those cases On-demand CV and/or route tracing MUST >> be run >> >>>> > without IP addressing, using the ACH channel type specified in >> Section >> >>>> > 3. In other cases it might be available, however, it may be >> 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 could 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 reason >> to >> >>>> > deliberately not do it. >> >>>> > > >> >>>> > >Best, >> >>>> > > >> >>>> > >Rolf >> >>>> > > >> >>>> > > >> >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> 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-ietf- >> 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 consistent >> with >> >>>> > >> this case. If - for some reason - one had a really good >> 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 disconnect, >> but we >> >>>> > >> are saved from going down that path by the fact that the >> 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 preferred, >> 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 preferred >> 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 on- >> demand >> >>>> > >> basis and is therefore not optimized for processing in >> hardware. >> >>>> > >> >> >>>> > >> Whether addresses or identifiers, if we are talking >> about >> >>>> > >> TLV contents, there are issues with trying to guarantee >> location >> >>>> > >> of specific content, because of the fact that the TLV in >> question >> >>>> > >> will probably follow other TLVs - thus making locations >> difficult >> >>>> > >> to predict in any case. >> >>>> > >> >> >>>> > >> With regard to needing more text on per-interface >> MIPs, do >> >>>> > >> you have specific suggestions as to what text we might add? >> >>>> > >> >> >>>> > >> I understand (from discussion with WG chairs) that we >> are >> >>>> > >> not allowed to explicitly address last call comments during >> 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", mean >> that there >> >>>> > >> may exist valid reasons in particular circumstances >> to >> >>>> > >> ignore a particular item, but the full implications >> must >> >>>> > >> be understood and carefully weighed before choosing >> a >> >>>> > >> different course.' >> >>>> > >> >> >>>> > >> -----Original Message----- >> >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 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-ietf- >> mpls-tp-on- >> >>>> > >> demand-cv-03 >> >>>> > >> >> >>>> > >> Hi, >> >>>> > >> >> >>>> > >> some comments below: >> >>>> > >> >> >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios >> 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 BFD >> packets. >> >>>> > In >> >>>> > >> such scenarios, On-demand CV and/or route tracing SHOULD >> be run >> >>>> > >> without IP addressing..." >> >>>> > >> >> >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing >> is >> >>>> > >> available, this thing MUST be run without IP addressing, >> mustn't it? >> >>>> > >> >> >>>> > >> I think some additional text regarding per-interface MIP >> 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 information >> 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 Victoria >> 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 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 >> >>>> > >> _______________________________________________ >> >>>> > >> 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 Bill.Armstrong@chartercom.com Thu May 12 10:49:28 2011 Return-Path: <Bill.Armstrong@chartercom.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 33A02E074B for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 10:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, 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 7oENAHar39KM for <mpls@ietfa.amsl.com>; Thu, 12 May 2011 10:49:27 -0700 (PDT) Received: from mail.chartercom.com (mail.chartercom.com [24.217.29.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6183EE0679 for <mpls@ietf.org>; Thu, 12 May 2011 10:49:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,359,1301893200"; d="jpg'145?scan'145,208,217,145";a="155405976" Received: from unknown (HELO KSTLMEXHTP01.CORP.CHARTERCOM.COM) ([192.168.31.33]) by mail.chartercom.com with ESMTP; 12 May 2011 12:49:26 -0500 Received: from KSTLMEXCP02MBX.CORP.CHARTERCOM.COM ([192.168.31.12]) by KSTLMEXHTP01.CORP.CHARTERCOM.COM ([192.168.31.33]) with mapi; Thu, 12 May 2011 12:49:26 -0500 From: "Armstrong, Bill R" <Bill.Armstrong@chartercom.com> To: "mpls@ietf.org" <mpls@ietf.org> Date: Thu, 12 May 2011 12:49:24 -0500 Thread-Topic: RE: [mpls] poll on draft-asati-pignataro-mpls-ldp-gtsm-01 Thread-Index: AcwQzO57ZYrAFW6UQd+7l17RVOp7bg== Message-ID: <76D95D4AE780344FA285A7896678477C02767E99@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_"; type="multipart/alternative" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 May 2011 07:14:57 -0700 Subject: Re: [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 <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: Thu, 12 May 2011 17:49:28 -0000 --_004_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_ Content-Type: multipart/alternative; boundary="_000_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_" --_000_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! Thanks, [cid:image001.jpg@01CC10A3.05A16A40] Bill Armstrong | Principal Engineer I | 314.543.2504 Charter Communications - 12405 Powerscourt Drive, St. Louis, MO 63131 E-MAIL CONFIDENTIALITY NOTICE:=20 =20 =20 =20 The contents of this e-mail message and=20 any attachments are intended solely for the=20 addressee(s) and may contain confidential=20 and/or legally privileged information. If you=20 are not the intended recipient of this message=20 or if this message has been addressed to you=20 in error, please immediately alert the sender by reply e-mail and then delete this message=20 and any attachments. If you are not the=20 intended recipient, you are notified that=20 any use, dissemination, distribution, copying,=20 or storage of this message or any attachment=20 is strictly prohibited. --_000_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUI= V=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"><meta name=3DG= enerator content=3D"Microsoft Word 12 (filtered medium)"><!--[if !mso]><sty= le>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Support!<o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thank= s,<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal><span style=3D'color:#1F497D'><img width=3D101 height=3D24 id=3D"Pictu= re_x0020_1" src=3D"cid:image001.jpg@01CC10A3.05A16A40" alt=3D"Charter_Logo"= ><o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:4.0pt;= color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal>Bill Armstr= ong | Principal Engineer I | 314.543.2504<o:p></o:p></p><p class=3DMsoNorma= l>Charter Communications - 12405 Powerscourt Drive,   St. Louis,&= nbsp;  MO  63131<o:p></o:p></p><p class=3DMsoNormal><o:p> </= o:p></p></div><font face=3D"monospace"><br> E-MAIL CONFIDENTIALITY NOTICE: <br> <br> <br> <br> <br> <br> <br> <br> The contents of this e-mail message and <br> any attachments are intended solely for the <br> addressee(s) and may contain confidential <br> and/or legally privileged information. If you <br> are not the intended recipient of this message <br> or if this message has been addressed to you <br> in error, please immediately alert the sender<br> by reply e-mail and then delete this message <br> and any attachments. If you are not the <br> intended recipient, you are notified that <br> any use, dissemination, distribution, copying, <br> or storage of this message or any attachment <br> is strictly prohibited.<br> <br> <br> <br> <br> <br> <br> </font></body></html> --_000_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_-- --_004_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1613; creation-date="Thu, 12 May 2011 12:49:25 GMT"; modification-date="Thu, 12 May 2011 12:49:25 GMT" Content-ID: <image001.jpg@01CC10A3.05A16A40> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAYAGUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1HWb2 6gghg08RG8u5PLiMv3U4JZyB1AA6fSub13RdTt9Fu77VPFl83kxM4S3VYVJ7DA5PNal1C63siWxu f3J6WxV/L3DPRuVyPQ1x/jszJZW1mLacXF9MFV55dzsB/sjgDJFTSqSdRQSOWtL3W2bHwrsZk0a6 1KdnZ7yXC72JyF4zz7k/lWrrXie8j1f+xNBsVvtQVd8pdtscCnpuPr7Vc8OafPo9lFp0iEJFGACr blJ7nnkZ9KyfBOw614lM2Ptf28789dmPl/DrW/MpuU2OKcYRgtCSDV/FtrK8Wq6PbNGYXdbq1fKR lVz8wNaPhrXP7R8O2F7qE8EdzdR7iu4KCckcAmtDVf8AkEXmP+feT/0E1xHg/wAEaLqfhG2u9Qtz cXF1GSJGc5iGSAF9MUe7KN3oN88ZWWvqegl1VSzEBR1JOMUyK5gnyYZo5cddjA4/KvM7e/sbjwja adrEd5qc8d9JDbW8DkSTBDgBj6AGo0X+yPEekXFl4cvNC825EMoeXdHMrdiM9afsugnX62PT2urd U8wzRhM43FxjPpWNZeJ4LnxBqWmSeTDHZBCsxmH7zcOR+Fcl4J8J2ms2kt9qjSTwxXci21vvIRCG yWwO5P8AKptO8J6Ff+Ndes7mwWSC3ETxoXb5SwJbv3NHJFXTewvaVHytLc9Alu7eBQ008Uat90u4 GfpmnNNEqB2dQh6MSAPzryexvNG1O7vL3XtJ1HUm81oreOKFnigjXgKMHrUF1NOvhjV9PgivY7CK 5gksRdxlWTLcrz6Gn7HWwvrGl7Hrkl7awtsluYo267WcA0VzNj8PNDW2V9Sga/vJBumnmkYlm79+ BRWdodzW9V9EWtV07WLLUJNW0OSOVpQv2ixm4WbaMAq38LY49DXL2El34u+I8F1d6fNZw6XFloZR yjds/UnP0FFFaQfutmdSPvxXS56UBXMa14Yvm1g65oF6lnfsuyZJVzFOB03D1oorFSa1R0SipLUj g0nxZfTtLq2q20MQidFtbVDtkLKR8xPOK1vDOlzaL4cstNuHR5bePazJnaeSeM0UU3NtWJjBJ3OZ h8DaraQQXVnf28WpWl3NNExUmNkkPKt3BqWfw54p1bUNPvNWv7FUsrhZRbwKwXA6nPc0UVXtZE+x ibfhTRbjQdIezuZI5Ha4kl3R5xhmyOtZ2o6Dr1v4hutV0C7tE+3IiTpcqTtKjAYYooqVN3b7lOnH lt2Ih4d8RaJdzzeHr20MF23mTWt0p2pIfvMhHYntSXnhTXdS0K4t7/WEuby5uIpSCCsMIU5wg69K KKftGL2UVodkOgoooqDU/9k= --_004_76D95D4AE780344FA285A7896678477C02767E99KSTLMEXCP02MBXC_-- From gregimirsky@gmail.com Tue May 17 18:07:33 2011 Return-Path: <gregimirsky@gmail.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 0A8D1E0854 for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJnRQ0mq5tFT for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 18:07:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18223E0853 for <mpls@ietf.org>; Tue, 17 May 2011 18:07:31 -0700 (PDT) Received: by vxg33 with SMTP id 33so912353vxg.31 for <mpls@ietf.org>; Tue, 17 May 2011 18:07: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 :content-type; bh=2kJrPykGVKr3dcGWNGof5v4Bh60ORfSxLLohqjNlwvo=; b=FlysMYNT253/dzbhG7e/zW/Hxl3rKgSXc5jMiTtV1vP1sBOrUASa5US3xZ90WYgajs 7yXtU2ovepaRnRd7mNUivpXg9c9uuOo4u8HeAPf8sciOZMJmRJuLuahwKyQJax5j+QIJ 1K+LN4OrijbQ7tOA916EPFP5ox4xaS9k505pM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iENfVlZjK3u0NOGD5cZne7uUkLoi2khuDaZcLSYQE9CQrwKFluFbiCwY8x0rLjXqVI 6blij40CyyuWwculCW8L3ZmBklszOJ69671KRenpTbRBGHya8l2IV4idrHI6Fe/5kTF6 b/K5NbI7mF+tLUH8LM0VUq0JQAuVTmWvlFi6s= MIME-Version: 1.0 Received: by 10.52.116.10 with SMTP id js10mr1760880vdb.256.1305680851234; Tue, 17 May 2011 18:07:31 -0700 (PDT) Received: by 10.52.156.228 with HTTP; Tue, 17 May 2011 18:07:31 -0700 (PDT) Date: Tue, 17 May 2011 18:07:31 -0700 Message-ID: <BANLkTi=KXXWr163kEYaV6Xoa67hO+iW0Qg@mail.gmail.com> From: Greg Mirsky <gregimirsky@gmail.com> To: Dan Frost <danfrost@cisco.com>, stbryant@cisco.com, mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec548668e53efa704a38283a3 Subject: [mpls] Possible future use of IEEE 1588v2 tiemstamp format in LM/DM 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, 18 May 2011 01:07:33 -0000 --bcaec548668e53efa704a38283a3 Content-Type: text/plain; charset=ISO-8859-1 Dear Dan and Stewart, probably it was already discussed and I apologize upfront for not finding right thread in archive. My question is to possible future use of IEEE1588 v2 timestamp format which uses 48 bits for second counter and, as in PTPv1, 32 bit for nanosend counter. Could the last paragraph of Appendix A that refers to truncated format of IEEE1588 PTP be applied to PTP v2 case? How then interpret Timestamp Type? As 'IEEE1588 version 1 Timestamp' or 'IEEE1588 Timestamp'? If former, as in the current document, then how IEEE1588 v2 format will be different from v1 if timestamps must fit into 64 bits? Or Timestamp Type in this case used only to negotiate the source of a timestamp? Regards, Greg --bcaec548668e53efa704a38283a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Dan and Stewart,<br>probably it was already discussed and I apologize = upfront for not finding right thread in archive.<br>My question is to possi= ble future use of IEEE1588 v2 timestamp format which uses 48 bits for secon= d counter and, as in PTPv1, 32 bit for nanosend counter. Could the last par= agraph of Appendix A that refers to truncated format of IEEE1588 PTP be app= lied to PTP v2 case? How then interpret Timestamp Type? As 'IEEE1588 ve= rsion 1 Timestamp' or 'IEEE1588 Timestamp'? If former, as in th= e current document, then how IEEE1588 v2 format will be different from v1 i= f timestamps must fit into 64 bits? Or Timestamp Type in this case used onl= y to negotiate the source of a timestamp?<br> <br>Regards,<br>Greg<br> --bcaec548668e53efa704a38283a3-- From gregimirsky@gmail.com Tue May 17 21:44:14 2011 Return-Path: <gregimirsky@gmail.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 482A4E06D4; Tue, 17 May 2011 21:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQcqgxWeJPPy; Tue, 17 May 2011 21:44:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3CE0681; Tue, 17 May 2011 21:44:12 -0700 (PDT) Received: by vws12 with SMTP id 12so1014918vws.31 for <multiple recipients>; Tue, 17 May 2011 21:44:12 -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=mTTCeVn7AzCm84p7I4QQF6QMFs7zRbzGs+AkeROEDWg=; b=HZa+Myc8M8g/Urt6285UEl1dLwQW5qMOHiZ5+SOS1cmwRXyu2FT0B6glT2Q4QR3G5i 49LubAxT/PXF1l6yO76XF6RPyvxdEI4o7pi7LmAgcG5Nt5aEpVZ0Sb6SvnKAcqEwtoUL N/Rh4OWbUg/v9LPHNFDl4FwkQHpEXmIMpey78= 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=i6aRiKZKPC0xdB5hEv2h4VJbF1pCmmXp/4Xzk09dYscSGcd4zlhRUWoSW2khSixu2g 2ngb+BFteWSTOXt5QasOpo1PCR/fdRFfpToZpd1APL3hkMJfIpho2JvRELGFsMOW7k2K KZsgnO9KvfOIJcKZNMhvh8Jvro7fyhY6eTFXI= MIME-Version: 1.0 Received: by 10.52.0.69 with SMTP id 5mr1978977vdc.96.1305693852022; Tue, 17 May 2011 21:44:12 -0700 (PDT) Received: by 10.52.156.228 with HTTP; Tue, 17 May 2011 21:44:11 -0700 (PDT) Date: Tue, 17 May 2011 21:44:11 -0700 Message-ID: <BANLkTi=fLXmsBiX1-anQojbapAWOqkJV9g@mail.gmail.com> From: Greg Mirsky <gregimirsky@gmail.com> To: "Siva Sivabalan(msiva)" <msiva@cisco.com>, Sami Boutros <sboutros@cisco.com>, Luca Martini <lmartini@cisco.com>, pwe3 <pwe3@ietf.org> Content-Type: multipart/alternative; boundary=20cf304346fe3c374f04a3858aeb Cc: mpls@ietf.org Subject: [mpls] Question on draft-boutros-pwe3-mpls-tp-mac-wd-01 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, 18 May 2011 04:44:14 -0000 --20cf304346fe3c374f04a3858aeb Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, I have a question to the document presented. The question is related to format of PW OAM message as defined in draft-ietf-pwe3-static-pw-status-03: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | TLV Length |A| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Length is 8 bits long and thus combined length of PW OAM TLVs can be only 255 bytes long. That is sufficient for signalling PW Status message. But the limit might force to send multiple PW OAM messages if the list of specific MAC addresses to withdraw grows too long. Perhaps the format of PW OAM message might be changed to use ACH TLV per RFC 5586, have Refresh Timer and PW OAM Flag TLVs. Regards, Greg --20cf304346fe3c374f04a3858aeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,<br>I have a question to the document presented. The q= uestion is related to format of PW OAM message as defined in draft-ietf-pwe= 3-static-pw-status-03:<br><br><pre class=3D"newpage"> 0 = 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | TLV Length |A| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>T= LV Length is 8 bits long and thus combined length of PW OAM TLVs can be onl= y 255 bytes long. That is sufficient for signalling PW Status message. But = the limit might force to send multiple PW OAM messages if the list of speci= fic MAC addresses to withdraw grows too long. Perhaps the format of PW OAM = message might be changed to use ACH TLV per RFC 5586, have Refresh Timer an= d PW OAM Flag TLVs.<br> <br>Regards,<br>Greg<br><br><br><br><br> --20cf304346fe3c374f04a3858aeb-- From hideki.endo.es@hitachi.com Tue May 17 22:56:22 2011 Return-Path: <hideki.endo.es@hitachi.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 53F6EE069D for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 22:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.663 X-Spam-Level: ** X-Spam-Status: No, score=2.663 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=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 11Ru9oo5OHdx for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 22:56:20 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAF8FE067C for <mpls@ietf.org>; Tue, 17 May 2011 22:56:18 -0700 (PDT) Received: from mlsv7.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id D527D37C89; Wed, 18 May 2011 14:56:16 +0900 (JST) Received: from mfilter3.hitachi.co.jp by mlsv7.hitachi.co.jp (8.13.1/8.13.1) id p4I5uGhL000845; Wed, 18 May 2011 14:56:16 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter3.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p4I5u3SV022786; Wed, 18 May 2011 14:56:16 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter3.hitachi.co.jp with RELAY id p4I5uFTZ022880 ; Wed, 18 May 2011 14:56:16 +0900 X-AuditID: b753bd60-a28ceba000006295-36-4dd35f7f26c7 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 36DCB8B02E3; Wed, 18 May 2011 14:56:15 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p4I5uFk29241476; Wed, 18 May 2011 14:56:15 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: <XNM1$7$0$0$$6$1$2$A$5001325U4dd35f47@hitachi.com> Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110518145606" To: <eric.gray@ericsson.com> From: <hideki.endo.es@hitachi.com> Date: Wed, 18 May 2011 14:55:52 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C756D@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001118U4d907aaa@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B065C759B@EUSAACMS0701.eamcs.er> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> <XNM1$7$0$0$$6$1$2$A$5001140U4d934d10@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B06679157@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001143U4d93a3de@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B0667959B@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001145U4d941dcc@hitachi.com> <A3C5DF08D38B6049839A6F553B331C76D722D074F7@ILPTMAIL02.ecitele.co> <C0AC8FAB6849AB4FADACCC70A949E2F10B066795AF@EUSAACMS0701.eamcs.er> <XNM1$7$0$0$$6$1$2$A$5001320U4dd2452b@hitachi.com> <C0AC8FAB6849AB4FADACCC70A949E2F10B0755212D@EUSAACMS0701.eamcs.er> Priority: normal Importance: normal X400-Content-Identifier: X4DD35F4700000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110518145519XAE] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Last_Callondraft-ietf-mpls-tp?= =?iso-8859-1?q?-on-demand-cv-?= 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, 18 May 2011 05:56:22 -0000 --GMAILSMTPBOUND01110518145606 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 RXJpYywNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBwcm9tcHQgcmVzcG9uc2Uu DQpJIGV4cGVjdCB0byBhZGQgc29tZSB0ZXh0IHRvIHRoaXMgZHJhZnQgYXMgeW91IHNhaWQu DQoNCkJSLA0KSGlkZWtpDQoNCg0KPkhpZGVraSwNCj4NCj4gICAgICAgIFRoYW5rcyBmb3Ig eW91ciBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRzIG9uIHRoaXMgdGV4dC4NCj4NCj4g ICAgICAgIFRoZSB3b3JkaW5nIHlvdSByZWZlciB0byBuZWVkcyB0byBiZSBjbGFyaWZpZWQu ICBCdXQgdGhlbg0KPnRoaXMgc2VjdGlvbiAoc2VjdGlvbiAyKSBpcyBtb2RpZmllZCB0byBh Y2NvbW1vZGF0ZSBjb21tZW50cyB3ZQ0KPnJlY2VpdmVkIGR1cmluZyB0aGUgbGFzdCBjYWxs IGluIGFueSBjYXNlLg0KPg0KPiAgICAgICAgSSBiZWxpZXZlIHRoZSBpbnRlbnRpb24gaXMg ZWl0aGVyIGEgZGVzdGluYXRpb24gaWRlbnRpZmllcg0KPm9yIGRvd25zdHJlYW0gbWFwcGlu ZyBUTFYgd2lsbCBiZSB1c2VkLiAgQSBzb3VyY2UgaWRlbnRpZmllciBtYXkNCj5hbHNvIGJl IGluY2x1ZGVkLg0KPg0KPiAgICAgICAgTm90ZSB0aGF0IGJvdGggZGVzdGluYXRpb24gaWRl bnRpZmllciBhbmQgRFNNQVAvRERNQVAgVExWcw0KPmNvdWxkIGJlIGluY2x1ZGVkLCBidXQg dGhpcyBzZWVtcyBhIHJlY2lwZSBmb3IgYSBmb3JjZWQgZmFpbHVyZQ0KPmFzIGEgcmVzdWx0 IG9mIGluY29uc2lzdGVuY3kgaW4gcG9zc2libHkgcmVkdW5kYW50IGluZm9ybWF0aW9uLg0K Pg0KPiAgICAgICAgSW5jbHVzaW9uIG9mIGFueSBvciBhbGwgb2YgdGhlc2UgbWVhbXMgdGhh dCB0aGV5IFNIT1VMRCBiZQ0KPnVzZWQgZm9yIHZlcmlmaWNhdGlvbiBieSB0aGUgcmVjZWl2 ZXIuDQo+DQo+ICAgICAgICBGb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIERTTUFQL0RETUFQIFRM ViBpcyB1c2VkLCB0aGUgc3RhdGUtDQo+bWVudCB0byB3aGljaCB5b3UgcmVmZXIgYXBwbGll cy4gIFRvIGNsYXJpZnkgdGhpcywgd2Ugc2hvdWxkIGFkZA0KPnNvbWUgdGV4dCB0byB0aGUg ZWZmZWN0IHRoYXQgIndoZW4gdGhlIERTTUFQL0RETUFQIFRMViBpcyB1c2VkLA0KPi4uLiIN Cj4NCj4gICAgICAgIFRoaXMgcmVzdWx0cyBpbiBhIHBpbGUtdXAgb2YgcXVhbGlmaWVycywg c2luY2Ugd2UgYWxyZWFkeQ0KPnNheSAiV2hlbiBzZW5kaW5nIE9uLWRlbWFuZCBDViBwYWNr ZXRzIHVzaW5nIEFDSCwgd2l0aG91dCBJUCBlbi0NCj5jYXBzdWxhdGlvbiwgLi4uIiAtIGJ1 dCBpdCBpcyBjbGVhciBmcm9tIHlvdXIgcXVlc3Rpb24gdGhhdCB0aGUNCj5hZGRpdGlvbmFs IHF1YWxpZmllciBtYXkgYWxzbyBiZSBuZWVkZWQuDQo+DQo+ICAgICAgICBOb3RlIHRoYXQg LSBpbiBtYW55IFJGQ3Mgd3JpdHRlbiBwcmV2aW91c2x5IC0gdGhlIHRleHQgaW4NCj5hbnkg c2VjdGlvbiBvZiB0aGUgUkZDIGlzIG5vdCBtZWFudCB0byBiZSBhcHBsaWVkIGV4Y2VwdCBp biB0aGUNCj5jb250ZXh0IG9mIHRoYXQgc2VjdGlvbi4gIEhlbmNlIHdlIGNvdWxkIHNheSB0 aGF0IHRoZSBxdWFsaWZpZXINCj5JIGRlc2NyaWJlIGFkZGluZyBhYm92ZSBpcyBpbXBsaWNp dCBmcm9tIGNvbnRleHQuDQo+DQo+ICAgICAgICBBcyBmYXIgYXMgaWdub3JpbmcgaXQsIGl0 IGlzIG5vdCBjbGVhciBob3cgeW91IGNhbWUgdG8gdGhpcw0KPmNvbmNsdXNpb24gYmFzZWQg b24gdGhlIHRleHQuICBCdXQgSSB0aGluayB3ZSBjYW4gY2xhcmlmeSB0aGlzIGENCj5saXR0 bGUgYml0IGJ5IGFnYWluIG1ha2luZyBpdCBjbGVhciB0aGF0IC0gY29udHJvbCBwbGFuZSBj aGVja3MNCj5pbmNsdWRlIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIGVpdGhlciBpZGVudGlm aWVyIG9yIERTTUFQL0RETUFQDQo+VExWcyBpbiB0aGUgbm9uLUlQIGNhc2UuDQo+DQo+ICAg ICAgICBOb3RlIHRoYXQgaXQncyBub3Qgb2J2aW91cyB3aGF0IGVsc2Ugd2UgbWlnaHQgcmVm ZXIgdG8gYXMgYQ0KPiJjb250cm9sIHBsYW5lIiAtIGZvciB2ZXJpZmljYXRpb24gcHVycG9z ZXMgLSBpbiB0aGUgbm9uLUlQIGNhc2UsDQo+b3RoZXJ3aXNlLiAgSG93IGRvZXMgb25lIGRv ICJzaWduYWxpbmciIChpbiB0aGUgc2Vuc2UgdGhhdCB3ZSBtZWFuDQo+dG8gYXBwbHkgaW4g dGhlICJNUExTIGNvbnRyb2wgcGxhbmUiKSBpZiBpdCBpcyBub3QgSVAtYmFzZWQ/DQo+DQo+ ICAgICAgICBJbiB0aGlzIGNhc2UsIHRoZSAiY29udHJvbCBlbnRpdHkiIGlzIHRoZSBlbnRp dHkgaWRlbnRpZmllZA0KPmJ5IGVpdGhlciBhbiBpZGVudGlmaWVyIG9yIGEgRFNNQVAvRERN QVAgVExWLg0KPg0KPi0tDQo+RXJpYw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRla2kuZW5k by5lc0BoaXRhY2hpLmNvbV0NCj5TZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTEgNTo1MiBB TQ0KPlRvOiBFcmljIEdyYXkNCj5DYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b207IE1hbnVlbC5QYXVsQHRlbGVrb20uZGU7IFJvbGYuV2ludGVyQG5lY2xhYi5ldTsgbXBs c0BpZXRmLm9yZzsgYWxkcmluLmlldGZAZ21haWwuY29tDQo+U3ViamVjdDogUmVbMl06IFtt cGxzXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC1vbi1k ZW1hbmQtY3YtDQo+SW1wb3J0YW5jZTogSGlnaA0KPg0KPkhpIEVyaWMsDQo+DQo+SXQgd2Fz IGdvb2Qgb3Bwb3J0dW5pdHkgZm9yIHVzIHRvIGRpc2N1c3MgYWJvdXQgUGVyLUlGIE1JUCBh dCBQYXJndWUuDQo+SW4gdGhhdCB3ZWVrLCB5b3UgcHV0IHJlcGx5IHRvIG1lIG9uIE1MIGFz IGJlbG93Ow0KPg0KPj4gPj4gICAgICAgIElmIHlvdSB3YW50IHRvIGluY2x1ZGUgc3BlY2lm aWMgaW50ZXJmYWNlIGluZm9ybWF0aW9uLA0KPj4gPj55b3UgY2FuIGluY2x1ZGUgYSBEU01B UCAob3IgRERNQVApIFRMViBhcyBkZWZpbmVkIGJ5IFJGQw0KPj4gPj40Mzc5LCBhbmQgZXh0 ZW5kZWQgYnkgdGhpcyBkcmFmdCAoaW4gY29tYmluYXRpb24gd2l0aCB0aGUNCj4+ID4+ZHJh ZnQgImRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1lbmhhbmNlZC1kc21hcCIgZm9yIERETUFQ KS4NCj4NCj5BZnRlciB0aGF0LCBJJ3YgcmVhZCBib3RoIG9mIFJGQyA0Mzc5IGFuZCBkcmFm dC1pZXRmLW1wbHMtb24tZGVtYW5kLWN2IGluIGRldGFpbC4NCj5BcyB0aGUgcmVzdWx0LCBJ J2QgbGlrZSB0byBjbGFyaWZ5IHNvbWUgcG9pbnRzIGFzIGJlbG93Ow0KPg0KPigxKWRyYWZ0 LW9uLWRlbWFuZC1jdiBzYXlzIGluIDIuMS4xLiB0aGF0DQo+ICAiV2hlbiBzZW5kaW5nIE9u LWRlbWFuZCBDViBwYWNrZXRzIHVzaW5nIEFDSCwgd2l0aG91dCBJUA0KPiAgIGVuY2Fwc3Vs YXRpb24sIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gTVVTVCBiZSBpbmNsdWRlZCBpbiBh bnkNCj4gICAoc291cmNlL2Rlc3RpbmF0aW9uKSBUTFYgdGhhdCBpcyBpbmNsdWRlZCBpbiB0 aGUgcGFja2V0LiIuDQo+ICBIZXJlLCAidGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiIgaXMg RFNNQVAvRERNQVAgYWRkcmVzcyBUTFYNCj4gIHdoaWNoIGhhcyBhZGRyZXNzIHR5cGUgIjUi Lg0KPg0KPiAgRnVydGhlcm1vcmUsIHRoZSBkcmFmdCBhbHNvIGRlc2NyaWJlcyBpbiAyLjEu IHRoYXQNCj4gICJXaGVuIHRoaXMgYWRkcmVzcyB0eXBlIGlzIHVzZWQsIG9uIHJlY2VpcHQg b2YgYSBMU1AtUGluZyBlY2hvDQo+ICAgcmVxdWVzdCwgaW50ZXJmYWNlIHZlcmlmaWNhdGlv biBNVVNUIGJlIGJ5cGFzc2VkLiAgVGh1cyB0aGUgcmVjZWl2aW5nDQo+ICAgbm9kZSBTSE9V TEQgb25seSBwZXJmb3JtIG1wbHMgbGFiZWwgY29udHJvbC1wbGFuZS9kYXRhLXBsYW5lDQo+ ICAgY29uc2lzdGVuY3kgY2hlY2tzLg0KPiAgSGVyZSwgInRoaXMgYWRkcmVzcyB0eXBlIiBp cyAiNSIuDQo+DQo+ICBJbiBteSB1bmRlcnN0YW5kaW5nIGZyb20gdGhlc2UgdHdvIGRlc2Ny aXB0aW9ucywNCj4gIGEgRFNNQVAvRERNQVAgTVVTVCBiZSBpbmNsdWRlZCBpbiBhbiBlY2hv IHJlcXVlc3QsDQo+ICB3aGVuIHVzaW5nIEFDSCB3aXRob3V0IElQL1VEUC4NCj4gIEhvd2V2 ZXIsIG9uIHJlY2VpcHQgb2YgdGhlIGVjaG8gcmVxdWVzdCwNCj4gIHRoZSBEU01BUC9ERE1B UCBNVVNUIGJlIGlnbm9yZWQuDQo+DQo+ICBpcyB0aGlzIHVuZGVyc3RhbmRpbmcgY29ycmVj dD8NCj4NCj4oMilJZiBhYm92ZSBpcyB5ZXMsIGlzIGl0IHBvc3NpYmxlIHRvIGFjaGlldmUg UGVyLUlGIE1JUA0KPiAgIGJ5IHNpbmdsZSByb3V0ZS10cmFjZSBhcyB5b3Ugc2FpZD8NCj4N Cj5CUiwNCj5IaWRla2kNCj4NCj4NCj4+U2FzaGEsDQo+Pg0KPj4gICAgICAgIEl0IGlzIG5v dCBwcmVjbHVkZWQuICBBcyBIaWRla2kgY29ycmVjdGx5IHBvaW50cyBvdXQsIGluZ3Jlc3MN Cj4+dG8gbWlkLXBvaW50IGNvbm5lY3Rpdml0eSB2ZXJpZmljYXRpb24gaXMgYSByZXF1aXJl bWVudCBpbiBSRkMgNTg2MC4NCj4+DQo+PiAgICAgICAgU2luY2UgdGhlIHNhbWUgbWVzc2Fn ZSBpcyB1c2VkIGluIGJvdGggVHJhY2Vyb3V0ZSBhbmQgQ1YsIGluDQo+PnRoZSBjYXNlIHdo ZXJlIHlvdSB3YW50IHRvIGRvIGEgY29udGludWl0eSBjaGVjayBmcm9tIExTUCBpbmdyZXNz IHRvDQo+PnNvbWUgZGV2aWNlIGJldHdlZW4gdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBmb3Ig dGhlIExTUCAoaS5lLiAtIGEgTUlQKSwNCj4+aW1wbGVtZW50YXRpb25zIHdvdWxkIGRvIGl0 IGluIHRoZSBzYW1lIHdheSB0aGF0IHlvdSBkbyBUcmFjZXJvdXRlIC0NCj4+d2l0aCB0aGUg ZXhjZXB0aW9uIHRoYXQgeW91IHdvdWxkIGRvIGl0IG9ubHkgd2l0aCB0aGUgaW50ZW5kZWQg VFRMDQo+PihhcyBvcHBvc2VkIHRvIHN0YXJ0aW5nIHdpdGggMSBhbmQgaW5jcmVtZW50aW5n IGl0IHVudGlsIHlvdSBnZXQgYQ0KPj4oIlBpbmciKSByZXNwb25zZSBmcm9tIHRoZSBpbnRl bmRlZCBMU1AgZWdyZXNzLg0KPj4NCj4+ICAgICAgICBBcyBJIGV4cGxhaW5lZCB0byBIaWRl a2ksIGl0IGlzIGxhcmdlbHkgYSBtYXR0ZXIgb2YgcGVyc29uYWwNCj4+cHJlZmVyZW5jZSB3 aGV0aGVyIHlvdSB0aGluayBvZiB0aGlzIGFzIGEgVHJhY2Vyb3V0ZSBvciBUVEwtbGltaXRl ZA0KPj5DViBtZXNzYWdlLg0KPj4NCj4+ICAgICAgICBOb3RlIHRoYXQgQ1YgaXMgZXhwbGlj aXRseSBub3QgaW5jbHVkZWQgaW4gcmVxdWlyZW1lbnRzIGZvcg0KPj50aGUgY2FzZSB3aGVy ZSBvbmUgbWlnaHQgd2FudCB0byB0ZXN0IE1JUC10by1NRVAuDQo+Pg0KPj4tLQ0KPj5Fcmlj DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBBbGV4YW5kZXIg VmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0K Pj5TZW50OiBUaHVyc2RheSwgTWFyY2ggMzEsIDIwMTEgMjo0NCBBTQ0KPj5UbzogaGlkZWtp LmVuZG8uZXNAaGl0YWNoaS5jb207IEVyaWMgR3JheQ0KPj5DYzogTWFudWVsLlBhdWxAdGVs ZWtvbS5kZTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1OyBtcGxzQGlldGYub3JnOyBhbGRyaW4u aWV0ZkBnbWFpbC5jb20NCj4+U3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExh c3QgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LQ0KPj5JbXBvcnRh bmNlOiBIaWdoDQo+Pg0KPj5IaWRla2ksIEVyaWMsIGFuZCBhbGwsDQo+PkkgYmVsaWV2ZSB0 aGF0IGFiaWxpdHkgdG8gZG8gcGluZyBNRVAtdG8tTUlQIHNob3VsZCBub3QgYmUgcHJlY2x1 ZGVkIChhdCBsZWFzdCBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcykuDQo+Pg0K Pj4NCj4+UmVnYXJkcywNCj4+ICAgICBTYXNoYQ0KPj4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4+IGhpZGVraS5lbmRv LmVzQGhpdGFjaGkuY29tDQo+Pj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDMxLCAyMDExIDg6 MjQgQU0NCj4+PiBUbzogbXBsc0BpZXRmLm9yZzsgZXJpYy5ncmF5QGVyaWNzc29uLmNvbTsg YWxkcmluLmlldGZAZ21haWwuY29tDQo+Pj4gQ2M6IE1hbnVlbC5QYXVsQHRlbGVrb20uZGU7 IFJvbGYuV2ludGVyQG5lY2xhYi5ldQ0KPj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2lu ZyBHcm91cCBMYXNDYWxsb25kcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gZGVtYW5kLWN2 LQ0KPj4+DQo+Pj4gSGkgRXJpYyBhbmQgU2FtLA0KPj4+DQo+Pj4gSSdtIHNvcnJ5IGZvciBt eSBpbmNvcnJlY3QgdW5kZXJzdGFuZGluZyBvbiBEU01BUCBUTFYuDQo+Pj4gQWNjb3JkaW5n IHRvIFNhbSwgV2UgY2FuIHVzZSBEU01BUCBpbiBib3RoIG9mIHBpbmcgYW5kIHRyYWNlIHJv dXRlLg0KPj4+DQo+Pj4gSG93ZXZlciwgSSBoYXZlIGEgY29uY2Vybi4NCj4+PiBFcmljLCB5 b3Ugc2FpZDsNCj4+PiA+ICAgICAgICBQaW5nIG1vZGUgd291bGQgYmUgc3RyaWN0bHkgTUVQ LXRvLU1FUC4gIEF0IGxlYXN0LCB0aGF0DQo+Pj4gPmlzIHRoZSB3YXkgaXQgaXMgaW50ZW5k ZWQgdG8gd29yayBpbiBvdXIgZHJhZnQuDQo+Pj4NCj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwg UkZDNTg2MCwgTVBMUy1UUCBPQU0gcmVxcywgc2F5czsNCj4+PiAyLjIuMy4gIENvbm5lY3Rp dml0eSBWZXJpZmljYXRpb25zDQo+Pj4gICAgPHNuaXBwZWQ+DQo+Pj4gICAgVGhpcyBmdW5j dGlvbiBTSE9VTEQgYmUgcGVyZm9ybWVkIG9uLWRlbWFuZCBiZXR3ZWVuIEVuZCBQb2ludHMg YW5kDQo+Pj4gICAgSW50ZXJtZWRpYXRlIFBvaW50cyBvZiBQV3MgYW5kIExTUHMsIGFuZCBi ZXR3ZWVuIEVuZCBQb2ludHMgb2YgUFdzLA0KPj4+ICAgIExTUHMsIGFuZCBTZWN0aW9ucy4N Cj4+Pg0KPj4+IGFuZDsNCj4+Pg0KPj4+IDIuMi40LiAgUm91dGUgVHJhY2luZw0KPj4+ICAg IDxzbmlwcGVkPg0KPj4+ICAgIFRoaXMgZnVuY3Rpb24gU0hPVUxEIGJlIHBlcmZvcm1lZCBv bi1kZW1hbmQuDQo+Pj4NCj4+PiAgICBUaGlzIGZ1bmN0aW9uIFNIT1VMRCBiZSBwZXJmb3Jt ZWQgYmV0d2VlbiBFbmQgUG9pbnRzIGFuZA0KPj4+IEludGVybWVkaWF0ZQ0KPj4+ICAgIFBv aW50cyBvZiBQV3MgYW5kIExTUHMsIGFuZCBiZXR3ZWVuIEVuZCBQb2ludHMgb2YgUFdzLCBM U1BzLCBhbmQNCj4+PiAgICBTZWN0aW9ucy4NCj4+Pg0KPj4+IFdoeSBkbyB5b3UgcmVzdHJp Y3QgcGluZyBtb2RlIHRvIG9ubHkgZm9yIGJldHdlZW4gTUVQcz8NCj4+PiBEbyB5b3UgbWVh biB0aGF0IE9uLWRlbWFuZCBDViBkb2Vzbid0IHNhdGlzZnkgYWxsIG9mIE9BTSByZXFzPw0K Pj4+DQo+Pj4gQlIsDQo+Pj4gSGlkZWtpDQo+Pj4NCj4+PiA+SGlkZWtpLA0KPj4+ID4NCj4+ PiA+ICAgICAgICBQaW5nIG1vZGUgd291bGQgYmUgc3RyaWN0bHkgTUVQLXRvLU1FUC4gIEF0 IGxlYXN0LCB0aGF0DQo+Pj4gPmlzIHRoZSB3YXkgaXQgaXMgaW50ZW5kZWQgdG8gd29yayBp biBvdXIgZHJhZnQuDQo+Pj4gPg0KPj4+ID4gICAgICAgIFdoeSB3b3VsZCB5b3UgbmVlZCBw ZXItaW50ZXJmYWNlIE1JUCBpbmZvcm1hdGlvbiBpbiB0aGlzDQo+Pj4gPmNhc2U/DQo+Pj4g Pg0KPj4+ID4gICAgICAgIElmIHNvbWVvbmUgd2FudGVkIHRvIGRvIExTUC1QaW5nIHRvIGEg c3BlY2lmaWMgaW50ZXJmYWNlLA0KPj4+ID5JIGFtIHVuY2VydGFpbiB3aHkgaXQgd291bGQg YmUgaW5jb3JyZWN0IHRvIHVzZSB0aGUgRFNNQVAgVExWLg0KPj4+ID4NCj4+PiA+LS0NCj4+ PiA+RXJpYw0KPj4+ID4NCj4+PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+ RnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRla2kuZW5kby5l c0BoaXRhY2hpLmNvbV0NCj4+PiA+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAzMCwgMjAxMSA1 OjQzIFBNDQo+Pj4gPlRvOiBFcmljIEdyYXk7IG1wbHNAaWV0Zi5vcmcNCj4+PiA+Q2M6IFJv bGYuV2ludGVyQG5lY2xhYi5ldTsgTWFudWVsLlBhdWxAdGVsZWtvbS5kZQ0KPj4+ID5TdWJq ZWN0OiBSZVsyXTogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsb25kcmFm dC1pZXRmLW1wbHMtDQo+Pj4gdHAtb24tZGVtYW5kLWN2LTAzDQo+Pj4gPkltcG9ydGFuY2U6 IEhpZ2gNCj4+PiA+DQo+Pj4gPkVyaWMsDQo+Pj4gPg0KPj4+ID5JbiBteSB1bmRlcnN0YW5k aW5nLCBEU01BUCBUTFYgaXMgb25seSBmb3IgdHJhY2Ugcm91dGUsIGlzbid0IGl0Pw0KPj4+ ID5XZSBuZWVkIHNwZWNpZmljIGludGVyZmFjZSBpbmZvcm1hdGlvbiBmb3IgcGluZyBtb2Rl IG9mIG9uLWRlbWFuZCBDVi4NCj4+PiA+DQo+Pj4gPkJSLA0KPj4+ID5IaWRla2kNCj4+PiA+ DQo+Pj4gPj5IaWRla2ksDQo+Pj4gPj4NCj4+PiA+PiAgICAgICAgSWYgeW91IHdhbnQgdG8g aW5jbHVkZSBzcGVjaWZpYyBpbnRlcmZhY2UgaW5mb3JtYXRpb24sDQo+Pj4gPj55b3UgY2Fu IGluY2x1ZGUgYSBEU01BUCAob3IgRERNQVApIFRMViBhcyBkZWZpbmVkIGJ5IFJGQw0KPj4+ ID4+NDM3OSwgYW5kIGV4dGVuZGVkIGJ5IHRoaXMgZHJhZnQgKGluIGNvbWJpbmF0aW9uIHdp dGggdGhlDQo+Pj4gPj5kcmFmdCAiZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWVuaGFuY2Vk LWRzbWFwIiBmb3IgRERNQVApLg0KPj4+ID4+DQo+Pj4gPj4gICAgICAgIFdvdWxkIHRoaXMg bm90IGRvIHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yPw0KPj4+ID4+DQo+Pj4gPj4tLQ0KPj4+ ID4+RXJpYw0KPj4+ID4+DQo+Pj4gPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ ID4+RnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRla2kuZW5k by5lc0BoaXRhY2hpLmNvbV0NCj4+PiA+PlNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIw MTEgMTE6MzMgQU0NCj4+PiA+PlRvOiBSb2xmLldpbnRlckBuZWNsYWIuZXU7IEVyaWMgR3Jh eTsgbXBsc0BpZXRmLm9yZzsNCj4+PiBNYW51ZWwuUGF1bEB0ZWxla29tLmRlDQo+Pj4gPj5T dWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1p ZXRmLW1wbHMtdHAtDQo+Pj4gb24tZGVtYW5kLWN2LTAzDQo+Pj4gPj5JbXBvcnRhbmNlOiBI aWdoDQo+Pj4gPj4NCj4+PiA+PkhpLA0KPj4+ID4+DQo+Pj4gPj5JIGhhdmUgb25lIGNvbW1l bnQgb24gSURzIGluIGRyYWZ0LW9uLWRlbWFuZC1jdi4NCj4+PiA+PlRoZSBpbnRlcmZhY2Ut RCBpcyBtaXNzaW5nIGluIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGVyZSBpcyBvbmx5IE5vZGUt DQo+Pj4gSUQuDQo+Pj4gPj5Zb3UgbmVlZCBhdCBsZWFzdCB0aGUgaW50ZXJmYWNlIElEIHRv IHN1cHBvcnQgcGVyLWludGVyZmFjZSBNSVAuDQo+Pj4gPj4NCj4+PiA+PkJSLA0KPj4+ID4+ SGlkZWtpDQo+Pj4gPj4NCj4+PiA+Pj4NCj4+PiA+Pj5EZWFyIEFsbCwNCj4+PiA+Pj4NCj4+ PiA+Pj5JIHJlYWxseSBhcHByZWNpYXRlIHRoZSBjb25zaWRlcmF0aW9uIG9uIHRoZSBwZXIt aW50ZXJmYWNlIE1JUA0KPj4+IHN1cHBvcnQgYW5kIHRoZSBkaXNjdXNzaW9uIG1vdmluZyBm b3J3YXJkLg0KPj4+ID4+Pg0KPj4+ID4+Pg0KPj4+ID4+PkZyb20gYW4gb3BlcmF0b3IncyBw ZXJzcGVjdGl2ZSwgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdGhhdCB0aGUNCj4+PiBzdXBwb3J0 IGZvciBwZXItaW50ZXJmYWNlIE1JUHMgaXMgY292ZXJlZCBieSB0aGUgZGVmaW5pdGlvbnMu DQo+Pj4gPj4+DQo+Pj4gPj4+TG9va2luZyBhdCBlYXJsaWVyIHZlcnNpb25zIG9mIGRyYWZ0 LWZhcnJlbC1tcGxzLXRwLW1pcC1tZXAtbWFwLA0KPj4+IHRoZXJlIHdhcyBhbHJlYWR5IGEg c29sdXRpb24gcHJvcG9zYWwsIHVzaW5nIHRoZSBUVEwuIEVuaGFuY2VkDQo+Pj4gc29sdXRp b25zIGhhdmUgYmVlbiB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGlzIElFVEYgbWVl dGluZy4gSXQgaXQNCj4+PiB0byBiZSBleHBlY3RlZCB0aGF0IHRoZXJlIHdpbGwgYmUgd2F5 cyB0byBzb2x2ZSBib3RoIHRoZSBmYXN0IHBhdGggYW5kDQo+Pj4gZmF0ZS1zaGFyaW5nIHJl cXVpcmVtZW50Lg0KPj4+ID4+Pg0KPj4+ID4+Pg0KPj4+ID4+Pkkgc2Vjb25kIHRoZSBwcm9w b3NhbCBpbml0aWFsbHkgbWFkZSBieSBSb2xmLCB0byBpbmNsdWRlIGFkZGl0aW9uYWwNCj4+ PiB0ZXh0IHRvIGRvY3VtZW50IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNzaW5nIGZv ciB0aGUgb24tZGVtYW5kLWN2DQo+Pj4gYW5kIGZvciBvdGhlciBPQU0gdG9vbHMuDQo+Pj4g Pj4+DQo+Pj4gPj4+DQo+Pj4gPj4+QmVzdCByZWdhcmRzLA0KPj4+ID4+Pk1hbnVlbA0KPj4+ ID4+Pg0KPj4+ID4+Pg0KPj4+ID4+PkRldXRzY2hlIFRlbGVrb20gQUcNCj4+PiA+Pj5Hcm91 cCBUZWNobm9sb2d5DQo+Pj4gPj4+TWFudWVsIFBhdWwNCj4+PiA+Pj5TQTMtMTENCj4+PiA+ Pj5Hb3NsYXJlciBVZmVyIDM1LTM3LCAxMDU4OSBCZXJsaW4NCj4+PiA+Pj4rNDkgMzAgMzQ5 NyAtIDQzOTQgKFRlbC4pDQo+Pj4gPj4+KzQ5IDMwIDM0OTcgLSA0OTU2IChGYXgpDQo+Pj4g Pj4+KzQ5IDE3MSAgODYzNDAzMiAoTW9iaWwpDQo+Pj4gPj4+RS1NYWlsOiBtYWlsdG86bWFu dWVsLnBhdWxAdGVsZWtvbS5kZQ0KPj4+ID4+Pmh0dHA6Ly93d3cudGVsZWtvbS5jb20NCj4+ PiA+Pj4NCj4+PiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gPj4+PiBG cm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uDQo+Pj4gQmVoYWxmIE9mDQo+Pj4gPj4+PiBSb2xmIFdpbnRlcg0KPj4+ID4+Pj4g U2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSAzOjAzIFBNDQo+Pj4gPj4+PiBUbzogRXJp YyBHcmF5OyBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbQ0KPj4+ID4+Pj4gQ2M6IG1wbHNA aWV0Zi5vcmcNCj4+PiA+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBM YXMgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC0NCj4+PiBvbi1kZW1hbmQtDQo+Pj4gPj4+ PiBjdi0wMw0KPj4+ID4+Pj4NCj4+PiA+Pj4+IEVyaWMsDQo+Pj4gPj4+Pg0KPj4+ID4+Pj4g SSBnZW5lcmFsbHkgYWdyZWUgYnV0IEkgdGhpbmsgdGhlcmUgaXMgb25lIGNhc2UgYWN0dWFs bHkgd2hpY2gNCj4+PiBuZWVkcyBhDQo+Pj4gPj4+PiBjbG9zZXIgbG9vayBpbiB0aGlzIHJl Z2FyZCAod2hpY2ggSSBoaW50ZWQgYXQgZWFybGllciksIHdoaWNoIGFyZQ0KPj4+IHRoZSBw ZXItDQo+Pj4gPj4+PiBpbnRlcmZhY2UgTUlQcy4gWW91ciBUVEwgZXhwaXJlcyAodGhlIGFj dHVhbCBhZGRyZXNzaW5nIGJpdCBoZXJlKSwNCj4+PiB0aGUNCj4+PiA+Pj4+IGlkZW50aWZp ZXIgdGVsbHMgeW91IGl0IGlzIG5vdCBpbnRlbmRlZCBmb3IgdGhlIGluZ3Jlc3MgTUlQLCBz byBpdA0KPj4+IG5lZWRzDQo+Pj4gPj4+PiB0byBiZSBmb3J3YXJkZWQgdG8gdGhlIGVncmVz cyBNSVAgdGhyb3VnaCB0aGUgZm9yd2FyZGluZyBlbmdpbmUuDQo+Pj4gTm93IGlmDQo+Pj4g Pj4+PiB5b3UgcHVsbCB0aGUgcGFja2V0IG91dCBvZiB0aGUgZmFzdCBwYXRoIGFuZCBpbmpl Y3QgaXQgYmFjayBpbiwgaXMNCj4+PiB0aGUgT0FNDQo+Pj4gPj4+PiBwYWNrZXQgc3RpbGwg ZmF0ZSBzaGFyaW5nPyBJZiB5b3UgY2FuIGRvIHRoaXMgaW4gSFcgb24gdGhlIGxpbmUNCj4+ PiBjYXJkLCB0aGVuDQo+Pj4gPj4+PiBpdCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUgZm9y d2FyZGVkIGFzIG5vcm1hbC4gSSBrbm93IHRoaXMgaXMgYQ0KPj4+ID4+Pj4gZGlmZmVyZW50 IGRyYWZ0LCBidXQgdGhpcyB3aWxsIGJlIGluIHBhcnRpY3VsYXIgaW1wb3J0YW50IGZvcg0K Pj4+IHBlcmZvcm1hbmNlDQo+Pj4gPj4+PiBtb25pdG9yaW5nLg0KPj4+ID4+Pj4NCj4+PiA+ Pj4+IEJlc3QsDQo+Pj4gPj4+Pg0KPj4+ID4+Pj4gUm9sZg0KPj4+ID4+Pj4NCj4+PiA+Pj4+ DQo+Pj4gPj4+Pg0KPj4+ID4+Pj4gTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBP ZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYQ0KPj4+IFJvYWQsIExvbmRvbg0KPj4+ID4+ Pj4gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+PiA+Pj4+DQo+ Pj4gPj4+Pg0KPj4+ID4+Pj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+ Pj4gPiBGcm9tOiBFcmljIEdyYXkgW21haWx0bzplcmljLmdyYXlAZXJpY3Nzb24uY29tXQ0K Pj4+ID4+Pj4gPiBTZW50OiBNb250YWcsIDI4LiBN5HJ6IDIwMTEgMTQ6NDUNCj4+PiA+Pj4+ ID4gVG86IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tOyBSb2xmIFdpbnRlcg0KPj4+ID4+ Pj4gPiBDYzogbXBsc0BpZXRmLm9yZw0KPj4+ID4+Pj4gPiBTdWJqZWN0OiBSRTogUmVbMl06 IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi0NCj4+PiBtcGxz LXRwLQ0KPj4+ID4+Pj4gPiBvbi1kZW1hbmQtY3YtMDMNCj4+PiA+Pj4+ID4NCj4+PiA+Pj4+ ID4gSGlkZWtpLA0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4gPiAgICBXaGF0IHlvdSdyZSBzYXlp bmcgaXMgdHJ1ZSwgYnV0IG5vdCByZWxldmFudCBpbiB0aGlzDQo+Pj4gPj4+PiA+IGNhc2Uu ICBUaGUgImFkZHJlc3NlcyIgaW4gdGhpcyBkaXNjdXNzaW9uIGFyZSBub3QgdXNlZCB0bw0K Pj4+ID4+Pj4gPiBkZXRlcm1pbmUgaG93IHRvIGZvcndhcmQgT0FNIHBhY2tldHMuICBUaGV5 IGFyZSB1c2VkIG9ubHkNCj4+PiA+Pj4+ID4gYnkgdGhlIHJlY2lwaWVudCBNSVAvTUVQIHRv IHZlcmlmeSB0aGF0IHRoZSBPQU0gcGFja2V0IHdhcw0KPj4+ID4+Pj4gPiBwcm9wZXJseSBk ZWxpdmVyZWQuDQo+Pj4gPj4+PiA+DQo+Pj4gPj4+PiA+ICAgIEJ5IHRoZSB3YXksIHRoaXMg ZGlzY3Vzc2lvbiBpcyBhbiBpbmRpY2F0aW9uIG9mIHRoZQ0KPj4+ID4+Pj4gPiBjb25mdXNp bmcgaW5qZWN0ZWQgYnkgY2FsbGluZyB0aGVzZSB0aGluZ3MgYWRkcmVzc2VzLiAgTXkNCj4+ PiA+Pj4+ID4gbWlzdGFrZSBhbmQgSSBicmluZyBpdCB1cCBub3cgdG8gaGVscCB0byBzdGVt IHRoZSB0aWRlIG9mDQo+Pj4gPj4+PiA+IGZ1cnRoZXIgY29tbWVudHMgcmVzdWx0aW5nIGZy b20gdGhhdCBjb25mdXNpb24uDQo+Pj4gPj4+PiA+DQo+Pj4gPj4+PiA+ICAgIEluIHRoZSB2 ZXJzaW9uIHdlIHBvc3QgYWZ0ZXIgbGFzdCBjYWxsIGlzIGNvbXBsZXRlLA0KPj4+ID4+Pj4g PiB3ZSB3aWxsIGJlIGNoYW5naW5nIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uICJhZGRy ZXNzIg0KPj4+ID4+Pj4gPiBUTFZzIHRvIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gImlkZW50 aWZpZXIiIFRMVnMuDQo+Pj4gPj4+PiA+DQo+Pj4gPj4+PiA+ICAgIFdlIHdpbGwgYWxzbyBi ZSBjb3JyZWN0aW5nIHRoZSByZWZlcmVuY2UgdG8gRFNNQVAsDQo+Pj4gPj4+PiA+IGFuZCBE RE1BUCwgYWRkcmVzcyBUTFZzICh3aGljaCBpcyBpbmNvcnJlY3QsIGJlY2F1c2UgdGhlDQo+ Pj4gPj4+PiA+IGZvcm1hdCBmb3IgRFNNQVAvRERNQVAgZG9lc24ndCBpbmNsdWRlIGEgImxl bmd0aCIgZmllbGQpLg0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4gPiAgICBUaGUgZm9ybWF0IG9m IHRoZSBEb3duc3RyZWFtIE1hcHBpbmcgKERTTUFQKSBUTFYgaXMNCj4+PiA+Pj4+ID4gZGVm aW5lZCBpbiBSRkMgNDM3OSwgYW5kIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGZvcm1hdA0K Pj4+ID4+Pj4gPiBvZiB0aGF0IFRMVi4NCj4+PiA+Pj4+ID4NCj4+PiA+Pj4+ID4gICAgVGhl c2UgY2hhbmdlcyBhcmUgZHJpdmVuIGJ5IGxhc3QgY2FsbCBjb21tZW50cyB3ZQ0KPj4+ID4+ Pj4gPiBoYXZlIGFscmVhZHkgcmVjZWl2ZWQgKHNlZSBKb2VsIEhhbHBlcm4ncyBjb21tZW50 cyBvbiB0aGUNCj4+PiA+Pj4+ID4gbWFpbGluZyBsaXN0KSBhbmQgYXJlIC0gaW4gcGFydCAt IHRvIGNvcnJlY3QgYWNjaWRlbnRhbA0KPj4+ID4+Pj4gPiB1c2Ugb2YgdGhlIHdvcmQgImFk ZHJlc3MiIGZvciBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uDQo+Pj4gPj4+PiA+IGlkZW50aWZp ZXIgVExWcyAod2hpY2ggaXMgd2hhdCB3ZSBoYWQgZGlzY3Vzc2VkIGJlZm9yZQ0KPj4+ID4+ Pj4gPiBJIGdlbmVyYXRlZCB0aGUgLTAzIHZlcnNpb24gYW1vbmcgdGhlIGF1dGhvcnMgb2Yg c2V2ZXJhbA0KPj4+ID4+Pj4gPiBvZiB0aGUgY3VycmVudCBzZXQgb2YgTVBMUy1UUCBkcmFm dHMpLg0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4gPiAgICBJbiB0aGUgY2FzZSBvZiBzb3VyY2Ug YW5kIGRlc3RpbmF0aW9uIGlkZW50aWZpZXJzLA0KPj4+ID4+Pj4gPiB0aGVzZSB3aWxsIGJl IHVzZWQgZXhjbHVzaXZlbHkgdG8gdmVyaWZ5IHRoYXQgYW4gT0FNIFBEVQ0KPj4+ID4+Pj4g PiBoYXMgYmVlbiBjb3JyZWN0bHkgcmVjZWl2ZWQgYnkgaXRzIGludGVuZGVkIHJlY2lwaWVu dC4NCj4+PiA+Pj4+ID4gQmVjYXVzZSB0aGlzIGlzIGFuIG9uLWRlbWFuZCBjb25uZWN0aXZp dHkgdmVyaWZpY2F0aW9uDQo+Pj4gPj4+PiA+IHByb3RvY29sLCB0aGF0IGlzIGV4cGVjdGVk IHRvIGJlIHVzZWQgb25seSBvbiB0aG9zZQ0KPj4+ID4+Pj4gPiBvY2Nhc2lvbnMgd2hlbiB0 aGVyZSBpcyBhIG5ldHdvcmsgcHJvYmxlbSB0aGF0IG5lZWRzIHRvDQo+Pj4gPj4+PiA+IGJl IGRpYWdub3NlZCwgYW5kIHRoZSBpbmZvcm1hdGlvbiBpcyBub3Qgc2VlbiAoYW5kIG5vdA0K Pj4+ID4+Pj4gPiB2aXNpYmxlIC0gd2l0aG91dCBsYXllciB2aW9sYXRpb25zKSwgb3B0aW1p emluZyB0aGVzZQ0KPj4+ID4+Pj4gPiBvYmplY3RzIGZvciBzb2Z0d2FyZSBtYWtlcyBzZW5z ZS4NCj4+PiA+Pj4+ID4NCj4+PiA+Pj4+ID4gICAgSW4gYWRkaXRpb24sIHNpbmNlIGVpdGhl ciBtYXkgYmUgaW5jbHVkZWQgKHdoaWNoDQo+Pj4gPj4+PiA+IGluY2x1ZGVzIHRoZSBwb3Nz aWJpbGl0eSBvZiBpbmNsdWRpbmcgYm90aCksIGl0IGlzIHRoZQ0KPj4+ID4+Pj4gPiBjYXNl IGFscmVhZHkgdGhhdCB3ZSB3b3VsZCB0aGVuIG5lZWQgdG8gZGVjaWRlIHdoaWNoIGlzDQo+ Pj4gPj4+PiA+IHRvIGdvIGZpcnN0IC0gYXNzdW1pbmcgd2Ugd2FudGVkIHRvIGRvIHRoaXMg KHdoaWNoIHdlDQo+Pj4gPj4+PiA+IGRvIG5vdCkuDQo+Pj4gPj4+PiA+DQo+Pj4gPj4+PiA+ IC0tDQo+Pj4gPj4+PiA+IEVyaWMNCj4+PiA+Pj4+ID4NCj4+PiA+Pj4+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+Pj4+ID4gRnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0 YWNoaS5jb20NCj4+PiBbbWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPj4+ ID4+Pj4gPiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDg6MTEgQU0NCj4+PiA+Pj4+ ID4gVG86IEVyaWMgR3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1DQo+Pj4gPj4+PiA+IENj OiBtcGxzQGlldGYub3JnDQo+Pj4gPj4+PiA+IFN1YmplY3Q6IFJlWzJdOiBbbXBsc10gV29y a2luZyBHcm91cCBMYXMgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy0NCj4+PiB0cC1vbi0NCj4+ PiA+Pj4+ID4gZGVtYW5kLWN2LTAzDQo+Pj4gPj4+PiA+IEltcG9ydGFuY2U6IEhpZ2gNCj4+ PiA+Pj4+ID4NCj4+PiA+Pj4+ID4gSGkgRXJpYyBhbmQgUm9sZiwNCj4+PiA+Pj4+ID4NCj4+ PiA+Pj4+ID4gSSdtIHNvcnJ5IGZvciBpbnRlcnJ1cHRpbmcuDQo+Pj4gPj4+PiA+DQo+Pj4g Pj4+PiA+IEkgYWdyZWUgd2l0aCBSb2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBN SVAgZGlzY3Vzc2lvbi4NCj4+PiA+Pj4+ID4gV2UgaGF2ZSB0byBjb25zaWRlciB0aGUgSFcg aW1wbGVtZW50YXRpb24gYXNwZWN0LA0KPj4+ID4+Pj4gPiBiZWNhdXNlIHRyYXBwaW5nIG9m IGFuIE9BTSBwYWNrZXQgaXMgSFcgcnVsZS9mdW5jdGlvbmFsaXR5IGV2ZW4NCj4+PiBpbg0K Pj4+ID4+Pj4gPiByb3V0ZXJzLg0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4gPiBJZiBldmVyeSBP QU0gcGFja2V0IGlzIHRyYXBwZWQgdG8gQ1BVDQo+Pj4gPj4+PiA+IGFuZCB0aGUgT0FNIHBh Y2tldHMgd2hpY2ggc2hvdWxkIE5PVCBiZSBwcm9jZXNzZWQgaW4gdGhlDQo+Pj4gSW50ZXJm YWNlDQo+Pj4gPj4+PiA+IGFyZSByZXR1cm5lZCB0byBEYXRhLXBsYW5lLA0KPj4+ID4+Pj4g PiBpdCBpcyBkaWZmZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZyb20gdXNlciBwYWNrZXRzLA0K Pj4+ID4+Pj4gPiB3aGljaCBpcyBOT1QgdGhlIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24g b2YgdGhlIHVzZXIgcGF0aC4NCj4+PiA+Pj4+ID4NCj4+PiA+Pj4+ID4gVGhlcmVmb3JlLCB3 ZSBzaG91bGQgdGFrZSB0aGUgSFcgYXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8NCj4+PiBh Y2NvdW50DQo+Pj4gPj4+PiA+IGNvbmN1cnJlbnRseS4NCj4+PiA+Pj4+ID4gSWYgYW4gYWRk cmVzcyBUTFYgTVVTVCBiZSB0aGUgZmlyc3QgaW4gVExWcywNCj4+PiA+Pj4+ID4gaXQgaXMg ZW5vdWdoIHRvIG1ha2UgSFcgaW1wbGVtZW50YXRpb24gZWFzeS4NCj4+PiA+Pj4+ID4NCj4+ PiA+Pj4+ID4gQlIsDQo+Pj4gPj4+PiA+IEhpZGVraQ0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4g Pg0KPj4+ID4+Pj4gPg0KPj4+ID4+Pj4gPiA+Um9sZiwNCj4+PiA+Pj4+ID4gPg0KPj4+ID4+ Pj4gPiA+ICBUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4NCj4+PiA+ Pj4+ID4gPg0KPj4+ID4+Pj4gPiA+ICBJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5k IGFkZHJlc3MgbG9jYXRpb24gaXNzdWVzDQo+Pj4gPj4+PiA+ID53ZXJlIHNlcGFyYXRlLg0K Pj4+ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ID4gIEkndmUgcGVyc29uYWxseSBoYWQgcHJvYmxl bXMgd2l0aCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucw0KPj4+ID4+Pj4gPiA+dGhhdCByZXF1 aXJlIG9yZGVyaW5nIG9mIFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGlzIG5vdCB2ZXJ5 DQo+Pj4gPj4+PiA+ID5yb2J1c3QgaW4gdGVybXMgb2YgImZ1dHVyZS1wcm9vZmluZy4iICBX aGF0IGhhcHBlbnMgaWYgbmV3IFRMVnMNCj4+PiA+Pj4+ID4gPmFyZSBhZGRlZCBsYXRlciBv bjsgZm9yIGluc3RhbmNlLCBzdXBwb3NlIGF0IHNvbWUgcG9pbnQgd2UgaGF2ZQ0KPj4+ID4+ Pj4gPiA+bXVsdGlwbGUgImFkZHJlc3MiIFRMVnM/DQo+Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+ ID4gPiAgQWxzbywgdGhlIGZhY3QgdGhhdCBpbXBsZW1lbnRhdGlvbnMgYXJlIGFsbG93ZWQg dG8gYXR0YWNoDQo+Pj4gPj4+PiA+ID5UTFZzIGluIGFueSBhcmJpdHJhcnkgb3JkZXIgYWxs b3dzIGNvbnNpZGVyYWJsZSBmbGV4aWJpbHR5IGluDQo+Pj4gPj4+PiA+ID5pbXBsZW1lbnRh dGlvbi4gIE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJpdHJhcmlseSBtYW55DQo+Pj4g d2F5cy4NCj4+PiA+Pj4+ID4gPlRoaXMgdG9vIGNhbiBiZSBhIGZ1dHVyZS1wcm9vZmluZyBp c3N1ZS4NCj4+PiA+Pj4+ID4gPg0KPj4+ID4+Pj4gPiA+ICBJIHdvdWxkIHByZWZlciBub3Qg dG8gc3RhcnQgZG93biB0aGUgcm9hZCBvZiByZXF1aXJpbmcgYQ0KPj4+ID4+Pj4gPiA+c3Vi c2V0IG9mIFRMVnMgdG8gYXBwZWFyIGluIGEgY2VydGFpbiBvcmRlciwgYW5kIHNheWluZyB3 ZSBoYXZlDQo+Pj4gPj4+PiA+ID5vbmUgVExWIHRoYXQgbmVlZHMgdG8gYmUgZmlyc3QgaXMg ZG9pbmcganVzdCB0aGF0Lg0KPj4+ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ID4tLQ0KPj4+ID4+ Pj4gPiA+RXJpYw0KPj4+ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ID4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+ID4+Pj4gPiA+RnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpSb2xm LldpbnRlckBuZWNsYWIuZXVdDQo+Pj4gPj4+PiA+ID5TZW50OiBNb25kYXksIE1hcmNoIDI4 LCAyMDExIDY6MTkgQU0NCj4+PiA+Pj4+ID4gPlRvOiBFcmljIEdyYXkNCj4+PiA+Pj4+ID4g PkNjOiBtcGxzQGlldGYub3JnDQo+Pj4gPj4+PiA+ID5TdWJqZWN0OiBSRTogW21wbHNdIFdv cmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLQ0KPj4+IHRwLW9uLQ0K Pj4+ID4+Pj4gPiBkZW1hbmQtY3YtMDMNCj4+PiA+Pj4+ID4gPkltcG9ydGFuY2U6IEhpZ2gN Cj4+PiA+Pj4+ID4gPg0KPj4+ID4+Pj4gPiA+SGksDQo+Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+ ID4gPkkgc3RpbGwgdGhpbmsgdGhlcmUgaXMgYSBsb2dpY2FsIGVycm9yLiBMZXQgbWUgZXhw bGFpbi4gSW4gY2FzZQ0KPj4+IHRoZXJlDQo+Pj4gPj4+PiA+IGlzIG5vIElQIHlvdSBzaW1w bHkgY2Fubm90IHVzZSBpdC4gWW91IHNheSB5b3UgY291bGQgZW5hYmxlIElQDQo+Pj4gYnV0 IHRoZW4NCj4+PiA+Pj4+ID4gdGhhdCBpcyBub3QgYSBjYXNlIHdoZXJlIHRoZXJlIGlzIG5v IElQLiBJbiBvcmRlciB0byBiZQ0KPj4+IGNvbnN0cnVjdGl2ZQ0KPj4+ID4+Pj4gPiBoZXJl IGlzIGEgdGV4dCBjaGFuZ2Ugc3VnZ2VzdGlvbjoNCj4+PiA+Pj4+ID4gPg0KPj4+ID4+Pj4g PiA+IkluIGNlcnRhaW4gTVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUCBhZGRyZXNz aW5nIG1pZ2h0DQo+Pj4gbm90IGJlDQo+Pj4gPj4+PiA+IGF2YWlsYWJsZS4gSW4gdGhvc2Ug Y2FzZXMgT24tZGVtYW5kIENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIE1VU1QNCj4+PiBiZSBy dW4NCj4+PiA+Pj4+ID4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCB1c2luZyB0aGUgQUNIIGNo YW5uZWwgdHlwZSBzcGVjaWZpZWQgaW4NCj4+PiBTZWN0aW9uDQo+Pj4gPj4+PiA+IDMuIElu IG90aGVyIGNhc2VzIGl0IG1pZ2h0IGJlIGF2YWlsYWJsZSwgaG93ZXZlciwgaXQgbWF5IGJl DQo+Pj4gcHJlZmVycmVkDQo+Pj4gPj4+PiA+IHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQ IGVuY2Fwc3VsYXRpb24uIEluIHRob3NlIGNhc2VzLCB0aGUNCj4+PiA+Pj4+ID4gcHJvY2Vk dXJlcyBhcyBvdXRsaW5lZCBpbiBzZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUgdXNlZC4iDQo+ Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+ID4gPlJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBN SVAgZGlzY3Vzc2lvbi4gVGhlIEhXIGFzcGVjdCBhbHNvDQo+Pj4gcG9wcGVkDQo+Pj4gPj4+ PiA+IHVwIGluIHRoZSBQV0UzIHNlc3Npb24gYW5kIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBv cnRhbnQNCj4+PiBjb25zaWRlcmF0aW9uLA0KPj4+ID4+Pj4gPiBpbiBwYXJ0aWN1bGFyIGZv ciBPQU0uIEV2ZW4gaWYgd2UgdGFsayBhYm91dCBUTFZzLCB3ZSBjb3VsZCBtYWtlDQo+Pj4g aXQgYQ0KPj4+ID4+Pj4gPiBNVVNUIHRoYXQgYW4gQWRkcmVzcyBUTFYgaXMgYWx3YXlzIHRo ZSBmaXJzdCBvbmUgdG8gYXBwZWFyLiBJZg0KPj4+IHlvdSBjYW4NCj4+PiA+Pj4+ID4gZmFj aWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhhcmR3YXJlLCBJIHNlZSBubyBy ZWFzb24NCj4+PiB0bw0KPj4+ID4+Pj4gPiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0KPj4+ ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ID5CZXN0LA0KPj4+ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ ID5Sb2xmDQo+Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+ID4gPg0KPj4+ID4+Pj4gPiA+TkVDIEV1 cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3Jp YQ0KPj4+IFJvYWQsDQo+Pj4gPj4+PiA+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgMjgzMjAxNA0KPj4+ID4+Pj4gPiA+DQo+Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+ ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+Pj4+ID4gPj4gRnJvbTog RXJpYyBHcmF5IFttYWlsdG86ZXJpYy5ncmF5QGVyaWNzc29uLmNvbV0NCj4+PiA+Pj4+ID4g Pj4gU2VudDogTW9udGFnLCAyOC4gTeRyeiAyMDExIDExOjQzDQo+Pj4gPj4+PiA+ID4+IFRv OiBSb2xmIFdpbnRlcg0KPj4+ID4+Pj4gPiA+PiBDYzogbG9hQHBpLm51OyBtcGxzQGlldGYu b3JnDQo+Pj4gPj4+PiA+ID4+IFN1YmplY3Q6IFJFOiBbbXBsc10gV29ya2luZyBHcm91cCBM YXMgQ2FsbCBvbiBkcmFmdC1pZXRmLQ0KPj4+IG1wbHMtdHAtb24tDQo+Pj4gPj4+PiA+ID4+ IGRlbWFuZC1jdi0wMw0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+Pj4gPiA+PiBSb2xmLA0KPj4+ ID4+Pj4gPiA+Pg0KPj4+ID4+Pj4gPiA+PiAgICAgICAgIFdpdGggcmVnYXJkIHRvIHRoZSB1 c2Ugb2YgU0hPVUxEICh2ZXJzZXMgTVVTVCkgLSB0aGUNCj4+PiBpbnRlbnQNCj4+PiA+Pj4+ ID4gPj4gKGFjY29yZGluZyB0byBSRkMgMjExOSAtIHNlZSB0aGUgcXVvdGUgYmVsb3cpIGlz IGNvbnNpc3RlbnQNCj4+PiB3aXRoDQo+Pj4gPj4+PiA+ID4+IHRoaXMgY2FzZS4gIElmIC0g Zm9yIHNvbWUgcmVhc29uIC0gb25lIGhhZCBhIHJlYWxseSBnb29kDQo+Pj4gcmVhc29uIHRv DQo+Pj4gPj4+PiA+ID4+IHVzZSBJUCBhZGRyZXNzaW5nIGluIHNvbWUgc3BlY2lmaWMgY2Fz ZSwgb25lIGNvdWxkIHRha2Ugc3RlcHMNCj4+PiB0bw0KPj4+ID4+Pj4gPiA+PiBtYWtlIElQ IGFkZHJlc3NpbmcgYXZhaWxhYmxlLg0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+Pj4gPiA+PiAg ICAgICAgIFRoaXMgY291bGQgYmUgc2FpZCB0byBpbnRyb2R1Y2UgYSBsb2dpY2FsIGRpc2Nv bm5lY3QsDQo+Pj4gYnV0IHdlDQo+Pj4gPj4+PiA+ID4+IGFyZSBzYXZlZCBmcm9tIGdvaW5n IGRvd24gdGhhdCBwYXRoIGJ5IHRoZSBmYWN0IHRoYXQgdGhlDQo+Pj4gc3RhdGVtZW50DQo+ Pj4gPj4+PiA+ID4+IGFsc28gaW5jbHVkZXMgdGhlIGNhc2Ugd2hlcmUgKGZvciBzb21lIHJl YXNvbikgdGhlcmUgaXMgYQ0KPj4+IGNhc2UgaW4NCj4+PiA+Pj4+ID4gPj4gd2hpY2ggc29t ZSBvdGhlciBhZGRyZXNzaW5nIHNjaGVtZSBtaWdodCBiZSBwcmVmZXJyZWQuICBJbg0KPj4+ IG1hbnkgb2YNCj4+PiA+Pj4+ID4gPj4gdGhlIGNhc2VzIHdoZXJlIGFub3RoZXIgYWRkcmVz c2luZyBzY2hlbWUgbWF5IGJlIHByZWZlcnJlZCwNCj4+PiBpdCBpcw0KPj4+ID4+Pj4gPiA+ PiBzdGlsbCBwb3NzaWJsZSAoaW4gZmFjdCBsaWtlbHkpIHRoYXQgSVAgYWRkcmVzc2luZyBp cw0KPj4+IGF2YWlsYWJsZS4NCj4+PiA+Pj4+ID4gPj4NCj4+PiA+Pj4+ID4gPj4gICAgICAg ICBPdGhlcndpc2UsIGl0IHdvdWxkIG5vdCBoYXZlIGJlZW4gbmVjZXNzYXJ5IHRvDQo+Pj4g ZGlzdGluZ3Vpc2gNCj4+PiA+Pj4+ID4gPj4gdGhpcyBjYXNlIGZyb20gdGhlIG9uZSBpbiB3 aGljaCBJUCBhZGRyZXNzaW5nIGlzIG5vdA0KPj4+IGF2YWlsYWJsZS4NCj4+PiA+Pj4+ID4g Pj4NCj4+PiA+Pj4+ID4gPj4gICAgICAgICBGb3IgdGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVz c2luZyBpcyBub3QgdGhlIHByZWZlcnJlZA0KPj4+IG1vZGUsDQo+Pj4gPj4+PiA+ID4+IHdl IGFyZSByZWNvbW1lbmRpbmcgYSBtb2RlIGluIHdoaWNoIGl0IGlzIG5vdCBuZWNlc3Nhcnku DQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+ICAgICAgICAgV2l0aCByZWdhcmQgdG8g aGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lDQo+Pj4gcGxhY2UsDQo+Pj4g Pj4+PiA+ID4+IHRoaXMgcHJvdG9jb2wgaXMgbWVhbnQgZm9yIGNvbm5lY3Rpdml0eSB0ZXN0 aW5nIG9uIGFuIG9uLQ0KPj4+IGRlbWFuZA0KPj4+ID4+Pj4gPiA+PiBiYXNpcyBhbmQgaXMg dGhlcmVmb3JlIG5vdCBvcHRpbWl6ZWQgZm9yIHByb2Nlc3NpbmcgaW4NCj4+PiBoYXJkd2Fy ZS4NCj4+PiA+Pj4+ID4gPj4NCj4+PiA+Pj4+ID4gPj4gICAgICAgICBXaGV0aGVyIGFkZHJl c3NlcyBvciBpZGVudGlmaWVycywgaWYgd2UgYXJlIHRhbGtpbmcNCj4+PiBhYm91dA0KPj4+ ID4+Pj4gPiA+PiBUTFYgY29udGVudHMsIHRoZXJlIGFyZSBpc3N1ZXMgd2l0aCB0cnlpbmcg dG8gZ3VhcmFudGVlDQo+Pj4gbG9jYXRpb24NCj4+PiA+Pj4+ID4gPj4gb2Ygc3BlY2lmaWMg Y29udGVudCwgYmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4NCj4+PiBxdWVz dGlvbg0KPj4+ID4+Pj4gPiA+PiB3aWxsIHByb2JhYmx5IGZvbGxvdyBvdGhlciBUTFZzIC0g dGh1cyBtYWtpbmcgbG9jYXRpb25zDQo+Pj4gZGlmZmljdWx0DQo+Pj4gPj4+PiA+ID4+IHRv IHByZWRpY3QgaW4gYW55IGNhc2UuDQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+ICAg ICAgICAgV2l0aCByZWdhcmQgdG8gbmVlZGluZyBtb3JlIHRleHQgb24gcGVyLWludGVyZmFj ZQ0KPj4+IE1JUHMsIGRvDQo+Pj4gPj4+PiA+ID4+IHlvdSBoYXZlIHNwZWNpZmljIHN1Z2dl c3Rpb25zIGFzIHRvIHdoYXQgdGV4dCB3ZSBtaWdodCBhZGQ/DQo+Pj4gPj4+PiA+ID4+DQo+ Pj4gPj4+PiA+ID4+ICAgICAgICAgSSB1bmRlcnN0YW5kIChmcm9tIGRpc2N1c3Npb24gd2l0 aCBXRyBjaGFpcnMpIHRoYXQgd2UNCj4+PiBhcmUNCj4+PiA+Pj4+ID4gPj4gbm90IGFsbG93 ZWQgdG8gZXhwbGljaXRseSBhZGRyZXNzIGxhc3QgY2FsbCBjb21tZW50cyBkdXJpbmcNCj4+ PiB0aGUNCj4+PiA+Pj4+ID4gPj4gSUVURiBtZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVzZSB0 aGUgbGFzdCBjYWxsIGlzIHN0aWxsDQo+Pj4gb25nb2luZw0KPj4+ID4+Pj4gPiA+PiBhdCB0 aGF0IHRpbWUuDQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+IC0tDQo+Pj4gPj4+PiA+ ID4+IEVyaWMNCj4+PiA+Pj4+ID4gPj4NCj4+PiA+Pj4+ID4gPj4gUFMgLQ0KPj4+ID4+Pj4g PiA+PiBGcm9tIFJGQyAyMTE5IC0NCj4+PiA+Pj4+ID4gPj4gJ1NIT1VMRCAgIFRoaXMgd29y ZCwgb3IgdGhlIGFkamVjdGl2ZSAiUkVDT01NRU5ERUQiLCBtZWFuDQo+Pj4gdGhhdCB0aGVy ZQ0KPj4+ID4+Pj4gPiA+PiAgICAgICAgICAgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4g cGFydGljdWxhciBjaXJjdW1zdGFuY2VzDQo+Pj4gdG8NCj4+PiA+Pj4+ID4gPj4gICAgICAg ICAgIGlnbm9yZSBhIHBhcnRpY3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9u cw0KPj4+IG11c3QNCj4+PiA+Pj4+ID4gPj4gICAgICAgICAgIGJlIHVuZGVyc3Rvb2QgYW5k IGNhcmVmdWxseSB3ZWlnaGVkIGJlZm9yZSBjaG9vc2luZw0KPj4+IGENCj4+PiA+Pj4+ID4g Pj4gICAgICAgICAgIGRpZmZlcmVudCBjb3Vyc2UuJw0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+ Pj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+Pj4gPiA+PiBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uDQo+Pj4gQmVoYWxmDQo+Pj4gPj4+PiA+IE9mDQo+Pj4gPj4+PiA+ID4+IFJvbGYgV2lu dGVyDQo+Pj4gPj4+PiA+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDExIDQ6NTcg QU0NCj4+PiA+Pj4+ID4gPj4gVG86IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZw0KPj4+ID4+ Pj4gPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24g ZHJhZnQtaWV0Zi0NCj4+PiBtcGxzLXRwLW9uLQ0KPj4+ID4+Pj4gPiA+PiBkZW1hbmQtY3Yt MDMNCj4+PiA+Pj4+ID4gPj4NCj4+PiA+Pj4+ID4gPj4gSGksDQo+Pj4gPj4+PiA+ID4+DQo+ Pj4gPj4+PiA+ID4+IHNvbWUgY29tbWVudHMgYmVsb3c6DQo+Pj4gPj4+PiA+ID4+DQo+Pj4g Pj4+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxv eW1lbnQgc2NlbmFyaW9zDQo+Pj4gSVANCj4+PiA+Pj4+ID4gPj4gYWRkcmVzc2luZyBtaWdo dCBub3QgYmUNCj4+PiA+Pj4+ID4gPj4gICAgYXZhaWxhYmxlIG9yIGl0IG1heSBiZSBwcmVm ZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tDQo+Pj4gSVANCj4+PiA+Pj4+ID4gPj4g ICAgZW5jYXBzdWxhdGlvbiBmb3IgT24tZGVtYW5kIENWLCByb3V0ZSB0cmFjaW5nIGFuZCBC RkQNCj4+PiBwYWNrZXRzLg0KPj4+ID4+Pj4gPiBJbg0KPj4+ID4+Pj4gPiA+PiAgICBzdWNo IHNjZW5hcmlvcywgT24tZGVtYW5kIENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIFNIT1VMRA0K Pj4+IGJlIHJ1bg0KPj4+ID4+Pj4gPiA+PiAgICB3aXRob3V0IElQIGFkZHJlc3NpbmcuLi4i DQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+IEkgYW0gbm90IHN1cmUgdGhlICJTSE9V TEQiIGlzIHJpZ2h0IGhlcmUuIElmIG5vIElQIGFkZHJlc3NpbmcNCj4+PiBpcw0KPj4+ID4+ Pj4gPiA+PiBhdmFpbGFibGUsIHRoaXMgdGhpbmcgTVVTVCBiZSBydW4gd2l0aG91dCBJUCBh ZGRyZXNzaW5nLA0KPj4+IG11c3RuJ3QgaXQ/DQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ ID4+IEkgdGhpbmsgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVnYXJkaW5nIHBlci1pbnRlcmZh Y2UgTUlQDQo+Pj4gYWRkcmVzc2luZw0KPj4+ID4+Pj4gPiA+PiB3b3VsZCBiZSBuaWNlLiBB cyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBkb2N1bWVudCwgYWxsIFRMVnMNCj4+PiB3aWxs IGJlDQo+Pj4gPj4+PiA+ID4+IGluc2lkZSB0aGUgTFNQIHBpbmcgcGFja2V0IChyYXRoZXIg dGhhbiBhcyBBQ0ggVExWcykuDQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+IFNvbWUg cGVvcGxlIGhhZCBjb25jZXJucyBlYXJsaWVyLCB0aGF0IGFkZHJlc3NpbmcgaW5mb3JtYXRp b24NCj4+PiBzaG91bGQNCj4+PiA+Pj4+ID4gYmUNCj4+PiA+Pj4+ID4gPj4gaW4gYSBmaXhl ZCBsb2NhdGlvbiBmb3IgZWFzaWVyIHByb2Nlc3NpbmcuIElzIHRoaXMgdGhlIGNhc2UNCj4+ PiBoZXJlIEkNCj4+PiA+Pj4+ID4gPj4gd29uZGVyPw0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+ Pj4gPiA+PiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgaW4g eW91cg0KPj4+IHByZXNlbnRhdGlvbiBpbg0KPj4+ID4+Pj4gPiA+PiBQcmFndWUuDQo+Pj4g Pj4+PiA+ID4+DQo+Pj4gPj4+PiA+ID4+IFRoYW5rcywNCj4+PiA+Pj4+ID4gPj4NCj4+PiA+ Pj4+ID4gPj4gUm9sZg0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+Pj4gPiA+Pg0KPj4+ID4+Pj4g PiA+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNl LCAxIFZpY3RvcmlhDQo+Pj4gUm9hZCwNCj4+PiA+Pj4+ID4gPj4gTG9uZG9uIFczIDZCTCB8 IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4gPj4+PiA+ID4+DQo+Pj4gPj4+ PiA+ID4+DQo+Pj4gPj4+PiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ PiA+Pj4+ID4gPj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4gT24NCj4+PiA+Pj4+ID4gQmVoYWxmDQo+Pj4gPj4+ PiA+ID4+IE9mDQo+Pj4gPj4+PiA+ID4+ID4gbG9hQHBpLm51DQo+Pj4gPj4+PiA+ID4+ID4g U2VudDogTWl0dHdvY2gsIDE2LiBN5HJ6IDIwMTEgMDA6MjYNCj4+PiA+Pj4+ID4gPj4gPiBU bzogbXBsc0BpZXRmLm9yZw0KPj4+ID4+Pj4gPiA+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0 ZWFtDQo+Pj4gPj4+PiA+ID4+ID4gU3ViamVjdDogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFz IENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLQ0KPj4+IHRwLW9uLQ0KPj4+ID4+Pj4gPiA+PiBk ZW1hbmQtDQo+Pj4gPj4+PiA+ID4+ID4gY3YtMDMNCj4+PiA+Pj4+ID4gPj4gPg0KPj4+ID4+ Pj4gPiA+PiA+IFdvcmtpbmcgR3JvdXAsDQo+Pj4gPj4+PiA+ID4+ID4NCj4+PiA+Pj4+ID4g Pj4gPiB0aGlzIGlzIHRvIHN0YXJ0IGEgMyB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IG9uDQo+Pj4gPj4+PiA+ID4+ID4NCj4+PiA+Pj4+ID4gPj4gPiBkcmFmdC1pZXRmLW1wbHMt dHAtb24tZGVtYW5kLWN2LTAzDQo+Pj4gPj4+PiA+ID4+ID4NCj4+PiA+Pj4+ID4gPj4gPiBQ bGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QN Cj4+PiA+Pj4+ID4gPj4gPiBtcGxzQGlldGYub3JnDQo+Pj4gPj4+PiA+ID4+ID4NCj4+PiA+ Pj4+ID4gPj4gPiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBBcHJpbCA4 LCAyMDExLg0KPj4+ID4+Pj4gPiA+PiA+DQo+Pj4gPj4+PiA+ID4+ID4gL0xvYQ0KPj4+ID4+ Pj4gPiA+PiA+DQo+Pj4gPj4+PiA+ID4+ID4NCj4+PiA+Pj4+ID4gPj4gPg0KPj4+ID4+Pj4g PiA+PiA+DQo+Pj4gPj4+PiA+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiA+Pj4+ID4gPj4gPiBtcGxzIG1haWxpbmcgbGlzdA0K Pj4+ID4+Pj4gPiA+PiA+IG1wbHNAaWV0Zi5vcmcNCj4+PiA+Pj4+ID4gPj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+PiA+Pj4+ID4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+Pj4+ ID4gPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+PiA+Pj4+ID4gPj4gbXBsc0BpZXRmLm9yZw0K Pj4+ID4+Pj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCj4+PiA+Pj4+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gPj4+PiA+ID5tcGxzIG1haWxpbmcgbGlzdA0KPj4+ID4+Pj4gPiA+ bXBsc0BpZXRmLm9yZw0KPj4+ID4+Pj4gPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo+Pj4gPj4+PiA+ID4NCj4+PiA+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4+PiBtcGxzIG1haWxp bmcgbGlzdA0KPj4+ID4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+ID4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4gPj4+DQo+Pj4gPj4NCj4+PiA+ DQo+Pg0KPg0K --GMAILSMTPBOUND01110518145606-- From yaacov.weingarten@nsn.com Tue May 17 23:18:52 2011 Return-Path: <yaacov.weingarten@nsn.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 74C40E068C for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 23:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74, 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 gaFyLaARLoir for <mpls@ietfa.amsl.com>; Tue, 17 May 2011 23:18:51 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDC2E06C4 for <mpls@ietf.org>; Tue, 17 May 2011 23:18:50 -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 p4I6ImB5019538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 May 2011 08:18:48 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4I6Ik8m032041; Wed, 18 May 2011 08:18:46 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 May 2011 08:18:45 +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_01CC1523.71AD799A" Date: Wed, 18 May 2011 08:18:34 +0200 Message-ID: <E4873516F3FC7547BCFE792C7D94039C3658D7@DEMUEXC013.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for clarification on On-Demand CV draft Thread-Index: AcwVI2qvDwcFq3k6SN+1S1wjMEzVog== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com> To: <mpls@ietf.org>, <draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org> X-OriginalArrivalTime: 18 May 2011 06:18:45.0672 (UTC) FILETIME=[715ADA80:01CC1523] Subject: [mpls] Question for clarification on On-Demand CV draft 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, 18 May 2011 06:18:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1523.71AD799A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In reviewing this document and the TP-Identifiers document there seems to be a discrepancy between the PW identification format between these two documents. On the one hand - the TP Identifiers documents describes the PW identifier by the string - "AGI::East-Global_Node_ID::East-AC_ID::West-Global_Node_ID::West-AC_ID." While on the other hand - the sub-TLV in section 2.3.2 for a static PW includes fields for both E&W Global Node_ID, and both E&W AC_ID, however does not include a field for the AGI - (Attachment Group Identification) - part of the FEC129 definition. Could you please clarify what lies behind this difference? Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CC1523.71AD799A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>Question for clarification on On-Demand CV draft

Hi,

In = reviewing this document and the TP-Identifiers document there seems to = be a discrepancy between the PW identification format between these two = documents.

On the one hand – the TP = Identifiers documents describes = the PW identifier by the string – "AGI::East-Global_Node_ID::East-AC_ID::West-Global_Node_ID::West-AC_I= D."

While on the other hand - the sub-TLV in section 2.3.2 = for a static PW includes fields = for both = E&W Global Node_ID, = and both E&W AC_ID, however does not include a field for the AGI – = (Attachment Group Identification) – part of the FEC129 = definition.

Could you please clarify what lies behind this difference?

Best = regards,

Yaacov = Weingarten

Nokia Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 0977

------_=_NextPart_001_01CC1523.71AD799A-- From binnyjeshan@gmail.com Wed May 18 00:35: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 8F7A5E06A5 for ; Wed, 18 May 2011 00:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnQH8xv8-elN for ; Wed, 18 May 2011 00:35:26 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93CC6E0694 for ; Wed, 18 May 2011 00:35:26 -0700 (PDT) Received: by gwb20 with SMTP id 20so540042gwb.31 for ; Wed, 18 May 2011 00:35: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; bh=0YZAOv9lLthhYbOQT4BUQ4BjUP4WkWYH0an89YsveVw=; b=Mx3c+k4/8zN+krweC2pB5SkegA1FawqlOiYhhYPOiL6AIIabkGQHjiKpwydNUGv844 qwvWaBF7BTPfbMIHUuaQeJzgDnzkd2N4EmlW771kIELd9ZiUU0jTvm5VY79BCOYlFaQK HOjL8KdxBKbLQocgKkZOaeFktYH5M2Ojsp1x8= 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=aDwJ9Wo0ZwkDPaC4kaEQS5qitctMlNJ2Iw0HBlUTguHpecqRDn6McwD1GosRBlEWak K87g1QGp6eMTU+EmRnU260nett/tKLHtSmTgrWXCpDCbGyisz8cWIWU7u27nlCebLrXm BVYLDRcze6ZVhMlMRME8qukzI4dsdUBD4ixFA= MIME-Version: 1.0 Received: by 10.101.183.2 with SMTP id k2mr921772anp.7.1305704125431; Wed, 18 May 2011 00:35:25 -0700 (PDT) Received: by 10.101.132.39 with HTTP; Wed, 18 May 2011 00:35:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 13:05:25 +0530 Message-ID: From: binny jeshan To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" Content-Type: multipart/alternative; boundary=00504502e72493ffcb04a387eece Cc: mpls@ietf.org, draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: [mpls] Question for clarification on On-Demand CV draft 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, 18 May 2011 07:35:27 -0000 --00504502e72493ffcb04a387eece Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yaakov, Group, I could remember the same question being posted last August 2010, and i fee= l this is still open and not answered in the recent drafts also.If in case it= s "intentionally" not included, kindly share your thoughts behind that. Hovever, presently, in case of IP based MEGs, during MEG Validation this AG= I would be validated (AGI:Global_ID::Node_ID::AC_ID, ) , but in case of ICC, this is still open. AGI being unique differentiator added to the FEC129 PW, i feel that somewhere it needs to be validated and as it is closely associated with the PW and not with the MEG, it could be best to validate it as a part of the FEC Sub-TLV. Thanks, Binny. On 18 May 2011 11:48, Weingarten, Yaacov (NSN - IL/Hod HaSharon) < yaacov.weingarten@nsn.com> wrote: > Hi, > > In reviewing this document and the TP-Identifiers document there seems to > be a discrepancy between the PW identification format between these two > documents. > > On the one hand =96 the TP Identifiers documents describes the PW identif= ier > by the string =96 " > AGI::East-Global_Node_ID::East-AC_ID::West-Global_Node_ID::West-AC_ID." > > While on the other hand - the sub-TLV in section 2.3.2 for a static PW > includes fields for both E&W Global Node_ID, and both E&W AC_ID, however > does not include a field for the AGI =96 (Attachment Group Identification= ) =96part of the FEC129 definition. > > Could you please clarify what lies behind this difference? > > Best regards, > > *******Yaacov Weingarten******* > > Nokia Siemens Networks > > Industry Environment, PTE > > ph#: +972-9-775 1827 > > mob#: +972-54-220 0977 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --00504502e72493ffcb04a387eece Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Yaakov, Group,
=A0
I could remember the same question being posted last August 2010, and = i feel this is still open and not answered in the recent drafts also.If in = case its "intentionally" not included, kindly share your thoughts= behind that.
=A0
Hovever, presently, in case of IP based MEGs, during MEG Validation th= is AGI would be validated (AGI:Global_ID::Node_ID::AC_ID,
) , but in cas= e of ICC, this is still open.
AGI being unique differentiator added to the FEC129 PW, i feel that so= mewhere it needs to be validated and as it is closely associated with the P= W and not with the MEG, it could be best to validate it as a part of the FE= C Sub-TLV.
Thanks,
Binny.
=A0
On 18 May 2011 11:48, Weingarten, Yaacov (NSN - = IL/Hod HaSharon) <yaacov.weingarten@nsn.com> wrote:

Hi,

In revi= ewing this document and the TP-Identifiers document there seems to be a dis= crepancy between the PW identification format between = these two documents.

On the one hand =96 the TP Identifiers d= ocuments describes the PW identifier by the string =96 "AGI::East-Gl= obal_Node_ID::East-AC_ID::West-Global_Node_ID::West-AC_ID."

While on the other hand - the sub-T= LV in section 2.3.2 for a static PW i= ncludes fields for both E&W Globa= l Node_ID, and both E&W AC_ID, however does not include a field for th= e AGI =96 (Attachment Group Identifi= cation) =96 part of the FEC129 definition.

Could you please clarify what= lies behind this difference?<= span lang=3D"en-us">

Best regards,

Yaaco= v Weingarten

Nokia Siemens Networks=

Industry Environment, PTE

ph#:=A0 +972-9-775 1827

mob#: +972-54-220 0977


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


--00504502e72493ffcb04a387eece-- From matthew.bocci@alcatel-lucent.com Wed May 18 02:36:47 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 AAD60E0671 for ; Wed, 18 May 2011 02:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 npnSYY+bbzpD for ; Wed, 18 May 2011 02:36:47 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B4796E0724 for ; Wed, 18 May 2011 02:36:46 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4I9ZoWx010556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 May 2011 11:36:43 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 18 May 2011 11:36:17 +0200 From: "Bocci, Matthew (Matthew)" To: "mpls@ietf.org" Date: Wed, 18 May 2011 11:36:14 +0200 Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt Thread-Index: AcwVPwj6V7lB4Cs4QY+CNdtp3wyFmA== Message-ID: In-Reply-To: <4DC95D08.7060305@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.80 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 09:36:47 -0000 Best regards, Matthew 1) ACH and LSP-Ping Based Tools The proposal in the draft defines both ACH and LSP-Ping based methods. However, the draft for the use of LSP Ping in both an IP demultiplexed and ACH demultiplexed mode. Please can you clarify why the additional ACH mode is required? 2) Identification of MEP/MIP at which to create a loopback. It is not clear how the target MEP/MIP identifier is carried. I assume that you just use the MEP/MIP identifier as per draft-ietf-mpls-tp-on-demand-cv-03, but I think the draft should explicitly state this. 2) Relationship to control plane and MPLS in general. The draft seems to present a new way of modifying the forwarding plane on an LSR or PE. This is because setting an LSP or PW into loopback mode would presumably require modifying the FIB at the LSR/PE hosting the MIP or MEP where the loopback is requested. Normally, one would imagine that this would be done by LDP, RSVP-TE, or whatever other control plane protocol has control of the FEC/Label bindings for the LSP/PW. The draft effectively gives an OAM protocol control of this function. This would add complexity to cases where a control plane was used to establish the LSP/PW, and indeed it is not clear how this would work unless there are extensions to the protocol to carry e.g. The FEC for the reverse direction of an LSP, or how you keep the control plane state in sync with what OAM is doing.=20 However, the draft says that the mechanisms are meant to be extensible to MPLS in general. I am not sure there is enough detail in the draft to explain how this can be achieved. I would therefore suggest removing any claims that this could work for MPLS in general and stating that it must not be used with a control plane. As an aside, I think we need an additional mechanism that makes use of the control plane. 3) Security The draft adds the ability for an OAM protocol to modify the forwarding behaviour of a downstream LSR or PE. In my view, this raises a number of security questions. Although the example of PPP chap is given as a mechanism, this is only an example and there is again too little detail about how to use it. Other MPLS-TP OAM protocols have there own well-specified security / authentication mechanisms (e.g. See RFC5880 Section 4.2-4.4 for BFD). Without a strong security mechanism, I think that any intermediate LSR or 'man in the middle' could inject LB request packets and disrupt the forwarding of an LSP or PW at a downstream node. The security section is at present very brief, but I think it should be expanded to explain the possible threats scenarios and how they could be mitigated. I think the draft should explicitly specify which security mechanisms should be used. On 10/05/2011 16:43, "Loa Andersson" wrote: >Working Group, > >this is to start a two week working group last call on > >draft-ietf-mpls-tp-li-lb-01.txt > >Please send your comments to the mpls@ietf.org mailing list. > >This working group last call ends on May 25th. > >/Loa > >for the mpls wg co-chairs > >--=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 internet-drafts@ietf.org Wed May 18 06:10:47 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 28ECDE0737; Wed, 18 May 2011 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 IcpZkDkYLqnQ; Wed, 18 May 2011 06:10:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412D0E0714; Wed, 18 May 2011 06:10:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110518131046.12577.23444.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 06:10:46 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-in-band-signaling-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:10:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Multipoint LDP in-band signaling for Point-to-Multipoint= and Multipoint- to-Multipoint Label Switched Paths Author(s) : IJsbrand Wijnands Toerless Eckert Nicolai Leymann Maria Napierala Filename : draft-ietf-mpls-mldp-in-band-signaling-04.txt Pages : 14 Date : 2011-05-18 Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-in-band-signaling-= 04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-mldp-in-band-signaling-0= 4.txt From internet-drafts@ietf.org Wed May 18 06:48: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 D7B35E06F5; Wed, 18 May 2011 06:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 WwMpmUkB0NZi; Wed, 18 May 2011 06:48:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E7E0688; Wed, 18 May 2011 06:48:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110518134827.12577.73670.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 06:48:27 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 13:48:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Updates to LDP for IPv6 Author(s) : Vishwas Manral Rajiv Papneja Rajiv Asati Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-04.txt Pages : 13 Date : 2011-05-18 The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-04.txt From loa@pi.nu Wed May 18 08:56: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 7BAF8E069C; Wed, 18 May 2011 08:56:42 -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 XZUiWen4cqjC; Wed, 18 May 2011 08:56:41 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA6E06E0; Wed, 18 May 2011 08:56:39 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 CB9082A8001; Wed, 18 May 2011 17:56:36 +0200 (CEST) Message-ID: <4DD3EC33.8050203@pi.nu> Date: Wed, 18 May 2011 17:56:35 +0200 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: The IESG , "draft-ietf-mpls-loss-delay@tools.ietf.org" Content-Type: multipart/mixed; boundary="------------060908050007020806070307" Cc: Ross Callon , MPLS-TP ad hoc team , "mpls@ietf.org" Subject: [mpls] Request for publication of two mpls working group documents 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, 18 May 2011 15:56:42 -0000 This is a multi-part message in MIME format. --------------060908050007020806070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG, the MPLS working group requests that: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 is published as an Informational RFC on the standards track; and that: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 is published as an informational RFC. This document is supposed be published as an IETF consensus document (IETF Last call). The shepherd write-up is included for both documents. /Loa on behalf of the MPLS working group. -- 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 --------------060908050007020806070307 Content-Type: text/plain; name="loss-delay.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loss-delay.txt" The MPLS WG requests that: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 is published as an Informational RFC on the standards track. Note: We are at the same time requesting publication for: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 These two draft started out as a single draft, but the working group decided to split them into two separate draft. One generic MPLS draft and one specific for MPLS based transport Networks. It is not strictly necessary, but recommended, to progress these two draft in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been reviewed in thr mpls working groups The shephered is convinced that this is sufficient review for this framework document. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. There is no IPR claim for this draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is a good consensus around this draft. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The nits tool does give some warnings, these can be address as we resolve comments during the AD, IESG and IETF review process. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. There is a normative reference to an IEEE document. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There are a well-written IANA section in this document with the following requests of IANA: o Allocation of Channel Types in the PW Associated Channel Type registry o Creation of a Measurement Timestamp Type registry o Creation of an MPLS Loss/Delay Measurement Control Code registry o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object registry > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary The ability to mesure and monitor one and two-way packet loss and delay performance metrics is the basis needed by service providers to deliver SLAs. These metrics are also that realted to delay variation and channel throughput. This measurement capability also providesgreater visibility for operators into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. This document specifies two closely-related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). Working Group Summary This document is a MPLS working group document, and stricly not a part of the MPLS-TP project, however the companion functionality for MPLS based Transport Networks is based on this document. The working goroup have reviewed the document with this in mind. Document Quality The document is well reviewed in the MPLS working group. --------------060908050007020806070307 Content-Type: text/plain; name="loss-delay-profile.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loss-delay-profile.txt" The MPLS WG requests that: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 is published as an informational RFC. This document is supposed be publsied as an IETF consensus document (IETF Last call). Note: We are at the same time requesting publication for: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 These two draft started out as a single draft, but the working group decided to split them into two separate draft. One generic MPLS draft and one specific for MPLS based transport Networks. It is not strictly necessary, but recommended, to progress these two draft in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been reviewed in the mpls working group and in the ITU-T SG15 as part of the joint MPLS-TP project The shephered is convinced that this is sufficient review for this framework document. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. There is no IPR claim for this draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is a good consensus around this draft. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The nits tool does give some warnings, these can be address as we resolve comments during the AD, IESG and IETF review process. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There are no IANA allocations requested by this document. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary This document is based on draft-ietf-mpls-loss-delay and makes necessary adaptions of the one and two-way packet loss and delay performance metrics for MPLS based transport Networks. Working Group Summary This document is a MPLS working group document, and part of the MPLS-TP project. Meaning that it has been reviewed by ITU-T SG15 as part of the working group last call process. Document Quality The document is well reviewed in the MPLS working group and SG15. --------------060908050007020806070307-- From loa@pi.nu Wed May 18 09:18: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 6FEBBE071E; Wed, 18 May 2011 09:18:43 -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 R2JWg8PTmIOy; Wed, 18 May 2011 09:18:42 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF8E0714; Wed, 18 May 2011 09:18:38 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 A0D562A8001; Wed, 18 May 2011 18:18:36 +0200 (CEST) Message-ID: <4DD3F15A.1080608@pi.nu> Date: Wed, 18 May 2011 18:18:34 +0200 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: The IESG , "draft-ietf-mpls-loss-delay@tools.ietf.org" References: <4DD3EC33.8050203@pi.nu> In-Reply-To: <4DD3EC33.8050203@pi.nu> Content-Type: multipart/mixed; boundary="------------090102090908040102060407" Cc: Ross Callon , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: [mpls] Update: Re: Request for publication of two mpls working group documents [www.ietf.org/rt #38180] 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, 18 May 2011 16:18:43 -0000 This is a multi-part message in MIME format. --------------090102090908040102060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG, the MPLS working group requests that: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 is published as a RFC on the standards track; and that: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 is published as an informational RFC. This document is supposed be published as an IETF consensus document (IETF Last call). The shepherd write-up is included for both documents. /Loa on behalf of the MPLS working group. -- 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 --------------090102090908040102060407 Content-Type: text/plain; name="loss-delay-profile.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loss-delay-profile.txt" The MPLS WG requests that: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 is published as an informational RFC. This document is supposed be publsied as an IETF consensus document (IETF Last call). Note: We are at the same time requesting publication for: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 These two draft started out as a single draft, but the working group decided to split them into two separate draft. One generic MPLS draft and one specific for MPLS based transport Networks. It is not strictly necessary, but recommended, to progress these two draft in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been reviewed in the mpls working group and in the ITU-T SG15 as part of the joint MPLS-TP project The shephered is convinced that this is sufficient review for this framework document. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. There is no IPR claim for this draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is a good consensus around this draft. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The nits tool does give some warnings, these can be address as we resolve comments during the AD, IESG and IETF review process. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There are no IANA allocations requested by this document. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary This document is based on draft-ietf-mpls-loss-delay and makes necessary adaptions of the one and two-way packet loss and delay performance metrics for MPLS based transport Networks. Working Group Summary This document is a MPLS working group document, and part of the MPLS-TP project. Meaning that it has been reviewed by ITU-T SG15 as part of the working group last call process. Document Quality The document is well reviewed in the MPLS working group and SG15. --------------090102090908040102060407 Content-Type: text/plain; name="loss-delay.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="loss-delay.txt" The MPLS WG requests that: Packet Loss and Delay Measurement for MPLS Networks draft-ietf-mpls-loss-delay-02 is published as an RFC on the standards track. Note: We are at the same time requesting publication for: A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks draft-ietf-mpls-tp-loss-delay-profile-03 These two draft started out as a single draft, but the working group decided to split them into two separate draft. One generic MPLS draft and one specific for MPLS based transport Networks. It is not strictly necessary, but recommended, to progress these two draft in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Loa Andersson is the Document Shepherd. He has reviewed the document and believes it is ready to be forwarded to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has been reviewed in thr mpls working groups The shephered is convinced that this is sufficient review for this framework document. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No such concerns. There is no IPR claim for this draft. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? There is a good consensus around this draft. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats or extreme discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? The nits tool does give some warnings, these can be address as we resolve comments during the AD, IESG and IETF review process. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References are correctly split. There is a normative reference to an IEEE document. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? There are a well-written IANA section in this document with the following requests of IANA: o Allocation of Channel Types in the PW Associated Channel Type registry o Creation of a Measurement Timestamp Type registry o Creation of an MPLS Loss/Delay Measurement Control Code registry o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object registry > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: Technical Summary The ability to mesure and monitor one and two-way packet loss and delay performance metrics is the basis needed by service providers to deliver SLAs. These metrics are also that realted to delay variation and channel throughput. This measurement capability also providesgreater visibility for operators into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. This document specifies two closely-related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). Working Group Summary This document is a MPLS working group document, and stricly not a part of the MPLS-TP project, however the companion functionality for MPLS based Transport Networks is based on this document. The working goroup have reviewed the document with this in mind. Document Quality The document is well reviewed in the MPLS working group. --------------090102090908040102060407-- From Adrian.Farrel@huawei.com Wed May 18 09:53: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 15F10E0709 for ; Wed, 18 May 2011 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.404 X-Spam-Level: X-Spam-Status: No, score=-105.404 tagged_above=-999 required=5 tests=[AWL=0.595, 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 lnJ9Z3HVJSGm for ; Wed, 18 May 2011 09:53:46 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id C178CE0665 for ; Wed, 18 May 2011 09:53:46 -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 <0LLE00M5QHLLQL@usaga03-in.huawei.com> for mpls@ietf.org; Wed, 18 May 2011 11:53:45 -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 <0LLE0059KHLJV1@usaga03-in.huawei.com> for mpls@ietf.org; Wed, 18 May 2011 11:53:45 -0500 (CDT) Date: Wed, 18 May 2011 17:53:42 +0100 From: Adrian Farrel To: draft-ietf-mpls-ldp-p2mp@tools.ietf.org Message-id: <020701cc157c$259b8960$70d29c20$@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: AcwVfCLJ/uvpAK9QQtuKIHH6UQlc7A== Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ldp-p2mp 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: Wed, 18 May 2011 16:53:48 -0000 Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. Most of my comments are pretty trivial, but there are quite a few of them and a couple need a bit of discussion. I think this merits a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- As noted in the write-up, RFC 4664 is an unused reference. I think it can simply be removed unless it was intended to be added to the final paragraph of Section 1. --- Abstract Some consistency in hyphenation, please. I think you need to adopt "point-to-multipoint" and "multipoint-to-multipoint" as in the title. --- Acronyms Need to expand them on first use in the main text (Abstract doesn't count). I find: (LDP is a permitted acronym - no action needed) LSP LSR --- Please s/draft/document/ in the text so that when it is published as an RFC the text is accurate. --- Section 1 Only a single copy of the packet will be sent on any link traversed by the MP LSP (see note at end of Section 2.4.1). Is this strictly true in all cases. are there not fringe cases, just as there were in P2MP RSVP-TE, where a branch is logically made upstream of a common link because of limited branching capabilities at the downstream end of the link? --- Section 1.2 Leaf node: A Leaf node can be either an Egress or Bud LSR when referred in the context of a P2MP LSP. In the context of a MP2MP LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. I think... s/an LSR is both Ingress and Egress/a leaf is both Ingress and Egress/ --- Section 2.1 The figure in this section appears to state that the S-bit must always be set to 1. That means that the capability cannot be withdrawn. I have no issue with that, but I think that if this is you intention, you must say that the S-bit must always be set to 1, the capability cannot be withdrawn, and the processing if S=0 is received. OTOH, if you allow withdrawal, you can leave "S" in the figure and refer to RFC5561 for the meaning. --- Pedantic point I don't propose you address (unless you have more spare than you should have)... The Opaque Value field is not truly opaque, since we can look into it and find a series of opaque elements. --- Section 2.2 Can you explain to me why the working group wanted to allow the P2MP FEC to use any address family from IANA's "Address Family Numbers" registry to identify the root LSR? --- Section 2.2 The combination of (Root Node Address, Opaque Value) uniquely identifies a P2MP LSP within the MPLS network. With the current specification as shown in the figure, this is not completely accurate since two addresses from different families could have the same root node address value. So your text should refer to the combination of {Root Node Address type, Root Node Address, Opaque Value). --- 2.3 OLD Type: The Type of the LDP MP Opaque Value Element basic type is to be assigned by IANA. NEW Type: The Type of the LDP MP Opaque Value Element. IANA maintains a registry of basic types (see Section 11). --- 2.3 We don't generally define empty TLVs and objects. Can you convince me of the need for the Extended Type? Are you predicting a large number of FCFS opaque values?. You are surely not expecting many standards track types. --- 2.3 OLD Extended Type: The Extended Type of the LDP MP Opaque Value Element extended type is to be assigned by IANA. NEW Extended Type: The Extended Type of the LDP MP Opaque Value Element. IANA maintains a registry of extended types (see Section 11). --- A point of pedantry, but you repeatedly refer to the "Label Map" message and (of course :-) it is really the "Label Mapping" message. --- 2.4 2. P2MP Label Map : a Label Map message with a FEC TLV with a single P2MP FEC Element and Label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031] section 3.14) of the LSR sending the Label Map Message. While you are at liberty to make this "MUST" requirement with the WGs support, it would be good if you gave the reason rather than "sneaking" it in. I assume that you want to do this to make FRR easier, but it is not immediately clear why P2MP is in any way different from P2P on upstream interfaces. Or maybe it is because you want to allow the choice of downstream interface to rest with the upstream LSR (per 2.4.1.2). Can you add a short clause to say why the per-platform label space is used? --- 2.4.1 The remainder of this section specifies the procedures for originating P2MP Label Map messages and for processing received P2MP s/The remainder of this/This/ --- You have two instances (spot the block copy!) of "label map" in lower case. --- 2.4.1.1 A node Z that wants to join a MP LSP determines the LDP peer U which is Z's next-hop on the best path from Z to the root node X. If there is more than one such LDP peer, only one of them is picked. U is Z's "Upstream LSR" for . When there are several candidate upstream LSRs, the LSR MAY select one upstream LSR. The "MAY" seems to be in contradiction to the previous paragraph that appears to say that the LSR MUST select exactly one upstream LSR. --- 2.4.1.1 CRC32 is not a well-known acronym and would benefit from a reference. --- 2.4.1 and 2.4.1.1 It seems that it is important to be precise about what is meant by the "opaque value" (Y). This is particularly important in 2.4.1.1 because there is an interop dependency relying on the input to the hash function. You might mean: - the whole opaque value TLV - the opaque value field of the opaque value TLV (i.e., the concatenation of the whole opaque value elements) - the value field of the opaque value element - the concatenation of the value fields from each of the value fields of the opaque value elements Please add text to clarify (at least for the CRC32 case). --- 2.4.1.4 Trivially... Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. Misses the case that I=Ii for some value of i. --- 2.4.2.1 If a leaf node Z discovers (by means outside the scope of this document) that it has no downstream neighbors in that LSP, and that it has no need to be an egress LSR for that LSP, then it SHOULD send Just some subtle re-wording needed. We *do* know the means by which Z discovers it has no downstream neighbors -- that is what this document is about! The parentheses apply to the second clause (that it has no need to be an egress). --- 2.4.2.2. In the light of the procedure set out in 2.4.3 and 8., should you recommend that propagation of Label Withdraw should be delayed to prevent full LSP teardown when there is a small change in the path of the trunk of an LSP? Maybe a fringe case we can leave to implementations? --- Section 3 Many of the nits in section 2 apply here, too. --- Section 3 While it is possible that the root of an MP2MP LSP is also a leaf and can act as a data source, I think that... An MP2MP LSP is much like a P2MP LSP in that it consists of a single root node, zero or more transit nodes and one or more leaf LSRs acting equally as Ingress or Egress LSR. Should read "two or more leaf LSRs" since the semantic change from P2MP is that leaf nodes are ingresses as well as egresses, and it would make no sense to have only one. --- Section 3 I can't help feeling that some figures would help understanding the path that packets are expected to take on an MP2MP LSP since this is key to working out what label state is installed. ---- 5.1 OLD Type: The type of the LDP MP Status Value Element is to be assigned by IANA. NEW Type: The type of the LDP MP Status Value Element. IANA maintains a registry of status value types (see Section 11). And in the figure s/Type(TBD)/Type/ --- 5.2. LDP Messages containing LDP MP Status messages The LDP MP status message may appear either in a label mapping message or a LDP notification message. I think s/status message/status TLV/ throughout. --- 5.2.1 An LDP MP status TLV sent in a notification message must be accompanied with a Status TLV. This is a statement of fact not a piece of new protocol spec, so you are correct to use lower case "must". But you should include a reference at this point. --- 7.1. Root node redundancy - procedures for P2MP LSPs Since all leafs have set up P2MP LSPs to all the roots, they are prepared to receive packets on either one of these LSPs. However, only one of the roots should be forwarding traffic at any given time, for the following reasons: 1) to achieve bandwidth savings in the network and 2) to ensure that the receiving leafs don't receive duplicate packets (since one cannot assume that the receiving leafs are able to discard duplicates). How the roots determine which one is the active sender is outside the scope of this document. The "should" seems strong since I know of deployed networks where 1+1 style P2MP transmission is performed and the application layer is responsible for sorting out duplicates that arise on failover. 1+1 is chosen in the face of network cost because of the high level of reliability that is wanted. --- 8.3 Same issue with the S-bit apparently always set meaning the capability cannot be withdrawn. --- Section 9 This is not clear. The figure shows "Type=mLDP". There are two FEC Elements defined in the document so I think you need... OLD 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed Wcard | Type = mLDP | Len = 2 | AFI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | +-+-+-+-+-+-+-+-+ Type Wcard: As specified in [RFC5918] Type: mLDP FEC Element Type as documented in this draft. NEW 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed Wcard | Type | Len = 2 | AFI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | +-+-+-+-+-+-+-+-+ Type Wcard: As specified in [RFC5918] Type: The type of FEC Element Type. Either the P2MP FEC Element or the MP2MP FEC Element using the values defined for those FEC Elements when carried in the FEC TLV as defined in this document --- Section 10 I am a bit disappointed by the Security Section. While it is true that the security relationships and techniques between LDP peers are not changed, and the imperatives are the same, you have introduced a new type of service that has a new attack vector. In P2P LSPs, the sender has some control over the receiver, but this is less the case in leaf-initiated join to P2MP LSPs. I think this section should at least note that there is no way for a root to validate the leafs of the P2MP tree. Probably the only security you can offer is that; - the leafs all form part of the same trusted network - the opaque values could be made unguessably large - the opaque values could be distributed in a secure way --- Section 11 Can you please add... The requested code point values listed below have been allocated by IANA through early allocation. ...between... The allocation policy for this space is 'Standards Action with Early Allocation' ...and... This document requires allocation of three new code points from the IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are: From rcallon@juniper.net Wed May 18 11:44:33 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 022EDE06B0 for ; Wed, 18 May 2011 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LJnj78XSjzmj for ; Wed, 18 May 2011 11:44:31 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id EC9A7E072C for ; Wed, 18 May 2011 11:44:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTdQTicJ+30qU7LVmGhtg8gRz7FcCAXtB@postini.com; Wed, 18 May 2011 11:44:30 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; Wed, 18 May 2011 11:40:37 -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; Wed, 18 May 2011 14:40:37 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 18 May 2011 14:40:34 -0400 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gR/Ioew 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_DF7F294AF4153D498141CBEFADB17704C220004B75EMBX01WFjnprn_" 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, 18 May 2011 18:44:33 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C220004B75EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for= the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) cons= ensus is to leave the document as currently defined. The authors are theref= ore instructed to continue progression of draft-ietf-mpls-tp-identifiers wi= thout a change in this area. This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers. Thanks, Ross and Loa (as MPLS WG chairs) [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] 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_DF7F294AF4153D498141CBEFADB17704C220004B75EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mixing ICC and Global-IDs in MPLS-TP = Identifiers?

After dis= cussion on the MPLS WG email list, there is no consensus to change draft-ie= tf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for th= e same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consens= us is to leave the document as currently defined. The authors are therefore= instructed to continue progression of draft-ietf-mpls-tp-identifiers witho= ut a change in this area.

=  

This decision neith= er supports nor precludes the possibility that at some point in the future,= after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, = the WG might consider additional work to extend the MPLS protocols to allow= mixed identifiers.

 

Thanks,

Ross and Loa (as MPLS WG chairs)

 

[Note that since George is co-author of draft-ietf-mp= ls-tp-identifiers, for this one document he is recused from his role as WG = co-chair.]

 

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

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] Mix= ing ICC and Global-IDs in MPLS-TP Identifiers?

<= /div>

 

All -

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

The identifiers for Tunnel, LSP, PW, and MEG include field= s 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 f= or both ends.  Mixed use is not permitted.

The ITU liaison requ= ests that we allow mixed use.

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

  1. Obtaining an AS Number (from which the Global-ID is deri= ved) is a fairly trivial procedure.  Many organizations if not most al= ready have AS Numbers.
  2. Su= ch 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 si= gnaling messages), the providers involved will need to run BGP and have AS = numbers.


We are looking for i= nput/consensus from the WG.

George, Eric, & Matthew =

= --_000_DF7F294AF4153D498141CBEFADB17704C220004B75EMBX01WFjnprn_-- From erminio.ottone_69@libero.it Wed May 18 13:53: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 368FCE0699 for ; Wed, 18 May 2011 13:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 8MdWsPzJlh-p for ; Wed, 18 May 2011 13:53:42 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 98B9AE068B for ; Wed, 18 May 2011 13:53:40 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4DD431CF.0059,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D5002F3480; Wed, 18 May 2011 22:53:34 +0200 Message-ID: <9391958.1470131305752014482.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 22:53:34 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_102125_3384551.1305752014481" X-SenderIP: 79.17.209.18 Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 20:53:43 -0000 ------=_Part_102125_3384551.1305752014481 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am a bit surprised by the decision to cut such an important discussion. =20 While it is true that there is no (yet?) agreement on mixing of Global-IDs = and ICC=E2=80=99s, the discussion has clarified that there are major holes = both in the Requirements RFC (at least RFC5680) as well as in this document= (which also do not fullfill the incomplete set of requirements of RFC5680)= . One of the argument against the proposal was the lack of requirements for s= upporting inter-domain LSP/PW. However, during the discussion it appeared t= hat this scenario is required by RFC5680. As the draft in its current form = does not address this scenario, it is clearly not fullfilling the requireme= nts of RFC5680, =20 There are other related issues which I am going to raise by replying to som= e mails on this thread. ----Messaggio originale---- Da: rcallon@juniper.net Data: 18-mag-2011 20.40 A: "mpls@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Mixing ICC and Global-IDs in MPLS-TP Identifiers?@font-face =09{font-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face =09{font-family:Tahoma; =09panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face =09{font-family:Verdana; =09panose-1:2 11 6 4 3 5 4 4 2 4;} p.MsoNormal, li.MsoNormal, div.MsoNormal =09{margin:0in; =09margin-bottom:.0001pt; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink =09{mso-style-priority:99; =09color:blue; =09text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed =09{mso-style-priority:99; =09color:purple; =09text-decoration:underline;} span.EmailStyle17 =09{mso-style-type:personal-reply; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} .MsoChpDefault =09{mso-style-type:export-only; =09font-size:10.0pt;} @page WordSection1 =09{size:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 =09{page:WordSection1;} @list l0 =09{mso-list-id:1179468456; =09mso-list-template-ids:-1043187258;} @list l0:level1 =09{mso-level-tab-stop:.5in; =09mso-level-number-position:left; =09text-indent:-.25in;} ol =09{margin-bottom:0in;} ul =09{margin-bottom:0in;} ->@font-face =09{font-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face =09{font-family:Tahoma; =09panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face =09{font-family:Verdana; =09panose-1:2 11 6 4 3 5 4 4 2 4;} p.MsoNormal, li.MsoNormal, div.MsoNormal =09{margin:0in; =09margin-bottom:.0001pt; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink =09{mso-style-priority:99; =09color:blue; =09text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed =09{mso-style-priority:99; =09color:purple; =09text-decoration:underline;} span.EmailStyle17 =09{mso-style-type:personal-reply; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} .MsoChpDefault =09{mso-style-type:export-only; =09font-size:10.0pt;} @page WordSection1 =09{size:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 =09{page:WordSection1;} @list l0 =09{mso-list-id:1179468456; =09mso-list-template-ids:-1043187258;} @list l0:level1 =09{mso-level-tab-stop:.5in; =09mso-level-number-position:left; =09text-indent:-.25in;} ol =09{margin-bottom:0in;} ul =09{margin-bottom:0in;} -> --> After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80= =99s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rou= gh) consensus is to leave the document as currently defined. The authors ar= e therefore instructed to continue progression of draft-ietf-mpls-tp-identi= fiers without a change in this area. =20 This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers.=20 =20 Thanks, Ross and Loa (as MPLS WG chairs) =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] =20 =20 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? =20 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. =20 Obtaining an AS Number (from which the Global-ID is derived) is a fairly tr= ivial procedure. Many organizations if not most already have AS Numbers.= =20 Such an addition will add numerous object formats, and test cases.=20 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 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. Ho= wever 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. George, Eric, & Matthew=20 ------=_Part_102125_3384551.1305752014481 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am a bit surprised by the decision to cut such an important discussion= .

 

While it is true that there is no (yet?) agreement on mixing of Global-I= Ds and ICC=E2=80=99s, the discussion has clarified that there are major hol= es both in the Requirements RFC (at least RFC5680) as well as in this docum= ent (which also do not fullfill the incomplete set of requirements of RFC56= 80).

One of the argument against the proposal was the lack of requirements fo= r supporting inter-domain LSP/PW. However, during the discussion it appeare= d that this scenario is required by RFC5680. As the draft in its current fo= rm does not address this scenario, it is clearly not fullfilling the requir= ements of RFC5680,

 

There are other related issues which I am going to raise by replyin= g to some mails on this thread.

----Messaggio originale----
Da: rcallon@juniper.net
Data:= 18-mag-2011 20.40
A: "mpls@ietf.org"<mpls@ietf.org>
Ogg: Re: [= mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

A= fter discussion on the MPLS WG email list, there is no consensus to change = draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80= =99s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rou= gh) consensus is to leave the document as currently defined. The authors ar= e therefore instructed to continue progression of draft-ietf-mpls-tp-identi= fiers without a change in this area.

<= o:p> 

T= his decision neither supports nor precludes the possibility that at some po= int in the future, after draft-ietf-mpls-tp-identifiers is approved and pub= lished as an RFC, the WG might consider additional work to extend the MPLS = protocols to allow mixed identifiers.

<= o:p> 

T= hanks,

R= oss and Loa (as MPLS WG chairs)

<= o:p> 

[= Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for = this one document he is recused from his role as WG co-chair.]

<= o:p> 

<= o:p> 

From:<= /B> mpls-bounces@ietf.org [mailto:mpl= s-bounces@ietf.org] On Behalf Of George Swallow
Sent: Mond= ay, 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.  Curr= ently the draft allows a Tunnel, LSP, PW, or MEG to use either the Global-I= D for both ends or or the ICC for both ends.  Mixed use is not permitt= ed.

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)= is a fairly trivial procedure.  Many organizations if not most alread= y 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.  I= f 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 ha= ve AS numbers.


We are look= ing for input/consensus from the WG.

George, Eric, & Matthew



------=_Part_102125_3384551.1305752014481-- From erminio.ottone_69@libero.it Wed May 18 13:59:45 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 3AF46E0775 for ; Wed, 18 May 2011 13:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.001, 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 FM9pNOOcChXw for ; Wed, 18 May 2011 13:59:44 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id AA578E0699 for ; Wed, 18 May 2011 13:59:43 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4DD4333B.0048,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D5002F4D89; Wed, 18 May 2011 22:59:39 +0200 Message-ID: <33481731.1472341305752379044.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 22:59:39 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.17.209.18 Cc: "mpls@ietf.org" Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 20:59:45 -0000 Well, I understand (and I agree) that it is possible to setup via NMS an LSP or a MS-PW that crosses both IP-based and ICC-based domains even if there is no e2e OAM. As this is possible, there is no realistic way to force the ICC-based operators to support also IP-based identification nor viceversa. The issue is that the draft in its current form does not allow giving a name to such an LSP or MS-PW. If you allow mixing IP-based and ICC-based identifiers for path ID (as proposed by ITU-T), naming these LSPs/MS-PWs becomes very trivial. As I stated in another mail, I do not see any protocol implications on mixing ICC and IP identifiers for path identification so it is not very clear what is the technical issue in accepting the ITU-T comment at least for path identification purposes. >----Messaggio originale---- >Da: gregory.mirsky@ericsson.com >Data: 3-mag-2011 0.31 >A: "erminio.ottone_69@libero.it", "Malcolm. BETTS@zte.com.cn" >Cc: "mpls@ietf.org" >Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Dear Erminio, >I don't see an issue with NMS setting an LSP that crosses domains that utilize different, IP-based and ICC-based, identifiers. The problem, as being identified, in running e2e OAM on such LSP. > > Regards, > Greg > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erminio.ottone_69@libero.it >Sent: Monday, May 02, 2011 2:58 PM >To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn >Cc: mpls@ietf.org; mpls-bounces@ietf.org >Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Section 2.1.4 of RFC5860 states: > > For certain functions, OAM messages need to incorporate > identification information (e.g., of source and/or destination > nodes). The protocol solution(s) MUST at least support > identification information in the form of an IP addressing structure > and MUST also be extensible to support additional identification > schemes. > >If an operator A supports IP-based identifiers and operator B supports ICC- based identifiers, how can we setup a transport path (LSP or PW) between the two operators? > > >----Messaggio originale---- >Da: gregimirsky@gmail.com >Data: 28-apr-2011 1.11 >A: >Cc: "mpls@ietf.org", >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >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 >ToGeorge Swallow , "mpls@ietf.org" >ccSubjectRe: [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 > > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed May 18 14:19: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 756ABE0770 for ; Wed, 18 May 2011 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_17=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 9HVi8hZa4KE5 for ; Wed, 18 May 2011 14:19:01 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1F141E074A for ; Wed, 18 May 2011 14:19:00 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4DD437BF.0171,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23D7C002EC8A5; Wed, 18 May 2011 23:18:55 +0200 Message-ID: <6563425.1480371305753535566.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 23:18:55 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "eric.gray@ericsson.com" , "huubatwork@gmail.com" , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.51.154.59 Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:19:02 -0000 I am not the one who brought G.8113.1 on the table. I was replying to a mai= l=20 that did that arguing why this is relevant. >----Messaggio originale---- >Da: jdrake@juniper.net >Data: 4-mag-2011 2.53 >A: "erminio.ottone_69@libero.it", "eric. gray@ericsson.com", "huubatwork@gmail.com" , "mpls@ietf.org" >Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Comments inline. > >Sent from my iPhone > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: Monday, May 02, 2011 3:32 PM >> To: eric.gray@ericsson.com; huubatwork@gmail.com; mpls@ietf.org >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >> Identifiers? >>=20 >> I do not understand how this discussion is related to the OAM debate >> regarding >> G.8113.1. > >JD: Um, what is G.8113.1, what is "the OAM debate regarding G.8113.1", an= d=20 what does either topic have to do with the identifiers draft? > >>=20 >> Nevertheless, I have not seen any supporter of G.8113.1 stating no need >> for >> end-to-end OAM nor the need for an OAM interworking function between >> G.8113.1 >> and IETF-OAM domains. > >JD: This is simply baffling > >>=20 >> Could you provide some reference about this? I might have missed them. >>=20 >> ----Messaggio originale---- >> Da: eric.gray@ericsson.com >> Data: 28-apr-2011 23.17 >> A: "huubatwork@gmail.com", >> "mpls@ietf.org"> org> >> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >> Huub, Please see below... --Eric >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub >> 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? >>=20 >> Hi Malcolm, >>=20 >> 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! >>=20 >> Actually I think a fair number of us disagree. It seems obvious (to me >> at >> least) that some sort of OAM interworkingfunction is going to be >> necessary, >> given that there is almost certainlya non-null intersection of >> operators that >> use ICC format identifiers, whoalso 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 >> identifiersand may very well use OAM as specified in IETF RFCs. Given >> that such >> an interworking requirement is likely, it is a far betteruse of time >> and energy >> to start thinking about how such an interworkingfunction would work and >> would >> most likely support translation of ICC andGlobal Identifiers. It is >> certainly a >> better use of time and energy than it is to try to support 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 >> 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. >>=20 >> 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 insome >> of the >> less temperate zones. Should this be formalized as a crystal clear >> housing >> requirement, I'mpretty sure that no one would subsequently interpret it >> to mean >> thatboth the furniture and the furnace need to be able to occupy the >> samespace >> in the same house. Since the apparent "requirement" that the same >> messages >> should beable to include either or both of the required identifiers, >> and this >> is notobvious from the assertion of a requirement to merely allow >> support >> forboth, this is indeed a late-breaking requirement. >> Best regards, Huub. >>=20 >>=20 >>=20 >> Sent from my mobile device. John E Drake >> 27/04/2011 07:25 >> PM >> To"Malcolm.BETTS@zte.com.cn" ccEric Gray >> > gray@ericsson.com>, "mpls@ietf.org" , "mpls- >> bounces@ietf.org" >> SubjectRE: [mpls] Mixing ICC and Global-IDs in >> MPLS-TP >> Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> I interpreted Eric=E2=80=99s use of =E2=80=98stitching=E2=80=99 to be = in the RFC 5150 sense. >> I >> think I will let him clarify, but if used in the RFC 5150 sense, a >> =E2=80=98stitched=E2=80=99 >> LSP would have end-to-end OAM, and different pieces could use 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] >> 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 27/04/2011 06:53 PM >>=20 >> To"Malcolm.BETTS@zte.com.cn" , Eric Gray >> > gray@ericsson.com> cc"mpls@ietf.org" , "mpls- >> bounces@ietf.org" >> SubjectRE: [mpls] Mixing ICC and Global-IDs in >> MPLS-TP >> Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> That=E2=80=99s incorrect. There is a single end-to-end LSP composed of >> different >> pieces, each under the control of a different administrative entity. >>=20 >> Thanks, >>=20 >> John >>=20 >> Sent from my iPhone >>=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 >> Eric Gray >> Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM >>=20 >> ToGeorge Swallow , "mpls@ietf.org" >> cc >> SubjectRe: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=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? >>=20 >> 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 >> 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. >>=20 >> We are looking for input/consensus from the WG. >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed May 18 14:25: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 7778CE0748 for ; Wed, 18 May 2011 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 ytRjOqgCDNYA for ; Wed, 18 May 2011 14:25:03 -0700 (PDT) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by ietfa.amsl.com (Postfix) with ESMTP id E0659E068B for ; Wed, 18 May 2011 14:25:02 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0205.4DD4392B.00E0,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out3.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23CD0002F057A; Wed, 18 May 2011 23:24:59 +0200 Message-ID: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 23:24:59 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.51.154.59 Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:25:04 -0000 Appendix II of Y.1731 provides a good example about how inter-domain connectivity with e2e OAM can be provided using transport-oriented OAM functions. You can download the latest version of Y.1731 (the pdr version is for free) at the following URL: http://www.itu.int/rec/T-REC-Y.1731/en It is a pity that with the current version of the identifier draft, MPLS-TP is not capable to support such a network scenario. >----Messaggio originale---- >Da: loa@pi.nu >Data: 4-mag-2011 8.00 >A: , "Malcolm.BETTS@zte.com.cn" >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Malcolm, > >are you saying that operators today allow OAM to control node (MIPs and >MEPs) on each others networks? > >Do we have an operator that can verify this? > >/Loa > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >> >> All, >> >> I share your concerns and doubts about a multi carrier control plane. >> However, I think that it is essential that a transport network supports >> multi carrier data plane interconnection with end to end OAM. In today's >> transport network this interconnection is supported by SDH and OTN. The >> objective for MPLS-TP is to allow for packet based interconnection as well. >> >> Regards, >> >> Malcolm >> >> >> >> *George Swallow * >> Sent by: mpls-bounces@ietf.org >> >> 03/05/2011 11:09 AM >> >> >> To >> "Andrew G. Malis" , >> cc >> mpls@ietf.org >> Subject >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> >> >> >> >> >> >> >> Andy - >> >> > Such >> > an E-NNI definition does not yet exist for MPLS-TP (something else to >> > put on the to-do list). This E-NNI would also include similar >> > identifier mapping/translation for MS-PWs, to answer an earlier >> > question from Erminio that I saw on the list. >> >> You are quite correct here! I think much of this debate surrounds a problem >> that is yet to be solved. So there are arguments for pieces of a solution >> without and overall architecture. >> >> Based on all that I am seeing my inclination is to NOT say that we disallow >> mixed identifiers, but to say that they are for future study. >> >> ...George >> >> >> >> >> >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >> >> > Neil, >> > >> > To your case 1, we're in complete agreement. We (VZ) don't see at >> > least a short-term need for peer-layer interworking, given where we >> > intend to deploy MPLS-TP in our infrastructure (as an internal server >> > layer in the transport core). If peer layer interworking ever becomes >> > a necessity, then obviously we'll need a well-defined E-NNI which >> > would include LSP identifier mapping/translation at the boundary, for >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such >> > an E-NNI definition does not yet exist for MPLS-TP (something else to >> > put on the to-do list). This E-NNI would also include similar >> > identifier mapping/translation for MS-PWs, to answer an earlier >> > question from Erminio that I saw on the list. >> > >> > I also agree that both intra-layer and inter-layer mis-connectivity >> > detection and amelioration are required, but I'm not convinced that >> > the already defined mechanisms can't do that. Do you have some >> > specific analysis on the inter-layer case? >> > >> > Cheers, >> > Andy >> > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: >> >> Hi Andy, >> >> >> >> 2 points: >> >> >> >> 1 I agree with your view of only having a single addressing scheme in a >> >> single layer network solely belonging to one party. Though you may >> need to >> >> be rather careful if you also advocate that one can also have peer layer >> >> interworking between different parties, ie E-NNIs (I believe this is >> >> something you may support, eg old MPLSF case?). In such a peer >> interworking >> >> case it would seem one must allow different addressing schemes (and >> indeed >> >> any other variations in DP/CP functional components) if they exist >> in the >> >> standards. >> >> >> >> Of course, having an E-NNI and peer interworking between different >> parties in >> >> any non-TOS layer network (not just MPLS) is not technically >> necessary (this >> >> is trivial to prove), and this provides a strong argument for only >> having a >> >> single addressing scheme in a non-TOS layer network. >> >> >> >> >> >> 2 You should also be aware that in client/server interworking of the >> >> co-ps mode using variable size traffic units, and therefore >> something rather >> >> important for MPLS-TP in the role of a transport network (I'll >> ignore issues >> >> of transparency here), there could be inter-layer misconnectivity >> (Aside=> >> >> This case cannot occur in the co-cs mode). To date, however, we have >> only >> >> really considered intra-layer misconnectivity, ie between different LSPs >> >> belonging to the same party (note this also includes all cases of >> nested LSP >> >> sublayer misconnectivity). >> >> >> >> In the case of inter-layer misconnectivity one may receive traffic >> units and >> >> OAM messages from some other party's layer network. The OAM messages may >> >> come from (i) networks using different OAM/addressing solutions or (ii) >> >> networks using the same OAM/addressing solutions. In both cases >> there are >> >> different issues wrt inter-layer misconnectivity one has to deal >> with. I'm >> >> not aware that these cases have been considered yet. >> >> >> >> >> >> I'd like to hear your comments on both these points, but in >> particular the >> >> first one.....especially if you also support the notion of E-NNIs in >> MPLS-TP, >> >> as there seems to a possible logical conflict here. >> >> >> >> Thanks. >> >> >> >> regards, 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. >> >> British Telecommunications plc >> >> Registered office: 81 Newgate Street London EC1A 7AJ >> >> Registered in England no: 1800000 >> >> >> >>> -----Original Message----- >> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> >>> Andrew G. Malis >> >>> Sent: 02 May 2011 20:48 >> >>> To: George Swallow >> >>> Cc: mpls@ietf.org >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >>> >> >>> George et al, >> >>> >> >>> Verizon does not have any requirement for mixed use of Global IDs and >> >>> ICCs. We are fine with specifications that require both ends of an LSP >> >>> to use one or the other. >> >>> >> >>> Thanks, >> >>> Andy >> >>> >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >> >>> wrote: >> >>>> 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. >> >>>> >> >>>> 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. >> >>>> >> >>>> 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 >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >-- > > >Loa Andersson email: loa.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 erminio.ottone_69@libero.it Wed May 18 14:25:45 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 7B958E077B; Wed, 18 May 2011 14:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=0.300, 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 9qxqfbbiO2SP; Wed, 18 May 2011 14:25:44 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 203BBE0748; Wed, 18 May 2011 14:25:43 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0203.4DD436F7.0127,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D5002F8CDA; Wed, 18 May 2011 23:15:35 +0200 Message-ID: <22644314.1479001305753335606.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 23:15:35 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.51.154.59 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: [mpls] R: RE: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:25:45 -0000 See in line >----Messaggio originale---- >Da: jdrake@juniper.net >Data: 4-mag-2011 2.48 >A: "erminio.ottone_69@libero.it", "Malcolm. BETTS@zte.com.cn" >Cc: "mpls@ietf.org", "mpls-bounces@ietf.org" >Ogg: RE: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Comments inline. > >Sent from my iPhone > > >> -----Original Message----- >> From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] >> Sent: Monday, May 02, 2011 3:13 PM >> To: John E Drake; Malcolm.BETTS@zte.com.cn >> Cc: mpls@ietf.org; mpls-bounces@ietf.org >> Subject: R: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP >> Identifiers? >>=20 >> If my name is XYZ and your name is 123, I do want to change my name in >> order to >> talk to you. >>=20 >> How can a requirement RFC require the interconnection between IP-based >> and ICC- >> based identifiers before these identifiers are defined? > >JD: By saying something like "If multiple types of identifiers are define= d,=20 the endpoints of a given LSP or pseudowire MUST be able to use different=20 identifier types"? > Well, if you force one of the two domains to adapt the identifier type of t= he=20 other domain, the endpoints of a given LSP or MS-PW MUST be able to use=20 different identifier types. Reading RFC5680 I see that it is requried to=20 support multi-domain OAM and to support both IP and ICC based identifiers. There are no furhter requirements about how this can be achieved. As far as= I=20 can see both your proposal as well as ITU-T proposal are "late breaking=20 requirements" wrt RFC5860. >>=20 >> I can see requirements for supporting different identifiers schemes and >> requirements to support multi-domain interconnection. I do not see any >> requirement that limit inter-domain interconnection only between >> domains that >> have the same identifiers scheme. > >JD: I didn't say that. What I said was: > >"JD: The endpoints have to agree on a common format for the data plane." > Sorry I must have been confused by other objecting against the requirement = to=20 support inter-domain LSP/PW between IP-based and ICC-based domains. So, I understand you agree that this is required but you do not agree with = the=20 solution proposed by ITU-T and you would prefer to force the two endpoints = to=20 use the same identifier scheme. The problem I see with your proposed solution is that this will force one o= f=20 the two operators to support two identifier schemes: one for intra-domain= =20 LSP/PW and inter-domain LSP/PW that use its own identifier scheme and one f= or=20 the inter-domain LSP/PW that use a second identifier scheme. I am expecting that the early deployments of MPLS-TP will be private=20 supporting only intra-domain LSP/PW so the operator most likely will=20 instantiate just its own identification scheme. The day the first inter-dom= ain=20 LSP/PW is needed, the operator is required to put in place a second/paralle= l=20 identification scheme (and mapping). I do not think this approach goes in t= he=20 direction to simplify operations nor of enabling global connectivity. >This is a very different statement, and seems eminently reasonable to me. > >>=20 >> Have I missed some requirement? >>=20 >> ----Messaggio originale---- >> Da: jdrake@juniper.net >> Data: 28-apr-2011 18.22 >> A: "Malcolm.BETTS@zte.com.cn" >> Cc: "mpls@ietf.org", "mpls-bounces@ietf.org"> bounces@ietf. >> org> >> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >> Comments inline. >>=20 >> Sent from my iPhone >>=20 >> 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? >>=20 >>=20 >> John, >>=20 >> 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=E2=80=99 >> s the whole point of the discussion. >> 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! >> 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 >> 5150. >>=20 >> 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. >> JD: If it is not in the MPLS-TP requirements RFCs, it is by definition >> a late >> breaking requirement. >>=20 >> Regards, >>=20 >> Malcolm >>=20 >>=20 >>=20 >> 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? >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> I interpreted Eric=E2=80=99s use of =E2=80=98stitching=E2=80=99 to be = in the RFC 5150 sense. >> I >> think I will let him clarify, but if used in the RFC 5150 sense, a >> =E2=80=98stitched=E2=80=99 >> LSP would have end-to-end OAM, and different pieces could use 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] >> 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 >> John E Drake >> 27/04/2011 06:53 PM >>=20 >> To >> "Malcolm.BETTS@zte.com.cn" , Eric Gray > gray@ericsson.com> >> cc >> "mpls@ietf.org" , "mpls-bounces@ietf.org" > bounces@ietf. >> org> >> Subject >> RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=20 >> That=E2=80=99s incorrect. There is a single end-to-end LSP composed of >> different >> pieces, each under the control of a different administrative entity. >>=20 >> Thanks, >>=20 >> John >>=20 >> Sent from my iPhone >>=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 >> Eric Gray >> Sent by: mpls-bounces@ietf.org >> 27/04/2011 12:11 PM >>=20 >>=20 >> To >> George Swallow , "mpls@ietf.org" >> cc >> Subject >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=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? >>=20 >> 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 >> 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. >>=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 >>=20 >>=20 > > From stbryant@cisco.com Wed May 18 14:47: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 DB4D1E0794 for ; Wed, 18 May 2011 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.117 X-Spam-Level: X-Spam-Status: No, score=-110.117 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 Ykr6n+DIDHrH for ; Wed, 18 May 2011 14:47:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF0E0787 for ; Wed, 18 May 2011 14:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1377; q=dns/txt; s=iport; t=1305755242; x=1306964842; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DzjT6w5F487EFrrsMU3RLozjopbvcly7LWXGy2sy5rU=; b=ifg4TEWD57hJk/ntxWF3A1cMCWFI+f1nuGUCP0Xk8D8EdSDUrhboW8JJ rF6EidU/zsqjj/5xwwYEAhq1Bl+3QN1+5a6FbohCLbDbDly0ohGmCWxdA 7g99mZT4VVPKuuBA0RR4YY7ZeRHaC/xKopZpUiatiZYO3CeRUGbBr/93E Q=; X-IronPort-AV: E=Sophos;i="4.65,233,1304294400"; d="scan'208";a="89319824" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 21:47:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4ILlLKP023438; Wed, 18 May 2011 21:47:21 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4ILlEU28144; Wed, 18 May 2011 22:47:14 +0100 (BST) Message-ID: <4DD3DE21.6020309@cisco.com> Date: Wed, 18 May 2011 15:56:33 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Greg Mirsky References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] Possible future use of IEEE 1588v2 tiemstamp format in LM/DM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:47:23 -0000 On 18/05/2011 02:07, Greg Mirsky wrote: > Dear Dan and Stewart, > probably it was already discussed and I apologize upfront for not > finding right thread in archive. > My question is to possible future use of IEEE1588 v2 timestamp format > which uses 48 bits for second counter and, as in PTPv1, 32 bit for > nanosend counter. Could the last paragraph of Appendix A that refers > to truncated format of IEEE1588 PTP be applied to PTP v2 case? How > then interpret Timestamp Type? As 'IEEE1588 version 1 Timestamp' or > 'IEEE1588 Timestamp'? If former, as in the current document, then how > IEEE1588 v2 format will be different from v1 if timestamps must fit > into 64 bits? Or Timestamp Type in this case used only to negotiate > the source of a timestamp? > > Regards, > Greg Greg The reference [ieee1588] is to IEEE 1588-2008 which is often known as IEEE-1588v2. However I think that section 3.4 point 3 needs to be changed to say: "IEEE 1588-2008 Precision Time Protocol timestamp format [IEEE1588] truncated to use only the lower 32 bits of the seconds field. This format consists of a 32-bit seconds field followed by a 32-bit nanoseconds field and is identical to the IEEE 1588-2002 timestamp format." I cannot imagine of any OAM application that would have difficulty coping with the 136 year rollover. - Stewart From erminio.ottone_69@libero.it Wed May 18 14:52:21 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 9BF2BE0794 for ; Wed, 18 May 2011 14:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 krx9d3FTe9xh for ; Wed, 18 May 2011 14:52:20 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id BF447E078D for ; Wed, 18 May 2011 14:52:18 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4DD43F91.0035,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23D7C002F2EB6; Wed, 18 May 2011 23:52:16 +0200 Message-ID: <11819553.1490821305755536596.JavaMail.defaultUser@defaultHost> Date: Wed, 18 May 2011 23:52:16 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.45.141.32 Subject: [mpls] R: FW: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:52:21 -0000 It seems another quite important scenario is missing, quoting from section 1.1 of RFC5921: 1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies. In this case transport operators are adding MPLS-TP capabilities on top of their huge installed based to support emerging packet-based transport services. They wish to protect the investment on existing transport network and operations stuff by operating MPLS-TP in a similar manner of the other transport technology they are still operating (and will continue to operate). >----Messaggio originale---- >Da: eric.gray@ericsson.com >Data: 9-mag-2011 20.03 >A: "mpls@ietf.org" >Ogg: [mpls] FW: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Forwarding in plain text... > >________________________________ > >From: Eric Gray >Sent: Monday, May 02, 2011 11:56 AM >To: 'Manuel.Paul@telekom.de'; Malcolm.BETTS@zte.com.cn; swallow@cisco.com >Cc: mpls@ietf.org >Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > >Manuel, > > There's at least two polar models for new equipment deployment in this case: > >1) folks who have both IP/MPLS equipment and transport service equipment who > view their existing deployment as consisting mostly of IP/MPLS and are looking > to buy new equipment (or add features to existing equipment) to allow them to > phase out aging transport equipment in favor of an all IP/MPLS network. >2) folks who have a network that they view as being dominated by transport and who > want to buy IP equipment to (gradually?) replace this equipment and increase the > compatibility of their network with what they see as a growing demand for IP and > MPLS. > >It's tempting to add a third deployment model for the folks who have acquired pre- >standard equipment and want all standards to be compatible with this equipment. >However, we've been assured that there will not be an interworking requirement to >support deployment of standards-based equipment and pre-standard deployment >- so this case seems to be irrelevant. > > In the first deployment model, we replace the transport equipment and move >transport applications over to MPLS-TP. Since transport equipment is being end- >of-lifed in any case, the capital investment we want to protect is the existing IP and >MPLS deployment. > > In the second deployment model, we seem to want to protect the existing network >throughout the transformation process, by front-loading additional functionality into the >new equipment to be installed. While this facilitates the first phase of transformation, >it does so by adding features and capabilities that we can be pretty sure we will not >need after the transformation is complete. > > While I refer to these two scenarios as separate, they are in fact the result of >network operators at different points in a transformation from packet based services >provided by a predominantly transport network to a predominantly packet network >that provides support for a small minority of applications that require transport-like >services. > > Clearly the further a network operator is along in the process, the more reluctant >they will be to find additional complexity in new capital investment that is important >only for a diminishingly small part of their network and will be obsolete in fairly short >order. > > Please see additional comments below... > >-- >Eric >________________________________ > >From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] >Sent: Monday, May 02, 2011 9:46 AM >To: Eric Gray; Malcolm.BETTS@zte.com.cn; swallow@cisco.com >Cc: mpls@ietf.org >Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >Importance: High > >Dear All, > >Please see some comments inline marked with [MP]. > >Thanks, > >Manuel > >________________________________ > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Gray >Sent: Thursday, April 28, 2011 10:58 PM >To: Malcolm.BETTS@zte.com.cn; George Swallow >Cc: mpls@ietf.org >Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >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. > >[MP:] Agree that this should be equally applicable to all sides of the story, although backwards compatibility considerations (often stressed along the MPLS OAM extension debate) apply here too. Its among TP's primary targets to fit for classicly operated transport networks, to save efforts and avoid disruptive (primarily operational) changes in this arena. Platforms aren't migrated with one single snip of the finger (sometimes more for operational rather than technical complexity). In a real world, may need to interconnect platforms in distinct phases of evolution. In case of need for handovers, an operator should have the flexibility to decide what device class is easiest to be (evolutionary) touched and tuned, i.e. supporting mixed identifiers. I admit this occurrence probably will not be as granular as the general requirement for End-to-End OAM interoperability in a multi-vendor transport network environment where the boundaries are drawn according to the reach of optica > l transparency domains and/or network management feasibilities. > > 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. > >[MP:] Is it really that difficult to handle when we focus on the data plane perspective for now? As in current scope of the identifiers draft? > >EG> Focus on the data plane is an one way to look at this. Unfortunately > it does not help us much since we have to figure out how this stuff is > supposed to get into the data plane, and how a maintenance entity > is supposed to be configured to recognize it once it arrives from the > data-plane. > > Simply looking at this as data-plane "stuff" would quickly get us in > trouble with our colleagues that have to handle the related needs to > get it there and recover it once it has arrived. > > 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. > >[MP:] Wouldn't it be sufficient to recognize either format to know what semantics do apply ( or do not apply ) to handle one, or the other, or boths formats properly on a node? > >EG> It would be sufficient, but non-trivial to specify in a standard. It is > also not particularly trivial to implement. > >[MP:] What happens today when a node receives any format that it doesn't support? > Would it result in a confusion / wrong comparison? > >EG> I don't think specifying that an unsupported format will be discarded > (perhaps with an error report) - which is the way that unsupported > objects and formats are dealt with generally (as long as it's possible > to detect this) - is what we want to do. > >IMHO solving inter-provider interface issues or automization in assignement may be tackled subsequently, i.e. in a next step. > > 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 Malcolm.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 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. > >Are suggesting that the same operator might make different choices in different >parts of the same network? > >[MP:] Looking at the reality where platforms aren't migrated with one single snip of the finger (sometimes for operational rather than technical reasons), it may indeed be of practical relevance. Want to say, even an intra-operator but inter-AS scenario may be thinkable. > >EG> In the inter-AS case generally, the best form of identifier is a Global > Identifier, simply because - by definition - you have a different AS for > the two (or more) portions of the network. > >This seems very unlikely, except possibly in the case where one operator who >uses one format identifier is acquired by another operator who uses the other. > >In any case, if the decision to use a particular identifier is made consistently >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, including having independent identifiers. The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers. > >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 that is not >necessarily consistent with their choice of signaling or configuration. > >It is exceedingly unlikely that operators that use existing (G)MPLS signaling 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 they are free >to do so as far as I can tell. > >It is (probably?) much more likely that operators that use configuration will 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 point it out. > >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. > >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 comparison >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-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 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed May 18 15:14: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 71466E0760 for ; Wed, 18 May 2011 15:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 vijr6OMUgWzh for ; Wed, 18 May 2011 15:14:14 -0700 (PDT) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2A068E06D3 for ; Wed, 18 May 2011 15:14:13 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020B.4DD444B4.00E4,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail43 (172.31.0.232) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD2374C002C394E; Thu, 19 May 2011 00:14:12 +0200 Message-ID: <7300779.1495401305756852476.JavaMail.defaultUser@defaultHost> Date: Thu, 19 May 2011 00:14:12 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.45.141.32 Subject: [mpls] R: I: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 22:14:15 -0000 I did not see any reply to the questions below. Following the discussions on this draft it appears clear that: a) it is not possible to impose both operators to use the same identifier structure to setup an inter-domain LSP/PW so without mixing ICC and IP identifiers it is not possible to define a path identifer for these entities (that can and will exist in the network) b) quoting George Swallow mail on a separate comment, "In an IP/MPLS environment, provisioning MIPs is pretty much a non-starter. Generally intermediate nodes respond to all requests (e.g. Ping, MPLS Ping) unless configured to filter on things such a source address." The problem is that if the MIP identifier is assigned according to the identification scheme adopted by the node the MIP resides on. As there is no provisioning, there is no way to ensure the MIP identification would follow the same scheme as the MEP. Bottom line: not allowing mixing different identification schemes is creating more technical issues that it is apparently solving (I think no problem is actually solved). >----Messaggio originale---- >Da: erminio.ottone_69@libero.it >Data: 2-mag-2011 23.54 >A: >Ogg: [mpls] I: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Forwarding the messate to the MPLS WG mailing list ... > >----Messaggio originale---- >Da: erminio.ottone_69@libero.it >Data: 2-mag-2011 23.41 >A: >Ogg: R: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >1) what about the operational burden to manage two different identifiers for >the same entities within the same operator's domain? > >2) This argument is not fully clear. > >Let's check the different identifiers that are defined and see if there is any >additional implementation complexity: > >-> Path identifiers: they are not carried by any protocol istance so what is >the testing burden? > >-> MEP identifier: each system should be able to generate its own format of >MEP-ID and to receive any format of MEP-ID that is defined today and will be >defined in the future because you cannot predict/avoid misconnections between >MEPs using different identification schemes. > >I would suggest to take a look at the following draft to understand todays >best-in-class solution for supporting an extensible and future proof solution >allowing different types of MEP identification schemes: > >http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-06 > >The secret spice is to do a bit-by-bit comparision between the expected MEP- ID >and the received MEP-ID and to define a typed encoding for the MEP >identifiers. > >Please note that section 2.1.4 of RFC 5860 requires that the solution must be >"extensible to support additional identification schemes". > >-> MIP identifier: the traceroute should discover the MIP-ID at a given TTL >distance and use that identifier for connectivity verification toward that MIP. >How can you impose all the MIPs to have the same structure? > >3) I understood the objective of the work was to allow inter-domain/inter- >provider MPLS-TP deployment with e2e OAM support. When this objective has been >changed? > >4) Control plane identifiers are separated from data plane and OAM identifier >so I think this argument is outside the scope of the draft. > > >----Messaggio originale---- >Da: swallow@cisco.com >Data: 25-apr-2011 23.16 >A: >Ogg: [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. > >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. > >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 > From gregimirsky@gmail.com Wed May 18 15:14:19 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 0BBA7E079B for ; Wed, 18 May 2011 15:14:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi5el4lIRw5C for ; Wed, 18 May 2011 15:14:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E87CEE0796 for ; Wed, 18 May 2011 15:14:17 -0700 (PDT) Received: by vws12 with SMTP id 12so1779618vws.31 for ; Wed, 18 May 2011 15:14: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=Q1rWVh7Ud40v80K/5oUyhYQ52dW7DiOogMtpQ3PLW34=; b=quBapRI/nn3fsaUrt/u/zYiB2YMROYhXkKRvJKaVxi8nx/V+9QyOhxr3ACNXUPjkMw UOyaPQ86MkSTYm1SzTIvzNOx8Qgvf0JZSoaj1Jnxx9DwfvPT41qA5kyq5wREkXdNzO8A IJjDDhe1cGWSvTWacx6QuAfv/uPkKnmXgzd5o= 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=oyjLcg+NYZ6YOdTtq1MBM9ZWGj28DqsojI2UmwlYlfC3vaYCVu60mJBUan4P6Pd8zW vhK3PP+4JxhM2wW3kox3wMAI/+nA8Ep40EynYcgtffyqG800AOHcS0GmdhMWQkQZgj2P Jg+CHIvf5bL6FLtJZP0eh2KlMXi8pun3GkLU4= MIME-Version: 1.0 Received: by 10.52.100.7 with SMTP id eu7mr3429833vdb.296.1305756857436; Wed, 18 May 2011 15:14:17 -0700 (PDT) Received: by 10.52.156.228 with HTTP; Wed, 18 May 2011 15:14:17 -0700 (PDT) In-Reply-To: <4DD3DE21.6020309@cisco.com> References: <4DD3DE21.6020309@cisco.com> Date: Wed, 18 May 2011 15:14:17 -0700 Message-ID: From: Greg Mirsky To: stbryant@cisco.com Content-Type: multipart/alternative; boundary=bcaec501618fa6892704a39435bb Cc: mpls@ietf.org Subject: Re: [mpls] Possible future use of IEEE 1588v2 tiemstamp format in LM/DM 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, 18 May 2011 22:14:19 -0000 --bcaec501618fa6892704a39435bb Content-Type: text/plain; charset=ISO-8859-1 Dear Stewart, thank you for such quick response to my question. I agree that proposed update addresses my concern. Perhaps you'll agree to update Timestamp Type in section 8.2 to 'IEEE 1588 Timestamp' to remove explicit reference to 'version 1'. Regards, Greg On Wed, May 18, 2011 at 7:56 AM, Stewart Bryant wrote: > On 18/05/2011 02:07, Greg Mirsky wrote: > >> Dear Dan and Stewart, >> probably it was already discussed and I apologize upfront for not finding >> right thread in archive. >> My question is to possible future use of IEEE1588 v2 timestamp format >> which uses 48 bits for second counter and, as in PTPv1, 32 bit for nanosend >> counter. Could the last paragraph of Appendix A that refers to truncated >> format of IEEE1588 PTP be applied to PTP v2 case? How then interpret >> Timestamp Type? As 'IEEE1588 version 1 Timestamp' or 'IEEE1588 Timestamp'? >> If former, as in the current document, then how IEEE1588 v2 format will be >> different from v1 if timestamps must fit into 64 bits? Or Timestamp Type in >> this case used only to negotiate the source of a timestamp? >> >> Regards, >> Greg >> > Greg > > The reference [ieee1588] is to IEEE 1588-2008 which is often known as > IEEE-1588v2. > > However I think that section 3.4 point 3 needs to be changed to say: > > "IEEE 1588-2008 Precision Time Protocol timestamp format [IEEE1588] > truncated to > use only the lower 32 bits of the seconds field. This format consists of > a 32-bit > seconds field followed by a 32-bit nanoseconds field and is identical to > the > IEEE 1588-2002 timestamp format." > > I cannot imagine of any OAM application that would have difficulty coping > with the > 136 year rollover. > > - Stewart > > > > > > > --bcaec501618fa6892704a39435bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Stewart,
thank you for such quick response to my question.
I agr= ee that proposed update addresses my concern. Perhaps you'll agree to u= pdate Timestamp Type in section 8.2 to 'IEEE 1588 Timestamp' to rem= ove explicit reference to 'version 1'.

Regards,
Greg


--bcaec501618fa6892704a39435bb-- From stbryant@cisco.com Wed May 18 15:19: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 5FDC6E0790 for ; Wed, 18 May 2011 15:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.595 X-Spam-Level: X-Spam-Status: No, score=-110.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fe+0k3s8DiZO for ; Wed, 18 May 2011 15:19:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 08DEAE0760 for ; Wed, 18 May 2011 15:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=6645; q=dns/txt; s=iport; t=1305757189; x=1306966789; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=FcOV42PrkJYGgLRl1bYYAp510kwi8Tx0BGkZu1OvwrQ=; b=eIQaPLKBpQomRGUzxBl84Ztisb2nanXYIAoD5ou11hcYoLJnbBrltXl8 Xr56EVuMn8ga4vtBpMPj1H0JQvhQAdu0capbWJvbgZU3JGQVzt+YyBDOu PfkuS9H7gvoF9AyzQQW3bOMp4C3l1c/eHgyaVkZS87sAdJbBkXoO+0tac c=; X-IronPort-AV: E=Sophos;i="4.65,233,1304294400"; d="scan'208,217";a="30992544" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 May 2011 22:19:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4IMJhBw002086; Wed, 18 May 2011 22:19:43 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4IMJeU00070; Wed, 18 May 2011 23:19:40 +0100 (BST) Message-ID: <4DD445FB.6080602@cisco.com> Date: Wed, 18 May 2011 23:19:39 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Greg Mirsky References: <4DD3DE21.6020309@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060202030400060309040002" Cc: mpls@ietf.org Subject: Re: [mpls] Possible future use of IEEE 1588v2 tiemstamp format in LM/DM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 22:19:50 -0000 This is a multi-part message in MIME format. --------------060202030400060309040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Greg Yes, we will make it all consistent. Thanks for picking this up. Stewart On 18/05/2011 23:14, Greg Mirsky wrote: > Dear Stewart, > thank you for such quick response to my question. > I agree that proposed update addresses my concern. Perhaps you'll > agree to update Timestamp Type in section 8.2 to 'IEEE 1588 Timestamp' > to remove explicit reference to 'version 1'. > > Regards, > Greg > > On Wed, May 18, 2011 at 7:56 AM, Stewart Bryant > wrote: > > On 18/05/2011 02:07, Greg Mirsky wrote: > > Dear Dan and Stewart, > probably it was already discussed and I apologize upfront for > not finding right thread in archive. > My question is to possible future use of IEEE1588 v2 timestamp > format which uses 48 bits for second counter and, as in PTPv1, > 32 bit for nanosend counter. Could the last paragraph of > Appendix A that refers to truncated format of IEEE1588 PTP be > applied to PTP v2 case? How then interpret Timestamp Type? As > 'IEEE1588 version 1 Timestamp' or 'IEEE1588 Timestamp'? If > former, as in the current document, then how IEEE1588 v2 > format will be different from v1 if timestamps must fit into > 64 bits? Or Timestamp Type in this case used only to negotiate > the source of a timestamp? > > Regards, > Greg > > Greg > > The reference [ieee1588] is to IEEE 1588-2008 which is often known > as IEEE-1588v2. > > However I think that section 3.4 point 3 needs to be changed to say: > > "IEEE 1588-2008 Precision Time Protocol timestamp format > [IEEE1588] truncated to > use only the lower 32 bits of the seconds field. This format > consists of a 32-bit > seconds field followed by a 32-bit nanoseconds field and is > identical to the > IEEE 1588-2002 timestamp format." > > I cannot imagine of any OAM application that would have difficulty > coping with the > 136 year rollover. > > - Stewart > > > > > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------060202030400060309040002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Greg

Yes, we will make it all consistent.

Thanks for picking this up.

Stewart

On 18/05/2011 23:14, Greg Mirsky wrote:
Dear Stewart,
thank you for such quick response to my question.
I agree that proposed update addresses my concern. Perhaps you'll agree to update Timestamp Type in section 8.2 to 'IEEE 1588 Timestamp' to remove explicit reference to 'version 1'.

Regards,
Greg

On Wed, May 18, 2011 at 7:56 AM, Stewart Bryant <stbryant@cisco.com> wrote:
On 18/05/2011 02:07, Greg Mirsky wrote:
Dear Dan and Stewart,
probably it was already discussed and I apologize upfront for not finding right thread in archive.
My question is to possible future use of IEEE1588 v2 timestamp format which uses 48 bits for second counter and, as in PTPv1, 32 bit for nanosend counter. Could the last paragraph of Appendix A that refers to truncated format of IEEE1588 PTP be applied to PTP v2 case? How then interpret Timestamp Type? As 'IEEE1588 version 1 Timestamp' or 'IEEE1588 Timestamp'? If former, as in the current document, then how IEEE1588 v2 format will be different from v1 if timestamps must fit into 64 bits? Or Timestamp Type in this case used only to negotiate the source of a timestamp?

Regards,
Greg
Greg

The reference [ieee1588] is to IEEE 1588-2008 which is often known as IEEE-1588v2.

However I think that section 3.4 point 3 needs to be changed to say:

"IEEE 1588-2008 Precision Time Protocol timestamp format [IEEE1588] truncated to
use only the lower 32 bits of the seconds field.  This format  consists of a 32-bit
seconds field followed by a 32-bit nanoseconds field and is identical to the
IEEE 1588-2002 timestamp format."

I cannot imagine of any OAM application that would have difficulty coping with the
136 year rollover.

- Stewart









-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------060202030400060309040002-- From manavbhatia@gmail.com Wed May 18 16:35: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 B4DA3E0794 for ; Wed, 18 May 2011 16:35:34 -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 2pJfq5-KP3kO for ; Wed, 18 May 2011 16:35:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD149E06F3 for ; Wed, 18 May 2011 16:35:33 -0700 (PDT) Received: by vxg33 with SMTP id 33so1799664vxg.31 for ; Wed, 18 May 2011 16:35:33 -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:content-transfer-encoding; bh=7TBHXyE1TAXoQWr6g9bT5DziK+HCIGbmHsg/3gGsF54=; b=QDagL5NMTcIosqyVFYt5fxVKUC2QKEgZxt3BCxOn/R835ll9OI+VFYVjrSGq2wItIy BsyEOs6hj2rUwpSBghQk0yIR/YdEzk3kZZc6nSKq6E7Pb1oj4ctGMdBr2+U8dqw9kylz yJeRAWEajFY9hX94rPIFo/UEEbrbfCRCYkPdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Qf7hvtDN6XdujRcoWka+12Cxkelxi14hdaa4d41xZrilGWt7FL6+eNVhRIxfPBrHrR XXn6inFSrDyMngb6zqas+a+wKYvESBuImBV3WMPkYUNmFHo1CfuxTohyUJVZB5ViSMvb hxjmMdoQpR61LT7gfuM/RRKVLLq962d8YRx1Q= MIME-Version: 1.0 Received: by 10.52.182.6 with SMTP id ea6mr3088138vdc.217.1305761732658; Wed, 18 May 2011 16:35:32 -0700 (PDT) Received: by 10.52.109.41 with HTTP; Wed, 18 May 2011 16:35:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 05:05:32 +0530 Message-ID: From: Manav Bhatia To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 18 May 2011 23:35:34 -0000 Hi, We have posted the revised version that addresses the comments that we had received on the list. http://www.ietf.org/id/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-01.txt Cheers, Manav On Fri, Apr 15, 2011 at 10:33 PM, Manav Bhatia wrot= e: > 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. =A0This cannot be > achieved with regular MPLS as the LSPs are unidirectional. =A0If > symmetry is required, a separate LSP in each direction is required for > bidirectional traffic flow. =A0Generalized MPLS on the other hand, has > provisions for setting up a bidirectional LSP. =A0This document uses the > extensions introduced for GMPLS and applies it to regular MPLS for > establishing bidirectional LSPs. =A0Additionally, 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 gregimirsky@gmail.com Wed May 18 22:40: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 3789AE0708; Wed, 18 May 2011 22:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7yRodL0kfpS; Wed, 18 May 2011 22:40:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB6E0701; Wed, 18 May 2011 22:40:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so1963063vxg.31 for ; Wed, 18 May 2011 22:40:23 -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=pM/UPV3dB//p2TU/17vPfzFdah2t0P3YkjqdTvk5a4c=; b=g76wDNi+w8viXXKLLz4GVYepe00uDMT+H3fpRBqRFzFJBo1r6XHke21InW8rVhKeMX d2NkIS3Lv4XeOGgJG+yUWY9UgwYsoPcBxYV/e9Zg1ivKvhkAGsA9ZSpY/UTpjfpBe2y9 DigwKLveVfi8GYpZTFyrp6DlmsO81tpgpeRt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HJ795g4BJ/IaJovxA6K49yKqVmBmPUV9j6/fWwLpFOoiqdze2f6z3FL2ccGzMC/zG2 7HUuQfzV6NJM2NJ+TL/KgpO3or3MVDDEFsTVP5rNctnqM0UH7Aay9LTni/GWmS4Ijvqx bM7/oC+Iq5Mc+8H24IA+h9kNBE3pG7h8aKhvw= MIME-Version: 1.0 Received: by 10.52.176.164 with SMTP id cj4mr3910815vdc.56.1305783623870; Wed, 18 May 2011 22:40:23 -0700 (PDT) Received: by 10.52.156.228 with HTTP; Wed, 18 May 2011 22:40:23 -0700 (PDT) Date: Wed, 18 May 2011 22:40:23 -0700 Message-ID: From: Greg Mirsky To: "Siva Sivabalan(msiva)" , Sami Boutros , Luca Martini , pwe3 , mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec5015d030dea6204a39a7100 Subject: [mpls] Question on draft-boutros-pwe3-mpls-tp-ms-pw-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 05:40:25 -0000 --bcaec5015d030dea6204a39a7100 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, I have a question on Section 3.1.2.1 when Lock (LI) is sent to S-PE. According to draft-ietf-mpls-tp-li-lb-01 Lock operates only on MEP, i.e. it originated by MEP and addressed to MEP. In scenario considered in 3.1.2.1 LI addressed and processed by S-PE which is a MIP, not MEP. I believe that if Loopback to be performed on MS-PW the LI request must be send to remote T-PE. LB then might be set on S-PE or remote T-PE if LI was successful. And I think that referring to nodes as T-PE and S-PE when LI-LB performed on MPLS-TP LSP is confusing. To address PE a PW label must be present which is not the case if scope of LI-LB is the LSP. Regards, Greg --bcaec5015d030dea6204a39a7100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
I have a question on Section 3.1.2.1 when Lock (LI) is sen= t to S-PE. According to draft-ietf-mpls-tp-li-lb-01 Lock operates only on M= EP, i.e. it originated by MEP and addressed to MEP. In scenario considered = in 3.1.2.1 LI addressed and processed by S-PE which is a MIP, not MEP. I be= lieve that if Loopback to be performed on MS-PW the LI request must be send= to remote T-PE. LB then might be set on S-PE or remote T-PE if LI was succ= essful.
And I think that referring to nodes as T-PE and S-PE when LI-LB performed o= n MPLS-TP LSP is confusing. To address PE a PW label must be present which = is not the case if scope of LI-LB is the LSP.

Regards,
Greg

--bcaec5015d030dea6204a39a7100-- From loa@pi.nu Wed May 18 23:09: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 C3DE1E06F6 for ; Wed, 18 May 2011 23:09:11 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=0.6, 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 bVzTxeB9cBoY for ; Wed, 18 May 2011 23:09:11 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id BA501E06D1 for ; Wed, 18 May 2011 23:09:08 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 C8ED82A8001; Thu, 19 May 2011 08:09:05 +0200 (CEST) Message-ID: <4DD4B401.4090501@pi.nu> Date: Thu, 19 May 2011 08:09:05 +0200 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: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" References: <201105130203.p4D23KEd065500@mse02.zte.com.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ross Callon , draft-ietf-mpls-tp-li-lb@tools.ietf.org, Sami Boutros , mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 06:09:11 -0000 Yacoov, indeed, isn't this one of the reason you'd actuall would like to put an LSP or PW in loopback? /Loa On 2011-05-17 06:03, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Hi, > > Again I am not sure that I understand the confusion โ€“ if the segment of > the LSP is in loopback mode then it should be easy for the source LER to > detect either of the misconnectivity conditions that you describe โ€“ > > 1. For the case of messages that are lost due to a misconnectivity > between the source LER and the MIP that is looping back โ€“ the messages > that are lost will not be looped-back, which can be detected by the > source LER > > 2. For the case of messages that are leaking into the segment from a > different LSP โ€“ this message will be looped back by the MIP and the > source LER could detect an excessive message in the stream. > > However, as was pointed out in a separate thread โ€“ it is advisable to > only enter loopback on an LSP that there are no suspected misconnectivities! > > Hope this helps, > > yaacov > > *From:*ext liu.guoman@zte.com.cn [mailto:liu.guoman@zte.com.cn] > *Sent:* Friday, May 13, 2011 4:47 AM > *To:* Sami Boutros > *Cc:* draft-ietf-mpls-tp-li-lb@tools.ietf.org; Loa Andersson; > mpls@ietf.org; Ross Callon; Weingarten, Yaacov (NSN - IL/Hod HaSharon) > *Subject:* RE: [mpls] working group last call on > draft-ietf-mpls-tp-li-lb-01.txt > > > sami, yaccov,hi > firstly i say sorry for not clearly describling my question. > for the first question, maybe yaacov's understanding be right. if a mep is > on loopback state, it can't check the e2e path for mis-connectivity because > the mep point loopback everything including any OAM packet(cc&cv etc); > > for the second question, I know loss/delay measurement should use LM/DM > fuction to > implement it. but for loopback function, there are the following two > application: > 1 To verify bidirectional connectivity of a MEP with a MIP or a peer MEP; > 2 To perform a bidirectional in-service or out-of-service diagnostics > test between a pair of peer MEPs. This includes verifying bandwidth > throughput, detecting bit errors, etc; > > so for application 1, loopback anything will not affect verify > bidirectional connectivity; but it may affect diagnostics test. > for example, if mis-connectivity or mis-configuration happened on a LSP > path, since the mep of the lsp is under loopback state, it can't check > mis-connectivity, > so the mep of the lsp maybe loopback other data packet of another lsp to > the peer mep.or the data pkt of the LSP will be leaked to other LSP > path, so it must affect the result of diagnostics test including > bandwidth throughput, bit errors. > > maybe i miss something important? > > thank sami and yaacov for prompt replying it. > > B.R. > Liu > > > > > > > *Sami Boutros * > > 2011-05-13 05:05 > > > > ๆ”ถไปถไบบ > > > > "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" > , , "Loa Andersson" > > > ๆŠ„้€ > > > > "Ross Callon" , , "MPLS-TP ad hoc > team" , > > ไธป้ข˜ > > > > RE: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt > > > > > > > Agreed Yaacov, during the period of loopback the cc-cv function can't be > performed, and yes the main benefit is of loopback is to measure > loss/delay on a segment of a path as you stated. > > Thanks, > > Sami > At 10:36 PM 5/11/2011, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote: > Sami, hi > > My understanding is that the question that was asked is how do you use > the cc-cv function to check for mis-connectivity if it is being looped-back. > > Truth be told that during the period of loopback you apparently cannot > check the e2e path for mis-connectivity, and the operator needs to take > this into consideration. But since the path is not transferring data e2e > (it is looping everything back) it is by definition not connected e2e. > > What is true is what Sami states this functionality should be used to > setup a loss/delay measurement on a segment of a path, and it should be > used only for limited periods. > > Just my 2cents, > yaacov > * > From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *ext Sami Boutros* > Sent:* Thursday, May 12, 2011 8:03 AM* > To:* liu.guoman@zte.com.cn; Loa Andersson* > Cc:* Ross Callon; mpls@ietf.org; MPLS-TP ad hoc team; > draft-ietf-mpls-tp-li-lb@tools.ietf.org* > Subject:* Re: [mpls] working group last call on > draft-ietf-mpls-tp-li-lb-01.txt > > To check for mis-connectivity/mis-configuration, you need a cc-cv > function not a loopback function. > > The loopback function can be used for loss/delay measurements, and this > will be addressed in the delay/loss draft. > > Thanks, > > Sami > At 07:11 PM 5/10/2011, liu.guoman@zte.com.cn wrote: > > > hi, all > for this draft, I have a question for Loopback function. > in last ietf meeting, IMO, the author sami said this > Loopback function is to loopback anything. for MEP point of > a LSP, if it is set to Loopback state, it will loopback all received > packets including any OAM packet. if so, how to detect mis-connectivity or > mis-configuration for the LSP? > in addtion, if it happen mis-connectivity, maybe other LSP packet be > transported to > the MEP , and the mep point will still Loopback the wrong packet to peer > mep point, > can it affectperformance statistics > or measurement on the peer mep point? > > B.R. > liu > > > > > > * > Loa Andersson * > ยทยขยผรพรˆร‹: mpls-bounces@ietf.org > > 2011-05-10 23:43 > > > รŠร•ยผรพรˆร‹ > > > "mpls@ietf.org" > > > ยณยญร‹ร > > > Ross Callon , MPLS-TP ad hoc team > , draft-ietf-mpls-tp-li-lb@tools.ietf.org > > > ร–รทรŒรข > > > [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt > > > > > Working Group, > > this is to start a two week working group last call on > > draft-ietf-mpls-tp-li-lb-01.txt > > Please send your comments to the mpls@ietf.org mailing list. > > This working group last call ends on May 25th. > > /Loa > > for 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org_ > _https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > -------------------------------------------------------- > > > 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. > > > > > -------------------------------------------------------- > > 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. -- 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 malcolm.betts@zte.com.cn Thu May 19 01:36:33 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 2962AE070A; Thu, 19 May 2011 01:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 vM60cbX8SkMC; Thu, 19 May 2011 01:36:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEDE068C; Thu, 19 May 2011 01:36:29 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 18341784411434; Thu, 19 May 2011 16:28:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 88213.1937000543; Thu, 19 May 2011 16:25:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4J8PYo8011001; Thu, 19 May 2011 16:25:34 +0800 (GMT-8) (envelope-from Malcolm.BETTS@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: Malcolm.BETTS@zte.com.cn Date: Thu, 19 May 2011 04:25:11 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-19 16:25:37, Serialize complete at 2011-05-19 16:25:37 Content-Type: multipart/alternative; boundary="=_alternative 002E479485257895_=" X-MAIL: mse02.zte.com.cn p4J8PYo8011001 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, 19 May 2011 08:36:33 -0000 This is a multipart message in MIME format. --=_alternative 002E479485257895_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Ross, I disappointed and, based on my reading of the emails on this thread,=20 surprised that this decision has been taken. Could you please elaborate=20 on the reasoning behind this decision. Regards, Malcolm Ross Callon =20 Sent by: mpls-bounces@ietf.org 18/05/2011 02:40 PM To "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to=20 change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and=20 ICC?s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly=20 rough) consensus is to leave the document as currently defined. The=20 authors are therefore instructed to continue progression of=20 draft-ietf-mpls-tp-identifiers without a change in this area. =20 This decision neither supports nor precludes the possibility that at some=20 point in the future, after draft-ietf-mpls-tp-identifiers is approved and=20 published as an RFC, the WG might consider additional work to extend the=20 MPLS protocols to allow mixed identifiers.=20 =20 Thanks, Ross and Loa (as MPLS WG chairs) =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers,=20 for this one document he is recused from his role as WG co-chair.] =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? =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 a=20 fairly trivial procedure. Many organizations if not most already have AS=20 Numbers.=20 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=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 based=20 on either the Global-ID or ICC. That would be a radical change to how IP=20 works. 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.=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 002E479485257895_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Ross,

I disappointed and, based on my read= ing of the emails on this thread, surprised that this decision has been taken.  Could you please elaborate on the reasoning behind this decision.

Regards,

Malcolm



Ross Callon <rcall= on@juniper.net>
Sent by: mpls-bounces@ietf.org

18/05/2011 02:40 PM

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





After discussion on the= MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifie= rs to allow mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the docum= ent as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifiers without a change in this area.
 
This decision neither s= upports nor precludes the possibility that at some point in the future, after draft= -ietf-mpls-tp-identifiers is approved and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.
 
Thanks,
Ross and Loa (as MPLS WG chairs)
 
[Note that since George= is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG co-chair.]
 
 
From: mpls-bounces@ietf.org [mail= to: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.        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 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=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 002E479485257895_=-- From loa@pi.nu Thu May 19 02:46:21 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 EB0ACE072A for ; Thu, 19 May 2011 02:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 wVXKsgk+tuXE for ; Thu, 19 May 2011 02:46:21 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF9E0727 for ; Thu, 19 May 2011 02:46:20 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 952EE2A8001; Thu, 19 May 2011 11:46:18 +0200 (CEST) Message-ID: <4DD4E6EB.5080107@pi.nu> Date: Thu, 19 May 2011 11:46:19 +0200 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" References: <4DC95D08.7060305@pi.nu> In-Reply-To: <4DC95D08.7060305@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MPLS-TP ad hoc team , draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 09:46:22 -0000 Authors, I've one thought that been nagging me about draft-ietf-mpls-tp-li-lb-01.txt, it is on how the lock instruct tool interwork with other OAM tools, in particular CC adn CV. Consider this case A====B====C====D====E c----b----a------------------------d----e f----g----a------------------------d----h i----j----a------------------------d----k A====B====C====D====E What I tried draw is a three LSPs [c to e, f to h, i to k] that are put into a tunnel at node A, A to E represents the tunnel. Consider the case where we are running CC and/or CV on bout the tunnel If the operator wants to put C in loop back, the first step is that A sends a lock instruct message to E for this LSP. This will immediately result in an alarm from A, and might trigger protection (the draft does not describe, how node A is prepared for locking E). This might be a minor problem since A originates the lock instruct, and we can put A in a "prepared state" but it might at least be mentioned in the draft. More problematic might be that c,f,h,e and k might also alarm, since these node might be widely dispersed it might cause quite some amount of alarms and protection switching. Since we are dealing with OAM tools, I think it is necessary to give some operational heads up in this kind of draft. /Loa On 2011-05-10 17:43, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > > draft-ietf-mpls-tp-li-lb-01.txt > > Please send your comments to the mpls@ietf.org mailing list. > > This working group last call ends on May 25th. > > /Loa > > for 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 eric.gray@ericsson.com Thu May 19 12:08: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 9931BE076B for ; Thu, 19 May 2011 12:08:25 -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 FU0MS1eH41tL for ; Thu, 19 May 2011 12:08:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD50E06BE for ; Thu, 19 May 2011 12:08:23 -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 p4JJ8MCZ015779; Thu, 19 May 2011 14:08:23 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 19 May 2011 15:08:16 -0400 From: Eric Gray To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" , "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" Date: Thu, 19 May 2011 15:08:15 -0400 Thread-Topic: Question for clarification on On-Demand CV draft Thread-Index: AcwVI2qvDwcFq3k6SN+1S1wjMEzVogBNGe5w 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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A4BC8EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] Question for clarification on On-Demand CV draft 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, 19 May 2011 19:08:25 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A4BC8EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaacov, As you know, the last call has closed. However, we are (unfortunately)= still addressing a few comments straggling in. I plan to discuss this particular question with my co-authors before gi= ving a detailed response on the mailing list. Thanks for you vigilence, patience and undurance! -- Eric ________________________________ From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:yaacov.weingarten@= nsn.com] Sent: Wednesday, May 18, 2011 2:19 AM To: mpls@ietf.org; draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Question for clarification on On-Demand CV draft Hi, In reviewing this document and the TP-Identifiers document there seems to b= e a discrepancy between the PW identification format between these two docu= ments. On the one hand - the TP Identifiers documents describes the PW identifier = by the string - "AGI::East-Global_Node_ID::East-AC_ID::West-Global_Node_ID:= :West-AC_ID." While on the other hand - the sub-TLV in section 2.3.2 for a static PW incl= udes fields for both E&W Global Node_ID, and both E&W AC_ID, however does n= ot include a field for the AGI - (Attachment Group Identification) - part o= f the FEC129 definition. Could you please clarify what lies behind this difference? Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A4BC8EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question for clarification on On-Demand CV draft
Yaacov,
 
  &n= bsp; As you know, the last call has closed= . =20 However, we are (unfortunately) still
addressing a few comments straggling=20 in.
 
  &n= bsp; I plan to discuss this particular que= stion with=20 my co-authors before giving a
detailed response on the mailing list.
 
  &n= bsp; Thanks for you vigilence, patience an= d=20 undurance!
--
Eric
From: Weingarten, Yaacov (NSN - IL/Hod = HaSharon)=20 [mailto:yaacov.weingarten@nsn.com]
Sent: Wednesday, May 18, 2011= 2:19=20 AM
To: mpls@ietf.org;=20 draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org
Subject: Question = for=20 clarification on On-Demand CV draft

Hi,

In reviewing th= is document=20 and the TP-Identifiers document there seems to be a=20 discrepancy between the PW identification format between these two=20 documents.

On Wed, May 18, 2011= at 7:56 AM, Stewart Bryant <stbryant@cisco.com> wrote:
On 18/05/2011 02:07, Greg Mirsky wrote:
Dear Dan and Stewart,
probably it was already discussed and I apologize upfront for not finding r= ight thread in archive.
My question is to possible future use of IEEE1588 v2 timestamp format which= uses 48 bits for second counter and, as in PTPv1, 32 bit for nanosend coun= ter. Could the last paragraph of Appendix A that refers to truncated format= of IEEE1588 PTP be applied to PTP v2 case? How then interpret Timestamp Ty= pe? As 'IEEE1588 version 1 Timestamp' or 'IEEE1588 Timestamp= 9;? If former, as in the current document, then how IEEE1588 v2 format will= be different from v1 if timestamps must fit into 64 bits? Or Timestamp Typ= e in this case used only to negotiate the source of a timestamp?

Regards,
Greg
Greg

The reference [ieee1588] is to IEEE 1588-2008 which is often known as IEEE-= 1588v2.

However I think that section 3.4 point 3 needs to be changed to say:

"IEEE 1588-2008 Precision Time Protocol timestamp format [IEEE1588] tr= uncated to
use only the lower 32 bits of the seconds field. =A0This format =A0consists= of a 32-bit
seconds field followed by a 32-bit nanoseconds field and is identical to th= e
IEEE 1588-2002 timestamp format."

I cannot imagine of any OAM application that would have difficulty coping w= ith the
136 year rollover.

- Stewart






On the one hand –= the TP= =20 Identifiers documents describes the PW iden= tifier by the=20 string –= "AGI::East-Global_Node_ID::East-AC_ID::West-Global_Node_ID::West-AC= _ID."

While on the other hand= =20 - the sub-TLV in section 2.3.2 for a=20 static PW includes fields for both<= SPAN=20 lang=3Den-us> E&W Global No= de_ID, and=20 both E&W AC_ID, however does not include a=20 field for the AGI –= (Attachment Group Identification) –= part of the FEC129 definition.

Could you=20 please clarify what lies behind this difference?

Best=20 regards,

Yaacov Weingarten

Nokia Siemens Networks

Industry Environment, PTE<= SPAN=20 lang=3Den-us>

ph#:  +972-9-775 1827=

mob#: +972-54-220 0977

--_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A4BC8EUSAACMS0701e_-- From sboutros@cisco.com Thu May 19 12:26: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 DB3B3E0768; Thu, 19 May 2011 12:26:25 -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 qZZ7xfP3VgwI; Thu, 19 May 2011 12:26:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA53E0742; Thu, 19 May 2011 12:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=1030; q=dns/txt; s=iport; t=1305833185; x=1307042785; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=KFL70TfBHD6GXdAzXZbpm+q94CY/DTDO2E1uFnXnEZE=; b=lLEjmJkHrHc1joZ2fpUih0J04t4wdwH34xmECfXFIJU7EWALQQHZFnTb Daqh3iS85APJmnWt/xaap3uIpK1s4rlUN9qHkxBSQDWQt8r4/rzoyg+C3 C8mw4SlJ0OmYGzt0TtWD5JipDosqc2P7kYErmNiBYc/r5xOAp4uvYSgSh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC1u1U2rRDoG/2dsb2JhbACHbJ4nd6lbnhSGGQSGUI15il0 X-IronPort-AV: E=Sophos;i="4.65,238,1304294400"; d="scan'208";a="319502705" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 19 May 2011 19:26:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4JJQOCa012630; Thu, 19 May 2011 19:26:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 12:26:23 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.85.76]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 12:26:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 May 2011 12:26:21 -0700 To: Greg Mirsky , "Siva Sivabalan(msiva)" , Luca Martini , pwe3 , mpls@ietf.org From: Sami Boutros In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 May 2011 19:26:23.0495 (UTC) FILETIME=[A3A02170:01CC165A] Subject: Re: [mpls] Question on draft-boutros-pwe3-mpls-tp-ms-pw-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 19:26:26 -0000 Hi Greg, At 10:40 PM 5/18/2011, Greg Mirsky wrote: >Dear Authors, >I have a question on Section 3.1.2.1 when Lock (LI) is sent to S-PE. >According to draft-ietf-mpls-tp-li-lb-01 Lock operates only on MEP, >i.e. it originated by MEP and addressed to MEP. In scenario >considered in 3.1.2.1 LI addressed and processed by S-PE which is a >MIP, not MEP. I believe that if Loopback to be performed on MS-PW >the LI request must be send to remote T-PE. LB then might be set on >S-PE or remote T-PE if LI was successful. Sami: Correct. We need to update this section, agreed the LI can't be intercepted at S-PE, and hence the S-PE wouldn't need to send any PW-status for the LI on a PW. >And I think that referring to nodes as T-PE and S-PE when LI-LB >performed on MPLS-TP LSP is confusing. To address PE a PW label must >be present which is not the case if scope of LI-LB is the LSP. Sami: Sure, will update the text to use MEP/MIP to refer to nodes for LI-LB. Thanks, Sami >Regards, >Greg From cpignata@cisco.com Thu May 19 14:36: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 DDCF8E0719; Thu, 19 May 2011 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.547 X-Spam-Level: X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.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 PgXRBcU4um1I; Thu, 19 May 2011 14:36:43 -0700 (PDT) Received: from av-tac-rtp.cisco.com (unknown [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id EF366E06AE; Thu, 19 May 2011 14:36:42 -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 p4JLafSD010076; Thu, 19 May 2011 17:36:41 -0400 (EDT) Received: from [64.102.157.109] (dhcp-64-102-157-109.cisco.com [64.102.157.109]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4JLafb7018826; Thu, 19 May 2011 17:36:41 -0400 (EDT) Message-ID: <4DD58D69.2030701@cisco.com> Date: Thu, 19 May 2011 17:36:41 -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: Kamran Raza References: In-Reply-To: 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: mpls@ietf.org, pwe3@ietf.org, Sami Boutros , andrew.g.malis@one.verizon.com Subject: Re: [mpls] Seeking feedback/comments on I-D "LDP Typed Wildcard PW FEC Elements" 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, 19 May 2011 21:36:44 -0000 Hi Kamran, I think the extension of an LDP Typed-Wildcard for the PWid and Generalized PWid FEC Elements is most useful. I have some questions/comments about the document: 1. The Typed-wildcard FECs as defined in the document apply to all FECs of a given type (all 0x80 or all 0x81). In contrast, RFC 5918 defines the typed-wildcard for the Prefix FEC Element with finer granularity, including also the AFI. Would it make sense to include in this case the PW type as part of both typed-wildcard FECs? I think that this document can either define the PW Type of 0x0000 as all-types for the typed wildcard, or (better) use the existing 0x7FFF Wildcard PW Type to provide the currently expected all-types functionality. 2. I think there might be a bit of overlap with the Group ID from the PWid FEC and with the PW Grouping TLV. I think that the document could discuss why the typed-wildcard is also needed (e.g., simplicity and different grouping). I think this is a useful doc. I also have some editorials that I will unicast. Thanks, -- Carlos. On 5/5/2011 12:15 PM, Kamran Raza wrote: > > > We had presented "LDP Typed Wildcard PW FEC Elements" I-D at IETF79 and > IETF80 [http://tools.ietf.org/html/draft-raza-pwe3-pw-typed-wc-fec-00], > which defines LDP Typed Wildcard FEC elements for PW FECs types (FEC128 > PW-Id, and FEC 129 Generalized PW-Id). > > We (the authors) are seeking more feedback from the mailing list, and would > be grateful if you could review the document and post comments on the > mailing list. > > I-D Abstract: > An extension to the Label Distribution Protocol (LDP) defines the > general notion of a "Typed Wildcard Forwarding Equivalence Class > (FEC) Element". This can be used when it is desired to request all > label bindings for a given type of FEC Element, or to release or > withdraw all label bindings for a given type of FEC element. > However, a typed wildcard FEC element must be individually defined > for each type of FEC element. This specification defines the typed > wildcard FEC elements for the Pseudowire Identifier (PW Id) and > Generalized Pseudowire Identifier (Gen. PW Id) FEC types. > > [P.S: This I-D was previously submitted as L2VPN WG doc > http://tools.ietf.org/html/draft-raza-l2vpn-pw-typed-wc-fec-01, but was > later resubmitted to PWE3 WG] > > Thanks. From lizhong.jin@zte.com.cn Thu May 19 20:44:10 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 B9F3AE06B0 for ; Thu, 19 May 2011 20:44:10 -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 JNHqH96Xlum6 for ; Thu, 19 May 2011 20:44:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B2F88E0659 for ; Thu, 19 May 2011 20:44:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 1834806486374; Fri, 20 May 2011 11:37:14 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 88213.2660365077; Fri, 20 May 2011 11:43:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p4K3hsAO004426; Fri, 20 May 2011 11:43:54 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) 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: Fri, 20 May 2011 11:43:47 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-05-20 11:43:54, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-05-20 11:43:54, Serialize complete at 2011-05-20 11:43:54, S/MIME Sign failed at 2011-05-20 11:43:54: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-20 11:43:56, Serialize complete at 2011-05-20 11:43:56 Content-Type: multipart/alternative; boundary="=_alternative 00147FF748257896_=" X-MAIL: mse01.zte.com.cn p4K3hsAO004426 Cc: kebo.liu@nsn.com Subject: [mpls] Asking comments for draft-jin-mpls-mldp-leaf-discovery-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 03:44:10 -0000 This is a multipart message in MIME format. --=_alternative 00147FF748257896_= Content-Type: text/plain; charset="US-ASCII" Hi all, We update draft-jin-mpls-mldp-leaf-discovery-02, and change the "Leaf discovery mechanism based on T-LDP", by using LDP mapping/withdraw message instead of LDP withdraw message. It would be more reasonable to use LDP mapping/withdraw message to discovery leaf node. Please review and any comments are welcome. Thanks Lizhong -------------------------------------------------------- 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 00147FF748257896_= Content-Type: text/html; charset="US-ASCII"
Hi all,
We update draft-jin-mpls-mldp-leaf-discovery-02, and change the "Leaf discovery mechanism based on T-LDP", by using LDP mapping/withdraw message instead of LDP withdraw message. It would be more reasonable to use LDP mapping/withdraw message to discovery leaf node. Please review and any comments are welcome.

Thanks
Lizhong 

--------------------------------------------------------
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 00147FF748257896_=-- From skraza@cisco.com Thu May 19 21:36: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 C6B84E06C2; Thu, 19 May 2011 21:36:15 -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 t39e5oi9aTnT; Thu, 19 May 2011 21:36:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7B40AE0659; Thu, 19 May 2011 21:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=4751; q=dns/txt; s=iport; t=1305866174; x=1307075774; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=qEED/zm9b5HTnCGm/p0Njcp6EyvoQm/qEezvfb98OJI=; b=WWAFSMIuku6hci86icUoQAMpIuq5VREaFYo5LwlEBuIOpwDUKUwjo24n EMKOKRT6FVbYYJ+Dzrxmau+oRQdHgXEUrb/PvR400ziJzkuR6z6PaMzYx 6KHJtanQIae9F96wUpVN+ljKPujGVSDNZp8VKBO9rsZpYWBAPhLKP9nMS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABLv1U2tJXG+/2dsb2JhbACmGXeIcJ93nX6DLoJrBJARhDiKWQ X-IronPort-AV: E=Sophos;i="4.65,240,1304294400"; d="scan'208";a="319783166" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 20 May 2011 04:36:13 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4K4aDuW004474; Fri, 20 May 2011 04:36:13 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 23:36:13 -0500 Received: from 10.86.255.179 ([10.86.255.179]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2011 04:36:13 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 20 May 2011 00:36:11 -0400 From: Kamran Raza To: Carlos Pignataro Message-ID: Thread-Topic: [mpls] Seeking feedback/comments on I-D "LDP Typed Wildcard PW FEC Elements" Thread-Index: AcwWp3G18RuCplitn0CNPIK0G1yDIA== In-Reply-To: <4DD58D69.2030701@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 May 2011 04:36:13.0416 (UTC) FILETIME=[73269680:01CC16A7] Cc: mpls@ietf.org, pwe3@ietf.org, Sami Boutros , andrew.g.malis@one.verizon.com Subject: Re: [mpls] Seeking feedback/comments on I-D "LDP Typed Wildcard PW FEC Elements" 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, 20 May 2011 04:36:15 -0000 Hi Carlos, Thanks for the review. Please see inline [skraza] On 11-05-19 5:36 PM, "Carlos Pignataro" wrote: > Hi Kamran, > > I think the extension of an LDP Typed-Wildcard for the PWid and > Generalized PWid FEC Elements is most useful. > > I have some questions/comments about the document: > > 1. The Typed-wildcard FECs as defined in the document apply to all FECs > of a given type (all 0x80 or all 0x81). In contrast, RFC 5918 > defines the typed-wildcard for the Prefix FEC Element with finer > granularity, including also the AFI. Would it make sense to include > in this case the PW type as part of both typed-wildcard FECs? I > think that this document can either define the PW Type of 0x0000 as > all-types for the typed wildcard, or (better) use the existing > 0x7FFF Wildcard PW Type to provide the currently expected all-types > functionality. [skraza]: Typed Wildcard for Prefix FEC Element uses "AFI" mainly because "AFI" is an integral part of basic "Prefix FEC Element". Prefix FEC Element is a single type defined to include both IPv4/IPv6 prefixes, and hence AFI field is needed to distinguish b/w IPv4 Prefix and IPV6 prefix element. In case of PW, we already have different types "0x80", "0x81", "0x82" for different type of PW FEC Elements. But, I agree that we can use finer control using fields like pw-type (with wildcard pw-type defined in rfc4863). For FEC 0x80: we can use pw-type based wildcard; For FEC 0x81: we can use pw-type/AGI-type based wildcard; So, the Typed Wildcard PW FECs will be defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed Wcard | Type = PWid | Len = 2 | PW-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+ [PW-Type 0x7FFF: All-Types] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed Wcard |Type = Gen PWid| Len = 3 | PW-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | AGI-Type | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+- [PW-Type 0x7FFF: All-Types] [AGI-Type ?? (0xFF): All-Types] BTW, since "0" is not defined/available for both pw-type and agi-type fields, we can pick "0" to mean "all-types" for the consistency reasons. FEC 0x82 [P2MP PW FEC] Typed Wildcard will be similar to FEC 0x81's. > > 2. I think there might be a bit of overlap with the Group ID from the > PWid FEC and with the PW Grouping TLV. I think that the document > could discuss why the typed-wildcard is also needed (e.g., > simplicity and different grouping). > [skraza]: Sure, will add a section in the next rev to clarify this. > I think this is a useful doc. > > I also have some editorials that I will unicast. > > Thanks, > > -- Carlos. > > On 5/5/2011 12:15 PM, Kamran Raza wrote: >> >> >> We had presented "LDP Typed Wildcard PW FEC Elements" I-D at IETF79 and >> IETF80 [http://tools.ietf.org/html/draft-raza-pwe3-pw-typed-wc-fec-00], >> which defines LDP Typed Wildcard FEC elements for PW FECs types (FEC128 >> PW-Id, and FEC 129 Generalized PW-Id). >> >> We (the authors) are seeking more feedback from the mailing list, and would >> be grateful if you could review the document and post comments on the >> mailing list. >> >> I-D Abstract: >> An extension to the Label Distribution Protocol (LDP) defines the >> general notion of a "Typed Wildcard Forwarding Equivalence Class >> (FEC) Element". This can be used when it is desired to request all >> label bindings for a given type of FEC Element, or to release or >> withdraw all label bindings for a given type of FEC element. >> However, a typed wildcard FEC element must be individually defined >> for each type of FEC element. This specification defines the typed >> wildcard FEC elements for the Pseudowire Identifier (PW Id) and >> Generalized Pseudowire Identifier (Gen. PW Id) FEC types. >> >> [P.S: This I-D was previously submitted as L2VPN WG doc >> http://tools.ietf.org/html/draft-raza-l2vpn-pw-typed-wc-fec-01, but was >> later resubmitted to PWE3 WG] >> >> Thanks. -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From RCosta@ptinovacao.pt Fri May 20 01:20: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 1C44BE06E7 for ; Fri, 20 May 2011 01:20:50 -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 H2aye5OJ3MAa for ; Fri, 20 May 2011 01:20:47 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0F51CE06D1 for ; Fri, 20 May 2011 01:20:46 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Fri, 20 May 2011 09:20:44 +0100 From: Rui Costa To: Ross Callon , "mpls@ietf.org" Date: Fri, 20 May 2011 09:20:41 +0100 Thread-Topic: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwDjhWgoNAFg6qj5UKNr65DBeS+7gR/IoewAE71POA= Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201ED33511459@INOAVREX11.ptin.corpPT.com> References: In-Reply-To: Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: multipart/alternative; boundary="_000_52981DB05D3C5247A12D0AEE309F3CC201ED33511459INOAVREX11p_" 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: Fri, 20 May 2011 08:20:50 -0000 --_000_52981DB05D3C5247A12D0AEE309F3CC201ED33511459INOAVREX11p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Most if not all circuits in PT's networks are currently identified in an IC= C-oriented way. It's something defined by ITU-T before MPLS or MPLS-TP. Cus= tomer orientation made this a preferred DB primary indexation. Operators are the final client of ITU-T MPLS-TP standards, which depend on = RFC drafts like this one, so i also don't understand the decision of not ch= anging draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC= 's for the same Tunnel, LSP, PW, or Section. It looks like just an unilater= al decision to allow/promote one type of IDs while preventing others. Regards, Rui From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: quarta-feira, 18 de Maio de 2011 19:41 To: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for= the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) cons= ensus is to leave the document as currently defined. The authors are theref= ore instructed to continue progression of draft-ietf-mpls-tp-identifiers wi= thout a change in this area. This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers. Thanks, Ross and Loa (as MPLS WG chairs) [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] 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_52981DB05D3C5247A12D0AEE309F3CC201ED33511459INOAVREX11p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mixing ICC = and Global-IDs in MPLS-TP Identifiers?

Most if not all circuits in PT’s networks are currently identi= fied in an ICC-oriented way. It’s something defined by ITU-T before M= PLS or MPLS-TP. Customer orientation made this a preferred DB primary index= ation.           &nb= sp; 

Op= erators are the final client of ITU-T MPLS-TP standards, which depend on RF= C drafts like this one, so i also don’t understand the decision of no= t changing draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and= ICC’s for the same Tunnel, LSP, PW, or Section. It looks like just a= n unilateral decision to allow/promote one type of IDs while preventing oth= ers.

&n= bsp;

Regards, = ;             <= o:p>

Rui

 

<= b>From: mpls-bounces@ietf.org [mailto:mpls-bounces@iet= f.org] On Behalf Of Ross Callon
Sent: quarta-feira, 18 de = Maio de 2011 19:41
To: mpls@ietf.org
Subject: Re: [mpls= ] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

 

After discussion on the MPLS WG email list, there is no c= onsensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global= -IDs and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the= (admittedly rough) consensus is to leave the document as currently defined= . The authors are therefore instructed to continue progression of draft-iet= f-mpls-tp-identifiers without a change in this area.

<= p class=3DMsoNormal> 

This decision neither supports nor preclu= des the possibility that at some point in the future, after draft-ietf-mpls= -tp-identifiers is approved and published as an RFC, the WG might consider = additional work to extend the MPLS protocols to allow mixed identifiers.

 

Thanks,

Ross and Loa (as MPLS WG = chairs)

 

[Note that= since George is co-author of draft-ietf-mpls-tp-identifiers, for this one = document he is recused from his role as WG co-chair.]

=

 

 

From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
Sen= t: Monday, April 25, 2011 5:17 PM
To: mpls@ietf.org
Sub= ject: [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.

T= he 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. &nbs= p;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 organiz= ations if not most already have AS Numbers. =
  2. Such an addition w= ill add numerous object formats, and test cases. =
  3. The extent int= er-provider MPLS-TP is as yet unknown.  If mixed modes of ICC and Glob= al-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. &n= bsp;However for IP routing to work (in order to forward the signaling messa= ges), the providers involved will need to run BGP and have AS numbers.


We are looking for input/consensus from the WG.

G= eorge, Eric, & Matthew

=
= --_000_52981DB05D3C5247A12D0AEE309F3CC201ED33511459INOAVREX11p_-- From loa@pi.nu Fri May 20 02:58: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 383EDE074E for ; Fri, 20 May 2011 02:58:35 -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 CkkOuXq4e04r for ; Fri, 20 May 2011 02:58:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C6E0733 for ; Fri, 20 May 2011 02:58:33 -0700 (PDT) Received: from [10.5.94.152] (unknown [60.247.107.98]) (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 0C1882A8001; Fri, 20 May 2011 11:58:29 +0200 (CEST) Message-ID: <4DD63B42.20200@pi.nu> Date: Fri, 20 May 2011 17:58:26 +0800 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" References: <4DBC4D2C.9090901@pi.nu> In-Reply-To: <4DBC4D2C.9090901@pi.nu> 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 has ended: Re: 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: Fri, 20 May 2011 09:58:35 -0000 Working group, this poll has ended and we have a new working group document. Could the authors please re-publish the draft as: draft-ietf-mpls-ldp-gtsm-00 with no other changes that filename, version number and dates. /Loa On 2011-05-01 01:55, Loa Andersson wrote: > > 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 csatarijani@gmail.com Fri May 20 03:00: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 E4264E0733 for ; Fri, 20 May 2011 03:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] 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 0k2OI64FXd9Y for ; Fri, 20 May 2011 03:00:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49828E070C for ; Fri, 20 May 2011 03:00:16 -0700 (PDT) Received: by iyn15 with SMTP id 15so3583125iyn.31 for ; Fri, 20 May 2011 03:00:15 -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:content-transfer-encoding; bh=L8xxg2EA4kKryXROFQaKySwjG6EpDRfPYoYmUNipXh0=; b=wsPqBWg92E2yyi+vX3JjaV3C9kxJ2CymTe+iys6kIHXGCiRJMdJ/o5NHptc1OVqN6L yrzPGH6MSvKCpnYcI/0tY4DZWMV7KYbzZPS51sDH8BvCEzAoJxBFziCrme7uQMBre4dZ 9tmrVmhHGLc5eaMlNv8PIzJtoiMdc8nUiFgSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=EV70uQ1tPrw0i6fmAiEY0jv9rPMUpFREQA5lgd6rx/1KPX68q1HVqj5J2VJhanXpJW eaQfPT5i9wbHlMQYFAHFnMDDoGTOeGRNSZhEJHdUyNbp0GNfcRraHBzzuYe/CpmJwig9 cJkABCddhW3It82eUgCZkRbdFKDDr1rT7WpBA= MIME-Version: 1.0 Received: by 10.42.195.207 with SMTP id ed15mr5265965icb.61.1305885615122; Fri, 20 May 2011 03:00:15 -0700 (PDT) Received: by 10.42.217.131 with HTTP; Fri, 20 May 2011 03:00:15 -0700 (PDT) Date: Fri, 20 May 2011 12:00:15 +0200 Message-ID: From: =?ISO-8859-1?Q?J=E1nos_Csat=E1ri?= To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mpls] MPLS LSP Discovery 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, 20 May 2011 10:00:17 -0000 Dear Authors! I am newbie to this mailing list and I hope that I ask my question in an appropriate place. If this is not that place, then please take my apologies and ignore this message. I am J=E1nos Csat=E1ri, a student at the University of Szeged in Hungary, and I work as Network Engineer here, too. Lately, we discovered a very interesting problem in our project, and since it is very close to MPLS (well, it IS fully MPLS :) ) I humbly decided to ask for your help. I applied a lot of ideas from the MPLS Network Management - MIBs, Tools, and Techniques book (which helped me a lot during the research), especially the MPLS-LSR and MPLS-TE MIB fields, and I have a little "problem" in those particular field. My job is to create a Java plug-in for the G=E9ant3 network to provide an MPLS-Tunnel discovery method. I studied the MPLS-TE and MPLS-LSR RFCs, and created a layered domain model for the project. The idea was to utilize the MPLS-TE for Tunnel discovery (this is ready and works fine), but we wanted to get an insight to the very basics of the MPLS mechanism. Then I started to study the MPLS-LSR MIB to acquire data which can "help" to understand the topology or the tunnels. I used a lot of things from that chapter in that book, I connected the appropriate MIB tables and created the LabelToLabel rules according to the acquired information. However, I discovered a very interesting thing, or maybe the purpose why I am inspecting this MIB (tunnel discovery) is inappropriate. I humbly ask for you help in that question. I created a document with example cases, diagrams and tables, which is attached (http://cid-35a88678eaeb8048.office.live.com/view.aspx/Nyilv%c3%a1= nos/Observations%20of%20the%20MPLS.docx). Long story short: Is this layer useless to provide the topology of the Tunnels, or its only purpose is to provide full connectivity in the domain? Because I figured out, that for every entry in the OSPF routing table there is an LSP made to that network(host) from every other router, that does not have direct connection to that. Yours sincerely, J=E1nos Csat=E1ri From rajiva@cisco.com Fri May 20 04:05:24 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 687C5E077B for ; Fri, 20 May 2011 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 BSKVw6zwRLuR for ; Fri, 20 May 2011 04:05:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF3E0733 for ; Fri, 20 May 2011 04:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1514; q=dns/txt; s=iport; t=1305889523; x=1307099123; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=hBIEmcK+RniheKwjUYX5e0lKVFAvwnq2+Ttg3uo7UWE=; b=SVK0fl3CqCIyK4DAJDXHYpnll618vmCbdQRSyNWrpEEIS5YnIxOuzsp+ HLEgD97PnOmcbuNuRAVpRZgGFCboV6Eo7vP6DgOW1zM1/Z9mWIEfm+VsE NPTNvaXxHon27p6btXGNGM4csIzKAxeBxQwuqwzEiQRRzZXvsf/tgGXCP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEGALNK1k2tJV2Y/2dsb2JhbACJJpxzAneIcJ16ng4ChhcEkBGEOIZrg24 X-IronPort-AV: E=Sophos;i="4.65,241,1304294400"; d="scan'208";a="700735019" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 20 May 2011 11:05:10 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4KB5AxZ013414; Fri, 20 May 2011 11:05:10 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); Fri, 20 May 2011 06:05:09 -0500 Received: from 144.254.231.96 ([144.254.231.96]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 May 2011 11:05:09 +0000 References: <4DBC4D2C.9090901@pi.nu> <4DD63B42.20200@pi.nu> Content-Transfer-Encoding: 7bit thread-topic: Poll has ended: Re: poll on draft-asati-pignataro-mpls-ldp-gtsm-01 thread-index: AcwW3ciaR8q1v8C0Rk2R6D/dEgGHkw== From: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4DD63B42.20200@pi.nu> Message-ID: Date: Fri, 20 May 2011 07:05:06 -0400 To: "Loa Andersson" MIME-Version: 1.0 (iPhone Mail 8J2) X-OriginalArrivalTime: 20 May 2011 11:05:09.0940 (UTC) FILETIME=[C8CD8F40:01CC16DD] Cc: mpls@ietf.org, Ross Callon , draft-asati-pignataro-mpls-ldp-gtsm@tools.ietf.org Subject: Re: [mpls] Poll has ended: Re: 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: Fri, 20 May 2011 11:05:24 -0000 Loa, Will do. Thanks. Cheers, Rajiv Sent from Phone.... On May 20, 2011, at 5:58 AM, "Loa Andersson" wrote: > Working group, > > this poll has ended and we have a new working group document. > > Could the authors please re-publish the draft as: > > draft-ietf-mpls-ldp-gtsm-00 > > with no other changes that filename, version number and dates. > > /Loa > > On 2011-05-01 01:55, Loa Andersson wrote: >> >> 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 tnadeau@lucidvision.com Fri May 20 04:50: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 34EE6E06BF for ; Fri, 20 May 2011 04:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, URI_HEX=0.368] 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 ZFr-CR0T2fBe for ; Fri, 20 May 2011 04:50:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 44E12E065D for ; Fri, 20 May 2011 04:50:58 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EC56C1B7B55D; Fri, 20 May 2011 07:50:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: Date: Fri, 20 May 2011 07:50:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?J=E1nos_Csat=E1ri?= X-Mailer: Apple Mail (2.1084) Cc: mpls@ietf.org Subject: Re: [mpls] MPLS LSP Discovery 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, 20 May 2011 11:50:59 -0000 Hi, > Dear Authors! >=20 > I am newbie to this mailing list and I hope that I ask my question in > an appropriate place. If this is not that place, then please take my > apologies and ignore this message. >=20 > I am J=E1nos Csat=E1ri, a student at the University of Szeged in = Hungary, > and I work as Network Engineer here, too. Lately, we discovered a very > interesting problem in our project, and since it is very close to MPLS > (well, it IS fully MPLS :) ) I humbly decided to ask for your help. I > applied a lot of ideas from the MPLS Network Management - MIBs, Tools, > and Techniques book (which helped me a lot during the research), > especially the MPLS-LSR and MPLS-TE MIB fields, and I have a little > "problem" in those particular field. Don't waste your time with that book. *) > My job is to create a Java plug-in for the G=E9ant3 network to provide > an MPLS-Tunnel discovery method. I studied the MPLS-TE and MPLS-LSR > RFCs, and created a layered domain model for the project. The idea was > to utilize the MPLS-TE for Tunnel discovery (this is ready and works > fine), but we wanted to get an insight to the very basics of the MPLS > mechanism. Then I started to study the MPLS-LSR MIB to acquire data > which can "help" to understand the topology or the tunnels. >=20 > I used a lot of things from that chapter in that book, I connected the > appropriate MIB tables and created the LabelToLabel rules according to > the acquired information. However, I discovered a very interesting > thing, or maybe the purpose why I am inspecting this MIB (tunnel > discovery) is inappropriate. I humbly ask for you help in that > question. >=20 > I created a document with example cases, diagrams and tables, which is > attached = (http://cid-35a88678eaeb8048.office.live.com/view.aspx/Nyilv%c3%a1nos/Obse= rvations%20of%20the%20MPLS.docx). > Long story short: Is this layer useless to provide the topology of the > Tunnels, or its only purpose is to provide full connectivity in the > domain? Because I figured out, that for every entry in the OSPF > routing table there is an LSP made to that network(host) from every > other router, that does not have direct connection to that. I'd suggest taking a different approach. Rather than discovering = the LSPs via the LSR-MIB and then mapping each one "upwards" to the = applications like TE, L2VPN, L3VPN, PWs, etc.... I would recommend you = start at the applications and work your way down. The reason is = two-fold. Firstly, the set relationship is a (very) many-to-one in terms = of LSPs -> applications. That means that if you are doing = root-cause-analysis based in some alarm, and start at the LSPs to find = the affected VPNs, you are going to be spending a lot of wasted time = rifling through the LSPs that are irrelevant. The other thing is that in = general, most LSPs are put there based on IP routes and so their = persistence can be relatively low. So for example, they might change = after you have discovered them, making your correlation inaccurate. The other thing you must realize about the LSPs in the MPLS = network is that there are generally no "connections" per se; they are = generally connection-less "paths" that come and go as routing changes. = There are of course connection-oriented paths (i.e.: RSVP-TE paths for = example), but they are relatively few compared to the rest (generally = speaking). I hope that helps. If not, feel free to contact me. --Tom >=20 > Yours sincerely, > J=E1nos Csat=E1ri > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Fri May 20 08:28: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 D211EE070B; Fri, 20 May 2011 08:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP9kXoyCxz7K; Fri, 20 May 2011 08:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC3AE0688; Fri, 20 May 2011 08:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110520152837.16023.55335.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2011 08:28:37 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-gtsm-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: Fri, 20 May 2011 15:28:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : The Generalized TTL Security Mechanism (GTSM) for Label = Distribution Protocol (LDP) Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-gtsm-00.txt Pages : 7 Date : 2011-05-20 The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-00.txt From adrian@olddog.co.uk Fri May 20 08:45:10 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 1A2A1E072A for ; Fri, 20 May 2011 08:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, 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 B-L9crnHgGMB for ; Fri, 20 May 2011 08:45:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 91915E075B for ; Fri, 20 May 2011 08:45:06 -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 p4KFj49w025227; Fri, 20 May 2011 16:45:04 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p4KFj3WL025218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 May 2011 16:45:04 +0100 From: "Adrian Farrel" To: References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> In-Reply-To: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> Date: Fri, 20 May 2011 16:45:01 +0100 Message-ID: <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHG5/PmLYrQ8+eFrUY9iVN8MbLCb5SgOGTg Content-language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 15:45:10 -0000 Ermino, We have already been round this loop on this list once. Want to do it again? As Huub said, this is about identifiers, not OAM. However, the model for OAM interworking shows "layering" not gatewaying, and certainly not mixing. That is, one end of the e2e path must be capable of operating both systems, but the other does not need to. To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. This becomes particularly important to the transit nodes that may have to inspect the identifiers. None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for free) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network supports > >> multi carrier data plane interconnection with end to end OAM. In today's > >> transport network this interconnection is supported by SDH and OTN. The > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solution > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal server > >> > layer in the transport core). If peer layer interworking ever becomes > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, for > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (and > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of the > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=> > >> >> This case cannot occur in the co-cs mode). To date, however, we have > >> only > >> >> really considered intra-layer misconnectivity, ie between different > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, 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. > >> >> British Telecommunications plc > >> >> Registered office: 81 Newgate Street London EC1A 7AJ > >> >> Registered in England no: 1800000 > >> >> > >> >>> -----Original Message----- > >> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs and > >> >>> ICCs. We are fine with specifications that require both ends of an > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> 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. > >> >>>> > >> >>>> 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. > >> >>>> > >> >>>> 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 > >> >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >Loa Andersson email: loa.andersson@ericsson.com > >Sr Strategy and Standards Manager loa@pi.nu > >Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Fri May 20 09:16: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 20350E0688 for ; Fri, 20 May 2011 09:16:44 -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.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 TJOPS6wOmu71 for ; Fri, 20 May 2011 09:16:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 16B41E0651 for ; Fri, 20 May 2011 09:16:40 -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 p4KGGcji024826; Fri, 20 May 2011 11:16:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 20 May 2011 12:16:33 -0400 From: Eric Gray To: "erminio.ottone_69@libero.it" , "rcallon@juniper.net" , "mpls@ietf.org" Date: Fri, 20 May 2011 12:16:30 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwVncCJfhz+H70YRCKw0EkznDwWfQBauBwg Message-ID: References: <9391958.1470131305752014482.JavaMail.defaultUser@defaultHost> In-Reply-To: <9391958.1470131305752014482.JavaMail.defaultUser@defaultHost> 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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A5099EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [mpls] R: Re: 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: Fri, 20 May 2011 16:16:44 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A5099EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Never-the-less, the decision is clearly traceable to the fact that there is no consensus to change. A number of SDOs require this. The reason is obvious: it is always true that one can construct an argument to change the direction of work in progress, and - if we allowed each such argument to cause a change in the direction of the work in progress - we would never make progress. Hence there must be agreement to change, not simply arguments that support it. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Wednesday, May 18, 2011 4:54 PM To: rcallon@juniper.net; mpls@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? I am a bit surprised by the decision to cut such an important discussion. While it is true that there is no (yet?) agreement on mixing of Global-IDs = and ICC's, the discussion has clarified that there are major holes both in = the Requirements RFC (at least RFC5680) as well as in this document (which = also do not fullfill the incomplete set of requirements of RFC5680). One of the argument against the proposal was the lack of requirements for s= upporting inter-domain LSP/PW. However, during the discussion it appeared t= hat this scenario is required by RFC5680. As the draft in its current form = does not address this scenario, it is clearly not fullfilling the requireme= nts of RFC5680, There are other related issues which I am going to raise by replying to som= e mails on this thread. ----Messaggio originale---- Da: rcallon@juniper.net Data: 18-mag-2011 20.40 A: "mpls@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for= the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) cons= ensus is to leave the document as currently defined. The authors are theref= ore instructed to continue progression of draft-ietf-mpls-tp-identifiers wi= thout a change in this area. This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers. Thanks, Ross and Loa (as MPLS WG chairs) [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] 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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A5099EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Never-the-less, the decision is clearly traceable = to the=20 fact that there is
no consensus to change.
 
A number of SDOs require this.  The reason is= obvious:=20 it is always true
that one can construct an argument to change the d= irection=20 of work in
progress, and - if we allowed each such argument t= o cause a=20 change in
the direction of the work in progress - we would=20 never make progress.
 
Hence there must be agreement to change, not simpl= y=20 arguments that
support it.

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 erminio.ottone_69@libero.it
Sent: Wednesday, May 18, 2011 4:5= 4=20 PM
To: rcallon@juniper.net; mpls@ietf.org
Subject: [mpl= s] R:=20 Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

I am a bit surprised by the decision to cut such an important discussion= .

 

While it is true that there is no (yet?) agreement on mixing of Global-I= Ds=20 and ICC’s, the discussion has clarified that there are major holes bo= th in the=20 Requirements RFC (at least RFC5680) as well as in this document (which also= do=20 not fullfill the incomplete set of requirements of RFC5680).

One of the argument against the proposal was the lack of requirements fo= r=20 supporting inter-domain LSP/PW. However, during the discussion it appeared = that=20 this scenario is required by RFC5680. As the draft in its current form does= not=20 address this scenario, it is clearly not fullfilling the requirements of=20 RFC5680,

 

There are other related issues which I am going to raise by replyin= g to=20 some mails on this thread.

----Messaggio originale----
Da: rcallon@juniper.net
Data:= =20 18-mag-2011 20.40
A: "mpls@ietf.org"<mpls@ietf.org>
Ogg: Re:= =20 [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

After discussion on the MPLS WG emai= l=20 list, there is no consensus to change draft-ietf-mpls-tp-identifiers to a= llow=20 mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Sec= tion.=20 Instead, the (admittedly rough) consensus is to leave the document as=20 currently defined. The authors are therefore instructed to continue=20 progression of draft-ietf-mpls-tp-identifiers without a change in this=20 area.

 

This decision neither supports nor=20 precludes the possibility that at some point in the future, after=20 draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the W= G=20 might consider additional work to extend the MPLS protocols to allow mixe= d=20 identifiers.

 

Thanks,

Ross and Loa (as MPLS WG=20 chairs)

 

[Note that since George is co-author= of=20 draft-ietf-mpls-tp-identifiers, for this one document he is recused from = his=20 role as WG co-chair.]

 

 

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

 

All=20 -

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. Obta= ining=20 an AS Number (from which the Global-ID is derived) is a fairly trivial= =20 procedure.  Many organizations if not most already have AS Numbers= .=20
  2. Such= an=20 addition will add numerous object formats, and test cases.=20
  3. The = extent=20 inter-provider MPLS-TP is as yet unknown.  If mixed modes of ICC a= nd=20 Global-ID identification is required, they can be added later.=20
  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.=20


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

George, Eric, &=20 Matthew



--_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A5099EUSAACMS0701e_-- From eric.gray@ericsson.com Fri May 20 09:19: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 15AEEE06FE for ; Fri, 20 May 2011 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.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 0jhQ4rs4GkVc for ; Fri, 20 May 2011 09:19:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id EE417E0651 for ; Fri, 20 May 2011 09:19:32 -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 p4KGJVsV005157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 May 2011 11:19:31 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 20 May 2011 12:19:31 -0400 From: Eric Gray To: "erminio.ottone_69@libero.it" , Gregory Mirsky , "Malcolm.BETTS@zte.com.cn" Date: Fri, 20 May 2011 12:19:26 -0400 Thread-Topic: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwVnpL/wcYUq/c6SbyygulK94M4CQBas0iw Message-ID: References: <33481731.1472341305752379044.JavaMail.defaultUser@defaultHost> In-Reply-To: <33481731.1472341305752379044.JavaMail.defaultUser@defaultHost> 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] R: RE: R: Re: 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: Fri, 20 May 2011 16:19:34 -0000 I cannot see how support for mixed identifier types is any different from forcing both ICC and IP based operators to support both types of identifiers. Moreover, in addition=20 to requiring the operators to do so, you effectively also require every device in any operator's network to do so.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erm= inio.ottone_69@libero.it Sent: Wednesday, May 18, 2011 5:00 PM To: Gregory Mirsky; Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? Well, I understand (and I agree) that it is possible to setup via NMS an LS= P or=20 a MS-PW that crosses both IP-based and ICC-based domains even if there is n= o=20 e2e OAM. As this is possible, there is no realistic way to force the ICC-based=20 operators to support also IP-based identification nor viceversa. The issue is that the draft in its current form does not allow giving a nam= e=20 to such an LSP or MS-PW. If you allow mixing IP-based and ICC-based identifiers for path ID (as=20 proposed by ITU-T), naming these LSPs/MS-PWs becomes very trivial. As I stated in another mail, I do not see any protocol implications on mixi= ng=20 ICC and IP identifiers for path identification so it is not very clear what= is=20 the technical issue in accepting the ITU-T comment at least for path=20 identification purposes. >----Messaggio originale---- >Da: gregory.mirsky@ericsson.com >Data: 3-mag-2011 0.31 >A: "erminio.ottone_69@libero.it", "Malcolm. BETTS@zte.com.cn" >Cc: "mpls@ietf.org" >Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Dear Erminio, >I don't see an issue with NMS setting an LSP that crosses domains that=20 utilize different, IP-based and ICC-based, identifiers. The problem, as bei= ng=20 identified, in running e2e OAM on such LSP. > > Regards, > Greg > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 erminio.ottone_69@libero.it >Sent: Monday, May 02, 2011 2:58 PM >To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn >Cc: mpls@ietf.org; mpls-bounces@ietf.org >Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Section 2.1.4 of RFC5860 states: > > For certain functions, OAM messages need to incorporate > identification information (e.g., of source and/or destination > nodes). The protocol solution(s) MUST at least support > identification information in the form of an IP addressing structure > and MUST also be extensible to support additional identification > schemes. > >If an operator A supports IP-based identifiers and operator B supports ICC= -=20 based identifiers, how can we setup a transport path (LSP or PW) between th= e=20 two operators? > > >----Messaggio originale---- >Da: gregimirsky@gmail.com >Data: 28-apr-2011 1.11 >A: >Cc: "mpls@ietf.org", >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Dear Malcolm, >I agree that e2e OAM is one of requirements for MPLS-TP but I cannot find= =20 >implicit, less explicit requirement to support e2e OAM over MPLS-TP LSP an= d=20 PW=20 >with heterogeneous addressing (mixed IP and ICC). > >Regards, >Greg > >On Wed, Apr 27, 2011 at 3:44 PM, wrote: > >Eric,=20 > >If you "stitch" the LSP or PW and change identifiers you will not have end= =20 to=20 >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 27/04/2011 12:11 PM=20 >ToGeorge Swallow , "mpls@ietf.org" =20 >ccSubjectRe: [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= =20 >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 wher= e=20 >there=20 >might be an identifier form change and "stitch" them together if that is=20 what=20 >the=20 >operators want/agree to do. This limits the need-to-know for the mapping= =20 of=20 >one=20 >form of identifier to the other to the point at which this occurs, rather= =20 than=20 >at each=20 >node in the LSP or (potentially) MS-PW.=20 > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 George=20 >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=20 each=20 >end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to us= e=20 >either the Global-ID for both ends or or the ICC for both ends. Mixed use= =20 is=20 >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=20 >fairly trivial procedure. Many organizations if not most already have AS= =20 >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=20 >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 base= d=20 on=20 >either the Global-ID or ICC. That would be a radical change to how IP=20 works. =20 >However for IP routing to work (in order to forward the signaling=20 messages),=20 >the providers involved will need to run BGP and have AS numbers.=20 > >We are looking for input/consensus from the WG. > >George, Eric, & Matthew _______________________________________________=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 > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Fri May 20 09:21:46 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 1463CE0762 for ; Fri, 20 May 2011 09:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 xuzgnzttyYFV for ; Fri, 20 May 2011 09:21:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id CDBCDE0651 for ; Fri, 20 May 2011 09:21:44 -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 p4KGLekv025729; Fri, 20 May 2011 11:21:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 20 May 2011 12:21:37 -0400 From: Eric Gray To: "erminio.ottone_69@libero.it" , "jdrake@juniper.net" , "huubatwork@gmail.com" , "mpls@ietf.org" Date: Fri, 20 May 2011 12:21:22 -0400 Thread-Topic: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwVoUNSixj8oKaiSeGQDnuwjx+8LwBaIMPg Message-ID: References: <6563425.1480371305753535566.JavaMail.defaultUser@defaultHost> In-Reply-To: <6563425.1480371305753535566.JavaMail.defaultUser@defaultHost> 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] R: Re: 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: Fri, 20 May 2011 16:21:46 -0000 In looking over your arguments, I have some difficulty in seeing how your presepective is different from my own. Perhaps we are in violent agreement?=20 -----Original Message----- From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it]=20 Sent: Wednesday, May 18, 2011 5:19 PM To: jdrake@juniper.net; Eric Gray; huubatwork@gmail.com; mpls@ietf.org Subject: R: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifi= ers? Importance: High I am not the one who brought G.8113.1 on the table. I was replying to a mai= l=20 that did that arguing why this is relevant. >----Messaggio originale---- >Da: jdrake@juniper.net >Data: 4-mag-2011 2.53 >A: "erminio.ottone_69@libero.it", "eric. gray@ericsson.com", "huubatwork@gmail.com" , "mpls@ietf.org" >Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Comments inline. > >Sent from my iPhone > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: Monday, May 02, 2011 3:32 PM >> To: eric.gray@ericsson.com; huubatwork@gmail.com; mpls@ietf.org >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP >> Identifiers? >>=20 >> I do not understand how this discussion is related to the OAM debate >> regarding >> G.8113.1. > >JD: Um, what is G.8113.1, what is "the OAM debate regarding G.8113.1", an= d=20 what does either topic have to do with the identifiers draft? > >>=20 >> Nevertheless, I have not seen any supporter of G.8113.1 stating no need >> for >> end-to-end OAM nor the need for an OAM interworking function between >> G.8113.1 >> and IETF-OAM domains. > >JD: This is simply baffling > >>=20 >> Could you provide some reference about this? I might have missed them. >>=20 >> ----Messaggio originale---- >> Da: eric.gray@ericsson.com >> Data: 28-apr-2011 23.17 >> A: "huubatwork@gmail.com", >> "mpls@ietf.org"> org> >> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >> Huub, Please see below... --Eric >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub >> 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? >>=20 >> Hi Malcolm, >>=20 >> 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! >>=20 >> Actually I think a fair number of us disagree. It seems obvious (to me >> at >> least) that some sort of OAM interworkingfunction is going to be >> necessary, >> given that there is almost certainlya non-null intersection of >> operators that >> use ICC format identifiers, whoalso 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 >> identifiersand may very well use OAM as specified in IETF RFCs. Given >> that such >> an interworking requirement is likely, it is a far betteruse of time >> and energy >> to start thinking about how such an interworkingfunction would work and >> would >> most likely support translation of ICC andGlobal Identifiers. It is >> certainly a >> better use of time and energy than it is to try to support 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 >> 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. >>=20 >> 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 insome >> of the >> less temperate zones. Should this be formalized as a crystal clear >> housing >> requirement, I'mpretty sure that no one would subsequently interpret it >> to mean >> thatboth the furniture and the furnace need to be able to occupy the >> samespace >> in the same house. Since the apparent "requirement" that the same >> messages >> should beable to include either or both of the required identifiers, >> and this >> is notobvious from the assertion of a requirement to merely allow >> support >> forboth, this is indeed a late-breaking requirement. >> Best regards, Huub. >>=20 >>=20 >>=20 >> Sent from my mobile device. John E Drake >> 27/04/2011 07:25 >> PM >> To"Malcolm.BETTS@zte.com.cn" ccEric Gray >> > gray@ericsson.com>, "mpls@ietf.org" , "mpls- >> bounces@ietf.org" >> SubjectRE: [mpls] Mixing ICC and Global-IDs in >> MPLS-TP >> Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=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 >> 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] >> 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 27/04/2011 06:53 PM >>=20 >> To"Malcolm.BETTS@zte.com.cn" , Eric Gray >> > gray@ericsson.com> cc"mpls@ietf.org" , "mpls- >> bounces@ietf.org" >> SubjectRE: [mpls] Mixing ICC and Global-IDs in >> MPLS-TP >> Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Malcolm, >>=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 >> Thanks, >>=20 >> John >>=20 >> Sent from my iPhone >>=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 >> Eric Gray >> Sent by: mpls-bounces@ietf.org 27/04/2011 12:11 PM >>=20 >> ToGeorge Swallow , "mpls@ietf.org" >> cc >> SubjectRe: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >>=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? >>=20 >> 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 >> 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. >>=20 >> We are looking for input/consensus from the WG. >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From eric.gray@ericsson.com Fri May 20 09:29: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 104CFE0710; Fri, 20 May 2011 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Bvbga+CUkn3t; Fri, 20 May 2011 09:29:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C8E06F3; Fri, 20 May 2011 09:29:10 -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 p4KGT8nO026991; Fri, 20 May 2011 11:29:09 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 20 May 2011 12:29:05 -0400 From: Eric Gray To: "Malcolm.BETTS@zte.com.cn" , Ross Callon Date: Fri, 20 May 2011 12:28:36 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwV/+cH0p/FLO9FR5+pVgUaVbQrFgBCk6dg 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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A50B1EUSAACMS0701e_" 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: Fri, 20 May 2011 16:29:13 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F10B075A50B1EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, As a co-author of the draft in question, I completely support this deci= sion. As I already explained to another person asking the same question, the bit about "no consensus to change" says it all. In my opinion, this is a quite sufficiently detailed response. The abs= ence of a consensus to change means no change. We do not typically require a strong consensus to continue on the current path. I am reasonably certain you apply similar rules yourself when working i= n other SDOs. -- Eric ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross, I disappointed and, based on my reading of the emails on this thread, surpr= ised that this decision has been taken. Could you please elaborate on the = reasoning behind this decision. Regards, Malcolm Ross Callon Sent by: mpls-bounces@ietf.org 18/05/2011 02:40 PM To "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for= the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) cons= ensus is to leave the document as currently defined. The authors are theref= ore instructed to continue progression of draft-ietf-mpls-tp-identifiers wi= thout a change in this area. This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers. Thanks, Ross and Loa (as MPLS WG chairs) [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] 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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A50B1EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Malcolm,
 
  &n= bsp; As a co-author of the draft in questi= on, I=20 completely support this decision.
 
  &n= bsp; As I already explained to another per= son asking=20 the same question, the
bit about "no consensus to change" says it=20 all.
 
  &n= bsp; In my opinion, this is a quite suffic= iently=20 detailed response.  The absence
of a consensus to change means no change.  We= do not=20 typically require a
strong consensus to continue on the current=20 path.
 
  &n= bsp; I am reasonably certain you apply sim= ilar rules=20 yourself when working in
other SDOs.
 
--
Eric
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn
Sent: Thursday, May 19, 2011 4:25=20 AM
To: Ross Callon
Cc: mpls@ietf.org;=20 mpls-bounces@ietf.org
Subject: Re: [mpls] Mixing ICC and Global-I= Ds in=20 MPLS-TP Identifiers?


Ross,

I disappointed and, based on my reading of the e= mails on=20 this thread, surprised that this decision has been taken.  Could you p= lease=20 elaborate on the reasoning behind this decision.

Regards,

Malcolm



Ross Callon=20 <rcallon@juniper.net>
Sent by: mpls-bounces@ietf.org=20

18/05/2011 02:40 PM

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




After discussion on the MPLS WG email list, there = is no=20 consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Globa= l-IDs=20 and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the (adm= ittedly=20 rough) consensus is to leave the document as currently defined. The authors= are=20 therefore instructed to continue progression of draft-ietf-mpls-tp-identifi= ers=20 without a change in this area.
 
Th= is decision=20 neither supports nor precludes the possibility that at some point in the fu= ture,=20 after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, t= he WG=20 might consider additional work to extend the MPLS protocols to allow mixed= =20 identifiers.
 = ;=20
Thanks,
Ross and Loa (as MPLS WG chairs)=20
 
[Note that since George is co-author of=20 draft-ietf-mpls-tp-identifiers, for this one document he is recused from hi= s=20 role as WG co-chair.]
 
&n= bsp;=20
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of George=20 Swallow
Sent: Monday, April 25, 2011 5:17 PM
To:=20 mpls@ietf.org
Subject: [mpls] Mixing ICC and Global-IDs in MPLS-T= P=20 Identifiers?
 =20
All -

Many of the comments receive= d from=20 the ITU on 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.      = =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.
2.=20        Such an add= ition=20 will add numerous object formats, and test cases.
3.        The extent inter-provider MPLS-TP is as yet unknown.  If mixe= d modes=20 of ICC and Global-ID identification is required, they can be added later.=20
4.      =20  For signaled connections, there = is no=20 plan to allow routing based on either the Global-ID or ICC.  That woul= d be=20 a radical change to how IP works.  However for IP routing to work (in = order=20 to forward the signaling messages), the providers involved will need to run= BGP=20 and have AS numbers.

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_C0AC8FAB6849AB4FADACCC70A949E2F10B075A50B1EUSAACMS0701e_-- From ilya@nobulus.com Fri May 20 15:09: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 D2029E070E for ; Fri, 20 May 2011 15:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, 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 70DYE8Rkt6tg for ; Fri, 20 May 2011 15:09:52 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 73C01E06AE for ; Fri, 20 May 2011 15:09:51 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id E088E17481 for ; Sat, 21 May 2011 00:09:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3PfJnLM852-r for ; Sat, 21 May 2011 00:09:47 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 118B017493 for ; Sat, 21 May 2011 00:09:46 +0200 (CEST) From: Ilya Varlashkin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 May 2011 00:09:43 +0200 Message-Id: To: IETF MPLS Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mpls] possibly error in rfc5443 (LDP-IGP sync) 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, 20 May 2011 22:09:53 -0000 Hi, section 2 "Proposed solution" of rfc5443 has text that reads: "...if a link is configured with 2^24-1 (the maximum link metric per = [RFC5305]), then this link is not advertised in the topology..." I believe this statement is not accurate because rfc5305 in fact = foresees situation that a link can be advertised with max metric. = Alternatively, if the above mentioned statement was intended to be part = of the proposed solution then it contradicts with very next sentence in = the same rfc5443, in which case it's still erroneous. Kind regards,=20 iLya From loa@pi.nu Sat May 21 02:56: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 8BDE0E0686 for ; Sat, 21 May 2011 02:56:22 -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 5UiNey7ugKjG for ; Sat, 21 May 2011 02:56:21 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0FE067C for ; Sat, 21 May 2011 02:56:20 -0700 (PDT) Received: from [10.5.94.152] (unknown [60.247.107.98]) (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 C36072A8002; Sat, 21 May 2011 11:17:36 +0200 (CEST) Message-ID: <4DD7832D.1070804@pi.nu> Date: Sat, 21 May 2011 17:17:33 +0800 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" , draft-ietf-mpls-ldp-p2mp@tools.ietf.org, George Swallow , Ross Callon , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR claims against draft-ietf-mpls-ldp-p2mp 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, 21 May 2011 09:56:22 -0000 Working Group, when we did the working group last call on draft-ietf-mpls-ldp-p2mp we failed to notify the working group that there are IPR claims against this draft. We have requested publication of this document as an RFC on the standards track! It is current in AD review and Adrian has requested that a new version is published addressing his comments before going to IETF last call. We would like to take the opportunity to ask if there is any issues continuing the publication process with the existing IPR claims in place. There are several ways to get to the IPR claims, the one I prefer is to go to: http://datatracker.ietf.org/wg/mpls/ find the draft and click on the figure in the IPR column. Please let the working group chairs and the mailing list know if you have issues with these IPR claims that would cause us to discontinue the publication process, before June 3rd 2011. Loa mpls wg co-chair -- 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 malcolm.betts@zte.com.cn Sat May 21 17:05: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 0C3F8E0716; Sat, 21 May 2011 17:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 HxY5002toK36; Sat, 21 May 2011 17:05:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 90AFDE06CA; Sat, 21 May 2011 17:05:36 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 18341784411434; Sun, 22 May 2011 07:58:04 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 88213.2171356784; Sun, 22 May 2011 08:05:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p4M05TT3054334; Sun, 22 May 2011 08:05:29 +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: Sat, 21 May 2011 20:04:51 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-22 08:05:30, Serialize complete at 2011-05-22 08:05:30 Content-Type: multipart/alternative; boundary="=_alternative 00007F0E85257898_=" X-MAIL: mse01.zte.com.cn p4M05TT3054334 Cc: Ross Callon , "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: Sun, 22 May 2011 00:05:41 -0000 This is a multipart message in MIME format. --=_alternative 00007F0E85257898_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eric, I find that argument somewhat circular since we did not have consensus to = omit this. Regards, Malcolm Eric Gray =20 20/05/2011 12:28 PM To "Malcolm.BETTS@zte.com.cn" , Ross Callon=20 cc "mpls@ietf.org" , "mpls-bounces@ietf.org"=20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, =20 As a co-author of the draft in question, I completely support this=20 decision. =20 As I already explained to another person asking the same question, the = bit about "no consensus to change" says it all. =20 In my opinion, this is a quite sufficiently detailed response. The=20 absence of a consensus to change means no change. We do not typically require a strong consensus to continue on the current path. =20 I am reasonably certain you apply similar rules yourself when working=20 in other SDOs. =20 -- Eric From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 Of Malcolm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross,=20 I disappointed and, based on my reading of the emails on this thread,=20 surprised that this decision has been taken. Could you please elaborate=20 on the reasoning behind this decision.=20 Regards,=20 Malcolm=20 Ross Callon =20 Sent by: mpls-bounces@ietf.org=20 18/05/2011 02:40 PM=20 To "mpls@ietf.org" =20 cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to=20 change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and=20 ICC?s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly=20 rough) consensus is to leave the document as currently defined. The=20 authors are therefore instructed to continue progression of=20 draft-ietf-mpls-tp-identifiers without a change in this area.=20 =20 This decision neither supports nor precludes the possibility that at some=20 point in the future, after draft-ietf-mpls-tp-identifiers is approved and=20 published as an RFC, the WG might consider additional work to extend the=20 MPLS protocols to allow mixed identifiers.=20 =20 Thanks,=20 Ross and Loa (as MPLS WG chairs)=20 =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers,=20 for this one document he is recused from his role as WG co-chair.]=20 =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?=20 =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 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 --=_alternative 00007F0E85257898_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eric,

I find that argument somewhat circul= ar since  we did not have consensus to omit this.

Regards,

Malcolm



Eric Gray <eric.gr= ay@ericsson.com>

20/05/2011 12:28 PM

To
"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Ross Callon <rcallon@juniper.net>
cc
"mpls@ietf.org" <mpls@i= etf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
Subject
RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





Malcolm,
 
    As a co-author of the draft in question, I completely support this decision.
 
    As I already explained to another person asking the same question, the
bit about "no consensus= to change" says it all.
 
    In my opinion, this is a quite sufficiently detailed response.  The absen= ce
of a consensus to change mea= ns no change.  We do not typically require a
strong consensus to continue= on the current path.
 
    I am reasonably certain you apply similar rules yourself when working in
other SDOs.
 
--
Eric <= /font>
From: mpls-bounces@ietf.org [mail= to:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Ross,

I disappointed and, based on my reading of the emails on this thread, surpr= ised that this decision has been taken.  Could you please elaborate on the reasoning behind this decision.

Regards,

Malcolm


Ross Callon <rcall= on@juniper.net>
Sent by: mpls-bounces@ietf.org

18/05/2011 02:40 PM


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







After discussion on the MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifi= ers without a change in this area.
 
This decision neither supports nor precludes the possibility that at some point in the future, after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.
 
Thanks,
Ross and Loa (as MPLS WG chairs)
 
[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG co-chair.]
 
 
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 00007F0E85257898_=-- From malcolm.betts@zte.com.cn Sat May 21 17:35: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 51BAEE0713; Sat, 21 May 2011 17:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 2ucqV1t9-f3V; Sat, 21 May 2011 17:35:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 77776E0677; Sat, 21 May 2011 17:35:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 18341784411434; Sun, 22 May 2011 07:58:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 88213.1929085062; Sun, 22 May 2011 08:05:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4M0575b081044; Sun, 22 May 2011 08:05:07 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> To: adrian@olddog.co.uk MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Sat, 21 May 2011 20:04:28 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-22 08:05:08, Serialize complete at 2011-05-22 08:05:08 Content-Type: multipart/alternative; boundary="=_alternative 000075E085257898_=" X-MAIL: mse02.zte.com.cn p4M0575b081044 Cc: mpls-bounces@ietf.org, mpls@ietf.org Subject: Re: [mpls] R: Re: 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: Sun, 22 May 2011 00:35:29 -0000 This is a multipart message in MIME format. --=_alternative 000075E085257898_= Content-Type: text/plain; charset="US-ASCII" Adrian, Please see in line below. Regards, Malcolm "Adrian Farrel" Sent by: mpls-bounces@ietf.org 20/05/2011 11:45 AM Please respond to adrian@olddog.co.uk To cc mpls@ietf.org Subject Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still open.... As Huub said, this is about identifiers, not OAM. However, the model for OAM interworking shows "layering" not gatewaying, and certainly not mixing. That is, one end of the e2e path must be capable of operating both systems, but the other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of identifiers. This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string. None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone_69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for free) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network supports > >> multi carrier data plane interconnection with end to end OAM. In today's > >> transport network this interconnection is supported by SDH and OTN. The > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" , > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solution > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal server > >> > layer in the transport core). If peer layer interworking ever becomes > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, for > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (and > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of the > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=> > >> >> This case cannot occur in the co-cs mode). To date, however, we have > >> only > >> >> really considered intra-layer misconnectivity, ie between different > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, 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. > >> >> British Telecommunications plc > >> >> Registered office: 81 Newgate Street London EC1A 7AJ > >> >> Registered in England no: 1800000 > >> >> > >> >>> -----Original Message----- > >> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs and > >> >>> ICCs. We are fine with specifications that require both ends of an > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow > >> >>> wrote: > >> >>>> 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. > >> >>>> > >> >>>> 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. > >> >>>> > >> >>>> 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 > >> >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >Loa Andersson email: loa.andersson@ericsson.com > >Sr Strategy and Standards Manager loa@pi.nu > >Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls 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 --=_alternative 000075E085257898_= Content-Type: text/html; charset="US-ASCII"
Adrian,

Please see in line below.

Regards,

Malcolm



"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: mpls-bounces@ietf.org

20/05/2011 11:45 AM
Please respond to
adrian@olddog.co.uk
To
<erminio.ottone_69@libero.it>
cc
mpls@ietf.org
Subject
Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?





Ermino,

We have already been round this loop on this list once.
Want to do it again?

[MB] well the continuation of this thread indicates that the loop is still open....

As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.

[MB] OK

To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.

[MB] It requires that one of the operators must administer both types of identifiers.  This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

This becomes particularly important to the transit nodes that may have to
inspect the identifiers.

[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string.

None of this is new or specific to MPLS-TP.

Adrian

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> erminio.ottone_69@libero.it
> Sent: 18 May 2011 22:25
> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
> Appendix II of Y.1731 provides a good example about how inter-domain
> connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
>
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
>
> http://www.itu.int/rec/T-REC-Y.1731/en
>
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
>
> >----Messaggio originale----
> >Da: loa@pi.nu
> >Data: 4-mag-2011 8.00
> >A: <mpls@ietf.org>,
> "Malcolm.BETTS@zte.com.cn"<Malcolm.BETTS@zte.com.cn>
> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconnection as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <swallow@cisco.com>*
> >> Sent by: mpls-bounces@ietf.org
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >>                  "Andrew G. Malis" <agmalis@gmail.com>, <neil.2.harrison@bt.com>
> >> cc
> >>                  mpls@ietf.org
> >> Subject
> >>                  Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >>  > Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surrounds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis@gmail.com> wrote:
> >>
> >>  > Neil,
> >>  >
> >>  > To your case 1, we're in complete agreement. We (VZ) don't see at
> >>  > least a short-term need for peer-layer interworking, given where we
> >>  > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >>  > layer in the transport core). If peer layer interworking ever becomes
> >>  > a necessity, then obviously we'll need a well-defined E-NNI which
> >>  > would include LSP identifier mapping/translation at the boundary, for
> >>  > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>  >
> >>  > I also agree that both intra-layer and inter-layer mis-connectivity
> >>  > detection and amelioration are required, but I'm not convinced that
> >>  > the already defined mechanisms can't do that. Do you have some
> >>  > specific analysis on the inter-layer case?
> >>  >
> >>  > Cheers,
> >>  > Andy
> >>  >
> >>  > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harrison@bt.com> wrote:
> >>  >> Hi Andy,
> >>  >>
> >>  >> 2 points:
> >>  >>
> >>  >> 1 I agree with your view of only having a single addressing scheme in
> a
> >>  >> single layer network solely belonging to one party. Though you may
> >> need to
> >>  >> be rather careful if you also advocate that one can also have peer
> layer
> >>  >> interworking between different parties, ie E-NNIs (I believe this is
> >>  >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >>  >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >>  >> any other variations in DP/CP functional components) if they exist
> >> in the
> >>  >> standards.
> >>  >>
> >>  >> Of course, having an E-NNI and peer interworking between different
> >> parties in
> >>  >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >>  >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >>  >> single addressing scheme in a non-TOS layer network.
> >>  >>
> >>  >>
> >>  >> 2 You should also be aware that in client/server interworking of the
> >>  >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >>  >> important for MPLS-TP in the role of a transport network (I'll
> >> ignore issues
> >>  >> of transparency here), there could be inter-layer misconnectivity
> >> (Aside=>
> >>  >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >>  >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >>  >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >>  >> sublayer misconnectivity).
> >>  >>
> >>  >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >>  >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >>  >> come from (i) networks using different OAM/addressing solutions or
> (ii)
> >>  >> networks using the same OAM/addressing solutions. In both cases
> >> there are
> >>  >> different issues wrt inter-layer misconnectivity one has to deal
> >> with. I'm
> >>  >> not aware that these cases have been considered yet.
> >>  >>
> >>  >>
> >>  >> I'd like to hear your comments on both these points, but in
> >> particular the
> >>  >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >>  >> as there seems to a possible logical conflict here.
> >>  >>
> >>  >> Thanks.
> >>  >>
> >>  >> regards, 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.
> >>  >> British Telecommunications plc
> >>  >> Registered office: 81 Newgate Street London EC1A 7AJ
> >>  >> Registered in England no: 1800000
> >>  >>
> >>  >>> -----Original Message-----
> >>  >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
> Of
> >>  >>> Andrew G. Malis
> >>  >>> Sent: 02 May 2011 20:48
> >>  >>> To: George Swallow
> >>  >>> Cc: mpls@ietf.org
> >>  >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>  >>>
> >>  >>> George et al,
> >>  >>>
> >>  >>> Verizon does not have any requirement for mixed use of Global IDs and
> >>  >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >>  >>> to use one or the other.
> >>  >>>
> >>  >>> Thanks,
> >>  >>> Andy
> >>  >>>
> >>  >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow@cisco.com>
> >>  >>> wrote:
> >>  >>>> 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.
> >>  >>>>
> >>  >>>> 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.
> >>  >>>>
> >>  >>>> 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
> >>  >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >--
> >
> >
> >Loa Andersson                         email: loa.andersson@ericsson.com
> >Sr Strategy and Standards Manager            loa@pi.nu
> >Ericsson Inc                          phone: +46 10 717 52 13
> >                                              +46 767 72 92 13
> >_______________________________________________
> >mpls mailing list
> >mpls@ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> _______________________________________________
> mpls 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
--=_alternative 000075E085257898_=-- From tnadeau@lucidvision.com Sat May 21 17:44: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 E7C10E06BE; Sat, 21 May 2011 17:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.633, 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 XVveUeNDLQ6s; Sat, 21 May 2011 17:44:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 16A64E0677; Sat, 21 May 2011 17:44:57 -0700 (PDT) Received: from [192.168.1.101] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 84E821B81993; Sat, 21 May 2011 20:44:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--847102796 From: Thomas Nadeau In-Reply-To: Date: Sat, 21 May 2011 20:44:55 -0400 Message-Id: <92D0AB85-20A8-45CC-AA5D-F0C9606DFEC8@lucidvision.com> References: To: Malcolm.BETTS@zte.com.cn X-Mailer: Apple Mail (2.1084) Cc: Ross Callon , "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: Sun, 22 May 2011 00:45:00 -0000 --Apple-Mail-1--847102796 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Malcolm, I think you have been doing this long enough to realize that it = is not you who call consensus; its the WG chairs. As I recall, that has = been done. --Tom >=20 > Eric,=20 >=20 > I find that argument somewhat circular since we did not have = consensus to omit this.=20 >=20 > Regards,=20 >=20 > Malcolm=20 >=20 >=20 >=20 > Eric Gray > 20/05/2011 12:28 PM >=20 > To > "Malcolm.BETTS@zte.com.cn" , Ross Callon = > cc > "mpls@ietf.org" , "mpls-bounces@ietf.org" = > Subject > RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 >=20 >=20 >=20 >=20 > Malcolm,=20 > =20 > As a co-author of the draft in question, I completely support this = decision.=20 > =20 > As I already explained to another person asking the same question, = the=20 > bit about "no consensus to change" says it all.=20 > =20 > In my opinion, this is a quite sufficiently detailed response. = The absence=20 > of a consensus to change means no change. We do not typically require = a=20 > strong consensus to continue on the current path.=20 > =20 > I am reasonably certain you apply similar rules yourself when = working in=20 > other SDOs.=20 > =20 > --=20 > Eric > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Malcolm.BETTS@zte.com.cn > Sent: Thursday, May 19, 2011 4:25 AM > To: Ross Callon > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 >=20 > Ross,=20 >=20 > I disappointed and, based on my reading of the emails on this thread, = surprised that this decision has been taken. Could you please elaborate = on the reasoning behind this decision.=20 >=20 > Regards,=20 >=20 > Malcolm=20 >=20 >=20 > Ross Callon =20 > Sent by: mpls-bounces@ietf.org > 18/05/2011 02:40 PM >=20 >=20 > To > "mpls@ietf.org" > cc > Subject > Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 >=20 >=20 >=20 >=20 >=20 >=20 > After discussion on the MPLS WG email list, there is no consensus to = change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and = ICC=92s for the same Tunnel, LSP, PW, or Section. Instead, the = (admittedly rough) consensus is to leave the document as currently = defined. The authors are therefore instructed to continue progression of = draft-ietf-mpls-tp-identifiers without a change in this area.=20 > =20 > This decision neither supports nor precludes the possibility that at = some point in the future, after draft-ietf-mpls-tp-identifiers is = approved and published as an RFC, the WG might consider additional work = to extend the MPLS protocols to allow mixed identifiers.=20 > =20 > Thanks,=20 > Ross and Loa (as MPLS WG chairs)=20 > =20 > [Note that since George is co-author of = draft-ietf-mpls-tp-identifiers, for this one document he is recused from = his role as WG co-chair.]=20 > =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?=20 > =20 > 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 > 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 >=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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-1--847102796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 = Malcolm,

I think you have been doing this = long enough to realize that it is not you who call consensus; its the WG = chairs.  As I recall, that has been = done.

= --Tom




Eric,

I find that argument somewhat = circular since  we did not have consensus to omit this.

Regards,

Malcolm



Eric Gray = <eric.gray@ericsson.com>

20/05/2011 12:28 = PM

To
"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>,= Ross Callon <rcallon@juniper.net>
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,
 
    As a co-author of the draft in question, I completely support this = decision.
 
    As I already explained to another person asking the same question, the =
bit about "no = consensus to change" says it all.
 
    In my opinion, this is a quite sufficiently detailed response.  The = absence
of a consensus to = change means no change.  We do not typically require a
strong consensus to = continue on the current path.
 
    I am reasonably certain you apply similar rules yourself when working = in
other SDOs.
 
--
Eric
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP = Identifiers?

Ross,

I disappointed and, based on my reading of the emails on this thread, = surprised that this decision has been taken.  Could you please elaborate on the reasoning behind this decision.

Regards,

Malcolm


Ross Callon = <rcallon@juniper.net>=
Sent by: mpls-bounces@ietf.org

18/05/2011 = 02:40 PM


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







After discussion on the MPLS WG email list, there is no consensus to = change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=92s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly = rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of = draft-ietf-mpls-tp-identifiers without a change in this area.
 
This decision neither supports nor precludes the possibility that at = some point in the future, after draft-ietf-mpls-tp-identifiers is approved = and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.
 
Thanks,
Ross and Loa (as MPLS WG chairs)
 
[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG = co-chair.]
 
 
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/m= ailman/listinfo/mpls
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls

= --Apple-Mail-1--847102796-- From yaacov.weingarten@nsn.com Sat May 21 22:56: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 804B3E0693; Sat, 21 May 2011 22:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.510, 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 C8N4XgqJESVO; Sat, 21 May 2011 22:56:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A6032E0618; Sat, 21 May 2011 22:56:13 -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 p4M5u0hu032539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2011 07:56:00 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4M5twqI008911; Sun, 22 May 2011 07:56:00 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 May 2011 07:55:58 +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_01CC1843.E1880915" Date: Sun, 22 May 2011 07:48:29 +0200 Message-ID: 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: AcwYFAnzPs8SalJUTPSBHwUxfeyeCAAL1GSw References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , "Eric Gray" X-OriginalArrivalTime: 22 May 2011 05:55:58.0140 (UTC) FILETIME=[EBE507C0:01CC1844] Cc: Ross Callon , 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: Sun, 22 May 2011 05:56:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1843.E1880915 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, hi =20 Borrowing the logic from other SDO's - any standards work is contribution driven - if you or any of the other persons feel that they see a need to extend the current draft with features that are not covered by the current work, they are able to write a new I-D that extends the functionality and details how this extension can be supported and whose responsibility (i.e. which MEP) it is to support all of the different formats. =20 Best regards, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Malcolm.BETTS@zte.com.cn Sent: Sunday, May 22, 2011 3:05 AM To: Eric Gray Cc: Ross Callon; mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Eric,=20 I find that argument somewhat circular since we did not have consensus to omit this.=20 Regards,=20 Malcolm=20 Eric Gray =20 20/05/2011 12:28 PM=20 To "Malcolm.BETTS@zte.com.cn" , Ross Callon =20 cc "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 As a co-author of the draft in question, I completely support this decision.=20 =20 As I already explained to another person asking the same question, the=20 bit about "no consensus to change" says it all.=20 =20 In my opinion, this is a quite sufficiently detailed response. The absence=20 of a consensus to change means no change. We do not typically require a strong consensus to continue on the current path.=20 =20 I am reasonably certain you apply similar rules yourself when working in=20 other SDOs.=20 =20 --=20 Eric=20 ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross,=20 I disappointed and, based on my reading of the emails on this thread, surprised that this decision has been taken. Could you please elaborate on the reasoning behind this decision.=20 Regards,=20 Malcolm=20 Ross Callon =20 Sent by: mpls-bounces@ietf.org=20 18/05/2011 02:40 PM=20 =20 To "mpls@ietf.org" =20 cc =09 Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 =09 After discussion on the MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifiers without a change in this area.=20 =20 This decision neither supports nor precludes the possibility that at some point in the future, after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.=20 =20 Thanks,=20 Ross and Loa (as MPLS WG chairs)=20 =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG co-chair.]=20 =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?=20 =20 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. George, Eric, & Matthew _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------_=_NextPart_001_01CC1843.E1880915 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm, hi

 

Borrowing the logic from other SDO's – any = standards work is contribution driven – if you or any of the other = persons feel that they see a need to extend the current draft with = features that are not covered by the current work, they are able to = write a new I-D that extends the functionality and details how this = extension can be supported and whose responsibility (i.e. which MEP) it = is to support all of the different formats.

 

Best regards,

yaacov

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Malcolm.BETTS@zte.com.cn
Sent: Sunday, May 22, 2011 = 3:05 AM
To: Eric Gray
Cc: Ross Callon; = mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] = Mixing ICC and Global-IDs in MPLS-TP = Identifiers?

 


Eric, =

I find that = argument somewhat circular since  we did not have consensus to omit = this.

Regards,

Malcolm


Eric Gray = <eric.gray@ericsson.com> =

20/05/2011 = 12:28 PM

To=

"Malcolm.= BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Ross Callon = <rcallon@juniper.net>

cc=

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

Subject=

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

 




Ma= lcolm,
 
    As= a co-author of the draft in question, I completely support this = decision.
 
    As= I already explained to another person asking the same question, the =
bi= t about "no consensus to change" says it all. =
 
    In= my opinion, this is a quite sufficiently detailed response.  The = absence
of= a consensus to change means no change.  We do not typically = require a
st= rong consensus to continue on the current path.
  =
    I = am reasonably certain you apply similar rules yourself when working = in
ot= her SDOs.
 
--=
Er= ic

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Malcolm.BETTS@zte.com.cn
Sent: Thursday, May 19, 2011 4:25 = AM
To: Ross Callon
Cc: mpls@ietf.org; = mpls-bounces@ietf.org
Subject: Re: [mpls] Mixing ICC and = Global-IDs in MPLS-TP Identifiers?


Ross,

I = disappointed and, based on my reading of the emails on this thread, = surprised that this decision has been taken.  Could you please = elaborate on the reasoning behind this decision.

Regards,<= /span>

Malcolm

Ross Callon = <rcallon@juniper.net>
Sent by: = mpls-bounces@ietf.org

18/05/2011 = 02:40 PM

 

To=

"mpls@iet= f.org" <mpls@ietf.org> =

cc=

Subject=

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

 





After discussion on the MPLS WG email list, there is no consensus = to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs = and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the = (admittedly rough) consensus is to leave the document as currently = defined. The authors are therefore instructed to continue progression of = draft-ietf-mpls-tp-identifiers without a change in this area. =
 
This decision neither supports nor precludes the possibility that = at some point in the future, after draft-ietf-mpls-tp-identifiers is = approved and published as an RFC, the WG might consider additional work = to extend the MPLS protocols to allow mixed identifiers. =
 
Thanks,
Ross and Loa (as MPLS WG chairs)
 
[Note that since George is co-author of = draft-ietf-mpls-tp-identifiers, for this one document he is recused from = his role as WG co-chair.]
 
 
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/l= istinfo/mpls

------_=_NextPart_001_01CC1843.E1880915-- From erminio.ottone_69@libero.it Sun May 22 10:25:33 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 45B24E06D5 for ; Sun, 22 May 2011 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 X7cxlPyCZn+e for ; Sun, 22 May 2011 10:25:32 -0700 (PDT) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 67225E06B4 for ; Sun, 22 May 2011 10:25:28 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020C.4DD94706.0040,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail53 (172.31.0.244) by cp-out1.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD237D50072608D; Sun, 22 May 2011 19:25:25 +0200 Message-ID: <29103941.2646971306085125867.JavaMail.root@wmail53> Date: Sun, 22 May 2011 19:25:25 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.164.217 Cc: mpls@ietf.org Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 17:25:33 -0000 I am very confused. If we are speaking about identifiers and not OAM why the fact that some endpoints need to support two OAM protocols requires some networks to support two identifers' schemes? >----Messaggio originale---- >Da: adrian@olddog.co.uk >Data: 20-mag-2011 17.45 >A: >Cc: >Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Ermino, > >We have already been round this loop on this list once. >Want to do it again? > >As Huub said, this is about identifiers, not OAM. However, the model for OAM >interworking shows "layering" not gatewaying, and certainly not mixing. That is, >one end of the e2e path must be capable of operating both systems, but the other >does not need to. > >To extend this model to identifiers means that one end of the e2e path must >support both identifier formats and the other does not need to. > >This becomes particularly important to the transit nodes that may have to >inspect the identifiers. > >None of this is new or specific to MPLS-TP. > >Adrian > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: 18 May 2011 22:25 >> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> Appendix II of Y.1731 provides a good example about how inter-domain >> connectivity with e2e OAM can be provided using transport-oriented OAM >> functions. >> >> You can download the latest version of Y.1731 (the pdr version is for free) at >> the following URL: >> >> http://www.itu.int/rec/T-REC-Y.1731/en >> >> It is a pity that with the current version of the identifier draft, MPLS-TP is >> not capable to support such a network scenario. >> >> >----Messaggio originale---- >> >Da: loa@pi.nu >> >Data: 4-mag-2011 8.00 >> >A: , >> "Malcolm.BETTS@zte.com.cn" >> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> > >> >Malcolm, >> > >> >are you saying that operators today allow OAM to control node (MIPs and >> >MEPs) on each others networks? >> > >> >Do we have an operator that can verify this? >> > >> >/Loa >> > >> >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >> >> >> >> All, >> >> >> >> I share your concerns and doubts about a multi carrier control plane. >> >> However, I think that it is essential that a transport network supports >> >> multi carrier data plane interconnection with end to end OAM. In today's >> >> transport network this interconnection is supported by SDH and OTN. The >> >> objective for MPLS-TP is to allow for packet based interconnection as >> well. >> >> >> >> Regards, >> >> >> >> Malcolm >> >> >> >> >> >> >> >> *George Swallow * >> >> Sent by: mpls-bounces@ietf.org >> >> >> >> 03/05/2011 11:09 AM >> >> >> >> >> >> To >> >> "Andrew G. Malis" , >> >> cc >> >> mpls@ietf.org >> >> Subject >> >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Andy - >> >> >> >> > Such >> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to >> >> > put on the to-do list). This E-NNI would also include similar >> >> > identifier mapping/translation for MS-PWs, to answer an earlier >> >> > question from Erminio that I saw on the list. >> >> >> >> You are quite correct here! I think much of this debate surrounds a >> problem >> >> that is yet to be solved. So there are arguments for pieces of a solution >> >> without and overall architecture. >> >> >> >> Based on all that I am seeing my inclination is to NOT say that we >> disallow >> >> mixed identifiers, but to say that they are for future study. >> >> >> >> ...George >> >> >> >> >> >> >> >> >> >> >> >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >> >> >> >> > Neil, >> >> > >> >> > To your case 1, we're in complete agreement. We (VZ) don't see at >> >> > least a short-term need for peer-layer interworking, given where we >> >> > intend to deploy MPLS-TP in our infrastructure (as an internal server >> >> > layer in the transport core). If peer layer interworking ever becomes >> >> > a necessity, then obviously we'll need a well-defined E-NNI which >> >> > would include LSP identifier mapping/translation at the boundary, for >> >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such >> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to >> >> > put on the to-do list). This E-NNI would also include similar >> >> > identifier mapping/translation for MS-PWs, to answer an earlier >> >> > question from Erminio that I saw on the list. >> >> > >> >> > I also agree that both intra-layer and inter-layer mis-connectivity >> >> > detection and amelioration are required, but I'm not convinced that >> >> > the already defined mechanisms can't do that. Do you have some >> >> > specific analysis on the inter-layer case? >> >> > >> >> > Cheers, >> >> > Andy >> >> > >> >> > On Tue, May 3, 2011 at 3:36 AM, wrote: >> >> >> Hi Andy, >> >> >> >> >> >> 2 points: >> >> >> >> >> >> 1 I agree with your view of only having a single addressing scheme in >> a >> >> >> single layer network solely belonging to one party. Though you may >> >> need to >> >> >> be rather careful if you also advocate that one can also have peer >> layer >> >> >> interworking between different parties, ie E-NNIs (I believe this is >> >> >> something you may support, eg old MPLSF case?). In such a peer >> >> interworking >> >> >> case it would seem one must allow different addressing schemes (and >> >> indeed >> >> >> any other variations in DP/CP functional components) if they exist >> >> in the >> >> >> standards. >> >> >> >> >> >> Of course, having an E-NNI and peer interworking between different >> >> parties in >> >> >> any non-TOS layer network (not just MPLS) is not technically >> >> necessary (this >> >> >> is trivial to prove), and this provides a strong argument for only >> >> having a >> >> >> single addressing scheme in a non-TOS layer network. >> >> >> >> >> >> >> >> >> 2 You should also be aware that in client/server interworking of the >> >> >> co-ps mode using variable size traffic units, and therefore >> >> something rather >> >> >> important for MPLS-TP in the role of a transport network (I'll >> >> ignore issues >> >> >> of transparency here), there could be inter-layer misconnectivity >> >> (Aside=> >> >> >> This case cannot occur in the co-cs mode). To date, however, we have >> >> only >> >> >> really considered intra-layer misconnectivity, ie between different >> LSPs >> >> >> belonging to the same party (note this also includes all cases of >> >> nested LSP >> >> >> sublayer misconnectivity). >> >> >> >> >> >> In the case of inter-layer misconnectivity one may receive traffic >> >> units and >> >> >> OAM messages from some other party's layer network. The OAM >> messages >> may >> >> >> come from (i) networks using different OAM/addressing solutions or >> (ii) >> >> >> networks using the same OAM/addressing solutions. In both cases >> >> there are >> >> >> different issues wrt inter-layer misconnectivity one has to deal >> >> with. I'm >> >> >> not aware that these cases have been considered yet. >> >> >> >> >> >> >> >> >> I'd like to hear your comments on both these points, but in >> >> particular the >> >> >> first one.....especially if you also support the notion of E-NNIs in >> >> MPLS-TP, >> >> >> as there seems to a possible logical conflict here. >> >> >> >> >> >> Thanks. >> >> >> >> >> >> regards, 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. >> >> >> British Telecommunications plc >> >> >> Registered office: 81 Newgate Street London EC1A 7AJ >> >> >> Registered in England no: 1800000 >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> >> >>> Andrew G. Malis >> >> >>> Sent: 02 May 2011 20:48 >> >> >>> To: George Swallow >> >> >>> Cc: mpls@ietf.org >> >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> >>> >> >> >>> George et al, >> >> >>> >> >> >>> Verizon does not have any requirement for mixed use of Global IDs and >> >> >>> ICCs. We are fine with specifications that require both ends of an >> LSP >> >> >>> to use one or the other. >> >> >>> >> >> >>> Thanks, >> >> >>> Andy >> >> >>> >> >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >> >> >>> wrote: >> >> >>>> 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. >> >> >>>> >> >> >>>> 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. >> >> >>>> >> >> >>>> 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 >> >> >> >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > >> >-- >> > >> > >> >Loa Andersson email: loa.andersson@ericsson.com >> >Sr Strategy and Standards Manager loa@pi.nu >> >Ericsson Inc phone: +46 10 717 52 13 >> > +46 767 72 92 13 >> >_______________________________________________ >> >mpls mailing list >> >mpls@ietf.org >> >https://www.ietf.org/mailman/listinfo/mpls >> > >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > From erminio.ottone_69@libero.it Sun May 22 10:32:40 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 6F82EE06B4 for ; Sun, 22 May 2011 10:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=0.300, 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 F+7HqmpO7VZy for ; Sun, 22 May 2011 10:32:39 -0700 (PDT) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAB6E06AB for ; Sun, 22 May 2011 10:32:38 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020D.4DD948B2.00A0,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail53 (172.31.0.244) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD2374C006A7CC8; Sun, 22 May 2011 19:32:34 +0200 Message-ID: <15877149.2648481306085554217.JavaMail.root@wmail53> Date: Sun, 22 May 2011 19:32:34 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , Gregory Mirsky , "Malcolm.BETTS@zte.com.cn" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.30.164.217 Cc: "mpls@ietf.org" Subject: [mpls] R: RE: R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 17:32:40 -0000 If I understand correctly, you think that all the operators and all the devices MUST support both types of identifiers. This is not indicated in the draft. If the consensus is to mandate all the operators to support two types of identifiers, the draft needs to be updated to clarify this. >----Messaggio originale---- >Da: eric.gray@ericsson.com >Data: 20-mag-2011 18.19 >A: "erminio.ottone_69@libero.it", "Gregory Mirsky", "Malcolm.BETTS@zte.com.cn" >Cc: "mpls@ietf.org" >Ogg: RE: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >I cannot see how support for mixed identifier types is any >different from forcing both ICC and IP based operators to >support both types of identifiers. Moreover, in addition >to requiring the operators to do so, you effectively also >require every device in any operator's network to do so. > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of erminio.ottone_69@libero.it >Sent: Wednesday, May 18, 2011 5:00 PM >To: Gregory Mirsky; Malcolm.BETTS@zte.com.cn >Cc: mpls@ietf.org >Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >Well, I understand (and I agree) that it is possible to setup via NMS an LSP or >a MS-PW that crosses both IP-based and ICC-based domains even if there is no >e2e OAM. > >As this is possible, there is no realistic way to force the ICC-based >operators to support also IP-based identification nor viceversa. > >The issue is that the draft in its current form does not allow giving a name >to such an LSP or MS-PW. > >If you allow mixing IP-based and ICC-based identifiers for path ID (as >proposed by ITU-T), naming these LSPs/MS-PWs becomes very trivial. > >As I stated in another mail, I do not see any protocol implications on mixing >ICC and IP identifiers for path identification so it is not very clear what is >the technical issue in accepting the ITU-T comment at least for path >identification purposes. > >>----Messaggio originale---- >>Da: gregory.mirsky@ericsson.com >>Data: 3-mag-2011 0.31 >>A: "erminio.ottone_69@libero.it", "Malcolm. >BETTS@zte.com.cn" >>Cc: "mpls@ietf.org" >>Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >>Dear Erminio, >>I don't see an issue with NMS setting an LSP that crosses domains that >utilize different, IP-based and ICC-based, identifiers. The problem, as being >identified, in running e2e OAM on such LSP. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >erminio.ottone_69@libero.it >>Sent: Monday, May 02, 2011 2:58 PM >>To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn >>Cc: mpls@ietf.org; mpls-bounces@ietf.org >>Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >>Section 2.1.4 of RFC5860 states: >> >> For certain functions, OAM messages need to incorporate >> identification information (e.g., of source and/or destination >> nodes). The protocol solution(s) MUST at least support >> identification information in the form of an IP addressing structure >> and MUST also be extensible to support additional identification >> schemes. >> >>If an operator A supports IP-based identifiers and operator B supports ICC- >based identifiers, how can we setup a transport path (LSP or PW) between the >two operators? >> >> >>----Messaggio originale---- >>Da: gregimirsky@gmail.com >>Data: 28-apr-2011 1.11 >>A: >>Cc: "mpls@ietf.org", >>Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >>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 >>ToGeorge Swallow , "mpls@ietf.org" >>ccSubjectRe: [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 >> >> >> >> >> >>_______________________________________________ >>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 erminio.ottone_69@libero.it Sun May 22 10:32: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 11FAEE06E3 for ; Sun, 22 May 2011 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, 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 A+3Ot0sRdqWE for ; Sun, 22 May 2011 10:32:41 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64EE06B4 for ; Sun, 22 May 2011 10:32:40 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4DD94823.00D9,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail53 (172.31.0.244) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23D7C00711EDD; Sun, 22 May 2011 19:30:11 +0200 Message-ID: <22582378.2647991306085411289.JavaMail.root@wmail53> Date: Sun, 22 May 2011 19:30:11 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "rcallon@juniper.net" , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.30.164.217 Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 17:32:42 -0000 Let me try to understand your point. The draft has a major issue that has been identified (together wtih a propo= sed=20 resolution) more than one year ago. The MPLS WG did not reach agreement to resolve the issue as proposed withou= t=20 any technical justification. Therefore the MPLS WG will progress an incorre= ct=20 document. This is what I can understand from your reply. ----Messaggio originale---- Da: eric.gray@ericsson.com Data: 20-mag-2011 18.16 A: "erminio.ottone_69@libero.it",=20 "rcallon@juniper.net", "mpls@ietf.org" Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Never-the-less, the decision is clearly traceable to the fact that there is= no=20 consensus to change. A number of SDOs require this. The reason is obvious:= it=20 is always truethat one can construct an argument to change the direction of= =20 work inprogress, and - if we allowed each such argument to cause a change i= nthe=20 direction of the work in progress - we would never make progress. Hence the= re=20 must be agreement to change, not simply arguments thatsupport it. From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 erminio.ottone_69@libero.it Sent: Wednesday, May 18, 2011 4:54 PM To: rcallon@juniper.net; mpls@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? I am a bit surprised by the decision to cut such an important discussion. =20 While it is true that there is no (yet?) agreement on mixing of Global-IDs = and=20 ICC=E2=80=99s, the discussion has clarified that there are major holes both= in the=20 Requirements RFC (at least RFC5680) as well as in this document (which also= do=20 not fullfill the incomplete set of requirements of RFC5680). One of the argument against the proposal was the lack of requirements for= =20 supporting inter-domain LSP/PW. However, during the discussion it appeared = that=20 this scenario is required by RFC5680. As the draft in its current form does= not=20 address this scenario, it is clearly not fullfilling the requirements of=20 RFC5680, =20 There are other related issues which I am going to raise by replying to som= e=20 mails on this thread. ----Messaggio originale---- Da: rcallon@juniper.net Data: 18-mag-2011 20.40 A: "mpls@ietf.org" Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to change= =20 draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80= =99s for the=20 same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus= is=20 to leave the document as currently defined. The authors are therefore=20 instructed to continue progression of draft-ietf-mpls-tp-identifiers withou= t a=20 change in this area. =20 This decision neither supports nor precludes the possibility that at some= =20 point in the future, after draft-ietf-mpls-tp-identifiers is approved and= =20 published as an RFC, the WG might consider additional work to extend the MP= LS=20 protocols to allow mixed identifiers.=20 =20 Thanks, Ross and Loa (as MPLS WG chairs) =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= =20 this one document he is recused from his role as WG co-chair.] =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge=20 Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 not permitted. The ITU liaison requests that we allow mixed use. The authors of the draft are very reluctant to do this. =20 Obtaining an AS Number (from which the Global-ID is derived) is a fairly=20 trivial procedure. Many organizations if not most already have AS Numbers.= =20 Such an addition will add numerous object formats, and test cases. The exte= nt=20 inter-provider MPLS-TP is as yet unknown. If mixed modes of ICC and Global= -ID=20 identification is required, they can be added later. For signaled connectio= ns,=20 there is no plan to allow routing based on either the Global-ID or ICC. Th= at=20 would 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 need = to=20 run BGP and have AS numbers.=20 We are looking for input/consensus from the WG. George, Eric, & Matthew=20 From erminio.ottone_69@libero.it Sun May 22 10:37: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 100E6E0682; Sun, 22 May 2011 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Yxmq8V0q67Ba; Sun, 22 May 2011 10:37:27 -0700 (PDT) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by ietfa.amsl.com (Postfix) with ESMTP id B21FBE06BF; Sun, 22 May 2011 10:37:26 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0206.4DD949D0.008D,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail53 (172.31.0.244) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4DD23D7C00713017; Sun, 22 May 2011 19:37:19 +0200 Message-ID: <20950777.2649361306085839979.JavaMail.root@wmail53> Date: Sun, 22 May 2011 19:37:19 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , , Eric Gray MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.30.164.217 Cc: Ross Callon , mpls@ietf.org, mpls-bounces@ietf.org Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 17:37:28 -0000 As far as I know, mail posted on this mailing list as well as comments on t= he=20 drafts are considered "IETF contributions". There is an issue which has been identified one year ago and for which a=20 solution has been proposed. Many people objected against the proposed resolution w/o proposing a viable= =20 alternative. So the only reasonable solution I can see up to now is still t= he=20 one proposed by ITU-T. What is the value to write a I-D which duplicates the comment from ITU-T? ----Messaggio originale---- Da: yaacov.weingarten@nsn.com Data: 22-mag-2011 7.48 A: , "Eric Gray" Cc: "Ross Callon", , Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, hi =20 Borrowing the logic from other SDO's =E2=80=93 any standards work is contri= bution=20 driven =E2=80=93 if you or any of the other persons feel that they see a ne= ed to extend=20 the current draft with features that are not covered by the current work, t= hey=20 are able to write a new I-D that extends the functionality and details how = this=20 extension can be supported and whose responsibility (i.e. which MEP) it is = to=20 support all of the different formats. =20 Best regards, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= =20 Malcolm.BETTS@zte.com.cn Sent: Sunday, May 22, 2011 3:05 AM To: Eric Gray Cc: Ross Callon; mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Eric,=20 I find that argument somewhat circular since we did not have consensus to= =20 omit this.=20 Regards,=20 Malcolm=20 Eric Gray =20 20/05/2011 12:28 PM=20 To "Malcolm.BETTS@zte.com.cn" , Ross Callon=20 =20 cc "mpls@ietf.org" , "mpls-bounces@ietf.org" =20 Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Malcolm,=20 =20 As a co-author of the draft in question, I completely support this=20 decision.=20 =20 As I already explained to another person asking the same question, the= =20 bit about "no consensus to change" says it all.=20 =20 In my opinion, this is a quite sufficiently detailed response. The=20 absence=20 of a consensus to change means no change. We do not typically require a=20 strong consensus to continue on the current path.=20 =20 I am reasonably certain you apply similar rules yourself when working i= n=20 other SDOs.=20 =20 --=20 Eric=20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross,=20 I disappointed and, based on my reading of the emails on this thread,=20 surprised that this decision has been taken. Could you please elaborate on= the=20 reasoning behind this decision.=20 Regards,=20 Malcolm=20 Ross Callon =20 Sent by: mpls-bounces@ietf.org=20 18/05/2011 02:40 PM=20 =20 To "mpls@ietf.org" =20 cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 After discussion on the MPLS WG email list, there is no consensus to change= =20 draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80= =99s for the=20 same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus= is=20 to leave the document as currently defined. The authors are therefore=20 instructed to continue progression of draft-ietf-mpls-tp-identifiers withou= t a=20 change in this area.=20 =20 This decision neither supports nor precludes the possibility that at some= =20 point in the future, after draft-ietf-mpls-tp-identifiers is approved and= =20 published as an RFC, the WG might consider additional work to extend the MP= LS=20 protocols to allow mixed identifiers.=20 =20 Thanks,=20 Ross and Loa (as MPLS WG chairs)=20 =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= =20 this one document he is recused from his role as WG co-chair.]=20 =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge=20 Swallow Sent: Monday, April 25, 2011 5:17 PM To: mpls@ietf.org Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?=20 =20 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=20 end of an LSP. Currently the draft allows a Tunnel, LSP, PW, or MEG to use= =20 either the Global-ID for both ends or or the ICC for both ends. Mixed use = is=20 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= =20 fairly trivial procedure. Many organizations if not most already have AS= =20 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 mo= des=20 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=20 either the Global-ID or ICC. That would be a radical change to how IP work= s. =20 However for IP routing to work (in order to forward the signaling messages)= ,=20 the providers involved will need to run BGP and have AS numbers.=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 From jdrake@juniper.net Sun May 22 11:08:07 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 0C2E3E06E3; Sun, 22 May 2011 11:08:07 -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.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 oA20I6RlE3cC; Sun, 22 May 2011 11:08:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C3B94E064E; Sun, 22 May 2011 11:08:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTdlRAyl/xY1M1ASyM6WI/BFmrLQygV/b@postini.com; Sun, 22 May 2011 11:08:05 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; Sun, 22 May 2011 11:02:22 -0700 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" Date: Sun, 22 May 2011 11:01:15 -0700 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYqmWF3nASTOagS86pE0iBv/0l4w== Message-ID: <7D014F8E-AB13-4962-895C-B2479D3F9439@juniper.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Ross Callon , "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: Sun, 22 May 2011 18:08:07 -0000 TWFsY29tLA0KDQpNaXhlZCBpZGVudGlmaWVycyBhcmUgbm90IHBhcnQgb2YgdGhlIGRyYWZ0LiAg VGhlcmUgd2FzIG5vIGNvbnNlbnN1cyB0byBhZGQgdGhlbSB0byB0aGUgZHJhZnQuICBUaGVyZWZv cmUsIHRoZXkgd2lsbCBub3QgYmUgYWRkZWQgdG8gdGhlIGRyYWZ0LiAgV2hhdCBwYXJ0IG9mICdO bycgZG8geW91IG5vdCB1bmRlcnN0YW5kPw0KDQpBcyBhbiBhc2lkZSwgeW91IGhhdmUgYSBsb3Qg b2YgZ2FsbCBhdHRlbXB0aW5nIHRvIGp1ZGdlIGNvbnNlbnN1cy4NCg0KSm9obg0KDQpTZW50IGZy b20gbXkgaVBob25lDQoNCk9uIE1heSAyMSwgMjAxMSwgYXQgODowNSBQTSwgIk1hbGNvbG0uQkVU VFNAenRlLmNvbS5jbjxtYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPiIgPE1hbGNvbG0u QkVUVFNAenRlLmNvbS5jbjxtYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPj4gd3JvdGU6 DQoNCg0KRXJpYywNCg0KSSBmaW5kIHRoYXQgYXJndW1lbnQgc29tZXdoYXQgY2lyY3VsYXIgc2lu Y2UgIHdlIGRpZCBub3QgaGF2ZSBjb25zZW5zdXMgdG8gb21pdCB0aGlzLg0KDQpSZWdhcmRzLA0K DQpNYWxjb2xtDQoNCg0KDQpFcmljIEdyYXkgPGVyaWMuZ3JheUBlcmljc3Nvbi5jb208bWFpbHRv OmVyaWMuZ3JheUBlcmljc3Nvbi5jb20+Pg0KDQoyMC8wNS8yMDExIDEyOjI4IFBNDQoNCg0KVG8N CiAgICAgICAgIk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjxtYWlsdG86TWFsY29sbS5CRVRUU0B6 dGUuY29tLmNuPiIgPE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjxtYWlsdG86TWFsY29sbS5CRVRU U0B6dGUuY29tLmNuPj4sIFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PG1haWx0bzpy Y2FsbG9uQGp1bmlwZXIubmV0Pj4NCmNjDQogICAgICAgICJtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiwgIm1w bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiIgPG1wbHMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPj4NClN1YmplY3QN CiAgICAgICAgUkU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAg SWRlbnRpZmllcnM/DQoNCg0KDQoNCg0KDQoNCk1hbGNvbG0sDQoNCiAgICBBcyBhIGNvLWF1dGhv ciBvZiB0aGUgZHJhZnQgaW4gcXVlc3Rpb24sIEkgY29tcGxldGVseSBzdXBwb3J0IHRoaXMgZGVj aXNpb24uDQoNCiAgICBBcyBJIGFscmVhZHkgZXhwbGFpbmVkIHRvIGFub3RoZXIgcGVyc29uIGFz a2luZyB0aGUgc2FtZSBxdWVzdGlvbiwgdGhlDQpiaXQgYWJvdXQgIm5vIGNvbnNlbnN1cyB0byBj aGFuZ2UiIHNheXMgaXQgYWxsLg0KDQogICAgSW4gbXkgb3BpbmlvbiwgdGhpcyBpcyBhIHF1aXRl IHN1ZmZpY2llbnRseSBkZXRhaWxlZCByZXNwb25zZS4gIFRoZSBhYnNlbmNlDQpvZiBhIGNvbnNl bnN1cyB0byBjaGFuZ2UgbWVhbnMgbm8gY2hhbmdlLiAgV2UgZG8gbm90IHR5cGljYWxseSByZXF1 aXJlIGENCnN0cm9uZyBjb25zZW5zdXMgdG8gY29udGludWUgb24gdGhlIGN1cnJlbnQgcGF0aC4N Cg0KICAgIEkgYW0gcmVhc29uYWJseSBjZXJ0YWluIHlvdSBhcHBseSBzaW1pbGFyIHJ1bGVzIHlv dXJzZWxmIHdoZW4gd29ya2luZyBpbg0Kb3RoZXIgU0RPcy4NCg0KLS0NCkVyaWMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY248bWFpbHRvOk1hbGNvbG0uQkVU VFNAenRlLmNvbS5jbj4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMTksIDIwMTEgNDoyNSBBTQ0KVG86 IFJvc3MgQ2FsbG9uDQpDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUCBJ ZGVudGlmaWVycz8NCg0KDQpSb3NzLA0KDQpJIGRpc2FwcG9pbnRlZCBhbmQsIGJhc2VkIG9uIG15 IHJlYWRpbmcgb2YgdGhlIGVtYWlscyBvbiB0aGlzIHRocmVhZCwgc3VycHJpc2VkIHRoYXQgdGhp cyBkZWNpc2lvbiBoYXMgYmVlbiB0YWtlbi4gIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlIG9u IHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgZGVjaXNpb24uDQoNClJlZ2FyZHMsDQoNCk1hbGNv bG0NCg0KDQpSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBq dW5pcGVyLm5ldD4+DQpTZW50IGJ5OiA8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gbXBs cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQoNCjE4LzA1 LzIwMTEgMDI6NDAgUE0NCg0KVG8NCiAgICAgICAgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQpjYw0KDQpT dWJqZWN0DQogICAgICAgIFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBN UExTLVRQIElkZW50aWZpZXJzPw0KDQoNCg0KDQoNCg0KDQoNCg0KQWZ0ZXIgZGlzY3Vzc2lvbiBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0LCB0aGVyZSBpcyBubyBjb25zZW5zdXMgdG8gY2hhbmdl IGRyYWZ0LWlldGYtbXBscy10cC1pZGVudGlmaWVycyB0byBhbGxvdyBtaXhpbmcgb2YgR2xvYmFs LUlEcyBhbmQgSUND4oCZcyBmb3IgdGhlIHNhbWUgVHVubmVsLCBMU1AsIFBXLCBvciBTZWN0aW9u LiBJbnN0ZWFkLCB0aGUgKGFkbWl0dGVkbHkgcm91Z2gpIGNvbnNlbnN1cyBpcyB0byBsZWF2ZSB0 aGUgZG9jdW1lbnQgYXMgY3VycmVudGx5IGRlZmluZWQuIFRoZSBhdXRob3JzIGFyZSB0aGVyZWZv cmUgaW5zdHJ1Y3RlZCB0byBjb250aW51ZSBwcm9ncmVzc2lvbiBvZiBkcmFmdC1pZXRmLW1wbHMt dHAtaWRlbnRpZmllcnMgd2l0aG91dCBhIGNoYW5nZSBpbiB0aGlzIGFyZWEuDQoNClRoaXMgZGVj aXNpb24gbmVpdGhlciBzdXBwb3J0cyBub3IgcHJlY2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSB0aGF0 IGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZSwgYWZ0ZXIgZHJhZnQtaWV0Zi1tcGxzLXRwLWlk ZW50aWZpZXJzIGlzIGFwcHJvdmVkIGFuZCBwdWJsaXNoZWQgYXMgYW4gUkZDLCB0aGUgV0cgbWln aHQgY29uc2lkZXIgYWRkaXRpb25hbCB3b3JrIHRvIGV4dGVuZCB0aGUgTVBMUyBwcm90b2NvbHMg dG8gYWxsb3cgbWl4ZWQgaWRlbnRpZmllcnMuDQoNClRoYW5rcywNClJvc3MgYW5kIExvYSAoYXMg TVBMUyBXRyBjaGFpcnMpDQoNCltOb3RlIHRoYXQgc2luY2UgR2VvcmdlIGlzIGNvLWF1dGhvciBv ZiBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMsIGZvciB0aGlzIG9uZSBkb2N1bWVudCBo ZSBpcyByZWN1c2VkIGZyb20gaGlzIHJvbGUgYXMgV0cgY28tY2hhaXIuXQ0KDQoNCkZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnZSBTd2FsbG93DQpTZW50 OiBNb25kYXksIEFwcmlsIDI1LCAyMDExIDU6MTcgUE0NClRvOiA8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbXBsc10g TWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQIElkZW50aWZpZXJzPw0KDQpBbGwg LQ0KDQpNYW55IG9mIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBJVFUgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLWlkZW50aWZpZXJzLTA0IGhhdmUgdG8gZG8gd2l0aCB0aGUgR2xvYmFsIGFu ZCBJQ0MgaWRlbnRpZmllcnMuDQoNClRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBX LCBhbmQgTUVHIGluY2x1ZGUgZmllbGRzIHRvIGlkZW50aWZ5IGVhY2ggZW5kIG9mIGFuIExTUC4g IEN1cnJlbnRseSB0aGUgZHJhZnQgYWxsb3dzIGEgVHVubmVsLCBMU1AsIFBXLCBvciBNRUcgdG8g dXNlIGVpdGhlciB0aGUgR2xvYmFsLUlEIGZvciBib3RoIGVuZHMgb3Igb3IgdGhlIElDQyBmb3Ig Ym90aCBlbmRzLiAgTWl4ZWQgdXNlIGlzIG5vdCBwZXJtaXR0ZWQuDQoNClRoZSBJVFUgbGlhaXNv biByZXF1ZXN0cyB0aGF0IHdlIGFsbG93IG1peGVkIHVzZS4NCg0KVGhlIGF1dGhvcnMgb2YgdGhl IGRyYWZ0IGFyZSB2ZXJ5IHJlbHVjdGFudCB0byBkbyB0aGlzLg0KMS4gICAgICAgIE9idGFpbmlu ZyBhbiBBUyBOdW1iZXIgKGZyb20gd2hpY2ggdGhlIEdsb2JhbC1JRCBpcyBkZXJpdmVkKSBpcyBh IGZhaXJseSB0cml2aWFsIHByb2NlZHVyZS4gIE1hbnkgb3JnYW5pemF0aW9ucyBpZiBub3QgbW9z dCBhbHJlYWR5IGhhdmUgQVMgTnVtYmVycy4NCjIuICAgICAgICBTdWNoIGFuIGFkZGl0aW9uIHdp bGwgYWRkIG51bWVyb3VzIG9iamVjdCBmb3JtYXRzLCBhbmQgdGVzdCBjYXNlcy4NCjMuICAgICAg ICBUaGUgZXh0ZW50IGludGVyLXByb3ZpZGVyIE1QTFMtVFAgaXMgYXMgeWV0IHVua25vd24uICBJ ZiBtaXhlZCBtb2RlcyBvZiBJQ0MgYW5kIEdsb2JhbC1JRCBpZGVudGlmaWNhdGlvbiBpcyByZXF1 aXJlZCwgdGhleSBjYW4gYmUgYWRkZWQgbGF0ZXIuDQo0LiAgICAgICAgRm9yIHNpZ25hbGVkIGNv bm5lY3Rpb25zLCB0aGVyZSBpcyBubyBwbGFuIHRvIGFsbG93IHJvdXRpbmcgYmFzZWQgb24gZWl0 aGVyIHRoZSBHbG9iYWwtSUQgb3IgSUNDLiAgVGhhdCB3b3VsZCBiZSBhIHJhZGljYWwgY2hhbmdl IHRvIGhvdyBJUCB3b3Jrcy4gIEhvd2V2ZXIgZm9yIElQIHJvdXRpbmcgdG8gd29yayAoaW4gb3Jk ZXIgdG8gZm9yd2FyZCB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzKSwgdGhlIHByb3ZpZGVycyBpbnZv bHZlZCB3aWxsIG5lZWQgdG8gcnVuIEJHUCBhbmQgaGF2ZSBBUyBudW1iZXJzLg0KDQpXZSBhcmUg bG9va2luZyBmb3IgaW5wdXQvY29uc2Vuc3VzIGZyb20gdGhlIFdHLg0KDQpHZW9yZ2UsIEVyaWMs ICYgTWF0dGhldyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXBscyBtYWlsaW5nIGxpc3QNCjxtYWlsdG86bXBsc0BpZXRmLm9yZz5tcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K PEFUVDAwMDAxLi50eHQ+DQo= From huubatwork@gmail.com Sun May 22 11:37: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 E49F2E06BA for ; Sun, 22 May 2011 11:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 TnBbJcy+SFqT for ; Sun, 22 May 2011 11:37:07 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEEDE0696 for ; Sun, 22 May 2011 11:37:07 -0700 (PDT) Received: by eye13 with SMTP id 13so2125739eye.31 for ; Sun, 22 May 2011 11:37:06 -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=KYJVCLL9Rj/t3n/FsIdtQh7gRzkv/1CfgM2PxPLknCs=; b=Xg7+iKPcf5TH0p1lwwU+scNT4bN9bbXCZrSZNUq3p6LrgqL/aA458qPOJBbdP7fmem l/u9EpCDCaN5PIXPEudMwac2NQiqz2QeQtqnmoD8a3BC9spHOzMkJsP0xtpy/SSUq7+Z YDPIKfJi3qg51E0Vl2lUgCBI8ud3pKo+Ou7CQ= 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=Kgi+YjlQD2PQbQz61HwaiAeqCVdtwkBMItALXNWJ+olmdp649ikrcZv71H2xh1OzAu +GBTh8wsrHPJ896Bru7wnGq/IxLrlsXu8qBIOmca8+O0kZ5p10HxQ1fiivYVziASAsxe jW8ipeCQna/Iwm6nNr28gHws5UxBRYWjpWaDo= Received: by 10.14.0.11 with SMTP id 11mr561545eea.32.1306088119739; Sun, 22 May 2011 11:15:19 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id y5sm4099955eeh.13.2011.05.22.11.15.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 May 2011 11:15:18 -0700 (PDT) Message-ID: <4DD952B5.4040405@gmail.com> Date: Sun, 22 May 2011 20:15:17 +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: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> In-Reply-To: <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] R: Re: 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: Sun, 22 May 2011 18:37:09 -0000 Hi Adrian, See my response in-line [hvh] > We have already been round this loop on this list once. > Want to do it again? [hvh] If it helps to get to the focal point, why not. > As Huub said, this is about identifiers, not OAM. However, the model for OAM > interworking shows "layering" not gatewaying, and certainly not mixing. That is, > one end of the e2e path must be capable of operating both systems, but the other > does not need to. [hvh] OK if you mean "OAM toolsets" by "systems" > To extend this model to identifiers means that one end of the e2e path must > support both identifier formats and the other does not need to. [hvh] to be more specific the originating end of an e2e path must be able to support one of the possible identifier formats, normally the identifier format of the local operator. The terminating end and the intermediate points of an e2e path must be able to verify the format inserted at the origin independent of the locally used identifier format. This means that it must be possible to support different identifier formats in the A-->Z ans Z-->A direction of an e2e path. I.e. mixing of identifier formats must be supported. > This becomes particularly important to the transit nodes that may have to > inspect the identifiers. [hvh] the inspection will consist of comparing a received value with an expected value which can have any format. > None of this is new or specific to MPLS-TP. [hvh] I agree, mixing of identifier formats it not restricted to MPLS-TP. Regards, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> erminio.ottone_69@libero.it >> Sent: 18 May 2011 22:25 >> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >> >> Appendix II of Y.1731 provides a good example about how inter-domain >> connectivity with e2e OAM can be provided using transport-oriented OAM >> functions. >> >> You can download the latest version of Y.1731 (the pdr version is for free) at >> the following URL: >> >> http://www.itu.int/rec/T-REC-Y.1731/en >> >> It is a pity that with the current version of the identifier draft, MPLS-TP is >> not capable to support such a network scenario. >> >>> ----Messaggio originale---- >>> Da: loa@pi.nu >>> Data: 4-mag-2011 8.00 >>> A:, >> "Malcolm.BETTS@zte.com.cn" >>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>> >>> Malcolm, >>> >>> are you saying that operators today allow OAM to control node (MIPs and >>> MEPs) on each others networks? >>> >>> Do we have an operator that can verify this? >>> >>> /Loa >>> >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: >>>> >>>> All, >>>> >>>> I share your concerns and doubts about a multi carrier control plane. >>>> However, I think that it is essential that a transport network supports >>>> multi carrier data plane interconnection with end to end OAM. In today's >>>> transport network this interconnection is supported by SDH and OTN. The >>>> objective for MPLS-TP is to allow for packet based interconnection as >> well. >>>> >>>> Regards, >>>> >>>> Malcolm >>>> >>>> >>>> >>>> *George Swallow* >>>> Sent by: mpls-bounces@ietf.org >>>> >>>> 03/05/2011 11:09 AM >>>> >>>> >>>> To >>>> "Andrew G. Malis", >>>> cc >>>> mpls@ietf.org >>>> Subject >>>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Andy - >>>> >>>> > Such >>>> > an E-NNI definition does not yet exist for MPLS-TP (something else to >>>> > put on the to-do list). This E-NNI would also include similar >>>> > identifier mapping/translation for MS-PWs, to answer an earlier >>>> > question from Erminio that I saw on the list. >>>> >>>> You are quite correct here! I think much of this debate surrounds a >> problem >>>> that is yet to be solved. So there are arguments for pieces of a solution >>>> without and overall architecture. >>>> >>>> Based on all that I am seeing my inclination is to NOT say that we >> disallow >>>> mixed identifiers, but to say that they are for future study. >>>> >>>> ...George >>>> >>>> >>>> >>>> >>>> >>>> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: >>>> >>>> > Neil, >>>> > >>>> > To your case 1, we're in complete agreement. We (VZ) don't see at >>>> > least a short-term need for peer-layer interworking, given where we >>>> > intend to deploy MPLS-TP in our infrastructure (as an internal server >>>> > layer in the transport core). If peer layer interworking ever becomes >>>> > a necessity, then obviously we'll need a well-defined E-NNI which >>>> > would include LSP identifier mapping/translation at the boundary, for >>>> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such >>>> > an E-NNI definition does not yet exist for MPLS-TP (something else to >>>> > put on the to-do list). This E-NNI would also include similar >>>> > identifier mapping/translation for MS-PWs, to answer an earlier >>>> > question from Erminio that I saw on the list. >>>> > >>>> > I also agree that both intra-layer and inter-layer mis-connectivity >>>> > detection and amelioration are required, but I'm not convinced that >>>> > the already defined mechanisms can't do that. Do you have some >>>> > specific analysis on the inter-layer case? >>>> > >>>> > Cheers, >>>> > Andy >>>> > >>>> > On Tue, May 3, 2011 at 3:36 AM, wrote: >>>> >> Hi Andy, >>>> >> >>>> >> 2 points: >>>> >> >>>> >> 1 I agree with your view of only having a single addressing scheme in >> a >>>> >> single layer network solely belonging to one party. Though you may >>>> need to >>>> >> be rather careful if you also advocate that one can also have peer >> layer >>>> >> interworking between different parties, ie E-NNIs (I believe this is >>>> >> something you may support, eg old MPLSF case?). In such a peer >>>> interworking >>>> >> case it would seem one must allow different addressing schemes (and >>>> indeed >>>> >> any other variations in DP/CP functional components) if they exist >>>> in the >>>> >> standards. >>>> >> >>>> >> Of course, having an E-NNI and peer interworking between different >>>> parties in >>>> >> any non-TOS layer network (not just MPLS) is not technically >>>> necessary (this >>>> >> is trivial to prove), and this provides a strong argument for only >>>> having a >>>> >> single addressing scheme in a non-TOS layer network. >>>> >> >>>> >> >>>> >> 2 You should also be aware that in client/server interworking of the >>>> >> co-ps mode using variable size traffic units, and therefore >>>> something rather >>>> >> important for MPLS-TP in the role of a transport network (I'll >>>> ignore issues >>>> >> of transparency here), there could be inter-layer misconnectivity >>>> (Aside=> >>>> >> This case cannot occur in the co-cs mode). To date, however, we have >>>> only >>>> >> really considered intra-layer misconnectivity, ie between different >> LSPs >>>> >> belonging to the same party (note this also includes all cases of >>>> nested LSP >>>> >> sublayer misconnectivity). >>>> >> >>>> >> In the case of inter-layer misconnectivity one may receive traffic >>>> units and >>>> >> OAM messages from some other party's layer network. The OAM >> messages >> may >>>> >> come from (i) networks using different OAM/addressing solutions or >> (ii) >>>> >> networks using the same OAM/addressing solutions. In both cases >>>> there are >>>> >> different issues wrt inter-layer misconnectivity one has to deal >>>> with. I'm >>>> >> not aware that these cases have been considered yet. >>>> >> >>>> >> >>>> >> I'd like to hear your comments on both these points, but in >>>> particular the >>>> >> first one.....especially if you also support the notion of E-NNIs in >>>> MPLS-TP, >>>> >> as there seems to a possible logical conflict here. >>>> >> >>>> >> Thanks. >>>> >> >>>> >> regards, 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. >>>> >> British Telecommunications plc >>>> >> Registered office: 81 Newgate Street London EC1A 7AJ >>>> >> Registered in England no: 1800000 >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>>> >>> Andrew G. Malis >>>> >>> Sent: 02 May 2011 20:48 >>>> >>> To: George Swallow >>>> >>> Cc: mpls@ietf.org >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? >>>> >>> >>>> >>> George et al, >>>> >>> >>>> >>> Verizon does not have any requirement for mixed use of Global IDs and >>>> >>> ICCs. We are fine with specifications that require both ends of an >> LSP >>>> >>> to use one or the other. >>>> >>> >>>> >>> Thanks, >>>> >>> Andy >>>> >>> >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow >>>> >>> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> We are looking for input/consensus from the WG. >>>> >>>> >>>> >>>> George, Eric,& Matthew -- ***************************************************************** ๆˆ‘็ˆฑๅค–็‚นไธ€ไธƒไธ‰ไธ€ From neil.2.harrison@bt.com Sun May 22 12:36: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 CE7E7E066A for ; Sun, 22 May 2011 12:36:59 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM4zQpUoNKf0 for ; Sun, 22 May 2011 12:36:58 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39EE0651 for ; Sun, 22 May 2011 12:36:58 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 22 May 2011 20:35:51 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.41]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Sun, 22 May 2011 20:35:50 +0100 From: To: , Date: Sun, 22 May 2011 20:35:48 +0100 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYr08r50q06GG8R5+xsw4O/HtJfgABu7ug Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> In-Reply-To: <4DD952B5.4040405@gmail.com> 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] R: Re: 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: Sun, 22 May 2011 19:36:59 -0000 SGkgQWRyaWFuL0h1dWIsDQoNCllvdSBhcmUgbGFyZ2VseSBhc3N1bWluZyBzb21lIGZvcm0gb2Yg cGVlcmluZyAoc2luZ2xlIHBhcnRpdGlvbmVkIGxheWVyIG5ldHdvcmspIGhlcmUuLi5hbmQgdGhh dCBtb2RlbCB3aWxsIGdlbmVyYXRlIGEgd2hvbGUgcmFmdCBvZiBwcm9ibGVtcyBmb3Igb3BlcmF0 b3JzIElNTy4gIEEgbW9yZSBpbXBvcnRhbnQgbW9kZWwgZm9yIGEgY28tcHMgdHJhbnNwb3J0IG5l dHdvcmsgaXMgY2xpZW50L3NlcnZlci4gIEFuZCBub3cgbm90IG9ubHkgaGF2ZSB3ZSB0aGUgdXN1 YWwgaW50cmEtbGF5ZXIgbWlzY29ubmVjdGl2aXR5IHRvIGRlYWwgd2l0aCBidXQgd2UgYWxzbyBo YXZlIGludGVyLWxheWVyIG1pc2Nvbm5lY3Rpdml0eS4uLmFuZCB0aGlzIG1lYW5zIGVhY2ggb3Bl cmF0aW5nIHBhcnR5IG11c3QgdW5kZXJzdGFuZCB0aGUgT0FNIGZvcm1hdHMgKGFuZCBDViBJRHMp IG9mIGVhY2ggb3RoZXIgYW55d2F5Li4uIG5vdCBzaW1wbHkgdG8gZGV0ZWN0IHRoZXJlIGlzIGEg bWlzY29ubmVjdGl2aXR5IHByb2JsZW1zIGJ1dCBhbHNvIHRvIGlkZW50aWZ5IHdoaWNoIG90aGVy IHBhcnRpZXMgYXJlIGludm9sdmVkLg0KDQpyZWdhcmRzLCBOZWlsDQoNCkJUIERlc2lnbg0KVGhp cyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3IgY29uZmlkZW50aWFsLg0KSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBv ciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGll bnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcg dGhpcyBpbmZvcm1hdGlvbg0KaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseQ0Kb24gdGhlIGVt YWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCldlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3Rl bSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMuDQpCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9u cyBwbGMNClJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3 QUoNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBIdXViIHZhbiBIZWx2b29ydA0K PiBTZW50OiAyMiBNYXkgMjAxMSAxOToxNQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFAN Cj4gSWRlbnRpZmllcnM/DQo+IA0KPiBIaSBBZHJpYW4sDQo+IA0KPiBTZWUgbXkgcmVzcG9uc2Ug aW4tbGluZSBbaHZoXQ0KPiANCj4gPiBXZSBoYXZlIGFscmVhZHkgYmVlbiByb3VuZCB0aGlzIGxv b3Agb24gdGhpcyBsaXN0IG9uY2UuDQo+ID4gV2FudCB0byBkbyBpdCBhZ2Fpbj8NCj4gDQo+IFto dmhdIElmIGl0IGhlbHBzIHRvIGdldCB0byB0aGUgZm9jYWwgcG9pbnQsIHdoeSBub3QuDQo+IA0K PiA+IEFzIEh1dWIgc2FpZCwgdGhpcyBpcyBhYm91dCBpZGVudGlmaWVycywgbm90IE9BTS4gSG93 ZXZlciwgdGhlIG1vZGVsDQo+IGZvciBPQU0NCj4gPiBpbnRlcndvcmtpbmcgc2hvd3MgImxheWVy aW5nIiBub3QgZ2F0ZXdheWluZywgYW5kIGNlcnRhaW5seSBub3QNCj4gbWl4aW5nLiBUaGF0IGlz LA0KPiA+IG9uZSBlbmQgb2YgdGhlIGUyZSBwYXRoIG11c3QgYmUgY2FwYWJsZSBvZiBvcGVyYXRp bmcgYm90aCBzeXN0ZW1zLA0KPiBidXQgdGhlIG90aGVyDQo+ID4gZG9lcyBub3QgbmVlZCB0by4N Cj4gDQo+IFtodmhdIE9LIGlmIHlvdSBtZWFuICJPQU0gdG9vbHNldHMiIGJ5ICJzeXN0ZW1zIg0K PiANCj4gPiBUbyBleHRlbmQgdGhpcyBtb2RlbCB0byBpZGVudGlmaWVycyBtZWFucyB0aGF0IG9u ZSBlbmQgb2YgdGhlIGUyZQ0KPiBwYXRoIG11c3QNCj4gPiBzdXBwb3J0IGJvdGggaWRlbnRpZmll ciBmb3JtYXRzIGFuZCB0aGUgb3RoZXIgZG9lcyBub3QgbmVlZCB0by4NCj4gDQo+IFtodmhdIHRv IGJlIG1vcmUgc3BlY2lmaWMgdGhlIG9yaWdpbmF0aW5nIGVuZCBvZiBhbiBlMmUgcGF0aCBtdXN0 DQo+IGJlIGFibGUgdG8gc3VwcG9ydCBvbmUgb2YgdGhlIHBvc3NpYmxlIGlkZW50aWZpZXIgZm9y bWF0cywgbm9ybWFsbHkNCj4gdGhlIGlkZW50aWZpZXIgZm9ybWF0IG9mIHRoZSBsb2NhbCBvcGVy YXRvci4gVGhlIHRlcm1pbmF0aW5nIGVuZCBhbmQNCj4gdGhlIGludGVybWVkaWF0ZSBwb2ludHMg b2YgYW4gZTJlIHBhdGggbXVzdCBiZSBhYmxlIHRvIHZlcmlmeSB0aGUNCj4gZm9ybWF0IGluc2Vy dGVkIGF0IHRoZSBvcmlnaW4gaW5kZXBlbmRlbnQgb2YgdGhlIGxvY2FsbHkgdXNlZA0KPiBpZGVu dGlmaWVyDQo+IGZvcm1hdC4gVGhpcyBtZWFucyB0aGF0IGl0IG11c3QgYmUgcG9zc2libGUgdG8g c3VwcG9ydCBkaWZmZXJlbnQNCj4gaWRlbnRpZmllciBmb3JtYXRzIGluIHRoZSBBLS0+WiBhbnMg Wi0tPkEgZGlyZWN0aW9uIG9mIGFuIGUyZSBwYXRoLg0KPiBJLmUuIG1peGluZyBvZiBpZGVudGlm aWVyIGZvcm1hdHMgbXVzdCBiZSBzdXBwb3J0ZWQuDQo+IA0KPiA+IFRoaXMgYmVjb21lcyBwYXJ0 aWN1bGFybHkgaW1wb3J0YW50IHRvIHRoZSB0cmFuc2l0IG5vZGVzIHRoYXQgbWF5DQo+IGhhdmUg dG8NCj4gPiBpbnNwZWN0IHRoZSBpZGVudGlmaWVycy4NCj4gDQo+IFtodmhdIHRoZSBpbnNwZWN0 aW9uIHdpbGwgY29uc2lzdCBvZiBjb21wYXJpbmcgYSByZWNlaXZlZCB2YWx1ZQ0KPiB3aXRoIGFu IGV4cGVjdGVkIHZhbHVlIHdoaWNoIGNhbiBoYXZlIGFueSBmb3JtYXQuDQo+IA0KPiA+IE5vbmUg b2YgdGhpcyBpcyBuZXcgb3Igc3BlY2lmaWMgdG8gTVBMUy1UUC4NCj4gDQo+IFtodmhdIEkgYWdy ZWUsIG1peGluZyBvZiBpZGVudGlmaWVyIGZvcm1hdHMgaXQgbm90IHJlc3RyaWN0ZWQgdG8NCj4g TVBMUy1UUC4NCj4gDQo+IFJlZ2FyZHMsIEh1dWIuDQo+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+PiBlcm1pbmlvLm90dG9uZV82 OUBsaWJlcm8uaXQNCj4gPj4gU2VudDogMTggTWF5IDIwMTEgMjI6MjUNCj4gPj4gVG86IGxvYUBw aS5udTsgbXBsc0BpZXRmLm9yZzsgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuDQo+ID4+IFN1Ympl Y3Q6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ IElkZW50aWZpZXJzPw0KPiA+Pg0KPiA+PiBBcHBlbmRpeCBJSSBvZiBZLjE3MzEgcHJvdmlkZXMg YSBnb29kIGV4YW1wbGUgYWJvdXQgaG93IGludGVyLWRvbWFpbg0KPiA+PiBjb25uZWN0aXZpdHkg d2l0aCBlMmUgT0FNIGNhbiBiZSBwcm92aWRlZCB1c2luZyB0cmFuc3BvcnQtb3JpZW50ZWQNCj4g T0FNDQo+ID4+IGZ1bmN0aW9ucy4NCj4gPj4NCj4gPj4gWW91IGNhbiBkb3dubG9hZCB0aGUgbGF0 ZXN0IHZlcnNpb24gb2YgWS4xNzMxICh0aGUgcGRyIHZlcnNpb24gaXMNCj4gZm9yIGZyZWUpIGF0 DQo+ID4+IHRoZSBmb2xsb3dpbmcgVVJMOg0KPiA+Pg0KPiA+PiBodHRwOi8vd3d3Lml0dS5pbnQv cmVjL1QtUkVDLVkuMTczMS9lbg0KPiA+Pg0KPiA+PiBJdCBpcyBhIHBpdHkgdGhhdCB3aXRoIHRo ZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGlkZW50aWZpZXIgZHJhZnQsDQo+IE1QTFMtVFAgaXMN Cj4gPj4gbm90IGNhcGFibGUgdG8gc3VwcG9ydCBzdWNoIGEgbmV0d29yayBzY2VuYXJpby4NCj4g Pj4NCj4gPj4+IC0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLQ0KPiA+Pj4gRGE6IGxvYUBwaS5u dQ0KPiA+Pj4gRGF0YTogNC1tYWctMjAxMSA4LjAwDQo+ID4+PiBBOjxtcGxzQGlldGYub3JnPiwN Cj4gPj4gIk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiI8TWFsY29sbS5CRVRUU0B6dGUuY29tLmNu Pg0KPiA+Pj4gT2dnOiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBM Uy1UUCBJZGVudGlmaWVycz8NCj4gPj4+DQo+ID4+PiBNYWxjb2xtLA0KPiA+Pj4NCj4gPj4+IGFy ZSB5b3Ugc2F5aW5nIHRoYXQgb3BlcmF0b3JzIHRvZGF5IGFsbG93IE9BTSB0byBjb250cm9sIG5v ZGUgKE1JUHMNCj4gYW5kDQo+ID4+PiBNRVBzKSBvbiBlYWNoIG90aGVycyBuZXR3b3Jrcz8NCj4g Pj4+DQo+ID4+PiBEbyB3ZSBoYXZlIGFuIG9wZXJhdG9yIHRoYXQgY2FuIHZlcmlmeSB0aGlzPw0K PiA+Pj4NCj4gPj4+IC9Mb2ENCj4gPj4+DQo+ID4+PiBPbiAyMDExLTA1LTAzIDIyOjQ0LCBNYWxj b2xtLkJFVFRTQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBBbGwsDQo+ID4+Pj4N Cj4gPj4+PiBJIHNoYXJlIHlvdXIgY29uY2VybnMgYW5kIGRvdWJ0cyBhYm91dCBhIG11bHRpIGNh cnJpZXIgY29udHJvbA0KPiBwbGFuZS4NCj4gPj4+PiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgaXQg aXMgZXNzZW50aWFsIHRoYXQgYSB0cmFuc3BvcnQgbmV0d29yaw0KPiBzdXBwb3J0cw0KPiA+Pj4+ IG11bHRpIGNhcnJpZXIgZGF0YSBwbGFuZSBpbnRlcmNvbm5lY3Rpb24gd2l0aCBlbmQgdG8gZW5k IE9BTS4gSW4NCj4gdG9kYXkncw0KPiA+Pj4+IHRyYW5zcG9ydCBuZXR3b3JrIHRoaXMgaW50ZXJj b25uZWN0aW9uIGlzIHN1cHBvcnRlZCBieSBTREggYW5kDQo+IE9UTi4gVGhlDQo+ID4+Pj4gb2Jq ZWN0aXZlIGZvciBNUExTLVRQIGlzIHRvIGFsbG93IGZvciBwYWNrZXQgYmFzZWQgaW50ZXJjb25u ZWN0aW9uDQo+IGFzDQo+ID4+IHdlbGwuDQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzLA0KPiA+Pj4+ DQo+ID4+Pj4gTWFsY29sbQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICpHZW9yZ2Ug U3dhbGxvdzxzd2FsbG93QGNpc2NvLmNvbT4qDQo+ID4+Pj4gU2VudCBieTogbXBscy1ib3VuY2Vz QGlldGYub3JnDQo+ID4+Pj4NCj4gPj4+PiAwMy8wNS8yMDExIDExOjA5IEFNDQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4+IFRvDQo+ID4+Pj4gCSJBbmRyZXcgRy4gTWFsaXMiPGFnbWFsaXNAZ21haWwu Y29tPiw8bmVpbC4yLmhhcnJpc29uQGJ0LmNvbT4NCj4gPj4+PiBjYw0KPiA+Pj4+IAltcGxzQGll dGYub3JnDQo+ID4+Pj4gU3ViamVjdA0KPiA+Pj4+IAlSZTogW21wbHNdIE1peGluZyBJQ0MgYW5k IEdsb2JhbC1JRHMgaW4gTVBMUy1UUCBJZGVudGlmaWVycz8NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gQW5keSAt DQo+ID4+Pj4NCj4gPj4+PiAgID4gIFN1Y2gNCj4gPj4+PiAgID4gIGFuIEUtTk5JIGRlZmluaXRp b24gZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQIChzb21ldGhpbmcNCj4gZWxzZSB0bw0K PiA+Pj4+ICAgPiAgcHV0IG9uIHRoZSB0by1kbyBsaXN0KS4gVGhpcyBFLU5OSSB3b3VsZCBhbHNv IGluY2x1ZGUgc2ltaWxhcg0KPiA+Pj4+ICAgPiAgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0 aW9uIGZvciBNUy1QV3MsIHRvIGFuc3dlciBhbg0KPiBlYXJsaWVyDQo+ID4+Pj4gICA+ICBxdWVz dGlvbiBmcm9tIEVybWluaW8gdGhhdCBJIHNhdyBvbiB0aGUgbGlzdC4NCj4gPj4+Pg0KPiA+Pj4+ IFlvdSBhcmUgcXVpdGUgY29ycmVjdCBoZXJlISBJIHRoaW5rIG11Y2ggb2YgdGhpcyBkZWJhdGUg c3Vycm91bmRzDQo+IGENCj4gPj4gcHJvYmxlbQ0KPiA+Pj4+IHRoYXQgaXMgeWV0IHRvIGJlIHNv bHZlZC4gU28gdGhlcmUgYXJlIGFyZ3VtZW50cyBmb3IgcGllY2VzIG9mIGENCj4gc29sdXRpb24N Cj4gPj4+PiB3aXRob3V0IGFuZCBvdmVyYWxsIGFyY2hpdGVjdHVyZS4NCj4gPj4+Pg0KPiA+Pj4+ IEJhc2VkIG9uIGFsbCB0aGF0IEkgYW0gc2VlaW5nIG15IGluY2xpbmF0aW9uIGlzIHRvIE5PVCBz YXkgdGhhdCB3ZQ0KPiA+PiBkaXNhbGxvdw0KPiA+Pj4+IG1peGVkIGlkZW50aWZpZXJzLCBidXQg dG8gc2F5IHRoYXQgdGhleSBhcmUgZm9yIGZ1dHVyZSBzdHVkeS4NCj4gPj4+Pg0KPiA+Pj4+IC4u Lkdlb3JnZQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBP biA1LzMvMTEgODozOCBBTSwgIkFuZHJldyBHLiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+ICB3 cm90ZToNCj4gPj4+Pg0KPiA+Pj4+ICAgPiAgTmVpbCwNCj4gPj4+PiAgID4NCj4gPj4+PiAgID4g IFRvIHlvdXIgY2FzZSAxLCB3ZSdyZSBpbiBjb21wbGV0ZSBhZ3JlZW1lbnQuIFdlIChWWikgZG9u J3QNCj4gc2VlIGF0DQo+ID4+Pj4gICA+ICBsZWFzdCBhIHNob3J0LXRlcm0gbmVlZCBmb3IgcGVl ci1sYXllciBpbnRlcndvcmtpbmcsIGdpdmVuDQo+IHdoZXJlIHdlDQo+ID4+Pj4gICA+ICBpbnRl bmQgdG8gZGVwbG95IE1QTFMtVFAgaW4gb3VyIGluZnJhc3RydWN0dXJlIChhcyBhbg0KPiBpbnRl cm5hbCBzZXJ2ZXINCj4gPj4+PiAgID4gIGxheWVyIGluIHRoZSB0cmFuc3BvcnQgY29yZSkuIElm IHBlZXIgbGF5ZXIgaW50ZXJ3b3JraW5nIGV2ZXINCj4gYmVjb21lcw0KPiA+Pj4+ICAgPiAgYSBu ZWNlc3NpdHksIHRoZW4gb2J2aW91c2x5IHdlJ2xsIG5lZWQgYSB3ZWxsLWRlZmluZWQgRS1OTkkN Cj4gd2hpY2gNCj4gPj4+PiAgID4gIHdvdWxkIGluY2x1ZGUgTFNQIGlkZW50aWZpZXIgbWFwcGlu Zy90cmFuc2xhdGlvbiBhdCB0aGUNCj4gYm91bmRhcnksIGZvcg0KPiA+Pj4+ICAgPiAgTFNQIHBy b3Zpc2lvbmluZyAod2hldGhlciBzdGF0aWMgb3IgZHluYW1pYykgYW5kIGVuZC10by1lbmQNCj4g T0FNLiBTdWNoDQo+ID4+Pj4gICA+ICBhbiBFLU5OSSBkZWZpbml0aW9uIGRvZXMgbm90IHlldCBl eGlzdCBmb3IgTVBMUy1UUCAoc29tZXRoaW5nDQo+IGVsc2UgdG8NCj4gPj4+PiAgID4gIHB1dCBv biB0aGUgdG8tZG8gbGlzdCkuIFRoaXMgRS1OTkkgd291bGQgYWxzbyBpbmNsdWRlIHNpbWlsYXIN Cj4gPj4+PiAgID4gIGlkZW50aWZpZXIgbWFwcGluZy90cmFuc2xhdGlvbiBmb3IgTVMtUFdzLCB0 byBhbnN3ZXIgYW4NCj4gZWFybGllcg0KPiA+Pj4+ICAgPiAgcXVlc3Rpb24gZnJvbSBFcm1pbmlv IHRoYXQgSSBzYXcgb24gdGhlIGxpc3QuDQo+ID4+Pj4gICA+DQo+ID4+Pj4gICA+ICBJIGFsc28g YWdyZWUgdGhhdCBib3RoIGludHJhLWxheWVyIGFuZCBpbnRlci1sYXllciBtaXMtDQo+IGNvbm5l Y3Rpdml0eQ0KPiA+Pj4+ICAgPiAgZGV0ZWN0aW9uIGFuZCBhbWVsaW9yYXRpb24gYXJlIHJlcXVp cmVkLCBidXQgSSdtIG5vdA0KPiBjb252aW5jZWQgdGhhdA0KPiA+Pj4+ICAgPiAgdGhlIGFscmVh ZHkgZGVmaW5lZCBtZWNoYW5pc21zIGNhbid0IGRvIHRoYXQuIERvIHlvdSBoYXZlDQo+IHNvbWUN Cj4gPj4+PiAgID4gIHNwZWNpZmljIGFuYWx5c2lzIG9uIHRoZSBpbnRlci1sYXllciBjYXNlPw0K PiA+Pj4+ICAgPg0KPiA+Pj4+ICAgPiAgQ2hlZXJzLA0KPiA+Pj4+ICAgPiAgQW5keQ0KPiA+Pj4+ ICAgPg0KPiA+Pj4+ICAgPiAgT24gVHVlLCBNYXkgMywgMjAxMSBhdCAzOjM2IEFNLDxuZWlsLjIu aGFycmlzb25AYnQuY29tPg0KPiB3cm90ZToNCj4gPj4+PiAgID4+ICBIaSBBbmR5LA0KPiA+Pj4+ ICAgPj4NCj4gPj4+PiAgID4+ICAyIHBvaW50czoNCj4gPj4+PiAgID4+DQo+ID4+Pj4gICA+PiAg MSBJIGFncmVlIHdpdGggeW91ciB2aWV3IG9mIG9ubHkgaGF2aW5nIGEgc2luZ2xlIGFkZHJlc3Np bmcNCj4gc2NoZW1lIGluDQo+ID4+IGENCj4gPj4+PiAgID4+ICBzaW5nbGUgbGF5ZXIgbmV0d29y ayBzb2xlbHkgYmVsb25naW5nIHRvIG9uZSBwYXJ0eS4gVGhvdWdoDQo+IHlvdSBtYXkNCj4gPj4+ PiBuZWVkIHRvDQo+ID4+Pj4gICA+PiAgYmUgcmF0aGVyIGNhcmVmdWwgaWYgeW91IGFsc28gYWR2 b2NhdGUgdGhhdCBvbmUgY2FuIGFsc28NCj4gaGF2ZSBwZWVyDQo+ID4+IGxheWVyDQo+ID4+Pj4g ICA+PiAgaW50ZXJ3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IHBhcnRpZXMsIGllIEUtTk5JcyAo SSBiZWxpZXZlDQo+IHRoaXMgaXMNCj4gPj4+PiAgID4+ICBzb21ldGhpbmcgeW91IG1heSBzdXBw b3J0LCBlZyBvbGQgTVBMU0YgY2FzZT8pLiBJbiBzdWNoIGENCj4gcGVlcg0KPiA+Pj4+IGludGVy d29ya2luZw0KPiA+Pj4+ICAgPj4gIGNhc2UgaXQgd291bGQgc2VlbSBvbmUgbXVzdCBhbGxvdyBk aWZmZXJlbnQgYWRkcmVzc2luZw0KPiBzY2hlbWVzIChhbmQNCj4gPj4+PiBpbmRlZWQNCj4gPj4+ PiAgID4+ICBhbnkgb3RoZXIgdmFyaWF0aW9ucyBpbiBEUC9DUCBmdW5jdGlvbmFsIGNvbXBvbmVu dHMpIGlmIHRoZXkNCj4gZXhpc3QNCj4gPj4+PiBpbiB0aGUNCj4gPj4+PiAgID4+ICBzdGFuZGFy ZHMuDQo+ID4+Pj4gICA+Pg0KPiA+Pj4+ICAgPj4gIE9mIGNvdXJzZSwgaGF2aW5nIGFuIEUtTk5J IGFuZCBwZWVyIGludGVyd29ya2luZyBiZXR3ZWVuDQo+IGRpZmZlcmVudA0KPiA+Pj4+IHBhcnRp ZXMgaW4NCj4gPj4+PiAgID4+ICBhbnkgbm9uLVRPUyBsYXllciBuZXR3b3JrIChub3QganVzdCBN UExTKSBpcyBub3QgdGVjaG5pY2FsbHkNCj4gPj4+PiBuZWNlc3NhcnkgKHRoaXMNCj4gPj4+PiAg ID4+ICBpcyB0cml2aWFsIHRvIHByb3ZlKSwgYW5kIHRoaXMgcHJvdmlkZXMgYSBzdHJvbmcgYXJn dW1lbnQNCj4gZm9yIG9ubHkNCj4gPj4+PiBoYXZpbmcgYQ0KPiA+Pj4+ICAgPj4gIHNpbmdsZSBh ZGRyZXNzaW5nIHNjaGVtZSBpbiBhIG5vbi1UT1MgbGF5ZXIgbmV0d29yay4NCj4gPj4+PiAgID4+ DQo+ID4+Pj4gICA+Pg0KPiA+Pj4+ICAgPj4gIDIgWW91IHNob3VsZCBhbHNvIGJlIGF3YXJlIHRo YXQgaW4gY2xpZW50L3NlcnZlcg0KPiBpbnRlcndvcmtpbmcgb2YgdGhlDQo+ID4+Pj4gICA+PiAg Y28tcHMgbW9kZSB1c2luZyB2YXJpYWJsZSBzaXplIHRyYWZmaWMgdW5pdHMsIGFuZCB0aGVyZWZv cmUNCj4gPj4+PiBzb21ldGhpbmcgcmF0aGVyDQo+ID4+Pj4gICA+PiAgaW1wb3J0YW50IGZvciBN UExTLVRQIGluIHRoZSByb2xlIG9mIGEgdHJhbnNwb3J0IG5ldHdvcmsNCj4gKEknbGwNCj4gPj4+ PiBpZ25vcmUgaXNzdWVzDQo+ID4+Pj4gICA+PiAgb2YgdHJhbnNwYXJlbmN5IGhlcmUpLCB0aGVy ZSBjb3VsZCBiZSBpbnRlci1sYXllcg0KPiBtaXNjb25uZWN0aXZpdHkNCj4gPj4+PiAoQXNpZGU9 Pg0KPiA+Pj4+ICAgPj4gIFRoaXMgY2FzZSBjYW5ub3Qgb2NjdXIgaW4gdGhlIGNvLWNzIG1vZGUp LiBUbyBkYXRlLCBob3dldmVyLA0KPiB3ZSBoYXZlDQo+ID4+Pj4gb25seQ0KPiA+Pj4+ICAgPj4g IHJlYWxseSBjb25zaWRlcmVkIGludHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSwgaWUgYmV0d2Vl bg0KPiBkaWZmZXJlbnQNCj4gPj4gTFNQcw0KPiA+Pj4+ICAgPj4gIGJlbG9uZ2luZyB0byB0aGUg c2FtZSBwYXJ0eSAobm90ZSB0aGlzIGFsc28gaW5jbHVkZXMgYWxsDQo+IGNhc2VzIG9mDQo+ID4+ Pj4gbmVzdGVkIExTUA0KPiA+Pj4+ICAgPj4gIHN1YmxheWVyIG1pc2Nvbm5lY3Rpdml0eSkuDQo+ ID4+Pj4gICA+Pg0KPiA+Pj4+ICAgPj4gIEluIHRoZSBjYXNlIG9mIGludGVyLWxheWVyIG1pc2Nv bm5lY3Rpdml0eSBvbmUgbWF5IHJlY2VpdmUNCj4gdHJhZmZpYw0KPiA+Pj4+IHVuaXRzIGFuZA0K PiA+Pj4+ICAgPj4gIE9BTSBtZXNzYWdlcyBmcm9tIHNvbWUgb3RoZXIgcGFydHkncyBsYXllciBu ZXR3b3JrLiBUaGUgT0FNDQo+ID4+IG1lc3NhZ2VzDQo+ID4+IG1heQ0KPiA+Pj4+ICAgPj4gIGNv bWUgZnJvbSAoaSkgbmV0d29ya3MgdXNpbmcgZGlmZmVyZW50IE9BTS9hZGRyZXNzaW5nDQo+IHNv bHV0aW9ucyBvcg0KPiA+PiAoaWkpDQo+ID4+Pj4gICA+PiAgbmV0d29ya3MgdXNpbmcgdGhlIHNh bWUgT0FNL2FkZHJlc3Npbmcgc29sdXRpb25zLiBJbiBib3RoDQo+IGNhc2VzDQo+ID4+Pj4gdGhl cmUgYXJlDQo+ID4+Pj4gICA+PiAgZGlmZmVyZW50IGlzc3VlcyB3cnQgaW50ZXItbGF5ZXIgbWlz Y29ubmVjdGl2aXR5IG9uZSBoYXMgdG8NCj4gZGVhbA0KPiA+Pj4+IHdpdGguIEknbQ0KPiA+Pj4+ ICAgPj4gIG5vdCBhd2FyZSB0aGF0IHRoZXNlIGNhc2VzIGhhdmUgYmVlbiBjb25zaWRlcmVkIHll dC4NCj4gPj4+PiAgID4+DQo+ID4+Pj4gICA+Pg0KPiA+Pj4+ICAgPj4gIEknZCBsaWtlIHRvIGhl YXIgeW91ciBjb21tZW50cyBvbiBib3RoIHRoZXNlIHBvaW50cywgYnV0IGluDQo+ID4+Pj4gcGFy dGljdWxhciB0aGUNCj4gPj4+PiAgID4+ICBmaXJzdCBvbmUuLi4uLmVzcGVjaWFsbHkgaWYgeW91 IGFsc28gc3VwcG9ydCB0aGUgbm90aW9uIG9mDQo+IEUtTk5JcyBpbg0KPiA+Pj4+IE1QTFMtVFAs DQo+ID4+Pj4gICA+PiAgYXMgdGhlcmUgc2VlbXMgdG8gYSBwb3NzaWJsZSBsb2dpY2FsIGNvbmZs aWN0IGhlcmUuDQo+ID4+Pj4gICA+Pg0KPiA+Pj4+ICAgPj4gIFRoYW5rcy4NCj4gPj4+PiAgID4+ DQo+ID4+Pj4gICA+PiAgcmVnYXJkcywgTmVpbCBIYXJyaXNvbg0KPiA+Pj4+ICAgPj4NCj4gPj4+ PiAgID4+ICBCVCBEZXNpZ24NCj4gPj4+PiAgID4+DQo+ID4+Pj4gICA+PiAgVGhpcyBlbWFpbCBj b250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQNCj4gb3INCj4g Pj4+PiBjb25maWRlbnRpYWwuDQo+ID4+Pj4gICA+PiAgSXQncyBtZWFudCBvbmx5IGZvciB0aGUg aW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuDQo+IElmDQo+ID4+Pj4geW91J3Jl IG5vdA0KPiA+Pj4+ICAgPj4gIHRoZSBpbnRlbmRlZA0KPiA+Pj4+ICAgPj4gIHJlY2lwaWVudCwg bm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvcg0KPiB1c2luZyB0 aGlzDQo+ID4+Pj4gICA+PiAgaW5mb3JtYXRpb24NCj4gPj4+PiAgID4+ICBpcyBwcm9oaWJpdGVk LiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwNCj4gcGxlYXNlIGxldCBt ZQ0KPiA+Pj4+IGtub3cNCj4gPj4+PiAgID4+ICBpbW1lZGlhdGVseQ0KPiA+Pj4+ICAgPj4gIG9u IHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuDQo+ID4+Pj4gICA+PiAgV2UgbW9u aXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWlscy4NCj4gPj4+ PiAgID4+ICBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCj4gPj4+PiAgID4+ICBSZWdp c3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQo+ID4+Pj4g ICA+PiAgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIG5vOiAxODAwMDAwDQo+ID4+Pj4gICA+Pg0KPiA+ Pj4+ICAgPj4+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+ICAgPj4+ICBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ IE9uIEJlaGFsZg0KPiA+PiBPZg0KPiA+Pj4+ICAgPj4+ICBBbmRyZXcgRy4gTWFsaXMNCj4gPj4+ PiAgID4+PiAgU2VudDogMDIgTWF5IDIwMTEgMjA6NDgNCj4gPj4+PiAgID4+PiAgVG86IEdlb3Jn ZSBTd2FsbG93DQo+ID4+Pj4gICA+Pj4gIENjOiBtcGxzQGlldGYub3JnDQo+ID4+Pj4gICA+Pj4g IFN1YmplY3Q6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQ DQo+IElkZW50aWZpZXJzPw0KPiA+Pj4+ICAgPj4+DQo+ID4+Pj4gICA+Pj4gIEdlb3JnZSBldCBh bCwNCj4gPj4+PiAgID4+Pg0KPiA+Pj4+ICAgPj4+ICBWZXJpem9uIGRvZXMgbm90IGhhdmUgYW55 IHJlcXVpcmVtZW50IGZvciBtaXhlZCB1c2Ugb2YNCj4gR2xvYmFsIElEcyBhbmQNCj4gPj4+PiAg ID4+PiAgSUNDcy4gV2UgYXJlIGZpbmUgd2l0aCBzcGVjaWZpY2F0aW9ucyB0aGF0IHJlcXVpcmUg Ym90aA0KPiBlbmRzIG9mIGFuDQo+ID4+IExTUA0KPiA+Pj4+ICAgPj4+ICB0byB1c2Ugb25lIG9y IHRoZSBvdGhlci4NCj4gPj4+PiAgID4+Pg0KPiA+Pj4+ICAgPj4+ICBUaGFua3MsDQo+ID4+Pj4g ICA+Pj4gIEFuZHkNCj4gPj4+PiAgID4+Pg0KPiA+Pj4+ICAgPj4+ICBPbiBNb24sIEFwciAyNSwg MjAxMSBhdCA1OjE2IFBNLCBHZW9yZ2UNCj4gU3dhbGxvdzxzd2FsbG93QGNpc2NvLmNvbT4NCj4g Pj4+PiAgID4+PiAgd3JvdGU6DQo+ID4+Pj4gICA+Pj4+ICBBbGwgLQ0KPiA+Pj4+ICAgPj4+Pg0K PiA+Pj4+ICAgPj4+PiAgTWFueSBvZiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUgSVRV IG9uDQo+ID4+Pj4gICA+Pj4+ICBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMtMDQgaGF2 ZSB0byBkbyB3aXRoIHRoZQ0KPiBHbG9iYWwgYW5kIElDQw0KPiA+Pj4+ICAgPj4+PiAgaWRlbnRp ZmllcnMuDQo+ID4+Pj4gICA+Pj4+DQo+ID4+Pj4gICA+Pj4+ICBUaGUgaWRlbnRpZmllcnMgZm9y IFR1bm5lbCwgTFNQLCBQVywgYW5kIE1FRyBpbmNsdWRlDQo+IGZpZWxkcyB0bw0KPiA+Pj4+ICAg Pj4+ICBpZGVudGlmeSBlYWNoDQo+ID4+Pj4gICA+Pj4+ICBlbmQgb2YgYW4gTFNQLiBDdXJyZW50 bHkgdGhlIGRyYWZ0IGFsbG93cyBhIFR1bm5lbCwgTFNQLA0KPiBQVywgb3IgTUVHDQo+ID4+Pj4g ICA+Pj4gIHRvIHVzZQ0KPiA+Pj4+ICAgPj4+PiAgZWl0aGVyIHRoZSBHbG9iYWwtSUQgZm9yIGJv dGggZW5kcyBvciBvciB0aGUgSUNDIGZvciBib3RoDQo+IGVuZHMuDQo+ID4+Pj4gICA+Pj4gIE1p eGVkIHVzZQ0KPiA+Pj4+ICAgPj4+PiAgaXMgbm90IHBlcm1pdHRlZC4NCj4gPj4+PiAgID4+Pj4N Cj4gPj4+PiAgID4+Pj4gIFRoZSBJVFUgbGlhaXNvbiByZXF1ZXN0cyB0aGF0IHdlIGFsbG93IG1p eGVkIHVzZS4NCj4gPj4+PiAgID4+Pj4NCj4gPj4+PiAgID4+Pj4gIFRoZSBhdXRob3JzIG9mIHRo ZSBkcmFmdCBhcmUgdmVyeSByZWx1Y3RhbnQgdG8gZG8gdGhpcy4NCj4gPj4+PiAgID4+Pj4NCj4g Pj4+PiAgID4+Pj4gIE9idGFpbmluZyBhbiBBUyBOdW1iZXIgKGZyb20gd2hpY2ggdGhlIEdsb2Jh bC1JRCBpcw0KPiBkZXJpdmVkKSBpcyBhDQo+ID4+Pj4gICA+Pj4gIGZhaXJseQ0KPiA+Pj4+ICAg Pj4+PiAgdHJpdmlhbCBwcm9jZWR1cmUuIE1hbnkgb3JnYW5pemF0aW9ucyBpZiBub3QgbW9zdCBh bHJlYWR5DQo+IGhhdmUgQVMNCj4gPj4+PiAgID4+PiAgTnVtYmVycy4NCj4gPj4+PiAgID4+Pj4g IFN1Y2ggYW4gYWRkaXRpb24gd2lsbCBhZGQgbnVtZXJvdXMgb2JqZWN0IGZvcm1hdHMsIGFuZA0K PiB0ZXN0IGNhc2VzLg0KPiA+Pj4+ICAgPj4+PiAgVGhlIGV4dGVudCBpbnRlci1wcm92aWRlciBN UExTLVRQIGlzIGFzIHlldCB1bmtub3duLiBJZg0KPiBtaXhlZCBtb2Rlcw0KPiA+Pj4+ICAgPj4+ ICBvZiBJQ0MNCj4gPj4+PiAgID4+Pj4gIGFuZCBHbG9iYWwtSUQgaWRlbnRpZmljYXRpb24gaXMg cmVxdWlyZWQsIHRoZXkgY2FuIGJlDQo+IGFkZGVkIGxhdGVyLg0KPiA+Pj4+ICAgPj4+PiAgRm9y IHNpZ25hbGVkIGNvbm5lY3Rpb25zLCB0aGVyZSBpcyBubyBwbGFuIHRvIGFsbG93DQo+IHJvdXRp bmcgYmFzZWQgb24NCj4gPj4+PiAgID4+PiAgZWl0aGVyDQo+ID4+Pj4gICA+Pj4+ICB0aGUgR2xv YmFsLUlEIG9yIElDQy4gVGhhdCB3b3VsZCBiZSBhIHJhZGljYWwgY2hhbmdlIHRvDQo+IGhvdyBJ UA0KPiA+Pj4+ICAgPj4+ICB3b3Jrcy4NCj4gPj4+PiAgID4+Pj4gIEhvd2V2ZXIgZm9yIElQIHJv dXRpbmcgdG8gd29yayAoaW4gb3JkZXIgdG8gZm9yd2FyZCB0aGUNCj4gc2lnbmFsaW5nDQo+ID4+ Pj4gICA+Pj4+ICBtZXNzYWdlcyksIHRoZSBwcm92aWRlcnMgaW52b2x2ZWQgd2lsbCBuZWVkIHRv IHJ1biBCR1AgYW5kDQo+IGhhdmUgQVMNCj4gPj4+PiAgID4+PiAgbnVtYmVycy4NCj4gPj4+PiAg ID4+Pj4NCj4gPj4+PiAgID4+Pj4gIFdlIGFyZSBsb29raW5nIGZvciBpbnB1dC9jb25zZW5zdXMg ZnJvbSB0aGUgV0cuDQo+ID4+Pj4gICA+Pj4+DQo+ID4+Pj4gICA+Pj4+ICBHZW9yZ2UsIEVyaWMs JiAgTWF0dGhldw0KPiANCj4gDQo+IC0tDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAg5oiR54ix5aSW54K55LiA5LiD5LiJ5LiADQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From neil.2.harrison@bt.com Sun May 22 13:18: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 6D324E066C for ; Sun, 22 May 2011 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 2JmXFks9Iwu8 for ; Sun, 22 May 2011 13:18:56 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D23B0E0651 for ; Sun, 22 May 2011 13:18:54 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 22 May 2011 21:18:53 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.41]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Sun, 22 May 2011 21:18:53 +0100 From: To: , , , Date: Sun, 22 May 2011 21:18:51 +0100 Thread-Topic: [mpls] R: RE: R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYpktGujkTYZbKSGGLHAN5+JrlJQAFdC5Q Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44025757704@EMV62-UKRD.domain1.systemhost.net> References: <15877149.2648481306085554217.JavaMail.root@wmail53> In-Reply-To: <15877149.2648481306085554217.JavaMail.root@wmail53> 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 Subject: Re: [mpls] R: RE: R: RE: R: Re: 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: Sun, 22 May 2011 20:18:57 -0000 erminio.ottone_69@libero.it wrote 22 May 2011 18:33 =20 > If I understand correctly, you think that all the operators and all the > devices > MUST support both types of identifiers. NH=3D> Of course they must. Forget the distraction of those who would have= us implement unnecessary non-TOS peering cases, this also applies to the i= mportant client/server transport case. Here we can have *inter-layer* misc= onnectivity and thus each party must be able to understand the CV ID it see= s incoming from some other party...and in such a case we should be able to = identify the other party involved to help Ops folks get the problem sorted = quickly. =20 Note - Both intra-layer and inter-layer misconnected traffic is also a pote= ntial security issue...probably not captured as such however. 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 >=20 > This is not indicated in the draft. >=20 > If the consensus is to mandate all the operators to support two types > of > identifiers, the draft needs to be updated to clarify this. >=20 > >----Messaggio originale---- > >Da: eric.gray@ericsson.com > >Data: 20-mag-2011 18.19 > >A: "erminio.ottone_69@libero.it", > "Gregory > Mirsky", > "Malcolm.BETTS@zte.com.cn" BETTS@zte.com.cn> > >Cc: "mpls@ietf.org" > >Ogg: RE: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > > >I cannot see how support for mixed identifier types is any > >different from forcing both ICC and IP based operators to > >support both types of identifiers. Moreover, in addition > >to requiring the operators to do so, you effectively also > >require every device in any operator's network to do so. > > > >-----Original Message----- > >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > erminio.ottone_69@libero.it > >Sent: Wednesday, May 18, 2011 5:00 PM > >To: Gregory Mirsky; Malcolm.BETTS@zte.com.cn > >Cc: mpls@ietf.org > >Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > > >Well, I understand (and I agree) that it is possible to setup via NMS > an LSP > or > >a MS-PW that crosses both IP-based and ICC-based domains even if there > is > no > >e2e OAM. > > > >As this is possible, there is no realistic way to force the ICC-based > >operators to support also IP-based identification nor viceversa. > > > >The issue is that the draft in its current form does not allow giving > a > name > >to such an LSP or MS-PW. > > > >If you allow mixing IP-based and ICC-based identifiers for path ID (as > >proposed by ITU-T), naming these LSPs/MS-PWs becomes very trivial. > > > >As I stated in another mail, I do not see any protocol implications on > mixing > >ICC and IP identifiers for path identification so it is not very clear > what > is > >the technical issue in accepting the ITU-T comment at least for path > >identification purposes. > > > >>----Messaggio originale---- > >>Da: gregory.mirsky@ericsson.com > >>Data: 3-mag-2011 0.31 > >>A: "erminio.ottone_69@libero.it", > "Malcolm. > >BETTS@zte.com.cn" > >>Cc: "mpls@ietf.org" > >>Ogg: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > >> > >>Dear Erminio, > >>I don't see an issue with NMS setting an LSP that crosses domains > that > >utilize different, IP-based and ICC-based, identifiers. The problem, > as > being > >identified, in running e2e OAM on such LSP. > >> > >> Regards, > >> Greg > >> > >>-----Original Message----- > >>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >erminio.ottone_69@libero.it > >>Sent: Monday, May 02, 2011 2:58 PM > >>To: gregimirsky@gmail.com; Malcolm.BETTS@zte.com.cn > >>Cc: mpls@ietf.org; mpls-bounces@ietf.org > >>Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > >> > >>Section 2.1.4 of RFC5860 states: > >> > >> For certain functions, OAM messages need to incorporate > >> identification information (e.g., of source and/or destination > >> nodes). The protocol solution(s) MUST at least support > >> identification information in the form of an IP addressing > structure > >> and MUST also be extensible to support additional identification > >> schemes. > >> > >>If an operator A supports IP-based identifiers and operator B > supports > ICC- > >based identifiers, how can we setup a transport path (LSP or PW) > between > the > >two operators? > >> > >> > >>----Messaggio originale---- > >>Da: gregimirsky@gmail.com > >>Data: 28-apr-2011 1.11 > >>A: > >>Cc: "mpls@ietf.org", > >>Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> > >>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 > >>ToGeorge Swallow , "mpls@ietf.org" > >>ccSubjectRe: [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 > >> > >> > >> > >> > >> > >>_______________________________________________ > >>mpls mailing list > >>mpls@ietf.org > >>https://www.ietf.org/mailman/listinfo/mpls > >> > > > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From larryli888@yahoo.com.cn Sun May 22 18:54: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 82946E06A6 for ; Sun, 22 May 2011 18:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_EXTRA_CLOSE=2.809, 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 oosGFv1owFxT for ; Sun, 22 May 2011 18:54:13 -0700 (PDT) Received: from web15608.mail.cnb.yahoo.com (web15608.mail.cnb.yahoo.com [202.165.102.62]) by ietfa.amsl.com (Postfix) with SMTP id 2FAE3E06A4 for ; Sun, 22 May 2011 18:54:12 -0700 (PDT) Received: (qmail 33071 invoked by uid 60001); 23 May 2011 01:54:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1306115647; bh=EXNPItFfLohUYOHT0hz3nFbHy6MvkmlwLUa0pRGN7kQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZAyDOI1eXmHOjBwf9Tf0aT33XoSKIcTMfSUfDIDLNvtdOx/Q8F6zuLpphQkpSuZ1OI5Y5CxCjhH5d8QU5pc5maZNSMbhCm3pSjgpqUnInnLTI+YIrkqGPqrrbRh3M0YOYHcHy92k0YfOvi2grfkf45yaGzmco3R30u00foBfi5g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=eOkxNx4TrV7Uh7ynCM+cNJQKu05pbsqfQYjQLkg431p9Ia3IZFI/SdQrR3aBH7GZy0III0PAvVtcso0jyD2UZMvxeXb2AJuI7sT1u44DvwZEs1hv01dRualsSusnpmajM/lZZhVjBg/0lNoCBy16NoIUMsnGHK6rMHUXRQJbUF4=; Message-ID: <840301.32809.qm@web15608.mail.cnb.yahoo.com> X-YMail-OSG: jCC9DDYVM1kFcS7GFegHHg8qWavsuBt6HJggUUrJ6AehWQx t_Xep0hbyIDHNYDBGGqr77eH7KVdW0VLcrVtOEVFjUMuOMaFzXN7zKSVgx2X 5L6Lr2uRiRVHaK22MRHmPQKqwPjhnevG1FgskUW4FAUSGg2N2jUEMxBNa_XY uKCqHHMRFSHswA01iVTO3hHPbaQ5amcpKIaKpMoXZeqBl9sPzkSH6Dl4.acc DOfgWOkC1Kq3hV2R6rxuxZX9KtJ.GCoaV8LTCKFMWEDm1OyoDZgLQYdZlXEf BaPcgESsSqe2G.Uigiq2cviedYlHh8Y2lVGSb.IcyEfdwHZlRo3SE06x.hhm agX3Q2kMD02o5781nVLSY0j41UTDW45q7mmUFgPRFLazV.AMfE4tKCV_ihy4 _fc67xbU_y00SNbrGOaiPvOh6lu310S3Ogv7DEOIWUSYG_On9VpByuBDbdDb Tug-- Received: from [221.130.253.135] by web15608.mail.cnb.yahoo.com via HTTP; Mon, 23 May 2011 09:54:07 CST X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Mon, 23 May 2011 09:54:07 +0800 (CST) From: Larry To: Ross Callon , "mpls@ietf.org" , Rui Costa In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201ED33511459@INOAVREX11.ptin.corpPT.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1794885232-1306115647=:32809" 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: Mon, 23 May 2011 01:54:15 -0000 --0-1794885232-1306115647=:32809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I fully agree and support. Thank you! ************************************************************************* Han Li, Ph.D=20 China Mobile Research Institute Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 Fax: +86 10 63601087=20 MOBILE: 13501093385=20 ************************************************************************* --- 11=E5=B9=B45=E6=9C=8820=E6=97=A5=EF=BC=8C=E5=91=A8=E4=BA=94, Rui Costa = =E5=86=99=E9=81=93=EF=BC=9A =E5=8F=91=E4=BB=B6=E4=BA=BA: Rui Costa =E4=B8=BB=E9=A2=98: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identif= iers? =E6=94=B6=E4=BB=B6=E4=BA=BA: "Ross Callon" , "mpls@iet= f.org" =E6=97=A5=E6=9C=9F: 2011=E5=B9=B45=E6=9C=8820=E6=97=A5,=E5=91=A8=E4=BA=94,= =E4=B8=8B=E5=8D=884:20 Most if not all circuits in PT=E2=80=99s networks are currently identified = in an ICC-oriented way. It=E2=80=99s something defined by ITU-T before MPLS= or MPLS-TP. Customer orientation made this a preferred DB primary indexati= on.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 Operators are the final client of ITU-T MPLS-TP standards, which depend on = RFC drafts like this one, so i also don=E2=80=99t understand the decision o= f not changing draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs= and ICC=E2=80=99s for the same Tunnel, LSP, PW, or Section. It looks like = just an unilateral decision to allow/promote one type of IDs while preventi= ng others.=20 =C2=A0 Regards,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=20 Rui =C2=A0 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: quarta-feira, 18 de Maio de 2011 19:41 To: mpls@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =C2=A0 After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80= =99s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rou= gh) consensus is to leave the document as currently defined. The authors ar= e therefore instructed to continue progression of draft-ietf-mpls-tp-identi= fiers without a change in this area. =C2=A0 This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers.=20 =C2=A0 Thanks, Ross and Loa (as MPLS WG chairs) =C2=A0 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] =C2=A0 =C2=A0 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? =C2=A0 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. =C2=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. =C2= =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. =C2=A0 Obtaining an AS Number (from which the Global-ID is derived) is a fairly tr= ivial procedure. =C2=A0Many organizations if not most already have AS Numbe= rs.=20 Such an addition will add numerous object formats, and test cases.=20 The extent inter-provider MPLS-TP is as yet unknown. =C2=A0If mixed modes o= f ICC and Global-ID identification is required, they can be added later.=20 For signaled connections, there is no plan to allow routing based on either= the Global-ID or ICC. =C2=A0That would be a radical change to how IP works= . =C2=A0However 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.= =20 We are looking for input/consensus from the WG. George, Eric, & Matthew=20 -----=E4=B8=8B=E9=9D=A2=E4=B8=BA=E9=99=84=E4=BB=B6=E5=86=85=E5=AE=B9----- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --0-1794885232-1306115647=:32809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable --0-1794885232-1306115647=:32809-- From mach.chen@huawei.com Sun May 22 20:41:19 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 39E34E06FA; Sun, 22 May 2011 20:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IISg8CzawV7H; Sun, 22 May 2011 20:41:18 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 90B08E06F5; Sun, 22 May 2011 20:41:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLM00JSVQ6PAI@szxga03-in.huawei.com>; Mon, 23 May 2011 11:40:01 +0800 (CST) Received: from szxeml202-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 <0LLM00D5XQ6PMP@szxga03-in.huawei.com>; Mon, 23 May 2011 11:40:01 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 11:40:00 +0800 Received: from SZXEML502-MBX.china.huawei.com ([169.254.6.52]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 23 May 2011 11:40:00 +0800 Date: Mon, 23 May 2011 03:39:59 +0000 From: Mach Chen X-Originating-IP: [10.110.98.39] To: CCAMP Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-chen-ccamp-mpls-tp-oio-00.txt Thread-index: AQHMEU4LBOSPdaalyU2jsyHTfU6zkZSZvGdw X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" Subject: [mpls] FW: New Version Notification for draft-chen-ccamp-mpls-tp-oio-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: Mon, 23 May 2011 03:41:19 -0000 Hi, We just submitted a new draft (http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 ) that defines two types of Operator Identifier Object (OIO). Because Opr_ID is part of the identifier of an LSP, the control plane has to communicate the Opr_IDs of the LSP among the relevant nodes when signal the LSP. The Objects are designed to be carried in the Path message to communicate the Opr_IDs that the two ends of an LSP in use. It also defines procedures to make sure all the nodes that the LSP traverses to use the same format of Opr_ID. We'd appreciate to receive your comments! Best regards, Mach and Vero > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 13, 2011 5:13 PM > To: Mach Chen > Cc: verozheng@huawei.com; Mach Chen > Subject: New Version Notification for draft-chen-ccamp-mpls-tp-oio-00.txt > > A new version of I-D, draft-chen-ccamp-mpls-tp-oio-00.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-chen-ccamp-mpls-tp-oio > Revision: 00 > Title: Multi-Protocol Label Switching Transport Profile (MPLS-TP) > Operator Identifier Object > Creation date: 2011-05-13 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > Two formats of Operator Identifier (Opr_ID) are specified in Multi- > Protocol Label Switching Transport Profile (MPLS-TP) networks, to > uniquely identify an operator. One is Global Identifier (Global_ID), > the other is ITU Carrier Code (ICC). In MPLS-TP networks, Opr_ID as > part of the global identifier of an MPLS-TP LSP may be required to be > carried in the Path message when setting up the LSP. > > This document defines two types of Operator Identifier Object: > Global_ID Object and ICC Object, which could be carried in the Path > message to comunicate the Operator Identifiers (Opr_IDs) that the two > ends of an LSP in use. At the same time, it makes sure all the nodes > that the LSP traverses to use the same format of Opr_ID. > > > > > > The IETF Secretariat From mach.chen@huawei.com Sun May 22 20:47: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 82080E0718; Sun, 22 May 2011 20:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-1.925, 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 WFBSbVCXHGR9; Sun, 22 May 2011 20:47:15 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8D084E0721; Sun, 22 May 2011 20:47:14 -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 <0LLM00CCKQFF4P@szxga05-in.huawei.com>; Mon, 23 May 2011 11:45:16 +0800 (CST) Received: from szxeml208-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 <0LLM004QJQFDWX@szxga05-in.huawei.com>; Mon, 23 May 2011 11:45:15 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 11:45:13 +0800 Received: from SZXEML502-MBX.china.huawei.com ([169.254.6.52]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Mon, 23 May 2011 11:45:00 +0800 Date: Mon, 23 May 2011 03:44:59 +0000 From: Mach Chen X-Originating-IP: [10.110.98.39] To: "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-chen-pwe3-mpls-tp-aii-icc-00.txt Thread-index: AQHMEUGiQV8lDwBJ7kOghOHnSx5FNZSZ0+8Q X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" Subject: [mpls] FW: New Version Notification for draft-chen-pwe3-mpls-tp-aii-icc-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: Mon, 23 May 2011 03:47:16 -0000 Hi, We just submitted a new draft (http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 ) that defines a new Aii: Aii-ICC that is used in the scenarios where ICC is used as the Operator Identifier. We'd appreciate to receive your comments! Best regards, Mach and Vero > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 13, 2011 3:44 PM > To: Mach Chen > Cc: verozheng@huawei.com; Mach Chen > Subject: New Version Notification for draft-chen-pwe3-mpls-tp-aii-icc-00.txt > > A new version of I-D, draft-chen-pwe3-mpls-tp-aii-icc-00.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-chen-pwe3-mpls-tp-aii-icc > Revision: 00 > Title: ITU Carrier Code (ICC) Attachment Individual Identifier (AII) > Creation date: 2011-05-12 > WG ID: Individual Submission > Number of pages: 5 > > Abstract: > This document defines a new Attachment Individual Identifier (AII) > type which could be used when ITU Carrier Code (ICC) is used as the > provider's globally unique identifier (Opr_ID). The new AII (ICC > AII) consists a ICC, a prefix and a AC ID field. > > > > > > The IETF Secretariat From N.Leymann@telekom.de Mon May 23 11:46: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 3F2A1E07E6 for ; Mon, 23 May 2011 11:46:13 -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 lRyWc4jNk3Yu for ; Mon, 23 May 2011 11:46:12 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9FE07EB for ; Mon, 23 May 2011 11:46:12 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 23 May 2011 20:46:07 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.131]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 23 May 2011 20:46:07 +0200 From: To: , , , , Date: Mon, 23 May 2011 20:46:06 +0200 Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: AcwQrOWFWKbWmuR+RRq8PjBekWDWjgIzLBog Message-ID: <9762ACF04FA26B4388476841256BDE020114423E18B2@HE111543.emea1.cds.t-internal.com> References: <4DCBE7BE.5010708@pi.nu> In-Reply-To: <4DCBE7BE.5010708@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 23 May 2011 18:46:13 -0000 Support! Regards Nic -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von Lo= a Andersson Gesendet: Donnerstag, 12. Mai 2011 15:59 An: mpls@ietf.org; draft-raggarwa-mpls-seamless-mcast@tools.ietf.org; Ross = Callon; George Swallow Betreff: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Working Group, this is to start a two week poll on making draft-raggarwa-mpls-seamless-mcast-03.txt 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 on May 27th. /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 marco@juniper.net Mon May 23 12:14:21 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 33B8DE07E9 for ; Mon, 23 May 2011 12:14:21 -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 yvXxkmGJOE92 for ; Mon, 23 May 2011 12:14:20 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFCAE07E0 for ; Mon, 23 May 2011 12:14:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTdqx925K9Nyo0AU2IF51/KdN9uPFnnVb@postini.com; Mon, 23 May 2011 12:14:20 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 23 May 2011 12:10:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 23 May 2011 15:10:36 -0400 From: Marco Rodrigues To: Loa Andersson , "mpls@ietf.org" , "draft-raggarwa-mpls-seamless-mcast@tools.ietf.org" , Ross Callon , George Swallow Date: Mon, 23 May 2011 15:10:32 -0400 Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: AcwZfRhPbUaevTnjQvGFSlgtGG8jSw== Message-ID: In-Reply-To: <4DCBE7BE.5010708@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 Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 23 May 2011 19:14:21 -0000 Support. On 5/12/11 9:59 AM, "Loa Andersson" wrote: >Working Group, > >this is to start a two week poll on making > >draft-raggarwa-mpls-seamless-mcast-03.txt > >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 on May 27th. > >/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 malcolm.betts@zte.com.cn Mon May 23 17:42: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 9AB38E06BD; Mon, 23 May 2011 17:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.163 X-Spam-Level: X-Spam-Status: No, score=-101.163 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 sfqWKSJ6C6zM; Mon, 23 May 2011 17:42:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C2852E06B3; Mon, 23 May 2011 17:42:43 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 18341784411434; Tue, 24 May 2011 08:34:55 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 69695.3355180459; Tue, 24 May 2011 08:42:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4O0gNsx090958; Tue, 24 May 2011 08:42:23 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: Mach Chen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Mon, 23 May 2011 20:42:12 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-24 08:42:25, Serialize complete at 2011-05-24 08:42:25 Content-Type: multipart/alternative; boundary="=_alternative 0003DF118525789A_=" X-MAIL: mse02.zte.com.cn p4O0gNsx090958 Cc: "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 00:42:48 -0000 This is a multipart message in MIME format. --=_alternative 0003DF118525789A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mach, Please see in line below - marked by [MB2] Regards, Malcolm Mach Chen =20 22/05/2011 11:34 PM To "Malcolm.BETTS@zte.com.cn" ,=20 "adrian@olddog.co.uk" cc "mpls-bounces@ietf.org" , "mpls@ietf.org"=20 Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, =20 See my response inline? =20 Ermino, We have already been round this loop on this list once. Want to do it again?=20 [MB] well the continuation of this thread indicates that the loop is still = open.... As Huub said, this is about identifiers, not OAM. However, the model for=20 OAM interworking shows "layering" not gatewaying, and certainly not mixing.=20 That is, one end of the e2e path must be capable of operating both systems, but the = other does not need to.=20 [MB] OK To extend this model to identifiers means that one end of the e2e path=20 must support both identifier formats and the other does not need to.=20 [MB] It requires that one of the operators must administer both types of=20 identifiers.=20 [Mach] If mixed identifiers used, seems that all relevant domains (other=20 than only one domain) of the path must administer both types of=20 identifiers, [MB2] Why? As I have explained several times on this thread a node that=20 receives an OAM message only needs to check that it is from the expected=20 entity, no need to understand or administer the format. and the operators(only prefer to ICC based Opr=5FID) have to support and=20 configure both ICC and Global=5FID style identifier. On the contrary, for a= =20 specific LSP or PW, if only one type of identifiers is used, the operators = (only prefer to ICC based Opr=5FID) can really only need to support and=20 administer only one type of identifiers (ICC) if they get the agreement of = using ICC type of identifier with other operators. This causes two problems a) A (potentially) new operational process must=20 be invoked to assign the second identifier type and; b) Given that a node=20 will terminate/originate traffic from/to the local network and a third=20 party network that node will have (different) identifiers, this will cause = significant issues when attempting to perform normal operational processes = e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers.=20 [MB] Why? only the entity inserting the identifier needs to understand the = semantics, all other nodes only need to check if the (bit string)=20 presented matches the expected string. [Mach] Here is an example that the transit nodes may require to ?inspect?=20 the identifiers: MPLS-TP control plane. Because Opr=5FID is part of the=20 identifier of an LSP, PW and Section, the control plane has to communicate = the Opr=5FIDs of the LSP, PW or Section among the relevant nodes when signa= l=20 the LSP, PW or Section. [MB2] As defined in the architecture the data plane and control plane=20 must be independent, including the identifiers that they use. Best regards, Mach =20 BTW, we just submitted two drafts that define extensions to RSVP-TE and PW = protocol for communicating Opr=5FID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > erminio.ottone=5F69@libero.it > Sent: 18 May 2011 22:25 > To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. >=20 > You can download the latest version of Y.1731 (the pdr version is for=20 free) at > the following URL: >=20 > http://www.itu.int/rec/T-REC-Y.1731/en >=20 > It is a pity that with the current version of the identifier draft,=20 MPLS-TP is > not capable to support such a network scenario. >=20 > >----Messaggio originale---- > >Da: loa@pi.nu > >Data: 4-mag-2011 8.00 > >A: , > "Malcolm.BETTS@zte.com.cn" > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network=20 supports > >> multi carrier data plane interconnection with end to end OAM. In=20 today's > >> transport network this interconnection is supported by SDH and OTN.=20 The > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow * > >> Sent by: mpls-bounces@ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" ,=20 > >> cc > >> mpls@ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a=20 solution > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where=20 we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal=20 server > >> > layer in the transport core). If peer layer interworking ever=20 becomes > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary,=20 for > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM.=20 Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else = to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer=20 mis-connectivity > >> > detection and amelioration are required, but I'm not convinced=20 that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing=20 scheme in > a > >> >> single layer network solely belonging to one party. Though you=20 may > >> need to > >> >> be rather careful if you also advocate that one can also have=20 peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this = is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes=20 (and > >> indeed > >> >> any other variations in DP/CP functional components) if they=20 exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between=20 different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for=20 only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of=20 the > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=3D> > >> >> This case cannot occur in the co-cs mode). To date, however, we=20 have > >> only > >> >> really considered intra-layer misconnectivity, ie between=20 different > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive=20 traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions=20 or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs = in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, 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=20 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. > >> >> British Telecommunications plc > >> >> Registered office: 81 Newgate Street London EC1A 7AJ > >> >> Registered in England no: 1800000 > >> >> > >> >>> -----Original Message----- > >> >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 Behalf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls@ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP=20 Identifiers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global=20 IDs and > >> >>> ICCs. We are fine with specifications that require both ends of=20 an > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow=20 > >> >>> wrote: > >> >>>> All - > >> >>>> > >> >>>> Many of the comments received from the ITU on > >> >>>> draft-ietf-mpls-tp-identifiers-04 have to do with the Global=20 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. > >> >>>> > >> >>>> Obtaining an AS Number (from which the Global-ID is derived) is = a > >> >>> fairly > >> >>>> trivial procedure. Many organizations if not most already have=20 AS > >> >>> Numbers. > >> >>>> Such an addition will add numerous object formats, and test=20 cases. > >> >>>> 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. > >> >>>> 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 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 = 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 > >> >>>> > >> >>>> > >> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > >> >>> mpls mailing list > >> >>> mpls@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mpls > >> >> > >> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> > >> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >> mpls 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 > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=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 >=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 0003DF118525789A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mach,

Please see in line below - marked by [MB2]

Regards,

Malcolm



I fully agree and support. Thank you!


**************************************************************= ***********
Han Li, Ph.D
China Mobile Research Institute
Unit 2, = 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
Fax: +86 10 = 63601087
MOBILE: 13501093385
**************************************= ***********************************

--- 11=E5=B9=B45=E6=9C=8820= =E6=97=A5=EF=BC=8C=E5=91=A8=E4=BA=94, Rui Costa <RCosta@ptinovacao.pt= > =E5=86=99=E9=81=93=EF=BC=9A

=E5=8F=91=E4=BB=B6=E4=BA=BA: Rui Costa <RCosta= @ptinovacao.pt>
=E4=B8=BB=E9=A2=98: Re: [mpls] Mixing ICC and Global-= IDs in MPLS-TP Identifiers?
=E6=94=B6=E4=BB=B6=E4=BA=BA: "Ross Callon" &= lt;rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
=E6=97= =A5=E6=9C=9F: 2011=E5=B9=B45=E6=9C=8820=E6=97=A5,=E5=91=A8=E4=BA=94,=E4=B8= =8B=E5=8D=884:20

Most if not all circuits in = PT=E2=80=99s networks are currently identified in an ICC-oriented way. It= =E2=80=99s something defined by ITU-T before MPLS or MPLS-TP. Customer orie= ntation made this a preferred DB primary indexation.    = ;         

Operators are the final clie= nt of ITU-T MPLS-TP standards, which depend on RFC drafts like this one, so= i also don=E2=80=99t understand the decision of not changing draft-ietf-mp= ls-tp-identifiers to allow mixing of Global-IDs and ICC=E2=80=99s for the s= ame Tunnel, LSP, PW, or Section. It looks like just an unilateral decision = to allow/promote one type of IDs while preventing others.

 

Regards,   &n= bsp;         

Rui

 

From: mpls-bounces@ietf.org [mai= lto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: = quarta-feira, 18 de Maio de 2011 19:41
To: mpls@ietf.org
Su= bject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

 

After discussion on the MPLS= WG email list, there is no consensus to change draft-ietf-mpls-tp-identifi= ers to allow mixing of Global-IDs and ICC=E2=80=99s for the same Tunnel, LS= P, PW, or Section. Instead, the (admittedly rough) consensus is to leave th= e document as currently defined. The authors are therefore instructed to co= ntinue progression of draft-ietf-mpls-tp-identifiers without a change in th= is area.

 

This decision neither suppor= ts nor precludes the possibility that at some point in the future, after dr= aft-ietf-mpls-tp-identifiers is approved and published as an RFC, the WG mi= ght consider additional work to extend the MPLS protocols to allow mixed id= entifiers.

 

Thanks,

Ross and Loa (as MPLS WG cha= irs)

 

[Note that since George is c= o-author of draft-ietf-mpls-tp-identifiers, for this one document he is rec= used from his role as WG co-chair.]

 

 

From: mpls-bounces@ietf.org [mai= lto: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.  <= SPAN lang=3DEN-US>

  1. Obtaining an AS Number (from which the Glob= al-ID is derived) is a fairly trivial procedure.  Many organizations i= f not most already have AS Numbers.
  2. Such an addition will add numerous object f= ormats, and test cases.
  3. The extent inter-provider MPLS-TP is as yet= unknown.  If mixed modes of ICC and Global-ID identification is requi= red, 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.
    5. <= /OL>


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

    George, Eric, & Matthew
    -----=E4=B8=8B=E9=9D=A2=E4=B8=BA=E9=99=84=E4=BB=B6= =E5=86=85=E5=AE=B9-----

    _______________________________________________
    m= pls mailing list
    mpls@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/mpls
Mach Chen <mach.ch= en@huawei.com>

22/05/2011 11:34 PM

To
"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, "adrian@olddog.co.uk" <adria= n@olddog.co.uk>
cc
"mpls-bounces@ietf.org" &l= t;mpls-bounces@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject
RE: [mpls] R: Re: Mixing ICC and Glo= bal-IDs in MPLS-TP Identifiers?





Hi Malcolm,
 
See my response inline&= #8230;
 

Ermino,

We have already been round this loop on this list once.
Want to do it again?

[MB] well the continuation of this thread indicates that the loop is still open....

As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.

[MB] OK

To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.

[MB] It requires that one of the operators must administer both types of identifiers.
[Mach] If mixed identif= iers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers,
[MB2] Why?  As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format.
 and the operators= (only prefer to ICC based Opr=5FID) have to support and configure both ICC and Global=5FID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr=5FID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators.
 This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

This becomes particularly important to the transit nodes that may have to
inspect the identifiers.

[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) prese= nted matches the expected string.
[Mach] Here is an examp= le that the transit nodes may require to “inspect” the identifiers= : MPLS-TP control plane. Because Opr=5FID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr=5FIDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section.
[MB2]  As defined in the archi= tecture the data plane and control plane must be independent, including the identif= iers that they use.
Best regards,
Mach
 
BTW, we just submitted = two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr=5FID when setup an LSP or PW.
http://tools.ietf.org/id/draf= t-chen-ccamp-mpls-tp-oio-00
http://tools.ietf.org/ht= ml/draft-chen-pwe3-mpls-tp-aii-icc-00

None of this is new or specific to MPLS-TP.

Adrian

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> erminio.ottone=5F69@libero.it
> Sent: 18 May 2011 22:25
> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifier= s?
>
> Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
>
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
>
> http://www.itu.int/rec/T-REC-Y.1731/en
>
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
>
> >----Messaggio originale----
> >Da: loa@pi.nu
> >Data: 4-mag-2011 8.00
> >A: <mpls@ietf.org>,
> "Malcolm.BETTS@zte.com.cn"<Malcolm.BETTS@zte.com.cn> > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?<= br> > >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconne= ction as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <swallow@cisco.com>*
> >> Sent by: mpls-bounces@ietf.org
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >>                  = ;"Andrew G. Malis" <agmalis@gmail.com>, <neil.2.harrison@bt.com>
> >> cc
> >>                  = ;mpls@ietf.org
> >> Subject
> >>                  = ;Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >>  > Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surro= unds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.=
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis@gm= ail.com> wrote:
> >>
> >>  > Neil,
> >>  >
> >>  > To your case 1, we're in complete agreement. We (VZ) don't see at
> >>  > least a short-term need for peer-layer interworkin= g, given where we
> >>  > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >>  > layer in the transport core). If peer layer interw= orking ever becomes
> >>  > a necessity, then obviously we'll need a well-defi= ned E-NNI which
> >>  > would include LSP identifier mapping/translation at the boundary, for
> >>  > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>  >
> >>  > I also agree that both intra-layer and inter-layer mis-connectivity
> >>  > detection and amelioration are required, but I'm not convinced that
> >>  > the already defined mechanisms can't do that. Do you have some
> >>  > specific analysis on the inter-layer case?
> >>  >
> >>  > Cheers,
> >>  > Andy
> >>  >
> >>  > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harriso= n@bt.com> wrote:
> >>  >> Hi Andy,
> >>  >>
> >>  >> 2 points:
> >>  >>
> >>  >> 1 I agree with your view of only having a single addressing scheme in
> a
> >>  >> single layer network solely belonging to one party. Though you may
> >> need to
> >>  >> be rather careful if you also advocate that one can also have peer
> layer
> >>  >> interworking between different parties, ie E-NNIs (I believe this is
> >>  >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >>  >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >>  >> any other variations in DP/CP functional compo= nents) if they exist
> >> in the
> >>  >> standards.
> >>  >>
> >>  >> Of course, having an E-NNI and peer interworki= ng between different
> >> parties in
> >>  >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >>  >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >>  >> single addressing scheme in a non-TOS layer network.
> >>  >>
> >>  >>
> >>  >> 2 You should also be aware that in client/serv= er interworking of the
> >>  >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >>  >> important for MPLS-TP in the role of a transpo= rt network (I'll
> >> ignore issues
> >>  >> of transparency here), there could be inter-la= yer misconnectivity
> >> (Aside=3D>
> >>  >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >>  >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >>  >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >>  >> sublayer misconnectivity).
> >>  >>
> >>  >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >>  >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >>  >> come from (i) networks using different OAM/add= ressing solutions or
> (ii)
> >>  >> networks using the same OAM/addressing solutio= ns. In both cases
> >> there are
> >>  >> different issues wrt inter-layer misconnectivi= ty one has to deal
> >> with. I'm
> >>  >> not aware that these cases have been considered yet.
> >>  >>
> >>  >>
> >>  >> I'd like to hear your comments on both these points, but in
> >> particular the
> >>  >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >>  >> as there seems to a possible logical conflict here.
> >>  >>
> >>  >> Thanks.
> >>  >>
> >>  >> regards, 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.
> >>  >> British Telecommunications plc
> >>  >> Registered office: 81 Newgate Street London EC1A 7AJ
> >>  >> Registered in England no: 1800000
> >>  >>
> >>  >>> -----Original Message-----
> >>  >>> From: mpls-bounces@ietf.org [mailto:mpls-b= ounces@ietf.org] On Behalf
> Of
> >>  >>> Andrew G. Malis
> >>  >>> Sent: 02 May 2011 20:48
> >>  >>> To: George Swallow
> >>  >>> Cc: mpls@ietf.org
> >>  >>> Subject: Re: [mpls] Mixing ICC and Global-= IDs in MPLS-TP Identifiers?
> >>  >>>
> >>  >>> George et al,
> >>  >>>
> >>  >>> Verizon does not have any requirement for mixed use of Global IDs and
> >>  >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >>  >>> to use one or the other.
> >>  >>>
> >>  >>> Thanks,
> >>  >>> Andy
> >>  >>>
> >>  >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow@cisco.com>
> >>  >>> wrote:
> >>  >>>> 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.
> >>  >>>>
> >>  >>>> 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 requir= ed, 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.
> >>  >>>>
> >>  >>>> 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
> >>  >>>>
> >>  >>>>
> >>  >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
> >>  >>> mpls mailing list
> >>  >>> mpls@ietf.org
> >>  >>> https://www.ietf.org/mailman/listinfo/mpls=
> >>  >>
> >>
> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> >> mpls mailing list
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> >> mpls 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
> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
> >mpls mailing list
> >mpls@ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 0003DF118525789A_=-- From gregory.mirsky@ericsson.com Mon May 23 18:04: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 E32FEE06AA; Mon, 23 May 2011 18:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqBWgoFK--X; Mon, 23 May 2011 18:04:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFC1E0651; Mon, 23 May 2011 18:04:05 -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 p4O13x0h005695; Mon, 23 May 2011 20:04:00 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 23 May 2011 21:03:53 -0400 From: Gregory Mirsky To: "Malcolm.BETTS@zte.com.cn" , Mach Chen Date: Mon, 23 May 2011 21:03:49 -0400 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwZq6iqTvSBcDrVR+yUzt3LL6hXOQAAebfA 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_FE60A4E52763E84B935532D7D9294FF1218E59B9B7EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 01:04:06 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1218E59B9B7EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Malcolm, a quick question, just one, promise, tagged with GIM>> <... snipped ...> ________________________________ [Mach] If mixed identifiers used, seems that all relevant domains (other th= an only one domain) of the path must administer both types of identifiers, [MB2] Why? As I have explained several times on this thread a node that re= ceives an OAM message only needs to check that it is from the expected enti= ty, no need to understand or administer the format. GIM>> For the datapath the Identifier in OAM message is opaque bit string o= f length determined by particular type (IP-based or ICC)? Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF1218E59B9B7EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Malcolm,
 
a quick question, just one, promise, tagged with=20 GIM>>
 
 
<... snipped ...>

[Mach] If mixed identifiers used, seems that all r= elevant=20 domains (other than only one domain) of the path must administer both types= of=20 identifiers,
[MB2] Why? &nbs= p;As I=20 have explained several times on this thread a node that receives an OAM mes= sage=20 only needs to check that it is from the expected entity, no need to underst= and=20 or administer the format. 
  
GIM>> For the datapath the Identifier in OA= M=20 message is opaque bit string of length determined by particular type=20 (IP-based or ICC)?
 
  
  &n= bsp; Regards,
        Greg
--_000_FE60A4E52763E84B935532D7D9294FF1218E59B9B7EUSAACMS0715e_-- From rcallon@juniper.net Mon May 23 19:03:40 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 12347E0682 for ; Mon, 23 May 2011 19:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3x1X7sin3PEv for ; Mon, 23 May 2011 19:03:36 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E3E0651 for ; Mon, 23 May 2011 19:03:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTdsR9UeK9QFOatQnLry+8sMcjwFEtrYR@postini.com; Mon, 23 May 2011 19:03:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 23 May 2011 19:02:35 -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, 23 May 2011 22:02:34 -0400 From: Ross Callon To: "Malcolm.BETTS@zte.com.cn" Date: Mon, 23 May 2011 22:02:33 -0400 Thread-Topic: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwYE/y4qeap3th4Rvy0pnCXlBEWFgBoieKw 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_DF7F294AF4153D498141CBEFADB17704C22025BB06EMBX01WFjnprn_" 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: Tue, 24 May 2011 02:03:40 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C22025BB06EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm; There has been extensive discussion of this issue on the MPLS WG email list= since George Swallow's original email of Mon 4/25/2011 5:17 PM. As has bee= n pointed out there is no consensus to include mixed identifier types in th= e current draft. Admittedly the consensus to leave it out is rough, but thi= s is the consensus that we have. You and others are welcome to author or co-author a draft which points out = scenarios in which mixing ICC and Global-IDs is useful, and the protocol me= chanisms needed to support this. If you choose to write such a draft, then = we would welcome discussion of this draft on the MPLS WG email list. Thanks, Ross and Loa (as MPLS WG co-chairs) From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Saturday, May 21, 2011 8:05 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org; Ross Callon Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Eric, I find that argument somewhat circular since we did not have consensus to = omit this. Regards, Malcolm Eric Gray 20/05/2011 12:28 PM To "Malcolm.BETTS@zte.com.cn" , Ross Callon cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm, As a co-author of the draft in question, I completely support this deci= sion. As I already explained to another person asking the same question, the bit about "no consensus to change" says it all. In my opinion, this is a quite sufficiently detailed response. The abs= ence of a consensus to change means no change. We do not typically require a strong consensus to continue on the current path. I am reasonably certain you apply similar rules yourself when working i= n other SDOs. -- Eric ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mal= colm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross, I disappointed and, based on my reading of the emails on this thread, surpr= ised that this decision has been taken. Could you please elaborate on the = reasoning behind this decision. Regards, Malcolm Ross Callon Sent by: mpls-bounces@ietf.org 18/05/2011 02:40 PM To "mpls@ietf.org" cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? After discussion on the MPLS WG email list, there is no consensus to change= draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for= the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) cons= ensus is to leave the document as currently defined. The authors are theref= ore instructed to continue progression of draft-ietf-mpls-tp-identifiers wi= thout a change in this area. This decision neither supports nor precludes the possibility that at some p= oint in the future, after draft-ietf-mpls-tp-identifiers is approved and pu= blished as an RFC, the WG might consider additional work to extend the MPLS= protocols to allow mixed identifiers. Thanks, Ross and Loa (as MPLS WG chairs) [Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for= this one document he is recused from his role as WG co-chair.] 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_DF7F294AF4153D498141CBEFADB17704C22025BB06EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm;<= o:p>

 

There has been extensive discussion of this i= ssue on the MPLS WG email list since George Swallow’s original email = of Mon 4/25/2011 5:17 PM. As has been pointed out there is no consensus to = include mixed identifier types in the current draft. Admittedly the consens= us to leave it out is rough, but this is the consensus that we have. <= /o:p>

 

You and others are welcome to author or co-author = a draft which points out scenarios in which mixing ICC and Global-IDs is us= eful, and the protocol mechanisms needed to support this. If you choose to = write such a draft, then we would welcome discussion of this draft on the M= PLS WG email list.

&n= bsp;

Thanks, =

Ross and Loa (as MPLS WG co-chairs)

 

From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS= @zte.com.cn]
Sent: Saturday, May 21, 2011 8:05 PM
To: = Eric Gray
Cc: mpls@ietf.org; mpls-bounces@ietf.org; Ross CallonSubject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifie= rs?

 


Eric,

I find that argume= nt somewhat circular since  we did not have consensus to omit this.

Regards,

Malcolm


Eric Gray <eric.gray@ericsson.com>= ;

20/05/2011 12:28 PM

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

<= /table>

 

To=

<= p class=3DMsoNormal>"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn= >, Ross Callon <rcallon@juniper.net>

cc

Subject

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



Malcolm,
 
    As a co-author of the dr= aft in question, I completely support this decision.
 
=     As I already explained to another person asking the same qu= estion, the
bit about "no consensus to change" says = it all.
 
    In my opinion, this is a quit= e sufficiently detailed response.  The absence
of a cons= ensus to change means no change.  We do not typically require a=
strong consensus to continue on the current path.
  =
    I am reasonably certain you apply similar rules yoursel= f when working in
other SDOs.
 
--
Eric

=

From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.co= m.cn
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Call= on
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re= : [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?


Ross,

I disappointed and, based on my reading of the emails on this thread, = surprised that this decision has been taken.  Could you please elabora= te on the reasoning behind this decision.

Regards,

Malcolm

= Ross Callon <rcallon@juniper.net>
Sent by: mpls-bounces@ietf.org=

18/05/2011 02:40 PM

 

To<= /p>

"mpls@ietf.org" <mpls@ietf.org>= ;

c= c

Subject

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

 





After discussion on the MP= LS WG email list, there is no consensus to change draft-ietf-mpls-tp-identi= fiers to allow mixing of Global-IDs and ICC’s for the same Tunnel, LS= P, PW, or Section. Instead, the (admittedly rough) consensus is to leave th= e document as currently defined. The authors are therefore instructed to co= ntinue progression of draft-ietf-mpls-tp-identifiers without a change in th= is area.
 
This decision neither su= pports nor precludes the possibility that at some point in the future, afte= r draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the W= G might consider additional work to extend the MPLS protocols to allow mixe= d identifiers.
 
Thanks,
Ross a= nd Loa (as MPLS WG chairs)
 
[Note = that since George is co-author of draft-ietf-mpls-tp-identifiers, for this = one document he is recused from his role as WG co-chair.]  
 
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?
&nbs= p;
A= ll -

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

The= identifiers for Tunnel, LSP, PW, and MEG include fields to identify each e= nd 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 m= ixed use.

The authors of the draft are very reluctant to do this. &n= bsp;
1.        Obtaining an AS Number (from which the= Global-ID is derived) is a fairly trivial procedure.  Many organizati= ons if not most already have AS Numbers.
2.        Su= ch 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 connection= s, 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

= --_000_DF7F294AF4153D498141CBEFADB17704C22025BB06EMBX01WFjnprn_-- From loa@pi.nu Mon May 23 19:15:21 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 BA4BFE0682 for ; Mon, 23 May 2011 19:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, 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 y0REbNg2Zabr for ; Mon, 23 May 2011 19:15:21 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2285DE0651 for ; Mon, 23 May 2011 19:15:20 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 05EC12A8001; Tue, 24 May 2011 04:15:17 +0200 (CEST) Received: from 202.96.60.37 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Tue, 24 May 2011 04:15:18 +0200 Message-ID: In-Reply-To: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> References: <833768e1a607dbafe4f3463989757b1a.squirrel@pi.nu> Date: Tue, 24 May 2011 04:15:18 +0200 From: loa@pi.nu To: loa@pi.nu 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: mpls@ietf.org, rcallon@juniper.net, draft-vkst-mpls-tp-te-mib@tools.ietf.org Subject: Re: [mpls] poll on draft-vkst-mpls-tp-te-mib-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, 24 May 2011 02:15:21 -0000 Working Group, This poll has ended, we have had comments of such nature that the authors agreed to re-publish an new version of the document as an individual draft. The decision whether the document will be accepted as a working group document will be taken based on the new version of the document. /Loa MPLS wg co-chair > > Working Group, > > this is to start a two week poll on making > > draft-vkst-mpls-tp-te-mib-00.txt > > 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 2011-05-18. > > /Loa > > From mach.chen@huawei.com Mon May 23 19:16: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 4DFCFE06DB; Mon, 23 May 2011 19:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 Ocj2DkKb7TYc; Mon, 23 May 2011 19:16:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1666CE06D6; Mon, 23 May 2011 19:16:33 -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 <0LLO001LKGXYEY@szxga03-in.huawei.com>; Tue, 24 May 2011 10:15:34 +0800 (CST) Received: from szxeml201-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 <0LLO0071OGXYDG@szxga03-in.huawei.com>; Tue, 24 May 2011 10:15:34 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 10:15:31 +0800 Received: from SZXEML502-MBX.china.huawei.com ([169.254.6.52]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 24 May 2011 10:15:33 +0800 Date: Tue, 24 May 2011 02:15:32 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.39] To: "Malcolm.BETTS@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwT7QXSM6/mFcE6u13UrRuHfH5SXc3wAgAIxuFCAAP18AIAAigmAgAAASwA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 02:16:34 -0000 Hi Malcolm, Thanks for your prompt response! Please see my reply inline... > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > Sent: Tuesday, May 24, 2011 8:42 AM > To: Mach Chen > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifie= rs? >=20 > Hi Mach, >=20 > Please see in line below - marked by [MB2] >=20 > Regards, >=20 > Malcolm >=20 > Mach Chen > 22/05/2011 11:34 PM > To > "Malcolm.BETTS@zte.com.cn" , > "adrian@olddog.co.uk" > cc > "mpls-bounces@ietf.org" , "mpls@ietf.org" > > Subject > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? >=20 > Hi Malcolm, >=20 > See my response inline. > > Ermino, >=20 > We have already been round this loop on this list once. > Want to do it again? >=20 > [MB] well the continuation of this thread indicates that the loop is stil= l open.... >=20 > As Huub said, this is about identifiers, not OAM. However, the model for = OAM > interworking shows "layering" not gatewaying, and certainly not mixing. T= hat > is, > one end of the e2e path must be capable of operating both systems, but th= e > other > does not need to. >=20 > [MB] OK >=20 > To extend this model to identifiers means that one end of the e2e path mu= st > support both identifier formats and the other does not need to. >=20 > [MB] It requires that one of the operators must administer both types of > identifiers. > [Mach] If mixed identifiers used, seems that all relevant domains (other = than > only one domain) of the path must administer both types of identifiers, > [MB2] Why? =A0 If it's static provisioning, the operators need to configure(by CLI or NMS)= the identifiers(include both ICC and Global_ID) on the related nodes. If there is control plane, the control plane has to communicate the identif= iers, and all the nodes along the LSP need to know the type firstly and hen= ce to interpret and process it=20 >As I have explained several times on this thread a node that > receives an OAM message only needs to check that it is from the expected > entity, no need to understand or administer the format. How could a node do that if it does not know the type of the identifier?=20 > =A0and the operators(only prefer to ICC based Opr_ID) have to support and > configure both ICC and Global_ID style identifier. On the contrary, for a= specific > LSP or PW, if only one type of identifiers is used, the operators (only p= refer to > ICC based Opr_ID) can really only need to support and administer only one= type > of identifiers (ICC) if they get the agreement of using ICC type of ident= ifier with > other operators. > =A0This causes two problems a) A (potentially) new operational process mu= st be > invoked to assign the second identifier type and; b) Given that a node wi= ll > terminate/originate traffic from/to the local network and a third party n= etwork > that node will have (different) identifiers, this will cause significant = issues when > attempting to perform normal operational processes e.g. alarm reporting. >=20 > This becomes particularly important to the transit nodes that may have to > inspect the identifiers. >=20 > [MB] Why? only the entity inserting the identifier needs to understand th= e > semantics, all other nodes only need to check if the (bit string) present= ed > matches the expected string. > [Mach] Here is an example that the transit nodes may require to "inspect"= the > identifiers: MPLS-TP control plane. Because Opr_ID is part of the identif= ier of an > LSP, PW and Section, the control plane has to communicate the Opr_IDs of = the > LSP, PW or Section among the relevant nodes when signal the LSP, PW or > Section. > [MB2] =A0As defined in the architecture the data plane and control plane = must > be independent, including the identifiers that they use. But, MPLS-TP identifiers should be not exclusive to data plane or control p= lane or management plane, and actually they are related to all the three pl= anes. Best regards, Mach >=20 > BTW, we just submitted two drafts that define extensions to RSVP-TE and P= W > protocol for communicating Opr_ID when setup an LSP or PW. > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 >=20 From malcolm.betts@zte.com.cn Mon May 23 22:19:47 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 9237CE0678; Mon, 23 May 2011 22:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.478 X-Spam-Level: X-Spam-Status: No, score=-101.478 tagged_above=-999 required=5 tests=[AWL=0.360, 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 wUT7azcvjr1B; Mon, 23 May 2011 22:19:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6D757E068D; Mon, 23 May 2011 22:19:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 18341784411434; Tue, 24 May 2011 13:11:39 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 69695.5258459626; Tue, 24 May 2011 13:19:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4O5JRPY050213; Tue, 24 May 2011 13:19:28 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: Gregory Mirsky MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Tue, 24 May 2011 01:19:18 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-24 13:19:31, Serialize complete at 2011-05-24 13:19:31 Content-Type: multipart/alternative; boundary="=_alternative 001D3E008525789A_=" X-MAIL: mse02.zte.com.cn p4O5JRPY050213 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 05:19:47 -0000 This is a multipart message in MIME format. --=_alternative 001D3E008525789A_= Content-Type: text/plain; charset="US-ASCII" Dear Greg, You are correct. Regards, Malcolm Gregory Mirsky 23/05/2011 09:03 PM To "Malcolm.BETTS@zte.com.cn" , Mach Chen cc "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Dear Malcolm, a quick question, just one, promise, tagged with GIM>> <... snipped ...> [Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers, [MB2] Why? As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format. GIM>> For the datapath the Identifier in OAM message is opaque bit string of length determined by particular type (IP-based or ICC)? Regards, Greg --=_alternative 001D3E008525789A_= Content-Type: text/html; charset="US-ASCII"
Dear Greg,

You are correct.

Regards,

Malcolm



Gregory Mirsky <gregory.mirsky@ericsson.com>

23/05/2011 09:03 PM

To
"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, Mach Chen <mach.chen@huawei.com>
cc
"mpls-bounces@ietf.org" <mpls-bounces@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject
RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?





Dear Malcolm,
 
a quick question, just one, promise, tagged with GIM>>
 
 
<... snipped ...>


[Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers,
[MB2] Why?  As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format.
 
GIM>> For the datapath the Identifier in OAM message is opaque bit string of length determined by particular type (IP-based or ICC)?
 
 
    Regards,
        Greg
--=_alternative 001D3E008525789A_=-- From malcolm.betts@zte.com.cn Mon May 23 22:32: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 2F363E0688; Mon, 23 May 2011 22:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=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 R8rZ48HPfUDb; Mon, 23 May 2011 22:32:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 676D9E0678; Mon, 23 May 2011 22:32:54 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 412301784411434; Tue, 24 May 2011 13:30:21 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 88213.3355180459; Tue, 24 May 2011 13:32:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p4O5WlvF097813; Tue, 24 May 2011 13:32:47 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: Mach Chen MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Tue, 24 May 2011 01:32:37 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-24 13:32:49, Serialize complete at 2011-05-24 13:32:49 Content-Type: multipart/alternative; boundary="=_alternative 001E76108525789A_=" X-MAIL: mse01.zte.com.cn p4O5WlvF097813 Cc: "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 05:32:56 -0000 This is a multipart message in MIME format. --=_alternative 001E76108525789A_= Content-Type: text/plain; charset="US-ASCII" Hi Mach, Please see in line below. Mach Chen wrote on 23/05/2011 10:15:32 PM: > Hi Malcolm, > > Thanks for your prompt response! > > Please see my reply inline... > > > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > > Sent: Tuesday, May 24, 2011 8:42 AM > > To: Mach Chen > > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org > > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > Hi Mach, > > > > Please see in line below - marked by [MB2] > > > > Regards, > > > > Malcolm > > > > Mach Chen > > 22/05/2011 11:34 PM > > To > > "Malcolm.BETTS@zte.com.cn" , > > "adrian@olddog.co.uk" > > cc > > "mpls-bounces@ietf.org" , "mpls@ietf.org" > > > > Subject > > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > Hi Malcolm, > > > > See my response inline. > > > > Ermino, > > > > We have already been round this loop on this list once. > > Want to do it again? > > > > [MB] well the continuation of this thread indicates that the loop > is still open.... > > > > As Huub said, this is about identifiers, not OAM. However, the model for OAM > > interworking shows "layering" not gatewaying, and certainly not mixing. That > > is, > > one end of the e2e path must be capable of operating both systems, but the > > other > > does not need to. > > > > [MB] OK > > > > To extend this model to identifiers means that one end of the e2e path must > > support both identifier formats and the other does not need to. > > > > [MB] It requires that one of the operators must administer both types of > > identifiers. > > [Mach] If mixed identifiers used, seems that all relevant domains > (other than > > only one domain) of the path must administer both types of identifiers, > > > [MB2] Why? > > If it's static provisioning, the operators need to configure(by CLI > or NMS) the identifiers(include both ICC and Global_ID) on the related nodes. > If there is control plane, the control plane has to communicate the > identifiers, and all the nodes along the LSP need to know the type > firstly and hence to interpret and process it [MB] No need for the nodes to understand the semantics, it may be convenient to have an OSS or GUI application that does understand the semantics to assist in provisioning the expected value. The control plane should be able to carry an opaque type. I would expect that when the encoding of these identifiers is defined it will include a "type" flag so that the node knows the length of the identifier field. > > >As I have explained several times on this thread a node that > > receives an OAM message only needs to check that it is from the expected > > entity, no need to understand or administer the format. > > How could a node do that if it does not know the type of the identifier? [MB] Just match the bit string...... > > > and the operators(only prefer to ICC based Opr_ID) have to support and > > configure both ICC and Global_ID style identifier. On the > contrary, for a specific > > LSP or PW, if only one type of identifiers is used, the operators > (only prefer to > > ICC based Opr_ID) can really only need to support and administer > only one type > > of identifiers (ICC) if they get the agreement of using ICC type > of identifier with > > other operators. > > This causes two problems a) A (potentially) new operational process must be > > invoked to assign the second identifier type and; b) Given that a node will > > terminate/originate traffic from/to the local network and a third > party network > > that node will have (different) identifiers, this will cause > significant issues when > > attempting to perform normal operational processes e.g. alarm reporting. > > > > This becomes particularly important to the transit nodes that may have to > > inspect the identifiers. > > > > [MB] Why? only the entity inserting the identifier needs to understand the > > semantics, all other nodes only need to check if the (bit string) presented > > matches the expected string. > > [Mach] Here is an example that the transit nodes may require to > "inspect" the > > identifiers: MPLS-TP control plane. Because Opr_ID is part of the > identifier of an > > LSP, PW and Section, the control plane has to communicate the Opr_IDs of the > > LSP, PW or Section among the relevant nodes when signal the LSP, PW or > > Section. > > [MB2] As defined in the architecture the data plane and control plane must > > be independent, including the identifiers that they use. > > But, MPLS-TP identifiers should be not exclusive to data plane or > control plane or management plane, and actually they are related to > all the three planes. [MB] The identifiers in all three planes are related but the values and type must be independent. > > Best regards, > Mach > > > > BTW, we just submitted two drafts that define extensions to RSVP-TE and PW > > protocol for communicating Opr_ID when setup an LSP or PW. > > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 > > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 > > --=_alternative 001E76108525789A_= Content-Type: text/html; charset="US-ASCII"
Hi Mach,

Please see in line below.

Mach Chen <mach.chen@huawei.com> wrote on 23/05/2011 10:15:32 PM:

> Hi Malcolm,
>
> Thanks for your prompt response!
>
> Please see my reply inline...
>
> > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
> > Sent: Tuesday, May 24, 2011 8:42 AM
> > To: Mach Chen
> > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org
> > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> > Hi Mach,
> >
> > Please see in line below - marked by [MB2]
> >
> > Regards,
> >
> > Malcolm
> >
> > Mach Chen <mach.chen@huawei.com>
> > 22/05/2011 11:34 PM
> > To
> > "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>,
> > "adrian@olddog.co.uk" <adrian@olddog.co.uk>
> > cc
> > "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>, "mpls@ietf.org"
> > <mpls@ietf.org>
> > Subject
> > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> > Hi Malcolm,
> >
> > See my response inline.
> >
> > Ermino,
> >
> > We have already been round this loop on this list once.
> > Want to do it again?
> >
> > [MB] well the continuation of this thread indicates that the loop
> is still open....
> >
> > As Huub said, this is about identifiers, not OAM. However, the model for OAM
> > interworking shows "layering" not gatewaying, and certainly not mixing. That
> > is,
> > one end of the e2e path must be capable of operating both systems, but the
> > other
> > does not need to.
> >
> > [MB] OK
> >
> > To extend this model to identifiers means that one end of the e2e path must
> > support both identifier formats and the other does not need to.
> >
> > [MB] It requires that one of the operators must administer both types of
> > identifiers.
> > [Mach] If mixed identifiers used, seems that all relevant domains
> (other than
> > only one domain) of the path must administer both types of identifiers,
>
> > [MB2] Why?  
>
> If it's static provisioning, the operators need to configure(by CLI
> or NMS) the identifiers(include both ICC and Global_ID) on the related nodes.
> If there is control plane, the control plane has to communicate the
> identifiers, and all the nodes along the LSP need to know the type
> firstly and hence to interpret and process it

[MB] No need for the nodes to understand the semantics, it may be convenient to have an OSS or GUI application that does understand the semantics to assist in provisioning the expected value.  The control plane should be able to carry an opaque type.  I would expect that when the encoding of these identifiers is defined it will include a "type" flag so that the node knows the length of the identifier field.

>
> >As I have explained several times on this thread a node that
> > receives an OAM message only needs to check that it is from the expected
> > entity, no need to understand or administer the format.
>
> How could a node do that if it does not know the type of the identifier?

[MB] Just match the bit string......
 
>
> >  and the operators(only prefer to ICC based Opr_ID) have to support and
> > configure both ICC and Global_ID style identifier. On the
> contrary, for a specific
> > LSP or PW, if only one type of identifiers is used, the operators
> (only prefer to
> > ICC based Opr_ID) can really only need to support and administer
> only one type
> > of identifiers (ICC) if they get the agreement of using ICC type
> of identifier with
> > other operators.
> >  This causes two problems a) A (potentially) new operational process must be
> > invoked to assign the second identifier type and; b) Given that a node will
> > terminate/originate traffic from/to the local network and a third
> party network
> > that node will have (different) identifiers, this will cause
> significant issues when
> > attempting to perform normal operational processes e.g. alarm reporting.
> >
> > This becomes particularly important to the transit nodes that may have to
> > inspect the identifiers.
> >
> > [MB] Why? only the entity inserting the identifier needs to understand the
> > semantics, all other nodes only need to check if the (bit string) presented
> > matches the expected string.
> > [Mach] Here is an example that the transit nodes may require to
> "inspect" the
> > identifiers: MPLS-TP control plane. Because Opr_ID is part of the
> identifier of an
> > LSP, PW and Section, the control plane has to communicate the Opr_IDs of the
> > LSP, PW or Section among the relevant nodes when signal the LSP, PW or
> > Section.
> > [MB2]  As defined in the architecture the data plane and control plane must
> > be independent, including the identifiers that they use.
>
> But, MPLS-TP identifiers should be not exclusive to data plane or
> control plane or management plane, and actually they are related to
> all the three planes.

[MB]  The identifiers in all three planes are related but the values and type must be independent.
>
> Best regards,
> Mach
> >
> > BTW, we just submitted two drafts that define extensions to RSVP-TE and PW
> > protocol for communicating Opr_ID when setup an LSP or PW.
> > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00
> > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00
> >
--=_alternative 001E76108525789A_=-- From neil.2.harrison@bt.com Mon May 23 23:09: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 66336E06BC; Mon, 23 May 2011 23:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=0.060, 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 0XlfXGVSgWzt; Mon, 23 May 2011 23:09:51 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A7E19E0688; Mon, 23 May 2011 23:09:50 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 24 May 2011 07:09:49 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.96]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 24 May 2011 07:09:49 +0100 From: To: , , Date: Tue, 24 May 2011 07:09:44 +0100 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AcwZq6iqTvSBcDrVR+yUzt3LL6hXOQAAebfAAApVu4A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44026404C13@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_6D3D47CB84BDE349BC23BF1C94E316E44026404C13EMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] R: Re: 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, 24 May 2011 06:09:53 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E44026404C13EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Malcolm's answer per se in not sufficient IMO. I would also want to know *= where* the leaking/misconnected traffic/OAM that I am seeing in my network= came from. When I made this point a couple of days ago Malcolm said this could be done= in off-line OSS. Which is indeed feasible. However, it still requires th= at the incoming OAM CV "SA" identifier be known to the receiving party....a= nd this was the point I was making, ie one can't simply generate ad hoc ID = formats even in client/server cases (let alone the unnecessary peering case= ) because when we have layering in co-ps layer networks based on a variable= size traffic unit we can have something that looks like XoverX wrt to the = layer network characteristic information (a case that cannot occur in co-cs= mode transport networks because they always define a fixed resource associ= ated with the 'traffic unit' (=3Dframe)), and thus we can have inter-layer = misconnectivity as well as the more usual intra-layer misconnectivity case. 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 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= gory Mirsky Sent: 24 May 2011 02:04 To: Malcolm.BETTS@zte.com.cn; Mach Chen Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers= ? Dear Malcolm, a quick question, just one, promise, tagged with GIM>> <... snipped ...> ________________________________ [Mach] If mixed identifiers used, seems that all relevant domains (other th= an only one domain) of the path must administer both types of identifiers, [MB2] Why? As I have explained several times on this thread a node that re= ceives an OAM message only needs to check that it is from the expected enti= ty, no need to understand or administer the format. GIM>> For the datapath the Identifier in OAM message is opaque bit string o= f length determined by particular type (IP-based or ICC)? Regards, Greg --_000_6D3D47CB84BDE349BC23BF1C94E316E44026404C13EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

Malcolm’s answer per se in not sufficient IMO.  I would also want to know *where= * the leaking/misconnected  traffic/OAM that I am seeing in my network c= ame from.  

 

When I made this point a couple of days ago Malcolm said this could be done in o= ff-line OSS.  Which is indeed feasible.  However, it still requires that = the incoming OAM CV “SA” identifier be known to the receiving party= ....and this was the point I was making, ie one can’t simply generate ad hoc = ID formats even in client/server cases (let alone the unnecessary peering case= ) because when we have layering in co-ps layer networks based on a variable s= ize traffic unit we can have something that looks like XoverX wrt to the layer network characteristic information (a case that cannot occur in co-cs mode transpor= t networks because they always define a fixed resource associated with the &#= 8216;traffic unit’ (=3Dframe)), and thus we can have inter-layer misconnectivity a= s well as the more usual intra-layer misconnectivity case.

 

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 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

 

 

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: 24 May 2011 02:04
To: Malcolm.BETTS@zte.com.cn; Mach Chen
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Iden= tifiers?

 

Dear Malcolm,

 

a quick question, just one, promise, tagged with GIM>>

 

 

<... snipped ...>

 

[Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types= of identifiers,
[MB2] Why?  As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format. 
  

GIM>> For the datapath the Identifier in OAM message is opaque bit string of length determined by particular type (= IP-based or ICC)?

 

  

    Regards,

        Greg

--_000_6D3D47CB84BDE349BC23BF1C94E316E44026404C13EMV62UKRDdoma_-- From maarten.vissers@huawei.com Mon May 23 23:53: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 E45EDE06B9 for ; Mon, 23 May 2011 23:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 c1S944YkuhGB for ; Mon, 23 May 2011 23:53:48 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2AEE0664 for ; Mon, 23 May 2011 23:53:48 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO004XETTHO5@lhrga04-in.huawei.com> for mpls@ietf.org; Tue, 24 May 2011 07:53:41 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00I8JTTGBT@lhrga04-in.huawei.com> for mpls@ietf.org; Tue, 24 May 2011 07:53:40 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 07:53:35 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 24 May 2011 07:53:39 +0100 Date: Tue, 24 May 2011 06:53:38 +0000 From: Maarten vissers X-Originating-IP: [10.202.112.102] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lVRlQhE0cM0yU323o+ahGA)" Content-language: en-US Accept-Language: en-GB, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMGatrImDxJu5RDUehAq6m8HGoSpSbb0cwgAAb1yA= X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [mpls] R: Re: 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, 24 May 2011 06:53:52 -0000 --Boundary_(ID_lVRlQhE0cM0yU323o+ahGA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT As Malcolm indicates, an ID mismatch process has to determine if there is a match/mismatch between the expected ID and the received ID. Such match/mismatch detection process compares the received bit pattern with the expected bit pattern. There is no need for the mismatch process to understand the structure of the bit patterns. The received and accepted ID bit pattern is reported to NMS/GMPLS on request of NMS/GMPLS. NMS can present the received ID on a GUI. At this point it is helpful if the ID bit pattern is presented as an ICC, Domain Name based sting, MAC address + 2-octet integer or Character string structured ID (case of Ethernet/VPLS), or an ICC or Global-ID structured ID (case of MPLS-TP). In order to present the structured ID correctly on a GUI, the ID should include a format field, format length field and an ID field. Refer to MAID field in clause 21.6.5/802.1ag as an example. Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: 24 May 2011 02:42 To: Mach Chen Cc: mpls-bounces@ietf.org; mpls@ietf.org Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Mach, Please see in line below - marked by [MB2] Regards, Malcolm Mach Chen 22/05/2011 11:34 PM To "Malcolm.BETTS@zte.com.cn" , "adrian@olddog.co.uk" cc "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, See my response inline... Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still open.... As Huub said, this is about identifiers, not OAM. However, the model for OAM interworking shows "layering" not gatewaying, and certainly not mixing. That is, one end of the e2e path must be capable of operating both systems, but the other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of identifiers. [Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers, [MB2] Why? As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format. and the operators(only prefer to ICC based Opr_ID) have to support and configure both ICC and Global_ID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr_ID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators. This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string. [Mach] Here is an example that the transit nodes may require to "inspect" the identifiers: MPLS-TP control plane. Because Opr_ID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr_IDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section. [MB2] As defined in the architecture the data plane and control plane must be independent, including the identifiers that they use. Best regards, Mach BTW, we just submitted two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr_ID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian --Boundary_(ID_lVRlQhE0cM0yU323o+ahGA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

As Malcolm indicates, an ID mismatch process has to determine if there is a match/mismatch between the expected ID and the received ID.  Such match/mismatch detection process compares the received bit pattern with the expected bit pattern. There is no need for the mismatch process to understand the structure of the bit patterns.

 

The received and accepted ID bit pattern is reported to NMS/GMPLS on request of NMS/GMPLS. NMS can present the received ID on a GUI. At this point it is helpful if the ID bit pattern is presented as an ICC, Domain Name based sting, MAC address + 2-octet integer or Character string  structured ID (case of Ethernet/VPLS), or an ICC or Global-ID structured ID (case of MPLS-TP). In order to present the structured ID correctly on a GUI, the ID should include a format field, format length field and an ID field. Refer to MAID field in clause 21.6.5/802.1ag as an example.

 

Regards,

Maarten

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn
Sent: 24 May 2011 02:42
To: Mach Chen
Cc: mpls-bounces@ietf.org; mpls@ietf.org
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

 


Hi Mach,

Please see in line below - marked by [MB2]

Regards,

Malcolm

Mach Chen <mach.chen@huawei.com>

22/05/2011 11:34 PM

To

"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>

cc

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

Subject

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

 




Hi Malcolm,
 
See my response inline…
 

Ermino,

We have already been round this loop on this list once.
Want to do it again?

[MB] well the continuation of this thread indicates that the loop is still open....

As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.

[MB] OK

To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.

[MB] It requires that one of the operators must administer both types of identifiers.
[Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers,
[MB2] Why?  As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format.
 and the operators(only prefer to ICC based Opr_ID) have to support and configure both ICC and Global_ID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr_ID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators.
 This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

This becomes particularly important to the transit nodes that may have to
inspect the identifiers.

[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string.
[Mach] Here is an example that the transit nodes may require to “inspect” the identifiers: MPLS-TP control plane. Because Opr_ID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr_IDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section.
[MB2]  As defined in the architecture the data plane and control plane must be independent, including the identifiers that they use.
Best regards,
Mach
 
BTW, we just submitted two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr_ID when setup an LSP or PW.
http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00
http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00

None of this is new or specific to MPLS-TP.

Adrian

--Boundary_(ID_lVRlQhE0cM0yU323o+ahGA)-- From mach.chen@huawei.com Tue May 24 01:28: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 5A521E0706; Tue, 24 May 2011 01:28:48 -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=0.400, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 r7oMAyMx-I2u; Tue, 24 May 2011 01:28:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E2CBFE0704; Tue, 24 May 2011 01:28:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00BK4Y7M5S@szxga04-in.huawei.com>; Tue, 24 May 2011 16:28:37 +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 <0LLO00MJ3Y725C@szxga04-in.huawei.com>; Tue, 24 May 2011 16:28:33 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 16:28:28 +0800 Received: from SZXEML502-MBX.china.huawei.com ([169.254.6.52]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 24 May 2011 16:28:30 +0800 Date: Tue, 24 May 2011 08:28:29 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.39] To: "Malcolm.BETTS@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwT7QXSM6/mFcE6u13UrRuHfH5SXc3wAgAIxuFCAAP18AIAAigmAgAAASwD//8bQgIAAocEQgAAAISA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "mpls-bounces@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] R: Re: 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, 24 May 2011 08:28:48 -0000 Hi Malcolm, Thanks for your response! Firstly, I have to claim that I do not object mixed identifier if there are= cases really need it.=20 >From the discussion on this thread, it's very clear that mixed identifiers = at least require control plane and management plane has to understand and s= upport the semantic of both ICC and Global_ID based identifiers. This means= that the operators have to operate both ICC and Global_ID based identifier= s when do mixed identifiers. If the purpose of mixed identifiers is to help= one operator (e.g., only prefers to ICC style) to avoid operating/maintain= ing unfamiliar identifier scheme (e.g., Global_ID) when do inter-domain con= nection, obviously, it cannot work. On the contrary, as many other guys on = the list pointed out, if the same format identifier is used for a specific = path, the domain one end hosting can really only need to support and admini= ster one type of identifier.=20 Best regards, Mach > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > Sent: Tuesday, May 24, 2011 1:33 PM > To: Mach Chen > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifie= rs? >=20 >=20 > Hi Mach, >=20 > Please see in line below. >=20 > Mach Chen wrote on 23/05/2011 10:15:32 PM: >=20 > > Hi Malcolm, > > > > Thanks for your prompt response! > > > > Please see my reply inline... > > > > > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > > > Sent: Tuesday, May 24, 2011 8:42 AM > > > To: Mach Chen > > > Cc: adrian@olddog.co.uk; mpls@ietf.org; mpls-bounces@ietf.org > > > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Ident= ifiers? > > > > > > Hi Mach, > > > > > > Please see in line below - marked by [MB2] > > > > > > Regards, > > > > > > Malcolm > > > > > > Mach Chen > > > 22/05/2011 11:34 PM > > > To > > > "Malcolm.BETTS@zte.com.cn" , > > > "adrian@olddog.co.uk" > > > cc > > > "mpls-bounces@ietf.org" , "mpls@ietf.org" > > > > > > Subject > > > RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > > > > Hi Malcolm, > > > > > > See my response inline. > > > > > > Ermino, > > > > > > We have already been round this loop on this list once. > > > Want to do it again? > > > > > > [MB] well the continuation of this thread indicates that the loop > > is still open.... > > > > > > As Huub said, this is about identifiers, not OAM. However, the model = for > OAM > > > interworking shows "layering" not gatewaying, and certainly not mixin= g. > That > > > is, > > > one end of the e2e path must be capable of operating both systems, bu= t the > > > other > > > does not need to. > > > > > > [MB] OK > > > > > > To extend this model to identifiers means that one end of the e2e pat= h must > > > support both identifier formats and the other does not need to. > > > > > > [MB] It requires that one of the operators must administer both types= of > > > identifiers. > > > [Mach] If mixed identifiers used, seems that all relevant domains > > (other than > > > only one domain) of the path must administer both types of identifier= s, > > > > > [MB2] Why? > > > > If it's static provisioning, the operators need to configure(by CLI > > or NMS) the identifiers(include both ICC and Global_ID) on the related = nodes. > > If there is control plane, the control plane has to communicate the > > identifiers, and all the nodes along the LSP need to know the type > > firstly and hence to interpret and process it >=20 > [MB] No need for the nodes to understand the semantics, it may be conveni= ent > to have an OSS or GUI application that does understand the semantics to a= ssist > in provisioning the expected value. =A0The control plane should be able t= o carry > an opaque type. =A0I would expect that when the encoding of these identif= iers is > defined it will include a "type" flag so that the node knows the length o= f the > identifier field. >=20 > > > > >As I have explained several times on this thread a node that > > > receives an OAM message only needs to check that it is from the expec= ted > > > entity, no need to understand or administer the format. > > > > How could a node do that if it does not know the type of the identifier= ? >=20 > [MB] Just match the bit string...... >=20 > > > > > =A0and the operators(only prefer to ICC based Opr_ID) have to support= and > > > configure both ICC and Global_ID style identifier. On the > > contrary, for a specific > > > LSP or PW, if only one type of identifiers is used, the operators > > (only prefer to > > > ICC based Opr_ID) can really only need to support and administer > > only one type > > > of identifiers (ICC) if they get the agreement of using ICC type > > of identifier with > > > other operators. > > > =A0This causes two problems a) A (potentially) new operational proces= s must > be > > > invoked to assign the second identifier type and; b) Given that a nod= e will > > > terminate/originate traffic from/to the local network and a third > > party network > > > that node will have (different) identifiers, this will cause > > significant issues when > > > attempting to perform normal operational processes e.g. alarm reporti= ng. > > > > > > This becomes particularly important to the transit nodes that may hav= e to > > > inspect the identifiers. > > > > > > [MB] Why? only the entity inserting the identifier needs to understan= d the > > > semantics, all other nodes only need to check if the (bit string) pre= sented > > > matches the expected string. > > > [Mach] Here is an example that the transit nodes may require to > > "inspect" the > > > identifiers: MPLS-TP control plane. Because Opr_ID is part of the > > identifier of an > > > LSP, PW and Section, the control plane has to communicate the Opr_IDs= of > the > > > LSP, PW or Section among the relevant nodes when signal the LSP, PW o= r > > > Section. > > > [MB2] =A0As defined in the architecture the data plane and control pl= ane > must > > > be independent, including the identifiers that they use. > > > > But, MPLS-TP identifiers should be not exclusive to data plane or > > control plane or management plane, and actually they are related to > > all the three planes. >=20 > [MB] =A0The identifiers in all three planes are related but the values an= d type > must be independent. > > > > Best regards, > > Mach > > > > > > BTW, we just submitted two drafts that define extensions to RSVP-TE a= nd > PW > > > protocol for communicating Opr_ID when setup an LSP or PW. > > > http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 > > > http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 > > > From yakov@juniper.net Tue May 24 14:49: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 A32F1E0782 for ; Tue, 24 May 2011 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, 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 64h12enzxj6h for ; Tue, 24 May 2011 14:49:32 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id B9DF6E0753 for ; Tue, 24 May 2011 14:49:25 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwn5eYED3srTLbMaOWFwRPHX/H+Io0M@postini.com; Tue, 24 May 2011 14:49:31 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; Tue, 24 May 2011 14:47: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 p4OLlcv77150; Tue, 24 May 2011 14:47:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105242147.p4OLlcv77150@magenta.juniper.net> To: Loa Andersson In-Reply-To: <4DCBE7BE.5010708@pi.nu> References: <4DCBE7BE.5010708@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Thu, 12 May 2011 15:59:26 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85026.1306273658.1@juniper.net> Date: Tue, 24 May 2011 14:47:38 -0700 From: Yakov Rekhter Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 24 May 2011 21:49:32 -0000 Loa, yes/support Yakov > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > 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 on May 27th. > > /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 wim.henderickx@alcatel-lucent.com Tue May 24 18:19:07 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 634D7E0753 for ; Tue, 24 May 2011 18:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 2-OZ1YsSURfY for ; Tue, 24 May 2011 18:19:06 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 868F7E0695 for ; Tue, 24 May 2011 18:19:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4P1J4R4027021 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 03:19:05 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 May 2011 03:19:05 +0200 From: "Henderickx, Wim (Wim)" To: Yakov Rekhter , Loa Andersson Date: Wed, 25 May 2011 03:19:02 +0200 Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: AcwaXIXknwItX/HaRpyfL8CnSg+TGgAHTHQg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67192FC552@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4DCBE7BE.5010708@pi.nu> <201105242147.p4OLlcv77150@magenta.juniper.net> In-Reply-To: <201105242147.p4OLlcv77150@magenta.juniper.net> 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.84 Cc: Ross Callon , "mpls@ietf.org" , "draft-raggarwa-mpls-seamless-mcast@tools.ietf.org" Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 25 May 2011 01:19:07 -0000 Yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Yak= ov Rekhter Sent: dinsdag 24 mei 2011 23:48 To: Loa Andersson Cc: Ross Callon; mpls@ietf.org; draft-raggarwa-mpls-seamless-mcast@tools.ie= tf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Loa, yes/support Yakov > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-raggarwa-mpls-seamless-mcast-03.txt >=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 on May 27th. >=20 > /Loa >=20 > --=20 >=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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lieven.levrau@alcatel-lucent.com Wed May 25 00:14: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 15C74E06BE for ; Wed, 25 May 2011 00:14:12 -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 SpgbaSXXAfYc for ; Wed, 25 May 2011 00:14:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA6C2E069A for ; Wed, 25 May 2011 00:14:10 -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 p4P7DMJF031754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 09:14:08 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 May 2011 09:14:01 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: Loa Andersson Date: Wed, 25 May 2011 09:13:59 +0200 Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: Acwaq1IhgVvjUpSZQwOMeJ8tXd6glQ== Message-ID: In-Reply-To: <201105242147.p4OLlcv77150@magenta.juniper.net> 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.83 Cc: Ross Callon , "mpls@ietf.org" , "draft-raggarwa-mpls-seamless-mcast@tools.ietf.org" Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 25 May 2011 07:14:12 -0000 Yes support ./ Lieve On 24/05/11 23:47, "Yakov Rekhter" wrote: >Loa, > >yes/support > >Yakov > >> Working Group, >>=20 >> this is to start a two week poll on making >>=20 >> draft-raggarwa-mpls-seamless-mcast-03.txt >>=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 on May 27th. >>=20 >> /Loa >>=20 >> --=20 >>=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 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From adrian@olddog.co.uk Wed May 25 02:13:33 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 637F0E06DF for ; Wed, 25 May 2011 02:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, 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 Naef6OfRT+P0 for ; Wed, 25 May 2011 02:13:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 60AAD13000C for ; Wed, 25 May 2011 02:13:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p4P96ZGG029582 for ; Wed, 25 May 2011 10:06:35 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p4P96XUg029572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 May 2011 10:06:34 +0100 From: "Adrian Farrel" To: References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 25 May 2011 10:13:25 +0100 Message-ID: <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQHG5/PmLYrQ8+eFrUY9iVN8MbLCbwL1LhofAUC+QiIBxGdVfJR31IKw Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:13:33 -0000 Hi Neil, I'm not assuming peering. I am actually pointing out to Huub that = (despite what he keeps saying) he is also not assuming peering. The consequence of not peering is that a single identifier mode is used = for both ends of an OAM "session". And that means that one end has to = understand *and* use the "foreign" format at the remote end of the = session. I am tired of this discussion. There seems to be no forward progress = only restatement of a "want". I always wanted a pony when I was a little = girl, but I never got one. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > neil.2.harrison@bt.com > Sent: 22 May 2011 20:36 > To: huubatwork@gmail.com; mpls@ietf.org > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP = Identifiers? >=20 > Hi Adrian/Huub, >=20 > You are largely assuming some form of peering (single partitioned = layer network) > here...and that model will generate a whole raft of problems for = operators IMO. > A more important model for a co-ps transport network is client/server. = And now > not only have we the usual intra-layer misconnectivity to deal with = but we also > have inter-layer misconnectivity...and this means each operating party = must > understand the OAM formats (and CV IDs) of each other anyway... not = simply to > detect there is a misconnectivity problems but also to identify which = other parties > are involved. >=20 > regards, Neil >=20 > 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. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > > Huub van Helvoort > > Sent: 22 May 2011 19:15 > > To: mpls@ietf.org > > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > > Identifiers? > > > > Hi Adrian, > > > > See my response in-line [hvh] > > > > > We have already been round this loop on this list once. > > > Want to do it again? > > > > [hvh] If it helps to get to the focal point, why not. > > > > > As Huub said, this is about identifiers, not OAM. However, the = model > > for OAM > > > interworking shows "layering" not gatewaying, and certainly not > > mixing. That is, > > > one end of the e2e path must be capable of operating both systems, > > but the other > > > does not need to. > > > > [hvh] OK if you mean "OAM toolsets" by "systems" > > > > > To extend this model to identifiers means that one end of the e2e > > path must > > > support both identifier formats and the other does not need to. > > > > [hvh] to be more specific the originating end of an e2e path must > > be able to support one of the possible identifier formats, normally > > the identifier format of the local operator. The terminating end and > > the intermediate points of an e2e path must be able to verify the > > format inserted at the origin independent of the locally used > > identifier > > format. This means that it must be possible to support different > > identifier formats in the A-->Z ans Z-->A direction of an e2e path. > > I.e. mixing of identifier formats must be supported. > > > > > This becomes particularly important to the transit nodes that may > > have to > > > inspect the identifiers. > > > > [hvh] the inspection will consist of comparing a received value > > with an expected value which can have any format. > > > > > None of this is new or specific to MPLS-TP. > > > > [hvh] I agree, mixing of identifier formats it not restricted to > > MPLS-TP. > > > > Regards, Huub. > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf > > Of > > >> erminio.ottone_69@libero.it > > >> Sent: 18 May 2011 22:25 > > >> To: loa@pi.nu; mpls@ietf.org; Malcolm.BETTS@zte.com.cn > > >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > > Identifiers? > > >> > > >> Appendix II of Y.1731 provides a good example about how = inter-domain > > >> connectivity with e2e OAM can be provided using = transport-oriented > > OAM > > >> functions. > > >> > > >> You can download the latest version of Y.1731 (the pdr version is > > for free) at > > >> the following URL: > > >> > > >> http://www.itu.int/rec/T-REC-Y.1731/en > > >> > > >> It is a pity that with the current version of the identifier = draft, > > MPLS-TP is > > >> not capable to support such a network scenario. > > >> > > >>> ----Messaggio originale---- > > >>> Da: loa@pi.nu > > >>> Data: 4-mag-2011 8.00 > > >>> A:, > > >> "Malcolm.BETTS@zte.com.cn" > > >>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP = Identifiers? > > >>> > > >>> Malcolm, > > >>> > > >>> are you saying that operators today allow OAM to control node = (MIPs > > and > > >>> MEPs) on each others networks? > > >>> > > >>> Do we have an operator that can verify this? > > >>> > > >>> /Loa > > >>> > > >>> On 2011-05-03 22:44, Malcolm.BETTS@zte.com.cn wrote: > > >>>> > > >>>> All, > > >>>> > > >>>> I share your concerns and doubts about a multi carrier control > > plane. > > >>>> However, I think that it is essential that a transport network > > supports > > >>>> multi carrier data plane interconnection with end to end OAM. = In > > today's > > >>>> transport network this interconnection is supported by SDH and > > OTN. The > > >>>> objective for MPLS-TP is to allow for packet based = interconnection > > as > > >> well. > > >>>> > > >>>> Regards, > > >>>> > > >>>> Malcolm > > >>>> > > >>>> > > >>>> > > >>>> *George Swallow* > > >>>> Sent by: mpls-bounces@ietf.org > > >>>> > > >>>> 03/05/2011 11:09 AM > > >>>> > > >>>> > > >>>> To > > >>>> "Andrew G. Malis", > > >>>> cc > > >>>> mpls@ietf.org > > >>>> Subject > > >>>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Andy - > > >>>> > > >>>> > Such > > >>>> > an E-NNI definition does not yet exist for MPLS-TP = (something > > else to > > >>>> > put on the to-do list). This E-NNI would also include = similar > > >>>> > identifier mapping/translation for MS-PWs, to answer an > > earlier > > >>>> > question from Erminio that I saw on the list. > > >>>> > > >>>> You are quite correct here! I think much of this debate = surrounds > > a > > >> problem > > >>>> that is yet to be solved. So there are arguments for pieces of = a > > solution > > >>>> without and overall architecture. > > >>>> > > >>>> Based on all that I am seeing my inclination is to NOT say that = we > > >> disallow > > >>>> mixed identifiers, but to say that they are for future study. > > >>>> > > >>>> ...George > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On 5/3/11 8:38 AM, "Andrew G. Malis" wrote: > > >>>> > > >>>> > Neil, > > >>>> > > > >>>> > To your case 1, we're in complete agreement. We (VZ) don't > > see at > > >>>> > least a short-term need for peer-layer interworking, given > > where we > > >>>> > intend to deploy MPLS-TP in our infrastructure (as an > > internal server > > >>>> > layer in the transport core). If peer layer interworking = ever > > becomes > > >>>> > a necessity, then obviously we'll need a well-defined = E-NNI > > which > > >>>> > would include LSP identifier mapping/translation at the > > boundary, for > > >>>> > LSP provisioning (whether static or dynamic) and = end-to-end > > OAM. Such > > >>>> > an E-NNI definition does not yet exist for MPLS-TP = (something > > else to > > >>>> > put on the to-do list). This E-NNI would also include = similar > > >>>> > identifier mapping/translation for MS-PWs, to answer an > > earlier > > >>>> > question from Erminio that I saw on the list. > > >>>> > > > >>>> > I also agree that both intra-layer and inter-layer mis- > > connectivity > > >>>> > detection and amelioration are required, but I'm not > > convinced that > > >>>> > the already defined mechanisms can't do that. Do you have > > some > > >>>> > specific analysis on the inter-layer case? > > >>>> > > > >>>> > Cheers, > > >>>> > Andy > > >>>> > > > >>>> > On Tue, May 3, 2011 at 3:36 AM, > > wrote: > > >>>> >> Hi Andy, > > >>>> >> > > >>>> >> 2 points: > > >>>> >> > > >>>> >> 1 I agree with your view of only having a single = addressing > > scheme in > > >> a > > >>>> >> single layer network solely belonging to one party. = Though > > you may > > >>>> need to > > >>>> >> be rather careful if you also advocate that one can also > > have peer > > >> layer > > >>>> >> interworking between different parties, ie E-NNIs (I = believe > > this is > > >>>> >> something you may support, eg old MPLSF case?). In such a > > peer > > >>>> interworking > > >>>> >> case it would seem one must allow different addressing > > schemes (and > > >>>> indeed > > >>>> >> any other variations in DP/CP functional components) if = they > > exist > > >>>> in the > > >>>> >> standards. > > >>>> >> > > >>>> >> Of course, having an E-NNI and peer interworking between > > different > > >>>> parties in > > >>>> >> any non-TOS layer network (not just MPLS) is not = technically > > >>>> necessary (this > > >>>> >> is trivial to prove), and this provides a strong argument > > for only > > >>>> having a > > >>>> >> single addressing scheme in a non-TOS layer network. > > >>>> >> > > >>>> >> > > >>>> >> 2 You should also be aware that in client/server > > interworking of the > > >>>> >> co-ps mode using variable size traffic units, and = therefore > > >>>> something rather > > >>>> >> important for MPLS-TP in the role of a transport network > > (I'll > > >>>> ignore issues > > >>>> >> of transparency here), there could be inter-layer > > misconnectivity > > >>>> (Aside=3D> > > >>>> >> This case cannot occur in the co-cs mode). To date, = however, > > we have > > >>>> only > > >>>> >> really considered intra-layer misconnectivity, ie between > > different > > >> LSPs > > >>>> >> belonging to the same party (note this also includes all > > cases of > > >>>> nested LSP > > >>>> >> sublayer misconnectivity). > > >>>> >> > > >>>> >> In the case of inter-layer misconnectivity one may = receive > > traffic > > >>>> units and > > >>>> >> OAM messages from some other party's layer network. The = OAM > > >> messages > > >> may > > >>>> >> come from (i) networks using different OAM/addressing > > solutions or > > >> (ii) > > >>>> >> networks using the same OAM/addressing solutions. In both > > cases > > >>>> there are > > >>>> >> different issues wrt inter-layer misconnectivity one has = to > > deal > > >>>> with. I'm > > >>>> >> not aware that these cases have been considered yet. > > >>>> >> > > >>>> >> > > >>>> >> I'd like to hear your comments on both these points, but = in > > >>>> particular the > > >>>> >> first one.....especially if you also support the notion = of > > E-NNIs in > > >>>> MPLS-TP, > > >>>> >> as there seems to a possible logical conflict here. > > >>>> >> > > >>>> >> Thanks. > > >>>> >> > > >>>> >> regards, 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. > > >>>> >> British Telecommunications plc > > >>>> >> Registered office: 81 Newgate Street London EC1A 7AJ > > >>>> >> Registered in England no: 1800000 > > >>>> >> > > >>>> >>> -----Original Message----- > > >>>> >>> From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] > > On Behalf > > >> Of > > >>>> >>> Andrew G. Malis > > >>>> >>> Sent: 02 May 2011 20:48 > > >>>> >>> To: George Swallow > > >>>> >>> Cc: mpls@ietf.org > > >>>> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP > > Identifiers? > > >>>> >>> > > >>>> >>> George et al, > > >>>> >>> > > >>>> >>> Verizon does not have any requirement for mixed use of > > Global IDs and > > >>>> >>> ICCs. We are fine with specifications that require both > > ends of an > > >> LSP > > >>>> >>> to use one or the other. > > >>>> >>> > > >>>> >>> Thanks, > > >>>> >>> Andy > > >>>> >>> > > >>>> >>> On Mon, Apr 25, 2011 at 5:16 PM, George > > Swallow > > >>>> >>> wrote: > > >>>> >>>> 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. > > >>>> >>>> > > >>>> >>>> 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. > > >>>> >>>> > > >>>> >>>> We are looking for input/consensus from the WG. > > >>>> >>>> > > >>>> >>>> George, Eric,& Matthew > > > > > > -- > > > ************************************************************** > *** > > = =E6=88=91=E7=88=B1=E5=A4=96=E7=82=B9=E4=B8=80=E4=B8=83=E4=B8=89=E4=B8=80 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From maarten.vissers@huawei.com Wed May 25 02:41: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 CEFE0E07D4 for ; Wed, 25 May 2011 02:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 J6i-zTeExtE8 for ; Wed, 25 May 2011 02:41:35 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id F1D22E0701 for ; Wed, 25 May 2011 02:41:34 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00CZBW994R@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 10:41:33 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLQ00FCJW9881@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 10:41:32 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 10:41:25 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 25 May 2011 10:41:31 +0100 Date: Wed, 25 May 2011 09:41:30 +0000 From: Maarten vissers In-reply-to: <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> X-Originating-IP: [10.202.112.103] To: "adrian@olddog.co.uk" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-GB, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0Q X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> Subject: Re: [mpls] R: Re: 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, 25 May 2011 09:41:36 -0000 QWRyaWFuLA0KDQpQbGVhc2UgYmUgYXdhcmUgdGhhdCB1bmRlciBmYXVsdCBjb25kaXRpb25zIGFu IElDQyBmb3JtYXR0ZWQgSUQgY2FuIGJlIHJlY2VpdmVkIGJ5IGFuIGVuZHBvaW50IHVzaW5nIGEg R2xvYmFsX0lEIGZvcm1hdHRlZCBJRCwgYW5kIHZpY2UgdmVyc2EuIEVpdGhlciBlbmRwb2ludCBt dXN0IGJlIGFibGUgdG8gZGV0ZWN0IGEgbWlzY29ubmVjdGlvbiBjb25kaXRpb24gYW5kIGJlIGFi bGUgdG8gcmVwb3J0IHRoZSByZWNlaXZlZCBJRCAoaW4gdGhlIG5vbi1leHBlY3RlZCBmb3JtYXQp IHRvIE5NUyB0byBndWlkZSBpbiB0aGUgZmF1bHQgbG9jYWxpc2F0aW9uLg0KDQpOb3RlIHRoYXQg d2Ugb3Zlcmxvb2tlZCBhIHNpbWlsYXIgcmVxdWlyZW1lbnQgaW5pdGlhbGx5IGluIFNESCAoMTYt Ynl0ZSBUVEkgYW5kIDY0LWJ5dGUgVFRJKSwgYW5kIHRoaXMgcmVxdWlyZWQgdXMgdG8gdXBncmFk ZSBvdXIgVkMtbiBlbmRwb2ludHMgYWZ0ZXJ3YXJkcy4gTGV0J3Mgbm90IG1ha2UgYSBzaW1pbGFy IG1pc3Rha2UgaW4gTVBMUy1UUC4NCg0KUmVnYXJkcywNCk1hYXJ0ZW4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBBZHJpYW4gRmFycmVsDQo+IFNl bnQ6IDI1IE1heSAyMDExIDExOjEzDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiBJ ZGVudGlmaWVycz8NCj4gDQo+IEhpIE5laWwsDQo+IA0KPiBJJ20gbm90IGFzc3VtaW5nIHBlZXJp bmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcgb3V0IHRvIEh1dWIgdGhhdA0KPiAoZGVzcGl0ZSB3 aGF0IGhlIGtlZXBzIHNheWluZykgaGUgaXMgYWxzbyBub3QgYXNzdW1pbmcgcGVlcmluZy4NCj4g DQo+IFRoZSBjb25zZXF1ZW5jZSBvZiBub3QgcGVlcmluZyBpcyB0aGF0IGEgc2luZ2xlIGlkZW50 aWZpZXIgbW9kZSBpcyB1c2VkDQo+IGZvciBib3RoIGVuZHMgb2YgYW4gT0FNICJzZXNzaW9uIi4g QW5kIHRoYXQgbWVhbnMgdGhhdCBvbmUgZW5kIGhhcyB0bw0KPiB1bmRlcnN0YW5kICphbmQqIHVz ZSB0aGUgImZvcmVpZ24iIGZvcm1hdCBhdCB0aGUgcmVtb3RlIGVuZCBvZiB0aGUNCj4gc2Vzc2lv bi4NCj4gDQo+IEkgYW0gdGlyZWQgb2YgdGhpcyBkaXNjdXNzaW9uLiBUaGVyZSBzZWVtcyB0byBi ZSBubyBmb3J3YXJkIHByb2dyZXNzDQo+IG9ubHkgcmVzdGF0ZW1lbnQgb2YgYSAid2FudCIuIEkg YWx3YXlzIHdhbnRlZCBhIHBvbnkgd2hlbiBJIHdhcyBhDQo+IGxpdHRsZSBnaXJsLCBidXQgSSBu ZXZlciBnb3Qgb25lLg0KPiANCj4gQWRyaWFuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YNCj4gPiBuZWlsLjIuaGFycmlzb25AYnQuY29t DQo+ID4gU2VudDogMjIgTWF5IDIwMTEgMjA6MzYNCj4gPiBUbzogaHV1YmF0d29ya0BnbWFpbC5j b207IG1wbHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcg SUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4gSWRlbnRpZmllcnM/DQo+ID4NCj4gPiBI aSBBZHJpYW4vSHV1YiwNCj4gPg0KPiA+IFlvdSBhcmUgbGFyZ2VseSBhc3N1bWluZyBzb21lIGZv cm0gb2YgcGVlcmluZyAoc2luZ2xlIHBhcnRpdGlvbmVkDQo+IGxheWVyIG5ldHdvcmspDQo+ID4g aGVyZS4uLmFuZCB0aGF0IG1vZGVsIHdpbGwgZ2VuZXJhdGUgYSB3aG9sZSByYWZ0IG9mIHByb2Js ZW1zIGZvcg0KPiBvcGVyYXRvcnMgSU1PLg0KPiA+IEEgbW9yZSBpbXBvcnRhbnQgbW9kZWwgZm9y IGEgY28tcHMgdHJhbnNwb3J0IG5ldHdvcmsgaXMNCj4gY2xpZW50L3NlcnZlci4gIEFuZCBub3cN Cj4gPiBub3Qgb25seSBoYXZlIHdlIHRoZSB1c3VhbCBpbnRyYS1sYXllciBtaXNjb25uZWN0aXZp dHkgdG8gZGVhbCB3aXRoDQo+IGJ1dCB3ZSBhbHNvDQo+ID4gaGF2ZSBpbnRlci1sYXllciBtaXNj b25uZWN0aXZpdHkuLi5hbmQgdGhpcyBtZWFucyBlYWNoIG9wZXJhdGluZw0KPiBwYXJ0eSBtdXN0 DQo+ID4gdW5kZXJzdGFuZCB0aGUgT0FNIGZvcm1hdHMgKGFuZCBDViBJRHMpIG9mIGVhY2ggb3Ro ZXIgYW55d2F5Li4uIG5vdA0KPiBzaW1wbHkgdG8NCj4gPiBkZXRlY3QgdGhlcmUgaXMgYSBtaXNj b25uZWN0aXZpdHkgcHJvYmxlbXMgYnV0IGFsc28gdG8gaWRlbnRpZnkgd2hpY2gNCj4gb3RoZXIg cGFydGllcw0KPiA+IGFyZSBpbnZvbHZlZC4NCj4gPg0KPiA+IHJlZ2FyZHMsIE5laWwNCj4gPg0K PiA+IEJUIERlc2lnbg0KPiA+IFRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdo aWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNvbmZpZGVudGlhbC4NCj4gPiBJdCdzIG1lYW50 IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYNCj4g eW91J3JlIG5vdCB0aGUNCj4gPiBpbnRlbmRlZA0KPiA+IHJlY2lwaWVudCwgbm90ZSB0aGF0IGRp c2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzDQo+IGluZm9ybWF0 aW9uDQo+ID4gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBsZXQgbWUNCj4ga25vdw0KPiA+IGltbWVkaWF0ZWx5DQo+ID4gb24gdGhl IGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4gPiBXZSBtb25pdG9yIG91ciBlbWFp bCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KPiA+IEJyaXRpc2ggVGVsZWNv bW11bmljYXRpb25zIHBsYw0KPiA+IFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVl dCBMb25kb24gRUMxQSA3QUoNCj4gPiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAwMDAN Cj4gPg0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG cm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uDQo+IEJlaGFsZiBPZg0KPiA+ID4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gPiA+IFNlbnQ6IDIy IE1heSAyMDExIDE5OjE1DQo+ID4gPiBUbzogbXBsc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDog UmU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+DQo+ID4gPiBIaSBBZHJpYW4sDQo+ID4gPg0KPiA+ID4g U2VlIG15IHJlc3BvbnNlIGluLWxpbmUgW2h2aF0NCj4gPiA+DQo+ID4gPiA+IFdlIGhhdmUgYWxy ZWFkeSBiZWVuIHJvdW5kIHRoaXMgbG9vcCBvbiB0aGlzIGxpc3Qgb25jZS4NCj4gPiA+ID4gV2Fu dCB0byBkbyBpdCBhZ2Fpbj8NCj4gPiA+DQo+ID4gPiBbaHZoXSBJZiBpdCBoZWxwcyB0byBnZXQg dG8gdGhlIGZvY2FsIHBvaW50LCB3aHkgbm90Lg0KPiA+ID4NCj4gPiA+ID4gQXMgSHV1YiBzYWlk LCB0aGlzIGlzIGFib3V0IGlkZW50aWZpZXJzLCBub3QgT0FNLiBIb3dldmVyLCB0aGUNCj4gbW9k ZWwNCj4gPiA+IGZvciBPQU0NCj4gPiA+ID4gaW50ZXJ3b3JraW5nIHNob3dzICJsYXllcmluZyIg bm90IGdhdGV3YXlpbmcsIGFuZCBjZXJ0YWlubHkgbm90DQo+ID4gPiBtaXhpbmcuIFRoYXQgaXMs DQo+ID4gPiA+IG9uZSBlbmQgb2YgdGhlIGUyZSBwYXRoIG11c3QgYmUgY2FwYWJsZSBvZiBvcGVy YXRpbmcgYm90aA0KPiBzeXN0ZW1zLA0KPiA+ID4gYnV0IHRoZSBvdGhlcg0KPiA+ID4gPiBkb2Vz IG5vdCBuZWVkIHRvLg0KPiA+ID4NCj4gPiA+IFtodmhdIE9LIGlmIHlvdSBtZWFuICJPQU0gdG9v bHNldHMiIGJ5ICJzeXN0ZW1zIg0KPiA+ID4NCj4gPiA+ID4gVG8gZXh0ZW5kIHRoaXMgbW9kZWwg dG8gaWRlbnRpZmllcnMgbWVhbnMgdGhhdCBvbmUgZW5kIG9mIHRoZSBlMmUNCj4gPiA+IHBhdGgg bXVzdA0KPiA+ID4gPiBzdXBwb3J0IGJvdGggaWRlbnRpZmllciBmb3JtYXRzIGFuZCB0aGUgb3Ro ZXIgZG9lcyBub3QgbmVlZCB0by4NCj4gPiA+DQo+ID4gPiBbaHZoXSB0byBiZSBtb3JlIHNwZWNp ZmljIHRoZSBvcmlnaW5hdGluZyBlbmQgb2YgYW4gZTJlIHBhdGggbXVzdA0KPiA+ID4gYmUgYWJs ZSB0byBzdXBwb3J0IG9uZSBvZiB0aGUgcG9zc2libGUgaWRlbnRpZmllciBmb3JtYXRzLCBub3Jt YWxseQ0KPiA+ID4gdGhlIGlkZW50aWZpZXIgZm9ybWF0IG9mIHRoZSBsb2NhbCBvcGVyYXRvci4g VGhlIHRlcm1pbmF0aW5nIGVuZA0KPiBhbmQNCj4gPiA+IHRoZSBpbnRlcm1lZGlhdGUgcG9pbnRz IG9mIGFuIGUyZSBwYXRoIG11c3QgYmUgYWJsZSB0byB2ZXJpZnkgdGhlDQo+ID4gPiBmb3JtYXQg aW5zZXJ0ZWQgYXQgdGhlIG9yaWdpbiBpbmRlcGVuZGVudCBvZiB0aGUgbG9jYWxseSB1c2VkDQo+ ID4gPiBpZGVudGlmaWVyDQo+ID4gPiBmb3JtYXQuIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJl IHBvc3NpYmxlIHRvIHN1cHBvcnQgZGlmZmVyZW50DQo+ID4gPiBpZGVudGlmaWVyIGZvcm1hdHMg aW4gdGhlIEEtLT5aIGFucyBaLS0+QSBkaXJlY3Rpb24gb2YgYW4gZTJlIHBhdGguDQo+ID4gPiBJ LmUuIG1peGluZyBvZiBpZGVudGlmaWVyIGZvcm1hdHMgbXVzdCBiZSBzdXBwb3J0ZWQuDQo+ID4g Pg0KPiA+ID4gPiBUaGlzIGJlY29tZXMgcGFydGljdWxhcmx5IGltcG9ydGFudCB0byB0aGUgdHJh bnNpdCBub2RlcyB0aGF0IG1heQ0KPiA+ID4gaGF2ZSB0bw0KPiA+ID4gPiBpbnNwZWN0IHRoZSBp ZGVudGlmaWVycy4NCj4gPiA+DQo+ID4gPiBbaHZoXSB0aGUgaW5zcGVjdGlvbiB3aWxsIGNvbnNp c3Qgb2YgY29tcGFyaW5nIGEgcmVjZWl2ZWQgdmFsdWUNCj4gPiA+IHdpdGggYW4gZXhwZWN0ZWQg dmFsdWUgd2hpY2ggY2FuIGhhdmUgYW55IGZvcm1hdC4NCj4gPiA+DQo+ID4gPiA+IE5vbmUgb2Yg dGhpcyBpcyBuZXcgb3Igc3BlY2lmaWMgdG8gTVBMUy1UUC4NCj4gPiA+DQo+ID4gPiBbaHZoXSBJ IGFncmVlLCBtaXhpbmcgb2YgaWRlbnRpZmllciBmb3JtYXRzIGl0IG5vdCByZXN0cmljdGVkIHRv DQo+ID4gPiBNUExTLVRQLg0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMsIEh1dWIuDQo+ID4gPg0KPiA+ ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxm DQo+ID4gPiBPZg0KPiA+ID4gPj4gZXJtaW5pby5vdHRvbmVfNjlAbGliZXJvLml0DQo+ID4gPiA+ PiBTZW50OiAxOCBNYXkgMjAxMSAyMjoyNQ0KPiA+ID4gPj4gVG86IGxvYUBwaS5udTsgbXBsc0Bp ZXRmLm9yZzsgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuDQo+ID4gPiA+PiBTdWJqZWN0OiBbbXBs c10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiA+ID4gSWRl bnRpZmllcnM/DQo+ID4gPiA+Pg0KPiA+ID4gPj4gQXBwZW5kaXggSUkgb2YgWS4xNzMxIHByb3Zp ZGVzIGEgZ29vZCBleGFtcGxlIGFib3V0IGhvdyBpbnRlci0NCj4gZG9tYWluDQo+ID4gPiA+PiBj b25uZWN0aXZpdHkgd2l0aCBlMmUgT0FNIGNhbiBiZSBwcm92aWRlZCB1c2luZyB0cmFuc3BvcnQt DQo+IG9yaWVudGVkDQo+ID4gPiBPQU0NCj4gPiA+ID4+IGZ1bmN0aW9ucy4NCj4gPiA+ID4+DQo+ ID4gPiA+PiBZb3UgY2FuIGRvd25sb2FkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBZLjE3MzEgKHRo ZSBwZHIgdmVyc2lvbg0KPiBpcw0KPiA+ID4gZm9yIGZyZWUpIGF0DQo+ID4gPiA+PiB0aGUgZm9s bG93aW5nIFVSTDoNCj4gPiA+ID4+DQo+ID4gPiA+PiBodHRwOi8vd3d3Lml0dS5pbnQvcmVjL1Qt UkVDLVkuMTczMS9lbg0KPiA+ID4gPj4NCj4gPiA+ID4+IEl0IGlzIGEgcGl0eSB0aGF0IHdpdGgg dGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgaWRlbnRpZmllcg0KPiBkcmFmdCwNCj4gPiA+IE1Q TFMtVFAgaXMNCj4gPiA+ID4+IG5vdCBjYXBhYmxlIHRvIHN1cHBvcnQgc3VjaCBhIG5ldHdvcmsg c2NlbmFyaW8uDQo+ID4gPiA+Pg0KPiA+ID4gPj4+IC0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0t LQ0KPiA+ID4gPj4+IERhOiBsb2FAcGkubnUNCj4gPiA+ID4+PiBEYXRhOiA0LW1hZy0yMDExIDgu MDANCj4gPiA+ID4+PiBBOjxtcGxzQGlldGYub3JnPiwNCj4gPiA+ID4+ICJNYWxjb2xtLkJFVFRT QHp0ZS5jb20uY24iPE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj4NCj4gPiA+ID4+PiBPZ2c6IFJl OiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+IElkZW50aWZp ZXJzPw0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gTWFsY29sbSwNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ IGFyZSB5b3Ugc2F5aW5nIHRoYXQgb3BlcmF0b3JzIHRvZGF5IGFsbG93IE9BTSB0byBjb250cm9s IG5vZGUNCj4gKE1JUHMNCj4gPiA+IGFuZA0KPiA+ID4gPj4+IE1FUHMpIG9uIGVhY2ggb3RoZXJz IG5ldHdvcmtzPw0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gRG8gd2UgaGF2ZSBhbiBvcGVyYXRvciB0 aGF0IGNhbiB2ZXJpZnkgdGhpcz8NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IC9Mb2ENCj4gPiA+ID4+ Pg0KPiA+ID4gPj4+IE9uIDIwMTEtMDUtMDMgMjI6NDQsIE1hbGNvbG0uQkVUVFNAenRlLmNvbS5j biB3cm90ZToNCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gQWxsLA0KPiA+ID4gPj4+Pg0KPiA+ID4g Pj4+PiBJIHNoYXJlIHlvdXIgY29uY2VybnMgYW5kIGRvdWJ0cyBhYm91dCBhIG11bHRpIGNhcnJp ZXIgY29udHJvbA0KPiA+ID4gcGxhbmUuDQo+ID4gPiA+Pj4+IEhvd2V2ZXIsIEkgdGhpbmsgdGhh dCBpdCBpcyBlc3NlbnRpYWwgdGhhdCBhIHRyYW5zcG9ydCBuZXR3b3JrDQo+ID4gPiBzdXBwb3J0 cw0KPiA+ID4gPj4+PiBtdWx0aSBjYXJyaWVyIGRhdGEgcGxhbmUgaW50ZXJjb25uZWN0aW9uIHdp dGggZW5kIHRvIGVuZCBPQU0uDQo+IEluDQo+ID4gPiB0b2RheSdzDQo+ID4gPiA+Pj4+IHRyYW5z cG9ydCBuZXR3b3JrIHRoaXMgaW50ZXJjb25uZWN0aW9uIGlzIHN1cHBvcnRlZCBieSBTREggYW5k DQo+ID4gPiBPVE4uIFRoZQ0KPiA+ID4gPj4+PiBvYmplY3RpdmUgZm9yIE1QTFMtVFAgaXMgdG8g YWxsb3cgZm9yIHBhY2tldCBiYXNlZA0KPiBpbnRlcmNvbm5lY3Rpb24NCj4gPiA+IGFzDQo+ID4g PiA+PiB3ZWxsLg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBSZWdhcmRzLA0KPiA+ID4gPj4+Pg0K PiA+ID4gPj4+PiBNYWxjb2xtDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ ID4gPiA+Pj4+ICpHZW9yZ2UgU3dhbGxvdzxzd2FsbG93QGNpc2NvLmNvbT4qDQo+ID4gPiA+Pj4+ IFNlbnQgYnk6IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiAw My8wNS8yMDExIDExOjA5IEFNDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IFRv DQo+ID4gPiA+Pj4+IAkiQW5kcmV3IEcuDQo+IE1hbGlzIjxhZ21hbGlzQGdtYWlsLmNvbT4sPG5l aWwuMi5oYXJyaXNvbkBidC5jb20+DQo+ID4gPiA+Pj4+IGNjDQo+ID4gPiA+Pj4+IAltcGxzQGll dGYub3JnDQo+ID4gPiA+Pj4+IFN1YmplY3QNCj4gPiA+ID4+Pj4gCVJlOiBbbXBsc10gTWl4aW5n IElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+IElkZW50aWZpZXJzPw0KPiA+ID4gPj4+ Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4g Pj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBBbmR5IC0NCj4gPiA+ID4+ Pj4NCj4gPiA+ID4+Pj4gICA+ICBTdWNoDQo+ID4gPiA+Pj4+ICAgPiAgYW4gRS1OTkkgZGVmaW5p dGlvbiBkb2VzIG5vdCB5ZXQgZXhpc3QgZm9yIE1QTFMtVFANCj4gKHNvbWV0aGluZw0KPiA+ID4g ZWxzZSB0bw0KPiA+ID4gPj4+PiAgID4gIHB1dCBvbiB0aGUgdG8tZG8gbGlzdCkuIFRoaXMgRS1O Tkkgd291bGQgYWxzbyBpbmNsdWRlDQo+IHNpbWlsYXINCj4gPiA+ID4+Pj4gICA+ICBpZGVudGlm aWVyIG1hcHBpbmcvdHJhbnNsYXRpb24gZm9yIE1TLVBXcywgdG8gYW5zd2VyIGFuDQo+ID4gPiBl YXJsaWVyDQo+ID4gPiA+Pj4+ICAgPiAgcXVlc3Rpb24gZnJvbSBFcm1pbmlvIHRoYXQgSSBzYXcg b24gdGhlIGxpc3QuDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IFlvdSBhcmUgcXVpdGUgY29ycmVj dCBoZXJlISBJIHRoaW5rIG11Y2ggb2YgdGhpcyBkZWJhdGUNCj4gc3Vycm91bmRzDQo+ID4gPiBh DQo+ID4gPiA+PiBwcm9ibGVtDQo+ID4gPiA+Pj4+IHRoYXQgaXMgeWV0IHRvIGJlIHNvbHZlZC4g U28gdGhlcmUgYXJlIGFyZ3VtZW50cyBmb3IgcGllY2VzIG9mDQo+IGENCj4gPiA+IHNvbHV0aW9u DQo+ID4gPiA+Pj4+IHdpdGhvdXQgYW5kIG92ZXJhbGwgYXJjaGl0ZWN0dXJlLg0KPiA+ID4gPj4+ Pg0KPiA+ID4gPj4+PiBCYXNlZCBvbiBhbGwgdGhhdCBJIGFtIHNlZWluZyBteSBpbmNsaW5hdGlv biBpcyB0byBOT1Qgc2F5DQo+IHRoYXQgd2UNCj4gPiA+ID4+IGRpc2FsbG93DQo+ID4gPiA+Pj4+ IG1peGVkIGlkZW50aWZpZXJzLCBidXQgdG8gc2F5IHRoYXQgdGhleSBhcmUgZm9yIGZ1dHVyZSBz dHVkeS4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gLi4uR2VvcmdlDQo+ID4gPiA+Pj4+DQo+ID4g PiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IE9u IDUvMy8xMSA4OjM4IEFNLCAiQW5kcmV3IEcuIE1hbGlzIjxhZ21hbGlzQGdtYWlsLmNvbT4NCj4g d3JvdGU6DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+ICAgPiAgTmVpbCwNCj4gPiA+ID4+Pj4gICA+ DQo+ID4gPiA+Pj4+ICAgPiAgVG8geW91ciBjYXNlIDEsIHdlJ3JlIGluIGNvbXBsZXRlIGFncmVl bWVudC4gV2UgKFZaKQ0KPiBkb24ndA0KPiA+ID4gc2VlIGF0DQo+ID4gPiA+Pj4+ICAgPiAgbGVh c3QgYSBzaG9ydC10ZXJtIG5lZWQgZm9yIHBlZXItbGF5ZXIgaW50ZXJ3b3JraW5nLA0KPiBnaXZl bg0KPiA+ID4gd2hlcmUgd2UNCj4gPiA+ID4+Pj4gICA+ICBpbnRlbmQgdG8gZGVwbG95IE1QTFMt VFAgaW4gb3VyIGluZnJhc3RydWN0dXJlIChhcyBhbg0KPiA+ID4gaW50ZXJuYWwgc2VydmVyDQo+ ID4gPiA+Pj4+ICAgPiAgbGF5ZXIgaW4gdGhlIHRyYW5zcG9ydCBjb3JlKS4gSWYgcGVlciBsYXll ciBpbnRlcndvcmtpbmcNCj4gZXZlcg0KPiA+ID4gYmVjb21lcw0KPiA+ID4gPj4+PiAgID4gIGEg bmVjZXNzaXR5LCB0aGVuIG9idmlvdXNseSB3ZSdsbCBuZWVkIGEgd2VsbC1kZWZpbmVkIEUtDQo+ IE5OSQ0KPiA+ID4gd2hpY2gNCj4gPiA+ID4+Pj4gICA+ICB3b3VsZCBpbmNsdWRlIExTUCBpZGVu dGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24gYXQgdGhlDQo+ID4gPiBib3VuZGFyeSwgZm9yDQo+ ID4gPiA+Pj4+ICAgPiAgTFNQIHByb3Zpc2lvbmluZyAod2hldGhlciBzdGF0aWMgb3IgZHluYW1p YykgYW5kIGVuZC10by0NCj4gZW5kDQo+ID4gPiBPQU0uIFN1Y2gNCj4gPiA+ID4+Pj4gICA+ICBh biBFLU5OSSBkZWZpbml0aW9uIGRvZXMgbm90IHlldCBleGlzdCBmb3IgTVBMUy1UUA0KPiAoc29t ZXRoaW5nDQo+ID4gPiBlbHNlIHRvDQo+ID4gPiA+Pj4+ICAgPiAgcHV0IG9uIHRoZSB0by1kbyBs aXN0KS4gVGhpcyBFLU5OSSB3b3VsZCBhbHNvIGluY2x1ZGUNCj4gc2ltaWxhcg0KPiA+ID4gPj4+ PiAgID4gIGlkZW50aWZpZXIgbWFwcGluZy90cmFuc2xhdGlvbiBmb3IgTVMtUFdzLCB0byBhbnN3 ZXIgYW4NCj4gPiA+IGVhcmxpZXINCj4gPiA+ID4+Pj4gICA+ICBxdWVzdGlvbiBmcm9tIEVybWlu aW8gdGhhdCBJIHNhdyBvbiB0aGUgbGlzdC4NCj4gPiA+ID4+Pj4gICA+DQo+ID4gPiA+Pj4+ICAg PiAgSSBhbHNvIGFncmVlIHRoYXQgYm90aCBpbnRyYS1sYXllciBhbmQgaW50ZXItbGF5ZXIgbWlz LQ0KPiA+ID4gY29ubmVjdGl2aXR5DQo+ID4gPiA+Pj4+ICAgPiAgZGV0ZWN0aW9uIGFuZCBhbWVs aW9yYXRpb24gYXJlIHJlcXVpcmVkLCBidXQgSSdtIG5vdA0KPiA+ID4gY29udmluY2VkIHRoYXQN Cj4gPiA+ID4+Pj4gICA+ICB0aGUgYWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMgY2FuJ3QgZG8g dGhhdC4gRG8geW91IGhhdmUNCj4gPiA+IHNvbWUNCj4gPiA+ID4+Pj4gICA+ICBzcGVjaWZpYyBh bmFseXNpcyBvbiB0aGUgaW50ZXItbGF5ZXIgY2FzZT8NCj4gPiA+ID4+Pj4gICA+DQo+ID4gPiA+ Pj4+ICAgPiAgQ2hlZXJzLA0KPiA+ID4gPj4+PiAgID4gIEFuZHkNCj4gPiA+ID4+Pj4gICA+DQo+ ID4gPiA+Pj4+ICAgPiAgT24gVHVlLCBNYXkgMywgMjAxMSBhdCAzOjM2IEFNLDxuZWlsLjIuaGFy cmlzb25AYnQuY29tPg0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+Pj4+ICAgPj4gIEhpIEFuZHksDQo+ ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4+Pj4gICA+PiAgMiBwb2ludHM6DQo+ID4gPiA+Pj4+ICAg Pj4NCj4gPiA+ID4+Pj4gICA+PiAgMSBJIGFncmVlIHdpdGggeW91ciB2aWV3IG9mIG9ubHkgaGF2 aW5nIGEgc2luZ2xlDQo+IGFkZHJlc3NpbmcNCj4gPiA+IHNjaGVtZSBpbg0KPiA+ID4gPj4gYQ0K PiA+ID4gPj4+PiAgID4+ICBzaW5nbGUgbGF5ZXIgbmV0d29yayBzb2xlbHkgYmVsb25naW5nIHRv IG9uZSBwYXJ0eS4NCj4gVGhvdWdoDQo+ID4gPiB5b3UgbWF5DQo+ID4gPiA+Pj4+IG5lZWQgdG8N Cj4gPiA+ID4+Pj4gICA+PiAgYmUgcmF0aGVyIGNhcmVmdWwgaWYgeW91IGFsc28gYWR2b2NhdGUg dGhhdCBvbmUgY2FuIGFsc28NCj4gPiA+IGhhdmUgcGVlcg0KPiA+ID4gPj4gbGF5ZXINCj4gPiA+ ID4+Pj4gICA+PiAgaW50ZXJ3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IHBhcnRpZXMsIGllIEUt Tk5JcyAoSQ0KPiBiZWxpZXZlDQo+ID4gPiB0aGlzIGlzDQo+ID4gPiA+Pj4+ICAgPj4gIHNvbWV0 aGluZyB5b3UgbWF5IHN1cHBvcnQsIGVnIG9sZCBNUExTRiBjYXNlPykuIEluIHN1Y2gNCj4gYQ0K PiA+ID4gcGVlcg0KPiA+ID4gPj4+PiBpbnRlcndvcmtpbmcNCj4gPiA+ID4+Pj4gICA+PiAgY2Fz ZSBpdCB3b3VsZCBzZWVtIG9uZSBtdXN0IGFsbG93IGRpZmZlcmVudCBhZGRyZXNzaW5nDQo+ID4g PiBzY2hlbWVzIChhbmQNCj4gPiA+ID4+Pj4gaW5kZWVkDQo+ID4gPiA+Pj4+ICAgPj4gIGFueSBv dGhlciB2YXJpYXRpb25zIGluIERQL0NQIGZ1bmN0aW9uYWwgY29tcG9uZW50cykgaWYNCj4gdGhl eQ0KPiA+ID4gZXhpc3QNCj4gPiA+ID4+Pj4gaW4gdGhlDQo+ID4gPiA+Pj4+ICAgPj4gIHN0YW5k YXJkcy4NCj4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPj4+PiAgID4+ICBPZiBjb3Vyc2UsIGhhdmlu ZyBhbiBFLU5OSSBhbmQgcGVlciBpbnRlcndvcmtpbmcgYmV0d2Vlbg0KPiA+ID4gZGlmZmVyZW50 DQo+ID4gPiA+Pj4+IHBhcnRpZXMgaW4NCj4gPiA+ID4+Pj4gICA+PiAgYW55IG5vbi1UT1MgbGF5 ZXIgbmV0d29yayAobm90IGp1c3QgTVBMUykgaXMgbm90DQo+IHRlY2huaWNhbGx5DQo+ID4gPiA+ Pj4+IG5lY2Vzc2FyeSAodGhpcw0KPiA+ID4gPj4+PiAgID4+ICBpcyB0cml2aWFsIHRvIHByb3Zl KSwgYW5kIHRoaXMgcHJvdmlkZXMgYSBzdHJvbmcNCj4gYXJndW1lbnQNCj4gPiA+IGZvciBvbmx5 DQo+ID4gPiA+Pj4+IGhhdmluZyBhDQo+ID4gPiA+Pj4+ICAgPj4gIHNpbmdsZSBhZGRyZXNzaW5n IHNjaGVtZSBpbiBhIG5vbi1UT1MgbGF5ZXIgbmV0d29yay4NCj4gPiA+ID4+Pj4gICA+Pg0KPiA+ ID4gPj4+PiAgID4+DQo+ID4gPiA+Pj4+ICAgPj4gIDIgWW91IHNob3VsZCBhbHNvIGJlIGF3YXJl IHRoYXQgaW4gY2xpZW50L3NlcnZlcg0KPiA+ID4gaW50ZXJ3b3JraW5nIG9mIHRoZQ0KPiA+ID4g Pj4+PiAgID4+ICBjby1wcyBtb2RlIHVzaW5nIHZhcmlhYmxlIHNpemUgdHJhZmZpYyB1bml0cywg YW5kDQo+IHRoZXJlZm9yZQ0KPiA+ID4gPj4+PiBzb21ldGhpbmcgcmF0aGVyDQo+ID4gPiA+Pj4+ ICAgPj4gIGltcG9ydGFudCBmb3IgTVBMUy1UUCBpbiB0aGUgcm9sZSBvZiBhIHRyYW5zcG9ydCBu ZXR3b3JrDQo+ID4gPiAoSSdsbA0KPiA+ID4gPj4+PiBpZ25vcmUgaXNzdWVzDQo+ID4gPiA+Pj4+ ICAgPj4gIG9mIHRyYW5zcGFyZW5jeSBoZXJlKSwgdGhlcmUgY291bGQgYmUgaW50ZXItbGF5ZXIN Cj4gPiA+IG1pc2Nvbm5lY3Rpdml0eQ0KPiA+ID4gPj4+PiAoQXNpZGU9Pg0KPiA+ID4gPj4+PiAg ID4+ICBUaGlzIGNhc2UgY2Fubm90IG9jY3VyIGluIHRoZSBjby1jcyBtb2RlKS4gVG8gZGF0ZSwN Cj4gaG93ZXZlciwNCj4gPiA+IHdlIGhhdmUNCj4gPiA+ID4+Pj4gb25seQ0KPiA+ID4gPj4+PiAg ID4+ICByZWFsbHkgY29uc2lkZXJlZCBpbnRyYS1sYXllciBtaXNjb25uZWN0aXZpdHksIGllDQo+ IGJldHdlZW4NCj4gPiA+IGRpZmZlcmVudA0KPiA+ID4gPj4gTFNQcw0KPiA+ID4gPj4+PiAgID4+ ICBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgcGFydHkgKG5vdGUgdGhpcyBhbHNvIGluY2x1ZGVzIGFs bA0KPiA+ID4gY2FzZXMgb2YNCj4gPiA+ID4+Pj4gbmVzdGVkIExTUA0KPiA+ID4gPj4+PiAgID4+ ICBzdWJsYXllciBtaXNjb25uZWN0aXZpdHkpLg0KPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+Pj4+ ICAgPj4gIEluIHRoZSBjYXNlIG9mIGludGVyLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSBvbmUgbWF5 DQo+IHJlY2VpdmUNCj4gPiA+IHRyYWZmaWMNCj4gPiA+ID4+Pj4gdW5pdHMgYW5kDQo+ID4gPiA+ Pj4+ICAgPj4gIE9BTSBtZXNzYWdlcyBmcm9tIHNvbWUgb3RoZXIgcGFydHkncyBsYXllciBuZXR3 b3JrLiBUaGUNCj4gT0FNDQo+ID4gPiA+PiBtZXNzYWdlcw0KPiA+ID4gPj4gbWF5DQo+ID4gPiA+ Pj4+ICAgPj4gIGNvbWUgZnJvbSAoaSkgbmV0d29ya3MgdXNpbmcgZGlmZmVyZW50IE9BTS9hZGRy ZXNzaW5nDQo+ID4gPiBzb2x1dGlvbnMgb3INCj4gPiA+ID4+IChpaSkNCj4gPiA+ID4+Pj4gICA+ PiAgbmV0d29ya3MgdXNpbmcgdGhlIHNhbWUgT0FNL2FkZHJlc3Npbmcgc29sdXRpb25zLiBJbg0K PiBib3RoDQo+ID4gPiBjYXNlcw0KPiA+ID4gPj4+PiB0aGVyZSBhcmUNCj4gPiA+ID4+Pj4gICA+ PiAgZGlmZmVyZW50IGlzc3VlcyB3cnQgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5IG9uZSBo YXMNCj4gdG8NCj4gPiA+IGRlYWwNCj4gPiA+ID4+Pj4gd2l0aC4gSSdtDQo+ID4gPiA+Pj4+ICAg Pj4gIG5vdCBhd2FyZSB0aGF0IHRoZXNlIGNhc2VzIGhhdmUgYmVlbiBjb25zaWRlcmVkIHlldC4N Cj4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+Pj4+ICAgPj4gIEknZCBs aWtlIHRvIGhlYXIgeW91ciBjb21tZW50cyBvbiBib3RoIHRoZXNlIHBvaW50cywgYnV0DQo+IGlu DQo+ID4gPiA+Pj4+IHBhcnRpY3VsYXIgdGhlDQo+ID4gPiA+Pj4+ICAgPj4gIGZpcnN0IG9uZS4u Li4uZXNwZWNpYWxseSBpZiB5b3UgYWxzbyBzdXBwb3J0IHRoZSBub3Rpb24NCj4gb2YNCj4gPiA+ IEUtTk5JcyBpbg0KPiA+ID4gPj4+PiBNUExTLVRQLA0KPiA+ID4gPj4+PiAgID4+ICBhcyB0aGVy ZSBzZWVtcyB0byBhIHBvc3NpYmxlIGxvZ2ljYWwgY29uZmxpY3QgaGVyZS4NCj4gPiA+ID4+Pj4g ICA+Pg0KPiA+ID4gPj4+PiAgID4+ICBUaGFua3MuDQo+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4+ Pj4gICA+PiAgcmVnYXJkcywgTmVpbCBIYXJyaXNvbg0KPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ Pj4+ICAgPj4gIEJUIERlc2lnbg0KPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+Pj4+ICAgPj4gIFRo aXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZQ0KPiBwcml2aWxl Z2VkDQo+ID4gPiBvcg0KPiA+ID4gPj4+PiBjb25maWRlbnRpYWwuDQo+ID4gPiA+Pj4+ICAgPj4g IEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkDQo+ IGFib3ZlLg0KPiA+ID4gSWYNCj4gPiA+ID4+Pj4geW91J3JlIG5vdA0KPiA+ID4gPj4+PiAgID4+ ICB0aGUgaW50ZW5kZWQNCj4gPiA+ID4+Pj4gICA+PiAgcmVjaXBpZW50LCBub3RlIHRoYXQgZGlz Y2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nDQo+IG9yDQo+ID4gPiB1c2luZyB0aGlzDQo+ ID4gPiA+Pj4+ICAgPj4gIGluZm9ybWF0aW9uDQo+ID4gPiA+Pj4+ICAgPj4gIGlzIHByb2hpYml0 ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLA0KPiA+ID4gcGxlYXNl IGxldCBtZQ0KPiA+ID4gPj4+PiBrbm93DQo+ID4gPiA+Pj4+ICAgPj4gIGltbWVkaWF0ZWx5DQo+ ID4gPiA+Pj4+ICAgPj4gIG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuDQo+ ID4gPiA+Pj4+ICAgPj4gIFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNv cmQgeW91ciBlbWFpbHMuDQo+ID4gPiA+Pj4+ICAgPj4gIEJyaXRpc2ggVGVsZWNvbW11bmljYXRp b25zIHBsYw0KPiA+ID4gPj4+PiAgID4+ICBSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBT dHJlZXQgTG9uZG9uIEVDMUEgN0FKDQo+ID4gPiA+Pj4+ICAgPj4gIFJlZ2lzdGVyZWQgaW4gRW5n bGFuZCBubzogMTgwMDAwMA0KPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+Pj4+ICAgPj4+ICAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPj4+PiAgID4+PiAgRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy0NCj4gYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+IE9u IEJlaGFsZg0KPiA+ID4gPj4gT2YNCj4gPiA+ID4+Pj4gICA+Pj4gIEFuZHJldyBHLiBNYWxpcw0K PiA+ID4gPj4+PiAgID4+PiAgU2VudDogMDIgTWF5IDIwMTEgMjA6NDgNCj4gPiA+ID4+Pj4gICA+ Pj4gIFRvOiBHZW9yZ2UgU3dhbGxvdw0KPiA+ID4gPj4+PiAgID4+PiAgQ2M6IG1wbHNAaWV0Zi5v cmcNCj4gPiA+ID4+Pj4gICA+Pj4gIFN1YmplY3Q6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQg R2xvYmFsLUlEcyBpbiBNUExTLQ0KPiBUUA0KPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+Pj4+ ICAgPj4+DQo+ID4gPiA+Pj4+ICAgPj4+ICBHZW9yZ2UgZXQgYWwsDQo+ID4gPiA+Pj4+ICAgPj4+ DQo+ID4gPiA+Pj4+ICAgPj4+ICBWZXJpem9uIGRvZXMgbm90IGhhdmUgYW55IHJlcXVpcmVtZW50 IGZvciBtaXhlZCB1c2Ugb2YNCj4gPiA+IEdsb2JhbCBJRHMgYW5kDQo+ID4gPiA+Pj4+ICAgPj4+ ICBJQ0NzLiBXZSBhcmUgZmluZSB3aXRoIHNwZWNpZmljYXRpb25zIHRoYXQgcmVxdWlyZSBib3Ro DQo+ID4gPiBlbmRzIG9mIGFuDQo+ID4gPiA+PiBMU1ANCj4gPiA+ID4+Pj4gICA+Pj4gIHRvIHVz ZSBvbmUgb3IgdGhlIG90aGVyLg0KPiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4gPj4+PiAgID4+PiAg VGhhbmtzLA0KPiA+ID4gPj4+PiAgID4+PiAgQW5keQ0KPiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4g Pj4+PiAgID4+PiAgT24gTW9uLCBBcHIgMjUsIDIwMTEgYXQgNToxNiBQTSwgR2VvcmdlDQo+ID4g PiBTd2FsbG93PHN3YWxsb3dAY2lzY28uY29tPg0KPiA+ID4gPj4+PiAgID4+PiAgd3JvdGU6DQo+ ID4gPiA+Pj4+ICAgPj4+PiAgQWxsIC0NCj4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+Pj4+ICAg Pj4+PiAgTWFueSBvZiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUgSVRVIG9uDQo+ID4g PiA+Pj4+ICAgPj4+PiAgZHJhZnQtaWV0Zi1tcGxzLXRwLWlkZW50aWZpZXJzLTA0IGhhdmUgdG8g ZG8gd2l0aCB0aGUNCj4gPiA+IEdsb2JhbCBhbmQgSUNDDQo+ID4gPiA+Pj4+ICAgPj4+PiAgaWRl bnRpZmllcnMuDQo+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBpZGVu dGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVHIGluY2x1ZGUNCj4gPiA+IGZpZWxk cyB0bw0KPiA+ID4gPj4+PiAgID4+PiAgaWRlbnRpZnkgZWFjaA0KPiA+ID4gPj4+PiAgID4+Pj4g IGVuZCBvZiBhbiBMU1AuIEN1cnJlbnRseSB0aGUgZHJhZnQgYWxsb3dzIGEgVHVubmVsLA0KPiBM U1AsDQo+ID4gPiBQVywgb3IgTUVHDQo+ID4gPiA+Pj4+ICAgPj4+ICB0byB1c2UNCj4gPiA+ID4+ Pj4gICA+Pj4+ICBlaXRoZXIgdGhlIEdsb2JhbC1JRCBmb3IgYm90aCBlbmRzIG9yIG9yIHRoZSBJ Q0MgZm9yDQo+IGJvdGgNCj4gPiA+IGVuZHMuDQo+ID4gPiA+Pj4+ICAgPj4+ICBNaXhlZCB1c2UN Cj4gPiA+ID4+Pj4gICA+Pj4+ICBpcyBub3QgcGVybWl0dGVkLg0KPiA+ID4gPj4+PiAgID4+Pj4N Cj4gPiA+ID4+Pj4gICA+Pj4+ICBUaGUgSVRVIGxpYWlzb24gcmVxdWVzdHMgdGhhdCB3ZSBhbGxv dyBtaXhlZCB1c2UuDQo+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBh dXRob3JzIG9mIHRoZSBkcmFmdCBhcmUgdmVyeSByZWx1Y3RhbnQgdG8gZG8NCj4gdGhpcy4NCj4g PiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+Pj4+ICAgPj4+PiAgT2J0YWluaW5nIGFuIEFTIE51bWJl ciAoZnJvbSB3aGljaCB0aGUgR2xvYmFsLUlEIGlzDQo+ID4gPiBkZXJpdmVkKSBpcyBhDQo+ID4g PiA+Pj4+ICAgPj4+ICBmYWlybHkNCj4gPiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFsIHByb2NlZHVy ZS4gTWFueSBvcmdhbml6YXRpb25zIGlmIG5vdCBtb3N0DQo+IGFscmVhZHkNCj4gPiA+IGhhdmUg QVMNCj4gPiA+ID4+Pj4gICA+Pj4gIE51bWJlcnMuDQo+ID4gPiA+Pj4+ICAgPj4+PiAgU3VjaCBh biBhZGRpdGlvbiB3aWxsIGFkZCBudW1lcm91cyBvYmplY3QgZm9ybWF0cywgYW5kDQo+ID4gPiB0 ZXN0IGNhc2VzLg0KPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBleHRlbnQgaW50ZXItcHJvdmlkZXIg TVBMUy1UUCBpcyBhcyB5ZXQgdW5rbm93bi4NCj4gSWYNCj4gPiA+IG1peGVkIG1vZGVzDQo+ID4g PiA+Pj4+ICAgPj4+ICBvZiBJQ0MNCj4gPiA+ID4+Pj4gICA+Pj4+ICBhbmQgR2xvYmFsLUlEIGlk ZW50aWZpY2F0aW9uIGlzIHJlcXVpcmVkLCB0aGV5IGNhbiBiZQ0KPiA+ID4gYWRkZWQgbGF0ZXIu DQo+ID4gPiA+Pj4+ICAgPj4+PiAgRm9yIHNpZ25hbGVkIGNvbm5lY3Rpb25zLCB0aGVyZSBpcyBu byBwbGFuIHRvIGFsbG93DQo+ID4gPiByb3V0aW5nIGJhc2VkIG9uDQo+ID4gPiA+Pj4+ICAgPj4+ ICBlaXRoZXINCj4gPiA+ID4+Pj4gICA+Pj4+ICB0aGUgR2xvYmFsLUlEIG9yIElDQy4gVGhhdCB3 b3VsZCBiZSBhIHJhZGljYWwgY2hhbmdlDQo+IHRvDQo+ID4gPiBob3cgSVANCj4gPiA+ID4+Pj4g ICA+Pj4gIHdvcmtzLg0KPiA+ID4gPj4+PiAgID4+Pj4gIEhvd2V2ZXIgZm9yIElQIHJvdXRpbmcg dG8gd29yayAoaW4gb3JkZXIgdG8gZm9yd2FyZA0KPiB0aGUNCj4gPiA+IHNpZ25hbGluZw0KPiA+ ID4gPj4+PiAgID4+Pj4gIG1lc3NhZ2VzKSwgdGhlIHByb3ZpZGVycyBpbnZvbHZlZCB3aWxsIG5l ZWQgdG8gcnVuIEJHUA0KPiBhbmQNCj4gPiA+IGhhdmUgQVMNCj4gPiA+ID4+Pj4gICA+Pj4gIG51 bWJlcnMuDQo+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPj4+PiAgID4+Pj4gIFdlIGFyZSBsb29r aW5nIGZvciBpbnB1dC9jb25zZW5zdXMgZnJvbSB0aGUgV0cuDQo+ID4gPiA+Pj4+ICAgPj4+Pg0K PiA+ID4gPj4+PiAgID4+Pj4gIEdlb3JnZSwgRXJpYywmICBNYXR0aGV3DQo+ID4gPg0KPiA+ID4N Cj4gPiA+IC0tDQo+ID4gPg0KPiA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4gKioqDQo+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG1wbHMgbWFpbGluZyBs aXN0DQo+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWls aW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg== From neil.2.harrison@bt.com Wed May 25 04:23: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 A0C8FE06C6 for ; Wed, 25 May 2011 04:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 2TxewtNwKry1 for ; Wed, 25 May 2011 04:23:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59AE0694 for ; Wed, 25 May 2011 04:23:34 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 25 May 2011 12:23:33 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.96]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 25 May 2011 12:23:33 +0100 From: To: , , Date: Wed, 25 May 2011 12:23:29 +0100 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0QgAAECTA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440264057E4@EMV62-UKRD.domain1.systemhost.net> References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> 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] R: Re: 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, 25 May 2011 11:23:36 -0000 VGhlcmUgaXMgYW4gaW1wb3J0YW50IGRpZmZlcmVuY2UgaGVyZS4gIFdlIGNhbm5vdCBoYXZlICpp bnRlciogbGF5ZXIgbWlzY29ubmVjdGl2aXR5IGluIGNvLWNzIG1vZGUgbmV0d29ya3MuLi50aGlz IGZvbGxvd3MgZGlyZWN0bHkgZnJvbSBob3cgdGhlIGxhYmVsbGluZyBvZiByZXNvdXJjZSBwYXJ0 aXRpb25zIHdvcmtzIGluIGVhY2ggb2YgdGhlIDMgbW9kZXMuICBTbyBpZiB0aGVyZSBpcyBhIG5l ZWQgdG8gcHJvY2VzcyBkaWZmZXJlbnQgQ1YgJ1NBJyBJRHMgaGVyZSB0aGVuIHRoYXQgaXMgZG93 biB0byBhIHNlbGYtaW5mbGljdGVkIHBlZXJpbmcgY2FzZSBvZiBmb3JjaW5nIG1vcmUgZnVuY3Rp b25hbGl0eSB0aGFuIGEgdHJ1ZSBCT1MtcGh5c2ljYWwgYml0IGludGVyY29ubmVjdCBjYXNlIHJl cXVpcmVzLg0KDQpIb3dldmVyLCB3aGVuIHdlIGhhdmUgYSB2YXJpYWJsZSBzaXplIHRyYWZmaWMg dW5pdCBpbiB0aGUgY28tcHMgbW9kZSwgYXMgd2UgaGF2ZSB3aXRoIE1QTFMtVFAsIHRoZW4gd2Ug Y2FuIGhhdmUgc29tZXRoaW5nIHRoYXQgbG9va3MgbGlrZSBYb3ZlclggKGFzIG1hbnkgdGltZXMg YXMgb25lIGxpa2VzIC0gc3ViamVjdCB0byA8TVRVKS4gIFNvLCBpbiBhZGRpdGlvbiB0byBtaXNj b25uZWN0aXZpdHkgZHVlIHRvIGFueSBzZWxmLWluZmxpY3RlZCBwZWVyaW5nIGNhc2UsIHdlIGNh biBhbHNvIGhhdmUgKGkpIG1pc2Nvbm5lY3Rpdml0eSBiZXR3ZWVuIGxheWVycyBhdCBkaWZmZXJl bnQgbGV2ZWxzIG9yIChpaSkgYmV0d2VlbiBkaWZmZXJlbnQvaW5kZXBlbmRlbnQgbGF5ZXIgbmV0 d29ya3MgYXQgbGV2ZWwgTiBzYXkgZHVlIHRvIGEgc2VydmVyIGxheWVyIG1pc2Nvbm5lY3Rpdml0 eSBkZWZlY3QgYmVsb3cgbGV2ZWwgTi4gIFRoZSBrZXkgcG9pbnRzIGhlcmUgYmVpbmc6DQogKGkp IGEgcmljaGVyIGRlZmVjdCBlbnZpcm9ubWVudCB0aGFuIHRoZSBjby1jcyBtb2RlDQooaWkpIGlm IE4gdHlwZXMgb2YgQ1YgJ0lEJyBleGlzdCB0aGVuIHdlIGNhbid0IGFzc3VtZSB0aGV5IHJlbWFp biBpbmRlcGVuZGVudCBvZiBlYWNoIG90aGVyIGF0IGFsbC4uLi5hcyB3ZSBjb3VsZCBpZiB3ZSBk aWQgbm90IGltcG9zZSBhIHNlbGYtaW5mbGljdGVkIHBlZXIgY2FzZSBvbiBvdXJzZWx2ZXMuLi5h bmQgdGh1cyBlYWNoIG5ldHdvcmsgbXVzdCBiZSBhYmxlIHRvIGhhbmRsZSBhbGwgTiBpbnN0YW5j ZXMgb2YgSUQgKEkgYXNzdW1lIHRoZSBzYW1lIENWIE9BTSB0cmFmZmljIHVuaXQgY2Fycnlpbmcg dGhlbSAtIHZhcnlpbmcgdGhhdCBqdXN0IG1ha2VzIHRoZSBtaXggZXZlbiBtb3JlIGludGVyZXN0 aW5nKS4NCg0KcmVnYXJkcywgTmVpbA0KQlQgRGVzaWduDQoNClRoaXMgZW1haWwgY29udGFpbnMg QlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4N Ckl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiBJZiB5b3UncmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50LCBub3RlIHRoYXQgZGlz Y2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMgaW5mb3JtYXRpb24N CmlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkNCm9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3Zl LiBUaGFuayB5b3UuDQpXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3Jk IHlvdXIgZW1haWxzLg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdpc3RlcmVk IG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm86IDE4MDAwMDANCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1hYXJ0ZW4gdmlzc2Vycw0KPiBTZW50OiAyNSBNYXkg MjAxMSAxMDo0Mg0KPiBUbzogYWRyaWFuQG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1Q TFMtVFANCj4gSWRlbnRpZmllcnM/DQo+DQo+IEFkcmlhbiwNCj4NCj4gUGxlYXNlIGJlIGF3YXJl IHRoYXQgdW5kZXIgZmF1bHQgY29uZGl0aW9ucyBhbiBJQ0MgZm9ybWF0dGVkIElEIGNhbiBiZQ0K PiByZWNlaXZlZCBieSBhbiBlbmRwb2ludCB1c2luZyBhIEdsb2JhbF9JRCBmb3JtYXR0ZWQgSUQs IGFuZCB2aWNlIHZlcnNhLg0KPiBFaXRoZXIgZW5kcG9pbnQgbXVzdCBiZSBhYmxlIHRvIGRldGVj dCBhIG1pc2Nvbm5lY3Rpb24gY29uZGl0aW9uIGFuZCBiZQ0KPiBhYmxlIHRvIHJlcG9ydCB0aGUg cmVjZWl2ZWQgSUQgKGluIHRoZSBub24tZXhwZWN0ZWQgZm9ybWF0KSB0byBOTVMgdG8NCj4gZ3Vp ZGUgaW4gdGhlIGZhdWx0IGxvY2FsaXNhdGlvbi4NCj4NCj4gTm90ZSB0aGF0IHdlIG92ZXJsb29r ZWQgYSBzaW1pbGFyIHJlcXVpcmVtZW50IGluaXRpYWxseSBpbiBTREggKDE2LWJ5dGUNCj4gVFRJ IGFuZCA2NC1ieXRlIFRUSSksIGFuZCB0aGlzIHJlcXVpcmVkIHVzIHRvIHVwZ3JhZGUgb3VyIFZD LW4NCj4gZW5kcG9pbnRzIGFmdGVyd2FyZHMuIExldCdzIG5vdCBtYWtlIGEgc2ltaWxhciBtaXN0 YWtlIGluIE1QTFMtVFAuDQo+DQo+IFJlZ2FyZHMsDQo+IE1hYXJ0ZW4NCj4NCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4gQWRyaWFuIEZh cnJlbA0KPiA+IFNlbnQ6IDI1IE1heSAyMDExIDExOjEzDQo+ID4gVG86IG1wbHNAaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURz IGluIE1QTFMtVFANCj4gPiBJZGVudGlmaWVycz8NCj4gPg0KPiA+IEhpIE5laWwsDQo+ID4NCj4g PiBJJ20gbm90IGFzc3VtaW5nIHBlZXJpbmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcgb3V0IHRv IEh1dWIgdGhhdA0KPiA+IChkZXNwaXRlIHdoYXQgaGUga2VlcHMgc2F5aW5nKSBoZSBpcyBhbHNv IG5vdCBhc3N1bWluZyBwZWVyaW5nLg0KPiA+DQo+ID4gVGhlIGNvbnNlcXVlbmNlIG9mIG5vdCBw ZWVyaW5nIGlzIHRoYXQgYSBzaW5nbGUgaWRlbnRpZmllciBtb2RlIGlzDQo+IHVzZWQNCj4gPiBm b3IgYm90aCBlbmRzIG9mIGFuIE9BTSAic2Vzc2lvbiIuIEFuZCB0aGF0IG1lYW5zIHRoYXQgb25l IGVuZCBoYXMgdG8NCj4gPiB1bmRlcnN0YW5kICphbmQqIHVzZSB0aGUgImZvcmVpZ24iIGZvcm1h dCBhdCB0aGUgcmVtb3RlIGVuZCBvZiB0aGUNCj4gPiBzZXNzaW9uLg0KPiA+DQo+ID4gSSBhbSB0 aXJlZCBvZiB0aGlzIGRpc2N1c3Npb24uIFRoZXJlIHNlZW1zIHRvIGJlIG5vIGZvcndhcmQgcHJv Z3Jlc3MNCj4gPiBvbmx5IHJlc3RhdGVtZW50IG9mIGEgIndhbnQiLiBJIGFsd2F5cyB3YW50ZWQg YSBwb255IHdoZW4gSSB3YXMgYQ0KPiA+IGxpdHRsZSBnaXJsLCBidXQgSSBuZXZlciBnb3Qgb25l Lg0KPiA+DQo+ID4gQWRyaWFuDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+IE9mDQo+ID4gPiBuZWlsLjIuaGFycmlzb25AYnQu Y29tDQo+ID4gPiBTZW50OiAyMiBNYXkgMjAxMSAyMDozNg0KPiA+ID4gVG86IGh1dWJhdHdvcmtA Z21haWwuY29tOyBtcGxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJl OiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4gPiBJZGVudGlmaWVycz8N Cj4gPiA+DQo+ID4gPiBIaSBBZHJpYW4vSHV1YiwNCj4gPiA+DQo+ID4gPiBZb3UgYXJlIGxhcmdl bHkgYXNzdW1pbmcgc29tZSBmb3JtIG9mIHBlZXJpbmcgKHNpbmdsZSBwYXJ0aXRpb25lZA0KPiA+ IGxheWVyIG5ldHdvcmspDQo+ID4gPiBoZXJlLi4uYW5kIHRoYXQgbW9kZWwgd2lsbCBnZW5lcmF0 ZSBhIHdob2xlIHJhZnQgb2YgcHJvYmxlbXMgZm9yDQo+ID4gb3BlcmF0b3JzIElNTy4NCj4gPiA+ IEEgbW9yZSBpbXBvcnRhbnQgbW9kZWwgZm9yIGEgY28tcHMgdHJhbnNwb3J0IG5ldHdvcmsgaXMN Cj4gPiBjbGllbnQvc2VydmVyLiAgQW5kIG5vdw0KPiA+ID4gbm90IG9ubHkgaGF2ZSB3ZSB0aGUg dXN1YWwgaW50cmEtbGF5ZXIgbWlzY29ubmVjdGl2aXR5IHRvIGRlYWwgd2l0aA0KPiA+IGJ1dCB3 ZSBhbHNvDQo+ID4gPiBoYXZlIGludGVyLWxheWVyIG1pc2Nvbm5lY3Rpdml0eS4uLmFuZCB0aGlz IG1lYW5zIGVhY2ggb3BlcmF0aW5nDQo+ID4gcGFydHkgbXVzdA0KPiA+ID4gdW5kZXJzdGFuZCB0 aGUgT0FNIGZvcm1hdHMgKGFuZCBDViBJRHMpIG9mIGVhY2ggb3RoZXIgYW55d2F5Li4uIG5vdA0K PiA+IHNpbXBseSB0bw0KPiA+ID4gZGV0ZWN0IHRoZXJlIGlzIGEgbWlzY29ubmVjdGl2aXR5IHBy b2JsZW1zIGJ1dCBhbHNvIHRvIGlkZW50aWZ5DQo+IHdoaWNoDQo+ID4gb3RoZXIgcGFydGllcw0K PiA+ID4gYXJlIGludm9sdmVkLg0KPiA+ID4NCj4gPiA+IHJlZ2FyZHMsIE5laWwNCj4gPiA+DQo+ ID4gPiBCVCBEZXNpZ24NCj4gPiA+IFRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24s IHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+ID4gY29uZmlkZW50aWFsLg0KPiA+ID4gSXQn cyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUu IElmDQo+ID4geW91J3JlIG5vdCB0aGUNCj4gPiA+IGludGVuZGVkDQo+ID4gPiByZWNpcGllbnQs IG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcNCj4g dGhpcw0KPiA+IGluZm9ybWF0aW9uDQo+ID4gPiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGxldA0KPiBtZQ0KPiA+IGtub3cNCj4g PiA+IGltbWVkaWF0ZWx5DQo+ID4gPiBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsg eW91Lg0KPiA+ID4gV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5 b3VyIGVtYWlscy4NCj4gPiA+IEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ID4g UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KPiA+ ID4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIG5vOiAxODAwMDAwDQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBC ZWhhbGYgT2YNCj4gPiA+ID4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gPiA+ID4gU2VudDogMjIgTWF5 IDIwMTEgMTk6MTUNCj4gPiA+ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDog UmU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ ID4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPg0KPiA+ID4gPiBIaSBBZHJpYW4sDQo+ID4gPiA+ DQo+ID4gPiA+IFNlZSBteSByZXNwb25zZSBpbi1saW5lIFtodmhdDQo+ID4gPiA+DQo+ID4gPiA+ ID4gV2UgaGF2ZSBhbHJlYWR5IGJlZW4gcm91bmQgdGhpcyBsb29wIG9uIHRoaXMgbGlzdCBvbmNl Lg0KPiA+ID4gPiA+IFdhbnQgdG8gZG8gaXQgYWdhaW4/DQo+ID4gPiA+DQo+ID4gPiA+IFtodmhd IElmIGl0IGhlbHBzIHRvIGdldCB0byB0aGUgZm9jYWwgcG9pbnQsIHdoeSBub3QuDQo+ID4gPiA+ DQo+ID4gPiA+ID4gQXMgSHV1YiBzYWlkLCB0aGlzIGlzIGFib3V0IGlkZW50aWZpZXJzLCBub3Qg T0FNLiBIb3dldmVyLCB0aGUNCj4gPiBtb2RlbA0KPiA+ID4gPiBmb3IgT0FNDQo+ID4gPiA+ID4g aW50ZXJ3b3JraW5nIHNob3dzICJsYXllcmluZyIgbm90IGdhdGV3YXlpbmcsIGFuZCBjZXJ0YWlu bHkgbm90DQo+ID4gPiA+IG1peGluZy4gVGhhdCBpcywNCj4gPiA+ID4gPiBvbmUgZW5kIG9mIHRo ZSBlMmUgcGF0aCBtdXN0IGJlIGNhcGFibGUgb2Ygb3BlcmF0aW5nIGJvdGgNCj4gPiBzeXN0ZW1z LA0KPiA+ID4gPiBidXQgdGhlIG90aGVyDQo+ID4gPiA+ID4gZG9lcyBub3QgbmVlZCB0by4NCj4g PiA+ID4NCj4gPiA+ID4gW2h2aF0gT0sgaWYgeW91IG1lYW4gIk9BTSB0b29sc2V0cyIgYnkgInN5 c3RlbXMiDQo+ID4gPiA+DQo+ID4gPiA+ID4gVG8gZXh0ZW5kIHRoaXMgbW9kZWwgdG8gaWRlbnRp ZmllcnMgbWVhbnMgdGhhdCBvbmUgZW5kIG9mIHRoZQ0KPiBlMmUNCj4gPiA+ID4gcGF0aCBtdXN0 DQo+ID4gPiA+ID4gc3VwcG9ydCBib3RoIGlkZW50aWZpZXIgZm9ybWF0cyBhbmQgdGhlIG90aGVy IGRvZXMgbm90IG5lZWQgdG8uDQo+ID4gPiA+DQo+ID4gPiA+IFtodmhdIHRvIGJlIG1vcmUgc3Bl Y2lmaWMgdGhlIG9yaWdpbmF0aW5nIGVuZCBvZiBhbiBlMmUgcGF0aCBtdXN0DQo+ID4gPiA+IGJl IGFibGUgdG8gc3VwcG9ydCBvbmUgb2YgdGhlIHBvc3NpYmxlIGlkZW50aWZpZXIgZm9ybWF0cywN Cj4gbm9ybWFsbHkNCj4gPiA+ID4gdGhlIGlkZW50aWZpZXIgZm9ybWF0IG9mIHRoZSBsb2NhbCBv cGVyYXRvci4gVGhlIHRlcm1pbmF0aW5nIGVuZA0KPiA+IGFuZA0KPiA+ID4gPiB0aGUgaW50ZXJt ZWRpYXRlIHBvaW50cyBvZiBhbiBlMmUgcGF0aCBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoZQ0K PiA+ID4gPiBmb3JtYXQgaW5zZXJ0ZWQgYXQgdGhlIG9yaWdpbiBpbmRlcGVuZGVudCBvZiB0aGUg bG9jYWxseSB1c2VkDQo+ID4gPiA+IGlkZW50aWZpZXINCj4gPiA+ID4gZm9ybWF0LiBUaGlzIG1l YW5zIHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSB0byBzdXBwb3J0IGRpZmZlcmVudA0KPiA+ID4g PiBpZGVudGlmaWVyIGZvcm1hdHMgaW4gdGhlIEEtLT5aIGFucyBaLS0+QSBkaXJlY3Rpb24gb2Yg YW4gZTJlDQo+IHBhdGguDQo+ID4gPiA+IEkuZS4gbWl4aW5nIG9mIGlkZW50aWZpZXIgZm9ybWF0 cyBtdXN0IGJlIHN1cHBvcnRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGlzIGJlY29tZXMgcGFy dGljdWxhcmx5IGltcG9ydGFudCB0byB0aGUgdHJhbnNpdCBub2RlcyB0aGF0DQo+IG1heQ0KPiA+ ID4gPiBoYXZlIHRvDQo+ID4gPiA+ID4gaW5zcGVjdCB0aGUgaWRlbnRpZmllcnMuDQo+ID4gPiA+ DQo+ID4gPiA+IFtodmhdIHRoZSBpbnNwZWN0aW9uIHdpbGwgY29uc2lzdCBvZiBjb21wYXJpbmcg YSByZWNlaXZlZCB2YWx1ZQ0KPiA+ID4gPiB3aXRoIGFuIGV4cGVjdGVkIHZhbHVlIHdoaWNoIGNh biBoYXZlIGFueSBmb3JtYXQuDQo+ID4gPiA+DQo+ID4gPiA+ID4gTm9uZSBvZiB0aGlzIGlzIG5l dyBvciBzcGVjaWZpYyB0byBNUExTLVRQLg0KPiA+ID4gPg0KPiA+ID4gPiBbaHZoXSBJIGFncmVl LCBtaXhpbmcgb2YgaWRlbnRpZmllciBmb3JtYXRzIGl0IG5vdCByZXN0cmljdGVkIHRvDQo+ID4g PiA+IE1QTFMtVFAuDQo+ID4gPiA+DQo+ID4gPiA+IFJlZ2FyZHMsIEh1dWIuDQo+ID4gPiA+DQo+ ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4+IEZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g PiBCZWhhbGYNCj4gPiA+ID4gT2YNCj4gPiA+ID4gPj4gZXJtaW5pby5vdHRvbmVfNjlAbGliZXJv Lml0DQo+ID4gPiA+ID4+IFNlbnQ6IDE4IE1heSAyMDExIDIyOjI1DQo+ID4gPiA+ID4+IFRvOiBs b2FAcGkubnU7IG1wbHNAaWV0Zi5vcmc7IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbg0KPiA+ID4g PiA+PiBTdWJqZWN0OiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4g TVBMUy1UUA0KPiA+ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQXBw ZW5kaXggSUkgb2YgWS4xNzMxIHByb3ZpZGVzIGEgZ29vZCBleGFtcGxlIGFib3V0IGhvdyBpbnRl ci0NCj4gPiBkb21haW4NCj4gPiA+ID4gPj4gY29ubmVjdGl2aXR5IHdpdGggZTJlIE9BTSBjYW4g YmUgcHJvdmlkZWQgdXNpbmcgdHJhbnNwb3J0LQ0KPiA+IG9yaWVudGVkDQo+ID4gPiA+IE9BTQ0K PiA+ID4gPiA+PiBmdW5jdGlvbnMuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFlvdSBjYW4gZG93 bmxvYWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIFkuMTczMSAodGhlIHBkciB2ZXJzaW9uDQo+ID4g aXMNCj4gPiA+ID4gZm9yIGZyZWUpIGF0DQo+ID4gPiA+ID4+IHRoZSBmb2xsb3dpbmcgVVJMOg0K PiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBodHRwOi8vd3d3Lml0dS5pbnQvcmVjL1QtUkVDLVkuMTcz MS9lbg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBJdCBpcyBhIHBpdHkgdGhhdCB3aXRoIHRoZSBj dXJyZW50IHZlcnNpb24gb2YgdGhlIGlkZW50aWZpZXINCj4gPiBkcmFmdCwNCj4gPiA+ID4gTVBM Uy1UUCBpcw0KPiA+ID4gPiA+PiBub3QgY2FwYWJsZSB0byBzdXBwb3J0IHN1Y2ggYSBuZXR3b3Jr IHNjZW5hcmlvLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+Pj4gLS0tLU1lc3NhZ2dpbyBvcmlnaW5h bGUtLS0tDQo+ID4gPiA+ID4+PiBEYTogbG9hQHBpLm51DQo+ID4gPiA+ID4+PiBEYXRhOiA0LW1h Zy0yMDExIDguMDANCj4gPiA+ID4gPj4+IEE6PG1wbHNAaWV0Zi5vcmc+LA0KPiA+ID4gPiA+PiAi TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIjxNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+DQo+ID4g PiA+ID4+PiBPZ2c6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExT LVRQDQo+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gTWFsY29sbSwN Cj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBhcmUgeW91IHNheWluZyB0aGF0IG9wZXJhdG9ycyB0 b2RheSBhbGxvdyBPQU0gdG8gY29udHJvbCBub2RlDQo+ID4gKE1JUHMNCj4gPiA+ID4gYW5kDQo+ ID4gPiA+ID4+PiBNRVBzKSBvbiBlYWNoIG90aGVycyBuZXR3b3Jrcz8NCj4gPiA+ID4gPj4+DQo+ ID4gPiA+ID4+PiBEbyB3ZSBoYXZlIGFuIG9wZXJhdG9yIHRoYXQgY2FuIHZlcmlmeSB0aGlzPw0K PiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IC9Mb2ENCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBP biAyMDExLTA1LTAzIDIyOjQ0LCBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4g PiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBBbGwsDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBJ IHNoYXJlIHlvdXIgY29uY2VybnMgYW5kIGRvdWJ0cyBhYm91dCBhIG11bHRpIGNhcnJpZXINCj4g Y29udHJvbA0KPiA+ID4gPiBwbGFuZS4NCj4gPiA+ID4gPj4+PiBIb3dldmVyLCBJIHRoaW5rIHRo YXQgaXQgaXMgZXNzZW50aWFsIHRoYXQgYSB0cmFuc3BvcnQNCj4gbmV0d29yaw0KPiA+ID4gPiBz dXBwb3J0cw0KPiA+ID4gPiA+Pj4+IG11bHRpIGNhcnJpZXIgZGF0YSBwbGFuZSBpbnRlcmNvbm5l Y3Rpb24gd2l0aCBlbmQgdG8gZW5kDQo+IE9BTS4NCj4gPiBJbg0KPiA+ID4gPiB0b2RheSdzDQo+ ID4gPiA+ID4+Pj4gdHJhbnNwb3J0IG5ldHdvcmsgdGhpcyBpbnRlcmNvbm5lY3Rpb24gaXMgc3Vw cG9ydGVkIGJ5IFNESA0KPiBhbmQNCj4gPiA+ID4gT1ROLiBUaGUNCj4gPiA+ID4gPj4+PiBvYmpl Y3RpdmUgZm9yIE1QTFMtVFAgaXMgdG8gYWxsb3cgZm9yIHBhY2tldCBiYXNlZA0KPiA+IGludGVy Y29ubmVjdGlvbg0KPiA+ID4gPiBhcw0KPiA+ID4gPiA+PiB3ZWxsLg0KPiA+ID4gPiA+Pj4+DQo+ ID4gPiA+ID4+Pj4gUmVnYXJkcywNCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+IE1hbGNvbG0N Cj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiAq R2VvcmdlIFN3YWxsb3c8c3dhbGxvd0BjaXNjby5jb20+Kg0KPiA+ID4gPiA+Pj4+IFNlbnQgYnk6 IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4gMDMvMDUv MjAxMSAxMTowOSBBTQ0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBU bw0KPiA+ID4gPiA+Pj4+ICAgICJBbmRyZXcgRy4NCj4gPiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5j b20+LDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ID4gPiA+Pj4+IGNjDQo+ID4gPiA+ID4+ Pj4gICAgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+Pj4+IFN1YmplY3QNCj4gPiA+ID4gPj4+PiAg ICBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiA+IElk ZW50aWZpZXJzPw0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+Pg0KPiA+ ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+DQo+ID4g PiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBBbmR5IC0NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+ ICAgPiAgU3VjaA0KPiA+ID4gPiA+Pj4+ICAgPiAgYW4gRS1OTkkgZGVmaW5pdGlvbiBkb2VzIG5v dCB5ZXQgZXhpc3QgZm9yIE1QTFMtVFANCj4gPiAoc29tZXRoaW5nDQo+ID4gPiA+IGVsc2UgdG8N Cj4gPiA+ID4gPj4+PiAgID4gIHB1dCBvbiB0aGUgdG8tZG8gbGlzdCkuIFRoaXMgRS1OTkkgd291 bGQgYWxzbyBpbmNsdWRlDQo+ID4gc2ltaWxhcg0KPiA+ID4gPiA+Pj4+ICAgPiAgaWRlbnRpZmll ciBtYXBwaW5nL3RyYW5zbGF0aW9uIGZvciBNUy1QV3MsIHRvIGFuc3dlciBhbg0KPiA+ID4gPiBl YXJsaWVyDQo+ID4gPiA+ID4+Pj4gICA+ICBxdWVzdGlvbiBmcm9tIEVybWluaW8gdGhhdCBJIHNh dyBvbiB0aGUgbGlzdC4NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+IFlvdSBhcmUgcXVpdGUg Y29ycmVjdCBoZXJlISBJIHRoaW5rIG11Y2ggb2YgdGhpcyBkZWJhdGUNCj4gPiBzdXJyb3VuZHMN Cj4gPiA+ID4gYQ0KPiA+ID4gPiA+PiBwcm9ibGVtDQo+ID4gPiA+ID4+Pj4gdGhhdCBpcyB5ZXQg dG8gYmUgc29sdmVkLiBTbyB0aGVyZSBhcmUgYXJndW1lbnRzIGZvciBwaWVjZXMNCj4gb2YNCj4g PiBhDQo+ID4gPiA+IHNvbHV0aW9uDQo+ID4gPiA+ID4+Pj4gd2l0aG91dCBhbmQgb3ZlcmFsbCBh cmNoaXRlY3R1cmUuDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBCYXNlZCBvbiBhbGwgdGhh dCBJIGFtIHNlZWluZyBteSBpbmNsaW5hdGlvbiBpcyB0byBOT1Qgc2F5DQo+ID4gdGhhdCB3ZQ0K PiA+ID4gPiA+PiBkaXNhbGxvdw0KPiA+ID4gPiA+Pj4+IG1peGVkIGlkZW50aWZpZXJzLCBidXQg dG8gc2F5IHRoYXQgdGhleSBhcmUgZm9yIGZ1dHVyZQ0KPiBzdHVkeS4NCj4gPiA+ID4gPj4+Pg0K PiA+ID4gPiA+Pj4+IC4uLkdlb3JnZQ0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBPbiA1LzMv MTEgODozOCBBTSwgIkFuZHJldyBHLiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+DQo+ID4gd3Jv dGU6DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiAgID4gIE5laWwsDQo+ID4gPiA+ID4+Pj4g ICA+DQo+ID4gPiA+ID4+Pj4gICA+ICBUbyB5b3VyIGNhc2UgMSwgd2UncmUgaW4gY29tcGxldGUg YWdyZWVtZW50LiBXZSAoVlopDQo+ID4gZG9uJ3QNCj4gPiA+ID4gc2VlIGF0DQo+ID4gPiA+ID4+ Pj4gICA+ICBsZWFzdCBhIHNob3J0LXRlcm0gbmVlZCBmb3IgcGVlci1sYXllciBpbnRlcndvcmtp bmcsDQo+ID4gZ2l2ZW4NCj4gPiA+ID4gd2hlcmUgd2UNCj4gPiA+ID4gPj4+PiAgID4gIGludGVu ZCB0byBkZXBsb3kgTVBMUy1UUCBpbiBvdXIgaW5mcmFzdHJ1Y3R1cmUgKGFzIGFuDQo+ID4gPiA+ IGludGVybmFsIHNlcnZlcg0KPiA+ID4gPiA+Pj4+ICAgPiAgbGF5ZXIgaW4gdGhlIHRyYW5zcG9y dCBjb3JlKS4gSWYgcGVlciBsYXllcg0KPiBpbnRlcndvcmtpbmcNCj4gPiBldmVyDQo+ID4gPiA+ IGJlY29tZXMNCj4gPiA+ID4gPj4+PiAgID4gIGEgbmVjZXNzaXR5LCB0aGVuIG9idmlvdXNseSB3 ZSdsbCBuZWVkIGEgd2VsbC1kZWZpbmVkDQo+IEUtDQo+ID4gTk5JDQo+ID4gPiA+IHdoaWNoDQo+ ID4gPiA+ID4+Pj4gICA+ICB3b3VsZCBpbmNsdWRlIExTUCBpZGVudGlmaWVyIG1hcHBpbmcvdHJh bnNsYXRpb24gYXQgdGhlDQo+ID4gPiA+IGJvdW5kYXJ5LCBmb3INCj4gPiA+ID4gPj4+PiAgID4g IExTUCBwcm92aXNpb25pbmcgKHdoZXRoZXIgc3RhdGljIG9yIGR5bmFtaWMpIGFuZCBlbmQtDQo+ IHRvLQ0KPiA+IGVuZA0KPiA+ID4gPiBPQU0uIFN1Y2gNCj4gPiA+ID4gPj4+PiAgID4gIGFuIEUt Tk5JIGRlZmluaXRpb24gZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQDQo+ID4gKHNvbWV0 aGluZw0KPiA+ID4gPiBlbHNlIHRvDQo+ID4gPiA+ID4+Pj4gICA+ICBwdXQgb24gdGhlIHRvLWRv IGxpc3QpLiBUaGlzIEUtTk5JIHdvdWxkIGFsc28gaW5jbHVkZQ0KPiA+IHNpbWlsYXINCj4gPiA+ ID4gPj4+PiAgID4gIGlkZW50aWZpZXIgbWFwcGluZy90cmFuc2xhdGlvbiBmb3IgTVMtUFdzLCB0 byBhbnN3ZXIgYW4NCj4gPiA+ID4gZWFybGllcg0KPiA+ID4gPiA+Pj4+ICAgPiAgcXVlc3Rpb24g ZnJvbSBFcm1pbmlvIHRoYXQgSSBzYXcgb24gdGhlIGxpc3QuDQo+ID4gPiA+ID4+Pj4gICA+DQo+ ID4gPiA+ID4+Pj4gICA+ICBJIGFsc28gYWdyZWUgdGhhdCBib3RoIGludHJhLWxheWVyIGFuZCBp bnRlci1sYXllciBtaXMtDQo+ID4gPiA+IGNvbm5lY3Rpdml0eQ0KPiA+ID4gPiA+Pj4+ICAgPiAg ZGV0ZWN0aW9uIGFuZCBhbWVsaW9yYXRpb24gYXJlIHJlcXVpcmVkLCBidXQgSSdtIG5vdA0KPiA+ ID4gPiBjb252aW5jZWQgdGhhdA0KPiA+ID4gPiA+Pj4+ICAgPiAgdGhlIGFscmVhZHkgZGVmaW5l ZCBtZWNoYW5pc21zIGNhbid0IGRvIHRoYXQuIERvIHlvdQ0KPiBoYXZlDQo+ID4gPiA+IHNvbWUN Cj4gPiA+ID4gPj4+PiAgID4gIHNwZWNpZmljIGFuYWx5c2lzIG9uIHRoZSBpbnRlci1sYXllciBj YXNlPw0KPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+Pj4+ICAgPiAgQ2hlZXJzLA0KPiA+ID4g PiA+Pj4+ICAgPiAgQW5keQ0KPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+Pj4+ICAgPiAgT24g VHVlLCBNYXkgMywgMjAxMSBhdCAzOjM2IEFNLDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ ID4gPiB3cm90ZToNCj4gPiA+ID4gPj4+PiAgID4+ICBIaSBBbmR5LA0KPiA+ID4gPiA+Pj4+ICAg Pj4NCj4gPiA+ID4gPj4+PiAgID4+ICAyIHBvaW50czoNCj4gPiA+ID4gPj4+PiAgID4+DQo+ID4g PiA+ID4+Pj4gICA+PiAgMSBJIGFncmVlIHdpdGggeW91ciB2aWV3IG9mIG9ubHkgaGF2aW5nIGEg c2luZ2xlDQo+ID4gYWRkcmVzc2luZw0KPiA+ID4gPiBzY2hlbWUgaW4NCj4gPiA+ID4gPj4gYQ0K PiA+ID4gPiA+Pj4+ICAgPj4gIHNpbmdsZSBsYXllciBuZXR3b3JrIHNvbGVseSBiZWxvbmdpbmcg dG8gb25lIHBhcnR5Lg0KPiA+IFRob3VnaA0KPiA+ID4gPiB5b3UgbWF5DQo+ID4gPiA+ID4+Pj4g bmVlZCB0bw0KPiA+ID4gPiA+Pj4+ICAgPj4gIGJlIHJhdGhlciBjYXJlZnVsIGlmIHlvdSBhbHNv IGFkdm9jYXRlIHRoYXQgb25lIGNhbg0KPiBhbHNvDQo+ID4gPiA+IGhhdmUgcGVlcg0KPiA+ID4g PiA+PiBsYXllcg0KPiA+ID4gPiA+Pj4+ICAgPj4gIGludGVyd29ya2luZyBiZXR3ZWVuIGRpZmZl cmVudCBwYXJ0aWVzLCBpZSBFLU5OSXMgKEkNCj4gPiBiZWxpZXZlDQo+ID4gPiA+IHRoaXMgaXMN Cj4gPiA+ID4gPj4+PiAgID4+ICBzb21ldGhpbmcgeW91IG1heSBzdXBwb3J0LCBlZyBvbGQgTVBM U0YgY2FzZT8pLiBJbg0KPiBzdWNoDQo+ID4gYQ0KPiA+ID4gPiBwZWVyDQo+ID4gPiA+ID4+Pj4g aW50ZXJ3b3JraW5nDQo+ID4gPiA+ID4+Pj4gICA+PiAgY2FzZSBpdCB3b3VsZCBzZWVtIG9uZSBt dXN0IGFsbG93IGRpZmZlcmVudCBhZGRyZXNzaW5nDQo+ID4gPiA+IHNjaGVtZXMgKGFuZA0KPiA+ ID4gPiA+Pj4+IGluZGVlZA0KPiA+ID4gPiA+Pj4+ICAgPj4gIGFueSBvdGhlciB2YXJpYXRpb25z IGluIERQL0NQIGZ1bmN0aW9uYWwgY29tcG9uZW50cykNCj4gaWYNCj4gPiB0aGV5DQo+ID4gPiA+ IGV4aXN0DQo+ID4gPiA+ID4+Pj4gaW4gdGhlDQo+ID4gPiA+ID4+Pj4gICA+PiAgc3RhbmRhcmRz Lg0KPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPj4+PiAgID4+ICBPZiBjb3Vyc2UsIGhhdmlu ZyBhbiBFLU5OSSBhbmQgcGVlciBpbnRlcndvcmtpbmcNCj4gYmV0d2Vlbg0KPiA+ID4gPiBkaWZm ZXJlbnQNCj4gPiA+ID4gPj4+PiBwYXJ0aWVzIGluDQo+ID4gPiA+ID4+Pj4gICA+PiAgYW55IG5v bi1UT1MgbGF5ZXIgbmV0d29yayAobm90IGp1c3QgTVBMUykgaXMgbm90DQo+ID4gdGVjaG5pY2Fs bHkNCj4gPiA+ID4gPj4+PiBuZWNlc3NhcnkgKHRoaXMNCj4gPiA+ID4gPj4+PiAgID4+ICBpcyB0 cml2aWFsIHRvIHByb3ZlKSwgYW5kIHRoaXMgcHJvdmlkZXMgYSBzdHJvbmcNCj4gPiBhcmd1bWVu dA0KPiA+ID4gPiBmb3Igb25seQ0KPiA+ID4gPiA+Pj4+IGhhdmluZyBhDQo+ID4gPiA+ID4+Pj4g ICA+PiAgc2luZ2xlIGFkZHJlc3Npbmcgc2NoZW1lIGluIGEgbm9uLVRPUyBsYXllciBuZXR3b3Jr Lg0KPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4+Pj4gICA+ PiAgMiBZb3Ugc2hvdWxkIGFsc28gYmUgYXdhcmUgdGhhdCBpbiBjbGllbnQvc2VydmVyDQo+ID4g PiA+IGludGVyd29ya2luZyBvZiB0aGUNCj4gPiA+ID4gPj4+PiAgID4+ICBjby1wcyBtb2RlIHVz aW5nIHZhcmlhYmxlIHNpemUgdHJhZmZpYyB1bml0cywgYW5kDQo+ID4gdGhlcmVmb3JlDQo+ID4g PiA+ID4+Pj4gc29tZXRoaW5nIHJhdGhlcg0KPiA+ID4gPiA+Pj4+ICAgPj4gIGltcG9ydGFudCBm b3IgTVBMUy1UUCBpbiB0aGUgcm9sZSBvZiBhIHRyYW5zcG9ydA0KPiBuZXR3b3JrDQo+ID4gPiA+ IChJJ2xsDQo+ID4gPiA+ID4+Pj4gaWdub3JlIGlzc3Vlcw0KPiA+ID4gPiA+Pj4+ICAgPj4gIG9m IHRyYW5zcGFyZW5jeSBoZXJlKSwgdGhlcmUgY291bGQgYmUgaW50ZXItbGF5ZXINCj4gPiA+ID4g bWlzY29ubmVjdGl2aXR5DQo+ID4gPiA+ID4+Pj4gKEFzaWRlPT4NCj4gPiA+ID4gPj4+PiAgID4+ ICBUaGlzIGNhc2UgY2Fubm90IG9jY3VyIGluIHRoZSBjby1jcyBtb2RlKS4gVG8gZGF0ZSwNCj4g PiBob3dldmVyLA0KPiA+ID4gPiB3ZSBoYXZlDQo+ID4gPiA+ID4+Pj4gb25seQ0KPiA+ID4gPiA+ Pj4+ICAgPj4gIHJlYWxseSBjb25zaWRlcmVkIGludHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSwg aWUNCj4gPiBiZXR3ZWVuDQo+ID4gPiA+IGRpZmZlcmVudA0KPiA+ID4gPiA+PiBMU1BzDQo+ID4g PiA+ID4+Pj4gICA+PiAgYmVsb25naW5nIHRvIHRoZSBzYW1lIHBhcnR5IChub3RlIHRoaXMgYWxz byBpbmNsdWRlcw0KPiBhbGwNCj4gPiA+ID4gY2FzZXMgb2YNCj4gPiA+ID4gPj4+PiBuZXN0ZWQg TFNQDQo+ID4gPiA+ID4+Pj4gICA+PiAgc3VibGF5ZXIgbWlzY29ubmVjdGl2aXR5KS4NCj4gPiA+ ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4+Pj4gICA+PiAgSW4gdGhlIGNhc2Ugb2YgaW50ZXItbGF5 ZXIgbWlzY29ubmVjdGl2aXR5IG9uZSBtYXkNCj4gPiByZWNlaXZlDQo+ID4gPiA+IHRyYWZmaWMN Cj4gPiA+ID4gPj4+PiB1bml0cyBhbmQNCj4gPiA+ID4gPj4+PiAgID4+ICBPQU0gbWVzc2FnZXMg ZnJvbSBzb21lIG90aGVyIHBhcnR5J3MgbGF5ZXIgbmV0d29yay4NCj4gVGhlDQo+ID4gT0FNDQo+ ID4gPiA+ID4+IG1lc3NhZ2VzDQo+ID4gPiA+ID4+IG1heQ0KPiA+ID4gPiA+Pj4+ICAgPj4gIGNv bWUgZnJvbSAoaSkgbmV0d29ya3MgdXNpbmcgZGlmZmVyZW50IE9BTS9hZGRyZXNzaW5nDQo+ID4g PiA+IHNvbHV0aW9ucyBvcg0KPiA+ID4gPiA+PiAoaWkpDQo+ID4gPiA+ID4+Pj4gICA+PiAgbmV0 d29ya3MgdXNpbmcgdGhlIHNhbWUgT0FNL2FkZHJlc3Npbmcgc29sdXRpb25zLiBJbg0KPiA+IGJv dGgNCj4gPiA+ID4gY2FzZXMNCj4gPiA+ID4gPj4+PiB0aGVyZSBhcmUNCj4gPiA+ID4gPj4+PiAg ID4+ICBkaWZmZXJlbnQgaXNzdWVzIHdydCBpbnRlci1sYXllciBtaXNjb25uZWN0aXZpdHkgb25l DQo+IGhhcw0KPiA+IHRvDQo+ID4gPiA+IGRlYWwNCj4gPiA+ID4gPj4+PiB3aXRoLiBJJ20NCj4g PiA+ID4gPj4+PiAgID4+ICBub3QgYXdhcmUgdGhhdCB0aGVzZSBjYXNlcyBoYXZlIGJlZW4gY29u c2lkZXJlZCB5ZXQuDQo+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ ID4gPj4+PiAgID4+ICBJJ2QgbGlrZSB0byBoZWFyIHlvdXIgY29tbWVudHMgb24gYm90aCB0aGVz ZSBwb2ludHMsDQo+IGJ1dA0KPiA+IGluDQo+ID4gPiA+ID4+Pj4gcGFydGljdWxhciB0aGUNCj4g PiA+ID4gPj4+PiAgID4+ICBmaXJzdCBvbmUuLi4uLmVzcGVjaWFsbHkgaWYgeW91IGFsc28gc3Vw cG9ydCB0aGUNCj4gbm90aW9uDQo+ID4gb2YNCj4gPiA+ID4gRS1OTklzIGluDQo+ID4gPiA+ID4+ Pj4gTVBMUy1UUCwNCj4gPiA+ID4gPj4+PiAgID4+ICBhcyB0aGVyZSBzZWVtcyB0byBhIHBvc3Np YmxlIGxvZ2ljYWwgY29uZmxpY3QgaGVyZS4NCj4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4+ Pj4gICA+PiAgVGhhbmtzLg0KPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPj4+PiAgID4+ICBy ZWdhcmRzLCBOZWlsIEhhcnJpc29uDQo+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+Pj4+ICAg Pj4gIEJUIERlc2lnbg0KPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPj4+PiAgID4+ICBUaGlz IGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUNCj4gPiBwcml2aWxl Z2VkDQo+ID4gPiA+IG9yDQo+ID4gPiA+ID4+Pj4gY29uZmlkZW50aWFsLg0KPiA+ID4gPiA+Pj4+ ICAgPj4gIEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5h bWVkDQo+ID4gYWJvdmUuDQo+ID4gPiA+IElmDQo+ID4gPiA+ID4+Pj4geW91J3JlIG5vdA0KPiA+ ID4gPiA+Pj4+ICAgPj4gIHRoZSBpbnRlbmRlZA0KPiA+ID4gPiA+Pj4+ICAgPj4gIHJlY2lwaWVu dCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZw0KPiA+IG9yDQo+ ID4gPiA+IHVzaW5nIHRoaXMNCj4gPiA+ID4gPj4+PiAgID4+ICBpbmZvcm1hdGlvbg0KPiA+ID4g PiA+Pj4+ICAgPj4gIGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLA0KPiA+ID4gPiBwbGVhc2UgbGV0IG1lDQo+ID4gPiA+ID4+Pj4ga25vdw0KPiA+ ID4gPiA+Pj4+ICAgPj4gIGltbWVkaWF0ZWx5DQo+ID4gPiA+ID4+Pj4gICA+PiAgb24gdGhlIGVt YWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4gPiA+ID4gPj4+PiAgID4+ICBXZSBtb25p dG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXINCj4gZW1haWxzLg0KPiA+ ID4gPiA+Pj4+ICAgPj4gIEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ID4gPiA+ Pj4+ICAgPj4gIFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMx QSA3QUoNCj4gPiA+ID4gPj4+PiAgID4+ICBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAw MDANCj4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4+Pj4gICA+Pj4gIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtDQo+ID4gYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gT24gQmVo YWxmDQo+ID4gPiA+ID4+IE9mDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIEFuZHJldyBHLiBNYWxpcw0K PiA+ID4gPiA+Pj4+ICAgPj4+ICBTZW50OiAwMiBNYXkgMjAxMSAyMDo0OA0KPiA+ID4gPiA+Pj4+ ICAgPj4+ICBUbzogR2VvcmdlIFN3YWxsb3cNCj4gPiA+ID4gPj4+PiAgID4+PiAgQ2M6IG1wbHNA aWV0Zi5vcmcNCj4gPiA+ID4gPj4+PiAgID4+PiAgU3ViamVjdDogUmU6IFttcGxzXSBNaXhpbmcg SUNDIGFuZCBHbG9iYWwtSURzIGluDQo+IE1QTFMtDQo+ID4gVFANCj4gPiA+ID4gSWRlbnRpZmll cnM/DQo+ID4gPiA+ID4+Pj4gICA+Pj4NCj4gPiA+ID4gPj4+PiAgID4+PiAgR2VvcmdlIGV0IGFs LA0KPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4+Pj4gICA+Pj4gIFZlcml6b24gZG9lcyBu b3QgaGF2ZSBhbnkgcmVxdWlyZW1lbnQgZm9yIG1peGVkIHVzZQ0KPiBvZg0KPiA+ID4gPiBHbG9i YWwgSURzIGFuZA0KPiA+ID4gPiA+Pj4+ICAgPj4+ICBJQ0NzLiBXZSBhcmUgZmluZSB3aXRoIHNw ZWNpZmljYXRpb25zIHRoYXQgcmVxdWlyZQ0KPiBib3RoDQo+ID4gPiA+IGVuZHMgb2YgYW4NCj4g PiA+ID4gPj4gTFNQDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIHRvIHVzZSBvbmUgb3IgdGhlIG90aGVy Lg0KPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4+Pj4gICA+Pj4gIFRoYW5rcywNCj4gPiA+ ID4gPj4+PiAgID4+PiAgQW5keQ0KPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4+Pj4gICA+ Pj4gIE9uIE1vbiwgQXByIDI1LCAyMDExIGF0IDU6MTYgUE0sIEdlb3JnZQ0KPiA+ID4gPiBTd2Fs bG93PHN3YWxsb3dAY2lzY28uY29tPg0KPiA+ID4gPiA+Pj4+ICAgPj4+ICB3cm90ZToNCj4gPiA+ ID4gPj4+PiAgID4+Pj4gIEFsbCAtDQo+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+ID4+Pj4g ICA+Pj4+ICBNYW55IG9mIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBJVFUgb24NCj4g PiA+ID4gPj4+PiAgID4+Pj4gIGRyYWZ0LWlldGYtbXBscy10cC1pZGVudGlmaWVycy0wNCBoYXZl IHRvIGRvIHdpdGgNCj4gdGhlDQo+ID4gPiA+IEdsb2JhbCBhbmQgSUNDDQo+ID4gPiA+ID4+Pj4g ICA+Pj4+ICBpZGVudGlmaWVycy4NCj4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPj4+PiAg ID4+Pj4gIFRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVHIGluY2x1 ZGUNCj4gPiA+ID4gZmllbGRzIHRvDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIGlkZW50aWZ5IGVhY2gN Cj4gPiA+ID4gPj4+PiAgID4+Pj4gIGVuZCBvZiBhbiBMU1AuIEN1cnJlbnRseSB0aGUgZHJhZnQg YWxsb3dzIGEgVHVubmVsLA0KPiA+IExTUCwNCj4gPiA+ID4gUFcsIG9yIE1FRw0KPiA+ID4gPiA+ Pj4+ICAgPj4+ICB0byB1c2UNCj4gPiA+ID4gPj4+PiAgID4+Pj4gIGVpdGhlciB0aGUgR2xvYmFs LUlEIGZvciBib3RoIGVuZHMgb3Igb3IgdGhlIElDQyBmb3INCj4gPiBib3RoDQo+ID4gPiA+IGVu ZHMuDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIE1peGVkIHVzZQ0KPiA+ID4gPiA+Pj4+ICAgPj4+PiAg aXMgbm90IHBlcm1pdHRlZC4NCj4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPj4+PiAgID4+ Pj4gIFRoZSBJVFUgbGlhaXNvbiByZXF1ZXN0cyB0aGF0IHdlIGFsbG93IG1peGVkIHVzZS4NCj4g PiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBhdXRob3JzIG9mIHRo ZSBkcmFmdCBhcmUgdmVyeSByZWx1Y3RhbnQgdG8gZG8NCj4gPiB0aGlzLg0KPiA+ID4gPiA+Pj4+ ICAgPj4+Pg0KPiA+ID4gPiA+Pj4+ICAgPj4+PiAgT2J0YWluaW5nIGFuIEFTIE51bWJlciAoZnJv bSB3aGljaCB0aGUgR2xvYmFsLUlEIGlzDQo+ID4gPiA+IGRlcml2ZWQpIGlzIGENCj4gPiA+ID4g Pj4+PiAgID4+PiAgZmFpcmx5DQo+ID4gPiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFsIHByb2NlZHVy ZS4gTWFueSBvcmdhbml6YXRpb25zIGlmIG5vdCBtb3N0DQo+ID4gYWxyZWFkeQ0KPiA+ID4gPiBo YXZlIEFTDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIE51bWJlcnMuDQo+ID4gPiA+ID4+Pj4gICA+Pj4+ ICBTdWNoIGFuIGFkZGl0aW9uIHdpbGwgYWRkIG51bWVyb3VzIG9iamVjdCBmb3JtYXRzLA0KPiBh bmQNCj4gPiA+ID4gdGVzdCBjYXNlcy4NCj4gPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBleHRlbnQg aW50ZXItcHJvdmlkZXIgTVBMUy1UUCBpcyBhcyB5ZXQgdW5rbm93bi4NCj4gPiBJZg0KPiA+ID4g PiBtaXhlZCBtb2Rlcw0KPiA+ID4gPiA+Pj4+ICAgPj4+ICBvZiBJQ0MNCj4gPiA+ID4gPj4+PiAg ID4+Pj4gIGFuZCBHbG9iYWwtSUQgaWRlbnRpZmljYXRpb24gaXMgcmVxdWlyZWQsIHRoZXkgY2Fu DQo+IGJlDQo+ID4gPiA+IGFkZGVkIGxhdGVyLg0KPiA+ID4gPiA+Pj4+ICAgPj4+PiAgRm9yIHNp Z25hbGVkIGNvbm5lY3Rpb25zLCB0aGVyZSBpcyBubyBwbGFuIHRvIGFsbG93DQo+ID4gPiA+IHJv dXRpbmcgYmFzZWQgb24NCj4gPiA+ID4gPj4+PiAgID4+PiAgZWl0aGVyDQo+ID4gPiA+ID4+Pj4g ICA+Pj4+ICB0aGUgR2xvYmFsLUlEIG9yIElDQy4gVGhhdCB3b3VsZCBiZSBhIHJhZGljYWwgY2hh bmdlDQo+ID4gdG8NCj4gPiA+ID4gaG93IElQDQo+ID4gPiA+ID4+Pj4gICA+Pj4gIHdvcmtzLg0K PiA+ID4gPiA+Pj4+ICAgPj4+PiAgSG93ZXZlciBmb3IgSVAgcm91dGluZyB0byB3b3JrIChpbiBv cmRlciB0byBmb3J3YXJkDQo+ID4gdGhlDQo+ID4gPiA+IHNpZ25hbGluZw0KPiA+ID4gPiA+Pj4+ ICAgPj4+PiAgbWVzc2FnZXMpLCB0aGUgcHJvdmlkZXJzIGludm9sdmVkIHdpbGwgbmVlZCB0byBy dW4NCj4gQkdQDQo+ID4gYW5kDQo+ID4gPiA+IGhhdmUgQVMNCj4gPiA+ID4gPj4+PiAgID4+PiAg bnVtYmVycy4NCj4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPj4+PiAgID4+Pj4gIFdlIGFy ZSBsb29raW5nIGZvciBpbnB1dC9jb25zZW5zdXMgZnJvbSB0aGUgV0cuDQo+ID4gPiA+ID4+Pj4g ICA+Pj4+DQo+ID4gPiA+ID4+Pj4gICA+Pj4+ICBHZW9yZ2UsIEVyaWMsJiAgTWF0dGhldw0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLQ0KPiA+ID4gPg0KPiA+ID4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPiA+ICoq Kg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4 ieS4gA0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG1w bHMgbWFpbGluZyBsaXN0DQo+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4g PiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From maarten.vissers@huawei.com Wed May 25 05:04:19 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 E6A0B13000D for ; Wed, 25 May 2011 05:04:19 -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.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 M3RGkw+0LBFY for ; Wed, 25 May 2011 05:04:18 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 941E3E0690 for ; Wed, 25 May 2011 05:04:17 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLR00JDC2V277@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 13:04:15 +0100 (BST) Received: from LHREML202-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLR003LU2V15V@lhrga02-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 13:04:14 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML202-EDG.china.huawei.com (172.18.7.189) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 13:04:06 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 25 May 2011 13:04:10 +0100 Date: Wed, 25 May 2011 12:04:10 +0000 From: Maarten vissers In-reply-to: <6D3D47CB84BDE349BC23BF1C94E316E440264057E4@EMV62-UKRD.domain1.systemhost.net> X-Originating-IP: [10.202.112.103] To: "neil.2.harrison@bt.com" , "adrian@olddog.co.uk" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-GB, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0QgAAECTCAACSAsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> <6D3D47CB84BDE349BC23BF1C94E316E440264057E4@EMV62-UKRD.domain1.systemhost.net> Subject: Re: [mpls] R: Re: 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, 25 May 2011 12:04:20 -0000 TmVpbCwNCg0KRllJLiBUaGUgY28tY3MgT0RVIGxheWVycyBoYXZlIHRoZSBzYW1lIHN0YWNraW5n IGNhcGFiaWxpdHkgYXMgTVBMUy1UUCBMU1AgYW5kIEVUSCBsYXllcnM7IGkuZS4gWG92ZXJYIGlz IHN1cHBvcnRlZCBhbmQgZGVwbG95ZWQuIEFzIHN1Y2ggaW4gT1ROIHdlIGNhbiBoYXZlIG1pc2Nv bm5lY3Rpb25zIGJldHdlZW4gZS5nLiBMTyBPRFUyIGFuZCBITyBPRFUyIGNvbm5lY3Rpb25zLiBU aGUgdHJhZmZpYyB1bml0cyBpbiBPVE4gYXJlIHZhcmlhYmxlIHNpemVkIHRyYWZmaWMgdW5pdHMu DQoNClJlZ2FyZHMsDQpNYWFydGVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbmVpbC4yLmhhcnJpc29uQGJ0LmNvbSBbbWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5j b21dDQo+IFNlbnQ6IDI1IE1heSAyMDExIDEzOjIzDQo+IFRvOiBNYWFydGVuIHZpc3NlcnM7IGFk cmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBS OiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+IElkZW50aWZpZXJz Pw0KPiANCj4gVGhlcmUgaXMgYW4gaW1wb3J0YW50IGRpZmZlcmVuY2UgaGVyZS4gIFdlIGNhbm5v dCBoYXZlICppbnRlciogbGF5ZXINCj4gbWlzY29ubmVjdGl2aXR5IGluIGNvLWNzIG1vZGUgbmV0 d29ya3MuLi50aGlzIGZvbGxvd3MgZGlyZWN0bHkgZnJvbSBob3cNCj4gdGhlIGxhYmVsbGluZyBv ZiByZXNvdXJjZSBwYXJ0aXRpb25zIHdvcmtzIGluIGVhY2ggb2YgdGhlIDMgbW9kZXMuICBTbw0K PiBpZiB0aGVyZSBpcyBhIG5lZWQgdG8gcHJvY2VzcyBkaWZmZXJlbnQgQ1YgJ1NBJyBJRHMgaGVy ZSB0aGVuIHRoYXQgaXMNCj4gZG93biB0byBhIHNlbGYtaW5mbGljdGVkIHBlZXJpbmcgY2FzZSBv ZiBmb3JjaW5nIG1vcmUgZnVuY3Rpb25hbGl0eQ0KPiB0aGFuIGEgdHJ1ZSBCT1MtcGh5c2ljYWwg Yml0IGludGVyY29ubmVjdCBjYXNlIHJlcXVpcmVzLg0KPiANCj4gSG93ZXZlciwgd2hlbiB3ZSBo YXZlIGEgdmFyaWFibGUgc2l6ZSB0cmFmZmljIHVuaXQgaW4gdGhlIGNvLXBzIG1vZGUsDQo+IGFz IHdlIGhhdmUgd2l0aCBNUExTLVRQLCB0aGVuIHdlIGNhbiBoYXZlIHNvbWV0aGluZyB0aGF0IGxv b2tzIGxpa2UNCj4gWG92ZXJYIChhcyBtYW55IHRpbWVzIGFzIG9uZSBsaWtlcyAtIHN1YmplY3Qg dG8gPE1UVSkuICBTbywgaW4gYWRkaXRpb24NCj4gdG8gbWlzY29ubmVjdGl2aXR5IGR1ZSB0byBh bnkgc2VsZi1pbmZsaWN0ZWQgcGVlcmluZyBjYXNlLCB3ZSBjYW4gYWxzbw0KPiBoYXZlIChpKSBt aXNjb25uZWN0aXZpdHkgYmV0d2VlbiBsYXllcnMgYXQgZGlmZmVyZW50IGxldmVscyBvciAoaWkp DQo+IGJldHdlZW4gZGlmZmVyZW50L2luZGVwZW5kZW50IGxheWVyIG5ldHdvcmtzIGF0IGxldmVs IE4gc2F5IGR1ZSB0byBhDQo+IHNlcnZlciBsYXllciBtaXNjb25uZWN0aXZpdHkgZGVmZWN0IGJl bG93IGxldmVsIE4uICBUaGUga2V5IHBvaW50cyBoZXJlDQo+IGJlaW5nOg0KPiAgKGkpIGEgcmlj aGVyIGRlZmVjdCBlbnZpcm9ubWVudCB0aGFuIHRoZSBjby1jcyBtb2RlDQo+IChpaSkgaWYgTiB0 eXBlcyBvZiBDViAnSUQnIGV4aXN0IHRoZW4gd2UgY2FuJ3QgYXNzdW1lIHRoZXkgcmVtYWluDQo+ IGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIgYXQgYWxsLi4uLmFzIHdlIGNvdWxkIGlmIHdlIGRp ZCBub3QgaW1wb3NlIGENCj4gc2VsZi1pbmZsaWN0ZWQgcGVlciBjYXNlIG9uIG91cnNlbHZlcy4u LmFuZCB0aHVzIGVhY2ggbmV0d29yayBtdXN0IGJlDQo+IGFibGUgdG8gaGFuZGxlIGFsbCBOIGlu c3RhbmNlcyBvZiBJRCAoSSBhc3N1bWUgdGhlIHNhbWUgQ1YgT0FNIHRyYWZmaWMNCj4gdW5pdCBj YXJyeWluZyB0aGVtIC0gdmFyeWluZyB0aGF0IGp1c3QgbWFrZXMgdGhlIG1peCBldmVuIG1vcmUN Cj4gaW50ZXJlc3RpbmcpLg0KPiANCj4gcmVnYXJkcywgTmVpbA0KPiBCVCBEZXNpZ24NCj4gDQo+ IFRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxl Z2VkIG9yDQo+IGNvbmZpZGVudGlhbC4NCj4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZp ZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSdyZQ0KPiBub3QgdGhlIGludGVu ZGVkDQo+IHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1 dGluZyBvciB1c2luZyB0aGlzDQo+IGluZm9ybWF0aW9uDQo+IGlzIHByb2hpYml0ZWQuIElmIHlv dSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0IG1lDQo+IGtub3cg aW1tZWRpYXRlbHkNCj4gb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4g V2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWlscy4N Cj4gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQo+IFJlZ2lzdGVyZWQgb2ZmaWNlOiA4 MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5k IG5vOiAxODAwMDAwDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4gTWFhcnRlbiB2aXNzZXJzDQo+ID4g U2VudDogMjUgTWF5IDIwMTEgMTA6NDINCj4gPiBUbzogYWRyaWFuQG9sZGRvZy5jby51azsgbXBs c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5k IEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiA+IElkZW50aWZpZXJzPw0KPiA+DQo+ID4gQWRyaWFu LA0KPiA+DQo+ID4gUGxlYXNlIGJlIGF3YXJlIHRoYXQgdW5kZXIgZmF1bHQgY29uZGl0aW9ucyBh biBJQ0MgZm9ybWF0dGVkIElEIGNhbg0KPiBiZQ0KPiA+IHJlY2VpdmVkIGJ5IGFuIGVuZHBvaW50 IHVzaW5nIGEgR2xvYmFsX0lEIGZvcm1hdHRlZCBJRCwgYW5kIHZpY2UNCj4gdmVyc2EuDQo+ID4g RWl0aGVyIGVuZHBvaW50IG11c3QgYmUgYWJsZSB0byBkZXRlY3QgYSBtaXNjb25uZWN0aW9uIGNv bmRpdGlvbiBhbmQNCj4gYmUNCj4gPiBhYmxlIHRvIHJlcG9ydCB0aGUgcmVjZWl2ZWQgSUQgKGlu IHRoZSBub24tZXhwZWN0ZWQgZm9ybWF0KSB0byBOTVMgdG8NCj4gPiBndWlkZSBpbiB0aGUgZmF1 bHQgbG9jYWxpc2F0aW9uLg0KPiA+DQo+ID4gTm90ZSB0aGF0IHdlIG92ZXJsb29rZWQgYSBzaW1p bGFyIHJlcXVpcmVtZW50IGluaXRpYWxseSBpbiBTREggKDE2LQ0KPiBieXRlDQo+ID4gVFRJIGFu ZCA2NC1ieXRlIFRUSSksIGFuZCB0aGlzIHJlcXVpcmVkIHVzIHRvIHVwZ3JhZGUgb3VyIFZDLW4N Cj4gPiBlbmRwb2ludHMgYWZ0ZXJ3YXJkcy4gTGV0J3Mgbm90IG1ha2UgYSBzaW1pbGFyIG1pc3Rh a2UgaW4gTVBMUy1UUC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gTWFhcnRlbg0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbXBscy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiBP Zg0KPiA+ID4gQWRyaWFuIEZhcnJlbA0KPiA+ID4gU2VudDogMjUgTWF5IDIwMTEgMTE6MTMNCj4g PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBN aXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4gPiA+IElkZW50aWZpZXJzPw0K PiA+ID4NCj4gPiA+IEhpIE5laWwsDQo+ID4gPg0KPiA+ID4gSSdtIG5vdCBhc3N1bWluZyBwZWVy aW5nLiBJIGFtIGFjdHVhbGx5IHBvaW50aW5nIG91dCB0byBIdXViIHRoYXQNCj4gPiA+IChkZXNw aXRlIHdoYXQgaGUga2VlcHMgc2F5aW5nKSBoZSBpcyBhbHNvIG5vdCBhc3N1bWluZyBwZWVyaW5n Lg0KPiA+ID4NCj4gPiA+IFRoZSBjb25zZXF1ZW5jZSBvZiBub3QgcGVlcmluZyBpcyB0aGF0IGEg c2luZ2xlIGlkZW50aWZpZXIgbW9kZSBpcw0KPiA+IHVzZWQNCj4gPiA+IGZvciBib3RoIGVuZHMg b2YgYW4gT0FNICJzZXNzaW9uIi4gQW5kIHRoYXQgbWVhbnMgdGhhdCBvbmUgZW5kIGhhcw0KPiB0 bw0KPiA+ID4gdW5kZXJzdGFuZCAqYW5kKiB1c2UgdGhlICJmb3JlaWduIiBmb3JtYXQgYXQgdGhl IHJlbW90ZSBlbmQgb2YgdGhlDQo+ID4gPiBzZXNzaW9uLg0KPiA+ID4NCj4gPiA+IEkgYW0gdGly ZWQgb2YgdGhpcyBkaXNjdXNzaW9uLiBUaGVyZSBzZWVtcyB0byBiZSBubyBmb3J3YXJkDQo+IHBy b2dyZXNzDQo+ID4gPiBvbmx5IHJlc3RhdGVtZW50IG9mIGEgIndhbnQiLiBJIGFsd2F5cyB3YW50 ZWQgYSBwb255IHdoZW4gSSB3YXMgYQ0KPiA+ID4gbGl0dGxlIGdpcmwsIGJ1dCBJIG5ldmVyIGdv dCBvbmUuDQo+ID4gPg0KPiA+ID4gQWRyaWFuDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmDQo+ID4gPiBPZg0KPiA+ID4g PiBuZWlsLjIuaGFycmlzb25AYnQuY29tDQo+ID4gPiA+IFNlbnQ6IDIyIE1heSAyMDExIDIwOjM2 DQo+ID4gPiA+IFRvOiBodXViYXR3b3JrQGdtYWlsLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ID4g PiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGlu IE1QTFMtVFANCj4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPg0KPiA+ID4gPiBIaSBBZHJpYW4v SHV1YiwNCj4gPiA+ID4NCj4gPiA+ID4gWW91IGFyZSBsYXJnZWx5IGFzc3VtaW5nIHNvbWUgZm9y bSBvZiBwZWVyaW5nIChzaW5nbGUgcGFydGl0aW9uZWQNCj4gPiA+IGxheWVyIG5ldHdvcmspDQo+ ID4gPiA+IGhlcmUuLi5hbmQgdGhhdCBtb2RlbCB3aWxsIGdlbmVyYXRlIGEgd2hvbGUgcmFmdCBv ZiBwcm9ibGVtcyBmb3INCj4gPiA+IG9wZXJhdG9ycyBJTU8uDQo+ID4gPiA+IEEgbW9yZSBpbXBv cnRhbnQgbW9kZWwgZm9yIGEgY28tcHMgdHJhbnNwb3J0IG5ldHdvcmsgaXMNCj4gPiA+IGNsaWVu dC9zZXJ2ZXIuICBBbmQgbm93DQo+ID4gPiA+IG5vdCBvbmx5IGhhdmUgd2UgdGhlIHVzdWFsIGlu dHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSB0byBkZWFsDQo+IHdpdGgNCj4gPiA+IGJ1dCB3ZSBh bHNvDQo+ID4gPiA+IGhhdmUgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5Li4uYW5kIHRoaXMg bWVhbnMgZWFjaCBvcGVyYXRpbmcNCj4gPiA+IHBhcnR5IG11c3QNCj4gPiA+ID4gdW5kZXJzdGFu ZCB0aGUgT0FNIGZvcm1hdHMgKGFuZCBDViBJRHMpIG9mIGVhY2ggb3RoZXIgYW55d2F5Li4uDQo+ IG5vdA0KPiA+ID4gc2ltcGx5IHRvDQo+ID4gPiA+IGRldGVjdCB0aGVyZSBpcyBhIG1pc2Nvbm5l Y3Rpdml0eSBwcm9ibGVtcyBidXQgYWxzbyB0byBpZGVudGlmeQ0KPiA+IHdoaWNoDQo+ID4gPiBv dGhlciBwYXJ0aWVzDQo+ID4gPiA+IGFyZSBpbnZvbHZlZC4NCj4gPiA+ID4NCj4gPiA+ID4gcmVn YXJkcywgTmVpbA0KPiA+ID4gPg0KPiA+ID4gPiBCVCBEZXNpZ24NCj4gPiA+ID4gVGhpcyBlbWFp bCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4g PiA+IGNvbmZpZGVudGlhbC4NCj4gPiA+ID4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZp ZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmDQo+ID4gPiB5b3UncmUgbm90IHRoZQ0K PiA+ID4gPiBpbnRlbmRlZA0KPiA+ID4gPiByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5n LCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcNCj4gPiB0aGlzDQo+ID4gPiBpbmZvcm1h dGlvbg0KPiA+ID4gPiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIGxldA0KPiA+IG1lDQo+ID4gPiBrbm93DQo+ID4gPiA+IGltbWVk aWF0ZWx5DQo+ID4gPiA+IG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuDQo+ ID4gPiA+IFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBl bWFpbHMuDQo+ID4gPiA+IEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ID4gPiBS ZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQo+ID4g PiA+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4g RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiA+ID4gQmVoYWxmIE9mDQo+ID4gPiA+ID4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gPiA+ ID4gPiBTZW50OiAyMiBNYXkgMjAxMSAxOToxNQ0KPiA+ID4gPiA+IFRvOiBtcGxzQGlldGYub3Jn DQo+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xv YmFsLUlEcyBpbiBNUExTLVRQDQo+ID4gPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBIaSBBZHJpYW4sDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTZWUgbXkgcmVzcG9uc2Ug aW4tbGluZSBbaHZoXQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBXZSBoYXZlIGFscmVhZHkgYmVl biByb3VuZCB0aGlzIGxvb3Agb24gdGhpcyBsaXN0IG9uY2UuDQo+ID4gPiA+ID4gPiBXYW50IHRv IGRvIGl0IGFnYWluPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW2h2aF0gSWYgaXQgaGVscHMgdG8g Z2V0IHRvIHRoZSBmb2NhbCBwb2ludCwgd2h5IG5vdC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g QXMgSHV1YiBzYWlkLCB0aGlzIGlzIGFib3V0IGlkZW50aWZpZXJzLCBub3QgT0FNLiBIb3dldmVy LA0KPiB0aGUNCj4gPiA+IG1vZGVsDQo+ID4gPiA+ID4gZm9yIE9BTQ0KPiA+ID4gPiA+ID4gaW50 ZXJ3b3JraW5nIHNob3dzICJsYXllcmluZyIgbm90IGdhdGV3YXlpbmcsIGFuZCBjZXJ0YWlubHkN Cj4gbm90DQo+ID4gPiA+ID4gbWl4aW5nLiBUaGF0IGlzLA0KPiA+ID4gPiA+ID4gb25lIGVuZCBv ZiB0aGUgZTJlIHBhdGggbXVzdCBiZSBjYXBhYmxlIG9mIG9wZXJhdGluZyBib3RoDQo+ID4gPiBz eXN0ZW1zLA0KPiA+ID4gPiA+IGJ1dCB0aGUgb3RoZXINCj4gPiA+ID4gPiA+IGRvZXMgbm90IG5l ZWQgdG8uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBbaHZoXSBPSyBpZiB5b3UgbWVhbiAiT0FNIHRv b2xzZXRzIiBieSAic3lzdGVtcyINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVG8gZXh0ZW5kIHRo aXMgbW9kZWwgdG8gaWRlbnRpZmllcnMgbWVhbnMgdGhhdCBvbmUgZW5kIG9mIHRoZQ0KPiA+IGUy ZQ0KPiA+ID4gPiA+IHBhdGggbXVzdA0KPiA+ID4gPiA+ID4gc3VwcG9ydCBib3RoIGlkZW50aWZp ZXIgZm9ybWF0cyBhbmQgdGhlIG90aGVyIGRvZXMgbm90IG5lZWQNCj4gdG8uDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBbaHZoXSB0byBiZSBtb3JlIHNwZWNpZmljIHRoZSBvcmlnaW5hdGluZyBlbmQg b2YgYW4gZTJlIHBhdGgNCj4gbXVzdA0KPiA+ID4gPiA+IGJlIGFibGUgdG8gc3VwcG9ydCBvbmUg b2YgdGhlIHBvc3NpYmxlIGlkZW50aWZpZXIgZm9ybWF0cywNCj4gPiBub3JtYWxseQ0KPiA+ID4g PiA+IHRoZSBpZGVudGlmaWVyIGZvcm1hdCBvZiB0aGUgbG9jYWwgb3BlcmF0b3IuIFRoZSB0ZXJt aW5hdGluZw0KPiBlbmQNCj4gPiA+IGFuZA0KPiA+ID4gPiA+IHRoZSBpbnRlcm1lZGlhdGUgcG9p bnRzIG9mIGFuIGUyZSBwYXRoIG11c3QgYmUgYWJsZSB0byB2ZXJpZnkNCj4gdGhlDQo+ID4gPiA+ ID4gZm9ybWF0IGluc2VydGVkIGF0IHRoZSBvcmlnaW4gaW5kZXBlbmRlbnQgb2YgdGhlIGxvY2Fs bHkgdXNlZA0KPiA+ID4gPiA+IGlkZW50aWZpZXINCj4gPiA+ID4gPiBmb3JtYXQuIFRoaXMgbWVh bnMgdGhhdCBpdCBtdXN0IGJlIHBvc3NpYmxlIHRvIHN1cHBvcnQNCj4gZGlmZmVyZW50DQo+ID4g PiA+ID4gaWRlbnRpZmllciBmb3JtYXRzIGluIHRoZSBBLS0+WiBhbnMgWi0tPkEgZGlyZWN0aW9u IG9mIGFuIGUyZQ0KPiA+IHBhdGguDQo+ID4gPiA+ID4gSS5lLiBtaXhpbmcgb2YgaWRlbnRpZmll ciBmb3JtYXRzIG11c3QgYmUgc3VwcG9ydGVkLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGlz IGJlY29tZXMgcGFydGljdWxhcmx5IGltcG9ydGFudCB0byB0aGUgdHJhbnNpdCBub2RlcyB0aGF0 DQo+ID4gbWF5DQo+ID4gPiA+ID4gaGF2ZSB0bw0KPiA+ID4gPiA+ID4gaW5zcGVjdCB0aGUgaWRl bnRpZmllcnMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBbaHZoXSB0aGUgaW5zcGVjdGlvbiB3aWxs IGNvbnNpc3Qgb2YgY29tcGFyaW5nIGEgcmVjZWl2ZWQgdmFsdWUNCj4gPiA+ID4gPiB3aXRoIGFu IGV4cGVjdGVkIHZhbHVlIHdoaWNoIGNhbiBoYXZlIGFueSBmb3JtYXQuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IE5vbmUgb2YgdGhpcyBpcyBuZXcgb3Igc3BlY2lmaWMgdG8gTVBMUy1UUC4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFtodmhdIEkgYWdyZWUsIG1peGluZyBvZiBpZGVudGlmaWVyIGZv cm1hdHMgaXQgbm90IHJlc3RyaWN0ZWQNCj4gdG8NCj4gPiA+ID4gPiBNUExTLVRQLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gUmVnYXJkcywgSHV1Yi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPj4gRnJvbTogbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPiBPbg0KPiA+ID4gQmVo YWxmDQo+ID4gPiA+ID4gT2YNCj4gPiA+ID4gPiA+PiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8u aXQNCj4gPiA+ID4gPiA+PiBTZW50OiAxOCBNYXkgMjAxMSAyMjoyNQ0KPiA+ID4gPiA+ID4+IFRv OiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmc7IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbg0KPiA+ ID4gPiA+ID4+IFN1YmplY3Q6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlE cyBpbiBNUExTLVRQDQo+ID4gPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4gPj4NCj4gPiA+ ID4gPiA+PiBBcHBlbmRpeCBJSSBvZiBZLjE3MzEgcHJvdmlkZXMgYSBnb29kIGV4YW1wbGUgYWJv dXQgaG93DQo+IGludGVyLQ0KPiA+ID4gZG9tYWluDQo+ID4gPiA+ID4gPj4gY29ubmVjdGl2aXR5 IHdpdGggZTJlIE9BTSBjYW4gYmUgcHJvdmlkZWQgdXNpbmcgdHJhbnNwb3J0LQ0KPiA+ID4gb3Jp ZW50ZWQNCj4gPiA+ID4gPiBPQU0NCj4gPiA+ID4gPiA+PiBmdW5jdGlvbnMuDQo+ID4gPiA+ID4g Pj4NCj4gPiA+ID4gPiA+PiBZb3UgY2FuIGRvd25sb2FkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBZ LjE3MzEgKHRoZSBwZHINCj4gdmVyc2lvbg0KPiA+ID4gaXMNCj4gPiA+ID4gPiBmb3IgZnJlZSkg YXQNCj4gPiA+ID4gPiA+PiB0aGUgZm9sbG93aW5nIFVSTDoNCj4gPiA+ID4gPiA+Pg0KPiA+ID4g PiA+ID4+IGh0dHA6Ly93d3cuaXR1LmludC9yZWMvVC1SRUMtWS4xNzMxL2VuDQo+ID4gPiA+ID4g Pj4NCj4gPiA+ID4gPiA+PiBJdCBpcyBhIHBpdHkgdGhhdCB3aXRoIHRoZSBjdXJyZW50IHZlcnNp b24gb2YgdGhlIGlkZW50aWZpZXINCj4gPiA+IGRyYWZ0LA0KPiA+ID4gPiA+IE1QTFMtVFAgaXMN Cj4gPiA+ID4gPiA+PiBub3QgY2FwYWJsZSB0byBzdXBwb3J0IHN1Y2ggYSBuZXR3b3JrIHNjZW5h cmlvLg0KPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPj4+IC0tLS1NZXNzYWdnaW8gb3JpZ2luYWxl LS0tLQ0KPiA+ID4gPiA+ID4+PiBEYTogbG9hQHBpLm51DQo+ID4gPiA+ID4gPj4+IERhdGE6IDQt bWFnLTIwMTEgOC4wMA0KPiA+ID4gPiA+ID4+PiBBOjxtcGxzQGlldGYub3JnPiwNCj4gPiA+ID4g PiA+PiAiTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIjxNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+ DQo+ID4gPiA+ID4gPj4+IE9nZzogUmU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURz IGluIE1QTFMtVFANCj4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ ID4+PiBNYWxjb2xtLA0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4+PiBhcmUgeW91IHNheWlu ZyB0aGF0IG9wZXJhdG9ycyB0b2RheSBhbGxvdyBPQU0gdG8gY29udHJvbA0KPiBub2RlDQo+ID4g PiAoTUlQcw0KPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4+PiBNRVBzKSBvbiBlYWNoIG90aGVy cyBuZXR3b3Jrcz8NCj4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+Pj4gRG8gd2UgaGF2ZSBhbiBv cGVyYXRvciB0aGF0IGNhbiB2ZXJpZnkgdGhpcz8NCj4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+ Pj4gL0xvYQ0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4+PiBPbiAyMDExLTA1LTAzIDIyOjQ0 LCBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4g PiA+ID4+Pj4gQWxsLA0KPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+IEkgc2hhcmUgeW91 ciBjb25jZXJucyBhbmQgZG91YnRzIGFib3V0IGEgbXVsdGkgY2Fycmllcg0KPiA+IGNvbnRyb2wN Cj4gPiA+ID4gPiBwbGFuZS4NCj4gPiA+ID4gPiA+Pj4+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBp dCBpcyBlc3NlbnRpYWwgdGhhdCBhIHRyYW5zcG9ydA0KPiA+IG5ldHdvcmsNCj4gPiA+ID4gPiBz dXBwb3J0cw0KPiA+ID4gPiA+ID4+Pj4gbXVsdGkgY2FycmllciBkYXRhIHBsYW5lIGludGVyY29u bmVjdGlvbiB3aXRoIGVuZCB0byBlbmQNCj4gPiBPQU0uDQo+ID4gPiBJbg0KPiA+ID4gPiA+IHRv ZGF5J3MNCj4gPiA+ID4gPiA+Pj4+IHRyYW5zcG9ydCBuZXR3b3JrIHRoaXMgaW50ZXJjb25uZWN0 aW9uIGlzIHN1cHBvcnRlZCBieSBTREgNCj4gPiBhbmQNCj4gPiA+ID4gPiBPVE4uIFRoZQ0KPiA+ ID4gPiA+ID4+Pj4gb2JqZWN0aXZlIGZvciBNUExTLVRQIGlzIHRvIGFsbG93IGZvciBwYWNrZXQg YmFzZWQNCj4gPiA+IGludGVyY29ubmVjdGlvbg0KPiA+ID4gPiA+IGFzDQo+ID4gPiA+ID4gPj4g d2VsbC4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiBSZWdhcmRzLA0KPiA+ID4gPiA+ ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+IE1hbGNvbG0NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4g Pj4+Pg0KPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+ICpHZW9yZ2UgU3dhbGxvdzxzd2Fs bG93QGNpc2NvLmNvbT4qDQo+ID4gPiA+ID4gPj4+PiBTZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcNCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiAwMy8wNS8yMDExIDExOjA5IEFN DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+IFRvDQo+ID4g PiA+ID4gPj4+PiAgICAiQW5kcmV3IEcuDQo+ID4gPiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+ LDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ID4gPiA+ID4+Pj4gY2MNCj4gPiA+ID4gPiA+ Pj4+ICAgIG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+Pj4+IFN1YmplY3QNCj4gPiA+ID4gPiA+ Pj4+ICAgIFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4g PiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4+Pj4N Cj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4+Pj4gQW5keSAtDQo+ ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBTdWNoDQo+ID4gPiA+ID4gPj4+PiAg ID4gIGFuIEUtTk5JIGRlZmluaXRpb24gZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQDQo+ ID4gPiAoc29tZXRoaW5nDQo+ID4gPiA+ID4gZWxzZSB0bw0KPiA+ID4gPiA+ID4+Pj4gICA+ICBw dXQgb24gdGhlIHRvLWRvIGxpc3QpLiBUaGlzIEUtTk5JIHdvdWxkIGFsc28gaW5jbHVkZQ0KPiA+ ID4gc2ltaWxhcg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBpZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNs YXRpb24gZm9yIE1TLVBXcywgdG8gYW5zd2VyDQo+IGFuDQo+ID4gPiA+ID4gZWFybGllcg0KPiA+ ID4gPiA+ID4+Pj4gICA+ICBxdWVzdGlvbiBmcm9tIEVybWluaW8gdGhhdCBJIHNhdyBvbiB0aGUg bGlzdC4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiBZb3UgYXJlIHF1aXRlIGNvcnJl Y3QgaGVyZSEgSSB0aGluayBtdWNoIG9mIHRoaXMgZGViYXRlDQo+ID4gPiBzdXJyb3VuZHMNCj4g PiA+ID4gPiBhDQo+ID4gPiA+ID4gPj4gcHJvYmxlbQ0KPiA+ID4gPiA+ID4+Pj4gdGhhdCBpcyB5 ZXQgdG8gYmUgc29sdmVkLiBTbyB0aGVyZSBhcmUgYXJndW1lbnRzIGZvcg0KPiBwaWVjZXMNCj4g PiBvZg0KPiA+ID4gYQ0KPiA+ID4gPiA+IHNvbHV0aW9uDQo+ID4gPiA+ID4gPj4+PiB3aXRob3V0 IGFuZCBvdmVyYWxsIGFyY2hpdGVjdHVyZS4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+ PiBCYXNlZCBvbiBhbGwgdGhhdCBJIGFtIHNlZWluZyBteSBpbmNsaW5hdGlvbiBpcyB0byBOT1Qg c2F5DQo+ID4gPiB0aGF0IHdlDQo+ID4gPiA+ID4gPj4gZGlzYWxsb3cNCj4gPiA+ID4gPiA+Pj4+ IG1peGVkIGlkZW50aWZpZXJzLCBidXQgdG8gc2F5IHRoYXQgdGhleSBhcmUgZm9yIGZ1dHVyZQ0K PiA+IHN0dWR5Lg0KPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+IC4uLkdlb3JnZQ0KPiA+ ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4+ Pj4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiBPbiA1LzMvMTEgODozOCBBTSwgIkFu ZHJldyBHLiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+DQo+ID4gPiB3cm90ZToNCj4gPiA+ID4g PiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiAgID4gIE5laWwsDQo+ID4gPiA+ID4gPj4+PiAgID4NCj4g PiA+ID4gPiA+Pj4+ICAgPiAgVG8geW91ciBjYXNlIDEsIHdlJ3JlIGluIGNvbXBsZXRlIGFncmVl bWVudC4gV2UgKFZaKQ0KPiA+ID4gZG9uJ3QNCj4gPiA+ID4gPiBzZWUgYXQNCj4gPiA+ID4gPiA+ Pj4+ICAgPiAgbGVhc3QgYSBzaG9ydC10ZXJtIG5lZWQgZm9yIHBlZXItbGF5ZXIgaW50ZXJ3b3Jr aW5nLA0KPiA+ID4gZ2l2ZW4NCj4gPiA+ID4gPiB3aGVyZSB3ZQ0KPiA+ID4gPiA+ID4+Pj4gICA+ ICBpbnRlbmQgdG8gZGVwbG95IE1QTFMtVFAgaW4gb3VyIGluZnJhc3RydWN0dXJlIChhcyBhbg0K PiA+ID4gPiA+IGludGVybmFsIHNlcnZlcg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBsYXllciBpbiB0 aGUgdHJhbnNwb3J0IGNvcmUpLiBJZiBwZWVyIGxheWVyDQo+ID4gaW50ZXJ3b3JraW5nDQo+ID4g PiBldmVyDQo+ID4gPiA+ID4gYmVjb21lcw0KPiA+ID4gPiA+ID4+Pj4gICA+ICBhIG5lY2Vzc2l0 eSwgdGhlbiBvYnZpb3VzbHkgd2UnbGwgbmVlZCBhIHdlbGwtZGVmaW5lZA0KPiA+IEUtDQo+ID4g PiBOTkkNCj4gPiA+ID4gPiB3aGljaA0KPiA+ID4gPiA+ID4+Pj4gICA+ICB3b3VsZCBpbmNsdWRl IExTUCBpZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24gYXQNCj4gdGhlDQo+ID4gPiA+ID4g Ym91bmRhcnksIGZvcg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBMU1AgcHJvdmlzaW9uaW5nICh3aGV0 aGVyIHN0YXRpYyBvciBkeW5hbWljKSBhbmQgZW5kLQ0KPiA+IHRvLQ0KPiA+ID4gZW5kDQo+ID4g PiA+ID4gT0FNLiBTdWNoDQo+ID4gPiA+ID4gPj4+PiAgID4gIGFuIEUtTk5JIGRlZmluaXRpb24g ZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQDQo+ID4gPiAoc29tZXRoaW5nDQo+ID4gPiA+ ID4gZWxzZSB0bw0KPiA+ID4gPiA+ID4+Pj4gICA+ICBwdXQgb24gdGhlIHRvLWRvIGxpc3QpLiBU aGlzIEUtTk5JIHdvdWxkIGFsc28gaW5jbHVkZQ0KPiA+ID4gc2ltaWxhcg0KPiA+ID4gPiA+ID4+ Pj4gICA+ICBpZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24gZm9yIE1TLVBXcywgdG8gYW5z d2VyDQo+IGFuDQo+ID4gPiA+ID4gZWFybGllcg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBxdWVzdGlv biBmcm9tIEVybWluaW8gdGhhdCBJIHNhdyBvbiB0aGUgbGlzdC4NCj4gPiA+ID4gPiA+Pj4+ICAg Pg0KPiA+ID4gPiA+ID4+Pj4gICA+ICBJIGFsc28gYWdyZWUgdGhhdCBib3RoIGludHJhLWxheWVy IGFuZCBpbnRlci1sYXllcg0KPiBtaXMtDQo+ID4gPiA+ID4gY29ubmVjdGl2aXR5DQo+ID4gPiA+ ID4gPj4+PiAgID4gIGRldGVjdGlvbiBhbmQgYW1lbGlvcmF0aW9uIGFyZSByZXF1aXJlZCwgYnV0 IEknbSBub3QNCj4gPiA+ID4gPiBjb252aW5jZWQgdGhhdA0KPiA+ID4gPiA+ID4+Pj4gICA+ICB0 aGUgYWxyZWFkeSBkZWZpbmVkIG1lY2hhbmlzbXMgY2FuJ3QgZG8gdGhhdC4gRG8geW91DQo+ID4g aGF2ZQ0KPiA+ID4gPiA+IHNvbWUNCj4gPiA+ID4gPiA+Pj4+ICAgPiAgc3BlY2lmaWMgYW5hbHlz aXMgb24gdGhlIGludGVyLWxheWVyIGNhc2U/DQo+ID4gPiA+ID4gPj4+PiAgID4NCj4gPiA+ID4g PiA+Pj4+ICAgPiAgQ2hlZXJzLA0KPiA+ID4gPiA+ID4+Pj4gICA+ICBBbmR5DQo+ID4gPiA+ID4g Pj4+PiAgID4NCj4gPiA+ID4gPiA+Pj4+ICAgPiAgT24gVHVlLCBNYXkgMywgMjAxMSBhdCAzOjM2 DQo+IEFNLDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ID4gPiA+IHdyb3RlOg0KPiA+ID4g PiA+ID4+Pj4gICA+PiAgSGkgQW5keSwNCj4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+ Pj4+ICAgPj4gIDIgcG9pbnRzOg0KPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4+Pj4g ICA+PiAgMSBJIGFncmVlIHdpdGggeW91ciB2aWV3IG9mIG9ubHkgaGF2aW5nIGEgc2luZ2xlDQo+ ID4gPiBhZGRyZXNzaW5nDQo+ID4gPiA+ID4gc2NoZW1lIGluDQo+ID4gPiA+ID4gPj4gYQ0KPiA+ ID4gPiA+ID4+Pj4gICA+PiAgc2luZ2xlIGxheWVyIG5ldHdvcmsgc29sZWx5IGJlbG9uZ2luZyB0 byBvbmUgcGFydHkuDQo+ID4gPiBUaG91Z2gNCj4gPiA+ID4gPiB5b3UgbWF5DQo+ID4gPiA+ID4g Pj4+PiBuZWVkIHRvDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBiZSByYXRoZXIgY2FyZWZ1bCBpZiB5 b3UgYWxzbyBhZHZvY2F0ZSB0aGF0IG9uZSBjYW4NCj4gPiBhbHNvDQo+ID4gPiA+ID4gaGF2ZSBw ZWVyDQo+ID4gPiA+ID4gPj4gbGF5ZXINCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIGludGVyd29ya2lu ZyBiZXR3ZWVuIGRpZmZlcmVudCBwYXJ0aWVzLCBpZSBFLU5OSXMgKEkNCj4gPiA+IGJlbGlldmUN Cj4gPiA+ID4gPiB0aGlzIGlzDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBzb21ldGhpbmcgeW91IG1h eSBzdXBwb3J0LCBlZyBvbGQgTVBMU0YgY2FzZT8pLiBJbg0KPiA+IHN1Y2gNCj4gPiA+IGENCj4g PiA+ID4gPiBwZWVyDQo+ID4gPiA+ID4gPj4+PiBpbnRlcndvcmtpbmcNCj4gPiA+ID4gPiA+Pj4+ ICAgPj4gIGNhc2UgaXQgd291bGQgc2VlbSBvbmUgbXVzdCBhbGxvdyBkaWZmZXJlbnQNCj4gYWRk cmVzc2luZw0KPiA+ID4gPiA+IHNjaGVtZXMgKGFuZA0KPiA+ID4gPiA+ID4+Pj4gaW5kZWVkDQo+ ID4gPiA+ID4gPj4+PiAgID4+ICBhbnkgb3RoZXIgdmFyaWF0aW9ucyBpbiBEUC9DUCBmdW5jdGlv bmFsIGNvbXBvbmVudHMpDQo+ID4gaWYNCj4gPiA+IHRoZXkNCj4gPiA+ID4gPiBleGlzdA0KPiA+ ID4gPiA+ID4+Pj4gaW4gdGhlDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBzdGFuZGFyZHMuDQo+ID4g PiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPj4+PiAgID4+ICBPZiBjb3Vyc2UsIGhhdmluZyBh biBFLU5OSSBhbmQgcGVlciBpbnRlcndvcmtpbmcNCj4gPiBiZXR3ZWVuDQo+ID4gPiA+ID4gZGlm ZmVyZW50DQo+ID4gPiA+ID4gPj4+PiBwYXJ0aWVzIGluDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBh bnkgbm9uLVRPUyBsYXllciBuZXR3b3JrIChub3QganVzdCBNUExTKSBpcyBub3QNCj4gPiA+IHRl Y2huaWNhbGx5DQo+ID4gPiA+ID4gPj4+PiBuZWNlc3NhcnkgKHRoaXMNCj4gPiA+ID4gPiA+Pj4+ ICAgPj4gIGlzIHRyaXZpYWwgdG8gcHJvdmUpLCBhbmQgdGhpcyBwcm92aWRlcyBhIHN0cm9uZw0K PiA+ID4gYXJndW1lbnQNCj4gPiA+ID4gPiBmb3Igb25seQ0KPiA+ID4gPiA+ID4+Pj4gaGF2aW5n IGENCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIHNpbmdsZSBhZGRyZXNzaW5nIHNjaGVtZSBpbiBhIG5v bi1UT1MgbGF5ZXIgbmV0d29yay4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+Pj4+ ICAgPj4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIDIgWW91IHNob3VsZCBhbHNvIGJlIGF3YXJlIHRo YXQgaW4gY2xpZW50L3NlcnZlcg0KPiA+ID4gPiA+IGludGVyd29ya2luZyBvZiB0aGUNCj4gPiA+ ID4gPiA+Pj4+ICAgPj4gIGNvLXBzIG1vZGUgdXNpbmcgdmFyaWFibGUgc2l6ZSB0cmFmZmljIHVu aXRzLCBhbmQNCj4gPiA+IHRoZXJlZm9yZQ0KPiA+ID4gPiA+ID4+Pj4gc29tZXRoaW5nIHJhdGhl cg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgaW1wb3J0YW50IGZvciBNUExTLVRQIGluIHRoZSByb2xl IG9mIGEgdHJhbnNwb3J0DQo+ID4gbmV0d29yaw0KPiA+ID4gPiA+IChJJ2xsDQo+ID4gPiA+ID4g Pj4+PiBpZ25vcmUgaXNzdWVzDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBvZiB0cmFuc3BhcmVuY3kg aGVyZSksIHRoZXJlIGNvdWxkIGJlIGludGVyLWxheWVyDQo+ID4gPiA+ID4gbWlzY29ubmVjdGl2 aXR5DQo+ID4gPiA+ID4gPj4+PiAoQXNpZGU9Pg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgVGhpcyBj YXNlIGNhbm5vdCBvY2N1ciBpbiB0aGUgY28tY3MgbW9kZSkuIFRvIGRhdGUsDQo+ID4gPiBob3dl dmVyLA0KPiA+ID4gPiA+IHdlIGhhdmUNCj4gPiA+ID4gPiA+Pj4+IG9ubHkNCj4gPiA+ID4gPiA+ Pj4+ICAgPj4gIHJlYWxseSBjb25zaWRlcmVkIGludHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSwg aWUNCj4gPiA+IGJldHdlZW4NCj4gPiA+ID4gPiBkaWZmZXJlbnQNCj4gPiA+ID4gPiA+PiBMU1Bz DQo+ID4gPiA+ID4gPj4+PiAgID4+ICBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgcGFydHkgKG5vdGUg dGhpcyBhbHNvIGluY2x1ZGVzDQo+ID4gYWxsDQo+ID4gPiA+ID4gY2FzZXMgb2YNCj4gPiA+ID4g PiA+Pj4+IG5lc3RlZCBMU1ANCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIHN1YmxheWVyIG1pc2Nvbm5l Y3Rpdml0eSkuDQo+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPj4+PiAgID4+ICBJbiB0 aGUgY2FzZSBvZiBpbnRlci1sYXllciBtaXNjb25uZWN0aXZpdHkgb25lIG1heQ0KPiA+ID4gcmVj ZWl2ZQ0KPiA+ID4gPiA+IHRyYWZmaWMNCj4gPiA+ID4gPiA+Pj4+IHVuaXRzIGFuZA0KPiA+ID4g PiA+ID4+Pj4gICA+PiAgT0FNIG1lc3NhZ2VzIGZyb20gc29tZSBvdGhlciBwYXJ0eSdzIGxheWVy IG5ldHdvcmsuDQo+ID4gVGhlDQo+ID4gPiBPQU0NCj4gPiA+ID4gPiA+PiBtZXNzYWdlcw0KPiA+ ID4gPiA+ID4+IG1heQ0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgY29tZSBmcm9tIChpKSBuZXR3b3Jr cyB1c2luZyBkaWZmZXJlbnQNCj4gT0FNL2FkZHJlc3NpbmcNCj4gPiA+ID4gPiBzb2x1dGlvbnMg b3INCj4gPiA+ID4gPiA+PiAoaWkpDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBuZXR3b3JrcyB1c2lu ZyB0aGUgc2FtZSBPQU0vYWRkcmVzc2luZyBzb2x1dGlvbnMuIEluDQo+ID4gPiBib3RoDQo+ID4g PiA+ID4gY2FzZXMNCj4gPiA+ID4gPiA+Pj4+IHRoZXJlIGFyZQ0KPiA+ID4gPiA+ID4+Pj4gICA+ PiAgZGlmZmVyZW50IGlzc3VlcyB3cnQgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5IG9uZQ0K PiA+IGhhcw0KPiA+ID4gdG8NCj4gPiA+ID4gPiBkZWFsDQo+ID4gPiA+ID4gPj4+PiB3aXRoLiBJ J20NCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIG5vdCBhd2FyZSB0aGF0IHRoZXNlIGNhc2VzIGhhdmUg YmVlbiBjb25zaWRlcmVkIHlldC4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+Pj4+ ICAgPj4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIEknZCBsaWtlIHRvIGhlYXIgeW91ciBjb21tZW50 cyBvbiBib3RoIHRoZXNlIHBvaW50cywNCj4gPiBidXQNCj4gPiA+IGluDQo+ID4gPiA+ID4gPj4+ PiBwYXJ0aWN1bGFyIHRoZQ0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgZmlyc3Qgb25lLi4uLi5lc3Bl Y2lhbGx5IGlmIHlvdSBhbHNvIHN1cHBvcnQgdGhlDQo+ID4gbm90aW9uDQo+ID4gPiBvZg0KPiA+ ID4gPiA+IEUtTk5JcyBpbg0KPiA+ID4gPiA+ID4+Pj4gTVBMUy1UUCwNCj4gPiA+ID4gPiA+Pj4+ ICAgPj4gIGFzIHRoZXJlIHNlZW1zIHRvIGEgcG9zc2libGUgbG9naWNhbCBjb25mbGljdCBoZXJl Lg0KPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgVGhhbmtzLg0KPiA+ ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgcmVnYXJkcywgTmVpbCBIYXJy aXNvbg0KPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgQlQgRGVzaWdu DQo+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPj4+PiAgID4+ICBUaGlzIGVtYWlsIGNv bnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUNCj4gPiA+IHByaXZpbGVnZWQNCj4g PiA+ID4gPiBvcg0KPiA+ID4gPiA+ID4+Pj4gY29uZmlkZW50aWFsLg0KPiA+ID4gPiA+ID4+Pj4g ICA+PiAgSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkNCj4g bmFtZWQNCj4gPiA+IGFib3ZlLg0KPiA+ID4gPiA+IElmDQo+ID4gPiA+ID4gPj4+PiB5b3UncmUg bm90DQo+ID4gPiA+ID4gPj4+PiAgID4+ICB0aGUgaW50ZW5kZWQNCj4gPiA+ID4gPiA+Pj4+ICAg Pj4gIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsDQo+IGRpc3RyaWJ1 dGluZw0KPiA+ID4gb3INCj4gPiA+ID4gPiB1c2luZyB0aGlzDQo+ID4gPiA+ID4gPj4+PiAgID4+ ICBpbmZvcm1hdGlvbg0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgaXMgcHJvaGliaXRlZC4gSWYgeW91 J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4NCj4gZXJyb3IsDQo+ID4gPiA+ID4gcGxlYXNlIGxl dCBtZQ0KPiA+ID4gPiA+ID4+Pj4ga25vdw0KPiA+ID4gPiA+ID4+Pj4gICA+PiAgaW1tZWRpYXRl bHkNCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFu ayB5b3UuDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0s IGFuZCBtYXkgcmVjb3JkIHlvdXINCj4gPiBlbWFpbHMuDQo+ID4gPiA+ID4gPj4+PiAgID4+ICBC cml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCj4gPiA+ID4gPiA+Pj4+ICAgPj4gIFJlZ2lz dGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4gPiA+ID4g PiA+Pj4+ICAgPj4gIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KPiA+ID4gPiA+ ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+ID4gPj4+PiAgID4+PiAgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy0NCj4gPiA+IGJvdW5jZXNAaWV0Zi5vcmddDQo+ID4gPiA+ID4gT24gQmVoYWxm DQo+ID4gPiA+ID4gPj4gT2YNCj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBBbmRyZXcgRy4gTWFsaXMN Cj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBTZW50OiAwMiBNYXkgMjAxMSAyMDo0OA0KPiA+ID4gPiA+ ID4+Pj4gICA+Pj4gIFRvOiBHZW9yZ2UgU3dhbGxvdw0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIENj OiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPj4+PiAgID4+PiAgU3ViamVjdDogUmU6IFttcGxz XSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGluDQo+ID4gTVBMUy0NCj4gPiA+IFRQDQo+ID4g PiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4+Pj4g ICA+Pj4gIEdlb3JnZSBldCBhbCwNCj4gPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4gPj4+ PiAgID4+PiAgVmVyaXpvbiBkb2VzIG5vdCBoYXZlIGFueSByZXF1aXJlbWVudCBmb3IgbWl4ZWQg dXNlDQo+ID4gb2YNCj4gPiA+ID4gPiBHbG9iYWwgSURzIGFuZA0KPiA+ID4gPiA+ID4+Pj4gICA+ Pj4gIElDQ3MuIFdlIGFyZSBmaW5lIHdpdGggc3BlY2lmaWNhdGlvbnMgdGhhdCByZXF1aXJlDQo+ ID4gYm90aA0KPiA+ID4gPiA+IGVuZHMgb2YgYW4NCj4gPiA+ID4gPiA+PiBMU1ANCj4gPiA+ID4g PiA+Pj4+ICAgPj4+ICB0byB1c2Ugb25lIG9yIHRoZSBvdGhlci4NCj4gPiA+ID4gPiA+Pj4+ICAg Pj4+DQo+ID4gPiA+ID4gPj4+PiAgID4+PiAgVGhhbmtzLA0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4g IEFuZHkNCj4gPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4gPj4+PiAgID4+PiAgT24gTW9u LCBBcHIgMjUsIDIwMTEgYXQgNToxNiBQTSwgR2VvcmdlDQo+ID4gPiA+ID4gU3dhbGxvdzxzd2Fs bG93QGNpc2NvLmNvbT4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICB3cm90ZToNCj4gPiA+ID4gPiA+ Pj4+ICAgPj4+PiAgQWxsIC0NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPiA+ID4+Pj4g ICA+Pj4+ICBNYW55IG9mIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBJVFUgb24NCj4g PiA+ID4gPiA+Pj4+ICAgPj4+PiAgZHJhZnQtaWV0Zi1tcGxzLXRwLWlkZW50aWZpZXJzLTA0IGhh dmUgdG8gZG8gd2l0aA0KPiA+IHRoZQ0KPiA+ID4gPiA+IEdsb2JhbCBhbmQgSUNDDQo+ID4gPiA+ ID4gPj4+PiAgID4+Pj4gIGlkZW50aWZpZXJzLg0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4g PiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBh bmQgTUVHDQo+IGluY2x1ZGUNCj4gPiA+ID4gPiBmaWVsZHMgdG8NCj4gPiA+ID4gPiA+Pj4+ICAg Pj4+ICBpZGVudGlmeSBlYWNoDQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIGVuZCBvZiBhbiBMU1Au IEN1cnJlbnRseSB0aGUgZHJhZnQgYWxsb3dzIGENCj4gVHVubmVsLA0KPiA+ID4gTFNQLA0KPiA+ ID4gPiA+IFBXLCBvciBNRUcNCj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICB0byB1c2UNCj4gPiA+ID4g PiA+Pj4+ICAgPj4+PiAgZWl0aGVyIHRoZSBHbG9iYWwtSUQgZm9yIGJvdGggZW5kcyBvciBvciB0 aGUgSUNDDQo+IGZvcg0KPiA+ID4gYm90aA0KPiA+ID4gPiA+IGVuZHMuDQo+ID4gPiA+ID4gPj4+ PiAgID4+PiAgTWl4ZWQgdXNlDQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIGlzIG5vdCBwZXJtaXR0 ZWQuDQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgVGhlIElU VSBsaWFpc29uIHJlcXVlc3RzIHRoYXQgd2UgYWxsb3cgbWl4ZWQgdXNlLg0KPiA+ID4gPiA+ID4+ Pj4gICA+Pj4+DQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBhdXRob3JzIG9mIHRoZSBkcmFm dCBhcmUgdmVyeSByZWx1Y3RhbnQgdG8gZG8NCj4gPiA+IHRoaXMuDQo+ID4gPiA+ID4gPj4+PiAg ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgT2J0YWluaW5nIGFuIEFTIE51bWJlciAoZnJv bSB3aGljaCB0aGUgR2xvYmFsLUlEDQo+IGlzDQo+ID4gPiA+ID4gZGVyaXZlZCkgaXMgYQ0KPiA+ ID4gPiA+ID4+Pj4gICA+Pj4gIGZhaXJseQ0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFs IHByb2NlZHVyZS4gTWFueSBvcmdhbml6YXRpb25zIGlmIG5vdCBtb3N0DQo+ID4gPiBhbHJlYWR5 DQo+ID4gPiA+ID4gaGF2ZSBBUw0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIE51bWJlcnMuDQo+ID4g PiA+ID4gPj4+PiAgID4+Pj4gIFN1Y2ggYW4gYWRkaXRpb24gd2lsbCBhZGQgbnVtZXJvdXMgb2Jq ZWN0IGZvcm1hdHMsDQo+ID4gYW5kDQo+ID4gPiA+ID4gdGVzdCBjYXNlcy4NCj4gPiA+ID4gPiA+ Pj4+ICAgPj4+PiAgVGhlIGV4dGVudCBpbnRlci1wcm92aWRlciBNUExTLVRQIGlzIGFzIHlldA0K PiB1bmtub3duLg0KPiA+ID4gSWYNCj4gPiA+ID4gPiBtaXhlZCBtb2Rlcw0KPiA+ID4gPiA+ID4+ Pj4gICA+Pj4gIG9mIElDQw0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBhbmQgR2xvYmFsLUlEIGlk ZW50aWZpY2F0aW9uIGlzIHJlcXVpcmVkLCB0aGV5IGNhbg0KPiA+IGJlDQo+ID4gPiA+ID4gYWRk ZWQgbGF0ZXIuDQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIEZvciBzaWduYWxlZCBjb25uZWN0aW9u cywgdGhlcmUgaXMgbm8gcGxhbiB0bw0KPiBhbGxvdw0KPiA+ID4gPiA+IHJvdXRpbmcgYmFzZWQg b24NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBlaXRoZXINCj4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAg dGhlIEdsb2JhbC1JRCBvciBJQ0MuIFRoYXQgd291bGQgYmUgYSByYWRpY2FsDQo+IGNoYW5nZQ0K PiA+ID4gdG8NCj4gPiA+ID4gPiBob3cgSVANCj4gPiA+ID4gPiA+Pj4+ICAgPj4+ICB3b3Jrcy4N Cj4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgSG93ZXZlciBmb3IgSVAgcm91dGluZyB0byB3b3JrIChp biBvcmRlciB0bw0KPiBmb3J3YXJkDQo+ID4gPiB0aGUNCj4gPiA+ID4gPiBzaWduYWxpbmcNCj4g PiA+ID4gPiA+Pj4+ICAgPj4+PiAgbWVzc2FnZXMpLCB0aGUgcHJvdmlkZXJzIGludm9sdmVkIHdp bGwgbmVlZCB0byBydW4NCj4gPiBCR1ANCj4gPiA+IGFuZA0KPiA+ID4gPiA+IGhhdmUgQVMNCj4g PiA+ID4gPiA+Pj4+ICAgPj4+ICBudW1iZXJzLg0KPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4g PiA+ID4gPj4+PiAgID4+Pj4gIFdlIGFyZSBsb29raW5nIGZvciBpbnB1dC9jb25zZW5zdXMgZnJv bSB0aGUgV0cuDQo+ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAg R2VvcmdlLCBFcmljLCYgIE1hdHRoZXcNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g LS0NCj4gPiA+ID4gPg0KPiA+ID4gPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+ID4gPiAqKioNCj4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0KPiA+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG1wbHMg bWFpbGluZyBsaXN0DQo+ID4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG1wbHMgbWFpbGluZyBs aXN0DQo+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From maarten.vissers@huawei.com Wed May 25 05: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 5FBDFE0657 for ; Wed, 25 May 2011 05:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 EK9Ye5y2lLjj for ; Wed, 25 May 2011 05:11:27 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfa.amsl.com (Postfix) with ESMTP id 37C56E0618 for ; Wed, 25 May 2011 05:11:27 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLR005R136Z8X@lhrga04-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 13:11:23 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLR002TB36Z25@lhrga04-in.huawei.com> for mpls@ietf.org; Wed, 25 May 2011 13:11:23 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 13:11:15 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 25 May 2011 13:11:22 +0100 Date: Wed, 25 May 2011 12:11:22 +0000 From: Maarten vissers X-Originating-IP: [10.202.112.103] To: "'adrian@olddog.co.uk'" <'adrian@olddog.co.uk'>, "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0QgAAqE9A= X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [mpls] R: Re: 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, 25 May 2011 12:11:28 -0000 Adrian, Please be aware that under fault conditions an ICC formatted MEG ID can be received by an endpoint using a Global_ID formatted MEG ID, and vice versa. Either endpoint must be able to detect a misconnection condition and be able to report the received MEG ID (in the non-expected format) to NMS to guide in the fault localisation. Note that we overlooked a similar requirement initially in SDH (16-byte TTI and 64-byte TTI), and this required us to upgrade our VC-n endpoints afterwards. Let's not make a similar mistake in MPLS-TP. This implies that the MEG ID field must be structured and must contain the following subfields: - MEG ID Format type - MEG ID Length - MEG ID Value. The data plane should be agnostic to the MEG ID format and should simply compare the received MEG ID bit pattern with the expected MEG ID bit pattern. The received MEG ID bit pattern should be reported to NMS on request of NMS. NMS has to interpret the MEG ID bit pattern and present it in the appropriate format on its GUI. Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 25 May 2011 11:13 > To: mpls@ietf.org > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP > Identifiers? > > Hi Neil, > > I'm not assuming peering. I am actually pointing out to Huub that > (despite what he keeps saying) he is also not assuming peering. > > The consequence of not peering is that a single identifier mode is used > for both ends of an OAM "session". And that means that one end has to > understand *and* use the "foreign" format at the remote end of the > session. > > I am tired of this discussion. There seems to be no forward progress > only restatement of a "want". I always wanted a pony when I was a > little girl, but I never got one. > > Adrian > From erosen@cisco.com Wed May 25 05:49: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 3CDB913001C for ; Wed, 25 May 2011 05:49:27 -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 pkWstak3t0ds for ; Wed, 25 May 2011 05:49:25 -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 E513DE0655 for ; Wed, 25 May 2011 05:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1397; q=dns/txt; s=iport; t=1306327765; x=1307537365; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=kVTNjgxFWmAurhkZ9zo4IiGkqCgF5xqllFLCrXlvgfo=; b=HofSW3v40s4vw6Tb/bJ3TG0hsMCqRcCMz5YH795L/1QeGsxSeoWxBsKh fcXoRy7cE0w0Hc0Fo97GvILjQx6v5Iz4V1eiNJtMIuXlM1zmAjytjPcnM 1AGYx9b1J9FdPY5ZbwPuLbLkBHhwsBS8yvFhBT7bFPGtjcGVGw9WAsTDM w=; X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="234174358" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 25 May 2011 12:49:24 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4PCnNqO003352; Wed, 25 May 2011 12:49:23 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p4PCnM38020862; Wed, 25 May 2011 08:49:22 -0400 To: Loa Andersson In-reply-to: Your message of Thu, 12 May 2011 15:59:26 +0200. <4DCBE7BE.5010708@pi.nu> Date: Wed, 25 May 2011 08:49:22 -0400 Message-ID: <20861.1306327762@erosen-linux> From: Eric Rosen Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:49:27 -0000 No/Do not Support. 1. The procedures for setting up P-tunnels across a seamless MPLS environment violate most of the requirements expressed in the "seamless MPLS" draft. In particular, it is proposed to get the ABRs intimately involved in the MVPN-specific service signaling. This violates the "seamless MPLS" requirement that the "transport nodes" (such as the ABRs) not have service-specific procedures, and that they should not have to maintain service-specific states. If one wants to use BGP to set up P-tunnels in a seamless environment, the NLRI should be a P-tunnel identifier, not a customer multicast flow identifier. I will develop this point in another thread and suggest an alternate approach. 2. I think the handling of Internet multicast is the wrong approach. It would be a lot simpler to treat "global table" multicast just like MVPN multicast, just using a special RD and RT to distinguish the global table from the VRFs. Instead, this draft tries to do global table multicast without using the C-multicast routes, but just with the A-D routes. There is no reason for this different way of handling multicast, it just creates unnecessary complexity. Since I think this draft takes the wrong approach on two very important topics, I cannot support its becoming a WG document in its present form. From erosen@cisco.com Wed May 25 05:53:40 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 2C1D1E068C for ; Wed, 25 May 2011 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED49MgzPs0AP for ; Wed, 25 May 2011 05:53:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04556E067C for ; Wed, 25 May 2011 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=12750; q=dns/txt; s=iport; t=1306328018; x=1307537618; h=to:subject:reply-to:date:message-id:from; bh=UrRj8RBYlcUXE5GZTgfrGXQIRLDIkMkv+3l2N45vTB8=; b=k5ueVaHM1gRnKAeVq0CgB5Xu+FGAtyycCeSqeV73VnwAhIXBU82vKIgW 3MqJGAzOjCAtwvpMzBs1TjEp6INRXei5TfzoS4rKxiRzdf5As26LoNiq+ EaQqTrHssUbLyF7ehToPh/6oQ9gAeOs0mOKkONxCojbsPoN4JkOkufM3w U=; X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="323226590" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 25 May 2011 12:53:36 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4PCraoL022979; Wed, 25 May 2011 12:53:36 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p4PCrZZY020901; Wed, 25 May 2011 08:53:35 -0400 To: mpls@ietf.org X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Wed, 25 May 2011 08:53:35 -0400 Message-ID: <20900.1306328015@erosen-linux> From: Eric Rosen Subject: [mpls] MVPN in the "seamless MPLS" environment X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:53:40 -0000 Draft-raggarwa-mpls-seamless-mcast covers a lot of topics, and I have a lot of comments on it, but I want to focus in this message on whether the proposed control plane model is really appropriate for a "seamless MPLS" environment. It seems to me that the proposed control plane model violates the requirements for "seamlessness", because it intermixes the service layer and the transport layers, and requires service-specific state and processing at the border routers of the transport layer. One of the basic concepts of the proposal is that of the "P2MP FEC" or service LSP" (these terms seem to be used more or less equivalently). For MVPN, the proposal identifies a P2MP FEC with a PMSI (i.e, with the entity that is identified by the NLRI of an I-PMSI or S-PMSI A-D route). To make the proposal fit into the seamless MPLS environment, the P2MP FEC really has to identify its P2MP FEC with a P-tunnel. I'll try to show that this change would result in a simpler and more scalable scheme. The "seamless MPLS" model is described in draft-leymann-mpls-seamless-mpls. This draft does not actually give a definition of "seamless MPLS", but it does specify a number of characteristics that a seamless MPLS system will have. One of the major characteristics of a seamless MPLS environment seems to be that there is a fairly strict demarcation between "service" and "transport". The environment is hierarchical, with service nodes at the lowest level of the hierarchy and transport nodes at the higher levels. The transport nodes are not to have any service-specific configuration, any service-specific procedures, or, presumably, to run any service-specific protocols. The service nodes run service-specific protocols with each other, and run transport-specific protocols with the transport nodes at the next level of hierarchy. For example, to support a pseudowire service in a seamless MPLS environment, the service node at the edge would run the pseudowire setup protocol with each other. The transport nodes would run "ordinary" MPLS with each other and with the service nodes. The transport nodes would not maintain per-pw state. An example of a non-seamless model would be the multi-segment pseudowire model, where some of the nodes at higher levels of the hierarchy actually talk pseudowire setup protocol to the service nodes, and do pseudowire-specific procedures. Although the "seamless-mcast" draft claims to specify the way to do MPLS multicast in the seamless MPLS model, the procedures it specifies are much more like the multi-segment pseudowire model than like the seamless model. For the MVPN service, the draft has the service nodes and the border transport nodes exchanging MVPN-specific control messages and performing MVPN-specific functions. The border routers at the upper level of the hierarchy have to maintain MVPN-specific state, and the amount of state maintained is proportional to the number of MVPN states maintained by the service nodes, not proportional to the number of transport tunnels that are needed. For example, a PE might send 100 S-PMSI A-D routes, each one binding a customer flow (C-S,C-G) to a P-tunnel. But these 100 S-PMSI A-D routes might all have the same PMSI Tunnel Attribute (PTA); that is, the PE might bind each of these 100 C-flows to the same P-tunnel. In seamless MPLS, the transport border nodes should have one state for the P-tunnel, not 100 states for the C-flows. The transport border routers do not care what the P-tunnel is being used for. And since the border routers do not perform MVPN-specific functions, they will not be deaggregating and reaggregating the C-flows. The border routers may decide to aggregate the P-tunnels in some way, but they should not deal with anything more finely grained than a P-tunnel; to do so would be to perform service-specific functions. I think it is possible to provide MVPN support in the seamless MPLS environment in a more seamless manner, keeping MVPN-specific functionality off the transport nodes, while still gaining the advantages of LSP hierarchy that the seamless MPLS model tries to provide. The MVPN specifications really provide three and a half "levels" of signaling: 1. The C-multicast signaling, which conveys the customer multicast states from one PE to another. This level of signaling should involve only the PE routers (the service nodes). 2. The A-D signaling, which assigns sets of customer multicast flows (C-flows) to P-tunnels. The A-D signaling also distributes the information that the PE routers need in order to determine which P-tunnels they need to join, as well as the information needed by the third level of signaling. This level of signaling is done via BGP. 3. The P-tunnel setup signaling. For unsegmented P-tunnels, and for individual segments of segmented P-tunnels, this level of signaling is done via mLDP, RSVP-TE, or other multicast tunnel setup protocol. For segmented P-tunnels, there is a "level 3.5" of signaling, that carries information among the segment endpoints. (When ingress replication is used to instantiate the P-tunnels, level 3 signaling is not needed, though level 3.5 signaling might still be needed.) In a seamless MPLS environment, I think the A-D signaling should, like the C-multicast signaling, should only involve the service nodes. It should be PE-PE signaling, most likely through service-specific route reflectors. The P-tunnel setup signaling (levels 3 and 3.5) should involve the transport nodes, of course, but in the seamless model, this level of signaling should be service-independent. The basic concept of this level of signaling should be the P-tunnel. The proposal in the seamless-mcast draft uses the MVPN A-D signaling for the level 3.5 signaling. As a result, the "P2MP FEC" used by the level 3.5 signaling is the NLRI of the A-D routes, rather than the P-tunnel. If we don't try to piggyback the level 3.5 signaling on the level 2 signaling messages, and we do the level 3.5 signaling on a per-P-tunnel basis, we can provide the following control flow model: PE2-- ... ---ABR2-- ... ---ABR1-- ... ---PE1 Let's suppose, e.g, that we want to create a three-segment P-tunnel, with each segment created by RSVP-TE. IMHO, the desired flow of control is: 1. PE1 sends MVPN-specific signaling to PE2 (using MVPN standard BGP). E.g., PE1 might send S-PMSI A-D routes binding (C-S1,C-G1), (C-S2,C-G2) and (C-S3,C-G3) to a particular P-tunnel. For this example, let's say that the PMSI Tunnel Attribute (PTA) identifies the P-tunnel using an mLDP P2MP FEC element: . 2. PE2 receives this S-PMSI A-D route. 3. PE2 needs to receive, say, traffic, and so needs to join the P-tunnel. 4. PE2 sends a "P-tunnel Join Request" message to ABR2, specifying the P-tunnel. 5. ABR2 adds PE2 to an RSVP-TE P2MP LSP tunnel of which ABR2 is the headend. 6. ABR2 send a "P-tunnel Join Response" to PE2, telling it that the tunnel is being carried within an identified RSVP-TE P2MP LSP. If the RSVP-TE P2MP LSP is aggregating other P-tunnels, PE2 would include an upstream-assigned label. 7. ABR2 sends ABR1 a "P-tunnel Join Request" message. .... etc. The "P-tunnel Join Request/Response" messages are the level 3.5 signaling. Note that although the PE-PE P-tunnel is identified using an mLDP P2MP FEC, there is no presumption that mLDP will be used to build the segments. The FEC is used as an identifier for the end-end (PE-PE) P-tunnel, not necessarily as an identifier for any of its segments. Let me suggest a couple of ways in which this control flow model can be provided. Proposal 1: this proposal follows the seamless-mcast draft in using BGP for setting up the segmented P-tunnels. It does so as follows: - New AFI/SAFI for BGP-based level 3.5 P-tunnel setup signaling. - NLRI of this AFI/SAFI is a "P2MP FEC", as defined, say, in the mLDP spec. (So the NLRI identifies a P-tunnel rather than a "service LSP".) - P-tunnel setup is initiated from the leaf nodes, using a new route type, "P-tunnel Join Request" routes. These are sort of like the "Leaf Info A-D routes", except that: * the NLRI encodes the P2MP FEC identifying the PE-PE P-tunnel * the ability of a PE to send one of these routes to an ABR does not depend on the PE's having first received any other P-tunnel route from the ABR. * Route distribution constrained to specific upstream LSR by the usual extended community methods from the MVPN specs. * Semantics are that the originator wants to join the specified P-tunnel. - When an upstream LSR receives one of these routes from downstream, it: * Responds by sending a P-tunnel Join Request upstream, same NLRI. * Responds by sending a P-tunnel Join Response downstream, same NLRI. A PTA may be included. This attribute identifies the tunnel and tunnel type of the particular segment connecting the upstream LSR to the downstream LSR. This segment may be carrying several end-to-end P-tunnels; if so the MPLS label in the PTA is used for demultiplexing. * If the segment is an RSVP-TE P2MP LSP, the upstream node initiates the signaling to add the downstream node. - When a downstream LSR receives a Join Response after having sent a corresponding Join Request, if further signaling is required to join the segment (e.g., if the segment is created by mLDP), the downstream node initiates the necessary signaling, based on the information in the PTA of the Join Response. This proposal uses BGP for the level 3.5 signaling, but keeps it separate from levels 1 and 2 of signaling. I believe this has the following advantages: - Non-PEs have state per P-tunnel, rather than state per C-flow or per-PMSI. If PE has originated 100 S-PMSI A-D routes, all with the same PTA, the transport border router will get only one route (for the P-tunnel) from that PE, rather than getting the 100 S-PMSI A-D routes. - Non-PEs have no MVPN-specific knowledge or state, and do not even have to know how to parse the "MCAST-VPN" SAFI messages. - Using a different AFI/SAFI than the service-specific C-multicast and A-D routes results in a simpler scheme. It eliminates the need to invent new attributes or communities for the A-D routes to carry, as we no longer need to have some attributes for the "level 2 signaling" and some for the "level 3.5 signaling". Another advantage of using a different AFI/SAFI is that it becomes much easier to set up the BGP sessions properly. Note that the C-multicast routes and A-D routes, as defined in the MVPN specs, share the same AFI/SAFI. If one wants to forward the C-multicast routes via a RR but send the A-D routes directly to the border routers, one has to filter on the "route type", which is encoded in the first octet of the NLRI. And if any new route types are invented, these filters would have to be modified. By using a separate AFI/SAFI for the level 3.5 signaling, it becomes much easier to set up the BGP sessions properly. - This signalling can be used to create segmented P-tunnels even if the service nodes are not using BGP A-D routes. For example, if one has existing MVPNs using PIM/GRE P-tunnels, one may want to migrate the "core" area to MPLS multicast, witout having to first migrate the existing PE routers. In this case, a transport border router receiving a PIM Join can "translate" it into a BGP P-tunnel Join Request. This sort of migration cannot be done with BGP A-D routes, because a Leaf Info A-D route cannot be originated as the result of receiving a PIM Join. (Per the MVPN/BGP spec, Leaf Info A-D routes can only be sent in response to S-PMSI A-D routes.) Proposal 2: use Targeted mLDP for the level 3.5 signaling, as specified in the following two drafts: draft-napierala-mpls-targeted-mldp draft-rosen-l3vpn-mvpn-segments However, the issue I want to focus on in this message is not whether mLDP is a better protocol to use than BGP, but whether we have the proper model for control flow in the seamless MPLS environment. Either protocol can be used to provide a seamless model without bringing service-specific processing or state into the transport nodes. Discussion? From ss2539@att.com Tue May 24 14:01:06 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 072D9E078B for ; Tue, 24 May 2011 14:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mRfS2zRvfvGz for ; Tue, 24 May 2011 14:01:05 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 63529E0786 for ; Tue, 24 May 2011 14:01:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ss2539@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1306270864!19288697!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4375 invoked from network); 24 May 2011 21:01:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 May 2011 21:01:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4OKxxT4012220; Tue, 24 May 2011 16:59:59 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4OKxr9i012129; Tue, 24 May 2011 16:59:53 -0400 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, 24 May 2011 17:00:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: AcwZfVu27LZdxifNSUe1WkizTbFa3gA1stNg References: <4DCBE7BE.5010708@pi.nu> From: "SAAD, SAMIR S (ATTSI)" To: , , , , Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 25 May 2011 13:38:47 -0000 Support. Samir Saad AT&T On 5/12/11 9:59 AM, "Loa Andersson" wrote: >Working Group, > >this is to start a two week poll on making > >draft-raggarwa-mpls-seamless-mcast-03.txt > >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 on May 27th. > >/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 ice@cisco.com Wed May 25 06:52: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 E5CB7E0697 for ; Wed, 25 May 2011 06:52:25 -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 v68+VrOpbxE3 for ; Wed, 25 May 2011 06:52:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 98C09E07FB for ; Wed, 25 May 2011 06:52:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4PDmZ0l020613; Wed, 25 May 2011 15:48:35 +0200 (CEST) Received: from ams-iwijnand-87112.cisco.com (ams-iwijnand-87112.cisco.com [10.55.191.157]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4PDmYIt013538; Wed, 25 May 2011 15:48:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <4DCBE7BE.5010708@pi.nu> Date: Wed, 25 May 2011 15:48:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <586D5814-71E9-4B93-997B-4E592F737240@cisco.com> References: <4DCBE7BE.5010708@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1081) Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 25 May 2011 13:52:26 -0000 No, do not support. The issues Eric raised are fundamental and need to be addressed before = adoption. Thx, Ice. On 12 May 2011, at 15:59, Loa Andersson wrote: > Working Group, >=20 > this is to start a two week poll on making >=20 > draft-raggarwa-mpls-seamless-mcast-03.txt >=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 on May 27th. >=20 > /Loa >=20 > --=20 >=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 malcolm.betts@zte.com.cn Wed May 25 14:28: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 392A5E0762 for ; Wed, 25 May 2011 14:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.938 X-Spam-Level: X-Spam-Status: No, score=-100.938 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_71=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 FYaAh4FjPlki for ; Wed, 25 May 2011 14:28:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 929F2E075D for ; Wed, 25 May 2011 14:27:59 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 41230806486374; Thu, 26 May 2011 05:25:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 94425.959075483; Thu, 26 May 2011 05:27:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4PLRndW044894; Thu, 26 May 2011 05:27:49 +0800 (GMT-8) (envelope-from Malcolm.BETTS@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: Malcolm.BETTS@zte.com.cn Date: Wed, 25 May 2011 17:27:28 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-26 05:27:49, Serialize complete at 2011-05-26 05:27:49 Content-Type: multipart/alternative; boundary="=_alternative 0075E5FC8525789B_=" X-MAIL: mse02.zte.com.cn p4PLRndW044894 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, 25 May 2011 21:28:04 -0000 This is a multipart message in MIME format. --=_alternative 0075E5FC8525789B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Ross, I understand that you have declared rough consensus on this point and the=20 WG has moved on. However, I was looking for some further technical rational for this=20 decision. From my perspective those supporting the need to mix ICC and=20 Global-ID have identified the scenarios, I do not see a need for any=20 protocol extensions, just the removal of the restriction and I did not see = any strong technical objections. Your perspective on the technical issues=20 would provide some useful guidance on the points that need to be addressed = if I, or some others, decide to write a new draft, as you suggest. Regards, Malcolm Ross Callon =20 23/05/2011 10:02 PM To "Malcolm.BETTS@zte.com.cn" cc "mpls@ietf.org" Subject RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Malcolm; =20 There has been extensive discussion of this issue on the MPLS WG email=20 list since George Swallow?s original email of Mon 4/25/2011 5:17 PM. As=20 has been pointed out there is no consensus to include mixed identifier=20 types in the current draft. Admittedly the consensus to leave it out is=20 rough, but this is the consensus that we have.=20 =20 You and others are welcome to author or co-author a draft which points out = scenarios in which mixing ICC and Global-IDs is useful, and the protocol=20 mechanisms needed to support this. If you choose to write such a draft,=20 then we would welcome discussion of this draft on the MPLS WG email list. =20 Thanks,=20 Ross and Loa (as MPLS WG co-chairs) =20 From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]=20 Sent: Saturday, May 21, 2011 8:05 PM To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org; Ross Callon Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 Eric,=20 I find that argument somewhat circular since we did not have consensus to = omit this.=20 Regards,=20 Malcolm=20 Eric Gray =20 20/05/2011 12:28 PM=20 To "Malcolm.BETTS@zte.com.cn" , Ross Callon=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 As a co-author of the draft in question, I completely support this=20 decision.=20 =20 As I already explained to another person asking the same question, the = bit about "no consensus to change" says it all.=20 =20 In my opinion, this is a quite sufficiently detailed response. The=20 absence=20 of a consensus to change means no change. We do not typically require a=20 strong consensus to continue on the current path.=20 =20 I am reasonably certain you apply similar rules yourself when working=20 in=20 other SDOs.=20 =20 --=20 Eric=20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Malcolm.BETTS@zte.com.cn Sent: Thursday, May 19, 2011 4:25 AM To: Ross Callon Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? Ross,=20 I disappointed and, based on my reading of the emails on this thread,=20 surprised that this decision has been taken. Could you please elaborate=20 on the reasoning behind this decision.=20 Regards,=20 Malcolm=20 Ross Callon =20 Sent by: mpls-bounces@ietf.org=20 18/05/2011 02:40 PM=20 =20 To "mpls@ietf.org" =20 cc Subject Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? =20 After discussion on the MPLS WG email list, there is no consensus to=20 change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and=20 ICC?s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly=20 rough) consensus is to leave the document as currently defined. The=20 authors are therefore instructed to continue progression of=20 draft-ietf-mpls-tp-identifiers without a change in this area.=20 =20 This decision neither supports nor precludes the possibility that at some=20 point in the future, after draft-ietf-mpls-tp-identifiers is approved and=20 published as an RFC, the WG might consider additional work to extend the=20 MPLS protocols to allow mixed identifiers.=20 =20 Thanks,=20 Ross and Loa (as MPLS WG chairs)=20 =20 [Note that since George is co-author of draft-ietf-mpls-tp-identifiers,=20 for this one document he is recused from his role as WG co-chair.]=20 =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?=20 =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 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 --=_alternative 0075E5FC8525789B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Ross,

I understand that you have declared rough consensus on this point and the WG has moved on.

However, I was looking for some furt= her technical rational for this decision.  From my perspective those suppo= rting the need to mix ICC and Global-ID have identified the scenarios, I do not see a need for any protocol extensions, just the removal of the restriction and I did not see any strong technical objections. Your perspective on the technical issues would provide some useful guidance on the points that need to be addressed if I, or some others, decide to write a new draft, as you suggest.

Regards,

Malcolm



Ross Callon <rcall= on@juniper.net>

23/05/2011 10:02 PM

To
"Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>
cc
"mpls@ietf.org" <mpls@i= etf.org>
Subject
RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?





Malcolm;
 
There has been extensive discussion of this issue on the MPLS WG email list since George SwallowR= 17;s original email of Mon 4/25/2011 5:17 PM. As has been pointed out there is no consensus to include mixed identifier types in the current draft. Admittedly the consensus to leave it out is rough, but this is the consensus that we have.
 
You and others are welc= ome to author or co-author a draft which points out scenarios in which mixing ICC and Global-IDs is useful, and the protocol mechanisms needed to support this. If you choose to write such a draft, then we would welcome discussion of this draft on the MPLS WG email list.
 
Thanks,
Ross and Loa (as MPLS WG co-chairs)
 
From: Malcolm.BETTS@zte.com.cn [m= ailto:Malcolm.BETTS@zte.com.cn]
Sent: Saturday, May 21, 2011 8:05 PM
To: Eric Gray
Cc: mpls@ietf.org; mpls-bounces@ietf.org; Ross Callon
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
 

Eric,

I find that argument somewhat circular since  we did not have consensus to omit this.

Regards,

Malcolm

Eric Gray <eric.gray@er= icsson.com>

20/05/2011 12:28 PM


To
"Malcolm.BETTS@zte.com.c= n" <Malcolm.BETTS@zte.com.cn>, Ross Callon <rcallon@juniper.net>
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,
 
   As a co-aut= hor of the draft in question, I completely support this decision.
 
   As I already explained to another person asking the same question, the
bit about "no consensus to change" says it all.
 
   In my opini= on, this is a quite sufficiently detailed response.  The absence
of a consensus to change means no change.  We do not typically require a
strong consensus to continue on the current path.
 
   I am reason= ably certain you apply similar rules yourself when working in
other SDOs.
 
--
Eric



From: mpls-bounces@ietf.org [mail= to:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?


Ross,

I disappointed and, based on my reading of the emails on this thread, surpr= ised that this decision has been taken.  Could you please elaborate on the reasoning behind this decision.

Regards,

Malcolm

Ross Callon <rcallon@ju= niper.net>
Sent by: mpls-bounces@ietf.org18/05/2011 02:40 PM 		 


To
"mpls@ietf.org" <= ;mpls@ietf.org>
cc
Subject
Re: [mpls] Mixing ICC and Global-IDs in M= PLS-TP Identifiers?

 








After discussion on the MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifi= ers without a change in this area.
This decision neither supports nor precludes the possibility that at some point in the future, after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.

Thanks,
Ross and Loa (as MPLS WG chairs)

[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG co-chair.]


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 0075E5FC8525789B_=-- From nitinb@juniper.net Wed May 25 17:35: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 CB4BCE06C9 for ; Wed, 25 May 2011 17:35:30 -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 hJLRumA6uNhT for ; Wed, 25 May 2011 17:35:26 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A5DADE06AB for ; Wed, 25 May 2011 17:35:21 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTd2gRBhr5UDyQt/a7Idir68zHdIT4gpm@postini.com; Wed, 25 May 2011 17:35:26 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 25 May 2011 17:31:54 -0700 From: Nitin Bahadur To: Loa Andersson , "mpls@ietf.org" , "draft-raggarwa-mpls-seamless-mcast@tools.ietf.org" , Ross Callon , "swallow@cisco.com" Date: Wed, 25 May 2011 17:31:51 -0700 Thread-Topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-Index: AcwZfVu27LZdxifNSUe1WkizTbFa3gA1stNgADoJyA8= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en 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: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 26 May 2011 00:35:30 -0000 Support. On 5/12/11 9:59 AM, "Loa Andersson" wrote: >Working Group, > >this is to start a two week poll on making > >draft-raggarwa-mpls-seamless-mcast-03.txt > >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 on May 27th. > >/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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From maciek@juniper.net Thu May 26 02:08:07 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 0D757E06CF for ; Thu, 26 May 2011 02:08:07 -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 Uhd2yFZcr7nL for ; Thu, 26 May 2011 02:08:06 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 40E96E0692 for ; Thu, 26 May 2011 02:08:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTd4YbtQ0+b04UwYNT56JQCKnPIH0IQIJ@postini.com; Thu, 26 May 2011 02:08:06 PDT Received: from [172.26.200.194] (172.26.200.194) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 26 May 2011 02:04:45 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Maciek Konstantynowicz In-Reply-To: <4DCBE7BE.5010708@pi.nu> Date: Thu, 26 May 2011 10:04:40 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <4DCBE7BE.5010708@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1081) Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 26 May 2011 09:08:07 -0000 yes/support Cheers, Maciek. On 12 May 2011, at 14:59, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > 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 on May 27th. > > /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 Adrian.Farrel@huawei.com Thu May 26 04:21: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 807A713003A for ; Thu, 26 May 2011 04:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.924 X-Spam-Level: X-Spam-Status: No, score=-104.924 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, J_CHICKENPOX_32=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 uLog6Ui24j3F for ; Thu, 26 May 2011 04:20:57 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5F13002F for ; Thu, 26 May 2011 04:20:57 -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 <0LLS003A2VIVF8@usaga03-in.huawei.com> for mpls@ietf.org; Thu, 26 May 2011 06:20:55 -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 <0LLS00MBDVITSH@usaga03-in.huawei.com> for mpls@ietf.org; Thu, 26 May 2011 06:20:55 -0500 (CDT) Date: Thu, 26 May 2011 12:20:43 +0100 From: Adrian Farrel To: daft-ietf-mpls-loss-delay@tools.ietf.org Message-id: <068901cc1b96$f9344b20$eb9ce160$@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: AcwblszoZZv9ul0DSNi2eHOnDCGnhg== Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of daft-ietf-mpls-loss-delay 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: Thu, 26 May 2011 11:21:03 -0000 Hi, Don't panic! I have performed my AD review of daft-ietf-mpls-loss-delay. 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. This is a good solid document: thanks! I don't have any major technical issues with your draft. The intention and solution are fine. However, I found a largish number of small issues and questions. These are mainly concerns with clarity, although I did have some more substantial concerns about the security section. 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 goes to IETF last call. 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 --- Section 1 o The LM and DM protocols are applicable to the LSPs, pseudowires, and sections of networks based on the MPLS Transport Profile (MPLS-TP), because the MPLS-TP is based on a standard MPLS data plane. The MPLS-TP is defined and described in [RFC5921], and MPLS-TP LSPs, pseudowires, and sections are discussed in detail in [RFC5960]. You should give an Informative forward reference to draft-ietf-mpls-tp-loss-delay-profile. --- Section 1 o The LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurement. s/for both/both for/ --- Section 2.3 This section on Throughput seems very thin. In Section 2.4 you note: Measurement of the one-way delay quantities requires that the clocks of A and B be synchronized, whereas the two-way delay metrics can be measured directly even when this is not the case (provided A and B have stable clocks). Doesn't the same logic apply to throughput measurement? --- 2.7. Dyadic Measurement It is so nice to see words used. But do you think that your readership will really understand? And is this precisely the right word, anyway? After all, it appears that you mean a specific limitation of a dyad to the pair of ends. You write: Consequently this document does not attempt to specify a dyadic operational mode. Delete "attempt to" --- 2.9.11 There are two significant timestamp formats in common use: the timestamp format of the Internet standard Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. Please avoid the word "standard" as RFC 5905 is not an Internet Standard. Suggest you delete "Internet standard" without any loss of meaning. Can you please add to this section some text such as... To ensure interop it is necessary that support of at least one format is mandatory. This specification requires the support of the PTP format as discussed in Section 3.4 and Appendix A. --- Section 3 The message formats for direct and inferred LM are identical, as are the formats for the DLM+DM and ILM+DM messages. A little care needed? I think you mean: The message formats for direct and inferred LM are identical. The formats for the DLM+DM and ILM+DM messages are identical. --- Section 3.1 Did you consider simply burning a new ACH type rather than including a version number field? Just idle curiosity... --- Section 3.1 Control Code : Responses This list starts off saying that the fields in the response either "MUST NOT be used" or "do not contain valid measurement data". And then this advice peters out in a way that might be inferred to mean that the data *is* valid on other response codes. I think the turning point was when you crossed the 0xf boundary, so you might simply say that for all return codes > 0xf the data is not valid. --- Section 3.1 Message Length: Set to the total length of this message in bytes. For the avoidance of doubt, it is usual to say "...including the Version, Flags, Control Code, and Message Length fields." I know one AD that will want you to say that the two-octet integer is presented in line format. --- Section 3.1 It wasn't clear to me until I read 3.4 that the timestamp field is uniformly 64 bits. Could you add a note? The way you have shown 8-byte quantities in the figure is slightly unusual. --- Sections 3.2 and 3.3 Some of the field description issues from 3.1 apply. --- Section 3.4 Implementations SHOULD also be capable of reading timestamps written in NTPv4 64-bit format and reconciling them internally with PTP timestamps for measurement purposes. Support for other timestamp formats is OPTIONAL. Why is this "SHOULD" not "MUST"? It seems to me that unless you say "MUST" you cannot achieve interoperability. --- 3.5 I am worried by two aspects of the parameter ranges defined here. Type Definition -------------- --------------------------------- Mandatory [snip] 4-119 Reserved 120-127 Implementation-specific usage Optional [snip] 131-247 Reserved 248-255 Implementation-specific usage 1. s/Reserved/Unallocated/ 2. Why so many (any!) implementation-specific TLVs. Any changes need to be reflected in the IANA section. --- 3.5.1 More than one padding object MAY be present, in which case they SHOULD be contiguous. Padding objects SHOULD occur at the end of the TLV Block. The Value field of a padding object is arbitrary. Not sure what the point these two "SHOULD" statements is. The fact that they are only "SHOULD" means that a parser must be able to process variations. --- Section 6 ends with the throw-away line: Authentication procedures can also be used to ensure that only queries from authorized devices are processed. I assume you are referring to Access Lists rather than authentication because there is no discussion here, or in Section 7, of any such authentication procedure.... See my next comment about Section 7 --- Section 7 If reception or alteration of performance-related data by unauthorized devices is an operational concern, authentication and/or encryption procedures should be used to ensure message integrity and confidentiality. Such procedures are outside the scope of this document, but have general applicability to OAM protocols in MPLS networks. There is no way you will get this through a review by anyone with security clue! I understand that what you are saying is that we need a generic solution to security for OAM and then you can shelter under that umbrella, but what you have done is identified an attack vector, defined it as a potential problem, and then left the protocol unprotected! Unfortunately, this could easily turn into a blocking issue as currently expressed. My advice is: 1. Expand upon the text you have in this section to include a discussion of how modification, injection, or snooping is only possible from an on-path node (you would need to explain why). Go on to say that, in general, all LSRs within a domain share a common trust relationship such that malign or compromised LSRs are not considered a significant risk. Explain that this means that the security concerns only become apparent in multi-domain environments where it is less likely that end-to-end OAM is run. 2. Include a reference to draft-ietf-mpls-tp-security-framework for "an overview of security issues concerning OAM messages" 3. Include a forward reference to an I-D that has been started to give a solution to the security concerns. I think you are in a bit of a hole and you may have to make the first version of this draft yourselves (before this I-D can go any further). Not a very comfortable situation. Please note that I think this is the *least* we will get away with. If I saw this coming up from a draft in another area and I was reviewing it, I would probably push back quite hard to get the security details properly worked out. From internet-drafts@ietf.org Thu May 26 05:25:33 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 A6438E0742; Thu, 26 May 2011 05:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, 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 lyv-HFnVx+zg; Thu, 26 May 2011 05:25:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5EE06FE; Thu, 26 May 2011 05:25:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110526122530.21766.88085.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 05:25:30 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mp-ldp-reqs-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 12:25:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Requirements for Point-To-Multipoint Extensions to the L= abel Distribution Protocol Author(s) : Jean-Louis Le Roux Thomas Morin Filename : draft-ietf-mpls-mp-ldp-reqs-08.txt Pages : 20 Date : 2011-05-26 This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-08.txt From gash5107@yahoo.com Thu May 26 09:51: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 47671E0655 for ; Thu, 26 May 2011 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.463 X-Spam-Level: X-Spam-Status: No, score=-98.463 tagged_above=-999 required=5 tests=[AWL=2.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 gKn-Hjma196S for ; Thu, 26 May 2011 09:51:30 -0700 (PDT) Received: from nm1-vm3.bullet.mail.ne1.yahoo.com (nm1-vm3.bullet.mail.ne1.yahoo.com [98.138.91.131]) by ietfa.amsl.com (Postfix) with SMTP id 89345E06FD for ; Thu, 26 May 2011 09:51:30 -0700 (PDT) Received: from [98.138.90.51] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 Received: from [98.138.89.246] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 26 May 2011 16:51:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 368988.71360.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 89745 invoked by uid 60001); 26 May 2011 16:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306428687; bh=0RrhAV1LY1ilwDBuu8cfkPjSeCUM9OiBRd7+LlCRmCs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=mfcTk2oxIGs9ge6S3mcrQLyuwghEoxAQqRjdO59ZIUWzdg9s1E5tzL7hUMTwzf6t1ir4lsGda0iDErbjtVsGa4uVlsfDQHn6W9LZPwxj7f0mo+ry6PH1uEBq7kUEOeQ664Wkyvib19w4zvQ7xGV3eARYc7s1dz0btSG0gr/KDak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VXe/8OCEeG0KKkFTGb3DaZljx6gF893l/NZbHGrX5sShd4g4ujJo/1ecsBFc907kKr4fetqh+KRNcd5zdOU/sAVbqrpVHO9vr+z6Fg9B6Pgk27DrBXx0PKE95M5Bnzwcr62Nx2iX7ZfRCDxULqqYqm2jCKojgD/qLgfQ4pUBryc=; Message-ID: <285128.82087.qm@web125919.mail.ne1.yahoo.com> X-YMail-OSG: 8kV5gCYVM1mnhywaa9Ft4Xgv7PS54KaW84.aUc9dKm0G6zG 1lFPbUDX.TEdtRMJtUEun2axEhY.fPJqTigj6aRTZedffpkWU0JRKfpnrkFl bnmZj33hTjBMJQn2I4btzkgPLGvb8nuv5VXFI7rXWQTBpfnr_Dc5aDg.5nbW u0C44OAhfLRSof4rv0p.hiVQPauET3NpldfQiH9EQH7PR9ZpAKczXImMakbv 7PFFfn4Q5p0BWvFWZH40EVIfvwic3WP4rz_L8hO_E5rA7XDEYAE9jq_pXEAB s9BCbohMUVVu1oJsZIVdVuFHnO3_mFvClj7gflQHcbMHrGz65lHP6dgvo0vQ RGnHP6NpRgNVKKZBgikG2f51l5g-- Received: from [71.233.102.170] by web125919.mail.ne1.yahoo.com via HTTP; Thu, 26 May 2011 09:51:27 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Thu, 26 May 2011 09:51:27 -0700 (PDT) From: Gerald Ash To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1626380600-1306428687=:82087" Cc: mpls@ietf.org Subject: [mpls] Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks 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, 26 May 2011 16:51:35 -0000 --0-1626380600-1306428687=:82087 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 Adrian has suggested that the RTGWG and the MPLS WG review=A0the draft "Gen= eric Connection Admission Control (GCAC) Algorithm Specification for IP/MPL= S Networks", available=A0at =A0http://www.ietf.org/id/draft-ash-gcac-algori= thm-spec-00.txt=A0(abstract=A0below). The underlying goal of the work is to specify an optional GCAC algorithm fo= r IP/MPLS networks,=A0to be adopted and implemented by vendors and service = providers, that interoperates between vendor equipment and across multiple = service provider domains.=A0 This would be analogous to the PNNI GCAC that = was widely adopted and=A0helped promote=A0interoperability of ATM networks.= =A0 In addition, the approach: o=A0is=A0based on=A0CSPF, widely implemented by vendors o=A0does=A0NOT include aspects of CAC that might be considered vendor propr= ietary implementations, such as detailed path selection mechanisms o relies on=A0available standard mechanisms for MPLS based networks, such a= s RSVP, DSTE, PCE... =A0 Comments appreciated. =A0 Thanks, Jerry =A0 From: Internet-Drafts@ietf.org=A0 To: i-d-announce@ietf.org=A0 Reply-to: Internet-Drafts@ietf.org=A0 Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt=A0 X-RSN: 1/0/935/34473/37870=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts =A0 directories. =A0 Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks=A0 Author(s) : G. Ash, D. McDysan=A0 Filename : draft-ash-gcac-algorithm-spec-00.txt=A0 Pages : 23=A0 Date : 2011-1-11=A0 =A0 This document presents a generic connection admission control (GCAC)=A0 reference model and algorithm for IP/MPLS-based networks. Service=A0 provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for=A0 example, to reject voice over Internet Protocol (VoIP) calls when=A0 additional calls would adversely affect calls already in progress.=A0 =A0 Without MPLS GCAC, connections on congested links will suffer=A0 degraded quality. The MPLS GCAC algorithm can be optionally=A0 implemented in vendor equipment and deployed by service providers.=A0 MPLS GCAC interoperates between vendor equipment and across multiple=A0 service provider domains. The MPLS GCAC algorithm uses available=A0 standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE,=A0 NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include=A0 aspects of CAC that might be considered vendor proprietary=A0 implementations, such as detailed path selection mechanisms. MPLS=A0 GCAC functions are implemented in a distributed manner to deliver the=A0 objective QoS for specified QoS constraints. The source is able to=A0 compute a source route with high likelihood that MPLS GCAC via=A0 elements along the selected path will in fact admit the request.=A0 MPLS GCAC is applicable to any service or flow that must meet an=A0 objective QoS (delay, jitter, packet loss rate) for a specified=A0 quantity of traffic.=A0 =A0 A URL for this Internet-Draft is:=A0 http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt =A0 Internet-Drafts are also available by anonymous FTP at:=A0 ftp://ftp.ietf.org/internet-drafts/ =A0 Below is the data which will enable a MIME compliant mail reader=A0 implementation to automatically retrieve the ASCII version of the=A0 Internet-Draft.=A0 _______________________________________________=A0 I-D-Announce mailing list=A0 I-D-Announce@ietf.org=A0 https://www.ietf.org/mailman/listinfo/i-d-announce=A0 Internet-Draft directories: http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=A0 =A0 *****=A0 Click below to download the attachment(s) in this message:=A0 Attachment: draft_ash_gcac_algorithm_spec_00= .txt (1K)=A0 --0-1626380600-1306428687=:82087 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
H= i,
 
Adrian has suggested that the RTGWG and the MPLS WG review the dr= aft "Generic http://www.ietf.org/id/draft-ash-gcac-algorithm-spec-00.txt=  (abstract below).
The underlying goal of the work is to specify an optional GCAC algorit= hm for IP/MPLS networks, to be adopted and implemented by vendors and = service providers, that interoperates between vendor equipment and across m= ultiple service provider domains.  This would be analogous to the PNNI= GCAC that was widely adopted and helped promote interoperability= of ATM networks.  In addition, the approach:
o is based on CSPF, widely implemented by vendors
o does NOT include aspects of CAC that might be considered v= endor proprietary implementations, such as detailed path selection mechanis= ms
o relies on available standard mechanisms for MPLS based networks= , such as RSVP, DSTE, PCE...
 
Comments appreciated.
 
Thanks,
Jerry
 
From: Internet-Drafts@ietf.org&nbs= p;
To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org 
Subject: I-D ACTION:draft-ash= -gcac-algorithm-spec-00.txt 
X-RSN: 1/0/935/34473/37870 
&n= bsp;
A New Internet-Draft is available from the on-line Internet-Drafts =  
directories.
 
Title : Generic Connection Admission Co= ntrol (GCAC) Algorithm Specification for IP/MPLS Networks 
Author(s= ) : G. Ash, D. McDysan 
Filename : draft-ash-gcac-algorithm-spec-00= .txt 
Pages : 23 
Date : 2011-1-11 
 
This = document presents a generic connection admission control (GCAC) 
reference model and algo= rithm for IP/MPLS-based networks. Serv= ice 
provider (SP) IP/MPLS networks need an MPLS GCAC mechan= ism, for 
example, to reject voice over Internet Protocol (VoIP) ca= lls when 
additional calls would adversely affect calls already in = progress. 
 
Without MPLS GCAC, connections on congested li= nks will suffer 
degraded quality. The MPLS GCAC algorithm can be o= ptionally 
implemented in vendor equipment and deployed by service = providers. 
MPLS GCAC interoperates between vendor equipment and ac= ross multiple 
service provider domains. The MPLS GCAC algorithm us= es available 
standard mechanisms for MPLS based networks, such as = RSVP, DSTE, PCE, 
NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm= does not include 
aspects of CAC that might be considered vendor p= roprietary 
implementations, such as detailed path selection mechanisms. MPLS 
GCAC functions are implemented in a distributed = manner to deliver the 
objective QoS for specified QoS constraints.= The source is able to 
compute a sour= ce route with high likelihood that MPLS GCAC via 
elements a= long the selected path will in fact admit the request. 
MPLS GCAC i= s applicable to any service or flow that must meet an 
objective Qo= S (delay, jitter, packet loss= rate) for a specified 
quantity of traffic. 
 =
A URL for this Internet-Draft is: 
http://www.ietf.= org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt
 
Internet-Drafts are also available by anonymous FTP at: = ;
ftp://ftp.ietf.org/internet-drafts/
 
Below is the data whi= ch will enable a MIME compliant mail reader 
implementation to auto= matically retrieve the ASCII version of the 
Internet-Draft. <= BR>_______________________________________________ 
I-D-Announce ma= iling list 
I-D-Announce@ietf.org 
https://www.ietf.org/mailman/listinfo/i-d-announc= e 
Internet-Draft directories: http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
 
***** 
Click below to download the attach= ment(s) in this message: 
<A HREF=3D"http://= www.ietf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D935&file= =3Di-d-announce.37870.1.txt">Attachment: draft_ash_gcac_algor= ithm_spec_00.txt</A> (1K) 
--0-1626380600-1306428687=:82087-- From ogondio@tid.es Thu May 26 13:32: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 E2A7BE0721 for ; Thu, 26 May 2011 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.502 X-Spam-Level: * X-Spam-Status: No, score=1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_39=0.6, MIME_8BIT_HEADER=0.3] 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 8eh6dhe1KmWL for ; Thu, 26 May 2011 13:32:37 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5110AE0707 for ; Thu, 26 May 2011 13:32:36 -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 <0LLT00F9FL29X0@tid.hi.inet> for mpls@ietf.org; Thu, 26 May 2011 22:32:33 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 1F.65.02885.002BEDD4; Thu, 26 May 2011 22:03:12 +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 <0LLT00F9CL28X0@tid.hi.inet> for mpls@ietf.org; Thu, 26 May 2011 22:32:32 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 26 May 2011 22:32:32 +0200 Date: Thu, 26 May 2011 22:31:29 +0200 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tzPRs0HP1zk3VSXMmw6vDg)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-index: AcwbwF6HLoTUDamgQ0mXgPKNCP+5Fw== acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7beeae000000b45-d8-4ddeb200f897 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42Lhinfg0mXYdM/XYPNWeYtbS1eyOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+uXv8wFV3wqWmduZ25gvOPcxcjJISFgIrH81iU2CFtM4sK9 9UA2F4eQwEZGifbLJ5hAEkICPxglZm71hEg0Mkos7/3OCpJgEVCV2LF2HyOIzSbgILFuUS/Y JGEBO4lXbc9YQGwRAWWJIxO7wep5BTwlOle3s0DYghI/Jt8Ds5kFciW6Hp5ih7DFJeb8mghW zyggK7Hy/GlGiDnOEueffmOGsPUkHh59yQ5RIyPxf/leFogPBCSW7DnPDGGLSrx8/I91AqPw LCTrZiFZNwvJOghbT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2BkX8UoVpxUlJmeUZKbmJmT bmCol5Gpl5mXWrKJERIvGTsYl+9UOcQowMGoxMMrEH3XV4g1say4MvcQoyQHk5IoL9+Oe75C fEn5KZUZicUZ8UWlOanFhxglOJiVRHg5OoFyvCmJlVWpRfkwKRkODiUJXkGQNsGi1PTUirTM HGBSgEkzcXCCtPMAtZ/dDtJeXJCYW5yZDpE/xSgpJc77DCQhAJLIKM2D633FKA50pDAvD8ho HmD6gut6BTSQCWigzu+7IANLEhFSUg2MUe8Sxdtur9/ysjNRO+BaFtvSZfffPZe8V+rroJwe wb5s0oZ7kQutO1aZ9+8Kr3C5m5o8k5E1cfcfgbeMjN87lky99uuQ5KnSC59Urq389PNSdpiE 8uOg9Nn1HeGHsk5I7V62vGei8mcrS7Z+p9eGep2ZX0J38zr4hcpHBr39f5ah+05o+rmpSizF GYmGWsxFxYkAxX7IcBwDAAA= Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 26 May 2011 20:32:39 -0000 --Boundary_(ID_tzPRs0HP1zk3VSXMmw6vDg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Support =D3scar >Working Group, > >this is to start a two week poll on making > >draft-raggarwa-mpls-seamless-mcast-03.txt > >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 on May 27th. > >/Loa > >-- > > >Loa Andersson email: loa.andersson at ericsson.com >Sr Strategy and Standards Manager loa at pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls at 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 --Boundary_(ID_tzPRs0HP1zk3VSXMmw6vDg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Support

 

     =D3sca= r

 

 

>Working Group,

> 

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

> 

>draft-raggarwa-mpls-seamles= s-mcast-03.txt

> 

>an mpls working group docum= ent.

> 

>If you support the document= becoming a working group document

>please respond to this poll= with "yes/support"

> 

>If you do not support the d= ocument becoming a working group

>document please respond to = this poll with "no/do not support"

>and at the same time give t= he technical reasons why you are

>not supporting the document= .

> 

>If you have technical comme= nts or in any other way want to

>discuss the document, pleas= e send these comments to the mpls

>working group mailing list,= but with another subject than what

>is on this mail.=

> 

>The poll ends on May 27th.<= o:p>

> 

>/Loa

> 

>--

> 

> 

>Loa Andersson  &n= bsp;            = ;          email: loa.andersso= n at ericsson.com

>Sr Strategy and Standards M= anager            lo= a at pi.nu

>Ericsson Inc   &n= bsp;            = ;          phone: &n= bsp;           +46 10= 717 52 13     

>    &nb= sp;            =             &nb= sp;            =             &nb= sp;   +46 767 72 92 13     

>___________________________= ____________________

>mpls mailing list

>mpls at ietf.org=

>https://www.ietf.org/mailma= n/listinfo/mpls

 


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_tzPRs0HP1zk3VSXMmw6vDg)-- From neil.2.harrison@bt.com Fri May 27 03:12:47 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 E0BD5E06BE for ; Fri, 27 May 2011 03:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=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 HbhOZVdystLK for ; Fri, 27 May 2011 03:12:46 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 509E4E06C4 for ; Fri, 27 May 2011 03:12:45 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 27 May 2011 11:12:45 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.96]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 27 May 2011 11:12:43 +0100 From: To: , , Date: Fri, 27 May 2011 11:12:40 +0100 Thread-Topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-Index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0QgAAECTCAACSAsIADBE4g Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440266EB8C8@EMV62-UKRD.domain1.systemhost.net> References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> <6D3D47CB84BDE349BC23BF1C94E316E440264057E4@EMV62-UKRD.domain1.systemhost.net> 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] R: Re: 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: Fri, 27 May 2011 10:12:48 -0000 U29ycnkgYml0IGxhdGUgcmVzcG9uZGluZyBNYWFydGVuLi4uLndhbnRlZCB0byBjaGVjayB0aGlz IG91dCB3aXRoIFRvbnkgRmxhdmluIGFuZCBBbGFuIE1jR3VpcmUgaGVyZSBmaXJzdC4gIFNlZW1z IHdlIGNhbiBoYXZlIHdoYXQgYXBwZWFycyB0byBiZSBYb3ZlclggZHVlIHRvIHJlY3Vyc2l2ZWx5 IG5lc3RpbmcgYSBkaWdpdGFsIHdyYXBwZXIgc2NoZW1lLiAgTm90IHN1cmUgd2hhdCByZWN1cnNp b24gbGltaXRzIGFwcGx5IGhlcmUgd3J0IHJlc291cmNlIChDRiA8PU1UVSBpbiBjby1wcyBwa3Qg Y2FzZSkgYW5kIHdlIHNob3VsZCBiZSBjYXJlZnVsIG5vdCB0byBjb21wcm9taXNlIHRoZSBzdHJv bmcgcmVzb3VyY2UgYWNjb3VudGluZy9tYW5hZ2VtZW50IGNhcGFiaWxpdHkgdGhhdCBhIGNvLWNz IG1vZGUgbmV0d29yayBzaG91bGQgYmUgYWJsZSB0byBkZWxpdmVyIHRvIGl0cyBjbGllbnRzLiAg U28gbWF5YmUgKGhvcGVmdWxseT8pIHRoZSBtYWpvciBpc3N1ZSBoZXJlIGlzIG9uZSBvZiBlbnN1 cmluZyB0aGF0IGVhY2ggbGF5ZXIgY2FuIGJlIHVuaXF1ZWx5IGlkZW50aWZpZWQgd3J0IGFjY2Vz cyBwb2ludHMuDQoNCnJlZ2FyZHMsIE5laWwNCg0KVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZv cm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLg0KSXQncyBt ZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElm IHlvdSdyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5n LCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbg0KaXMgcHJv aGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBs ZXQgbWUga25vdyBpbW1lZGlhdGVseQ0Kb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5r IHlvdS4NCldlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBl bWFpbHMuDQpCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNClJlZ2lzdGVyZWQgb2ZmaWNl OiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNClJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCBubzogMTgwMDAwMA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBNYWFydGVuIHZpc3NlcnMgW21haWx0bzptYWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0NCj4g U2VudDogMjUgTWF5IDIwMTEgMTM6MDQNCj4gVG86IEhhcnJpc29uLE4sTmVpbCxES1E3IFI7IGFk cmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBS OiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+IElkZW50aWZpZXJz Pw0KPg0KPiBOZWlsLA0KPg0KPiBGWUkuIFRoZSBjby1jcyBPRFUgbGF5ZXJzIGhhdmUgdGhlIHNh bWUgc3RhY2tpbmcgY2FwYWJpbGl0eSBhcyBNUExTLVRQDQo+IExTUCBhbmQgRVRIIGxheWVyczsg aS5lLiBYb3ZlclggaXMgc3VwcG9ydGVkIGFuZCBkZXBsb3llZC4gQXMgc3VjaCBpbg0KPiBPVE4g d2UgY2FuIGhhdmUgbWlzY29ubmVjdGlvbnMgYmV0d2VlbiBlLmcuIExPIE9EVTIgYW5kIEhPIE9E VTINCj4gY29ubmVjdGlvbnMuIFRoZSB0cmFmZmljIHVuaXRzIGluIE9UTiBhcmUgdmFyaWFibGUg c2l6ZWQgdHJhZmZpYyB1bml0cy4NCj4NCj4gUmVnYXJkcywNCj4gTWFhcnRlbg0KPg0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmVpbC4yLmhhcnJpc29uQGJ0LmNv bSBbbWFpbHRvOm5laWwuMi5oYXJyaXNvbkBidC5jb21dDQo+ID4gU2VudDogMjUgTWF5IDIwMTEg MTM6MjMNCj4gPiBUbzogTWFhcnRlbiB2aXNzZXJzOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBtcGxz QGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQg R2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ID4gSWRlbnRpZmllcnM/DQo+ID4NCj4gPiBUaGVyZSBp cyBhbiBpbXBvcnRhbnQgZGlmZmVyZW5jZSBoZXJlLiAgV2UgY2Fubm90IGhhdmUgKmludGVyKiBs YXllcg0KPiA+IG1pc2Nvbm5lY3Rpdml0eSBpbiBjby1jcyBtb2RlIG5ldHdvcmtzLi4udGhpcyBm b2xsb3dzIGRpcmVjdGx5IGZyb20NCj4gaG93DQo+ID4gdGhlIGxhYmVsbGluZyBvZiByZXNvdXJj ZSBwYXJ0aXRpb25zIHdvcmtzIGluIGVhY2ggb2YgdGhlIDMgbW9kZXMuDQo+IFNvDQo+ID4gaWYg dGhlcmUgaXMgYSBuZWVkIHRvIHByb2Nlc3MgZGlmZmVyZW50IENWICdTQScgSURzIGhlcmUgdGhl biB0aGF0IGlzDQo+ID4gZG93biB0byBhIHNlbGYtaW5mbGljdGVkIHBlZXJpbmcgY2FzZSBvZiBm b3JjaW5nIG1vcmUgZnVuY3Rpb25hbGl0eQ0KPiA+IHRoYW4gYSB0cnVlIEJPUy1waHlzaWNhbCBi aXQgaW50ZXJjb25uZWN0IGNhc2UgcmVxdWlyZXMuDQo+ID4NCj4gPiBIb3dldmVyLCB3aGVuIHdl IGhhdmUgYSB2YXJpYWJsZSBzaXplIHRyYWZmaWMgdW5pdCBpbiB0aGUgY28tcHMgbW9kZSwNCj4g PiBhcyB3ZSBoYXZlIHdpdGggTVBMUy1UUCwgdGhlbiB3ZSBjYW4gaGF2ZSBzb21ldGhpbmcgdGhh dCBsb29rcyBsaWtlDQo+ID4gWG92ZXJYIChhcyBtYW55IHRpbWVzIGFzIG9uZSBsaWtlcyAtIHN1 YmplY3QgdG8gPE1UVSkuICBTbywgaW4NCj4gYWRkaXRpb24NCj4gPiB0byBtaXNjb25uZWN0aXZp dHkgZHVlIHRvIGFueSBzZWxmLWluZmxpY3RlZCBwZWVyaW5nIGNhc2UsIHdlIGNhbg0KPiBhbHNv DQo+ID4gaGF2ZSAoaSkgbWlzY29ubmVjdGl2aXR5IGJldHdlZW4gbGF5ZXJzIGF0IGRpZmZlcmVu dCBsZXZlbHMgb3IgKGlpKQ0KPiA+IGJldHdlZW4gZGlmZmVyZW50L2luZGVwZW5kZW50IGxheWVy IG5ldHdvcmtzIGF0IGxldmVsIE4gc2F5IGR1ZSB0byBhDQo+ID4gc2VydmVyIGxheWVyIG1pc2Nv bm5lY3Rpdml0eSBkZWZlY3QgYmVsb3cgbGV2ZWwgTi4gIFRoZSBrZXkgcG9pbnRzDQo+IGhlcmUN Cj4gPiBiZWluZzoNCj4gPiAgKGkpIGEgcmljaGVyIGRlZmVjdCBlbnZpcm9ubWVudCB0aGFuIHRo ZSBjby1jcyBtb2RlDQo+ID4gKGlpKSBpZiBOIHR5cGVzIG9mIENWICdJRCcgZXhpc3QgdGhlbiB3 ZSBjYW4ndCBhc3N1bWUgdGhleSByZW1haW4NCj4gPiBpbmRlcGVuZGVudCBvZiBlYWNoIG90aGVy IGF0IGFsbC4uLi5hcyB3ZSBjb3VsZCBpZiB3ZSBkaWQgbm90IGltcG9zZQ0KPiBhDQo+ID4gc2Vs Zi1pbmZsaWN0ZWQgcGVlciBjYXNlIG9uIG91cnNlbHZlcy4uLmFuZCB0aHVzIGVhY2ggbmV0d29y ayBtdXN0IGJlDQo+ID4gYWJsZSB0byBoYW5kbGUgYWxsIE4gaW5zdGFuY2VzIG9mIElEIChJIGFz c3VtZSB0aGUgc2FtZSBDViBPQU0NCj4gdHJhZmZpYw0KPiA+IHVuaXQgY2FycnlpbmcgdGhlbSAt IHZhcnlpbmcgdGhhdCBqdXN0IG1ha2VzIHRoZSBtaXggZXZlbiBtb3JlDQo+ID4gaW50ZXJlc3Rp bmcpLg0KPiA+DQo+ID4gcmVnYXJkcywgTmVpbA0KPiA+IEJUIERlc2lnbg0KPiA+DQo+ID4gVGhp cyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3INCj4gPiBjb25maWRlbnRpYWwuDQo+ID4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZp ZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmDQo+IHlvdSdyZQ0KPiA+IG5vdCB0aGUg aW50ZW5kZWQNCj4gPiByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBk aXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcw0KPiA+IGluZm9ybWF0aW9uDQo+ID4gaXMgcHJvaGli aXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQg bWUNCj4gPiBrbm93IGltbWVkaWF0ZWx5DQo+ID4gb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUu IFRoYW5rIHlvdS4NCj4gPiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVj b3JkIHlvdXIgZW1haWxzLg0KPiA+IEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ IFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4g PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAwMDANCj4gPg0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbXBscy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhh bGYNCj4gPiBPZg0KPiA+ID4gTWFhcnRlbiB2aXNzZXJzDQo+ID4gPiBTZW50OiAyNSBNYXkgMjAx MSAxMDo0Mg0KPiA+ID4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCj4g PiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMg aW4gTVBMUy1UUA0KPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPg0KPiA+ID4gQWRyaWFuLA0KPiA+ ID4NCj4gPiA+IFBsZWFzZSBiZSBhd2FyZSB0aGF0IHVuZGVyIGZhdWx0IGNvbmRpdGlvbnMgYW4g SUNDIGZvcm1hdHRlZCBJRCBjYW4NCj4gPiBiZQ0KPiA+ID4gcmVjZWl2ZWQgYnkgYW4gZW5kcG9p bnQgdXNpbmcgYSBHbG9iYWxfSUQgZm9ybWF0dGVkIElELCBhbmQgdmljZQ0KPiA+IHZlcnNhLg0K PiA+ID4gRWl0aGVyIGVuZHBvaW50IG11c3QgYmUgYWJsZSB0byBkZXRlY3QgYSBtaXNjb25uZWN0 aW9uIGNvbmRpdGlvbg0KPiBhbmQNCj4gPiBiZQ0KPiA+ID4gYWJsZSB0byByZXBvcnQgdGhlIHJl Y2VpdmVkIElEIChpbiB0aGUgbm9uLWV4cGVjdGVkIGZvcm1hdCkgdG8gTk1TDQo+IHRvDQo+ID4g PiBndWlkZSBpbiB0aGUgZmF1bHQgbG9jYWxpc2F0aW9uLg0KPiA+ID4NCj4gPiA+IE5vdGUgdGhh dCB3ZSBvdmVybG9va2VkIGEgc2ltaWxhciByZXF1aXJlbWVudCBpbml0aWFsbHkgaW4gU0RIICgx Ni0NCj4gPiBieXRlDQo+ID4gPiBUVEkgYW5kIDY0LWJ5dGUgVFRJKSwgYW5kIHRoaXMgcmVxdWly ZWQgdXMgdG8gdXBncmFkZSBvdXIgVkMtbg0KPiA+ID4gZW5kcG9pbnRzIGFmdGVyd2FyZHMuIExl dCdzIG5vdCBtYWtlIGEgc2ltaWxhciBtaXN0YWtlIGluIE1QTFMtVFAuDQo+ID4gPg0KPiA+ID4g UmVnYXJkcywNCj4gPiA+IE1hYXJ0ZW4NCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYNCj4gPiA+IE9mDQo+ID4gPiA+IEFk cmlhbiBGYXJyZWwNCj4gPiA+ID4gU2VudDogMjUgTWF5IDIwMTEgMTE6MTMNCj4gPiA+ID4gVG86 IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBSOiBSZTogTWl4aW5n IElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ID4gPiA+IElkZW50aWZpZXJzPw0KPiA+ ID4gPg0KPiA+ID4gPiBIaSBOZWlsLA0KPiA+ID4gPg0KPiA+ID4gPiBJJ20gbm90IGFzc3VtaW5n IHBlZXJpbmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcgb3V0IHRvIEh1dWIgdGhhdA0KPiA+ID4g PiAoZGVzcGl0ZSB3aGF0IGhlIGtlZXBzIHNheWluZykgaGUgaXMgYWxzbyBub3QgYXNzdW1pbmcg cGVlcmluZy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGNvbnNlcXVlbmNlIG9mIG5vdCBwZWVyaW5n IGlzIHRoYXQgYSBzaW5nbGUgaWRlbnRpZmllciBtb2RlDQo+IGlzDQo+ID4gPiB1c2VkDQo+ID4g PiA+IGZvciBib3RoIGVuZHMgb2YgYW4gT0FNICJzZXNzaW9uIi4gQW5kIHRoYXQgbWVhbnMgdGhh dCBvbmUgZW5kDQo+IGhhcw0KPiA+IHRvDQo+ID4gPiA+IHVuZGVyc3RhbmQgKmFuZCogdXNlIHRo ZSAiZm9yZWlnbiIgZm9ybWF0IGF0IHRoZSByZW1vdGUgZW5kIG9mDQo+IHRoZQ0KPiA+ID4gPiBz ZXNzaW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBJIGFtIHRpcmVkIG9mIHRoaXMgZGlzY3Vzc2lvbi4g VGhlcmUgc2VlbXMgdG8gYmUgbm8gZm9yd2FyZA0KPiA+IHByb2dyZXNzDQo+ID4gPiA+IG9ubHkg cmVzdGF0ZW1lbnQgb2YgYSAid2FudCIuIEkgYWx3YXlzIHdhbnRlZCBhIHBvbnkgd2hlbiBJIHdh cyBhDQo+ID4gPiA+IGxpdHRsZSBnaXJsLCBidXQgSSBuZXZlciBnb3Qgb25lLg0KPiA+ID4gPg0K PiA+ID4gPiBBZHJpYW4NCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiA+IEJlaGFsZg0KPiA+ID4gPiBPZg0KPiA+ID4gPiA+ IG5laWwuMi5oYXJyaXNvbkBidC5jb20NCj4gPiA+ID4gPiBTZW50OiAyMiBNYXkgMjAxMSAyMDoz Ng0KPiA+ID4gPiA+IFRvOiBodXViYXR3b3JrQGdtYWlsLmNvbTsgbXBsc0BpZXRmLm9yZw0KPiA+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1J RHMgaW4gTVBMUy1UUA0KPiA+ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEhpIEFkcmlhbi9IdXViLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gWW91IGFyZSBsYXJnZWx5IGFz c3VtaW5nIHNvbWUgZm9ybSBvZiBwZWVyaW5nIChzaW5nbGUNCj4gcGFydGl0aW9uZWQNCj4gPiA+ ID4gbGF5ZXIgbmV0d29yaykNCj4gPiA+ID4gPiBoZXJlLi4uYW5kIHRoYXQgbW9kZWwgd2lsbCBn ZW5lcmF0ZSBhIHdob2xlIHJhZnQgb2YgcHJvYmxlbXMNCj4gZm9yDQo+ID4gPiA+IG9wZXJhdG9y cyBJTU8uDQo+ID4gPiA+ID4gQSBtb3JlIGltcG9ydGFudCBtb2RlbCBmb3IgYSBjby1wcyB0cmFu c3BvcnQgbmV0d29yayBpcw0KPiA+ID4gPiBjbGllbnQvc2VydmVyLiAgQW5kIG5vdw0KPiA+ID4g PiA+IG5vdCBvbmx5IGhhdmUgd2UgdGhlIHVzdWFsIGludHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0 eSB0byBkZWFsDQo+ID4gd2l0aA0KPiA+ID4gPiBidXQgd2UgYWxzbw0KPiA+ID4gPiA+IGhhdmUg aW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5Li4uYW5kIHRoaXMgbWVhbnMgZWFjaA0KPiBvcGVy YXRpbmcNCj4gPiA+ID4gcGFydHkgbXVzdA0KPiA+ID4gPiA+IHVuZGVyc3RhbmQgdGhlIE9BTSBm b3JtYXRzIChhbmQgQ1YgSURzKSBvZiBlYWNoIG90aGVyIGFueXdheS4uLg0KPiA+IG5vdA0KPiA+ ID4gPiBzaW1wbHkgdG8NCj4gPiA+ID4gPiBkZXRlY3QgdGhlcmUgaXMgYSBtaXNjb25uZWN0aXZp dHkgcHJvYmxlbXMgYnV0IGFsc28gdG8gaWRlbnRpZnkNCj4gPiA+IHdoaWNoDQo+ID4gPiA+IG90 aGVyIHBhcnRpZXMNCj4gPiA+ID4gPiBhcmUgaW52b2x2ZWQuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiByZWdhcmRzLCBOZWlsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCVCBEZXNpZ24NCj4gPiA+ID4g PiBUaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmls ZWdlZCBvcg0KPiA+ID4gPiBjb25maWRlbnRpYWwuDQo+ID4gPiA+ID4gSXQncyBtZWFudCBvbmx5 IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmDQo+ID4gPiA+ IHlvdSdyZSBub3QgdGhlDQo+ID4gPiA+ID4gaW50ZW5kZWQNCj4gPiA+ID4gPiByZWNpcGllbnQs IG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcNCj4g PiA+IHRoaXMNCj4gPiA+ID4gaW5mb3JtYXRpb24NCj4gPiA+ID4gPiBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlDQo+IGxldA0KPiA+ ID4gbWUNCj4gPiA+ID4ga25vdw0KPiA+ID4gPiA+IGltbWVkaWF0ZWx5DQo+ID4gPiA+ID4gb24g dGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4gPiA+ID4gPiBXZSBtb25pdG9y IG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KPiA+ID4gPiA+ IEJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ID4gPiA+IFJlZ2lzdGVyZWQgb2Zm aWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4gPiA+ID4gPiBSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgbm86IDE4MDAwMDANCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBG cm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uDQo+ID4gPiA+IEJlaGFsZiBPZg0KPiA+ID4gPiA+ID4gSHV1YiB2YW4gSGVsdm9vcnQNCj4g PiA+ID4gPiA+IFNlbnQ6IDIyIE1heSAyMDExIDE5OjE1DQo+ID4gPiA+ID4gPiBUbzogbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUmU6IFttcGxzXSBSOiBSZTogTWl4aW5nIElD QyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLQ0KPiBUUA0KPiA+ID4gPiA+ID4gSWRlbnRpZmllcnM/ DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSGkgQWRyaWFuLA0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IFNlZSBteSByZXNwb25zZSBpbi1saW5lIFtodmhdDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiBXZSBoYXZlIGFscmVhZHkgYmVlbiByb3VuZCB0aGlzIGxvb3Agb24gdGhpcyBsaXN0 IG9uY2UuDQo+ID4gPiA+ID4gPiA+IFdhbnQgdG8gZG8gaXQgYWdhaW4/DQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gW2h2aF0gSWYgaXQgaGVscHMgdG8gZ2V0IHRvIHRoZSBmb2NhbCBwb2ludCwg d2h5IG5vdC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEFzIEh1dWIgc2FpZCwgdGhpcyBp cyBhYm91dCBpZGVudGlmaWVycywgbm90IE9BTS4gSG93ZXZlciwNCj4gPiB0aGUNCj4gPiA+ID4g bW9kZWwNCj4gPiA+ID4gPiA+IGZvciBPQU0NCj4gPiA+ID4gPiA+ID4gaW50ZXJ3b3JraW5nIHNo b3dzICJsYXllcmluZyIgbm90IGdhdGV3YXlpbmcsIGFuZCBjZXJ0YWlubHkNCj4gPiBub3QNCj4g PiA+ID4gPiA+IG1peGluZy4gVGhhdCBpcywNCj4gPiA+ID4gPiA+ID4gb25lIGVuZCBvZiB0aGUg ZTJlIHBhdGggbXVzdCBiZSBjYXBhYmxlIG9mIG9wZXJhdGluZyBib3RoDQo+ID4gPiA+IHN5c3Rl bXMsDQo+ID4gPiA+ID4gPiBidXQgdGhlIG90aGVyDQo+ID4gPiA+ID4gPiA+IGRvZXMgbm90IG5l ZWQgdG8uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW2h2aF0gT0sgaWYgeW91IG1lYW4gIk9B TSB0b29sc2V0cyIgYnkgInN5c3RlbXMiDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUbyBl eHRlbmQgdGhpcyBtb2RlbCB0byBpZGVudGlmaWVycyBtZWFucyB0aGF0IG9uZSBlbmQgb2YNCj4g dGhlDQo+ID4gPiBlMmUNCj4gPiA+ID4gPiA+IHBhdGggbXVzdA0KPiA+ID4gPiA+ID4gPiBzdXBw b3J0IGJvdGggaWRlbnRpZmllciBmb3JtYXRzIGFuZCB0aGUgb3RoZXIgZG9lcyBub3QgbmVlZA0K PiA+IHRvLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFtodmhdIHRvIGJlIG1vcmUgc3BlY2lm aWMgdGhlIG9yaWdpbmF0aW5nIGVuZCBvZiBhbiBlMmUgcGF0aA0KPiA+IG11c3QNCj4gPiA+ID4g PiA+IGJlIGFibGUgdG8gc3VwcG9ydCBvbmUgb2YgdGhlIHBvc3NpYmxlIGlkZW50aWZpZXIgZm9y bWF0cywNCj4gPiA+IG5vcm1hbGx5DQo+ID4gPiA+ID4gPiB0aGUgaWRlbnRpZmllciBmb3JtYXQg b2YgdGhlIGxvY2FsIG9wZXJhdG9yLiBUaGUgdGVybWluYXRpbmcNCj4gPiBlbmQNCj4gPiA+ID4g YW5kDQo+ID4gPiA+ID4gPiB0aGUgaW50ZXJtZWRpYXRlIHBvaW50cyBvZiBhbiBlMmUgcGF0aCBt dXN0IGJlIGFibGUgdG8gdmVyaWZ5DQo+ID4gdGhlDQo+ID4gPiA+ID4gPiBmb3JtYXQgaW5zZXJ0 ZWQgYXQgdGhlIG9yaWdpbiBpbmRlcGVuZGVudCBvZiB0aGUgbG9jYWxseSB1c2VkDQo+ID4gPiA+ ID4gPiBpZGVudGlmaWVyDQo+ID4gPiA+ID4gPiBmb3JtYXQuIFRoaXMgbWVhbnMgdGhhdCBpdCBt dXN0IGJlIHBvc3NpYmxlIHRvIHN1cHBvcnQNCj4gPiBkaWZmZXJlbnQNCj4gPiA+ID4gPiA+IGlk ZW50aWZpZXIgZm9ybWF0cyBpbiB0aGUgQS0tPlogYW5zIFotLT5BIGRpcmVjdGlvbiBvZiBhbiBl MmUNCj4gPiA+IHBhdGguDQo+ID4gPiA+ID4gPiBJLmUuIG1peGluZyBvZiBpZGVudGlmaWVyIGZv cm1hdHMgbXVzdCBiZSBzdXBwb3J0ZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGlz IGJlY29tZXMgcGFydGljdWxhcmx5IGltcG9ydGFudCB0byB0aGUgdHJhbnNpdCBub2Rlcw0KPiB0 aGF0DQo+ID4gPiBtYXkNCj4gPiA+ID4gPiA+IGhhdmUgdG8NCj4gPiA+ID4gPiA+ID4gaW5zcGVj dCB0aGUgaWRlbnRpZmllcnMuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW2h2aF0gdGhlIGlu c3BlY3Rpb24gd2lsbCBjb25zaXN0IG9mIGNvbXBhcmluZyBhIHJlY2VpdmVkDQo+IHZhbHVlDQo+ ID4gPiA+ID4gPiB3aXRoIGFuIGV4cGVjdGVkIHZhbHVlIHdoaWNoIGNhbiBoYXZlIGFueSBmb3Jt YXQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBOb25lIG9mIHRoaXMgaXMgbmV3IG9yIHNw ZWNpZmljIHRvIE1QTFMtVFAuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW2h2aF0gSSBhZ3Jl ZSwgbWl4aW5nIG9mIGlkZW50aWZpZXIgZm9ybWF0cyBpdCBub3QgcmVzdHJpY3RlZA0KPiA+IHRv DQo+ID4gPiA+ID4gPiBNUExTLVRQLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFJlZ2FyZHMs IEh1dWIuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiA+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCj4gPiBPbg0KPiA+ID4gPiBCZWhhbGYNCj4gPiA+ID4g PiA+IE9mDQo+ID4gPiA+ID4gPiA+PiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCj4gPiA+ ID4gPiA+ID4+IFNlbnQ6IDE4IE1heSAyMDExIDIyOjI1DQo+ID4gPiA+ID4gPiA+PiBUbzogbG9h QHBpLm51OyBtcGxzQGlldGYub3JnOyBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24NCj4gPiA+ID4g PiA+ID4+IFN1YmplY3Q6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBp biBNUExTLQ0KPiBUUA0KPiA+ID4gPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4gPiA+Pg0K PiA+ID4gPiA+ID4gPj4gQXBwZW5kaXggSUkgb2YgWS4xNzMxIHByb3ZpZGVzIGEgZ29vZCBleGFt cGxlIGFib3V0IGhvdw0KPiA+IGludGVyLQ0KPiA+ID4gPiBkb21haW4NCj4gPiA+ID4gPiA+ID4+ IGNvbm5lY3Rpdml0eSB3aXRoIGUyZSBPQU0gY2FuIGJlIHByb3ZpZGVkIHVzaW5nIHRyYW5zcG9y dC0NCj4gPiA+ID4gb3JpZW50ZWQNCj4gPiA+ID4gPiA+IE9BTQ0KPiA+ID4gPiA+ID4gPj4gZnVu Y3Rpb25zLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+IFlvdSBjYW4gZG93bmxvYWQg dGhlIGxhdGVzdCB2ZXJzaW9uIG9mIFkuMTczMSAodGhlIHBkcg0KPiA+IHZlcnNpb24NCj4gPiA+ ID4gaXMNCj4gPiA+ID4gPiA+IGZvciBmcmVlKSBhdA0KPiA+ID4gPiA+ID4gPj4gdGhlIGZvbGxv d2luZyBVUkw6DQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gaHR0cDovL3d3dy5pdHUu aW50L3JlYy9ULVJFQy1ZLjE3MzEvZW4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBJ dCBpcyBhIHBpdHkgdGhhdCB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlDQo+IGlkZW50 aWZpZXINCj4gPiA+ID4gZHJhZnQsDQo+ID4gPiA+ID4gPiBNUExTLVRQIGlzDQo+ID4gPiA+ID4g PiA+PiBub3QgY2FwYWJsZSB0byBzdXBwb3J0IHN1Y2ggYSBuZXR3b3JrIHNjZW5hcmlvLg0KPiA+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+PiAtLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0N Cj4gPiA+ID4gPiA+ID4+PiBEYTogbG9hQHBpLm51DQo+ID4gPiA+ID4gPiA+Pj4gRGF0YTogNC1t YWctMjAxMSA4LjAwDQo+ID4gPiA+ID4gPiA+Pj4gQTo8bXBsc0BpZXRmLm9yZz4sDQo+ID4gPiA+ ID4gPiA+PiAiTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIjxNYWxjb2xtLkJFVFRTQHp0ZS5jb20u Y24+DQo+ID4gPiA+ID4gPiA+Pj4gT2dnOiBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2Jh bC1JRHMgaW4gTVBMUy1UUA0KPiA+ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4gPiA+ID4+Pg0K PiA+ID4gPiA+ID4gPj4+IE1hbGNvbG0sDQo+ID4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+ID4+ PiBhcmUgeW91IHNheWluZyB0aGF0IG9wZXJhdG9ycyB0b2RheSBhbGxvdyBPQU0gdG8gY29udHJv bA0KPiA+IG5vZGUNCj4gPiA+ID4gKE1JUHMNCj4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4g Pj4+IE1FUHMpIG9uIGVhY2ggb3RoZXJzIG5ldHdvcmtzPw0KPiA+ID4gPiA+ID4gPj4+DQo+ID4g PiA+ID4gPiA+Pj4gRG8gd2UgaGF2ZSBhbiBvcGVyYXRvciB0aGF0IGNhbiB2ZXJpZnkgdGhpcz8N Cj4gPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4gPj4+IC9Mb2ENCj4gPiA+ID4gPiA+ID4+Pg0K PiA+ID4gPiA+ID4gPj4+IE9uIDIwMTEtMDUtMDMgMjI6NDQsIE1hbGNvbG0uQkVUVFNAenRlLmNv bS5jbiB3cm90ZToNCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gQWxsLA0KPiA+ ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+PiBJIHNoYXJlIHlvdXIgY29uY2VybnMgYW5k IGRvdWJ0cyBhYm91dCBhIG11bHRpIGNhcnJpZXINCj4gPiA+IGNvbnRyb2wNCj4gPiA+ID4gPiA+ IHBsYW5lLg0KPiA+ID4gPiA+ID4gPj4+PiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgaXQgaXMgZXNz ZW50aWFsIHRoYXQgYSB0cmFuc3BvcnQNCj4gPiA+IG5ldHdvcmsNCj4gPiA+ID4gPiA+IHN1cHBv cnRzDQo+ID4gPiA+ID4gPiA+Pj4+IG11bHRpIGNhcnJpZXIgZGF0YSBwbGFuZSBpbnRlcmNvbm5l Y3Rpb24gd2l0aCBlbmQgdG8gZW5kDQo+ID4gPiBPQU0uDQo+ID4gPiA+IEluDQo+ID4gPiA+ID4g PiB0b2RheSdzDQo+ID4gPiA+ID4gPiA+Pj4+IHRyYW5zcG9ydCBuZXR3b3JrIHRoaXMgaW50ZXJj b25uZWN0aW9uIGlzIHN1cHBvcnRlZCBieQ0KPiBTREgNCj4gPiA+IGFuZA0KPiA+ID4gPiA+ID4g T1ROLiBUaGUNCj4gPiA+ID4gPiA+ID4+Pj4gb2JqZWN0aXZlIGZvciBNUExTLVRQIGlzIHRvIGFs bG93IGZvciBwYWNrZXQgYmFzZWQNCj4gPiA+ID4gaW50ZXJjb25uZWN0aW9uDQo+ID4gPiA+ID4g PiBhcw0KPiA+ID4gPiA+ID4gPj4gd2VsbC4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ ID4+Pj4gUmVnYXJkcywNCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gTWFsY29s bQ0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pg0K PiA+ID4gPiA+ID4gPj4+PiAqR2VvcmdlIFN3YWxsb3c8c3dhbGxvd0BjaXNjby5jb20+Kg0KPiA+ ID4gPiA+ID4gPj4+PiBTZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gMDMvMDUvMjAxMSAxMTowOSBBTQ0KPiA+ID4gPiA+ID4g Pj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+PiBUbw0KPiA+ID4gPiA+ID4g Pj4+PiAgICAiQW5kcmV3IEcuDQo+ID4gPiA+IE1hbGlzIjxhZ21hbGlzQGdtYWlsLmNvbT4sPG5l aWwuMi5oYXJyaXNvbkBidC5jb20+DQo+ID4gPiA+ID4gPiA+Pj4+IGNjDQo+ID4gPiA+ID4gPiA+ Pj4+ICAgIG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4+Pj4gU3ViamVjdA0KPiA+ID4gPiA+ ID4gPj4+PiAgICBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1U UA0KPiA+ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+ Pj4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4N Cj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4g PiA+ID4gPiA+ID4+Pj4gQW5keSAtDQo+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+ ICAgPiAgU3VjaA0KPiA+ID4gPiA+ID4gPj4+PiAgID4gIGFuIEUtTk5JIGRlZmluaXRpb24gZG9l cyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQDQo+ID4gPiA+IChzb21ldGhpbmcNCj4gPiA+ID4g PiA+IGVsc2UgdG8NCj4gPiA+ID4gPiA+ID4+Pj4gICA+ICBwdXQgb24gdGhlIHRvLWRvIGxpc3Qp LiBUaGlzIEUtTk5JIHdvdWxkIGFsc28NCj4gaW5jbHVkZQ0KPiA+ID4gPiBzaW1pbGFyDQo+ID4g PiA+ID4gPiA+Pj4+ICAgPiAgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9uIGZvciBNUy1Q V3MsIHRvDQo+IGFuc3dlcg0KPiA+IGFuDQo+ID4gPiA+ID4gPiBlYXJsaWVyDQo+ID4gPiA+ID4g PiA+Pj4+ICAgPiAgcXVlc3Rpb24gZnJvbSBFcm1pbmlvIHRoYXQgSSBzYXcgb24gdGhlIGxpc3Qu DQo+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+IFlvdSBhcmUgcXVpdGUgY29ycmVj dCBoZXJlISBJIHRoaW5rIG11Y2ggb2YgdGhpcyBkZWJhdGUNCj4gPiA+ID4gc3Vycm91bmRzDQo+ ID4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiA+PiBwcm9ibGVtDQo+ID4gPiA+ID4gPiA+Pj4+IHRo YXQgaXMgeWV0IHRvIGJlIHNvbHZlZC4gU28gdGhlcmUgYXJlIGFyZ3VtZW50cyBmb3INCj4gPiBw aWVjZXMNCj4gPiA+IG9mDQo+ID4gPiA+IGENCj4gPiA+ID4gPiA+IHNvbHV0aW9uDQo+ID4gPiA+ ID4gPiA+Pj4+IHdpdGhvdXQgYW5kIG92ZXJhbGwgYXJjaGl0ZWN0dXJlLg0KPiA+ID4gPiA+ID4g Pj4+Pg0KPiA+ID4gPiA+ID4gPj4+PiBCYXNlZCBvbiBhbGwgdGhhdCBJIGFtIHNlZWluZyBteSBp bmNsaW5hdGlvbiBpcyB0byBOT1QNCj4gc2F5DQo+ID4gPiA+IHRoYXQgd2UNCj4gPiA+ID4gPiA+ ID4+IGRpc2FsbG93DQo+ID4gPiA+ID4gPiA+Pj4+IG1peGVkIGlkZW50aWZpZXJzLCBidXQgdG8g c2F5IHRoYXQgdGhleSBhcmUgZm9yIGZ1dHVyZQ0KPiA+ID4gc3R1ZHkuDQo+ID4gPiA+ID4gPiA+ Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+IC4uLkdlb3JnZQ0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4g PiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPj4+PiBPbiA1LzMvMTEgODozOCBBTSwgIkFuZHJldyBHLiBN YWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPj4+ Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4gIE5laWwsDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ ID4gPiA+ID4gPj4+PiAgID4gIFRvIHlvdXIgY2FzZSAxLCB3ZSdyZSBpbiBjb21wbGV0ZSBhZ3Jl ZW1lbnQuIFdlDQo+IChWWikNCj4gPiA+ID4gZG9uJ3QNCj4gPiA+ID4gPiA+IHNlZSBhdA0KPiA+ ID4gPiA+ID4gPj4+PiAgID4gIGxlYXN0IGEgc2hvcnQtdGVybSBuZWVkIGZvciBwZWVyLWxheWVy DQo+IGludGVyd29ya2luZywNCj4gPiA+ID4gZ2l2ZW4NCj4gPiA+ID4gPiA+IHdoZXJlIHdlDQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPiAgaW50ZW5kIHRvIGRlcGxveSBNUExTLVRQIGluIG91ciBpbmZy YXN0cnVjdHVyZSAoYXMNCj4gYW4NCj4gPiA+ID4gPiA+IGludGVybmFsIHNlcnZlcg0KPiA+ID4g PiA+ID4gPj4+PiAgID4gIGxheWVyIGluIHRoZSB0cmFuc3BvcnQgY29yZSkuIElmIHBlZXIgbGF5 ZXINCj4gPiA+IGludGVyd29ya2luZw0KPiA+ID4gPiBldmVyDQo+ID4gPiA+ID4gPiBiZWNvbWVz DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgYSBuZWNlc3NpdHksIHRoZW4gb2J2aW91c2x5IHdlJ2xs IG5lZWQgYSB3ZWxsLQ0KPiBkZWZpbmVkDQo+ID4gPiBFLQ0KPiA+ID4gPiBOTkkNCj4gPiA+ID4g PiA+IHdoaWNoDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgd291bGQgaW5jbHVkZSBMU1AgaWRlbnRp ZmllciBtYXBwaW5nL3RyYW5zbGF0aW9uIGF0DQo+ID4gdGhlDQo+ID4gPiA+ID4gPiBib3VuZGFy eSwgZm9yDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgTFNQIHByb3Zpc2lvbmluZyAod2hldGhlciBz dGF0aWMgb3IgZHluYW1pYykgYW5kDQo+IGVuZC0NCj4gPiA+IHRvLQ0KPiA+ID4gPiBlbmQNCj4g PiA+ID4gPiA+IE9BTS4gU3VjaA0KPiA+ID4gPiA+ID4gPj4+PiAgID4gIGFuIEUtTk5JIGRlZmlu aXRpb24gZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExTLVRQDQo+ID4gPiA+IChzb21ldGhpbmcN Cj4gPiA+ID4gPiA+IGVsc2UgdG8NCj4gPiA+ID4gPiA+ID4+Pj4gICA+ICBwdXQgb24gdGhlIHRv LWRvIGxpc3QpLiBUaGlzIEUtTk5JIHdvdWxkIGFsc28NCj4gaW5jbHVkZQ0KPiA+ID4gPiBzaW1p bGFyDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9u IGZvciBNUy1QV3MsIHRvDQo+IGFuc3dlcg0KPiA+IGFuDQo+ID4gPiA+ID4gPiBlYXJsaWVyDQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPiAgcXVlc3Rpb24gZnJvbSBFcm1pbmlvIHRoYXQgSSBzYXcgb24g dGhlIGxpc3QuDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+ID4gPj4+PiAgID4gIEkg YWxzbyBhZ3JlZSB0aGF0IGJvdGggaW50cmEtbGF5ZXIgYW5kIGludGVyLWxheWVyDQo+ID4gbWlz LQ0KPiA+ID4gPiA+ID4gY29ubmVjdGl2aXR5DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgZGV0ZWN0 aW9uIGFuZCBhbWVsaW9yYXRpb24gYXJlIHJlcXVpcmVkLCBidXQgSSdtDQo+IG5vdA0KPiA+ID4g PiA+ID4gY29udmluY2VkIHRoYXQNCj4gPiA+ID4gPiA+ID4+Pj4gICA+ICB0aGUgYWxyZWFkeSBk ZWZpbmVkIG1lY2hhbmlzbXMgY2FuJ3QgZG8gdGhhdC4gRG8NCj4geW91DQo+ID4gPiBoYXZlDQo+ ID4gPiA+ID4gPiBzb21lDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgc3BlY2lmaWMgYW5hbHlzaXMg b24gdGhlIGludGVyLWxheWVyIGNhc2U/DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+ ID4gPj4+PiAgID4gIENoZWVycywNCj4gPiA+ID4gPiA+ID4+Pj4gICA+ICBBbmR5DQo+ID4gPiA+ ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+ID4gPj4+PiAgID4gIE9uIFR1ZSwgTWF5IDMsIDIwMTEg YXQgMzozNg0KPiA+IEFNLDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ID4gPiA+ID4gd3Jv dGU6DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIEhpIEFuZHksDQo+ID4gPiA+ID4gPiA+Pj4+ICAg Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgMiBwb2ludHM6DQo+ID4gPiA+ID4gPiA+Pj4+ICAg Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgMSBJIGFncmVlIHdpdGggeW91ciB2aWV3IG9mIG9u bHkgaGF2aW5nIGEgc2luZ2xlDQo+ID4gPiA+IGFkZHJlc3NpbmcNCj4gPiA+ID4gPiA+IHNjaGVt ZSBpbg0KPiA+ID4gPiA+ID4gPj4gYQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBzaW5nbGUgbGF5 ZXIgbmV0d29yayBzb2xlbHkgYmVsb25naW5nIHRvIG9uZQ0KPiBwYXJ0eS4NCj4gPiA+ID4gVGhv dWdoDQo+ID4gPiA+ID4gPiB5b3UgbWF5DQo+ID4gPiA+ID4gPiA+Pj4+IG5lZWQgdG8NCj4gPiA+ ID4gPiA+ID4+Pj4gICA+PiAgYmUgcmF0aGVyIGNhcmVmdWwgaWYgeW91IGFsc28gYWR2b2NhdGUg dGhhdCBvbmUNCj4gY2FuDQo+ID4gPiBhbHNvDQo+ID4gPiA+ID4gPiBoYXZlIHBlZXINCj4gPiA+ ID4gPiA+ID4+IGxheWVyDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGludGVyd29ya2luZyBiZXR3 ZWVuIGRpZmZlcmVudCBwYXJ0aWVzLCBpZSBFLU5OSXMNCj4gKEkNCj4gPiA+ID4gYmVsaWV2ZQ0K PiA+ID4gPiA+ID4gdGhpcyBpcw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBzb21ldGhpbmcgeW91 IG1heSBzdXBwb3J0LCBlZyBvbGQgTVBMU0YgY2FzZT8pLiBJbg0KPiA+ID4gc3VjaA0KPiA+ID4g PiBhDQo+ID4gPiA+ID4gPiBwZWVyDQo+ID4gPiA+ID4gPiA+Pj4+IGludGVyd29ya2luZw0KPiA+ ID4gPiA+ID4gPj4+PiAgID4+ICBjYXNlIGl0IHdvdWxkIHNlZW0gb25lIG11c3QgYWxsb3cgZGlm ZmVyZW50DQo+ID4gYWRkcmVzc2luZw0KPiA+ID4gPiA+ID4gc2NoZW1lcyAoYW5kDQo+ID4gPiA+ ID4gPiA+Pj4+IGluZGVlZA0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBhbnkgb3RoZXIgdmFyaWF0 aW9ucyBpbiBEUC9DUCBmdW5jdGlvbmFsDQo+IGNvbXBvbmVudHMpDQo+ID4gPiBpZg0KPiA+ID4g PiB0aGV5DQo+ID4gPiA+ID4gPiBleGlzdA0KPiA+ID4gPiA+ID4gPj4+PiBpbiB0aGUNCj4gPiA+ ID4gPiA+ID4+Pj4gICA+PiAgc3RhbmRhcmRzLg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4g PiA+ID4gPiA+Pj4+ICAgPj4gIE9mIGNvdXJzZSwgaGF2aW5nIGFuIEUtTk5JIGFuZCBwZWVyIGlu dGVyd29ya2luZw0KPiA+ID4gYmV0d2Vlbg0KPiA+ID4gPiA+ID4gZGlmZmVyZW50DQo+ID4gPiA+ ID4gPiA+Pj4+IHBhcnRpZXMgaW4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgYW55IG5vbi1UT1Mg bGF5ZXIgbmV0d29yayAobm90IGp1c3QgTVBMUykgaXMgbm90DQo+ID4gPiA+IHRlY2huaWNhbGx5 DQo+ID4gPiA+ID4gPiA+Pj4+IG5lY2Vzc2FyeSAodGhpcw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ ICBpcyB0cml2aWFsIHRvIHByb3ZlKSwgYW5kIHRoaXMgcHJvdmlkZXMgYSBzdHJvbmcNCj4gPiA+ ID4gYXJndW1lbnQNCj4gPiA+ID4gPiA+IGZvciBvbmx5DQo+ID4gPiA+ID4gPiA+Pj4+IGhhdmlu ZyBhDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIHNpbmdsZSBhZGRyZXNzaW5nIHNjaGVtZSBpbiBh IG5vbi1UT1MgbGF5ZXINCj4gbmV0d29yay4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4g PiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIDIgWW91IHNob3VsZCBhbHNv IGJlIGF3YXJlIHRoYXQgaW4gY2xpZW50L3NlcnZlcg0KPiA+ID4gPiA+ID4gaW50ZXJ3b3JraW5n IG9mIHRoZQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBjby1wcyBtb2RlIHVzaW5nIHZhcmlhYmxl IHNpemUgdHJhZmZpYyB1bml0cywgYW5kDQo+ID4gPiA+IHRoZXJlZm9yZQ0KPiA+ID4gPiA+ID4g Pj4+PiBzb21ldGhpbmcgcmF0aGVyDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGltcG9ydGFudCBm b3IgTVBMUy1UUCBpbiB0aGUgcm9sZSBvZiBhIHRyYW5zcG9ydA0KPiA+ID4gbmV0d29yaw0KPiA+ ID4gPiA+ID4gKEknbGwNCj4gPiA+ID4gPiA+ID4+Pj4gaWdub3JlIGlzc3Vlcw0KPiA+ID4gPiA+ ID4gPj4+PiAgID4+ICBvZiB0cmFuc3BhcmVuY3kgaGVyZSksIHRoZXJlIGNvdWxkIGJlIGludGVy LWxheWVyDQo+ID4gPiA+ID4gPiBtaXNjb25uZWN0aXZpdHkNCj4gPiA+ID4gPiA+ID4+Pj4gKEFz aWRlPT4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgVGhpcyBjYXNlIGNhbm5vdCBvY2N1ciBpbiB0 aGUgY28tY3MgbW9kZSkuIFRvDQo+IGRhdGUsDQo+ID4gPiA+IGhvd2V2ZXIsDQo+ID4gPiA+ID4g PiB3ZSBoYXZlDQo+ID4gPiA+ID4gPiA+Pj4+IG9ubHkNCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAg cmVhbGx5IGNvbnNpZGVyZWQgaW50cmEtbGF5ZXIgbWlzY29ubmVjdGl2aXR5LCBpZQ0KPiA+ID4g PiBiZXR3ZWVuDQo+ID4gPiA+ID4gPiBkaWZmZXJlbnQNCj4gPiA+ID4gPiA+ID4+IExTUHMNCj4g PiA+ID4gPiA+ID4+Pj4gICA+PiAgYmVsb25naW5nIHRvIHRoZSBzYW1lIHBhcnR5IChub3RlIHRo aXMgYWxzbw0KPiBpbmNsdWRlcw0KPiA+ID4gYWxsDQo+ID4gPiA+ID4gPiBjYXNlcyBvZg0KPiA+ ID4gPiA+ID4gPj4+PiBuZXN0ZWQgTFNQDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIHN1YmxheWVy IG1pc2Nvbm5lY3Rpdml0eSkuDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+ID4+ Pj4gICA+PiAgSW4gdGhlIGNhc2Ugb2YgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5IG9uZSBt YXkNCj4gPiA+ID4gcmVjZWl2ZQ0KPiA+ID4gPiA+ID4gdHJhZmZpYw0KPiA+ID4gPiA+ID4gPj4+ PiB1bml0cyBhbmQNCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgT0FNIG1lc3NhZ2VzIGZyb20gc29t ZSBvdGhlciBwYXJ0eSdzIGxheWVyDQo+IG5ldHdvcmsuDQo+ID4gPiBUaGUNCj4gPiA+ID4gT0FN DQo+ID4gPiA+ID4gPiA+PiBtZXNzYWdlcw0KPiA+ID4gPiA+ID4gPj4gbWF5DQo+ID4gPiA+ID4g PiA+Pj4+ICAgPj4gIGNvbWUgZnJvbSAoaSkgbmV0d29ya3MgdXNpbmcgZGlmZmVyZW50DQo+ID4g T0FNL2FkZHJlc3NpbmcNCj4gPiA+ID4gPiA+IHNvbHV0aW9ucyBvcg0KPiA+ID4gPiA+ID4gPj4g KGlpKQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBuZXR3b3JrcyB1c2luZyB0aGUgc2FtZSBPQU0v YWRkcmVzc2luZyBzb2x1dGlvbnMuDQo+IEluDQo+ID4gPiA+IGJvdGgNCj4gPiA+ID4gPiA+IGNh c2VzDQo+ID4gPiA+ID4gPiA+Pj4+IHRoZXJlIGFyZQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBk aWZmZXJlbnQgaXNzdWVzIHdydCBpbnRlci1sYXllciBtaXNjb25uZWN0aXZpdHkNCj4gb25lDQo+ ID4gPiBoYXMNCj4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+IGRlYWwNCj4gPiA+ID4gPiA+ID4+Pj4g d2l0aC4gSSdtDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIG5vdCBhd2FyZSB0aGF0IHRoZXNlIGNh c2VzIGhhdmUgYmVlbiBjb25zaWRlcmVkDQo+IHlldC4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0K PiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIEknZCBsaWtlIHRv IGhlYXIgeW91ciBjb21tZW50cyBvbiBib3RoIHRoZXNlDQo+IHBvaW50cywNCj4gPiA+IGJ1dA0K PiA+ID4gPiBpbg0KPiA+ID4gPiA+ID4gPj4+PiBwYXJ0aWN1bGFyIHRoZQ0KPiA+ID4gPiA+ID4g Pj4+PiAgID4+ICBmaXJzdCBvbmUuLi4uLmVzcGVjaWFsbHkgaWYgeW91IGFsc28gc3VwcG9ydCB0 aGUNCj4gPiA+IG5vdGlvbg0KPiA+ID4gPiBvZg0KPiA+ID4gPiA+ID4gRS1OTklzIGluDQo+ID4g PiA+ID4gPiA+Pj4+IE1QTFMtVFAsDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGFzIHRoZXJlIHNl ZW1zIHRvIGEgcG9zc2libGUgbG9naWNhbCBjb25mbGljdA0KPiBoZXJlLg0KPiA+ID4gPiA+ID4g Pj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIFRoYW5rcy4NCj4gPiA+ID4gPiA+ID4+ Pj4gICA+Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICByZWdhcmRzLCBOZWlsIEhhcnJpc29uDQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgQlQgRGVzaWduDQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgVGhpcyBlbWFpbCBj b250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlDQo+ID4gPiA+IHByaXZpbGVnZWQN Cj4gPiA+ID4gPiA+IG9yDQo+ID4gPiA+ID4gPiA+Pj4+IGNvbmZpZGVudGlhbC4NCj4gPiA+ID4g PiA+ID4+Pj4gICA+PiAgSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBl bnRpdHkNCj4gPiBuYW1lZA0KPiA+ID4gPiBhYm92ZS4NCj4gPiA+ID4gPiA+IElmDQo+ID4gPiA+ ID4gPiA+Pj4+IHlvdSdyZSBub3QNCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgdGhlIGludGVuZGVk DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3Npbmcs IGNvcHlpbmcsDQo+ID4gZGlzdHJpYnV0aW5nDQo+ID4gPiA+IG9yDQo+ID4gPiA+ID4gPiB1c2lu ZyB0aGlzDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGluZm9ybWF0aW9uDQo+ID4gPiA+ID4gPiA+ Pj4+ICAgPj4gIGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu DQo+ID4gZXJyb3IsDQo+ID4gPiA+ID4gPiBwbGVhc2UgbGV0IG1lDQo+ID4gPiA+ID4gPiA+Pj4+ IGtub3cNCj4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgaW1tZWRpYXRlbHkNCj4gPiA+ID4gPiA+ID4+ Pj4gICA+PiAgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4gPiA+ID4g PiA+ID4+Pj4gICA+PiAgV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29y ZCB5b3VyDQo+ID4gPiBlbWFpbHMuDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIEJyaXRpc2ggVGVs ZWNvbW11bmljYXRpb25zIHBsYw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBSZWdpc3RlcmVkIG9m ZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUENCj4gN0FKDQo+ID4gPiA+ID4gPiA+ Pj4+ICAgPj4gIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KPiA+ID4gPiA+ID4g Pj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy0NCj4gPiA+ID4gYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gPiA+IE9u IEJlaGFsZg0KPiA+ID4gPiA+ID4gPj4gT2YNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIEFuZHJl dyBHLiBNYWxpcw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgU2VudDogMDIgTWF5IDIwMTEgMjA6 NDgNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIFRvOiBHZW9yZ2UgU3dhbGxvdw0KPiA+ID4gPiA+ ID4gPj4+PiAgID4+PiAgQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4g IFN1YmplY3Q6IFJlOiBbbXBsc10gTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbg0KPiA+ID4g TVBMUy0NCj4gPiA+ID4gVFANCj4gPiA+ID4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPiA+ID4g Pj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgR2VvcmdlIGV0IGFsLA0KPiA+ID4g PiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgVmVyaXpvbiBkb2VzIG5v dCBoYXZlIGFueSByZXF1aXJlbWVudCBmb3IgbWl4ZWQNCj4gdXNlDQo+ID4gPiBvZg0KPiA+ID4g PiA+ID4gR2xvYmFsIElEcyBhbmQNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIElDQ3MuIFdlIGFy ZSBmaW5lIHdpdGggc3BlY2lmaWNhdGlvbnMgdGhhdA0KPiByZXF1aXJlDQo+ID4gPiBib3RoDQo+ ID4gPiA+ID4gPiBlbmRzIG9mIGFuDQo+ID4gPiA+ID4gPiA+PiBMU1ANCj4gPiA+ID4gPiA+ID4+ Pj4gICA+Pj4gIHRvIHVzZSBvbmUgb3IgdGhlIG90aGVyLg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgVGhhbmtzLA0KPiA+ID4gPiA+ID4gPj4+PiAgID4+ PiAgQW5keQ0KPiA+ID4gPiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAg T24gTW9uLCBBcHIgMjUsIDIwMTEgYXQgNToxNiBQTSwgR2VvcmdlDQo+ID4gPiA+ID4gPiBTd2Fs bG93PHN3YWxsb3dAY2lzY28uY29tPg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgd3JvdGU6DQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgQWxsIC0NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgTWFueSBvZiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJv bSB0aGUgSVRVIG9uDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgZHJhZnQtaWV0Zi1tcGxzLXRw LWlkZW50aWZpZXJzLTA0IGhhdmUgdG8gZG8NCj4gd2l0aA0KPiA+ID4gdGhlDQo+ID4gPiA+ID4g PiBHbG9iYWwgYW5kIElDQw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIGlkZW50aWZpZXJzLg0K PiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBUaGUgaWRl bnRpZmllcnMgZm9yIFR1bm5lbCwgTFNQLCBQVywgYW5kIE1FRw0KPiA+IGluY2x1ZGUNCj4gPiA+ ID4gPiA+IGZpZWxkcyB0bw0KPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgaWRlbnRpZnkgZWFjaA0K PiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIGVuZCBvZiBhbiBMU1AuIEN1cnJlbnRseSB0aGUgZHJh ZnQgYWxsb3dzIGENCj4gPiBUdW5uZWwsDQo+ID4gPiA+IExTUCwNCj4gPiA+ID4gPiA+IFBXLCBv ciBNRUcNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIHRvIHVzZQ0KPiA+ID4gPiA+ID4gPj4+PiAg ID4+Pj4gIGVpdGhlciB0aGUgR2xvYmFsLUlEIGZvciBib3RoIGVuZHMgb3Igb3IgdGhlIElDQw0K PiA+IGZvcg0KPiA+ID4gPiBib3RoDQo+ID4gPiA+ID4gPiBlbmRzLg0KPiA+ID4gPiA+ID4gPj4+ PiAgID4+PiAgTWl4ZWQgdXNlDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgaXMgbm90IHBlcm1p dHRlZC4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAg VGhlIElUVSBsaWFpc29uIHJlcXVlc3RzIHRoYXQgd2UgYWxsb3cgbWl4ZWQNCj4gdXNlLg0KPiA+ ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBUaGUgYXV0aG9y cyBvZiB0aGUgZHJhZnQgYXJlIHZlcnkgcmVsdWN0YW50IHRvDQo+IGRvDQo+ID4gPiA+IHRoaXMu DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIE9idGFp bmluZyBhbiBBUyBOdW1iZXIgKGZyb20gd2hpY2ggdGhlIEdsb2JhbC1JRA0KPiA+IGlzDQo+ID4g PiA+ID4gPiBkZXJpdmVkKSBpcyBhDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBmYWlybHkNCj4g PiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFsIHByb2NlZHVyZS4gTWFueSBvcmdhbml6YXRp b25zIGlmIG5vdA0KPiBtb3N0DQo+ID4gPiA+IGFscmVhZHkNCj4gPiA+ID4gPiA+IGhhdmUgQVMN Cj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIE51bWJlcnMuDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ PiAgU3VjaCBhbiBhZGRpdGlvbiB3aWxsIGFkZCBudW1lcm91cyBvYmplY3QNCj4gZm9ybWF0cywN Cj4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gdGVzdCBjYXNlcy4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+ Pj4+ICBUaGUgZXh0ZW50IGludGVyLXByb3ZpZGVyIE1QTFMtVFAgaXMgYXMgeWV0DQo+ID4gdW5r bm93bi4NCj4gPiA+ID4gSWYNCj4gPiA+ID4gPiA+IG1peGVkIG1vZGVzDQo+ID4gPiA+ID4gPiA+ Pj4+ICAgPj4+ICBvZiBJQ0MNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBhbmQgR2xvYmFsLUlE IGlkZW50aWZpY2F0aW9uIGlzIHJlcXVpcmVkLCB0aGV5DQo+IGNhbg0KPiA+ID4gYmUNCj4gPiA+ ID4gPiA+IGFkZGVkIGxhdGVyLg0KPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIEZvciBzaWduYWxl ZCBjb25uZWN0aW9ucywgdGhlcmUgaXMgbm8gcGxhbiB0bw0KPiA+IGFsbG93DQo+ID4gPiA+ID4g PiByb3V0aW5nIGJhc2VkIG9uDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBlaXRoZXINCj4gPiA+ ID4gPiA+ID4+Pj4gICA+Pj4+ICB0aGUgR2xvYmFsLUlEIG9yIElDQy4gVGhhdCB3b3VsZCBiZSBh IHJhZGljYWwNCj4gPiBjaGFuZ2UNCj4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+IGhvdyBJUA0KPiA+ ID4gPiA+ID4gPj4+PiAgID4+PiAgd29ya3MuDQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgSG93 ZXZlciBmb3IgSVAgcm91dGluZyB0byB3b3JrIChpbiBvcmRlciB0bw0KPiA+IGZvcndhcmQNCj4g PiA+ID4gdGhlDQo+ID4gPiA+ID4gPiBzaWduYWxpbmcNCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ ICBtZXNzYWdlcyksIHRoZSBwcm92aWRlcnMgaW52b2x2ZWQgd2lsbCBuZWVkIHRvDQo+IHJ1bg0K PiA+ID4gQkdQDQo+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gaGF2ZSBBUw0KPiA+ID4gPiA+ID4g Pj4+PiAgID4+PiAgbnVtYmVycy4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+ID4g PiA+Pj4+ICAgPj4+PiAgV2UgYXJlIGxvb2tpbmcgZm9yIGlucHV0L2NvbnNlbnN1cyBmcm9tIHRo ZSBXRy4NCj4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAg R2VvcmdlLCBFcmljLCYgIE1hdHRoZXcNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gLS0NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPiA+ID4gPiAqKioNCj4g PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg5oiR54ix5aSW54K55LiA5LiD5LiJ 5LiADQo+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+IG1wbHNA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBtcGxzQGll dGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo+ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG1wbHNAaWV0 Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From maarten.vissers@huawei.com Fri May 27 05:13: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 7BFA0E068F for ; Fri, 27 May 2011 05:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_81=0.6, 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 R7K7GubiCxQB for ; Fri, 27 May 2011 05:13:13 -0700 (PDT) Received: from lhrga02-in.huawei.com (lhrga02-in.huawei.com [195.33.106.143]) by ietfa.amsl.com (Postfix) with ESMTP id 56328E0679 for ; Fri, 27 May 2011 05:13:10 -0700 (PDT) Received: from huawei.com (lhrga02-in [172.18.7.45]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00KKGSLQUK@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 27 May 2011 13:13:03 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLU00CQFSLJRH@lhrga02-in.huawei.com> for mpls@ietf.org; Fri, 27 May 2011 13:13:02 +0100 (BST) Received: from LHREML402-HUB.china.huawei.com (10.201.5.31) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 27 May 2011 13:12:43 +0100 Received: from LHREML504-MBX.china.huawei.com ([fe80::e9b4:763:77f9:dcea]) by LHREML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 27 May 2011 13:12:47 +0100 Date: Fri, 27 May 2011 12:12:46 +0000 From: Maarten vissers In-reply-to: <6D3D47CB84BDE349BC23BF1C94E316E440266EB8C8@EMV62-UKRD.domain1.systemhost.net> X-Originating-IP: [10.202.112.102] To: "neil.2.harrison@bt.com" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-GB, en-US Thread-topic: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Thread-index: AQHMFwUCImDxJu5RDUehAq6m8HGoSpSZGZqAgAAWfwCABAkagIAAFv0QgAAECTCAACSAsIADBE4ggAAiNgA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7356234.1482501305753899416.JavaMail.defaultUser@defaultHost> <073e01cc1704$e22a1ae0$a67e50a0$@olddog.co.uk> <4DD952B5.4040405@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E44025757701@EMV62-UKRD.domain1.systemhost.net> <040301cc1abc$016f0a90$044d1fb0$@olddog.co.uk> <6D3D47CB84BDE349BC23BF1C94E316E440264057E4@EMV62-UKRD.domain1.systemhost.net> <6D3D47CB84BDE349BC23BF1C94E316E440266EB8C8@EMV62-UKRD.domain1.systemhost.net> Subject: Re: [mpls] R: Re: 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: Fri, 27 May 2011 12:13:15 -0000 TmVpbCwNCg0KTE8gT0RVIGFjY2VzcyBwb2ludHMgYXJlIG9uIFVOSS1OIHBvcnQgY2FyZHMsIEhP IE9EVSBOTkkgYWNjZXNzIHBvaW50cyBhcmUgdHlwaWNhbGx5IG9uIE5OSSBwb3J0IGNhcmRzLCBi dXQgY291bGQgYWxzbyBiZSBvbiBVTkktTiBwb3J0IGNhcmRzLCBTSE8gT0RVIE5OSSBhY2Nlc3Mg cG9pbnRzIGFyZSBvbiBOTkkgcG9ydCBjYXJkcy4NCg0KUmVzb3VyY2VzIGZvciBlYWNoIE9EVSBp biB0aGUgT0RVb3Zlck9EVW92ZXJPRFVvdmVyLi4uIGFyZSBhbGxvY2F0ZWQsIG5vdCBqdXN0IHJl c2VydmVkLiBTbyBkb24ndCBiZSB3b3JyaWVkIGhlcmUuDQoNCk9EVSBjb25uZWN0aW9uIG1hbmFn ZW1lbnQgdHJlYXRzIGFsbCBPRFUgY29ubmVjdGlvbnMgdGhlIHNhbWUuIE9EVSBjb25uZWN0aW9u IHNldCB1cCBwcm9jZXNzIGRvZXMgbm90IGNhcmUgYXQgd2hhdCBsZXZlbCB0aGUgT0RVIGNvbm5l Y3Rpb24gaXMgb3BlcmF0aW5nLiBCdXQgYmUgYXdhcmUgdGhhdCBub3QgYWxsIE9EVSBsaW5rcyB3 aWxsIGJlIGFibGUgdG8gc3VwcG9ydCBhIHNwZWNpZmljIE9EVSBiYW5kd2lkdGguDQoNClJlZ2Fy ZHMsDQpNYWFydGVuDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IG5laWwuMi5oYXJyaXNvbkBidC5jb20gW21haWx0bzpuZWlsLjIuaGFycmlzb25AYnQuY29tXQ0K PiBTZW50OiAyNyBNYXkgMjAxMSAxMjoxMw0KPiBUbzogTWFhcnRlbiB2aXNzZXJzOyBhZHJpYW5A b2xkZG9nLmNvLnVrOyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gUjogUmU6 IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiBJZGVudGlmaWVycz8NCj4g DQo+IFNvcnJ5IGJpdCBsYXRlIHJlc3BvbmRpbmcgTWFhcnRlbi4uLi53YW50ZWQgdG8gY2hlY2sg dGhpcyBvdXQgd2l0aCBUb255DQo+IEZsYXZpbiBhbmQgQWxhbiBNY0d1aXJlIGhlcmUgZmlyc3Qu ICBTZWVtcyB3ZSBjYW4gaGF2ZSB3aGF0IGFwcGVhcnMgdG8NCj4gYmUgWG92ZXJYIGR1ZSB0byBy ZWN1cnNpdmVseSBuZXN0aW5nIGEgZGlnaXRhbCB3cmFwcGVyIHNjaGVtZS4gIE5vdA0KPiBzdXJl IHdoYXQgcmVjdXJzaW9uIGxpbWl0cyBhcHBseSBoZXJlIHdydCByZXNvdXJjZSAoQ0YgPD1NVFUg aW4gY28tcHMNCj4gcGt0IGNhc2UpIGFuZCB3ZSBzaG91bGQgYmUgY2FyZWZ1bCBub3QgdG8gY29t cHJvbWlzZSB0aGUgc3Ryb25nDQo+IHJlc291cmNlIGFjY291bnRpbmcvbWFuYWdlbWVudCBjYXBh YmlsaXR5IHRoYXQgYSBjby1jcyBtb2RlIG5ldHdvcmsNCj4gc2hvdWxkIGJlIGFibGUgdG8gZGVs aXZlciB0byBpdHMgY2xpZW50cy4gIFNvIG1heWJlIChob3BlZnVsbHk/KSB0aGUNCj4gbWFqb3Ig aXNzdWUgaGVyZSBpcyBvbmUgb2YgZW5zdXJpbmcgdGhhdCBlYWNoIGxheWVyIGNhbiBiZSB1bmlx dWVseQ0KPiBpZGVudGlmaWVkIHdydCBhY2Nlc3MgcG9pbnRzLg0KPiANCj4gcmVnYXJkcywgTmVp bA0KPiANCj4gVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLg0KPiBJdCdzIG1lYW50IG9ubHkgZm9yIHRo ZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlDQo+IG5vdCB0 aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywg ZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMNCj4gaW5mb3JtYXRpb24NCj4gaXMgcHJvaGliaXRl ZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUN Cj4ga25vdyBpbW1lZGlhdGVseQ0KPiBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsg eW91Lg0KPiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIg ZW1haWxzLg0KPiBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCj4gUmVnaXN0ZXJlZCBv ZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KPiBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm86IDE4MDAwMDANCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IE1hYXJ0ZW4gdmlzc2VycyBbbWFpbHRvOm1hYXJ0ZW4udmlzc2Vy c0BodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDI1IE1heSAyMDExIDEzOjA0DQo+ID4gVG86IEhhcnJp c29uLE4sTmVpbCxES1E3IFI7IGFkcmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSRTogW21wbHNdIFI6IFJlOiBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzIGlu IE1QTFMtVFANCj4gPiBJZGVudGlmaWVycz8NCj4gPg0KPiA+IE5laWwsDQo+ID4NCj4gPiBGWUku IFRoZSBjby1jcyBPRFUgbGF5ZXJzIGhhdmUgdGhlIHNhbWUgc3RhY2tpbmcgY2FwYWJpbGl0eSBh cyBNUExTLQ0KPiBUUA0KPiA+IExTUCBhbmQgRVRIIGxheWVyczsgaS5lLiBYb3ZlclggaXMgc3Vw cG9ydGVkIGFuZCBkZXBsb3llZC4gQXMgc3VjaCBpbg0KPiA+IE9UTiB3ZSBjYW4gaGF2ZSBtaXNj b25uZWN0aW9ucyBiZXR3ZWVuIGUuZy4gTE8gT0RVMiBhbmQgSE8gT0RVMg0KPiA+IGNvbm5lY3Rp b25zLiBUaGUgdHJhZmZpYyB1bml0cyBpbiBPVE4gYXJlIHZhcmlhYmxlIHNpemVkIHRyYWZmaWMN Cj4gdW5pdHMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IE1hYXJ0ZW4NCj4gPg0KPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG5laWwuMi5oYXJyaXNvbkBidC5j b20gW21haWx0bzpuZWlsLjIuaGFycmlzb25AYnQuY29tXQ0KPiA+ID4gU2VudDogMjUgTWF5IDIw MTEgMTM6MjMNCj4gPiA+IFRvOiBNYWFydGVuIHZpc3NlcnM7IGFkcmlhbkBvbGRkb2cuY28udWs7 IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbbXBsc10gUjogUmU6IE1peGluZyBJ Q0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy1UUA0KPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPg0K PiA+ID4gVGhlcmUgaXMgYW4gaW1wb3J0YW50IGRpZmZlcmVuY2UgaGVyZS4gIFdlIGNhbm5vdCBo YXZlICppbnRlcioNCj4gbGF5ZXINCj4gPiA+IG1pc2Nvbm5lY3Rpdml0eSBpbiBjby1jcyBtb2Rl IG5ldHdvcmtzLi4udGhpcyBmb2xsb3dzIGRpcmVjdGx5IGZyb20NCj4gPiBob3cNCj4gPiA+IHRo ZSBsYWJlbGxpbmcgb2YgcmVzb3VyY2UgcGFydGl0aW9ucyB3b3JrcyBpbiBlYWNoIG9mIHRoZSAz IG1vZGVzLg0KPiA+IFNvDQo+ID4gPiBpZiB0aGVyZSBpcyBhIG5lZWQgdG8gcHJvY2VzcyBkaWZm ZXJlbnQgQ1YgJ1NBJyBJRHMgaGVyZSB0aGVuIHRoYXQNCj4gaXMNCj4gPiA+IGRvd24gdG8gYSBz ZWxmLWluZmxpY3RlZCBwZWVyaW5nIGNhc2Ugb2YgZm9yY2luZyBtb3JlIGZ1bmN0aW9uYWxpdHkN Cj4gPiA+IHRoYW4gYSB0cnVlIEJPUy1waHlzaWNhbCBiaXQgaW50ZXJjb25uZWN0IGNhc2UgcmVx dWlyZXMuDQo+ID4gPg0KPiA+ID4gSG93ZXZlciwgd2hlbiB3ZSBoYXZlIGEgdmFyaWFibGUgc2l6 ZSB0cmFmZmljIHVuaXQgaW4gdGhlIGNvLXBzDQo+IG1vZGUsDQo+ID4gPiBhcyB3ZSBoYXZlIHdp dGggTVBMUy1UUCwgdGhlbiB3ZSBjYW4gaGF2ZSBzb21ldGhpbmcgdGhhdCBsb29rcyBsaWtlDQo+ ID4gPiBYb3ZlclggKGFzIG1hbnkgdGltZXMgYXMgb25lIGxpa2VzIC0gc3ViamVjdCB0byA8TVRV KS4gIFNvLCBpbg0KPiA+IGFkZGl0aW9uDQo+ID4gPiB0byBtaXNjb25uZWN0aXZpdHkgZHVlIHRv IGFueSBzZWxmLWluZmxpY3RlZCBwZWVyaW5nIGNhc2UsIHdlIGNhbg0KPiA+IGFsc28NCj4gPiA+ IGhhdmUgKGkpIG1pc2Nvbm5lY3Rpdml0eSBiZXR3ZWVuIGxheWVycyBhdCBkaWZmZXJlbnQgbGV2 ZWxzIG9yIChpaSkNCj4gPiA+IGJldHdlZW4gZGlmZmVyZW50L2luZGVwZW5kZW50IGxheWVyIG5l dHdvcmtzIGF0IGxldmVsIE4gc2F5IGR1ZSB0bw0KPiBhDQo+ID4gPiBzZXJ2ZXIgbGF5ZXIgbWlz Y29ubmVjdGl2aXR5IGRlZmVjdCBiZWxvdyBsZXZlbCBOLiAgVGhlIGtleSBwb2ludHMNCj4gPiBo ZXJlDQo+ID4gPiBiZWluZzoNCj4gPiA+ICAoaSkgYSByaWNoZXIgZGVmZWN0IGVudmlyb25tZW50 IHRoYW4gdGhlIGNvLWNzIG1vZGUNCj4gPiA+IChpaSkgaWYgTiB0eXBlcyBvZiBDViAnSUQnIGV4 aXN0IHRoZW4gd2UgY2FuJ3QgYXNzdW1lIHRoZXkgcmVtYWluDQo+ID4gPiBpbmRlcGVuZGVudCBv ZiBlYWNoIG90aGVyIGF0IGFsbC4uLi5hcyB3ZSBjb3VsZCBpZiB3ZSBkaWQgbm90DQo+IGltcG9z ZQ0KPiA+IGENCj4gPiA+IHNlbGYtaW5mbGljdGVkIHBlZXIgY2FzZSBvbiBvdXJzZWx2ZXMuLi5h bmQgdGh1cyBlYWNoIG5ldHdvcmsgbXVzdA0KPiBiZQ0KPiA+ID4gYWJsZSB0byBoYW5kbGUgYWxs IE4gaW5zdGFuY2VzIG9mIElEIChJIGFzc3VtZSB0aGUgc2FtZSBDViBPQU0NCj4gPiB0cmFmZmlj DQo+ID4gPiB1bml0IGNhcnJ5aW5nIHRoZW0gLSB2YXJ5aW5nIHRoYXQganVzdCBtYWtlcyB0aGUg bWl4IGV2ZW4gbW9yZQ0KPiA+ID4gaW50ZXJlc3RpbmcpLg0KPiA+ID4NCj4gPiA+IHJlZ2FyZHMs IE5laWwNCj4gPiA+IEJUIERlc2lnbg0KPiA+ID4NCj4gPiA+IFRoaXMgZW1haWwgY29udGFpbnMg QlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+ID4gPiBjb25maWRl bnRpYWwuDQo+ID4gPiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVu dGl0eSBuYW1lZCBhYm92ZS4gSWYNCj4gPiB5b3UncmUNCj4gPiA+IG5vdCB0aGUgaW50ZW5kZWQN Cj4gPiA+IHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1 dGluZyBvciB1c2luZw0KPiB0aGlzDQo+ID4gPiBpbmZvcm1hdGlvbg0KPiA+ID4gaXMgcHJvaGli aXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQN Cj4gbWUNCj4gPiA+IGtub3cgaW1tZWRpYXRlbHkNCj4gPiA+IG9uIHRoZSBlbWFpbCBhZGRyZXNz IGFib3ZlLiBUaGFuayB5b3UuDQo+ID4gPiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFu ZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KPiA+ID4gQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlv bnMgcGxjDQo+ID4gPiBSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9u IEVDMUEgN0FKDQo+ID4gPiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAwMDANCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmDQo+ID4gPiBPZg0KPiA+ID4gPiBNYWFy dGVuIHZpc3NlcnMNCj4gPiA+ID4gU2VudDogMjUgTWF5IDIwMTEgMTA6NDINCj4gPiA+ID4gVG86 IGFkcmlhbkBvbGRkb2cuY28udWs7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6 IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ID4g PiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPg0KPiA+ID4gPiBBZHJpYW4sDQo+ID4gPiA+DQo+ID4g PiA+IFBsZWFzZSBiZSBhd2FyZSB0aGF0IHVuZGVyIGZhdWx0IGNvbmRpdGlvbnMgYW4gSUNDIGZv cm1hdHRlZCBJRA0KPiBjYW4NCj4gPiA+IGJlDQo+ID4gPiA+IHJlY2VpdmVkIGJ5IGFuIGVuZHBv aW50IHVzaW5nIGEgR2xvYmFsX0lEIGZvcm1hdHRlZCBJRCwgYW5kIHZpY2UNCj4gPiA+IHZlcnNh Lg0KPiA+ID4gPiBFaXRoZXIgZW5kcG9pbnQgbXVzdCBiZSBhYmxlIHRvIGRldGVjdCBhIG1pc2Nv bm5lY3Rpb24gY29uZGl0aW9uDQo+ID4gYW5kDQo+ID4gPiBiZQ0KPiA+ID4gPiBhYmxlIHRvIHJl cG9ydCB0aGUgcmVjZWl2ZWQgSUQgKGluIHRoZSBub24tZXhwZWN0ZWQgZm9ybWF0KSB0bw0KPiBO TVMNCj4gPiB0bw0KPiA+ID4gPiBndWlkZSBpbiB0aGUgZmF1bHQgbG9jYWxpc2F0aW9uLg0KPiA+ ID4gPg0KPiA+ID4gPiBOb3RlIHRoYXQgd2Ugb3Zlcmxvb2tlZCBhIHNpbWlsYXIgcmVxdWlyZW1l bnQgaW5pdGlhbGx5IGluIFNESA0KPiAoMTYtDQo+ID4gPiBieXRlDQo+ID4gPiA+IFRUSSBhbmQg NjQtYnl0ZSBUVEkpLCBhbmQgdGhpcyByZXF1aXJlZCB1cyB0byB1cGdyYWRlIG91ciBWQy1uDQo+ ID4gPiA+IGVuZHBvaW50cyBhZnRlcndhcmRzLiBMZXQncyBub3QgbWFrZSBhIHNpbWlsYXIgbWlz dGFrZSBpbiBNUExTLQ0KPiBUUC4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4g TWFhcnRlbg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiA+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSBPbg0KPiA+ID4gQmVoYWxmDQo+ID4gPiA+IE9mDQo+ID4gPiA+ID4gQWRyaWFu IEZhcnJlbA0KPiA+ID4gPiA+IFNlbnQ6IDI1IE1heSAyMDExIDExOjEzDQo+ID4gPiA+ID4gVG86 IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIFI6IFJlOiBNaXhp bmcgSUNDIGFuZCBHbG9iYWwtSURzIGluIE1QTFMtVFANCj4gPiA+ID4gPiBJZGVudGlmaWVycz8N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIE5laWwsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJJ20g bm90IGFzc3VtaW5nIHBlZXJpbmcuIEkgYW0gYWN0dWFsbHkgcG9pbnRpbmcgb3V0IHRvIEh1dWIN Cj4gdGhhdA0KPiA+ID4gPiA+IChkZXNwaXRlIHdoYXQgaGUga2VlcHMgc2F5aW5nKSBoZSBpcyBh bHNvIG5vdCBhc3N1bWluZyBwZWVyaW5nLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGNvbnNl cXVlbmNlIG9mIG5vdCBwZWVyaW5nIGlzIHRoYXQgYSBzaW5nbGUgaWRlbnRpZmllciBtb2RlDQo+ ID4gaXMNCj4gPiA+ID4gdXNlZA0KPiA+ID4gPiA+IGZvciBib3RoIGVuZHMgb2YgYW4gT0FNICJz ZXNzaW9uIi4gQW5kIHRoYXQgbWVhbnMgdGhhdCBvbmUgZW5kDQo+ID4gaGFzDQo+ID4gPiB0bw0K PiA+ID4gPiA+IHVuZGVyc3RhbmQgKmFuZCogdXNlIHRoZSAiZm9yZWlnbiIgZm9ybWF0IGF0IHRo ZSByZW1vdGUgZW5kIG9mDQo+ID4gdGhlDQo+ID4gPiA+ID4gc2Vzc2lvbi4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEkgYW0gdGlyZWQgb2YgdGhpcyBkaXNjdXNzaW9uLiBUaGVyZSBzZWVtcyB0byBi ZSBubyBmb3J3YXJkDQo+ID4gPiBwcm9ncmVzcw0KPiA+ID4gPiA+IG9ubHkgcmVzdGF0ZW1lbnQg b2YgYSAid2FudCIuIEkgYWx3YXlzIHdhbnRlZCBhIHBvbnkgd2hlbiBJIHdhcw0KPiBhDQo+ID4g PiA+ID4gbGl0dGxlIGdpcmwsIGJ1dCBJIG5ldmVyIGdvdCBvbmUuDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBBZHJpYW4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiA+ID4gQmVoYWxmDQo+ID4gPiA+ID4gT2YNCj4g PiA+ID4gPiA+IG5laWwuMi5oYXJyaXNvbkBidC5jb20NCj4gPiA+ID4gPiA+IFNlbnQ6IDIyIE1h eSAyMDExIDIwOjM2DQo+ID4gPiA+ID4gPiBUbzogaHV1YmF0d29ya0BnbWFpbC5jb207IG1wbHNA aWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gUjogUmU6IE1peGluZyBJ Q0MgYW5kIEdsb2JhbC1JRHMgaW4gTVBMUy0NCj4gVFANCj4gPiA+ID4gPiBJZGVudGlmaWVycz8N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBIaSBBZHJpYW4vSHV1YiwNCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBZb3UgYXJlIGxhcmdlbHkgYXNzdW1pbmcgc29tZSBmb3JtIG9mIHBlZXJpbmcg KHNpbmdsZQ0KPiA+IHBhcnRpdGlvbmVkDQo+ID4gPiA+ID4gbGF5ZXIgbmV0d29yaykNCj4gPiA+ ID4gPiA+IGhlcmUuLi5hbmQgdGhhdCBtb2RlbCB3aWxsIGdlbmVyYXRlIGEgd2hvbGUgcmFmdCBv ZiBwcm9ibGVtcw0KPiA+IGZvcg0KPiA+ID4gPiA+IG9wZXJhdG9ycyBJTU8uDQo+ID4gPiA+ID4g PiBBIG1vcmUgaW1wb3J0YW50IG1vZGVsIGZvciBhIGNvLXBzIHRyYW5zcG9ydCBuZXR3b3JrIGlz DQo+ID4gPiA+ID4gY2xpZW50L3NlcnZlci4gIEFuZCBub3cNCj4gPiA+ID4gPiA+IG5vdCBvbmx5 IGhhdmUgd2UgdGhlIHVzdWFsIGludHJhLWxheWVyIG1pc2Nvbm5lY3Rpdml0eSB0bw0KPiBkZWFs DQo+ID4gPiB3aXRoDQo+ID4gPiA+ID4gYnV0IHdlIGFsc28NCj4gPiA+ID4gPiA+IGhhdmUgaW50 ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5Li4uYW5kIHRoaXMgbWVhbnMgZWFjaA0KPiA+IG9wZXJh dGluZw0KPiA+ID4gPiA+IHBhcnR5IG11c3QNCj4gPiA+ID4gPiA+IHVuZGVyc3RhbmQgdGhlIE9B TSBmb3JtYXRzIChhbmQgQ1YgSURzKSBvZiBlYWNoIG90aGVyDQo+IGFueXdheS4uLg0KPiA+ID4g bm90DQo+ID4gPiA+ID4gc2ltcGx5IHRvDQo+ID4gPiA+ID4gPiBkZXRlY3QgdGhlcmUgaXMgYSBt aXNjb25uZWN0aXZpdHkgcHJvYmxlbXMgYnV0IGFsc28gdG8NCj4gaWRlbnRpZnkNCj4gPiA+ID4g d2hpY2gNCj4gPiA+ID4gPiBvdGhlciBwYXJ0aWVzDQo+ID4gPiA+ID4gPiBhcmUgaW52b2x2ZWQu DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gcmVnYXJkcywgTmVpbA0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEJUIERlc2lnbg0KPiA+ID4gPiA+ID4gVGhpcyBlbWFpbCBjb250YWlucyBCVCBp bmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQNCj4gb3INCj4gPiA+ID4gPiBjb25m aWRlbnRpYWwuDQo+ID4gPiA+ID4gPiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFs KHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4NCj4gSWYNCj4gPiA+ID4gPiB5b3UncmUgbm90IHRo ZQ0KPiA+ID4gPiA+ID4gaW50ZW5kZWQNCj4gPiA+ID4gPiA+IHJlY2lwaWVudCwgbm90ZSB0aGF0 IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvcg0KPiB1c2luZw0KPiA+ID4gPiB0 aGlzDQo+ID4gPiA+ID4gaW5mb3JtYXRpb24NCj4gPiA+ID4gPiA+IGlzIHByb2hpYml0ZWQuIElm IHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UNCj4gPiBsZXQNCj4g PiA+ID4gbWUNCj4gPiA+ID4gPiBrbm93DQo+ID4gPiA+ID4gPiBpbW1lZGlhdGVseQ0KPiA+ID4g PiA+ID4gb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4NCj4gPiA+ID4gPiA+ IFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMu DQo+ID4gPiA+ID4gPiBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCj4gPiA+ID4gPiA+ IFJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoNCj4g PiA+ID4gPiA+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+IE9uDQo+ID4gPiA+ID4gQmVoYWxmIE9mDQo+ ID4gPiA+ID4gPiA+IEh1dWIgdmFuIEhlbHZvb3J0DQo+ID4gPiA+ID4gPiA+IFNlbnQ6IDIyIE1h eSAyMDExIDE5OjE1DQo+ID4gPiA+ID4gPiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4g PiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gUjogUmU6IE1peGluZyBJQ0MgYW5kIEdsb2JhbC1JRHMg aW4NCj4gTVBMUy0NCj4gPiBUUA0KPiA+ID4gPiA+ID4gPiBJZGVudGlmaWVycz8NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gSGkgQWRyaWFuLA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiBTZWUgbXkgcmVzcG9uc2UgaW4tbGluZSBbaHZoXQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gPiA+IFdlIGhhdmUgYWxyZWFkeSBiZWVuIHJvdW5kIHRoaXMgbG9vcCBvbiB0aGlzIGxp c3Qgb25jZS4NCj4gPiA+ID4gPiA+ID4gPiBXYW50IHRvIGRvIGl0IGFnYWluPw0KPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiBbaHZoXSBJZiBpdCBoZWxwcyB0byBnZXQgdG8gdGhlIGZvY2Fs IHBvaW50LCB3aHkgbm90Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEFzIEh1dWIg c2FpZCwgdGhpcyBpcyBhYm91dCBpZGVudGlmaWVycywgbm90IE9BTS4NCj4gSG93ZXZlciwNCj4g PiA+IHRoZQ0KPiA+ID4gPiA+IG1vZGVsDQo+ID4gPiA+ID4gPiA+IGZvciBPQU0NCj4gPiA+ID4g PiA+ID4gPiBpbnRlcndvcmtpbmcgc2hvd3MgImxheWVyaW5nIiBub3QgZ2F0ZXdheWluZywgYW5k DQo+IGNlcnRhaW5seQ0KPiA+ID4gbm90DQo+ID4gPiA+ID4gPiA+IG1peGluZy4gVGhhdCBpcywN Cj4gPiA+ID4gPiA+ID4gPiBvbmUgZW5kIG9mIHRoZSBlMmUgcGF0aCBtdXN0IGJlIGNhcGFibGUg b2Ygb3BlcmF0aW5nIGJvdGgNCj4gPiA+ID4gPiBzeXN0ZW1zLA0KPiA+ID4gPiA+ID4gPiBidXQg dGhlIG90aGVyDQo+ID4gPiA+ID4gPiA+ID4gZG9lcyBub3QgbmVlZCB0by4NCj4gPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ID4gW2h2aF0gT0sgaWYgeW91IG1lYW4gIk9BTSB0b29sc2V0cyIgYnkg InN5c3RlbXMiDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVG8gZXh0ZW5kIHRoaXMg bW9kZWwgdG8gaWRlbnRpZmllcnMgbWVhbnMgdGhhdCBvbmUgZW5kIG9mDQo+ID4gdGhlDQo+ID4g PiA+IGUyZQ0KPiA+ID4gPiA+ID4gPiBwYXRoIG11c3QNCj4gPiA+ID4gPiA+ID4gPiBzdXBwb3J0 IGJvdGggaWRlbnRpZmllciBmb3JtYXRzIGFuZCB0aGUgb3RoZXIgZG9lcyBub3QNCj4gbmVlZA0K PiA+ID4gdG8uDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFtodmhdIHRvIGJlIG1vcmUg c3BlY2lmaWMgdGhlIG9yaWdpbmF0aW5nIGVuZCBvZiBhbiBlMmUNCj4gcGF0aA0KPiA+ID4gbXVz dA0KPiA+ID4gPiA+ID4gPiBiZSBhYmxlIHRvIHN1cHBvcnQgb25lIG9mIHRoZSBwb3NzaWJsZSBp ZGVudGlmaWVyIGZvcm1hdHMsDQo+ID4gPiA+IG5vcm1hbGx5DQo+ID4gPiA+ID4gPiA+IHRoZSBp ZGVudGlmaWVyIGZvcm1hdCBvZiB0aGUgbG9jYWwgb3BlcmF0b3IuIFRoZQ0KPiB0ZXJtaW5hdGlu Zw0KPiA+ID4gZW5kDQo+ID4gPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+IHRoZSBpbnRlcm1lZGlh dGUgcG9pbnRzIG9mIGFuIGUyZSBwYXRoIG11c3QgYmUgYWJsZSB0bw0KPiB2ZXJpZnkNCj4gPiA+ IHRoZQ0KPiA+ID4gPiA+ID4gPiBmb3JtYXQgaW5zZXJ0ZWQgYXQgdGhlIG9yaWdpbiBpbmRlcGVu ZGVudCBvZiB0aGUgbG9jYWxseQ0KPiB1c2VkDQo+ID4gPiA+ID4gPiA+IGlkZW50aWZpZXINCj4g PiA+ID4gPiA+ID4gZm9ybWF0LiBUaGlzIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSB0 byBzdXBwb3J0DQo+ID4gPiBkaWZmZXJlbnQNCj4gPiA+ID4gPiA+ID4gaWRlbnRpZmllciBmb3Jt YXRzIGluIHRoZSBBLS0+WiBhbnMgWi0tPkEgZGlyZWN0aW9uIG9mIGFuDQo+IGUyZQ0KPiA+ID4g PiBwYXRoLg0KPiA+ID4gPiA+ID4gPiBJLmUuIG1peGluZyBvZiBpZGVudGlmaWVyIGZvcm1hdHMg bXVzdCBiZSBzdXBwb3J0ZWQuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVGhpcyBi ZWNvbWVzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgdG8gdGhlIHRyYW5zaXQgbm9kZXMNCj4gPiB0 aGF0DQo+ID4gPiA+IG1heQ0KPiA+ID4gPiA+ID4gPiBoYXZlIHRvDQo+ID4gPiA+ID4gPiA+ID4g aW5zcGVjdCB0aGUgaWRlbnRpZmllcnMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFto dmhdIHRoZSBpbnNwZWN0aW9uIHdpbGwgY29uc2lzdCBvZiBjb21wYXJpbmcgYSByZWNlaXZlZA0K PiA+IHZhbHVlDQo+ID4gPiA+ID4gPiA+IHdpdGggYW4gZXhwZWN0ZWQgdmFsdWUgd2hpY2ggY2Fu IGhhdmUgYW55IGZvcm1hdC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBOb25lIG9m IHRoaXMgaXMgbmV3IG9yIHNwZWNpZmljIHRvIE1QTFMtVFAuDQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+IFtodmhdIEkgYWdyZWUsIG1peGluZyBvZiBpZGVudGlmaWVyIGZvcm1hdHMgaXQg bm90DQo+IHJlc3RyaWN0ZWQNCj4gPiA+IHRvDQo+ID4gPiA+ID4gPiA+IE1QTFMtVFAuDQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFJlZ2FyZHMsIEh1dWIuDQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtDQo+IGJvdW5jZXNA aWV0Zi5vcmddDQo+ID4gPiBPbg0KPiA+ID4gPiA+IEJlaGFsZg0KPiA+ID4gPiA+ID4gPiBPZg0K PiA+ID4gPiA+ID4gPiA+PiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCj4gPiA+ID4gPiA+ ID4gPj4gU2VudDogMTggTWF5IDIwMTEgMjI6MjUNCj4gPiA+ID4gPiA+ID4gPj4gVG86IGxvYUBw aS5udTsgbXBsc0BpZXRmLm9yZzsgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuDQo+ID4gPiA+ID4g PiA+ID4+IFN1YmplY3Q6IFttcGxzXSBSOiBSZTogTWl4aW5nIElDQyBhbmQgR2xvYmFsLUlEcyBp bg0KPiBNUExTLQ0KPiA+IFRQDQo+ID4gPiA+ID4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPiA+ ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiBBcHBlbmRpeCBJSSBvZiBZLjE3MzEgcHJvdmlkZXMg YSBnb29kIGV4YW1wbGUgYWJvdXQgaG93DQo+ID4gPiBpbnRlci0NCj4gPiA+ID4gPiBkb21haW4N Cj4gPiA+ID4gPiA+ID4gPj4gY29ubmVjdGl2aXR5IHdpdGggZTJlIE9BTSBjYW4gYmUgcHJvdmlk ZWQgdXNpbmcNCj4gdHJhbnNwb3J0LQ0KPiA+ID4gPiA+IG9yaWVudGVkDQo+ID4gPiA+ID4gPiA+ IE9BTQ0KPiA+ID4gPiA+ID4gPiA+PiBmdW5jdGlvbnMuDQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4g PiA+ID4gPiA+ID4+IFlvdSBjYW4gZG93bmxvYWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIFkuMTcz MSAodGhlIHBkcg0KPiA+ID4gdmVyc2lvbg0KPiA+ID4gPiA+IGlzDQo+ID4gPiA+ID4gPiA+IGZv ciBmcmVlKSBhdA0KPiA+ID4gPiA+ID4gPiA+PiB0aGUgZm9sbG93aW5nIFVSTDoNCj4gPiA+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gaHR0cDovL3d3dy5pdHUuaW50L3JlYy9ULVJFQy1Z LjE3MzEvZW4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gSXQgaXMgYSBwaXR5 IHRoYXQgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZQ0KPiA+IGlkZW50aWZpZXINCj4g PiA+ID4gPiBkcmFmdCwNCj4gPiA+ID4gPiA+ID4gTVBMUy1UUCBpcw0KPiA+ID4gPiA+ID4gPiA+ PiBub3QgY2FwYWJsZSB0byBzdXBwb3J0IHN1Y2ggYSBuZXR3b3JrIHNjZW5hcmlvLg0KPiA+ID4g PiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4gLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0t DQo+ID4gPiA+ID4gPiA+ID4+PiBEYTogbG9hQHBpLm51DQo+ID4gPiA+ID4gPiA+ID4+PiBEYXRh OiA0LW1hZy0yMDExIDguMDANCj4gPiA+ID4gPiA+ID4gPj4+IEE6PG1wbHNAaWV0Zi5vcmc+LA0K PiA+ID4gPiA+ID4gPiA+PiAiTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIjxNYWxjb2xtLkJFVFRT QHp0ZS5jb20uY24+DQo+ID4gPiA+ID4gPiA+ID4+PiBPZ2c6IFJlOiBbbXBsc10gTWl4aW5nIElD QyBhbmQgR2xvYmFsLUlEcyBpbiBNUExTLVRQDQo+ID4gPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4g PiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4gTWFsY29sbSwNCj4gPiA+ID4gPiA+ID4g Pj4+DQo+ID4gPiA+ID4gPiA+ID4+PiBhcmUgeW91IHNheWluZyB0aGF0IG9wZXJhdG9ycyB0b2Rh eSBhbGxvdyBPQU0gdG8NCj4gY29udHJvbA0KPiA+ID4gbm9kZQ0KPiA+ID4gPiA+IChNSVBzDQo+ ID4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gPiA+Pj4gTUVQcykgb24gZWFjaCBvdGhlcnMg bmV0d29ya3M/DQo+ID4gPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4gRG8gd2UgaGF2 ZSBhbiBvcGVyYXRvciB0aGF0IGNhbiB2ZXJpZnkgdGhpcz8NCj4gPiA+ID4gPiA+ID4gPj4+DQo+ ID4gPiA+ID4gPiA+ID4+PiAvTG9hDQo+ID4gPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4gPiA+ Pj4gT24gMjAxMS0wNS0wMyAyMjo0NCwgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIHdyb3RlOg0K PiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gQWxsLA0KPiA+ID4gPiA+ID4g PiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gSSBzaGFyZSB5b3VyIGNvbmNlcm5zIGFuZCBkb3Vi dHMgYWJvdXQgYSBtdWx0aSBjYXJyaWVyDQo+ID4gPiA+IGNvbnRyb2wNCj4gPiA+ID4gPiA+ID4g cGxhbmUuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gSG93ZXZlciwgSSB0aGluayB0aGF0IGl0IGlzIGVz c2VudGlhbCB0aGF0IGEgdHJhbnNwb3J0DQo+ID4gPiA+IG5ldHdvcmsNCj4gPiA+ID4gPiA+ID4g c3VwcG9ydHMNCj4gPiA+ID4gPiA+ID4gPj4+PiBtdWx0aSBjYXJyaWVyIGRhdGEgcGxhbmUgaW50 ZXJjb25uZWN0aW9uIHdpdGggZW5kIHRvDQo+IGVuZA0KPiA+ID4gPiBPQU0uDQo+ID4gPiA+ID4g SW4NCj4gPiA+ID4gPiA+ID4gdG9kYXkncw0KPiA+ID4gPiA+ID4gPiA+Pj4+IHRyYW5zcG9ydCBu ZXR3b3JrIHRoaXMgaW50ZXJjb25uZWN0aW9uIGlzIHN1cHBvcnRlZCBieQ0KPiA+IFNESA0KPiA+ ID4gPiBhbmQNCj4gPiA+ID4gPiA+ID4gT1ROLiBUaGUNCj4gPiA+ID4gPiA+ID4gPj4+PiBvYmpl Y3RpdmUgZm9yIE1QTFMtVFAgaXMgdG8gYWxsb3cgZm9yIHBhY2tldCBiYXNlZA0KPiA+ID4gPiA+ IGludGVyY29ubmVjdGlvbg0KPiA+ID4gPiA+ID4gPiBhcw0KPiA+ID4gPiA+ID4gPiA+PiB3ZWxs Lg0KPiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gUmVnYXJkcywNCj4gPiA+ ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+IE1hbGNvbG0NCj4gPiA+ID4gPiA+ID4g Pj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ ID4gPj4+PiAqR2VvcmdlIFN3YWxsb3c8c3dhbGxvd0BjaXNjby5jb20+Kg0KPiA+ID4gPiA+ID4g PiA+Pj4+IFNlbnQgYnk6IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+Pj4+ DQo+ID4gPiA+ID4gPiA+ID4+Pj4gMDMvMDUvMjAxMSAxMTowOSBBTQ0KPiA+ID4gPiA+ID4gPiA+ Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiBUbw0KPiA+ID4gPiA+ ID4gPiA+Pj4+ICAgICJBbmRyZXcgRy4NCj4gPiA+ID4gPiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5j b20+LDxuZWlsLjIuaGFycmlzb25AYnQuY29tPg0KPiA+ID4gPiA+ID4gPiA+Pj4+IGNjDQo+ID4g PiA+ID4gPiA+ID4+Pj4gICAgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gPiA+Pj4+IFN1Ympl Y3QNCj4gPiA+ID4gPiA+ID4gPj4+PiAgICBSZTogW21wbHNdIE1peGluZyBJQ0MgYW5kIEdsb2Jh bC1JRHMgaW4gTVBMUy1UUA0KPiA+ID4gPiA+IElkZW50aWZpZXJzPw0KPiA+ID4gPiA+ID4gPiA+ Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4g PiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiBBbmR5IC0N Cj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgU3VjaA0KPiA+ID4g PiA+ID4gPiA+Pj4+ICAgPiAgYW4gRS1OTkkgZGVmaW5pdGlvbiBkb2VzIG5vdCB5ZXQgZXhpc3Qg Zm9yIE1QTFMtDQo+IFRQDQo+ID4gPiA+ID4gKHNvbWV0aGluZw0KPiA+ID4gPiA+ID4gPiBlbHNl IHRvDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBwdXQgb24gdGhlIHRvLWRvIGxpc3QpLiBUaGlz IEUtTk5JIHdvdWxkIGFsc28NCj4gPiBpbmNsdWRlDQo+ID4gPiA+ID4gc2ltaWxhcg0KPiA+ID4g PiA+ID4gPiA+Pj4+ICAgPiAgaWRlbnRpZmllciBtYXBwaW5nL3RyYW5zbGF0aW9uIGZvciBNUy1Q V3MsIHRvDQo+ID4gYW5zd2VyDQo+ID4gPiBhbg0KPiA+ID4gPiA+ID4gPiBlYXJsaWVyDQo+ID4g PiA+ID4gPiA+ID4+Pj4gICA+ICBxdWVzdGlvbiBmcm9tIEVybWluaW8gdGhhdCBJIHNhdyBvbiB0 aGUgbGlzdC4NCj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+IFlvdSBhcmUg cXVpdGUgY29ycmVjdCBoZXJlISBJIHRoaW5rIG11Y2ggb2YgdGhpcw0KPiBkZWJhdGUNCj4gPiA+ ID4gPiBzdXJyb3VuZHMNCj4gPiA+ID4gPiA+ID4gYQ0KPiA+ID4gPiA+ID4gPiA+PiBwcm9ibGVt DQo+ID4gPiA+ID4gPiA+ID4+Pj4gdGhhdCBpcyB5ZXQgdG8gYmUgc29sdmVkLiBTbyB0aGVyZSBh cmUgYXJndW1lbnRzIGZvcg0KPiA+ID4gcGllY2VzDQo+ID4gPiA+IG9mDQo+ID4gPiA+ID4gYQ0K PiA+ID4gPiA+ID4gPiBzb2x1dGlvbg0KPiA+ID4gPiA+ID4gPiA+Pj4+IHdpdGhvdXQgYW5kIG92 ZXJhbGwgYXJjaGl0ZWN0dXJlLg0KPiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+ Pj4gQmFzZWQgb24gYWxsIHRoYXQgSSBhbSBzZWVpbmcgbXkgaW5jbGluYXRpb24gaXMgdG8gTk9U DQo+ID4gc2F5DQo+ID4gPiA+ID4gdGhhdCB3ZQ0KPiA+ID4gPiA+ID4gPiA+PiBkaXNhbGxvdw0K PiA+ID4gPiA+ID4gPiA+Pj4+IG1peGVkIGlkZW50aWZpZXJzLCBidXQgdG8gc2F5IHRoYXQgdGhl eSBhcmUgZm9yIGZ1dHVyZQ0KPiA+ID4gPiBzdHVkeS4NCj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ ID4gPiA+ID4gPiA+Pj4+IC4uLkdlb3JnZQ0KPiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4g PiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiBPbiA1LzMvMTEgODozOCBBTSwgIkFuZHJl dyBHLg0KPiBNYWxpcyI8YWdtYWxpc0BnbWFpbC5jb20+DQo+ID4gPiA+ID4gd3JvdGU6DQo+ID4g PiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4gIE5laWwsDQo+ID4gPiA+ID4g PiA+ID4+Pj4gICA+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBUbyB5b3VyIGNhc2UgMSwgd2Un cmUgaW4gY29tcGxldGUgYWdyZWVtZW50LiBXZQ0KPiA+IChWWikNCj4gPiA+ID4gPiBkb24ndA0K PiA+ID4gPiA+ID4gPiBzZWUgYXQNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4gIGxlYXN0IGEgc2hv cnQtdGVybSBuZWVkIGZvciBwZWVyLWxheWVyDQo+ID4gaW50ZXJ3b3JraW5nLA0KPiA+ID4gPiA+ IGdpdmVuDQo+ID4gPiA+ID4gPiA+IHdoZXJlIHdlDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBp bnRlbmQgdG8gZGVwbG95IE1QTFMtVFAgaW4gb3VyIGluZnJhc3RydWN0dXJlDQo+IChhcw0KPiA+ IGFuDQo+ID4gPiA+ID4gPiA+IGludGVybmFsIHNlcnZlcg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAg PiAgbGF5ZXIgaW4gdGhlIHRyYW5zcG9ydCBjb3JlKS4gSWYgcGVlciBsYXllcg0KPiA+ID4gPiBp bnRlcndvcmtpbmcNCj4gPiA+ID4gPiBldmVyDQo+ID4gPiA+ID4gPiA+IGJlY29tZXMNCj4gPiA+ ID4gPiA+ID4gPj4+PiAgID4gIGEgbmVjZXNzaXR5LCB0aGVuIG9idmlvdXNseSB3ZSdsbCBuZWVk IGEgd2VsbC0NCj4gPiBkZWZpbmVkDQo+ID4gPiA+IEUtDQo+ID4gPiA+ID4gTk5JDQo+ID4gPiA+ ID4gPiA+IHdoaWNoDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICB3b3VsZCBpbmNsdWRlIExTUCBp ZGVudGlmaWVyIG1hcHBpbmcvdHJhbnNsYXRpb24NCj4gYXQNCj4gPiA+IHRoZQ0KPiA+ID4gPiA+ ID4gPiBib3VuZGFyeSwgZm9yDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBMU1AgcHJvdmlzaW9u aW5nICh3aGV0aGVyIHN0YXRpYyBvciBkeW5hbWljKSBhbmQNCj4gPiBlbmQtDQo+ID4gPiA+IHRv LQ0KPiA+ID4gPiA+IGVuZA0KPiA+ID4gPiA+ID4gPiBPQU0uIFN1Y2gNCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4gIGFuIEUtTk5JIGRlZmluaXRpb24gZG9lcyBub3QgeWV0IGV4aXN0IGZvciBNUExT LQ0KPiBUUA0KPiA+ID4gPiA+IChzb21ldGhpbmcNCj4gPiA+ID4gPiA+ID4gZWxzZSB0bw0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPiAgcHV0IG9uIHRoZSB0by1kbyBsaXN0KS4gVGhpcyBFLU5OSSB3 b3VsZCBhbHNvDQo+ID4gaW5jbHVkZQ0KPiA+ID4gPiA+IHNpbWlsYXINCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4gIGlkZW50aWZpZXIgbWFwcGluZy90cmFuc2xhdGlvbiBmb3IgTVMtUFdzLCB0bw0K PiA+IGFuc3dlcg0KPiA+ID4gYW4NCj4gPiA+ID4gPiA+ID4gZWFybGllcg0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPiAgcXVlc3Rpb24gZnJvbSBFcm1pbmlvIHRoYXQgSSBzYXcgb24gdGhlIGxpc3Qu DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBJIGFsc28g YWdyZWUgdGhhdCBib3RoIGludHJhLWxheWVyIGFuZCBpbnRlci0NCj4gbGF5ZXINCj4gPiA+IG1p cy0NCj4gPiA+ID4gPiA+ID4gY29ubmVjdGl2aXR5DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+ICBk ZXRlY3Rpb24gYW5kIGFtZWxpb3JhdGlvbiBhcmUgcmVxdWlyZWQsIGJ1dCBJJ20NCj4gPiBub3QN Cj4gPiA+ID4gPiA+ID4gY29udmluY2VkIHRoYXQNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4gIHRo ZSBhbHJlYWR5IGRlZmluZWQgbWVjaGFuaXNtcyBjYW4ndCBkbyB0aGF0LiBEbw0KPiA+IHlvdQ0K PiA+ID4gPiBoYXZlDQo+ID4gPiA+ID4gPiA+IHNvbWUNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4g IHNwZWNpZmljIGFuYWx5c2lzIG9uIHRoZSBpbnRlci1sYXllciBjYXNlPw0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPiAgQ2hlZXJzLA0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPiAgQW5keQ0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPg0KPiA+ID4gPiA+ID4gPiA+ Pj4+ICAgPiAgT24gVHVlLCBNYXkgMywgMjAxMSBhdCAzOjM2DQo+ID4gPiBBTSw8bmVpbC4yLmhh cnJpc29uQGJ0LmNvbT4NCj4gPiA+ID4gPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4+Pj4g ICA+PiAgSGkgQW5keSwNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+ID4+ Pj4gICA+PiAgMiBwb2ludHM6DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPj4gIDEgSSBhZ3JlZSB3aXRoIHlvdXIgdmlldyBvZiBvbmx5IGhhdmluZyBhIHNp bmdsZQ0KPiA+ID4gPiA+IGFkZHJlc3NpbmcNCj4gPiA+ID4gPiA+ID4gc2NoZW1lIGluDQo+ID4g PiA+ID4gPiA+ID4+IGENCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBzaW5nbGUgbGF5ZXIgbmV0 d29yayBzb2xlbHkgYmVsb25naW5nIHRvIG9uZQ0KPiA+IHBhcnR5Lg0KPiA+ID4gPiA+IFRob3Vn aA0KPiA+ID4gPiA+ID4gPiB5b3UgbWF5DQo+ID4gPiA+ID4gPiA+ID4+Pj4gbmVlZCB0bw0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGJlIHJhdGhlciBjYXJlZnVsIGlmIHlvdSBhbHNvIGFkdm9j YXRlIHRoYXQgb25lDQo+ID4gY2FuDQo+ID4gPiA+IGFsc28NCj4gPiA+ID4gPiA+ID4gaGF2ZSBw ZWVyDQo+ID4gPiA+ID4gPiA+ID4+IGxheWVyDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgaW50 ZXJ3b3JraW5nIGJldHdlZW4gZGlmZmVyZW50IHBhcnRpZXMsIGllIEUtDQo+IE5OSXMNCj4gPiAo SQ0KPiA+ID4gPiA+IGJlbGlldmUNCj4gPiA+ID4gPiA+ID4gdGhpcyBpcw0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPj4gIHNvbWV0aGluZyB5b3UgbWF5IHN1cHBvcnQsIGVnIG9sZCBNUExTRiBjYXNl PykuDQo+IEluDQo+ID4gPiA+IHN1Y2gNCj4gPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiA+IHBlZXIN Cj4gPiA+ID4gPiA+ID4gPj4+PiBpbnRlcndvcmtpbmcNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ ICBjYXNlIGl0IHdvdWxkIHNlZW0gb25lIG11c3QgYWxsb3cgZGlmZmVyZW50DQo+ID4gPiBhZGRy ZXNzaW5nDQo+ID4gPiA+ID4gPiA+IHNjaGVtZXMgKGFuZA0KPiA+ID4gPiA+ID4gPiA+Pj4+IGlu ZGVlZA0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGFueSBvdGhlciB2YXJpYXRpb25zIGluIERQ L0NQIGZ1bmN0aW9uYWwNCj4gPiBjb21wb25lbnRzKQ0KPiA+ID4gPiBpZg0KPiA+ID4gPiA+IHRo ZXkNCj4gPiA+ID4gPiA+ID4gZXhpc3QNCj4gPiA+ID4gPiA+ID4gPj4+PiBpbiB0aGUNCj4gPiA+ ID4gPiA+ID4gPj4+PiAgID4+ICBzdGFuZGFyZHMuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0K PiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIE9mIGNvdXJzZSwgaGF2aW5nIGFuIEUtTk5JIGFuZCBw ZWVyIGludGVyd29ya2luZw0KPiA+ID4gPiBiZXR3ZWVuDQo+ID4gPiA+ID4gPiA+IGRpZmZlcmVu dA0KPiA+ID4gPiA+ID4gPiA+Pj4+IHBhcnRpZXMgaW4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ ICBhbnkgbm9uLVRPUyBsYXllciBuZXR3b3JrIChub3QganVzdCBNUExTKSBpcyBub3QNCj4gPiA+ ID4gPiB0ZWNobmljYWxseQ0KPiA+ID4gPiA+ID4gPiA+Pj4+IG5lY2Vzc2FyeSAodGhpcw0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGlzIHRyaXZpYWwgdG8gcHJvdmUpLCBhbmQgdGhpcyBwcm92 aWRlcyBhIHN0cm9uZw0KPiA+ID4gPiA+IGFyZ3VtZW50DQo+ID4gPiA+ID4gPiA+IGZvciBvbmx5 DQo+ID4gPiA+ID4gPiA+ID4+Pj4gaGF2aW5nIGENCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBz aW5nbGUgYWRkcmVzc2luZyBzY2hlbWUgaW4gYSBub24tVE9TIGxheWVyDQo+ID4gbmV0d29yay4N Cj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4g PiA+ID4gPiA+Pj4+ICAgPj4gIDIgWW91IHNob3VsZCBhbHNvIGJlIGF3YXJlIHRoYXQgaW4gY2xp ZW50L3NlcnZlcg0KPiA+ID4gPiA+ID4gPiBpbnRlcndvcmtpbmcgb2YgdGhlDQo+ID4gPiA+ID4g PiA+ID4+Pj4gICA+PiAgY28tcHMgbW9kZSB1c2luZyB2YXJpYWJsZSBzaXplIHRyYWZmaWMgdW5p dHMsDQo+IGFuZA0KPiA+ID4gPiA+IHRoZXJlZm9yZQ0KPiA+ID4gPiA+ID4gPiA+Pj4+IHNvbWV0 aGluZyByYXRoZXINCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBpbXBvcnRhbnQgZm9yIE1QTFMt VFAgaW4gdGhlIHJvbGUgb2YgYSB0cmFuc3BvcnQNCj4gPiA+ID4gbmV0d29yaw0KPiA+ID4gPiA+ ID4gPiAoSSdsbA0KPiA+ID4gPiA+ID4gPiA+Pj4+IGlnbm9yZSBpc3N1ZXMNCj4gPiA+ID4gPiA+ ID4gPj4+PiAgID4+ICBvZiB0cmFuc3BhcmVuY3kgaGVyZSksIHRoZXJlIGNvdWxkIGJlIGludGVy LQ0KPiBsYXllcg0KPiA+ID4gPiA+ID4gPiBtaXNjb25uZWN0aXZpdHkNCj4gPiA+ID4gPiA+ID4g Pj4+PiAoQXNpZGU9Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIFRoaXMgY2FzZSBjYW5ub3Qg b2NjdXIgaW4gdGhlIGNvLWNzIG1vZGUpLiBUbw0KPiA+IGRhdGUsDQo+ID4gPiA+ID4gaG93ZXZl ciwNCj4gPiA+ID4gPiA+ID4gd2UgaGF2ZQ0KPiA+ID4gPiA+ID4gPiA+Pj4+IG9ubHkNCj4gPiA+ ID4gPiA+ID4gPj4+PiAgID4+ICByZWFsbHkgY29uc2lkZXJlZCBpbnRyYS1sYXllciBtaXNjb25u ZWN0aXZpdHksDQo+IGllDQo+ID4gPiA+ID4gYmV0d2Vlbg0KPiA+ID4gPiA+ID4gPiBkaWZmZXJl bnQNCj4gPiA+ID4gPiA+ID4gPj4gTFNQcw0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGJlbG9u Z2luZyB0byB0aGUgc2FtZSBwYXJ0eSAobm90ZSB0aGlzIGFsc28NCj4gPiBpbmNsdWRlcw0KPiA+ ID4gPiBhbGwNCj4gPiA+ID4gPiA+ID4gY2FzZXMgb2YNCj4gPiA+ID4gPiA+ID4gPj4+PiBuZXN0 ZWQgTFNQDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgc3VibGF5ZXIgbWlzY29ubmVjdGl2aXR5 KS4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgSW4g dGhlIGNhc2Ugb2YgaW50ZXItbGF5ZXIgbWlzY29ubmVjdGl2aXR5IG9uZQ0KPiBtYXkNCj4gPiA+ ID4gPiByZWNlaXZlDQo+ID4gPiA+ID4gPiA+IHRyYWZmaWMNCj4gPiA+ID4gPiA+ID4gPj4+PiB1 bml0cyBhbmQNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBPQU0gbWVzc2FnZXMgZnJvbSBzb21l IG90aGVyIHBhcnR5J3MgbGF5ZXINCj4gPiBuZXR3b3JrLg0KPiA+ID4gPiBUaGUNCj4gPiA+ID4g PiBPQU0NCj4gPiA+ID4gPiA+ID4gPj4gbWVzc2FnZXMNCj4gPiA+ID4gPiA+ID4gPj4gbWF5DQo+ ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgY29tZSBmcm9tIChpKSBuZXR3b3JrcyB1c2luZyBkaWZm ZXJlbnQNCj4gPiA+IE9BTS9hZGRyZXNzaW5nDQo+ID4gPiA+ID4gPiA+IHNvbHV0aW9ucyBvcg0K PiA+ID4gPiA+ID4gPiA+PiAoaWkpDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgbmV0d29ya3Mg dXNpbmcgdGhlIHNhbWUgT0FNL2FkZHJlc3NpbmcNCj4gc29sdXRpb25zLg0KPiA+IEluDQo+ID4g PiA+ID4gYm90aA0KPiA+ID4gPiA+ID4gPiBjYXNlcw0KPiA+ID4gPiA+ID4gPiA+Pj4+IHRoZXJl IGFyZQ0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIGRpZmZlcmVudCBpc3N1ZXMgd3J0IGludGVy LWxheWVyIG1pc2Nvbm5lY3Rpdml0eQ0KPiA+IG9uZQ0KPiA+ID4gPiBoYXMNCj4gPiA+ID4gPiB0 bw0KPiA+ID4gPiA+ID4gPiBkZWFsDQo+ID4gPiA+ID4gPiA+ID4+Pj4gd2l0aC4gSSdtDQo+ID4g PiA+ID4gPiA+ID4+Pj4gICA+PiAgbm90IGF3YXJlIHRoYXQgdGhlc2UgY2FzZXMgaGF2ZSBiZWVu IGNvbnNpZGVyZWQNCj4gPiB5ZXQuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBJJ2QgbGlrZSB0byBoZWFy IHlvdXIgY29tbWVudHMgb24gYm90aCB0aGVzZQ0KPiA+IHBvaW50cywNCj4gPiA+ID4gYnV0DQo+ ID4gPiA+ID4gaW4NCj4gPiA+ID4gPiA+ID4gPj4+PiBwYXJ0aWN1bGFyIHRoZQ0KPiA+ID4gPiA+ ID4gPiA+Pj4+ICAgPj4gIGZpcnN0IG9uZS4uLi4uZXNwZWNpYWxseSBpZiB5b3UgYWxzbyBzdXBw b3J0IHRoZQ0KPiA+ID4gPiBub3Rpb24NCj4gPiA+ID4gPiBvZg0KPiA+ID4gPiA+ID4gPiBFLU5O SXMgaW4NCj4gPiA+ID4gPiA+ID4gPj4+PiBNUExTLVRQLA0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAg Pj4gIGFzIHRoZXJlIHNlZW1zIHRvIGEgcG9zc2libGUgbG9naWNhbCBjb25mbGljdA0KPiA+IGhl cmUuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIFRo YW5rcy4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAg cmVnYXJkcywgTmVpbCBIYXJyaXNvbg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4NCj4gPiA+ID4g PiA+ID4gPj4+PiAgID4+ICBCVCBEZXNpZ24NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4g PiA+ID4gPiA+ID4+Pj4gICA+PiAgVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwg d2hpY2ggbWF5IGJlDQo+ID4gPiA+ID4gcHJpdmlsZWdlZA0KPiA+ID4gPiA+ID4gPiBvcg0KPiA+ ID4gPiA+ID4gPiA+Pj4+IGNvbmZpZGVudGlhbC4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBJ dCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eQ0KPiA+ID4gbmFt ZWQNCj4gPiA+ID4gPiBhYm92ZS4NCj4gPiA+ID4gPiA+ID4gSWYNCj4gPiA+ID4gPiA+ID4gPj4+ PiB5b3UncmUgbm90DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgdGhlIGludGVuZGVkDQo+ID4g PiA+ID4gPiA+ID4+Pj4gICA+PiAgcmVjaXBpZW50LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29w eWluZywNCj4gPiA+IGRpc3RyaWJ1dGluZw0KPiA+ID4gPiA+IG9yDQo+ID4gPiA+ID4gPiA+IHVz aW5nIHRoaXMNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBpbmZvcm1hdGlvbg0KPiA+ID4gPiA+ ID4gPiA+Pj4+ICAgPj4gIGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluDQo+ID4gPiBlcnJvciwNCj4gPiA+ID4gPiA+ID4gcGxlYXNlIGxldCBtZQ0KPiA+ID4g PiA+ID4gPiA+Pj4+IGtub3cNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBpbW1lZGlhdGVseQ0K PiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4gIG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFu ayB5b3UuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+PiAgV2UgbW9uaXRvciBvdXIgZW1haWwgc3lz dGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyDQo+ID4gPiA+IGVtYWlscy4NCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4+ICBCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4+ICBSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVD MUENCj4gPiA3QUoNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+ICBSZWdpc3RlcmVkIGluIEVuZ2xh bmQgbm86IDE4MDAwMDANCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+DQo+ID4gPiA+ID4gPiA+ID4+ Pj4gICA+Pj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4+Pj4g ICA+Pj4gIEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtDQo+ID4gPiA+ ID4gYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gPiA+ID4gT24gQmVoYWxmDQo+ID4gPiA+ID4g PiA+ID4+IE9mDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIEFuZHJldyBHLiBNYWxpcw0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBTZW50OiAwMiBNYXkgMjAxMSAyMDo0OA0KPiA+ID4gPiA+ ID4gPiA+Pj4+ICAgPj4+ICBUbzogR2VvcmdlIFN3YWxsb3cNCj4gPiA+ID4gPiA+ID4gPj4+PiAg ID4+PiAgQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgU3ViamVj dDogUmU6IFttcGxzXSBNaXhpbmcgSUNDIGFuZCBHbG9iYWwtSURzDQo+IGluDQo+ID4gPiA+IE1Q TFMtDQo+ID4gPiA+ID4gVFANCj4gPiA+ID4gPiA+ID4gSWRlbnRpZmllcnM/DQo+ID4gPiA+ID4g PiA+ID4+Pj4gICA+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgR2VvcmdlIGV0IGFsLA0K PiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIFZlcml6 b24gZG9lcyBub3QgaGF2ZSBhbnkgcmVxdWlyZW1lbnQgZm9yIG1peGVkDQo+ID4gdXNlDQo+ID4g PiA+IG9mDQo+ID4gPiA+ID4gPiA+IEdsb2JhbCBJRHMgYW5kDQo+ID4gPiA+ID4gPiA+ID4+Pj4g ICA+Pj4gIElDQ3MuIFdlIGFyZSBmaW5lIHdpdGggc3BlY2lmaWNhdGlvbnMgdGhhdA0KPiA+IHJl cXVpcmUNCj4gPiA+ID4gYm90aA0KPiA+ID4gPiA+ID4gPiBlbmRzIG9mIGFuDQo+ID4gPiA+ID4g PiA+ID4+IExTUA0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICB0byB1c2Ugb25lIG9yIHRoZSBv dGhlci4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ ICBUaGFua3MsDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIEFuZHkNCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBPbiBNb24sIEFwciAyNSwgMjAx MSBhdCA1OjE2IFBNLCBHZW9yZ2UNCj4gPiA+ID4gPiA+ID4gU3dhbGxvdzxzd2FsbG93QGNpc2Nv LmNvbT4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4+ Pj4gICA+Pj4+ICBBbGwgLQ0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+Pg0KPiA+ID4gPiA+ID4g PiA+Pj4+ICAgPj4+PiAgTWFueSBvZiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUgSVRV IG9uDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRp ZmllcnMtMDQgaGF2ZSB0byBkbw0KPiA+IHdpdGgNCj4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiA+ IEdsb2JhbCBhbmQgSUNDDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBpZGVudGlmaWVycy4N Cj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIFRo ZSBpZGVudGlmaWVycyBmb3IgVHVubmVsLCBMU1AsIFBXLCBhbmQgTUVHDQo+ID4gPiBpbmNsdWRl DQo+ID4gPiA+ID4gPiA+IGZpZWxkcyB0bw0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBpZGVu dGlmeSBlYWNoDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBlbmQgb2YgYW4gTFNQLiBDdXJy ZW50bHkgdGhlIGRyYWZ0IGFsbG93cyBhDQo+ID4gPiBUdW5uZWwsDQo+ID4gPiA+ID4gTFNQLA0K PiA+ID4gPiA+ID4gPiBQVywgb3IgTUVHDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIHRvIHVz ZQ0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgZWl0aGVyIHRoZSBHbG9iYWwtSUQgZm9yIGJv dGggZW5kcyBvciBvciB0aGUNCj4gSUNDDQo+ID4gPiBmb3INCj4gPiA+ID4gPiBib3RoDQo+ID4g PiA+ID4gPiA+IGVuZHMuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIE1peGVkIHVzZQ0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgaXMgbm90IHBlcm1pdHRlZC4NCj4gPiA+ID4gPiA+ID4g Pj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIFRoZSBJVFUgbGlhaXNvbiBy ZXF1ZXN0cyB0aGF0IHdlIGFsbG93IG1peGVkDQo+ID4gdXNlLg0KPiA+ID4gPiA+ID4gPiA+Pj4+ ICAgPj4+Pg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgVGhlIGF1dGhvcnMgb2YgdGhlIGRy YWZ0IGFyZSB2ZXJ5IHJlbHVjdGFudCB0bw0KPiA+IGRvDQo+ID4gPiA+ID4gdGhpcy4NCj4gPiA+ ID4gPiA+ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIE9idGFpbmlu ZyBhbiBBUyBOdW1iZXIgKGZyb20gd2hpY2ggdGhlIEdsb2JhbC0NCj4gSUQNCj4gPiA+IGlzDQo+ ID4gPiA+ID4gPiA+IGRlcml2ZWQpIGlzIGENCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgZmFp cmx5DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICB0cml2aWFsIHByb2NlZHVyZS4gTWFueSBv cmdhbml6YXRpb25zIGlmIG5vdA0KPiA+IG1vc3QNCj4gPiA+ID4gPiBhbHJlYWR5DQo+ID4gPiA+ ID4gPiA+IGhhdmUgQVMNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgTnVtYmVycy4NCj4gPiA+ ID4gPiA+ID4gPj4+PiAgID4+Pj4gIFN1Y2ggYW4gYWRkaXRpb24gd2lsbCBhZGQgbnVtZXJvdXMg b2JqZWN0DQo+ID4gZm9ybWF0cywNCj4gPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+IHRlc3QgY2Fz ZXMuDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBUaGUgZXh0ZW50IGludGVyLXByb3ZpZGVy IE1QTFMtVFAgaXMgYXMgeWV0DQo+ID4gPiB1bmtub3duLg0KPiA+ID4gPiA+IElmDQo+ID4gPiA+ ID4gPiA+IG1peGVkIG1vZGVzDQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIG9mIElDQw0KPiA+ ID4gPiA+ID4gPiA+Pj4+ICAgPj4+PiAgYW5kIEdsb2JhbC1JRCBpZGVudGlmaWNhdGlvbiBpcyBy ZXF1aXJlZCwgdGhleQ0KPiA+IGNhbg0KPiA+ID4gPiBiZQ0KPiA+ID4gPiA+ID4gPiBhZGRlZCBs YXRlci4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIEZvciBzaWduYWxlZCBjb25uZWN0aW9u cywgdGhlcmUgaXMgbm8gcGxhbiB0bw0KPiA+ID4gYWxsb3cNCj4gPiA+ID4gPiA+ID4gcm91dGlu ZyBiYXNlZCBvbg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ICBlaXRoZXINCj4gPiA+ID4gPiA+ ID4gPj4+PiAgID4+Pj4gIHRoZSBHbG9iYWwtSUQgb3IgSUNDLiBUaGF0IHdvdWxkIGJlIGEgcmFk aWNhbA0KPiA+ID4gY2hhbmdlDQo+ID4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ID4gaG93IElQDQo+ ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4gIHdvcmtzLg0KPiA+ID4gPiA+ID4gPiA+Pj4+ICAgPj4+ PiAgSG93ZXZlciBmb3IgSVAgcm91dGluZyB0byB3b3JrIChpbiBvcmRlciB0bw0KPiA+ID4gZm9y d2FyZA0KPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gPiBzaWduYWxpbmcNCj4gPiA+ID4gPiA+ ID4gPj4+PiAgID4+Pj4gIG1lc3NhZ2VzKSwgdGhlIHByb3ZpZGVycyBpbnZvbHZlZCB3aWxsIG5l ZWQgdG8NCj4gPiBydW4NCj4gPiA+ID4gQkdQDQo+ID4gPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+ IGhhdmUgQVMNCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+PiAgbnVtYmVycy4NCj4gPiA+ID4gPiA+ ID4gPj4+PiAgID4+Pj4NCj4gPiA+ID4gPiA+ID4gPj4+PiAgID4+Pj4gIFdlIGFyZSBsb29raW5n IGZvciBpbnB1dC9jb25zZW5zdXMgZnJvbSB0aGUNCj4gV0cuDQo+ID4gPiA+ID4gPiA+ID4+Pj4g ICA+Pj4+DQo+ID4gPiA+ID4gPiA+ID4+Pj4gICA+Pj4+ICBHZW9yZ2UsIEVyaWMsJiAgTWF0dGhl dw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLQ0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPiA+ID4gPiA+ICoqKg0KPiA+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0K PiA+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4gPiA+ID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ID4gPiBtcGxz QGlldGYub3JnDQo+ID4gPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4g PiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QN Cj4gPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo= From yakov@juniper.net Fri May 27 09:21: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 937CBE0813 for ; Fri, 27 May 2011 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 fEZ4GwH+3pM3 for ; Fri, 27 May 2011 09:21:43 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 54D16E070C for ; Fri, 27 May 2011 09:21:42 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTd/PlQxCdOO/iO+j8OiAhbhhi4lDX6lr@postini.com; Fri, 27 May 2011 09:21:43 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; Fri, 27 May 2011 09:20:32 -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 p4RGKWv46513; Fri, 27 May 2011 09:20:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201105271620.p4RGKWv46513@magenta.juniper.net> To: In-Reply-To: <20900.1306328015@erosen-linux> References: <20900.1306328015@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Wed, 25 May 2011 08:53:35 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83752.1306513232.1@juniper.net> Date: Fri, 27 May 2011 09:20:32 -0700 From: Yakov Rekhter Cc: mpls@ietf.org Subject: Re: [mpls] MVPN in the "seamless MPLS" environment 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, 27 May 2011 16:21:44 -0000 Eric, > Although the "seamless-mcast" draft claims to specify the way to > do MPLS multicast in the seamless MPLS model, the procedures it > specifies are much more like the multi-segment pseudowire model > than like the seamless model. For the MVPN service, the draft has > the service nodes and the border transport nodes exchanging > MVPN-specific control messages and performing MVPN-specific functions. > The border routers at the upper level of the hierarchy have to > maintain MVPN-specific state, and the amount of state maintained > is proportional to the number of MVPN states maintained by the > service nodes, not proportional to the number of transport tunnels > that are needed. Please note that the MVPN states at the border routers is the control plane states only, as the data plane state is determined by the number of transport tunnels that are needed. > For example, a PE might send 100 S-PMSI A-D routes, each one binding > a customer flow (C-S,C-G) to a P-tunnel. But these 100 S-PMSI A-D > routes might all have the same PMSI Tunnel Attribute (PTA); that > is, the PE might bind each of these 100 C-flows to the same P-tunnel. > In seamless MPLS, the transport border nodes should have one state > for the P-tunnel, not 100 states for the C-flows. The transport > border routers do not care what the P-tunnel is being used for. > And since the border routers do not perform MVPN-specific functions, > they will not be deaggregating and reaggregating the C-flows. The > border routers may decide to aggregate the P-tunnels in some way, > but they should not deal with anything more finely grained than a > P-tunnel; to do so would be to perform service-specific functions. In the case where all these 100 S-PMSI A-D routes are for the same C-G, and C-G is in the ASM range, all one needs to do is to use a single (C-*, C-G) S-PMSI A-D route (instead of 100 S-PMSI A-D routes). The seamless-mcast draft does apply to this case, as it does support (C-*, C-G) S-PMSI A-D routes. Now let's consider the scenario where these 100 flows are for different C-Gs. The example that you described above *implicitly* assumes that the (ingress) PE performs aggregation at the granularity of the whole (inter-area) p2mp LSP (as all these 100 flows are aggregated into the same P-tunnel). That is, *in addition* to whatever aggregation one could perform at the granularity of the intra-area segments, the example also assumes that the aggregation is performed at the granularity of the inter-area p2mp LSPs. When one can perform aggregation at the granularity of intra-area segments, there are good reasons *not* to perform aggregation at the granularity of inter-area p2mp LSPs. This is because when aggregating p2mp LSPs, to reduce b/w inefficiency, one need to perform leaf tracking. The overhead of leaf tracking, when aggregation is performed at the level of inter-area p2mp LSPs, is higher than when aggregation is done at the level of the intra-area segments. Furthermore, aggregation at the level of inter-area p2mp LSPs reduces the choices that could be applied at the level of intra-area segments, which has adverse impact on the ability to reduce b/w inefficiency (b/w inefficiency is due to partial congruence). And if for the reasons mentioned above one does not perform aggregation at the granularity of inter-area p2mp LSPs, then your example above does *not* apply in the context of seamless-mcast (as seamless-mcast provides aggregation at the granularity of intra-area segments). > I think it is possible to provide MVPN support in the seamless MPLS > environment in a more seamless manner, keeping MVPN-specific > functionality off the transport nodes, while still gaining the > advantages of LSP hierarchy that the seamless MPLS model tries to > provide. > > The MVPN specifications really provide three and a half "levels" > of signaling: > > 1. The C-multicast signaling, which conveys the customer multicast > states > from one PE to another. This level of signaling should involve > only the PE routers (the service nodes). > > 2. The A-D signaling, which assigns sets of customer multicast flows > (C-flows) to P-tunnels. The A-D signaling also distributes the > information that the PE routers need in order to determine which > P-tunnels they need to join, as well as the information needed > by the third level of signaling. This level of signaling is > done via BGP. > > 3. The P-tunnel setup signaling. > > For unsegmented P-tunnels, and for individual segments of segmented > P-tunnels, this level of signaling is done via mLDP, RSVP-TE, > or other multicast tunnel setup protocol. > > For segmented P-tunnels, there is a "level 3.5" of signaling, > that carries information among the segment endpoints. (When > ingress replication is used to instantiate the P-tunnels, level > 3 signaling is not needed, though level 3.5 signaling might still > be needed.) > > In a seamless MPLS environment, I think the A-D signaling should, > like the C-multicast signaling, should only involve the service > nodes. It should be PE-PE signaling, most likely through > service-specific route reflectors. > > The P-tunnel setup signaling (levels 3 and 3.5) should involve the > transport nodes, of course, but in the seamless model, this level > of signaling should be service-independent. The basic concept of > this level of signaling should be the P-tunnel. > > The proposal in the seamless-mcast draft uses the MVPN A-D signaling > for the level 3.5 signaling. As a result, the "P2MP FEC" used by > the level 3.5 signaling is the NLRI of the A-D routes, rather than > the P-tunnel. > > If we don't try to piggyback the level 3.5 signaling on the level > 2 signaling messages, and we do the level 3.5 signaling on a > per-P-tunnel basis, we can provide the following control flow model: > > PE2-- ... ---ABR2-- ... ---ABR1-- ... ---PE1 > > Let's suppose, e.g, that we want to create a three-segment > P-tunnel, with each segment created by RSVP-TE. IMHO, the desired > flow of control is: > > 1. PE1 sends MVPN-specific signaling to PE2 (using MVPN standard > BGP). > E.g., PE1 might send S-PMSI A-D routes binding (C-S1,C-G1), > (C-S2,C-G2) and (C-S3,C-G3) to a particular P-tunnel. For > this example, let's say that the PMSI Tunnel Attribute (PTA) > identifies the P-tunnel using an mLDP P2MP FEC element: > . > > 2. PE2 receives this S-PMSI A-D route. > > 3. PE2 needs to receive, say, traffic, and so needs > to join > the P-tunnel. > > 4. PE2 sends a "P-tunnel Join Request" message to ABR2, specifying > the > P-tunnel. > > 5. ABR2 adds PE2 to an RSVP-TE P2MP LSP tunnel of which ABR2 is > the > headend. > > 6. ABR2 send a "P-tunnel Join Response" to PE2, telling it that > the > tunnel is being carried within > an identified RSVP-TE P2MP LSP. If the RSVP-TE P2MP LSP is > aggregating other P-tunnels, PE2 would include an upstream-assigned > label. > > 7. ABR2 sends ABR1 a "P-tunnel Join Request" message. > > .... > > etc. Please note that what you outlined above follows pretty close to the Internet multicast for PIM-SM in SSM mode procedures specified in the seamless-mcast draft. E.g., with these procedures the ability of a PE to send a Leaf A-D route to another ABR does not depend on the PE's having first receive any A-D route from that ABR. While in the current seamless-mcast spec on the egress PEs these procedures are triggered by receiving PIM or IGMP message from their CEs, the trigger could be augmented by receiving S-PMSI A-D routes with a particular Tunnel Type in the PMSI Tunnel attribute. From that point on, one would just follow the currently specified seamless-mcast procedures for Internet multicast for PIM-SM in SSM mode. There is no need to invent a new "P-tunnel Join Request" message - the existing Leaf A-D route is sufficient. Likewise, there is no need to invent a new "P-tunnel Join Response" message - the existing MVPN S-PMSI A-D route is sufficient. So, the control flow model that you asked above could be provided within the framework of the current seamless-mcast draft. Yakov. From rahul@juniper.net Fri May 27 10:12: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 46FD5E0830 for ; Fri, 27 May 2011 10:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 frDuQhpJhtGk for ; Fri, 27 May 2011 10:12:30 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1FE0826 for ; Fri, 27 May 2011 10:12:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTd/bcGwVkW3bPP+UjUR6H7ayF+6B/8aF@postini.com; Fri, 27 May 2011 10:12:24 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; Fri, 27 May 2011 10:10:33 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p4RHAWv68862; Fri, 27 May 2011 10:10:32 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Fri, 27 May 2011 10:10:33 -0700 From: Rahul Aggarwal To: Eric Rosen In-Reply-To: <20861.1306327762@erosen-linux> Message-ID: <20110527084928.C47885@sapphire.juniper.net> References: <20861.1306327762@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 27 May 2011 17:12:31 -0000 Hi Eric, Please see inline: On Wed, 25 May 2011, Eric Rosen wrote: > > No/Do not Support. > > 1. The procedures for setting up P-tunnels across a seamless MPLS > environment violate most of the requirements expressed in the "seamless > MPLS" draft. In particular, it is proposed to get the ABRs intimately > involved in the MVPN-specific service signaling. This violates the > "seamless MPLS" requirement that the "transport nodes" (such as the ABRs) > not have service-specific procedures, and that they should not have to > maintain service-specific states. If one wants to use BGP to set up > P-tunnels in a seamless environment, the NLRI should be a P-tunnel > identifier, not a customer multicast flow identifier. > > I will develop this point in another thread and suggest an alternate > approach. > draft-raggarwa-mpls-seamless-mcast does provide the building blocks which do not require service signaling on ABRs. The draft makes a careful choice on the state that should be placed on the ABRs and the state that should not be on the ABRs. For example MVPN C-multicast routes are not required to be on ABRs. There are good reasons, described in response to your other thread by Yakov, for using the ABRs as RRs for I/S-PMSI A-D routes. Also, please see the response by Yakov on how your alternative approach could be supported within the framework of draft-raggarwa-mpls-seamless-mcast. > 2. I think the handling of Internet multicast is the wrong approach. It > would be a lot simpler to treat "global table" multicast just like MVPN > multicast, just using a special RD and RT to distinguish the global table > from the VRFs. Instead, this draft tries to do global table multicast > without using the C-multicast routes, but just with the A-D routes. > There is no reason for this different way of handling multicast, it just > creates unnecessary complexity. > Without getting into debate on whether treating "global table" multicast "just like MVPN" is "a lot simpler", and whether the approach described in the draft "creates unnecessary complexity", let me point out that draft-raggarwa-mpls-seamless-mcast does not preclude treating "global table" multicast just like MVPN. In fact, since draft-raggarwa-mpls-seamless-mcast does apply to MVPN, draft-raggarwa-mpls-seamless-mcast does support the model you described above, where "global table" multicast is treated just ike MVPN. However not all Service Providers are willing to buy into this model, just like not all SPs are willing to put Internet unicast in a VRF. Hence the draft describes an alternate model > Since I think this draft takes the wrong approach on two very important > topics, The draft does not "take the wrong approach" on these two topics. Please see above and the response by Yakov. Your comments are in no way fundamental and should not prevent the draft from being adopted as a WG draft and allow the WG to work on improving it. rahul From rahul@juniper.net Fri May 27 10:15: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 9EE87E0820 for ; Fri, 27 May 2011 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UboyHqK7mCDi for ; Fri, 27 May 2011 10:15:00 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id EAE57E082E for ; Fri, 27 May 2011 10:14:53 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTd/cDfFkD2pTfZrKwfPmw5c9Sk97zM/n@postini.com; Fri, 27 May 2011 10:14:59 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; Fri, 27 May 2011 10:12:56 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p4RHCuv70136; Fri, 27 May 2011 10:12:56 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Fri, 27 May 2011 10:12:56 -0700 From: Rahul Aggarwal To: Loa Andersson In-Reply-To: <4DCBE7BE.5010708@pi.nu> Message-ID: <20110527101244.Q47885@sapphire.juniper.net> References: <4DCBE7BE.5010708@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Cc: Ross Callon , mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 27 May 2011 17:15:00 -0000 Hi Loa, Yes/support. rahul On Thu, 12 May 2011, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > 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 on May 27th. > > /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 fjjc@tid.es Fri May 27 12:26: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 3495BE07D5 for ; Fri, 27 May 2011 12:26:44 -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 AUfhiS5zT+Gm for ; Fri, 27 May 2011 12:26:43 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 162ACE0794 for ; Fri, 27 May 2011 12:26:43 -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 <0LLV005ISCOHDJ@tid.hi.inet> for mpls@ietf.org; Fri, 27 May 2011 21:26:41 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 14.15.02885.014FFDD4; Fri, 27 May 2011 20:57:21 +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 <0LLV005IMCOHDJ@tid.hi.inet> for mpls@ietf.org; Fri, 27 May 2011 21:26:41 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Fri, 27 May 2011 21:26:41 +0200 Date: Fri, 27 May 2011 21:26:36 +0200 From: FRANCISCO JAVIER JIMENEZ CHICO In-reply-to: <20110527101244.Q47885@sapphire.juniper.net> To: Rahul Aggarwal , Loa Andersson Message-id: <4FE737A7257DB84C8CB36B7DFAFCC1CB4A0211F29E@EXCLU2K7.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [mpls] poll on draft-raggarwa-mpls-seamless-mcast Thread-index: AcwckbHXFZ0cedJFT36C9KYcvbEtywAEkgsg acceptlanguage: en-US X-AuditID: 0a5f4068-b7beeae000000b45-33-4ddff410fb4e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsXCFe/ApSv45b6vwbcNzBa3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq8L99kKpolVbLx7m6mB8YxoFyMHh4SAicTWTRVdjJxAppjE hXvr2UBsIYGNjBJrDkd0MXIB2T8YJQ6sO8UK4TQySsy4u4UFpJlFQFViQTM7SAObgJHE7YYm sGZhATuJWYsmMYLYnAKWEvM+nGAGsUUEHCW+NM0Hq2cW2MwoseKKCcgYXgFPiT8vhEDCvAKC Ej8m3wObziygLjFlSi5EtbjEnF8TWSFsRYlpixrApjMCnfz91BomiOn2EmuvHGWHsI0k/i3e zwZRIypxp309I8SLAhJL9pxnhrBFJV4+/scK8W6wxJsj31kmMIrPQnLFLIQrZiG5YhaSKxYw sqxiFCtOKspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJnowdjMt3qhxiFOBgVOLh/bD1nq8Qa2JZ cWXuIUZJDiYlUd6e7/d9hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwmuwHyvGmJFZWpRblw6Rk ODiUJHgzfwGlBItS01Mr0jJzgCkCJs3EwQnSzgPUngBSw1tckJhbnJkOkT/FKCklzmsJkhAA SWSU5sH1vmIUBzpSmDcGJMsDTGZwXa+ABjIBDdT5fRdkYEkiQkqqgXGHylfjpe2Xjj5P/Toh 5GTEWfMs9TN8OXPEboslnpcM7Z0495FfiZPFMoN9f49NTVr6aNnp1KVX+hzvOYt+qd/uUeA9 SfTML1NH/oTjV7T3H4jg2bYweP6K4Azm1X6WbidFJZau7+v/5XXqFO/OR3aHgnh//ki6uXjW LKmqRgHL6uPqzN/Xld9RYinOSDTUYi4qTgQAp0neLiMDAAA= References: <4DCBE7BE.5010708@pi.nu> <20110527101244.Q47885@sapphire.juniper.net> Cc: Ross Callon , "mpls@ietf.org" , "draft-raggarwa-mpls-seamless-mcast@tools.ietf.org" Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 27 May 2011 19:26:44 -0000 WWVzLCBzdXBwb3J0Lg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gRW4gbm9tYnJlIGRl IFJhaHVsIEFnZ2Fyd2FsDQpFbnZpYWRvIGVsOiB2aWVybmVzLCAyNyBkZSBtYXlvIGRlIDIwMTEg MTk6MTMNClBhcmE6IExvYSBBbmRlcnNzb24NCkNDOiBSb3NzIENhbGxvbjsgbXBsc0BpZXRmLm9y ZzsgZHJhZnQtcmFnZ2Fyd2EtbXBscy1zZWFtbGVzcy1tY2FzdEB0b29scy5pZXRmLm9yZw0KQXN1 bnRvOiBSZTogW21wbHNdIHBvbGwgb24gZHJhZnQtcmFnZ2Fyd2EtbXBscy1zZWFtbGVzcy1tY2Fz dA0KDQoNCkhpIExvYSwNCg0KWWVzL3N1cHBvcnQuDQoNCnJhaHVsDQoNCk9uIFRodSwgMTIgTWF5 IDIwMTEsIExvYSBBbmRlcnNzb24gd3JvdGU6DQoNCj4gV29ya2luZyBHcm91cCwNCj4NCj4gdGhp cyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQo+DQo+IGRyYWZ0LXJhZ2dh cndhLW1wbHMtc2VhbWxlc3MtbWNhc3QtMDMudHh0DQo+DQo+IGFuIG1wbHMgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCj4NCj4gSWYgeW91IHN1cHBvcnQgdGhlIGRvY3VtZW50IGJlY29taW5nIGEg d29ya2luZyBncm91cCBkb2N1bWVudA0KPiBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHBvbGwgd2l0 aCAieWVzL3N1cHBvcnQiDQo+DQo+IElmIHlvdSBkbyBub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQg YmVjb21pbmcgYSB3b3JraW5nIGdyb3VwDQo+IGRvY3VtZW50IHBsZWFzZSByZXNwb25kIHRvIHRo aXMgcG9sbCB3aXRoICJuby9kbyBub3Qgc3VwcG9ydCINCj4gYW5kIGF0IHRoZSBzYW1lIHRpbWUg Z2l2ZSB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgd2h5IHlvdSBhcmUNCj4gbm90IHN1cHBvcnRpbmcg dGhlIGRvY3VtZW50Lg0KPg0KPiBJZiB5b3UgaGF2ZSB0ZWNobmljYWwgY29tbWVudHMgb3IgaW4g YW55IG90aGVyIHdheSB3YW50IHRvDQo+IGRpc2N1c3MgdGhlIGRvY3VtZW50LCBwbGVhc2Ugc2Vu ZCB0aGVzZSBjb21tZW50cyB0byB0aGUgbXBscw0KPiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dCwgYnV0IHdpdGggYW5vdGhlciBzdWJqZWN0IHRoYW4gd2hhdA0KPiBpcyBvbiB0aGlzIG1haWwu DQo+DQo+IFRoZSBwb2xsIGVuZHMgb24gTWF5IDI3dGguDQo+DQo+IC9Mb2ENCj4NCj4gLS0NCj4N Cj4NCj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFu ZGVyc3NvbkBlcmljc3Nvbi5jb20NCj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2Vy ICAgICAgICAgICAgbG9hQHBpLm51DQo+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAg ICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1w bHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBs cyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUg ZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBz aXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJ TkFTL2Rpc2NsYWltZXIuYXNweA0K From mn1921@att.com Fri May 27 14:40: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 EDB30E077D for ; Fri, 27 May 2011 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YAlXkRmxu0nW for ; Fri, 27 May 2011 14:40:09 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 62D09E0658 for ; Fri, 27 May 2011 14:40:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1306532407!19840871!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13865 invoked from network); 27 May 2011 21:40:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 May 2011 21:40:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4RLd2an032226; Fri, 27 May 2011 17:39:02 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4RLd0FQ032201; Fri, 27 May 2011 17:39:00 -0400 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, 27 May 2011 17:38:36 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20092105E9@misout7msgusr7e.ugd.att.com> In-Reply-To: <201105271620.p4RGKWv46513@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] MVPN in the "seamless MPLS" environment Thread-Index: Acwcijiu6v3TpZaoTimzNymyahNycgAJlNvg References: <20900.1306328015@erosen-linux> <201105271620.p4RGKWv46513@magenta.juniper.net> From: "NAPIERALA, MARIA H (ATTSI)" To: "Yakov Rekhter" Cc: mpls@ietf.org Subject: Re: [mpls] MVPN in the "seamless MPLS" environment 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, 27 May 2011 21:40:10 -0000 > When one can perform aggregation at the granularity of intra-area > segments, there are good reasons *not* to perform aggregation at > the granularity of inter-area p2mp LSPs. This is because when > aggregating p2mp LSPs, to reduce b/w inefficiency, one need to > perform leaf tracking. The overhead of leaf tracking, when aggregation > is performed at the level of inter-area p2mp LSPs, is higher than > when aggregation is done at the level of the intra-area segments. > Furthermore, aggregation at the level of inter-area p2mp LSPs reduces > the choices that could be applied at the level of intra-area segments, > which has adverse impact on the ability to reduce b/w inefficiency > (b/w inefficiency is due to partial congruence). The problem with the aggregation done only at the intra-area level is that the ABRs need to participate in leaf tracking for specific customer (*,G) or (S,G) states.=20 It is not desirable from SP core network stability/scalability standpoint to have such "service" visibility on ABRs. It goes against a design principle stated in the seamless-mpls, in 2.1. "Why Seamless MPLS": "The Seamless MPLS architecture [...] decuples the service and transport layer". In addition, the "aggregation" at the inter-area level is not only used in conjunction with leaf tracking but it also allow to control the number of P-tunnels that need to be signaled across SP network. This is possible only when PMSI A-D routes are exchanged between service nodes/PEs out-of-band. _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sat May 28 22:16: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 E3AD6E068E for ; Sat, 28 May 2011 22:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLvcT4Wt5a0t for ; Sat, 28 May 2011 22:16:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA3E0685 for ; Sat, 28 May 2011 22:16:25 -0700 (PDT) Received: from [60.247.107.126] (unknown [60.247.107.126]) (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 0FB432A8001; Sun, 29 May 2011 07:16:17 +0200 (CEST) Message-ID: <4DE1D69F.40009@pi.nu> Date: Sun, 29 May 2011 13:16:15 +0800 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" References: <4DC95D08.7060305@pi.nu> In-Reply-To: <4DC95D08.7060305@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , MPLS-TP ad hoc team , draft-ietf-mpls-tp-li-lb@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 05:16:26 -0000 Working Group, this last call has ended. There has been comments, could the authors please resolve the comments and publish a new version of the document. /Loa for the MPLS wg chairs On 2011-05-10 23:43, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > > draft-ietf-mpls-tp-li-lb-01.txt > > Please send your comments to the mpls@ietf.org mailing list. > > This working group last call ends on May 25th. > > /Loa > > for 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 thomas.morin@orange-ftgroup.com Mon May 30 03:02: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 DA86CE0692 for ; Mon, 30 May 2011 03:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 EIRo6+LU1Uc2 for ; Mon, 30 May 2011 03:02:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 897B1E0686 for ; Mon, 30 May 2011 03:02:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3CA768B81E3; Mon, 30 May 2011 12:02:41 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 200368B8005; Mon, 30 May 2011 11:58:50 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 11:57:32 +0200 Received: from [10.193.71.142] ([10.193.71.142]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 11:57:32 +0200 Message-ID: <4DE36A0C.7000709@orange-ftgroup.com> Date: Mon, 30 May 2011 11:57:32 +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, Eric Rosen References: <20861.1306327762@erosen-linux> In-Reply-To: <20861.1306327762@erosen-linux> X-TagToolbar-Keys: D20110530115732040 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 May 2011 09:57:32.0256 (UTC) FILETIME=[FE5D9E00:01CC1EAF] Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 30 May 2011 10:02:42 -0000 Hello Eric, working group, Eric Rosen: > 1. The procedures for setting up P-tunnels across a seamless MPLS > environment violate most of the requirements expressed in the "seamless > MPLS" draft. In particular, it is proposed to get the ABRs intimately > involved in the MVPN-specific service signaling. This violates the > "seamless MPLS" requirement that the "transport nodes" (such as the ABRs) > not have service-specific procedures, and that they should not have to > maintain service-specific states. I don't think that there are contradictions between draft-leymann-mpls-seamless-mpls and draft-raggarwa-mpls-seamless-mcast. First, the unicast seamless MPLS architecture strongly relies on region boundaries (ie. ABRs) to improve scaling, and this is precisely the spirit of the seamless MPLS multicast proposal. Second, if you read the last ยง of section 2.1 or the unicast focused "seamless MPLS" draft, the motivation for decoupling service and transport is essentially presented in a configuration overhead perspective; the seamless MPLS multicast proposal does not require per-service configuration and is thus completely in line with this. Last, let's keep in mind that the seamless MPLS draft is itself quite modest on how much it applies to multicast ("Currently, this document focus on end to end unicast LSP") and that what the seamless MPLS draft says on states in "transport nodes" is that they "*ideally* have no customer or service state" (emphasis mine) : far from being formulated as an fundamental requirement or as an architecture principle, it sounds as possibly open to a tradeoff. So well... no surprise to see someone co-authoring both drafts ! ;-) That said, generally speaking, I don't think that we should even shape the debate by applying as-is unicast-focused principles. I will restate the obvious, but the solutions that have been designed to enable multicast connectivity in flat IP or VPN environnement can actually be considered as "violating" what is often considered as key principle for unicast: these solutions introduced the possibility for multicast per-VPN and/or per-session control plane and/or dataplane state in the network. This is a necessary tradeoff. So, it looks more reasonable to me to discuss precisely which (claimed) problems are brought by the proposal and whether or not this is problematic in a context such as the one described in the "seamless MPLS" draft (and we should carefully distinguish between configuration state, control plane state, and dataplane state). The seamless MPLS multicast architecture provides tools that are a solid tradeoff to scale multicast MPLS in such context. That it is at the expense of some state in ABRs does not prevent this solution from being a good solution. In fact, the leaf tracking issue happens to be reduced to a smaller issue by introducing some state in ABRs. -Thomas, co-author *and* supporting WG adoption ! From internet-drafts@ietf.org Mon May 30 09:13:46 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 29862E0804; Mon, 30 May 2011 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Xbe0FzorPCtB; Mon, 30 May 2011 09:13:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC40E06A2; Mon, 30 May 2011 09:13:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110530161345.27739.71357.idtracker@ietfa.amsl.com> Date: Mon, 30 May 2011 09:13:45 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-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: Mon, 30 May 2011 16:13:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-00.txt Pages : 47 Date : 2011-05-30 This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS appro= ach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mpls-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mpls-00.txt From db3546@att.com Tue May 31 07:45: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 DFB1CE078F for ; Tue, 31 May 2011 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 UE7x05fwkfXT for ; Tue, 31 May 2011 07:45:25 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id AC34EE0789 for ; Tue, 31 May 2011 07:45:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1306853123!19617517!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16277 invoked from network); 31 May 2011 14:45:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 May 2011 14:45:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4VEiIZu013221 for ; Tue, 31 May 2011 10:44:18 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4VEiGiX013210 for ; Tue, 31 May 2011 10:44:16 -0400 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, 31 May 2011 10:45:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt Thread-Index: AcwcmVIl5XeruN3TSbuHZmDxQFWWbQDB+G2g From: "BRUNGARD, DEBORAH A (ATTSI)" To: Subject: [mpls] FW: [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:45:29 -0000 FYI - Please send any comments to the ccamp mailing list- -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTSI) Sent: Friday, May 27, 2011 2:10 PM To: CCAMP Subject: [CCAMP] WG last call on draft-ietf-ccamp-attribute-bnf-01.txt This mail begins a WG last call on: http://www.ietf.org/id/draft-ietf-ccamp-attribute-bnf-01.txt This working group last call ends on June 10th. Please send comments to the CCAMP mailing list. Deborah (and Lou) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From krbalaji.in@gmail.com Tue May 31 08:23:49 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 0E1C3E0714 for ; Tue, 31 May 2011 08:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqFujZmAOvIO for ; Tue, 31 May 2011 08:23:44 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2A95E0677 for ; Tue, 31 May 2011 08:23:44 -0700 (PDT) Received: by yxk30 with SMTP id 30so2497189yxk.31 for ; Tue, 31 May 2011 08:23:44 -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=1NfVcS4On6CzTuxEILiEdEmkL0kAHVy8PFdQTkEo8Ps=; b=W+MJcpY7YsLbia/5UaB7U0TvDlG4MJvk/FwPzz4snGHaJEQQD6GZDm4xGi9O614FdK 4M3mfxwSiLaVGZ+pF5ZhePIVPyJfT9RWPQIS4tAOA2BTv4kcivACUJMY0NjrLmIXsagE 526rZfZfi4blUin0szlUD5R58KBmkcqsckeQc= 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=eS+5y/e4pqY013ITfZE9fW2STucm8kkFxX8NpoZK4gul9Ud6HwZbmi3aECucUaLGId Y7MC9muNkBhF9nZ4iUcLa1srBxqNC7WVj0V/RTSMyaMyBc4EbHmjBdcI9tBe9UPDOd3g klIX9OYAPBZ2V6MZpwsqoZhQwSEcQCHSynkRU= Received: by 10.236.195.102 with SMTP id o66mr7160790yhn.364.1306855424079; Tue, 31 May 2011 08:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.203.226 with HTTP; Tue, 31 May 2011 08:23:24 -0700 (PDT) In-Reply-To: <9762ACF04FA26B4388476841256BDE020114423E18B2@HE111543.emea1.cds.t-internal.com> References: <4DCBE7BE.5010708@pi.nu> <9762ACF04FA26B4388476841256BDE020114423E18B2@HE111543.emea1.cds.t-internal.com> From: Balaji KR Date: Tue, 31 May 2011 20:53:24 +0530 Message-ID: To: N.Leymann@telekom.de Content-Type: multipart/alternative; boundary=20cf305b091a53358404a493fde4 Cc: rcallon@juniper.net, mpls@ietf.org, draft-raggarwa-mpls-seamless-mcast@tools.ietf.org Subject: Re: [mpls] poll on draft-raggarwa-mpls-seamless-mcast 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, 31 May 2011 15:23:49 -0000 --20cf305b091a53358404a493fde4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support. On Tue, May 24, 2011 at 12:16 AM, wrote: > Support! > > Regards > > Nic > > -----Urspr=FCngliche Nachricht----- > Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von > Loa Andersson > Gesendet: Donnerstag, 12. Mai 2011 15:59 > An: mpls@ietf.org; draft-raggarwa-mpls-seamless-mcast@tools.ietf.org; Ros= s > Callon; George Swallow > Betreff: [mpls] poll on draft-raggarwa-mpls-seamless-mcast > > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > 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 on May 27th. > > /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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf305b091a53358404a493fde4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support.

On Tue, May 24, 2011 at 12:16 AM= , <N.Leymann@= telekom.de> wrote:
Support!

=A0Regards

=A0 Nic

-----Urspr=FCngliche Nachricht-----
Von: mpls-bounces@ietf.org [ma= ilto:mpls-bounces@ietf.org] Im= Auftrag von Loa Andersson
Gesendet: Donnerstag, 12. Mai 2011 15:59
An: mpls@ietf.org; draft-raggarwa-mpls-seaml= ess-mcast@tools.ietf.org; Ross Callon; George Swallow
Betreff: [mpls] poll on draft-raggarwa-mpls-seamless-mcast

Working Group,

this is to start a two week poll on making

draft-raggarwa-mpls-seamless-mcast-03.txt

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 on May 27th.

/Loa

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13
_______________________________________________
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

--20cf305b091a53358404a493fde4-- From rajiva@cisco.com Tue May 31 17:54: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 F1754E0763 for ; Tue, 31 May 2011 17:54:17 -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 8VEAiPYBCvEg for ; Tue, 31 May 2011 17:54:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 516A7E0756 for ; Tue, 31 May 2011 17:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=154; q=dns/txt; s=iport; t=1306889656; x=1308099256; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=dbBWL9Am9k8+T8RGdpIOs3+HpV+o5/Wn0Q1gpXNh0D0=; b=GEEp4b6JP+xT/7pJlX0SRfkl7Cf+M43PQ6lkNCdXQxwOGgTxBFFZdi3A mmDR7qpY+x7TtMKiUcddNfR72jlZewSAwUuHtGYgroDrGK3Q7QjcZkBXG ncuqznErKt+TJArqSNJ/Y2QunHMdOmNR17C3yUwX8eyLKj81vUVY/nQGo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgHAFKN5U2tJV2b/2dsb2JhbABTmA2OEnenW51ThiAEhmSOOop3 X-IronPort-AV: E=Sophos;i="4.65,300,1304294400"; d="scan'208";a="706144295" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2011 00:54:15 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p510sFgZ006087; Wed, 1 Jun 2011 00:54:15 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 May 2011 19:54:14 -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, 31 May 2011 19:54:13 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C051D2959@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for WGLC draft-ietf-mpls-ldp-ipv6-04 Thread-Index: Acwf9mz5PnsQCvsSRg2FFQRvUffsUA== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 01 Jun 2011 00:54:15.0052 (UTC) FILETIME=[6DBE84C0:01CC1FF6] Cc: mpls@ietf.org Subject: [mpls] Request for WGLC draft-ietf-mpls-ldp-ipv6-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 00:54:18 -0000 Loa, George, The authors believe that draft-ietf-mpls-ldp-ipv6-04 is ready for the WGLC. Could you please advise the next step? Cheers, Rajiv=20