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

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 2 May 2011 15:48:22 -0400

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

---

From: <[email-masked]>
Date: Tue, 3 May 2011 08:36:19 +0100

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

---

From: <[email-masked]>
Date: Tue, 3 May 2011 11:33:31 +0200

Changed to plain text and resend as the first try hasn’t made it to the list due to size limits.

Regards,
Manuel

________________________________________
From: Paul, Manuel
Sent: Monday, May 02, 2011 3:46 PM
To: 'Eric Gray'; [email-masked]; George Swallow
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Dear All,

Please see some comments inline marked with [MP].

Thanks,
Manuel

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Thursday, April 28, 2011 10:58 PM
To: [email-masked]; George Swallow
Cc: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm,

    There is nothing about not mixing the two identifier formats that
prevents an operator from continuing to use ICC identifiers within
their own network.  The implication that it is okay to require any
operator that does not use ICC identifiers to be able to recognize
them, but it is not okay for an operator that use them to be able to
recognize the Global Identifier format, is decidedly one sided.

[MP:] Agree that this should be equally applicable to all sides of the story, although backwards compatibility considerations (often stressed along the MPLS OAM extension debate) apply here too. Its among TP’s primary targets to fit for classicly operated transport networks, to save efforts and avoid  disruptive (primarily operational) changes in this arena. Platforms aren’t migrated with one single snip of the finger (sometimes more for operational rather than technical complexity). In a real world, may need to interconnect platforms in distinct phases of evolution. In case of need for handovers, an operator should have the flexibility to decide what device class is easiest to be (evolutionary) touched and tuned, i.e. supporting mixed identifiers. I admit this occurrence probably will not be as granular as the general requirement for End-to-End OAM interoperability in a multi-vendor transport network environment where the boundaries are drawn according to the reach of optical transparency domains and/or network management feasibilities.

    But, to be able to recognize the Global identifier format, the ICC
user has to first be able to support this format.  Contrary to your
assertion, the format and comparison semantics of the two are not
the same.

[MP:] Is it really that difficult to handle when we focus on the data plane perspective for now? As in current scope of the identifiers draft?

    The Global Identifier format consists of a pair of 32-bit integers,
in network bit/byte order.  The ICC is a litteral string.  Most of us
know that the same comparison operation cannot be used with
these two formats.  For example, a very significant fraction of all
Global Identifiers would match in a string compare with the empty
string ("").

    Hence the specific identifier semantics is significant.

[MP:] Wouldn’t it be sufficient to recognize either format to know what semantics do apply ( or do not apply ) to handle one, or the other, or boths formats properly on a node?
What happens today when a node receives any format that it doesn’t support? Would it result in a confusion / wrong comparison?

IMHO solving inter-provider interface issues or automization in assignement may be tackled subsequently, i.e. in a next step.

    As for the inter-provider case, do you now assert that there will
in fact be a requirement for OAM interworking, given that at least
some subset of the carriers that use ICC format identifiers are the
same carriers who argued that the applications were more than
sufficently different to justify specification of distinct OAM?

    If there is going to be a requirement for OAM inteworking, then
let's allow that this interworking function will probably need to
support identifier format conversion.  Certainly we should not - at
this point - rule this likelihood out.

    Also, see in-line responses below.

--
Eric

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 27, 2011 12:05 AM
To: George Swallow
Cc: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

George,

I do not agree the proposed resolution of this comment.  As stated in the draft allows an operator can select the use of either Global (IP) or ICC based identifiers.  Insisting that both ends of a LSP or PW must use the same scheme removes the freedom to select the between ICC and Global (IP) identifiers.
Are suggesting that the same operator might make different choices in different
parts of the same network?

[MP:] Looking at the reality where platforms aren’t migrated with one single snip of the finger (sometimes for operational rather than technical reasons), it may indeed be of practical relevance. Want to say, even an intra-operator but inter-AS scenario may be thinkable.

This seems very unlikely, except possibly in the case where one operator who
uses one format identifier is acquired by another operator who uses the other.

In any case, if the decision to use a particular identifier is made consistently
within any adminstrative domain, then the onus is on the boundary points to
make stuff work, not on every device in the network.

MPLS-TP requires that the data plane and control plane are independent, including having independent identifiers.  The draft describes the mapping between the GMPLS identifiers used by the control plane and the data plane identifiers.
I believe you are correct in terms of what the requirements are.  There is nothing
I am aware of that prevents any operator from using a form of identifier that is not
necessarily consistent with their choice of signaling or configuration.

It is exceedingly unlikely that operators that use existing (G)MPLS signaling will
be in the camp that would prefer not to use identifiers that are consistent with IP
addressing and routing - but it is possible.  If that is the case, then they are free
to do so as far as I can tell.

