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

From: "[email-masked]" <[email-masked]>
Date: Sun, 22 May 2011 19:25:25 +0200 (CEST)

I am very confused.

If we are speaking about identifiers and not OAM why the fact that some 
endpoints need to support two OAM protocols requires some networks to support 
two identifers' schemes?

>----Messaggio originale----
>Da: [email-masked]
>Data: 20-mag-2011 17.45
>A: <[email-masked]>
>Cc: <[email-masked]>
>Ogg: RE: [mpls] R: Re:  Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>Ermino,
>
>We have already been round this loop on this list once.
>Want to do it again?
>
>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.
>
>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. 
>
>This becomes particularly important to the transit nodes that may have to
>inspect the identifiers.
>
>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 <swallow@cisco.
com>
>> >>  >>> 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
>
>