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

[Loa Andersson <[e-mail]>]

Maarten,

lots of interesting data and thoughts, however not addressing the
question I asked.

Let us assume that an LSP go across several operators transport
networks, e.g. it starts from operator A, go across operator B, C and
D to end up at a different geographical loacation i operator A's
network again.

Now how likely is operator C, would let operator A, whom he does not
really need to have a relationship with (masked by B and D) initiate
OAM actions that can cause MIPs in operator A's network take actions
that is totally unexpected and uncontrolled by C?

Would appreciate input from operators!

/Loa

On 2011-05-04 08:45, Maarten vissers wrote:
> 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

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]