It is (probably?) much more likely that operators that use configuration will still
elect to use identifiers that are consistent with IP addressing and routing.  They
can certainly do that.

If you know of a specific place in the text that preculdes this, please point it out.

From the perspective of the data plane an identifier is inserted at the source and received by the sink.  Neither the source or sink need to understand the semantics of the identifier, all a sink needs to, for example, to verify connectivity is to check that the received identifier string matches the expected identifier string.
Here is - in part at least - the crux of the misunderstanding.  The Global Identifier
format does not include the notion of an identifier string.  Hence the comparison
you describe is less than adequate.

Please see in-line below.

Regards,

Malcolm

George Swallow <[email-masked]>
Sent by: [email-masked]
25/04/2011 05:16 PM
To
<[email-masked]>
cc

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

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.

1.        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.
[MB] Many organizations already have process in place to use ICC based identifiers for the data plane changing to IP based identifiers would be a major burden.
2.        Such an addition will add numerous object formats, and test cases.
[MB]  Why - the data plane does not need to interpret the string, just check that it matches the expected string
3.        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.
[MB]  This would be a major roadblock to the use of MPLS-TP in an inter provider transport network
4.        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.
[MB] The control plane identifiers must be independent of the data plane identifiers.

George, Eric, & Matthew _______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 3 May 2011 08:38:29 -0400

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

---

From: George Swallow <[email-masked]>
Date: Tue, 03 May 2011 11:09:25 -0400

Andy -

> Such

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:

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

---

From: <[email-masked]>
Date: Tue, 3 May 2011 16:27:10 +0100

Thanks Andy.  Glad to hear you don't see any need for an E-NNI in MPLS-TP - at least right now.  However, I'm not sure an MPLS-TP E-NNI should go on the 'to do' list at any time in the future either.  If ones does venture into E-NNIs one must consider the DP adaptation functions that interface with the external message/file/stream applications (and that are always present in a true TOS layer network in all networking cases) as these essentially define the service.  Defining any E-NNIs without this perspective is rather naive IMO (though it does not seem to stop folks pushing this, and in some cases even suggesting peer interworking between different non-TOS network technologies/modes!).  The problem with non-TOS layer networks is that they don't have generic external message/file/stream adaptation functions so one can end up with a whole raft of specific-case E-NNIs for every interworking 'service' scenario.

I also saw the mails from Erminio where he had spotted that the same issues apply to MS PWs.  Well, I think most folks know my views on these...but having E-NNIs in an artificial/unnecessary PW layer network is a wonderful concept...I mean, just how bad can we make this stuff if we really try?

Wrt inter-layer misconnectivity.  I have not done any deep analysis.  However, I can see a new situation arising here that had not existed in any previous co-ps mode technology.  Like MS PWs, MPLS-TP should not have traditional sublayering of LSPs...this is an unnecessary  behaviour in a transport network ....and the deeper arch reason harks back to what transparency really means and why this is a very important property of a transport network.

The reason I mention this is that in a set of nested LSPs we can have both layering (of same or different party MPLS-TP layer networks) and sublayering (of the same/single party MPLS-TP layer network) mixed-up, and AFAIK it is not obvious which is which in the DP (though I am aware of at least one vendor who seems may have a solution to this).....and we thus need to be able to detect both intra and inter layer misconnectivity across all these cases.  The use of different addressing schemes (noting that OAM CV messages should contain proper SA information, and not some arbitrary IDs, eg to justify the use of TCM sublayering say, which is a bad OAM idea anyway) creates an obvious need to be able to recognise/handle different OAM cases in a layer network due to inter-layer misconnectivity even with no peer interworking.  However, one might also have the use of identical addressing in a client and server layer network (since these are non-TOS and have no need to peer interwork).  So now one can have inter layer misconnectivity that might look like it's intra layer misconnectivity from inspection of CV OAM messages.....or put another way one needs to be able to identify instances of inter-layering misconnectivity of different layer networks belonging to the same party as well as instances inter-layer misconnectivity of different layer networks belonging to different parties.  Hope that makes sense.

regards, Neil

BT Design

  

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: 03 May 2011 13:38
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]
> > 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
> >
> >> > end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or
> MEG
> >> to use
> >> > The extent inter-provider MPLS-TP is as yet unknown.  If mixed
> modes
> >> of ICC
> >> > For signaled connections, there is no plan to allow routing based
> on
> >> either

---

From: [email-masked]
Date: Wed, 4 May 2011 01:44:49 -0400

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

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 -

> 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

