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

From: "[email-masked]" <[email-masked]>
Date: Tue, 3 May 2011 00:31:54 +0200 (CEST)

I do not understand how this discussion is related to the OAM debate regarding 
G.8113.1.

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.

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]>, "[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]>, "[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.

---

From: John E Drake <[email-masked]>
Date: Tue, 3 May 2011 17:53:09 -0700

Comments inline.

Sent from my iPhone

> -----Original Message-----
> [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?
> 

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?

> end-to-end OAM nor the need for an OAM interworking function between

JD:  This is simply baffling

> Huub
> George
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls