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

From: George Swallow <[email-masked]>
Date: Mon, 25 Apr 2011 17:16:47 -0400

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.

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.

We are looking for input/consensus from the WG.

George, Eric, & Matthew

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Apr 2011 06:59:44 +0300

George, and all,
I support the current restriction of not mixing Global and ICC-based identifiers at the ends of an LSP.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of George Swallow [[email-masked]]
Sent: Tuesday, April 26, 2011 12:16 AM
To: [email-masked]
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.
 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.

George, Eric, & Matthew

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: <[email-masked]>
Date: Tue, 26 Apr 2011 09:14:31 +0100

George,

IMO this is a disaster (on many levels).....see a few remarks in-line:

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: 25 April 2011 22:17
To: [email-masked]
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.
NH=> The (access point) addressing of any layer network (whatever the mode) is crucial to get right at t=0.  This has never been properly recognised/appreciated for MPLS (due to its initial symbiotic relationship with a cl-ps mode IP layer network...BTW IPv4 and IPv6 are very different IP layer networks), let alone the quite artificial/unnecessary MS PW layer network that has been created (moreover, the initial arch LDP merging problem that forced PW labels to assume a source address semantic which is quite the opposite of the forwarding (DA proxy) semantic a PW label needed in the MS case ....see my mail to Matthew Bocci/PWE3 29 Nov 2008 that explains this problem in some detail).

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.
NH=> Hmmm.  If MPLS-TP is supposed to be a transport network then it MUST deliver transparency to its clients.  I am not sure many folks in ITU, let alone IETF, properly understand this from what I have seen.  However, MPLS-TP cannot be transparent as long as it persists in having traditional LSP sublayering (transport networks only require proper client/server layering behaviour) and, much worse in many respects, *MS* PWs......no transport network worthy of the name generates another form of unnecessary layer network above it (esp when that layer network was only a product of co-ps mode arch violations in a previously spin of MPLS that has to be deprecated in MPLS-TP).

The ITU liaison requests that we allow mixed use.
NH=> It is only in *public TOS* layer networks that all parties MUST agree on a common, well-structured and enduring addressing structure (CF the problems caused by the small size of v4 addressing in the public Internet, and within this the initial Classful structure).  This is because one is required to horizontally partition these layer networks between different operating parties at E-NNIs and so getting the addressing right at the outset is crucial (it is very hard to change addressing later if its wrong).  This consideration does NOT apply to non-TOS layer networks however.....which is the vast majority of layer network modes/technologies, including all spins of MPLS and its unnecessary PW layer network spawn.  One can, of course, create such E-NNIs in non-TOS layer networks and thus generate lots of problems/costs....indeed one can do all manner of unnecessary things in networking.

 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.
NH=> You only (and quite incorrectly) think of peering here.  You should actually only be concerned about true client/server layering too....and this does hold a latent addressing problems wrt misconnectivity which I'll come back to shortly.  Also note that mixed DP cases of layering and sublayering are 'not a great idea' and will generate further problems in the peering case anyway....but as I have noted above, sublayering in a transport network is unnecessary.

 1.  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.
NH=> I see we are still sort-of clinging to the 'common instance of routing' myth here.  I think its time to let go of this one now George.  The GMPLS folks had to let go of this a long time ago as its is just plain impossible to have a common instance of routing across all layer networks TOS to BOS.

We are looking for input/consensus from the WG.
NH=> On what?  Agreeing to continue to endorse/promulgate arch and technical errors?

Anyway, let me close by noting a new misconnectivity problem that we will need to think about in MPLS-TP.  In traditional MPLS one only had intra-layer misconnectivity to worry about.  However, even this was complicated because:
-      we had LSP sublayering
-      we did not have consistent characteristic information (CI) wrt the meaning of a MPLS traffic unit header...esp the meaning of its (semantically overloaded) label field.

We should have removed both these problems in MPLS-TP as we were supposed to have been designing a transport network.  But park that for now.

As I noted earlier, THE  key service a transport network has to provide to its clients is client symbol transport transparency...and note carefully that this also includes the crucial MPLS-TPoverMPLS-TP case, where MPLS-TP is now the client.

Now the co-ps mode is not like the co-cs mode when considering client/server relationships.  In the co-cs case, and due to the physics of how labelling and resource partitioning works here, one cannot have XoverX (eg T1overT1, VC4overVC4, etc).  However, one can have XoverX in the co-ps mode.

What this means in practice is that we can't have ambiguous cases of nested client/server CI and inter-layer misconnectivity in the co-cs mode.  However, with bad design we can have these problems in the co-ps mode.

So, to cut to the chase, we can now have inter-layer and well as intra-layer misconnectivity in MPLS-TP....where the latter intra-layer misconnectivity case also retains instances of sublayer misconnectivity.  Aside=> One can also add even more unnecessary TCM OAM sublayering to the mix if one wants....remember, we are dealing with a non-TOS layer network here so all these problems are self-inflicted (whether by conscious bad design or ignorance).

Now providing one has consistent DP OAM and applies this to *all* connections within a co-ps mode layer network based on label-swapping (Aside=> this is not a problem in a co-ps mode layer network that does not use label-swapping) one can mitigate the effects of a lack of consistent CI wrt intra-layer misconnectivity (ie no matter where a DP connection is misdirected the trail termination point must be able to parse/understand OAM traffic unit fields).  Now when we can also have client/server co-ps mode layering we need to extend this notion of consistent DP OAM to all the layer networks to cater for the cases of inter-layer misconnectivity.

Note - This is NOT the same problem as TOS layer network E-NNI peering wrt its implications for access point addressing, ie all parties must agree on a common/enduring forms of addressing.  But we do need to ensure that addressing in each layer network is unique and *well-known to all parties*..as we should always be using pukka access point addressing in the CV OAM flows on *all* such nested layer networks (eg we need to know where any sources of misconnectivity we see in our layer network come from).

Something else to think about....

regards, Neil

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

George, Eric, & Matthew

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 26 Apr 2011 08:30:02 -0400

I agree with the authors of the draft and recommend we reject the liaison request for mixed use.

	--Tom

> 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. 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: John E Drake <[email-masked]>
Date: Tue, 26 Apr 2011 12:34:40 -0700

George,

I agree that mixed use identifiers do not make sense, for the reasons both you and Neil  cite.

Thanks,

John

Sent from my iPhone

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

All -

George, Eric, & Matthew

---

From: Autumn Liu <[email-masked]>
Date: Tue, 26 Apr 2011 20:24:04 -0400

+1

-Autumn

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, April 26, 2011 5:30 AM
To: George Swallow
Cc: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

--Tom

All -

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

---

From: [email-masked]
Date: Wed, 27 Apr 2011 00:04:43 -0400

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.

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.

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

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 -

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: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 Apr 2011 07:43:49 +0200

Hi,

I think such mixing environment requires more study. We need to better
understand the applicability and the implications on all components and
planes...

When such a mixing environment is completely analyzed and understood, if
needed can be added in a later phase. 

IMO, in the meantime the document should both ICC OR IP environments,
with no mixing identifiers. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Wednesday, April 27, 2011 7: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. 

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. 

Regards, 

Malcolm 

25/04/2011 05:16 PM 

To

<[email-masked]> 

cc

Subject

		

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.

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.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 27 Apr 2011 09:06:03 +0300

Malcolm, Nurit and all,
One technical reason for not mixing identifiers of different types is that in certain situations these identifiers are treated as an ordered set, i.e., it is possible to say when one of these identifiers is "less" than the other one.
The typical use case is tie-breaking in various protocols (e.g., for deciding which request for a protection-related has to be granted). Even if the current set of MPLS-TP protocols does not use such tie-breakers, I would not preclude this usage in future.

It is relatively simple to impose some order on identifiers of the same type. Imposing an order on a superset of identifiers at least requires some thought.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, April 27, 2011 8:44 AM
To: [email-masked]; George Swallow
Cc: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi,
I think such mixing environment requires more study. We need to better understand the applicability and the implications on all components and planes...
When such a mixing environment is completely analyzed and understood, if needed can be added in a later phase.
IMO, in the meantime the document should both ICC OR IP environments, with no mixing identifiers.
Best regards,
Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, April 27, 2011 7: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.

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.

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

Regards,

Malcolm

25/04/2011 05:16 PM

To

<[email-masked]>

cc

Subject