>> 1       I agree with your view of only having a single addressing 
scheme in a
>> Of course, having an E-NNI and peer interworking between different 
parties in
>> In the case of inter-layer misconnectivity one may receive traffic 
units and
>> It's meant only for the individual(s) or entity named above. If you're 
not
>> the intended
>> is prohibited. If you've received this email in error, please let me 
know
>> immediately

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 May 2011 23:00:26 -0700

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:
> objective for MPLS-TP is to allow for packet based interconnection as well.
>
> Regards,
>
> Malcolm
>
>
>
> *George Swallow <[email-masked]>*
> particular the
>  >> It's meant only for the individual(s) or entity named above. If
> you're not
>  >> the intended

-- 

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

---

From: Maarten vissers <[email-masked]>
Date: Wed, 04 May 2011 06:45:33 +0000

Loa,

The connections in the "Transport Service" layers can be multi-operator connections. Examples are the SDH Transport Service layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c, ..), ATM Transport Service layer connections (ATM VCs), OTN Transport Service layer connections (LO ODUs), Ethernet Transport Service layer connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport Service layer connections (MS-PW, Service-LSP).

These Transport Service layer connections are monitored using pro-active OAM and on-demand OAM between the Service Provider MEG level MEP functions on the UNI-N ports and Service Provider MEG level MIP functions on the E-NNI/IrDI ports. In a multi-operator connection these Service Provider MEG level MEP functions on the UNI-N ports will be located in different operator domains. Also the Service Provider MEG level MIP functions on the E-NNI/IrDI ports will be located in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID MPLS-TP identifiers, then you will have a mixed case.

We can ask the question if there is a need for an MPLS-TP E-NNI/IrDI. 
If the answer is "no" then mixed identifier usage will not be a requirement. 
If the application for MPLS-TP is within an MEF Ethernet Services architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason is that in the MEF architecture the E-NNI/IrDI is defined as an Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer. 
- MPLS-TP Transport Service layer may not be present at all in such MEF Ethernet Services architecture, only the MPLS-TP Transport Path layer could be used (to carry PW-labelled Ethernet Connections) and those MPLS-TP Transport Path connections terminate in the operator domain's edge node (i.e. single operator connections).
- For the case a MPLS-TP Transport Service layer is used in an MEF Ethernet Services architecture the MPLS-TP Transport Service connections will be terminated  in the operator domain's edge node (i.e. single operator connections).

------

MPLS-TP Transport Path layer connections (transport-LSPs) are connecting a PE with an adjacent PE (via zero or more P nodes). Those transport-LSPs do not cross an E-NNI/IrDI.

There is however one exception... when a group of Transport Service layer connections has to be sent from one domain via a second domain to a third domain, this is typically done via a Transport Path layer connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3. Domain treats this domain 1-3 transport path layer connection as a transport service layer connection. E-NNI/IrDI ports in domain 1 and 3 may use different identifiers (ICC, Global-ID) and a mixed case is present. If domains 1 and 3 use the same identifier type, then domain 2 may be using a different identifier type in the MIPs on its E-NNI/IrDI ports.

------

MPLS-TP Section layer connections are connecting adjacent MPLS-TP nodes. In 99.9% of the cases those nodes are in one operator domain. For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different operator domains. If one operator deploys ICC and the other operator deploys Global-ID based MPLS-TP identifiers there is a mixed case.

Regards,
Maarten

> Loa Andersson
> Sent: 4 May 2011 08:00
> To: [email-masked]; [email-masked]
> >  >> single layer network solely belonging to one party. Though you
> may
> > need to
> >  >> 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.
> >  >>
> >  >> 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
> >  >> first one.....especially if you also support the notion of E-NNIs
> in
> > MPLS-TP,
> >  >> recipient, note that disclosing, copying, distributing or using
> this
> >  >> information
> >  >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow
> <[email-masked]>
> >  >>> wrote:
> >  >>>> All -
> >  >>>>
> >  >>>> 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.
> >  >>>> For signaled connections, there is no plan to allow routing
> based on
> >  >>> either
> >  >>>> messages), the providers involved will need to run BGP and have
> AS
> >  >>> numbers.
> >  >>>>

---

From: Maarten vissers <[email-masked]>
Date: Wed, 04 May 2011 07:03:07 +0000

George,

> disallow mixed identifiers, but to say that they are for future study.

Transport networks are multi-operator networks and this requires that transport network technology developments must support multi-operator networks. The MPLS-TP architecture and OAM include capabilities to support such multi-operator networks and associated multi-operator connections at MPLS-TP transport service, transport path and section layers.

With the support of multiple identifier schemes and the support of multi-operator connections, we have to describe and support the mixed identifier cases. Only if we remove from the MPLS_TP architecture and OAM architecture the support for multi-operator networks we can treat mixed identifier cases as a for further study item.

Regards,
Maarten

