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

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

See in line

>----Messaggio originale----
>Da: [email-masked]
>Data: 4-mag-2011 2.48
>A: "[email-masked]"<[email-masked]>, "Malcolm.
[email-masked]"<[email-masked]>
>Cc: "[email-masked]"<[email-masked]>, "[email-masked]"<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: [email-masked] [mailto:[email-masked]]
>> Sent: Monday, May 02, 2011 3:13 PM
>> To: John E Drake; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: R: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP
>> Identifiers?
>> 
>> If my name is XYZ and your name is 123, I do want to change my name in
>> order to
>> talk to you.
>> 
>> 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 defined, 
the endpoints of a given LSP or pseudowire MUST be able to use different 
identifier types"?

Well, if you force one of the two domains to adapt the identifier type of the 
other domain, the endpoints of a given LSP or MS-PW MUST be able to use 
different identifier types. Reading RFC5680 I see that it is requried to 
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 
can see both your proposal as well as ITU-T proposal are "late breaking 
requirements" wrt RFC5860.

>> 
>> 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 
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 
solution proposed by ITU-T and you would prefer to force the two endpoints to 
use the same identifier scheme.

The problem I see with your proposed solution is that this will force one of 
the two operators to support two identifier schemes: one for intra-domain 
LSP/PW and inter-domain LSP/PW that use its own identifier scheme and one for 
the inter-domain LSP/PW that use a second identifier scheme.

I am expecting that the early deployments of MPLS-TP will be private 
supporting only intra-domain LSP/PW so the operator most likely will 
instantiate just its own identification scheme. The day the first inter-domain 
LSP/PW is needed, the operator is required to put in place a second/parallel 
identification scheme (and mapping). I do not think this approach goes in the 
direction to simplify operations nor of enabling global connectivity.

>This is a very different statement, and seems eminently reasonable to me.
>
>> 
>> Have I missed some requirement?
>> 
>> ----Messaggio originale----
>> Da: [email-masked]
>> Data: 28-apr-2011 18.22
>> A: "[email-masked]"<[email-masked]>
>> Cc: "[email-masked]"<[email-masked]>, "[email-masked]"<mpls-
>> bounces@ietf.
>> org>
>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> Comments inline.
>> 
>> Sent from my iPhone
>> 
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, April 27, 2011 8:25 PM
>> To: John E Drake
>> Cc: Eric Gray; [email-masked]; [email-masked]
>> Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> 
>> John,
>> 
>> John, if you do not allow mix identifier types how can you have an end
>> to end
>> CV message.
>> JD:  The endpoints have to agree on a common format for the data plane.
>> That’
>> s the whole point of the discussion.
>>  If you are using stitching to allow a single 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.
>> 
>> 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.
>> 
>> Regards,
>> 
>> Malcolm
>> 
>> 
>> 
>> John E Drake <[email-masked]>
>> 27/04/2011 07:25 PM
>> To
>> "[email-masked]" <[email-masked]>
>> cc
>> Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>,
>> "mpls-
>> [email-masked]" <[email-masked]>
>> Subject
>> RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> 
>> 
>> 
>> Malcolm,
>> 
>> I interpreted Eric’s use of  ‘stitching’  to be in the RFC 5150 sense.
>> I
>> think I will let him clarify, but if used in the RFC 5150 sense, a
>> ‘stitched’
>> LSP would have end-to-end OAM, and different pieces could use different
>> identifiers in the control and management planes.
>> 
>> Also, as Greg notes, this appears to be a late breaking requirement.
>> 
>> Thanks,
>> 
>> John
>> 
>> Sent from my iPhone
>> 
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, April 27, 2011 4:11 PM
>> To: John E Drake
>> Cc: Eric Gray; [email-masked]; [email-masked]
>> 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 <[email-masked]>
>> 27/04/2011 06:53 PM
>> 
>> To
>> "[email-masked]" <[email-masked]>, Eric Gray <eric.
>> [email-masked]>
>> cc
>> "[email-masked]" <[email-masked]>, "[email-masked]" <mpls-
>> bounces@ietf.
>> org>
>> Subject
>> RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Malcolm,
>> 
>> That’s incorrect.  There is a single end-to-end LSP composed of
>> different
>> pieces, each under the control of a different administrative entity.
>> 
>> Thanks,
>> 
>> John
>> 
>> Sent from my iPhone
>> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Wednesday, April 27, 2011 3:44 PM
>> To: Eric Gray
>> Cc: [email-masked]; [email-masked]
>> 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 <[email-masked]>
>> Sent by: [email-masked]
>> 27/04/2011 12:11 PM
>> 
>> 
>> To
>> George Swallow <[email-masked]>, "[email-masked]" <[email-masked]>
>> cc
>> Subject
>> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> As one of the co-authors on this draft, I support a restriction to
>> using a
>> common
>> form of identifier throughout an LSP or PW.
>> 
>> In my opinion, it is far better to terminate LSPs or PWs at the point
>> where
>> there
>> might be an identifier form change and "stitch" them together if that
>> is what
>> the
>> operators want/agree to do.  This limits the need-to-know for the
>> mapping of
>> one
>> form of identifier to the other to the point at which this occurs,
>> rather than
>> at each
>> node in the LSP or (potentially) MS-PW.
>> 
>> 
>> 
>> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> George
>> Swallow
>> Sent: Monday, April 25, 2011 5:17 PM
>> To: [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
>> 
>
>