All -

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.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Apr 2011 00:34:33 -0700

Sasha,

from 5036

       2. LSR1 determines whether it will play the active or passive role
          in session establishment by comparing addresses A1 and A2 as
          unsigned integers.  If A1 > A2, LSR1 plays the active role;
          otherwise, it is passive.

tLDP maybe used to set up PWs in MPLS based transport networks!

/Loa

On 2011-04-26 23:06, Alexander Vainshtein wrote:
> Malcolm, Nurit and all,
>
> One /technical/ reason for not mixing identifiers of different types is
> that in certain situations these identifiers are treated as an ordered
> set, i.e., it is possible to say when one of these identifiers is “less”
> than the other one.
>
> The typical use case is tie-breaking in various protocols (e.g., for
> deciding which request for a protection-related has to be granted). Even
> if the current set of MPLS-TP protocols does not use such tie-breakers,
> I would not preclude this usage in future.
>
> It is relatively simple to impose some order on identifiers of the same
> type. Imposing an order on a superset of identifiers at least requires
> some thought.
>
> Regards,
>
> Sasha
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Sprecher, Nurit (NSN - IL/Hod HaSharon)
> *Sent:* Wednesday, April 27, 2011 8:44 AM
> *To:* [email-masked]; George Swallow
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
> Hi,
>
> planes…
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext [email-masked]
> *Sent:* Wednesday, April 27, 2011 7:05 AM
> *To:* George Swallow
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
>
> George,
>
> same scheme removes the freedom to select the between ICC and Global
> (IP) identifiers.
>
> *George Swallow <[email-masked]>*
> 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.
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>
>
>

-- 

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: Eric Gray <[email-masked]>
Date: Wed, 27 Apr 2011 12:11:05 -0400

As one of the co-authors on this draft, I support a restriction to using a common
form of identifier throughout an LSP or PW.

In my opinion, it is far better to terminate LSPs or PWs at the point where there
might be an identifier form change and "stitch" them together if that is what the
operators want/agree to do.  This limits the need-to-know for the mapping of one
form of identifier to the other to the point at which this occurs, rather than at each
node in the LSP or (potentially) MS-PW.

________________________________
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: Eric Gray <[email-masked]>
Date: Wed, 27 Apr 2011 12:15:51 -0400

Neil,

    In short-form, are you saying that you support the restriction, or that you
think doing so is a bad idea?

--
Eric
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 26, 2011 4:15 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

George,

---[SNIP]---

---

From: [email-masked]
Date: Wed, 27 Apr 2011 18:44:10 -0400

Eric,

If you "stitch" the LSP or PW and change identifiers you will not have end 
to end OAM which is a requirement for a MPLS-TP transport network.

Regards,

Malcolm

Eric Gray <[email-masked]> 
Sent by: [email-masked]
27/04/2011 12:11 PM

To
George Swallow <[email-masked]>, "[email-masked]" <[email-masked]>
cc

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

As one of the co-authors on this draft, I support a restriction to using a 
common
form of identifier throughout an LSP or PW.
 
In my opinion, it is far better to terminate LSPs or PWs at the point 
where there
might be an identifier form change and "stitch" them together if that is 
what the
operators want/agree to do.  This limits the need-to-know for the mapping 
of one
form of identifier to the other to the point at which this occurs, rather 
than at each
node in the LSP or (potentially) MS-PW.

George Swallow

All -

---

From: [email-masked]
Date: Wed, 27 Apr 2011 18:49:33 -0400

Nurit,

The initial last call of this draft was one year ago.  How much longer do 
we need to study this before all the requirements can be met.

I see no major problems, please identify some specific issues.

If mixing of identifier types is not allowed then it will be a significant 
impediment to the deployment of MPLS-TP in a multi carrier transport 
network application.

Regards,

Malcolm

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
27/04/2011 01:43 AM

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

Hi,
planes?
IMO, in the meantime the document should both ICC OR IP environments, with 
no mixing identifiers. 
Best regards,
Nurit

George, 

Regards, 

Malcolm 

To
<[email-masked]> 
cc

Subject

All -

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. 
signaling messages), the providers involved will need to run BGP and have 
AS numbers.

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Apr 2011 15:53:21 -0700

Malcolm,