> George Swallow
> Sent: 3 May 2011 17:09
> To: Andrew G. Malis; [email-masked]
> Cc: [email-masked]
> of the
> have only

---

From: <[email-masked]>
Date: Wed, 4 May 2011 08:21:10 +0100

Thanks Malcolm,

I think we need to careful and precise as some folks could be confused by what you wrote unless they have a proper model in their head of what is really needed here.  I am sure you understand it Malcolm but I am not sure everyone else does.  So let me try and step through this....

In all networking scenarios there is always:
-	a TOS layer network present that interfaces with external message/file/stream applications...this is the whole point of *all* networking, including providing lower layer transport networks
-	a BOS layer network present that modulates an EM wave on either metallic/optical/radio media...this is how we ultimately send the information generated by the TOS external interfacing message/file/stream applications over large geographic distance.

We do not simply connect any non-TOS layer networks together on their own 'just for the fun of it' ....they MUST ultimately support a TOS layer network and external message/file/stream applications as I noted in the 1st bullet above.  It seems to me some folks working on transport networks somehow forget this crucial point and only think about their lower layer network.....and this is what can generate lots of unnecessary work and confusion IMO.

Now we have to connect all layer networks together at the BOS....that is just a physical fact.  However, this does not mean we have an E-NNI here.   And I am sure this is why you were careful to differentiate interconnecting the CP and DP cases Malcolm in your mail below.  However there is a little more to it than just this observation of the facts.....

At a lower transport layer network level we cannot (and indeed must not) try and judge the importance of the ultimate TOS message/file/stream applications.  And even more generally we must not try and 'guess/assume' what higher layer client symbols mean.....the client can change the alphabet and/or semantics of its symbols and/or encrypt the symbols.  All we should be doing in transport networks is to treat the conveyance of each client symbol equally....and ultimately this means shipping bits in order (a bit is the atomic information unit - see Shannon).  If you look at all co-cs mode transport networks today this is exactly what they do.  And this is what is meant by transparency.

So I hope this now clarifies the difference between a BOS physical interconnection and what E-NNIs are....proper E-NNIs only apply to TOS layer networks and we should not get carried away with elaborate specification of BOS interconnections...THE key requirement here is transparency.  Aside=> There is a whole bunch of stuff that could now follow on how QoS (at least how some folks think of QoS) is not relevant to transport networks.....another day maybe.

regards, Neil

BT Design

From: [email-masked] [mailto:[email-masked]] 
Sent: 04 May 2011 06:45
To: George Swallow
Cc: Andrew G. Malis; [email-masked]; [email-masked]; Harrison,N,Neil,DKQ7 R
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

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 

Andy -

...George

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 May 2011 17:48:08 +0200

Maarten,

lots of interesting data and thoughts, however not addressing the
question I asked.

Let us assume that an LSP go across several operators transport
networks, e.g. it starts from operator A, go across operator B, C and
D to end up at a different geographical loacation i operator A's
network again.

Now how likely is operator C, would let operator A, whom he does not
really need to have a relationship with (masked by B and D) initiate
OAM actions that can cause MIPs in operator A's network take actions
that is totally unexpected and uncontrolled by C?

Would appreciate input from operators!

/Loa

On 2011-05-04 08:45, Maarten vissers wrote:
>>> *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:
>>>   >>
>>>   >>>>  George, Eric,&  Matthew

--

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 May 2011 19:26:00 +0200

Hej Loa,

> Would appreciate input from operators!

A similar scenario on the use of OAm is described in:
http://www.ietf.org/id/draft-tsb-mpls-tp-ach-ptn-00.txt  or
shown in slides 9-12 of the presentation in the RTGA open meeting
http://www.ietf.org/proceedings/80/slides/rtgarea-1.ppt

These figures are taken from ITU-T contribution C-1124
which is signed by several operators. This contribution
was supported by other operators as well.

It is possible to use the same OAM (PTN or PSN) in
all domains (A, B and C in figures 1 and 2).
You can see that operator B *cannot* influence the OAM
in domains A and C nor in the top layer end-to-end OAM.

Regards, Huub.
===============

