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

From: "[email-masked]" <[email-masked]>
Date: Wed, 18 May 2011 23:24:59 +0200 (CEST)

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
>
>-- 
>
>
>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
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 20 May 2011 16:45:01 +0100

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

> 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?
> 
> >A: <[email-masked]>,
> "[email-masked]"<[email-masked]>

---

From: [email-masked]
Date: Sat, 21 May 2011 20:04:28 -0400

Adrian,

Please see in line below.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]> 
Sent by: [email-masked]
20/05/2011 11:45 AM
Please respond to
[email-masked]

To
<[email-masked]>
cc
[email-masked]
Subject
Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Ermino,

[MB] well the continuation of this thread indicates that the loop is still 
open....

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.

[MB] OK

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.

[MB] It requires that one of the operators must administer both types of 
identifiers.  This causes two problems a) A (potentially) new operational 
process must be invoked to assign the second identifier type and; b) Given 
that a node will terminate/originate traffic from/to the local network and 
a third party network that node will have (different) identifiers, this 
will cause significant issues when attempting to perform normal 
operational processes e.g. alarm reporting.

[MB] Why? only the entity inserting the identifier needs to understand the 
semantics, all other nodes only need to check if the (bit string) 
presented matches the expected string.

Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 22 May 2011 20:15:17 +0200

Hi Adrian,

See my response in-line [hvh]

> We have already been round this loop on this list once.

[hvh] If it helps to get to the focal point, why not.

> one end of the e2e path must be capable of operating both systems, but the other

[hvh] OK if you mean "OAM toolsets" by "systems"

> 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