That's incorrect.  There is a single end-to-end LSP composed of different pieces, each under the control of a different administrative entity.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 27, 2011 3:44 PM
To: Eric Gray
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Eric,

If you "stitch" the LSP or PW and change identifiers you will not have end to end OAM which is a requirement for a MPLS-TP transport network.

Regards,

Malcolm

27/04/2011 12:11 PM

To

cc

Subject

All -

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Apr 2011 15:56:42 -0700

Malcolm,

Please see the other email I just sent on this topic.  LSP stitching and multi-segment psedowire were designed to handle situations in which different administrative domains each control different pieces of an end-to-end LSP or pseudowire.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 27, 2011 3:50 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Nurit,

The initial last call of this draft was one year ago.  How much longer do we need to study this before all the requirements can be met.

If mixing of identifier types is not allowed then it will be a significant impediment to the deployment of MPLS-TP in a multi carrier transport network application.

Regards,

Malcolm

27/04/2011 01:43 AM

To

cc

<[email-masked]>

Subject

Hi,

George,

Regards,

Malcolm

25/04/2011 05:16 PM

To

<[email-masked]>

cc

Subject

All -

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Apr 2011 16:11:26 -0700

Dear Malcolm,
I agree that e2e OAM is one of requirements for MPLS-TP but I cannot find
implicit, less explicit requirement to support e2e OAM over MPLS-TP LSP and
PW with heterogeneous addressing (mixed IP and ICC).

Regards,
Greg

On Wed, Apr 27, 2011 at 3:44 PM, <[email-masked]> wrote:

>  *Eric Gray <[email-masked]>*
> ------------------------------
> *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 -
>
> 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.
>
> a fairly trivial procedure.  Many organizations if not most already have AS
> Numbers.
> 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

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Apr 2011 16:25:16 -0700

Malcolm,

I interpreted Eric's use of  'stitching'  to be in the RFC 5150 sense.  I think I will let him clarify, but if used in the RFC 5150 sense, a 'stitched' LSP would have end-to-end OAM, and different pieces could use different identifiers in the control and management planes.

Also, as Greg notes, this appears to be a late breaking requirement.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 27, 2011 4:11 PM
To: John E Drake
Cc: Eric Gray; [email-masked]; [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

John,

The proposal from Eric is that the identifiers are "switched" at the stitching point, this requires a complex interworking function and interrupts the end to end OAM flow - i.e. data packet can transit without any manipulation (other than the normal label swap) but OAM packets must be intercepted and manipulated in the middle of the connection so it is no longer an end to end construct.  User data and OAM no longer fully fate share.

Regards,

Malcolm

John E Drake <[email-masked]>

27/04/2011 06:53 PM

To

"[email-masked]" <[email-masked]>, Eric Gray <[email-masked]>

cc

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

Malcolm,

Thanks,

John

Sent from my iPhone

Eric,

Regards,

Malcolm

27/04/2011 12:11 PM

To

cc

Subject

All -

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Apr 2011 23:23:04 -0400

In message <[email-masked]>
George Swallow writes:
> 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.
>  
> 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.
>  

George,

I agree with the authors on this.  Keep the restriction.  Do not allow
mixed ICC and IP identifiers.

If ever there were a transition necessary an LSR can support both
address types during the transition but not have any one PW or LSP
with different MEG ID on either side.

Curtis

---

From: [email-masked]
Date: Wed, 27 Apr 2011 23:24:46 -0400

John,

John, if you do not allow mix identifier types how can you have an end to 
end CV message.  If you are using stitching to allow a single identifier 
type then the identifiers in a CV message must be translated at the 
stitching point.  A very bad idea!

This is not a "late breaking requirement".  The requirements for support 
of both ICC and IP identifiers schemes is well documented.  As is the 
expectation of using MPLS-TP in multi-operator transport networks.  Hence 
the need to support both on a LSP/PW.  This comment has been made during 
previous last calls on this draft.

Regards,

Malcolm

27/04/2011 07:25 PM

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

Malcolm,
 
I interpreted Eric?s use of  ?stitching?  to be in the RFC 5150 sense.  I 
think I will let him clarify, but if used in the RFC 5150 sense, a 
?stitched? LSP would have end-to-end OAM, and different pieces could use 
different identifiers in the control and management planes.

Thanks,
 
John
 
Sent from my iPhone

John, 

The proposal from Eric is that the identifiers are "switched" at the 
stitching point, this requires a complex interworking function and 
interrupts the end to end OAM flow - i.e. data packet can transit without 
any manipulation (other than the normal label swap) but OAM packets must 
be intercepted and manipulated in the middle of the connection so it is no 
longer an end to end construct.  User data and OAM no longer fully fate 
share. 

Regards, 

Malcolm 

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

Malcolm, 
  
That?s incorrect.  There is a single end-to-end LSP composed of different 
pieces, each under the control of a different administrative entity. 
  
Thanks, 
  
John   
  
Sent from my iPhone 
  
[email-masked]

Eric, 

Regards, 

Malcolm 

To

Subject

 

All -

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 28 Apr 2011 12:14:11 +0300

Malcolm,
Lots of thanks for a prompt response.

I did not ever say this is impossible - just that nobody took care to define the order so far.

An even simpler way would be to say that Global identifiers are always "greater" than ICC-based ones (or vice versa:) - depending on where you come from).
The point is, have we fully covered all the cases that should be considered if we allow for mixed identifiers? And would it be really worth the time an effort spent...

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 28, 2011 1:54 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Sasha,