>> The connections in the "Transport Service" layers can be
>> multi-operator connections. Examples are the SDH Transport Service
>> layer connections (VC-11/VT-1.5, VC-12/VT-2, VC-3/STS-1, VC-4/STS-3c,
>> ..), ATM Transport Service layer connections (ATM VCs), OTN Transport
>> Service layer connections (LO ODUs), Ethernet Transport Service layer
>> connections (S-VLAN EC, BSI EC) and in MPLS-TP the MPLS-TP Transport
>> Service layer connections (MS-PW, Service-LSP).
>>
>> These Transport Service layer connections are monitored using
>> pro-active OAM and on-demand OAM between the Service Provider MEG
>> level MEP functions on the UNI-N ports and Service Provider MEG level
>> MIP functions on the E-NNI/IrDI ports. In a multi-operator connection
>> these Service Provider MEG level MEP functions on the UNI-N ports will
>> be located in different operator domains. Also the Service Provider
>> MEG level MIP functions on the E-NNI/IrDI ports will be located in
>> different operator domains. If one operator deploys ICC and the other
>> operator deploys Global-ID MPLS-TP identifiers, then you will have a
>> mixed case.
>>
>> If the application for MPLS-TP is within an MEF Ethernet Services
>> architecture, then there is no need for an MPLS-TP E-NNI/IrDI; reason
>> is that in the MEF architecture the E-NNI/IrDI is defined as an
>> Ethernet E-NNI/IrDI and part of the Ethernet Transport Service layer.
>> - MPLS-TP Transport Service layer may not be present at all in such
>> MEF Ethernet Services architecture, only the MPLS-TP Transport Path
>> layer could be used (to carry PW-labelled Ethernet Connections) and
>> those MPLS-TP Transport Path connections terminate in the operator
>> domain's edge node (i.e. single operator connections).
>> - For the case a MPLS-TP Transport Service layer is used in an MEF
>> Ethernet Services architecture the MPLS-TP Transport Service
>> connections will be terminated in the operator domain's edge node
>> (i.e. single operator connections).
>>
>> ------
>>
>> MPLS-TP Transport Path layer connections (transport-LSPs) are
>> connecting a PE with an adjacent PE (via zero or more P nodes). Those
>> transport-LSPs do not cross an E-NNI/IrDI.
>>
>> There is however one exception... when a group of Transport Service
>> layer connections has to be sent from one domain via a second domain
>> to a third domain, this is typically done via a Transport Path layer
>> connection with endpoints in the E-NNI/IrDI ports of domain 1 and 3.
>> Domain treats this domain 1-3 transport path layer connection as a
>> transport service layer connection. E-NNI/IrDI ports in domain 1 and 3
>> may use different identifiers (ICC, Global-ID) and a mixed case is
>> present. If domains 1 and 3 use the same identifier type, then domain
>> 2 may be using a different identifier type in the MIPs on its
>> E-NNI/IrDI ports.
>>
>> ------
>>
>> MPLS-TP Section layer connections are connecting adjacent MPLS-TP
>> nodes. In 99.9% of the cases those nodes are in one operator domain.
>> For the case of an MPLS-TP E-NNI/IrDI the two nodes are in different
>> operator domains. If one operator deploys ICC and the other operator
>> deploys Global-ID based MPLS-TP identifiers there is a mixed case.
>>
>> Regards,
>> Maarten
>>
>>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2011 22:04:04 +0100

So, I may have understood the import of those figures (specifically figure 3 in draft-palanivelan-bfd-v2-gr-11.txt) but I read that to mean that, in the case of mismatched OAM types, one of the OAM types (in the figure, the PSN type is indicated) would be run end-to-end, and the local OAM types would be used within the networks according to what they supported.

Now, noting very clearly that OAM types have nothing whatsoever to do with MPLS-TP Identifiers, you seem to be suggesting that the same approach holds. That would mean that (to paraphrase Figure 3) network A might use one form of identifier and network B might use another form of identifier, but the end-to-end identifiers would be of one form only.

Have I misunderstood you?

Adrian

