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

From: "[email-masked]" <[email-masked]>
Date: Thu, 19 May 2011 00:14:12 +0200 (CEST)

I did not see any reply to the questions below.

Following the discussions on this draft it appears clear that:

a) it is not possible to impose both operators to use the same identifier 
structure to setup an inter-domain LSP/PW so without mixing ICC and IP 
identifiers it is not possible to define a path identifer for these entities 
(that can and will exist in the network)

b) quoting George Swallow mail on a separate comment, "In an IP/MPLS 
environment, provisioning MIPs is pretty much a non-starter.  Generally 
intermediate nodes respond to all requests (e.g. Ping, MPLS Ping) unless 
configured to filter on things such a source address."

The problem is that if the MIP identifier is assigned according to the 
identification scheme adopted by the node the MIP resides on. As there is no 
provisioning, there is no way to ensure the MIP identification would follow the 
same scheme as the MEP.

Bottom line: not allowing mixing different identification schemes is creating 
more technical issues that it is apparently solving (I think no problem is 
actually solved).

>----Messaggio originale----
>Da: [email-masked]
>Data: 2-mag-2011 23.54
>A: <[email-masked]>
>Ogg: [mpls] I:  Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>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 
>
>
>
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>