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

From: "[email-masked]" <[email-masked]>
Date: Sun, 22 May 2011 19:37:19 +0200 (CEST)

As far as I know, mail posted on this mailing list as well as comments on the 
drafts are considered "IETF contributions".

There is an issue which has been identified one year ago and for which a 
solution has been proposed.

Many people objected against the proposed resolution w/o proposing a viable 
alternative. So the only reasonable solution I can see up to now is still the 
one proposed by ITU-T.

What is the value to write a I-D which duplicates the comment from ITU-T?

----Messaggio originale----
Da: [email-masked]
Data: 22-mag-2011 7.48
A: <[email-masked]>, "Eric Gray"<[email-masked]>
Cc: "Ross Callon"<[email-masked]>, <[email-masked]>, <mpls-bounces@ietf.
org>
Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm, hi
 
Borrowing the logic from other SDO's – any standards work is contribution 
driven – if you or any of the other persons feel that they see a need to extend 
the current draft with features that are not covered by the current work, they 
are able to write a new I-D that extends the functionality and details how this 
extension can be supported and whose responsibility (i.e. which MEP) it is to 
support all of the different formats.
 
Best regards,
yaacov
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext 
[email-masked]
Sent: Sunday, May 22, 2011 3:05 AM
To: Eric Gray
Cc: Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Eric, 

I find that argument somewhat circular since  we did not have consensus to 
omit this. 

Regards, 

Malcolm 

Eric Gray <[email-masked]> 
20/05/2011 12:28 PM 
To
"[email-masked]" <[email-masked]>, Ross Callon 
<[email-masked]> 
cc
"[email-masked]" <[email-masked]>, "[email-masked]" <mpls-bounces@ietf.
org> 
Subject
RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm, 
  
    As a co-author of the draft in question, I completely support this 
decision. 
  
    As I already explained to another person asking the same question, the 
bit about "no consensus to change" says it all. 
  
    In my opinion, this is a quite sufficiently detailed response.  The 
absence 
of a consensus to change means no change.  We do not typically require a 
strong consensus to continue on the current path. 
  
    I am reasonably certain you apply similar rules yourself when working in 
other SDOs. 
  
-- 
Eric 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Ross, 

I disappointed and, based on my reading of the emails on this thread, 
surprised that this decision has been taken.  Could you please elaborate on the 
reasoning behind this decision. 

Regards, 

Malcolm 

Ross Callon <[email-masked]> 
Sent by: [email-masked] 
18/05/2011 02:40 PM 
 
To
"[email-masked]" <[email-masked]> 
cc
Subject
Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

After discussion on the MPLS WG email list, there is no consensus to change 
draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for the 
same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is 
to leave the document as currently defined. The authors are therefore 
instructed to continue progression of draft-ietf-mpls-tp-identifiers without a 
change in this area. 
 
This decision neither supports nor precludes the possibility that at some 
point in the future, after draft-ietf-mpls-tp-identifiers is approved and 
published as an RFC, the WG might consider additional work to extend the MPLS 
protocols to allow mixed identifiers. 
 
Thanks, 
Ross and Loa (as MPLS WG chairs) 
 
[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for 
this one document he is recused from his role as WG co-chair.] 

From: [email-masked] [mailto:[email-masked]] On Behalf Of George 
Swallow
Sent: Monday, April 25, 2011 5:17 PM
To: [email-masked]
Subject: [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.   
1.        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. 
2.        Such an addition will add numerous object formats, and test cases. 
3.        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. 
4.        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

---

From: Maarten vissers <[email-masked]>
Date: Tue, 24 May 2011 06:53:38 +0000

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 24 May 2011 02:42
To: Mach Chen
Cc: [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?  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.

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

---

From: Mach Chen <[email-masked]>
Date: Tue, 24 May 2011 08:28:29 +0000

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,
> > >
> > > "[email-masked]" <[email-masked]>,
> > > "[email-masked]" <[email-masked]>
> > > cc
> > > See my response inline.
> > > interworking shows "layering" not gatewaying, and certainly not mixing.
> That
> > > is,
> > > [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.
> > >
> > > [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.

---

From: Maarten vissers <[email-masked]>
Date: Wed, 25 May 2011 12:11:22 +0000

Adrian,

Please be aware that under fault conditions an ICC formatted MEG ID can be received by an endpoint using a Global_ID formatted MEG ID, and vice versa. Either endpoint must be able to detect a misconnection condition and be able to report the received MEG ID (in the non-expected format) to NMS to guide in the fault localisation.

Note that we overlooked a similar requirement initially in SDH (16-byte TTI and 64-byte TTI), and this required us to upgrade our VC-n endpoints afterwards. Let's not make a similar mistake in MPLS-TP.

This implies that the MEG ID field must be structured and must contain the following subfields:
- MEG ID Format type
- MEG ID Length
- MEG ID Value.

The data plane should be agnostic to the MEG ID format and should simply compare the received MEG ID bit pattern with the expected MEG ID bit pattern. The received MEG ID bit pattern should be reported to NMS on request of NMS. NMS has to interpret the MEG ID bit pattern and present it in the appropriate format on its GUI.

Regards,
Maarten

> -----Original Message-----
> Adrian Farrel
> Sent: 25 May 2011 11:13
> Hi Neil,
> I'm not assuming peering. I am actually pointing out to Huub that
> (despite what he keeps saying) he is also not assuming peering.
> 
> The consequence of not peering is that a single identifier mode is used
> for both ends of an OAM "session". And that means that one end has to
> understand *and* use the "foreign" format at the remote end of the
> session.
> 
> I am tired of this discussion. There seems to be no forward progress
> only restatement of a "want". I always wanted a pony when I was a
> little girl, but I never got one.
> 
> Adrian
>