> Huub van Helvoort
> Sent: 06 May 2011 18:26
> To: [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 10 May 2011 09:35:45 +0200

Hello Adrian,

You replied:

> So, I may have understood the import of those figures (specifically
 > figure 3 in draft-palanivelan-bfd-v2-gr-11.txt)

Just to avoid confusion I was refering to the figures in
draft-tsb-mpls-tp-ach-ptn-00.txt and looking at the text below
you may be refering to that draft too.

> but I read that to  mean that, in the case of mismatched OAM types,
 > one of the OAM types (in the figure, the PSN type is indicated)
 > would be run end-to-end, and the local OAM types would be used
 > within the networks according to what they supported.

Indeed.

> Now, noting very clearly that OAM types have nothing whatsoever to
 > do with MPLS-TP Identifiers, you seem to be suggesting that the
 > same approach holds.

The OAM types are independent of the used identifiers.

> That would mean that (to paraphrase Figure 3) network A might use
 > one form of identifier and network B might use another form of 
identifier,

yes.

> but the end-to-end identifiers would be of one form only.

Indeed, and the identifier that is used end-to-end can be either
form A or form B. The actual form has to be agreed between the
operators of network A and B.

> Have I misunderstood you?

I don't think so.

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 11 May 2011 08:52:31 +0200

All,

Please let me add some clarification:

> operators of network A and B.

This can mean that in the direction A --> B one form can be used
(i.e. the form that operator A uses in his whole network) and
that in direction B --> A of the same LSP/PW form B can be used
(the form that operator B uses in his network).
At the sink MEP the identifier has to be verified, the form can
be independent of the form used in the network. Operators A and B
inform each other about the "value" of the expected identifier.

Regards, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 May 2011 18:57:01 +0100

Hi Huub,

Converging your two emails...

> you may be refering to that draft too.

Yeah! Sorry about that. Sloppy cut and paste. So many I-Ds and so little time.

> operators of network A and B.

| This can mean that in the direction A --> B one form can be used
| (i.e. the form that operator A uses in his whole network) and
| that in direction B --> A of the same LSP/PW form B can be used
| (the form that operator B uses in his network).
| At the sink MEP the identifier has to be verified, the form can
| be independent of the form used in the network. Operators A and B
| inform each other about the "value" of the expected identifier.

I'm not clear about this.
It is true that this *could* be done, but it also seems that it would be a bit odd to mix and match like this for a bidirectional LSP. However, I can see that for individual LSPs the behavior could be one of:
- always be configured so "A runs over B"
or
- always depend on the initiating network
or
- one mechanism always runs over the other

My interpretation of the OAM discussion was that "once the IETF OAM mechanism was standardised, all edge nodes would need to support it" so that we would have to have a case where the third option was the only one available. 

Now, regardless of all that, it seems that we have reached agreement that, while the end points might need to support both identifier formats, there would never be a case where mixed identifier formats were used.

Cheers,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 12 May 2011 00:46:47 +0200

Hello Adrian,

OK, I will try to be more clear:

> It is true that this *could* be done, but it also seems that it
 > would be a bit odd to mix and match like this for a bidirectional LSP.

I did mean to write that this *MUST* be done.
This will allow each operator to use his own identifier form for all
MEPs and MIPs in the forward direction. The rrsponses from these
MEPs and MIPs will contain the identifiers that he is used to, because 
in their responses they copy the received identifier.

 > However, I can see that for individual LSPs the behavior could be one of:

What you describe can be valid for the OAM because in this case the
forward and backward direction have to use the same mechanisms.

> My interpretation of the OAM discussion was that "once the IETF OAM
 > mechanism was standardised, all edge nodes would need to support it"
 > so that we would have to have a case where the third option was the
 > only one available.

As you write: this is OAM discussion.
The identifier discussion is something else.

> Now, regardless of all that, it seems that we have reached agreement
 > that, while the end points might need to support both identifier
 > formats, there would never be a case where mixed identifier formats
 > were used.

Apparently we don't agree.

I still have the opinion that mixed identifier formats *must* be
supported as I described in my initial response.

Best regards, Huub.

---

From: Ross Callon <[email-masked]>
Date: Wed, 18 May 2011 14:40:34 -0400

After discussion on the MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifiers without a change in this area.

This decision neither supports nor precludes the possibility that at some point in the future, after draft-ietf-mpls-tp-identifiers is approved and published as an RFC, the WG might consider additional work to extend the MPLS protocols to allow mixed identifiers.

Thanks,
Ross and Loa (as MPLS WG chairs)

[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, for this one document he is recused from his role as WG co-chair.]

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Monday, April 25, 2011 5:17 PM
To: [email-masked]
Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

All -

George, Eric, & Matthew

---

From: [email-masked]
Date: Thu, 19 May 2011 04:25:11 -0400

Ross,

I disappointed and, based on my reading of the emails on this thread, 
surprised that this decision has been taken.  Could you please elaborate 
on the reasoning behind this decision.

Regards,

Malcolm

Ross Callon <[email-masked]> 
Sent by: [email-masked]
18/05/2011 02:40 PM

To
"[email-masked]" <[email-masked]>
cc

Subject

After discussion on the MPLS WG email list, there is no consensus to 
change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and 
ICC?s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly 
rough) consensus is to leave the document as currently defined. The 
authors are therefore instructed to continue progression of 
draft-ietf-mpls-tp-identifiers without a change in this area.
 
This decision neither supports nor precludes the possibility that at some 
point in the future, after draft-ietf-mpls-tp-identifiers is approved and 
published as an RFC, the WG might consider additional work to extend the 
MPLS protocols to allow mixed identifiers. 
 
Thanks,
 
[Note that since George is co-author of draft-ietf-mpls-tp-identifiers, 
for this one document he is recused from his role as WG co-chair.]

All -

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 authors of the draft are very reluctant to do this. 
1.      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. 
2.      Such an addition will add numerous object formats, and test cases. 

3.      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. 
4.      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.

---

