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

From: "[email-masked]" <[email-masked]>
Date: Sun, 5 Jun 2011 17:37:26 +0200 (CEST)

>I am tired of this discussion. There seems to be no forward progress only 
restatement of a "want". I always wanted a pony when I was a little girl, but I 
never got one.

The problem is that there are a lot of technical questions on the table that 
can be easily answered by supporting mixed ICC and IP identifiers that are now 
waiting for an answer,

>----Messaggio originale----
>Da: [email-masked]
>Data: 25-mag-2011 11.13
>A: <[email-masked]>
>Ogg: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>Hi Neil,
>
>I'm not assuming peering. I am actually pointing out to Huub that (despite 
what he keeps saying) he is also not assuming peering.
>
>The consequence of not peering is that a single identifier mode is used for 
both ends of an OAM "session". And that means that one end has to understand 
*and* use the "foreign" format at the remote end of the session.
>
>I am tired of this discussion. There seems to be no forward progress only 
restatement of a "want". I always wanted a pony when I was a little girl, but I 
never got one.
>
>Adrian
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: 22 May 2011 20:36
>> To: [email-masked]; [email-masked]
>> Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP 
Identifiers?
>> 
>> Hi Adrian/Huub,
>> 
>> You are largely assuming some form of peering (single partitioned layer 
network)
>> here...and that model will generate a whole raft of problems for operators 
IMO.
>> A more important model for a co-ps transport network is client/server.  And 
now
>> not only have we the usual intra-layer misconnectivity to deal with but we 
also
>> have inter-layer misconnectivity...and this means each operating party 
must
>> understand the OAM formats (and CV IDs) of each other anyway... not simply 
to
>> detect there is a misconnectivity problems but also to identify which other 
parties
>> are involved.
>> 
>> regards, Neil
>> 
>> 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
>> > Huub van Helvoort
>> > Sent: 22 May 2011 19:15
>> > To: [email-masked]
>> > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
>> > Identifiers?
>> >
>> > Hi Adrian,
>> >
>> > See my response in-line [hvh]
>> >
>> > > We have already been round this loop on this list once.
>> > > Want to do it again?
>> >
>> > [hvh] If it helps to get to the focal point, why not.
>> >
>> > > 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.
>> >
>> > [hvh] OK if you mean "OAM toolsets" by "systems"
>> >
>> > > 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.
>> >
>> > [hvh] to be more specific the originating end of an e2e path must
>> > be able to support one of the possible identifier formats, normally
>> > the identifier format of the local operator. The terminating end and
>> > the intermediate points of an e2e path must be able to verify the
>> > format inserted at the origin independent of the locally used
>> > identifier
>> > format. This means that it must be possible to support different
>> > identifier formats in the A-->Z ans Z-->A direction of an e2e path.
>> > I.e. mixing of identifier formats must be supported.
>> >
>> > > This becomes particularly important to the transit nodes that may
>> > have to
>> > > inspect the identifiers.
>> >
>> > [hvh] the inspection will consist of comparing a received value
>> > with an expected value which can have any format.
>> >
>> > > None of this is new or specific to MPLS-TP.
>> >
>> > [hvh] I agree, mixing of identifier formats it not restricted to
>> > MPLS-TP.
>> >
>> > Regards, Huub.
>> >
>> > >> -----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<[email-masked]>
>> > >>>>   >>>  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
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 5 Jun 2011 17:41:33 +0200

So come with a draft and present it. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Sunday, June 05, 2011 6:37 PM
To: [email-masked]; [email-masked]
Subject: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Identifiers?
network)
IMO.
now
also
must
to
parties
confidential.
the
information