[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.

>>> A:<[email-masked]>,
>>>> *George Swallow<[email-masked]>*
>>>> 	"Andrew G. Malis"<[email-masked]>,<[email-masked]>
>>>> cc
>>>> 	[email-masked]
>>>> Subject
>>>> On 5/3/11 8:38 AM, "Andrew G. Malis"<[email-masked]>  wrote:
>>>>
>>>>   >  Neil,
>>>>   >
>>>>   >  On Tue, May 3, 2011 at 3:36 AM,<[email-masked]>  wrote:
>>>>   >>  Hi Andy,
>>>>   >>
>>>>   >>  2 points:
>>>>   >>
>>>>   >>>  On Mon, Apr 25, 2011 at 5:16 PM, George Swallow<[email-masked]>
>>>>   >>>  wrote:
>>>>   >>>>  All -
>>>>   >>>>
>>>>   >>>>  George, Eric,&  Matthew

-- 
*****************************************************************
                          我爱外点一七三一

---

From: <[email-masked]>
Date: Sun, 22 May 2011 20:35:48 +0100

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

> 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,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 May 2011 10:13:25 +0100

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

> [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

---

From: Maarten vissers <[email-masked]>
Date: Wed, 25 May 2011 09:41:30 +0000

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

> Adrian Farrel
> Sent: 25 May 2011 11:13
> 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
> 
> you're not the
> > intended
> > > > As Huub said, this is about identifiers, not OAM. However, the
> model
> > > for OAM
> > > > one end of the e2e path must be capable of operating both
> systems,
> > > but the other
> > > > does not need to.
> > >
> > > >> 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:
> > > >>
> > > >> It is a pity that with the current version of the identifier
> draft,
> > > MPLS-TP is
> > > >>> are you saying that operators today allow OAM to control node
> (MIPs
> > > and
> > > >>>> multi carrier data plane interconnection with end to end OAM.
> In
> > > today's
> > > >>>> objective for MPLS-TP is to allow for packet based
> interconnection
> > > as
> > > >> well.
> > > >>>>
> > > >>>> Regards,
> > > >>>>
> > > >>>> Malcolm
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> 	"Andrew G.
> Malis"<[email-masked]>,<[email-masked]>
> > > >>>> cc
> > > >>>> 	[email-masked]
> > > >>>> Subject
> > > >>>>   >  an E-NNI definition does not yet exist for MPLS-TP
> (something
> > > else to
> > > >>>> 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
> > > >>>>   >  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
> > > >>>>   >  layer in the transport core). If peer layer interworking
> ever
> > > becomes
> > > >>>>   >  a necessity, then obviously we'll need a well-defined E-
> NNI
> > > which
> > > >>>>   >  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
> > > >>>>   >>  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
> > > >>>>   >>  interworking between different parties, ie E-NNIs (I
> believe
> > > this is
> > > >>>>   >>  something you may support, eg old MPLSF case?). In such
> a
> > > peer
> > > >>>> interworking
> > > >>>>   >>  any other variations in DP/CP functional components) if
> they
> > > exist
> > > >>>> in the
> > > >>>>   >>  standards.
> > > >>>>   >>
> > > >>>>   >>  is trivial to prove), and this provides a strong
> argument
> > > for only
> > > >>>> having a
> > > >>>>   >>  This case cannot occur in the co-cs mode). To date,
> however,
> > > we have
> > > >>>> only
> > > >>>>   >>  really considered intra-layer misconnectivity, ie
> between
> > > different
> > > >> LSPs
> > > >>>>   >>  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
> > > >>>>   >>  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
> > > >>>>   >>  first one.....especially if you also support the notion
> of
> > > E-NNIs in
> > > >>>> MPLS-TP,
> > > >>>>   >>  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
> > > >>>>   >>>  From: [email-masked] [mailto:mpls-
> [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,
> > > >>>>   >>>
> > > >>>>   >>>>  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.
> > > >>>>   >>>>
> > > >>>>   >>>>  trivial procedure. Many organizations if not most
> already
> > > have AS
> > > >>>>   >>>  Numbers.
> > > >>>>   >>>>  The extent inter-provider MPLS-TP is as yet unknown.
> If
> > > mixed modes
> > > >>>>   >>>  of ICC
> > > >>>>   >>>>  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.
> > > >>>>   >>>>

---

From: <[email-masked]>
Date: Wed, 25 May 2011 12:23:29 +0100

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

> Maarten vissers
> Sent: 25 May 2011 10:42
> To: [email-masked]; [email-masked]
> 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
>
> > > detect there is a misconnectivity problems but also to identify
> which
> > other parties
> > > are involved.
> > >
> > > regards, Neil
> > >
> > > BT Design
> > > > > To extend this model to identifiers means that one end of the
> e2e
> > > > path must
> > > > > This becomes particularly important to the transit nodes that
> may
> > > > have to
> > > > > inspect the identifiers.
> > > >
> > > > >>>> I share your concerns and doubts about a multi carrier
> control
> > > > plane.
> > > > >>>> However, I think that it is essential that a transport
> network
> > > > supports
> > > > >>>> transport network this interconnection is supported by SDH
> and
> > > > OTN. The
> > > > >>>>   >  the already defined mechanisms can't do that. Do you
> have
> > > > some
> > > > >>>>   >>  be rather careful if you also advocate that one can
> also
> > > > have peer
> > > > >> layer
> > > > >>>>   >>  Of course, having an E-NNI and peer interworking
> between
> > > > different
> > > > >>>> parties in
> > > > >>>>   >>  important for MPLS-TP in the role of a transport
> network
> > > > (I'll
> > > > >>>> ignore issues
> > > > >>>>   >>  belonging to the same party (note this also includes
> all
> > > > cases of
> > > > >>>> nested LSP
> > > > >>>>   >>  I'd like to hear your comments on both these points,
> but
> > in
> > > > >>>> particular the
> > > > >>>>   >>>  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
> > > > >>>>   >>>
> > > > >>>>   >>>>  draft-ietf-mpls-tp-identifiers-04 have to do with
> the
> > > > Global and ICC
> > > > >>>>   >>>>  identifiers.
> > > > >>>>   >>>>
> > > > >>>>   >>>>  Such an addition will add numerous object formats,
> and
> > > > test cases.
> > > > >>>>   >>>>  and Global-ID identification is required, they can
> be
> > > > added later.

---

From: Maarten vissers <[email-masked]>
Date: Wed, 25 May 2011 12:04:10 +0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: 25 May 2011 13:23
> To: Maarten vissers; [email-masked]; [email-masked]
> 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:
> (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
> 
> know immediately
> > > > not only have we the usual intra-layer misconnectivity to deal
> with
> > > but we also
> > > > understand the OAM formats (and CV IDs) of each other anyway...
> not
> > > simply to
> > > > > > interworking shows "layering" not gatewaying, and certainly
> not
> > > > > mixing. That is,
> > > > > the identifier format of the local operator. The terminating
> end
> > > and
> > > > > >> From: [email-masked] [mailto:[email-masked]]
> On
> > > Behalf
> > > > > Of
> > > > > >> Appendix II of Y.1731 provides a good example about how
> inter-
> > > domain
> > > > > >>>>   >  identifier mapping/translation for MS-PWs, to answer
> an
> > > > > earlier
> > > > > >>>> that is yet to be solved. So there are arguments for
> pieces
> > of
> > > a
> > > > > solution
> > > > > >>>>   >  would include LSP identifier mapping/translation at
> the
> > > > > boundary, for
> > > > > >>>>   >  identifier mapping/translation for MS-PWs, to answer
> an
> > > > > earlier
> > > > > >>>>   >  I also agree that both intra-layer and inter-layer
> mis-
> > > > > connectivity
> > > > > >>>>   >  On Tue, May 3, 2011 at 3:36
> AM,<[email-masked]>
> > > > > wrote:
> > > > > >>>>   >>  Hi Andy,
> > > > > >>>>   >>
> > > > > >>>>   >>  2 points:
> > > > > >>>>   >>
> > > > > >>>>   >>  case it would seem one must allow different
> addressing
> > > > > schemes (and
> > > > > >>>> indeed
> > > > > >>>>   >>  come from (i) networks using different
> OAM/addressing
> > > > > solutions or
> > > > > >> (ii)
> > > > > >>>>   >>  is prohibited. If you've received this email in
> error,
> > > > > please let me
> > > > > >>>> know
> > > > > >>>>   >>  immediately
> > > > > >>>>   >>>>  The identifiers for Tunnel, LSP, PW, and MEG
> include
> > > > > fields to
> > > > > >>>>   >>>  identify each
> > > > > >>>>   >>>>  Obtaining an AS Number (from which the Global-ID
> is
> > > > > derived) is a
> > > > > >>>>   >>>  fairly
> > > > > >>>>   >>>>  For signaled connections, there is no plan to
> allow
> > > > > routing based on
> > > > > >>>>   >>>  either

---

From: <[email-masked]>
Date: Fri, 27 May 2011 11:12:40 +0100

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

> From: Maarten vissers [mailto:[email-masked]]
> Sent: 25 May 2011 13:04
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]
> 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
>
> you're
> > not the intended
> > > Either endpoint must be able to detect a misconnection condition
> and
> > be
> > > > 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
> > > > > 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.
> > > > > have inter-layer misconnectivity...and this means each
> operating
> > > > party must
> > > > > is prohibited. If you've received this email in error, please
> let
> > > me
> > > > know
> > > > > immediately
> > > > > > >> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-
> TP
> > > > > > Identifiers?
> > > > > > >>
> > > > > > >>>>   >  put on the to-do list). This E-NNI would also
> include
> > > > similar
> > > > > > >>>> Based on all that I am seeing my inclination is to NOT
> say
> > > > that we
> > > > > > >> disallow
> > > > > > >>>>   >  intend to deploy MPLS-TP in our infrastructure (as
> an
> > > > > > internal server
> > > > > > >>>>   >  a necessity, then obviously we'll need a well-
> defined
> > > E-
> > > > NNI
> > > > > > which
> > > > > > >>>>   >  LSP provisioning (whether static or dynamic) and
> end-
> > > to-
> > > > end
> > > > > > OAM. Such
> > > > > > >>>>   >  put on the to-do list). This E-NNI would also
> include
> > > > similar
> > > > > > >>>>   >  detection and amelioration are required, but I'm
> not
> > > > > > convinced that
> > > > > > >>>>   >>  any other variations in DP/CP functional
> components)
> > > if
> > > > they
> > > > > > exist
> > > > > > >>>> in the
> > > > > > >>>>   >>  standards.
> > > > > > >>>>   >>
> > > > > > >>>>   >>  OAM messages from some other party's layer
> network.
> > > The
> > > > OAM
> > > > > > >> messages
> > > > > > >> may
> > > > > > >>>>   >>  different issues wrt inter-layer misconnectivity
> one
> > > has
> > > > to
> > > > > > deal
> > > > > > >>>> with. I'm
> > > > > > >>>>   >>>>  The authors of the draft are very reluctant to
> do
> > > > this.
> > > > > > >>>>   >>>>
> > > > > > >>>>   >>>>  messages), the providers involved will need to
> run
> > > BGP
> > > > and
> > > > > > have AS
> > > > > > >>>>   >>>  numbers.
> > > > > > >>>>   >>>>

---

From: Maarten vissers <[email-masked]>
Date: Fri, 27 May 2011 12:12:46 +0000

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

> Sent: 27 May 2011 12:13
> 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
> 
> > > independent of each other at all....as we could if we did not
> impose
> > a
> > > > Please be aware that under fault conditions an ICC formatted ID
> can
> > > be
> > > > able to report the received ID (in the non-expected format) to
> NMS
> > to
> > > > Note that we overlooked a similar requirement initially in SDH
> (16-
> > > byte
> > > > > > recipient, note that disclosing, copying, distributing or
> using
> > > > this
> > > > > information
> > > > > Behalf Of
> > > > > > > Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in
> MPLS-
> > TP
> > > > > > > Identifiers?
> > > > > > >
> > > > > > > Hi Adrian,
> > > > > > >
> > > > > > > > As Huub said, this is about identifiers, not OAM.
> However,
> > > the
> > > > > model
> > > > > > > for OAM
> > > > > > > > support both identifier formats and the other does not
> need
> > > to.
> > > > > > >
> > > > > > > [hvh] to be more specific the originating end of an e2e
> path
> > > must
> > > > > > > the intermediate points of an e2e path must be able to
> verify
> > > the
> > > > > > > format inserted at the origin independent of the locally
> used
> > > > > > > identifier
> > > > > > > identifier formats in the A-->Z ans Z-->A direction of an
> e2e
> > > > path.
> > > > > > > [hvh] I agree, mixing of identifier formats it not
> restricted
> > > to
> > > > > > > MPLS-TP.
> > > > > > >
> > > > > > > Regards, Huub.
> > > > > > >
> > > > > > > >>> are you saying that operators today allow OAM to
> control
> > > node
> > > > > (MIPs
> > > > > > > and
> > > > > > > >>>> multi carrier data plane interconnection with end to
> end
> > > > OAM.
> > > > > In
> > > > > > > today's
> > > > > > > >>>> On 5/3/11 8:38 AM, "Andrew G.
> Malis"<[email-masked]>
> > > > > wrote:
> > > > > > > >>>>
> > > > > > > >>>>   >  Neil,
> > > > > > > >>>>   >
> > > > > > > >>>>   >>  interworking between different parties, ie E-
> NNIs
> > (I
> > > > > believe
> > > > > > > this is
> > > > > > > >>>>   >>  something you may support, eg old MPLSF case?).
> In
> > > > such
> > > > > a
> > > > > > > peer
> > > > > > > >>>> interworking
> > > > > > > >>>>   >>  co-ps mode using variable size traffic units,
> and
> > > > > therefore
> > > > > > > >>>> something rather
> > > > > > > >>>>   >>  of transparency here), there could be inter-
> layer
> > > > > > > misconnectivity
> > > > > > > >>>> (Aside=>
> > > > > > > >>>>   >>  networks using the same OAM/addressing
> solutions.
> > In
> > > > > both
> > > > > > > cases
> > > > > > > >>>> there are
> > > > > > > >>>>   >>>  Subject: Re: [mpls] Mixing ICC and Global-IDs
> in
> > > > MPLS-
> > > > > TP
> > > > > > > Identifiers?
> > > > > > > >>>>   >>>
> > > > > > > >>>>   >>>  George et al,
> > > > > > > >>>>   >>>
> > > > > > > >>>>   >>>>  either the Global-ID for both ends or or the
> ICC
> > > for
> > > > > both
> > > > > > > ends.
> > > > > > > >>>>   >>>  Mixed use
> > > > > > > >>>>   >>>>  is not permitted.
> > > > > > > >>>>   >>>>