From: Rui Costa <[email-masked]>
Date: Fri, 20 May 2011 09:20:41 +0100

Most if not all circuits in PT's networks are currently identified in an ICC-oriented way. It's something defined by ITU-T before MPLS or MPLS-TP. Customer orientation made this a preferred DB primary indexation.
Operators are the final client of ITU-T MPLS-TP standards, which depend on RFC drafts like this one, so i also don't understand the decision of not changing draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC's for the same Tunnel, LSP, PW, or Section. It looks like just an unilateral decision to allow/promote one type of IDs while preventing others.

Regards,
Rui

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: quarta-feira, 18 de Maio de 2011 19:41
To: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Thanks,

All -

George, Eric, & Matthew

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 May 2011 12:28:36 -0400

Malcolm,

    As a co-author of the draft in question, I completely support this decision.

    As I already explained to another person asking the same question, the
bit about "no consensus to change" says it all.

    In my opinion, this is a quite sufficiently detailed response.  The absence
of a consensus to change means no change.  We do not typically require a
strong consensus to continue on the current path.

    I am reasonably certain you apply similar rules yourself when working in
other SDOs.

--
Eric
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Ross,

I disappointed and, based on my reading of the emails on this thread, surprised that this decision has been taken.  Could you please elaborate on the reasoning behind this decision.

Regards,

Malcolm

18/05/2011 02:40 PM

To

Thanks,

All -

---

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

Eric,

I find that argument somewhat circular since  we did not have consensus to 
omit this.

Regards,

Malcolm

Eric Gray <[email-masked]> 
20/05/2011 12:28 PM

To
"[email-masked]" <[email-masked]>, Ross Callon 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject
RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm,
 
    As a co-author of the draft in question, I completely support this 
decision.

 
    In my opinion, this is a quite sufficiently detailed response.  The 
absence
of a consensus to change means no change.  We do not typically require a
strong consensus to continue on the current path.
 
    I am reasonably certain you apply similar rules yourself when working 
in
other SDOs.
 
--
Eric From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Thursday, May 19, 2011 4:25 AM
To: Ross Callon
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Ross, 

Regards, 

Malcolm 

To

Subject

  
Thanks, 

  
All -

The authors of the draft are very reluctant to do this.   
1.        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. 
2.        Such an addition will add numerous object formats, and test 
cases. 
3.        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. 
4.        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.

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 21 May 2011 20:44:55 -0400

Malcolm,

	I think you have been doing this long enough to realize that it is not you who call consensus; its the WG chairs.  As I recall, that has been done.

	--Tom

> 
> Eric, 
> 
> I find that argument somewhat circular since  we did not have consensus to omit this. 
> 
> Regards, 
> 
> Malcolm 
> 
> 
> 
> "[email-masked]" <[email-masked]>, Ross Callon <[email-masked]>
> cc
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject
> After discussion on the MPLS WG email list, there is no consensus to change draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly rough) consensus is to leave the document as currently defined. The authors are therefore instructed to continue progression of draft-ietf-mpls-tp-identifiers without a change in this area. 
>

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 22 May 2011 07:48:29 +0200

Malcolm, hi

Borrowing the logic from other SDO's - any standards work is
contribution driven - if you or any of the other persons feel that they
see a need to extend the current draft with features that are not
covered by the current work, they are able to write a new I-D that
extends the functionality and details how this extension can be
supported and whose responsibility (i.e. which MEP) it is to support all
of the different formats.

Best regards,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Sunday, May 22, 2011 3:05 AM
To: Eric Gray
Cc: Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Eric, 

I find that argument somewhat circular since  we did not have consensus
to omit this. 

Regards, 

Malcolm 

20/05/2011 12:28 PM 

To

cc

Subject

		

Malcolm, 

    As I already explained to another person asking the same question,
the 
bit about "no consensus to change" says it all. 

  
    I am reasonably certain you apply similar rules yourself when
working in 
other SDOs. 
  
-- 
Eric 

[email-masked]

Ross, 

Regards, 

Malcolm 

18/05/2011 02:40 PM 

To

cc

Subject

		

ICC's for the same Tunnel, LSP, PW, or Section. Instead, the (admittedly
 
This decision neither supports nor precludes the possibility that at
some point in the future, after draft-ietf-mpls-tp-identifiers is
approved and published as an RFC, the WG might consider additional work
to extend the MPLS protocols to allow mixed identifiers. 
 
Thanks, 

 
All -

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 authors of the draft are very reluctant to do this.   
1.        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. 
2.        Such an addition will add numerous object formats, and test
cases. 
3.        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. 
4.        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.

---

From: John E Drake <[email-masked]>
Date: Sun, 22 May 2011 11:01:15 -0700

Malcom,

