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

["Adrian Farrel" <[e-mail]>]

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

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. 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, but the end-to-end identifiers would be of one form only.

Have I misunderstood you?

Adrian

> -----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
> 
> 
> --
> **************************************************************
> ***
>                           我爱外点一七三一
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls