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

From: "[email-masked]" <[email-masked]>
Date: Mon, 2 May 2011 23:57:46 +0200 (CEST)

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: [email-masked]
Data: 28-apr-2011 1.11
A: <[email-masked]>
Cc: "[email-masked]"<[email-masked]>, <[email-masked]>
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, <[email-masked]> 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 <[email-masked]> 
Sent by: [email-masked] 27/04/2011 12:11 PM 
ToGeorge Swallow <[email-masked]>, "[email-masked]" <[email-masked]> 
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: [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

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 2 May 2011 18:31:36 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 02, 2011 2:58 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

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: [email-masked]
Data: 28-apr-2011 1.11
A: <[email-masked]>
Cc: "[email-masked]"<[email-masked]>, <[email-masked]>
Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Dear Malcolm,

Regards,
Greg

Eric, 

Regards, 

Malcolm 

  

All -

---

From: <[email-masked]>
Date: Tue, 3 May 2011 09:48:07 +0100

Hi Greg,

A lesson that should have been learned a long time ago is that the most sensible/obvious OAM identifier to use in CV-like OAM packets in co-cs/co-ps mode layer networks is the actual source address of the layer network connection (in cl-ps mode networks we are forced to place this in each/every traffic unit as we cannot take labelling short-cuts here as we have no connection 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 uniqueness in a 1:1 sense wrt the 2 sets.  So all one has gained is additional complexity via such a mapping.  Not a great idea IMO.

Aside=> A long time ago some operators used to use text-like strings to identify co-cs mode connections....simply because this is what their Operations folks were used to.  It's not a good arch solution of course for OAM message misconnectivity detection purposes.

However, you are right in a sense below if you are considering some E-NNI case between 2 different network operators.  This however, seems a very strange basis on which to justify allowing different addressing schemes in a single horizontally partitioned non-TOS layer network, as it is quite trivial to prove that such peer interworking cases are technically quite unnecessary.  Good as a job creation scheme however.....and I have never known a single technology promoting forum not promote E-NNIs despite their being unnecessary in all non-TOS cases ;-)

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gregory Mirsky
> Sent: 02 May 2011 23:32
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: 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
> 
> 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?
> 
>