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

[Maarten vissers <[e-mail]>]

Neil,

LO ODU access points are on UNI-N port cards, HO ODU NNI access points are typically on NNI port cards, but could also be on UNI-N port cards, SHO ODU NNI access points are on NNI port cards.

Resources for each ODU in the ODUoverODUoverODUover... are allocated, not just reserved. So don't be worried here.

ODU connection management treats all ODU connections the same. ODU connection set up process does not care at what level the ODU connection is operating. But be aware that not all ODU links will be able to support a specific ODU bandwidth.

Regards,
Maarten



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 27 May 2011 12:13
> To: Maarten vissers; [e-mail]; [e-mail]
> Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
> Identifiers?
> 
> Sorry bit late responding Maarten....wanted to check this out with Tony
> Flavin and Alan McGuire here first.  Seems we can have what appears to
> be XoverX due to recursively nesting a digital wrapper scheme.  Not
> sure what recursion limits apply here wrt resource (CF <=MTU in co-ps
> pkt case) and we should be careful not to compromise the strong
> resource accounting/management capability that a co-cs mode network
> should be able to deliver to its clients.  So maybe (hopefully?) the
> major issue here is one of ensuring that each layer can be uniquely
> identified wrt access points.
> 
> regards, Neil
> 
> 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: Maarten vissers [mailto:[e-mail]]
> > Sent: 25 May 2011 13:04
> > To: Harrison,N,Neil,DKQ7 R; [e-mail]; [e-mail]
> > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
> > Identifiers?
> >
> > Neil,
> >
> > FYI. The co-cs ODU layers have the same stacking capability as MPLS-
> TP
> > LSP and ETH layers; i.e. XoverX is supported and deployed. As such in
> > OTN we can have misconnections between e.g. LO ODU2 and HO ODU2
> > connections. The traffic units in OTN are variable sized traffic
> units.
> >
> > Regards,
> > Maarten
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: 25 May 2011 13:23
> > > To: Maarten vissers; [e-mail]; [e-mail]
> > > Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
> > > Identifiers?
> > >
> > > There is an important difference here.  We cannot have *inter*
> layer
> > > misconnectivity in co-cs mode networks...this follows directly from
> > how
> > > the labelling of resource partitions works in each of the 3 modes.
> > So
> > > if there is a need to process different CV 'SA' IDs here then that
> is
> > > down to a self-inflicted peering case of forcing more functionality
> > > than a true BOS-physical bit interconnect case requires.
> > >
> > > However, when we have a variable size traffic unit in the co-ps
> mode,
> > > as we have with MPLS-TP, then we can have something that looks like
> > > XoverX (as many times as one likes - subject to <MTU).  So, in
> > addition
> > > to misconnectivity due to any self-inflicted peering case, we can
> > also
> > > have (i) misconnectivity between layers at different levels or (ii)
> > > between different/independent layer networks at level N say due to
> a
> > > server layer misconnectivity defect below level N.  The key points
> > here
> > > being:
> > >  (i) a richer defect environment than the co-cs mode
> > > (ii) if N types of CV 'ID' exist then we can't assume they remain
> > > independent of each other at all....as we could if we did not
> impose
> > a
> > > self-inflicted peer case on ourselves...and thus each network must
> be
> > > able to handle all N instances of ID (I assume the same CV OAM
> > traffic
> > > unit carrying them - varying that just makes the mix even more
> > > interesting).
> > >
> > > 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: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > Of
> > > > Maarten vissers
> > > > Sent: 25 May 2011 10:42
> > > > To: [e-mail]; [e-mail]
> > > > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP
> > > > Identifiers?
> > > >
> > > > Adrian,
> > > >
> > > > Please be aware that under fault conditions an ICC formatted ID
> can
> > > be
> > > > received by an endpoint using a Global_ID formatted ID, and vice
> > > versa.
> > > > Either endpoint must be able to detect a misconnection condition
> > and
> > > be
> > > > able to report the received ID (in the non-expected format) to
> NMS
> > to
> > > > guide in the fault localisation.
> > > >
> > > > Note that we overlooked a similar requirement initially in SDH
> (16-
> > > byte
> > > > TTI and 64-byte TTI), and this required us to upgrade our VC-n
> > > > endpoints afterwards. Let's not make a similar mistake in MPLS-
> TP.
> > > >
> > > > Regards,
> > > > Maarten
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > > Of
> > > > > Adrian Farrel
> > > > > Sent: 25 May 2011 11:13
> > > > > To: [e-mail]
> > > > > Subject: 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: [e-mail] [mailto:[e-mail]] On
> > > > Behalf
> > > > > Of
> > > > > > [e-mail]
> > > > > > Sent: 22 May 2011 20:36
> > > > > > To: [e-mail]; [e-mail]
> > > > > > 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: [e-mail] [mailto:[e-mail]]
> On
> > > > > Behalf Of
> > > > > > > Huub van Helvoort
> > > > > > > Sent: 22 May 2011 19:15
> > > > > > > To: [e-mail]
> > > > > > > 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: [e-mail] [mailto:mpls-
> [e-mail]]
> > > On
> > > > > Behalf
> > > > > > > Of
> > > > > > > >> [e-mail]
> > > > > > > >> Sent: 18 May 2011 22:25
> > > > > > > >> To: [e-mail]; [e-mail]; [e-mail]
> > > > > > > >> 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: [e-mail]
> > > > > > > >>> Data: 4-mag-2011 8.00
> > > > > > > >>> A:<[e-mail]>,
> > > > > > > >> "[e-mail]"<[e-mail]>
> > > > > > > >>> 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, [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:mpls-
> > > > > [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
> > > > > > _______________________________________________
> > > > > > mpls mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/mpls
> > > > >
> > > > > _______________________________________________
> > > > > mpls mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/mpls
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mpls