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

[Huub van Helvoort <[e-mail]>]

Hello Adrian,

You replied:

> So, I may have understood the import of those figures (specifically
 > figure 3 in draft-palanivelan-bfd-v2-gr-11.txt)

Just to avoid confusion I was refering to the figures in
draft-tsb-mpls-tp-ach-ptn-00.txt and looking at the text below
you may be refering to that draft too.

> but I read that to  mean that, in the case of mismatched OAM types,
 > one of the OAM types (in the figure, the PSN type is indicated)
 > would be run end-to-end, and the local OAM types would be used
 > within the networks according to what they supported.

Indeed.

> Now, noting very clearly that OAM types have nothing whatsoever to
 > do with MPLS-TP Identifiers, you seem to be suggesting that the
 > same approach holds.

The OAM types are independent of the used identifiers.

> That would mean that (to paraphrase Figure 3) network A might use
 > one form of identifier and network B might use another form of 
identifier,

yes.

> but the end-to-end identifiers would be of one form only.

Indeed, and the identifier that is used end-to-end can be either
form A or form B. The actual form has to be agreed between the
operators of network A and B.

> Have I misunderstood you?

I don't think so.

Regards, Huub.


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Huub van Helvoort
>> Sent: 06 May 2011 18:26
>> To: [e-mail]
>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>> Hej Loa,
>>
>> You wrote:
>>
>>> 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!
>>
>> A similar scenario on the use of OAm is described in:
>> http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt  or
>> shown in slides 9-12 of the presentation in the RTGA open meeting
>> http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt
>>
>> These figures are taken from ITU-T contribution C-1124
>> which is signed by several operators. This contribution
>> was supported by other operators as well.
>>
>> It is possible to use the same OAM (PTN or PSN) in
>> all domains (A, B and C in figures 1 and 2).
>> You can see that operator B *cannot* influence the OAM
>> in domains A and C nor in the top layer end-to-end OAM.
>>
>> Regards, Huub.
>> ===============
>>
>>
>>> 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



-- 
*****************************************************************
                          我爱外点一七三一