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

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

I am not the one who brought G.8113.1 on the table. I was replying to a mail 
that did that arguing why this is relevant.

>----Messaggio originale----
>Da: [email-masked]
>Data: 4-mag-2011 2.53
>A: "[email-masked]"<[email-masked]>, "eric.
[email-masked]"<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"<[email-masked]>
>Ogg: RE: [mpls] R: Re:  Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>Comments inline.
>
>Sent from my iPhone
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Monday, May 02, 2011 3:32 PM
>> To: [email-masked]; [email-masked]; [email-masked]
>> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
>> Identifiers?
>> 
>> 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", and 
what does either topic have to do with the identifiers draft?
>
>> 
>> 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
>
>> 
>> Could you provide some reference about this? I might have missed them.
>> 
>> ----Messaggio originale----
>> Da: [email-masked]
>> Data: 28-apr-2011 23.17
>> A: "[email-masked]"<[email-masked]>,
>> "[email-masked]"<mpls@ietf.
>> org>
>> Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> Huub,     Please see below... --Eric
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Huub
>> van Helvoort
>> Sent: Thursday, April 28, 2011 6:44 AM
>> To: [email-masked]
>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>> 
>> Hi Malcolm,
>> 
>> You wrote:
>> John, if you do not allow mix identifier types how can you have an end
>> to end
>> CV message.  If you are using stitching to allow a single identifier
>> type then
>> the identifiers in a CV message must be translated at the stitching
>> point.  A
>> very bad idea!
>> Indeed!
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>> 
>> Sent from my mobile device. John E Drake <[email-masked]>
>> 27/04/2011 07:25
>> PM
>> To"[email-masked]" <[email-masked]> ccEric Gray
>> <eric.
>> [email-masked]>, "[email-masked]" <[email-masked]>, "mpls-
>> [email-masked]"
>> <[email-masked]> SubjectRE: [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]>, "mpls-
>> [email-masked]"
>> <[email-masked]> SubjectRE: [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
>> 
>> ToGeorge Swallow <[email-masked]>, "[email-masked]" <[email-masked]>
>> cc
>> SubjectRe: [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.
>> 
>> 
>> 
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 May 2011 12:21:22 -0400

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? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 5:19 PM
To: [email-masked]; Eric Gray; [email-masked]; [email-masked]
Subject: R: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Importance: High

>> I interpreted Eric's use of  'stitching'  to be in the RFC 5150 sense.
>> I
>> 'stitched'
>> That's incorrect.  There is a single end-to-end LSP composed of
>> different