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

From: "[email-masked]" <[email-masked]>
Date: Sun, 5 Jun 2011 17:50:20 +0200 (CEST)

Mach,

let me try to explain the point/issue with an example.

I have my own domain and I name nodes (or tunnel endpoints if you prefer) 
using numbers (i.e., 1, 2, 3, 4, ...). Within my domain I can setup any p2p 
connection between any paer of numbers (1 to 2; 3 to 4 and so on).

You have your own domain and you name nodes (or tunnel endpoints) using latin 
letters (i.e., A, B, C, ...). Within your domain you can setup any p2p 
connection betwen any pair of letters (A to B; C to D and so on).

Now there is a need to setup a connection betwee my node 5 and your node E. 
What can we do? We can setup a conection 5 to E (i.e., supporting mixed 
identifiers on the connection) or mandate one of us to assign two names to the 
same node?

Would you be happy to assign two names to all your nodes (one following 
numeric convention and one following latin letters?

Woud you be happy to re-number all your nodes with a third convention when you 
need to be connected with another operator that is adopting a third naming 
convention?

If we mix identifiers, what you need is just to provision the peer MEP-ID 
information as an unstructure bit string (note that while E has a meaning for 
you, 5 does not have any meanign for you).

Note that in any case you must be able to identify a misconnection between 
different identifiers scheme. For example, if the traffic coming from my node 2 
leaks out into the 5-E connection, you will receive a source MEP-ID equal to 2 
in the CV packets.

>----Messaggio originale----
>Da: [email-masked]
>Data: 24-mag-2011 10.28
>A: "[email-masked]"<[email-masked]>
>Cc: "[email-masked]"<[email-masked]>, "[email-masked]"<mpls@ietf.
org>
>Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>Hi Malcolm,
>
>Thanks for your response!
>
>Firstly, I have to claim that I do not object mixed identifier if there are 
cases really need it. 
>
>From the discussion on this thread, it's very clear that mixed identifiers at 
least require control plane and management plane has to understand and support 
the semantic of both ICC and Global_ID based identifiers. This means that the 
operators have to operate both ICC and Global_ID based identifiers when do 
mixed identifiers. If the purpose of mixed identifiers is to help one operator 
(e.g., only prefers to ICC style) to avoid operating/maintaining unfamiliar 
identifier scheme (e.g., Global_ID) when do inter-domain connection, obviously, 
it cannot work. On the contrary, as many other guys on the list pointed out, if 
the same format identifier is used for a specific path, the domain one end 
hosting can really only need to support and administer one type of 
identifier. 
>
>Best regards,
>Mach
>
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, May 24, 2011 1:33 PM
>> 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.
>> 
>> Mach Chen <[email-masked]> wrote on 23/05/2011 10:15:32 PM:
>> 
>> > 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
>> 
>> [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.
>> 
>> >
>> > >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?
>> 
>> [MB] Just match the bit string......
>> 
>> >
>> > >  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.
>> 
>> [MB]  The identifiers in all three planes are related but the values and 
type
>> must be independent.
>> >
>> > 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
>> > >
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 6 Jun 2011 13:49:26 -0400

Dear Erminio,
Please find my comments in-line tagged by GIM>>.

	Regards,
		Greg 

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

Mach,

I have my own domain and I name nodes (or tunnel endpoints if you prefer) using numbers (i.e., 1, 2, 3, 4, ...). Within my domain I can setup any p2p connection between any paer of numbers (1 to 2; 3 to 4 and so on).

You have your own domain and you name nodes (or tunnel endpoints) using latin letters (i.e., A, B, C, ...). Within your domain you can setup any p2p connection betwen any pair of letters (A to B; C to D and so on).

Now there is a need to setup a connection betwee my node 5 and your node E. 
What can we do? We can setup a conection 5 to E (i.e., supporting mixed identifiers on the connection) or mandate one of us to assign two names to the same node?

Would you be happy to assign two names to all your nodes (one following numeric convention and one following latin letters?
GIM>> If both or any of addressing schemes uses locally unique addressing scheme then re-numbering or secondary addressing will be required.

Woud you be happy to re-number all your nodes with a third convention when you need to be connected with another operator that is adopting a third naming convention?

If we mix identifiers, what you need is just to provision the peer MEP-ID information as an unstructure bit string (note that while E has a meaning for you, 5 does not have any meanign for you).

Note that in any case you must be able to identify a misconnection between different identifiers scheme. For example, if the traffic coming from my node 2 leaks out into the 5-E connection, you will receive a source MEP-ID equal to 2 in the CV packets.
GIM>> The MPLS-TP dataplane will be able to identify the fact of misconnection defect but I don't see it is required to identify the source of misconnetion, i.e. interpret source MEP-ID being leaked into the monitored connection. I believe that such interpretation is function of not the dataplane but NMS or control plane.

org>
cases really need it. 
>From the discussion on this thread, it's very clear that mixed 
least require control plane and management plane has to understand and support the semantic of both ICC and Global_ID based identifiers. This means that the operators have to operate both ICC and Global_ID based identifiers when do mixed identifiers. If the purpose of mixed identifiers is to help one operator (e.g., only prefers to ICC style) to avoid operating/maintaining unfamiliar identifier scheme (e.g., Global_ID) when do inter-domain connection, obviously, it cannot work. On the contrary, as many other guys on the list pointed out, if the same format identifier is used for a specific path, the domain one end hosting can really only need to support and administer one type of identifier. 
Identifiers?
Identifiers?
>> > > "[email-masked]" <[email-masked]> cc 
for
mixing.
the
must
of
identifiers,
nodes.
convenient
assist
carry
is
the
expected
and
must
will
reporting.
to
the
presented
of
>> the
>> > > LSP, PW or Section among the relevant nodes when signal the LSP, 
>> > > PW or Section.
type
and