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

From: Mach Chen <[email-masked]>
Date: Tue, 24 May 2011 02:15:32 +0000

Hi Malcolm,

Thanks for your prompt response!

Please see my reply inline...

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 8:42 AM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> 
> 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
> 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,

> [MB2] Why?  

If it's static provisioning, the operators need to configure(by CLI or NMS) the identifiers(include both ICC and Global_ID) on the related nodes.
If there is control plane, the control plane has to communicate the identifiers, and all the nodes along the LSP need to know the type firstly and hence to interpret and process it 

>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.

How could a node do that if it does not know the type of the identifier? 

>  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.
> [MB2]  As defined in the architecture the data plane and control plane must
> be independent, including the identifiers that they use.

But, MPLS-TP identifiers should be not exclusive to data plane or control plane or management plane, and actually they are related to all the three planes.

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
>

---

From: [email-masked]
Date: Tue, 24 May 2011 01:32:37 -0400

Hi Mach,

Please see in line below.

Mach Chen <[email-masked]> wrote on 23/05/2011 10:15:32 PM:

> If it's static provisioning, the operators need to configure(by CLI 
> or NMS) the identifiers(include both ICC and Global_ID) on the related 
nodes.
> If there is control plane, the control plane has to communicate the 
> identifiers, and all the nodes along the LSP need to know the type 
> firstly and hence to interpret and process it

[MB] No need for the nodes to understand the semantics, it may be 
convenient to have an OSS or GUI application that does understand the 
semantics to assist in provisioning the expected value.  The control plane 
should be able to carry an opaque type.  I would expect that when the 
encoding of these identifiers is defined it will include a "type" flag so 
that the node knows the length of the identifier field.

> How could a node do that if it does not know the type of the identifier?

[MB] Just match the bit string......
 
> But, MPLS-TP identifiers should be not exclusive to data plane or 
> control plane or management plane, and actually they are related to 
> all the three planes.

[MB]  The identifiers in all three planes are related but the values and 
type must be independent.