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

[Maarten vissers <[e-mail]>]

Loa,

The connections in the "Transport Service" layers can be multi-operator connections. Examples are the SDH Transport Service layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, ..), ATM Transport Service layer connections (ATM VCs), OTN Transport Service layer connections (LO ODUs), Ethernet Transport Service layer connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport Service layer connections (MS-PW, Service-LSP).

These Transport Service layer connections are monitored using pro-active OAM and on-demand OAM between the Service Provider MEG level MEP functions on the UNI-N ports and Service Provider MEG level MIP functions on the E-NNI/IrDI ports. In a multi-operator connection these Service Provider MEG level MEP functions on the UNI-N ports will be located in different operator domains. Also the Service Provider MEG level MIP functions on the E-NNI/IrDI ports will be located in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID MPLS-TP identifiers, then you will have a mixed case.

We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. 
If the answer is "no" then mixed identifier usage will not be a requirement. 
If the application for MPLS-TP is within an MEF Ethernet Services architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason is that in the MEF architecture the E-NNI/IrDI is defined as an Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. 
- MPLS-TP Transport Service layer may not be present at all in such MEF Ethernet Services architecture, only the MPLS-TP Transport Path layer could be used (to carry PW-labelled Ethernet Connections) and those MPLS-TP Transport Path connections terminate in the operator domain's edge node (i.e. single operator connections).
- For the case a MPLS-TP Transport Service layer is used in an MEF Ethernet Services architecture the MPLS-TP Transport Service connections will be terminated  in the operator domain's edge node (i.e. single operator connections).

------

MPLS-TP Transport Path layer connections (transport-LSPs) are connecting a PE with an adjacent PE (via zero or more P nodes). Those transport-LSPs do not cross an E-NNI/IrDI.

There is however one exception... when a group of Transport Service layer connections has to be sent from one domain via a second domain to a third domain, this is typically done via a Transport Path layer connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. Domain treats this domain 1-3 transport path layer connection as a transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 may use different identifiers (ICC, Global-ID) and a mixed case is present. If domains 1 and 3 use the same identifier type, then domain 2 may be using a different identifier type in the MIPs on its E-NNI/IrDI ports.

------

MPLS-TP Section layer connections are connecting adjacent MPLS-TP nodes. In 99.9% of the cases those nodes are in one operator domain. For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID based MPLS-TP identifiers there is a mixed case.

Regards,
Maarten


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Loa Andersson
> Sent: 4 May 2011 08:00
> To: [e-mail]; [e-mail]
> Subject: 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, [e-mail] 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 <[e-mail]>*
> > Sent by: [e-mail]
> >
> > 03/05/2011 11:09 AM
> >
> >
> > To
> > 	"Andrew G. Malis" <[e-mail]>, <[e-mail]>
> > cc
> > 	[e-mail]
> > 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" <[e-mail]> 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, <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of
> >  >>> Andrew G. Malis
> >  >>> Sent: 02 May 2011 20:48
> >  >>> To: George Swallow
> >  >>> Cc: [e-mail]
> >  >>> 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
> <[e-mail]>
> >  >>> 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
> >  >>>> [e-mail]
> >  >>>> https://www.ietf.org/mailman/listinfo/mpls
> >  >>>>
> >  >>>>
> >  >>> _______________________________________________
> >  >>> mpls mailing list
> >  >>> [e-mail]
> >  >>> https://www.ietf.org/mailman/listinfo/mpls
> >  >>
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> --
> 
> 
> Loa Andersson                         email: [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                               [phone]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls