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

From: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:13:25 -0400

Forwarding in plain text... 

________________________________

From: Mach Chen [mailto:[email-masked]] 
Sent: Sunday, May 22, 2011 11:35 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi Malcolm,

See my response inline...

Ermino,

We have already been round this loop on this list once.
Want to do it again? 

[MB] well the continuation of this thread indicates that the loop is still open....

As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to. 

[MB] OK

To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to. 

[MB] It requires that one of the operators must administer both types of identifiers. 

[Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers, and the operators(only prefer to ICC based Opr_ID) have to support and configure both ICC and Global_ID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr_ID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators.

 This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

This becomes particularly important to the transit nodes that may have to
inspect the identifiers. 

[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string.

[Mach] Here is an example that the transit nodes may require to "inspect" the identifiers: MPLS-TP control plane. Because Opr_ID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr_IDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section.

Best regards,

Mach

BTW, we just submitted two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr_ID when setup an LSP or PW.

http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00

http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00

None of this is new or specific to MPLS-TP.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 18 May 2011 22:25
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> 
> Appendix II of Y.1731 provides a good example about how inter-domain
> connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
> 
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
> 
> http://www.itu.int/rec/T-REC-Y.1731/en
> 
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
> 
> >----Messaggio originale----
> >Da: [email-masked]
> >Data: 4-mag-2011 8.00
> >A: <[email-masked]>,
> "[email-masked]"<[email-masked]>
> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, [email-masked] wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconnection as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <[email-masked]>*
> >> Sent by: [email-masked]
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >>                  "Andrew G. Malis" <[email-masked]>, <[email-masked]>
> >> cc
> >>                  [email-masked]
> >> Subject
> >>                  Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >>  > Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surrounds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <[email-masked]> wrote:
> >>
> >>  > Neil,
> >>  >
> >>  > To your case 1, we're in complete agreement. We (VZ) don't see at
> >>  > least a short-term need for peer-layer interworking, given where we
> >>  > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >>  > layer in the transport core). If peer layer interworking ever becomes
> >>  > a necessity, then obviously we'll need a well-defined E-NNI which
> >>  > would include LSP identifier mapping/translation at the boundary, for
> >>  > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >>  > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >>  > put on the to-do list). This E-NNI would also include similar
> >>  > identifier mapping/translation for MS-PWs, to answer an earlier
> >>  > question from Erminio that I saw on the list.
> >>  >
> >>  > I also agree that both intra-layer and inter-layer mis-connectivity
> >>  > detection and amelioration are required, but I'm not convinced that
> >>  > the already defined mechanisms can't do that. Do you have some
> >>  > specific analysis on the inter-layer case?
> >>  >
> >>  > Cheers,
> >>  > Andy
> >>  >
> >>  > On Tue, May 3, 2011 at 3:36 AM, <[email-masked]> wrote:
> >>  >> Hi Andy,
> >>  >>
> >>  >> 2 points:
> >>  >>
> >>  >> 1 I agree with your view of only having a single addressing scheme in
> a
> >>  >> single layer network solely belonging to one party. Though you may
> >> need to
> >>  >> be rather careful if you also advocate that one can also have peer
> layer
> >>  >> interworking between different parties, ie E-NNIs (I believe this is
> >>  >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >>  >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >>  >> any other variations in DP/CP functional components) if they exist
> >> in the
> >>  >> standards.
> >>  >>
> >>  >> Of course, having an E-NNI and peer interworking between different
> >> parties in
> >>  >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >>  >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >>  >> single addressing scheme in a non-TOS layer network.
> >>  >>
> >>  >>
> >>  >> 2 You should also be aware that in client/server interworking of the
> >>  >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >>  >> important for MPLS-TP in the role of a transport network (I'll
> >> ignore issues
> >>  >> of transparency here), there could be inter-layer misconnectivity
> >> (Aside=>
> >>  >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >>  >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >>  >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >>  >> sublayer misconnectivity).
> >>  >>
> >>  >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >>  >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >>  >> come from (i) networks using different OAM/addressing solutions or
> (ii)
> >>  >> networks using the same OAM/addressing solutions. In both cases
> >> there are
> >>  >> different issues wrt inter-layer misconnectivity one has to deal
> >> with. I'm
> >>  >> not aware that these cases have been considered yet.
> >>  >>
> >>  >>
> >>  >> I'd like to hear your comments on both these points, but in
> >> particular the
> >>  >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >>  >> as there seems to a possible logical conflict here.
> >>  >>
> >>  >> Thanks.
> >>  >>
> >>  >> 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
> >>  >>
> >>  >>> -----Original Message-----
> >>  >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >>  >>> Andrew G. Malis
> >>  >>> Sent: 02 May 2011 20:48
> >>  >>> To: George Swallow
> >>  >>> Cc: [email-masked]
> >>  >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>  >>>
> >>  >>> George et al,
> >>  >>>
> >>  >>> Verizon does not have any requirement for mixed use of Global IDs and
> >>  >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >>  >>> to use one or the other.
> >>  >>>
> >>  >>> Thanks,
> >>  >>> Andy
> >>  >>>
> >>  >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <[email-masked]>
> >>  >>> wrote:
> >>  >>>> 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
> >>  >>>>
> >>  >>>>
> >>  >>> _______________________________________________
> >>  >>> mpls mailing list
> >>  >>> [email-masked]
> >>  >>> https://www.ietf.org/mailman/listinfo/mpls
> >>  >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >--
> >
> >
> >Loa Andersson                         email: [email-masked]
> >Sr Strategy and Standards Manager            [email-masked]
> >Ericsson Inc                          phone: +46 10 717 52 13
> >                                              +46 767 72 92 13
> >_______________________________________________
> >mpls mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> 
> _______________________________________________
> 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: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:14:06 -0400

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, May 22, 2011 3:56 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Thanks Malcolm,