One way of resolving this is to treat the n bytes of the identifier as a binary number.  This would ensure consistent behaviour.

Regards,

Malcolm

Alexander Vainshtein <[email-masked]>

27/04/2011 02:06 AM

To

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "[email-masked]" <[email-masked]>

cc

"[email-masked]" <[email-masked]>, George Swallow <[email-masked]>

Subject

Malcolm, Nurit and all,

Regards,
     Sasha

Hi,

George,

Regards,

Malcolm

25/04/2011 05:16 PM

To

<[email-masked]>

cc

Subject

All -

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 28 Apr 2011 12:25:18 +0300

Loa,

I am not sure your example fully applies, because tLDP (which, I fully agree, is part of the MPLS-TP CP) always runs over IP and hence can always use comparison of IP addresses.

A more interesting example could be the PW redundancy protocol which today compares IP addresses of PE boxes as a tie breaker. 
In MPLS-TP (with PW status carried in static status messages) this would not be always applicable, and one possibility would be to use MPLS-TP identifiers...

Regards,
     Sasha

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 10:35 AM
> To: Alexander Vainshtein
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
> [email-masked]
> > set, i.e., it is possible to say when one of these identifiers is
> "less"
> > than the other one.
> >
> the
> identify
> MEG
> AS
> modes
> on

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 28 Apr 2011 12:44:12 +0200

Hi Malcolm,

You wrote:

John, if you do not allow
mix identifier
types how can you have an end to end CV message.  If you are using
stitching to allow a single identifier type then the identifiers in a
CV
message must be translated at the stitching point.  A very bad idea!

Indeed!

This is not a "late
breaking requirement".
The requirements for support of both ICC and IP identifiers schemes
is well documented.  As is the expectation of using MPLS-TP in
multi-operator
transport networks.  Hence the need to support both on a LSP/PW.  This
comment has been made during previous last calls on this draft.

Correct. I fully agree with your assessment.

Best regards, Huub.

Sent from my mobile device.

John E
Drake <[email-masked]>

27/04/2011 07:25 PM

To

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

cc

