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

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

Does the draft has a special status vs mail comments?

There is nothing I can put in the draft that has not been said on the mailing 
list.

>----Messaggio originale----
>Da: [email-masked]
>Data: 5-giu-2011 17.41
>A: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Ogg: RE: [mpls] R: Re: R: Re: Mixing ICC and Global-IDs in MPLS-TP 
Identifiers?
>
>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?
>
>>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
>>
>
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: John E Drake <[email-masked]>
Date: Sun, 5 Jun 2011 11:20:08 -0700

If this was the ITU, wouldn't you be expected to write a
contribution?  Think of an I-D as a similar concept.

Sent from my iPhone

On Jun 5, 2011, at 11:51 AM, "[email-masked]" <[email-masked]

>> A: <[email-masked]>, <[email-masked]>, <[email-masked]
>> >
>>>>>>>>>     "Andrew G. Malis"<[email-masked]>,<[email-masked]
>>>>>>>>> >
>>>>>>>>> cc
>>>>>>>>>     [email-masked]
>>>>>>>>> Subject