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

From: [email-masked]
Date: Mon, 23 May 2011 20:42:12 -0400

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

> -----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: Gregory Mirsky <[email-masked]>
Date: Mon, 23 May 2011 21:03:49 -0400

Dear Malcolm,

a quick question, just one, promise, tagged with GIM>>

<... snipped ...>

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

GIM>> For the datapath the Identifier in OAM message is opaque bit string of length determined by particular type (IP-based or ICC)?

    Regards,
        Greg

---

From: [email-masked]
Date: Tue, 24 May 2011 01:19:18 -0400

Dear Greg,

You are correct.

Regards,

Malcolm

Gregory Mirsky <[email-masked]> 
23/05/2011 09:03 PM

To
"[email-masked]" <[email-masked]>, Mach Chen 
<[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?

Dear Malcolm,

<... snipped ...>

GIM>> For the datapath the Identifier in OAM message is opaque bit string 
of length determined by particular type (IP-based or ICC)?

    Regards,
        Greg

---

From: <[email-masked]>
Date: Tue, 24 May 2011 07:09:44 +0100

Greg,

Malcolm's answer per se in not sufficient IMO.  I would also want to know *where* the leaking/misconnected  traffic/OAM that I am seeing in my network came from.

When I made this point a couple of days ago Malcolm said this could be done in off-line OSS.  Which is indeed feasible.  However, it still requires that the incoming OAM CV "SA" identifier be known to the receiving party....and this was the point I was making, ie one can't simply generate ad hoc ID formats even in client/server cases (let alone the unnecessary peering case) because when we have layering in co-ps layer networks based on a variable size traffic unit we can have something that looks like XoverX wrt to the layer network characteristic information (a case that cannot occur in co-cs mode transport networks because they always define a fixed resource associated with the 'traffic unit' (=frame)), and thus we can have inter-layer misconnectivity as well as the more usual intra-layer misconnectivity case.

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.
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 Gregory Mirsky
Sent: 24 May 2011 02:04
To: [email-masked]; Mach Chen
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Dear Malcolm,

<... snipped ...>

    Regards,
        Greg