That would work.  Though we would need to know a priori what IDs all other parties were using who could enter in to client/server relationships.

Further, since client/server relationships are THE critical service for a transport network (non-TOS peering is not a good idea IMO for many reasons) this means we can have inter-layer misconnectivity and thus it is simply not tenable to say 'we will only consider IDs from this family' anyway.  Obviously a single CV 'SA' structure that all parties use would be best, but if X SA formats are used then each party really needs to be able to handle incoming misconnected traffic from any of the X SA formats.

regards, Neil

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.

From: [email-masked] [mailto:[email-masked]]
Sent: 22 May 2011 13:36
To: Harrison,N,Neil,DKQ7 R
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Neil,

I should have been more explicit.  We have two forms of Global identifiers, ICC based and IP based, both offer a "real" source ID.  I put "real" in quotes since whilst it is a unique identifier it is not a routable address (in the Ethernet SA sense).

I assume that when we get around to doing the encoding we will have a simple flag to identify which type is being used to both, avoid accidental collisions and allow interpretation.  My assertion is that their is no need, in the data plane, to understand the semantics of the identifier to determine if it is the correct value.

The actual received value can be passed up to an OSS, off line, for further analysis, at which level, using the type flag it should be possible to present the actual location, or at least the network that the OAM PDU was received from.  This will allow the source to be identified so that the actual route can be traced to located the point of the miss-connection.

Regards,

Malcolm

<[email-masked]>

22/05/2011 03:19 AM

        To

        <[email-masked]>, <[email-masked]>

cc

        <[email-masked]>, <[email-masked]>

Subject

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

Malcolm wrote:

"[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string."

IMO this is not a great idea.  Indeed, just inserting any old string of symbols is not a great idea anyway....this was always the major weakness of BFD as originally defined.  One wants a proper SA semantic so that operations folks cannot only detect misconnectivity they can immediately *diagnose* from where it came.

Note also that when we have a nested transparent (one hopes) client/server relationship (which is a pretty fundamental capability for a useful co-ps mode transport network) then:
-       not only must we be able to detect and diagnose a source of misconnectivity from within this layer network (ie intra-layer misconnectivity),
-       we must also be able to detect and diagnose a source of misconnectivity from other layer networks due to a misconnectivity defect in some lower server layer network (ie inter-layer misconnectivity) and not mistake this for intra-layer misconnectivity.

