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

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

Forwarding the messate to the MPLS WG mailing list ...

----Messaggio originale----
Da: [email-masked]
Data: 2-mag-2011 23.41
A: <[email-masked]>
Ogg: R: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

1) what about the operational burden to manage two different identifiers for 
the same entities within the same operator's domain?
 
2) This argument is not fully clear.
 
Let's check the different identifiers that are defined and see if there is any 
additional implementation complexity:
 
-> Path identifiers: they are not carried by any protocol istance so what is 
the testing burden?
 
-> MEP identifier: each system should be able to generate its own format of 
MEP-ID and to receive any format of MEP-ID that is defined today and will be 
defined in the future because you cannot predict/avoid misconnections between 
MEPs using different identification schemes.
 
I would suggest to take a look at the following draft to understand todays 
best-in-class solution for supporting an extensible and future proof solution 
allowing different types of MEP identification schemes:
 
http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-06
 
The secret spice is to do a bit-by-bit comparision between the expected MEP-ID 
and the received MEP-ID and to define a typed encoding for the MEP 
identifiers.
 
Please note that section 2.1.4 of RFC 5860 requires that the solution must be 
"extensible to support additional identification schemes".
 
-> MIP identifier: the traceroute should discover the MIP-ID at a given TTL 
distance and use that identifier for connectivity verification toward that MIP. 
How can you impose all the MIPs to have the same structure?
 
3) I understood the objective of the work was to allow inter-domain/inter-
provider MPLS-TP deployment with e2e OAM support. When this objective has been 
changed?
 
4) Control plane identifiers are separated from data plane and OAM identifier 
so I think this argument is outside the scope of the draft.

----Messaggio originale----
Da: [email-masked]
Data: 25-apr-2011 23.16
A: <[email-masked]>
Ogg: [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.  

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. 
Such an addition will add numerous object formats, and test cases. 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. 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