Mixed identifiers are not part of the draft.  There was no consensus to add them to the draft.  Therefore, they will not be added to the draft.  What part of 'No' do you not understand?

As an aside, you have a lot of gall attempting to judge consensus.

John

Sent from my iPhone

On May 21, 2011, at 8:05 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Eric,

Regards,

Malcolm

Eric Gray <[email-masked]<mailto:[email-masked]>>

20/05/2011 12:28 PM

To
        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ross Callon <[email-masked]<mailto:[email-masked]>>
cc
        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject
        RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

Ross,

Regards,

Malcolm

Ross Callon <[email-masked]<mailto:[email-masked]>>
Sent by: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

18/05/2011 02:40 PM

To
        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
cc

Subject

Thanks,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Monday, April 25, 2011 5:17 PM
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

All -

George, Eric, & Matthew _______________________________________________
mpls mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/mpls>https://www.ietf.org/mailman/listinfo/mpls

<ATT00001..txt>

---

From: Larry <[email-masked]>
Date: Mon, 23 May 2011 09:54:07 +0800 (CST)

I fully agree and support. Thank you!

*************************************************************************
Han Li, Ph.D 
China Mobile Research Institute
Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 
Fax: +86 10 63601087 
MOBILE: 13501093385 
*************************************************************************

--- 11年5月20日，周五, Rui Costa <[email-masked]> 写道：

发件人: Rui Costa <[email-masked]>
主题: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
收件人: "Ross Callon" <[email-masked]>, "[email-masked]" <[email-masked]>
日期: 2011年5月20日,周五,下午4:20

Most if not all circuits in PT’s networks are currently identified in an ICC-oriented way. It’s something defined by ITU-T before MPLS or MPLS-TP. Customer orientation made this a preferred DB primary indexation.              
Operators are the final client of ITU-T MPLS-TP standards, which depend on RFC drafts like this one, so i also don’t understand the decision of not changing draft-ietf-mpls-tp-identifiers to allow mixing of Global-IDs and ICC’s for the same Tunnel, LSP, PW, or Section. It looks like just an unilateral decision to allow/promote one type of IDs while preventing others. 
 
Regards,              
Rui

 
 
Thanks,

 
All -

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. 

George, Eric, & Matthew

---

From: Ross Callon <[email-masked]>
Date: Mon, 23 May 2011 22:02:33 -0400

Malcolm;

There has been extensive discussion of this issue on the MPLS WG email list since George Swallow's original email of Mon 4/25/2011 5:17 PM. As has been pointed out there is no consensus to include mixed identifier types in the current draft. Admittedly the consensus to leave it out is rough, but this is the consensus that we have.

You and others are welcome to author or co-author a draft which points out scenarios in which mixing ICC and Global-IDs is useful, and the protocol mechanisms needed to support this. If you choose to write such a draft, then we would welcome discussion of this draft on the MPLS WG email list.

Thanks,
Ross and Loa (as MPLS WG co-chairs)

From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, May 21, 2011 8:05 PM
To: Eric Gray
Cc: [email-masked]; [email-masked]; Ross Callon
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Eric,

Regards,

Malcolm

20/05/2011 12:28 PM

To

cc

Subject

Malcolm,

Ross,

Regards,

Malcolm

18/05/2011 02:40 PM

To

cc

Subject

Thanks,

All -

---

From: [email-masked]
Date: Wed, 25 May 2011 17:27:28 -0400

Ross,

I understand that you have declared rough consensus on this point and the 
WG has moved on.

However, I was looking for some further technical rational for this 
decision.  From my perspective those supporting the need to mix ICC and 
Global-ID have identified the scenarios, I do not see a need for any 
protocol extensions, just the removal of the restriction and I did not see 
any strong technical objections. Your perspective on the technical issues 
would provide some useful guidance on the points that need to be addressed 
if I, or some others, decide to write a new draft, as you suggest.

Regards,

Malcolm

23/05/2011 10:02 PM

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

Malcolm;
 
There has been extensive discussion of this issue on the MPLS WG email 
list since George Swallow?s original email of Mon 4/25/2011 5:17 PM. As 
has been pointed out there is no consensus to include mixed identifier 
types in the current draft. Admittedly the consensus to leave it out is 
rough, but this is the consensus that we have. 
 
You and others are welcome to author or co-author a draft which points out 
scenarios in which mixing ICC and Global-IDs is useful, and the protocol 
mechanisms needed to support this. If you choose to write such a draft, 
then we would welcome discussion of this draft on the MPLS WG email list.
 
Thanks, 

Eric, 

Regards, 

Malcolm 

To

Malcolm, 

 

-- 
Eric 

Ross, 

Regards, 

Malcolm 

To

Subject

 
Thanks, 

 
All -