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

From: "[email-masked]" <[email-masked]>
Date: Wed, 18 May 2011 23:52:16 +0200 (CEST)

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: [email-masked]
>Data: 9-mag-2011 20.03
>A: "[email-masked]"<[email-masked]>
>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: [email-masked]'; [email-masked]; [email-masked]
>Cc: [email-masked]
>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: [email-masked] [mailto:[email-masked]] 
>Sent: Monday, May 02, 2011 9:46 AM
>To: Eric Gray; [email-masked]; [email-masked]
>Cc: [email-masked]
>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: [email-masked] [mailto:[email-masked]] On Behalf Of Eric 
Gray
>Sent: Thursday, April 28, 2011 10:58 PM
>To: [email-masked]; George Swallow
>Cc: [email-masked]
>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: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
>Sent: Wednesday, April 27, 2011 12:05 AM
>To: George Swallow
>Cc: [email-masked]
>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 <[email-masked]> 
>Sent by: [email-masked] 
>
>25/04/2011 05:16 PM 
>
>	To	<[email-masked]> 
>	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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>