Eric Gray
<[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>

Subject

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

Malcolm,

I interpreted Eric’s
use
of  ‘stitching’  to be in the RFC 5150 sense.  I think
I will let him clarify, but if used in the RFC 5150 sense, a ‘stitched’
LSP would have end-to-end OAM, and different pieces could use different
identifiers in the control and management planes.

Also, as Greg notes,
this
appears to be a late breaking requirement.

Thanks,

John

Sent from my iPhone

From: [email-masked]
[mailto:[email-masked]]

To: John E Drake

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

John,

The proposal from Eric is that the identifiers are "switched"
at the stitching point, this requires a complex interworking function
and
interrupts the end to end OAM flow - i.e. data packet can transit
without
any manipulation (other than the normal label swap) but OAM packets
must
be intercepted and manipulated in the middle of the connection so it is
no longer an end to end construct.  User data and OAM no longer fully
fate share.

Regards,

Malcolm

John E Drake
<[email-masked]>

27/04/2011 06:53 PM

To

"[email-masked]"
<[email-masked]>,
Eric Gray <[email-masked]>

cc

"[email-masked]"
<[email-masked]>,

Subject

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

Malcolm,

That’s incorrect.  There is a single end-to-end LSP composed of
different
pieces, each under the control of a different administrative entity.

Thanks,

John

Sent from my iPhone

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

To: Eric Gray

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

Eric,

If you "stitch" the LSP or PW and change identifiers you will
not have end to end OAM which is a requirement for a MPLS-TP transport
network.

Regards,

Malcolm

Eric Gray
<[email-masked]>

27/04/2011 12:11 PM

To

George
Swallow <[email-masked]>,
"[email-masked]" <[email-masked]>

cc

Subject

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

As one of the co-authors on this draft, I support a restriction to
using
a common

where
there

might be an identifier form change and "stitch" them together
if that is what the

operators want/agree to do.  This limits the need-to-know for the
mapping of one

form of identifier to the other to the point at which this occurs,
rather
than at each

From: [email-masked] [mailto:[email-masked]] On
Behalf
Of George Swallow

To: [email-masked]

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.

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: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 28 Apr 2011 13:01:23 +0200

Hi,

I cannot find such a requirement in the MPLS-TP requirement documents.  

It may be a very valid requirement, but it requires more study to
understand the applicability, implications on the different components
and protocols, and it can be added in a later phase.

As indicated before, I support the completion of the document supporting
both IP and ICC addresses but not a mixture. This should be added when
we have complete understanding of the applicability, implications, etc. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Huub van Helvoort
Sent: Thursday, April 28, 2011 1:44 PM
To: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi Malcolm,

You wrote:

John, if you do not allow mix identifier types how can you have an end
to end CV message.  If you are using stitching to allow a single
identifier type then the identifiers in a CV message must be translated
at the stitching point.  A very bad idea! 

Indeed!

This is not a "late breaking requirement".  The requirements for support
of both ICC and IP identifiers schemes is well documented.  As is the
expectation of using MPLS-TP in multi-operator transport networks.
Hence the need to support both on a LSP/PW.  This comment has been made
during previous last calls on this draft. 

Best regards, Huub.

John E Drake <[email-masked]> <mailto:[email-masked]>  

27/04/2011 07:25 PM 

To

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

cc

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

Subject

		

Malcolm, 
  
I interpreted Eric's use of  'stitching'  to be in the RFC 5150 sense.
I think I will let him clarify, but if used in the RFC 5150 sense, a
'stitched' LSP would have end-to-end OAM, and different pieces could use
different identifiers in the control and management planes. 

Thanks, 
  
John 
  
Sent from my iPhone 

John, 

The proposal from Eric is that the identifiers are "switched" at the
stitching point, this requires a complex interworking function and
interrupts the end to end OAM flow - i.e. data packet can transit
without any manipulation (other than the normal label swap) but OAM
packets must be intercepted and manipulated in the middle of the
connection so it is no longer an end to end construct.  User data and
OAM no longer fully fate share. 

Regards, 

Malcolm 

John E Drake <[email-masked]> <mailto:[email-masked]>  

27/04/2011 06:53 PM 

To

"[email-masked]" <mailto:[email-masked]>
<[email-masked]> <mailto:[email-masked]> , Eric Gray
<[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

  

Malcolm, 
 
That's incorrect.  There is a single end-to-end LSP composed of
different pieces, each under the control of a different administrative
entity.   
 
Thanks, 
 
John   
 
Sent from my iPhone 

Eric, 

If you "stitch" the LSP or PW and change identifiers you will not have
end to end OAM which is a requirement for a MPLS-TP transport network. 

Regards, 

Malcolm 

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

27/04/2011 12:11 PM 

To

George Swallow <[email-masked]> <mailto:[email-masked]> ,
"[email-masked]" <mailto:[email-masked]>  <[email-masked]>
<mailto:[email-masked]>  

cc

Subject

  

As one of the co-authors on this draft, I support a restriction to using
a common 
form of identifier throughout an LSP or PW. 

rather than at each 

All -

---

From: John E Drake <[email-masked]>
Date: Thu, 28 Apr 2011 09:22:13 -0700

Comments inline.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 27, 2011 8:25 PM
To: John E Drake
Cc: Eric Gray; [email-masked]; [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

John,

John, if you do not allow mix identifier types how can you have an end to end CV message.
JD:  The endpoints have to agree on a common format for the data plane.  That's the whole point of the discussion.
 If you are using stitching to allow a single identifier type then the identifiers in a CV message must be translated at the stitching point.  A very bad idea!
JD:  I never proposed this.  You have a tendency to attribute a silly idea to someone and then ridicule it.  Btw, you might consider reviewing RFC 5150.

This is not a "late breaking requirement".  The requirements for support of both ICC and IP identifiers schemes is well documented.  As is the expectation of using MPLS-TP in multi-operator transport networks.  Hence the need to support both on a LSP/PW.  This comment has been made during previous last calls on this draft.
JD:  If it is not in the MPLS-TP requirements RFCs, it is by definition a late breaking requirement.

Regards,

Malcolm

27/04/2011 07:25 PM

To

cc

Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

Malcolm,

Thanks,

John

Sent from my iPhone

John,

Regards,

Malcolm

27/04/2011 06:53 PM

To

cc

Subject

Malcolm,

Thanks,

John

Sent from my iPhone

Eric,

Regards,

Malcolm

27/04/2011 12:11 PM

To

cc

Subject

All -

---

From: Eric Gray <[email-masked]>
Date: Thu, 28 Apr 2011 16:57:51 -0400

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.

    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.

    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.

    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?

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 ne…
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.

Regards,

Malcolm

25/04/2011 05:16 PM

To
<[email-masked]>
cc
Subject

All -

---

From: Eric Gray <[email-masked]>
Date: Thu, 28 Apr 2011 17:17:26 -0400

Huub,

    Please see below...

--
Eric

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Thursday, April 28, 2011 6:44 AM
To: [email-masked]
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi Malcolm,

You wrote:
John, if you do not allow mix identifier types how can you have an end to end CV message.  If you are using stitching to allow a single identifier type then the identifiers in a CV message must be translated at the stitching point.  A very bad idea!
Indeed!

Actually I think a fair number of us disagree.

It seems obvious (to me at least) that some sort of OAM interworking
function is going to be necessary, given that there is almost certainly
a non-null intersection of operators that use ICC format identifiers, who
also plan to use OAM as specified in G8113.1 and who are now arguing
they want end-to-end OAM with operators who will use Global identifiers
and may very well use OAM as specified in IETF RFCs.

Given that such an interworking requirement is likely, it is a far better
use of time and energy to start thinking about how such an interworking
function would work and would most likely support translation of ICC and
Global Identifiers.

It is certainly a better use of time and energy than it is to try to support
a presumed mixing of the two formats in a single administrative domain.

Unfortunately this is an incorrect (or naive) assessment.

Many houses have both a furnace and one or more sets of furniture.

It is certainly arguable that the need for both is a rigid requirement in
some of the less temperate zones.

Should this be formalized as a crystal clear housing requirement, I'm
pretty sure that no one would subsequently interpret it to mean that
both the furniture and the furnace need to be able to occupy the same
space in the same house.

Since the apparent "requirement" that the same messages should be
able to include either or both of the required identifiers, and this is not
obvious from the assertion of a requirement to merely allow support for
both, this is indeed a late-breaking requirement.

Best regards, Huub.

Sent from my mobile device.
John E Drake <[email-masked]><mailto:[email-masked]>

27/04/2011 07:25 PM

To
        "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
cc
        Eric Gray <[email-masked]><mailto:[email-masked]>, "[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,

Thanks,

John

Sent from my iPhone

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 27, 2011 4:11 PM
To: John E Drake
Cc: Eric Gray; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

John,

Regards,

Malcolm

John E Drake <[email-masked]><mailto:[email-masked]>

27/04/2011 06:53 PM

To
        "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Eric Gray <[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,

Thanks,

John

Sent from my iPhone

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, April 27, 2011 3:44 PM
To: Eric Gray
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Eric,

Regards,

Malcolm

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

27/04/2011 12:11 PM

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

Subject

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

All -