So IMO any identifiers that are used should be pukka SAs.....to use some other structure is not a great idea IMO....and they must not only be unique across all same technology co-ps mode layer networks that can form client/server relationships they must also be known to all such layer networks, ie which party owns a given SA structure, so that rapid operations diagnosis can be made.

I don't think sufficient attention has be paid to the diagnosis point.

regards, Neil

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 [email-masked]
Sent: 22 May 2011 01:04
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Adrian,

Please see in line below.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]

20/05/2011 11:45 AM

Please respond to
[email-masked]

To

        <[email-masked]>

cc

        [email-masked]

Subject

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

Ermino,

[MB] OK

[MB] It requires that one of the operators must administer both types of identifiers.  This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:14:43 -0400

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, May 22, 2011 8:36 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Neil,

Regards,

Malcolm

<[email-masked]>

22/05/2011 03:19 AM

To

Malcolm wrote:

regards, Neil

BT Design

Adrian,

Regards,

Malcolm

20/05/2011 11:45 AM

Please respond to
[email-masked]

To

Ermino,

[MB] OK

Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:15:19 -0400

Sent: Sunday, May 22, 2011 3:20 AM

Malcolm wrote:

regards, Neil

BT Design

Adrian,

Regards,

Malcolm

20/05/2011 11:45 AM

Please respond to
[email-masked]

To

cc

        [email-masked]

Subject

Ermino,

[MB] OK

Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:15:49 -0400

From: Mach Chen [mailto:[email-masked]] 
Sent: Monday, May 23, 2011 6:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi, 

Please see my response inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, May 22, 2011 8:04 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Adrian, 

Regards, 

Malcolm 

20/05/2011 11:45 AM 

Please respond to
[email-masked]

To

cc

	[email-masked] 

Subject

 

Ermino,

[MB] OK

Best regards,

Mach

Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 1 Jun 2011 14:15:52 -0400

From: Maarten vissers [mailto:[email-masked]]
Sent: Tuesday, May 24, 2011 1:39 AM
To: [email-masked]
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

As Malcolm indicates, an ID mismatch process has to determine if there is a match/mismatch between the expected ID and the received ID.  Such match/mismatch detection process compares the received bit pattern with the expected bit pattern. There is no need for the mismatch process to understand the structure of the bit patterns.

The received and accepted ID bit pattern is reported to NMS/GMPLS on request of NMS/GMPLS. NMS can present the received ID on a GUI. At this point it is helpful if the ID bit pattern is presented as an ICC, Domain Name based sting, MAC address + 2-octet integer or Character string  structured ID (case of Ethernet/VPLS), or an ICC or Global-ID structured ID (case of MPLS-TP). In order to present the structured ID correctly on a GUI, the ID should include a format field, format length field and an ID field. Refer to MAID field in clause 21.6.5/802.1ag as an example.

Regards,

Maarten

Sent: 24 May 2011 02:42
To: Mach Chen

Hi Mach,

Please see in line below - marked by [MB2]

Regards,

Malcolm

Mach Chen <[email-masked]>

22/05/2011 11:34 PM

        To

        "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

cc

        "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

Hi Malcolm,

Ermino,

[MB] OK

[MB] It requires that one of the operators must administer both types of identifiers.
[Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers,
[MB2] Why?  As I have explained several times on this thread a node that receives an OAM message only needs to check that it is from the expected entity, no need to understand or administer the format.
 and the operators(only prefer to ICC based Opr_ID) have to support and configure both ICC and Global_ID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr_ID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators.
 This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting.

[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string.
[Mach] Here is an example that the transit nodes may require to "inspect" the identifiers: MPLS-TP control plane. Because Opr_ID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr_IDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section.
[MB2]  As defined in the architecture the data plane and control plane must be independent, including the identifiers that they use.
Best regards,
Mach

BTW, we just submitted two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr_ID when setup an LSP or PW.
http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 <http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00>
http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 <http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00>

Adrian