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

From: [email-masked]
Date: Mon, 2 May 2011 00:07:46 -0400

Eric,

Please see in line below, comments marked with [MB].

Regards,

Malcolm

Eric Gray <[email-masked]> 
29/04/2011 11:47 AM

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

I agree with John's interpretation.
 
With a "stiched" LSP, forwarding is done exactly as if the LSP is 
contiguous.

[MB] OK that meets the requirement that OAM and data fate share.
 
If OAM packets are forwarded exactly as data, the difference in 
the case where an OAM translation needs to occur is minimal. 
The only difference is the (potential) need for boundary devices 
to perform translation/adaptation of OAM identifiers.

[MB] Two points: 1) How can it be the same if we have a difference in the 
treatment of OAM and data packets.   2) How are OAM packets identified, is 
the boundary node required to examine the bottom of stack label to for the 
value 13?  This appears to be a deviation from "normal" MPLS forwarding 
behaviour. 
 
With a proper implementation, a translation can be performed 
with no more impact on OAM messages than would be seen by
any data packet that needs to have a CRC modification, or an
adaptation from one underlying network layer to another.

[MB]  In the case of CRC modification the same process is performed on 
every packet, no difference between OAM and data packets.
 
Since these things also happen, it is difficult to buy the argument 
that a similar function should not be allowed.
 
If, on the other hand, we were to require equipment that is now
purpose built for IP forwarding to be able to map OAM message
identifiers to "strange" identifiers (currently used mostly for the
"transport layer" in the sense of TDM/optical switching), we may
expect all sorts of false indications to occur.

[MB] Two points:  MPLS-TP forwarding must not rely on the presence of an 
IP forwarding function. 2) I do not understand (or accept) your assertion 
that nodes "purpose built for IP forwarding  to be able to map OAM message 
identifiers to "strange" identifiers".  All that "sink" needs to do is to 
compare the received binary string to the expected binary string to 
determine if the OAM packet is being received from the expected source.  I 
agree that in the OSS it may be desirable for the OSS to be able to 
interpret both identifier formats - but the nodes responsible for 
forwarding do not need to understand or interpret the identifier.
  
Besides, my point was that there will clearly be an interworking
function requirement in any case.

[MB]  As discussed at the SG15 meeting and documented in TD458/PLEN an 
interworking function will not be required.  Interworking functions create 
complexity and should not be used.
 
And piece-wise OAM is often required when interworking is used,
and ther is a distinct advantage in terms of divide-and-conquer 
diagnostics in this case.

[MB] Interworking results in piece-wise OAM and prevents end to end 
integrity checks.
 
The potential impact on OAM PDU fowarding due to translation of
identifiers will be nothing in comparison with remapping OAM from
RFC-based OAM to ITU-T G8113.1-based OAM.

[MB] Please remember the discussion at the last SG15 meeting as documented 
in TD458/PLEN.  If end to end OAM between regions that run RFC based OAM 
and G.8113.1 based OAM will use the RFC version.  i.e. An interworking 
function is not required.
 
Surely you are not now going to argue that there should be end-to-
end support for both forms of OAM?  But these arguments are very
similar.

[MB] No - please see my previous comment
 
OAM across service provider boundaries is a very strange thing 
anyway.  Most service providers are extremely reluctant to give 
their competitors the ability to find out what is wrong within their 
network.

[MB]  It is common/mandatory in all existing transport networks to be able 
to check the end to end integrity of a connection.
 
This is even more likely to be the case with service providers who
have fundamentally different operating paradigms.
 
Other than reports from a small number of people (who've already
indicated that they will support a different form of OAM for their
customers), we've not seen any evidence that there is a real need
to support end-to-end, multi-provider OAM - particularly for the 
case where peered service providers use different forms of OAM
and identifiers.
 
The appropriate time to deal with this possible scenario is when
it actually comes up.  No doubt it will, given that there is going
to be two different types of OAM.
 
But perhaps the vendors and service providers that argued that
the applications are sufficently different for the two different OAM
types that they will not need to mix, will turn out to be correct...

[MB]  So in your view MPLS-TP will never support multi-operator 
deployments in the same way the SDH, OTN and PBB-TE do?
 
--
Eric
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2011 7:25 PM
To: [email-masked]
Cc: Eric Gray; [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]] 
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
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]
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 

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. 

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 -

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

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 May 2011 13:41:23 -0400

Forwarding in plain text...

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 06, 2011 11:40 AM
To: Eric Gray
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Importance: High

Hi Eric,

Pleased to say that I am enjoying my vacation ;)

On your comments:

1)  I agree, we need more open technical discussion.

2) & 3) I agree with some of your comments.  I think that the major point where I disagree is that I see a significant difference between the need to "understand" both identifier formats and the need to administer both identifier formats.

If we allow mixed types then for both operators will need to "understand" the "other" format to be able to enter the expected identifier for CV.  This can be achieved by several means; For example, a simple GUI application can aid the input of the expected "foreign" identifier type.  Note that when an identifier is inserted into a CV message the "native" format is always used therefore neither operator has to administer the "foreign" identifier type.

If we only allow a single identifier type then one operator must administer the "foreign" identifier type since this must be inserted into the CV message that is sent.

On this basis I suggest that allowing mixed identifiers causes less change and complexity in the operational processes of the network operators.

Regards,

Malcolm

04/05/2011 12:44 PM

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

Hi Malcolm,

    Hopefully you're enjoying your vacation.

    To address your specific comments below:

1) I guess the discussion you refer to (on precisely how to avoid
    the necessity for OAM interworking) was less public than it
    maybe should have been.  That's okay, now that it has been
    brought up in a broader context.

2) it isn't possible for the operators you refer to avoid administering
    IP-based identifiers, since inter-operator OAM is not a one-way
    process.  They will need to administer the IP-based identifiers
    the other carrier uses, if they expect to be able to recognize
    those identifiers in OAM messages they receive, or include them
    in OAM messages they send.  Entering these identifiers as a
    "binary string" via a craft interface will be horrendous, hence each
    vendor will need to help them by providing the user-interfaces to
    support this.  Once they've done this - as they MUST - the need
    to administer different identifiers for different peering relationships
    will quickly become more cumbersome than complex - assuming
    it is not a complete non-starter from the first.

    This equates in my opinion not only to an argument to prohibit
    identifier type mixing, but also to only allow one identifier type.
    The initial requirement - however - was to support two types.  If
    this requirement still applies, then we should at least preclude
    needless complexity associated with arbitrary mixing of identifier
    types.

    I believe this addresses at least some aspect of several of your
    comments (related to complexity of identifier types, administration
    etc.).

3) I do not follow your logic on mixing identifiers.  The way I would
    interpret the requirement - based on your own argument - is that
    there is a requirement for operators to agree on the identifiers they
    will use (which would not result in mixing them).  The reason for
    this conclusion/interpretation is that either we're formally requiring
    IP-based operators to recognize and support either identifer type,
    we're asking ICC-based operators to recognize and support either
    identifier, or (as seems likely based on discussion) we're requiring
    both to recognize either.  If we're asking both to recognize either,
    then it is quite likely that either operator could use either identifier
    type and that further means there should be no issue with both of
    the operators using the same identifier type.

    It is not conceivable that any inter-carrier OAM would occur without
    prior agreement on several issues relating to how this OAM would
    work.

    This being the case, it is needlessly complex to require support
    for mixing identifiers.

    Based on this reasoning, I don't see how a requirement to support
    mixing of identifiers is anything other than a new requirement.

--
Eric

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 04, 2011 1:35 AM
To: Eric Gray
Cc: John E Drake; [email-masked]; [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Importance: High

Eric,

Thank you for your reply, I am currently on vacation with limited access to email.  A few quick comments in line below:

Malcolm

02/05/2011 10:06 AM

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

Malcolm,

   Thanks for your reply.  While it raises some additional questions in
my mind, it does make some good points.  We will probably get back
to you in a few days with a more thorough response, but I want to get
back to you on (what I consider) your most significant point, as well as
a few of your other points.

   Perhaps the most significant point you make is that (apparently)
SG-15 has recorded discussion that goes into more detail about why
an interworking function will not be required.  Although I definitely recall
the assertion that OAM interworking would not be required, I don't recall
a specific statement to the effect that - if end-to-end OAM will be used
between a domain that uses G.8113.1 OAM and one or more other
domains using RFC-based OAM - that RFC-based OAM will be used
exclusively for this purpose.

   But I am prepared to accept your assertion that this is the case.

[MB] This was discussed in detail by the group who support the standardization of both G.8113 (Y.1731 OAM) and "BFD" based OAM for MPLS-TP

   The creation of G.8113.1 OAM is something that was not expected
during the requirements development phase, and it may very well be the
case that - since G.8113.1 has been created at this point - some of the
requirements we've attempted to address have actually been overcome
by events.

   For example, if - as you've asserted - the intention is that operators
that use G.8113.1 OAM will use RFC-based OAM for end-to-end OAM,
then possibly the best way to eliminate the complexity associated with
having two different identifier types is to remove all references to ICC
based identifiers in the current identifiers draft.

[MB]  I do not follow your logic here.  The main point is that if an operator that normally runs G.8113.1 with ICC based identifiers has to run "BFD" based OAM for end to end inter operator connections then we do not want to impose the additional burden of also having to administer IP based identifiers.

   This is one of the possibilties we should consider.  If - again, as you
assert - users of G.8113.1 OAM will use RFC-based OAM where there
would otherwise be an interworking requirement, then RFC-based OAM
should exclusively define Global identifiers as the simplest approach.

   Another issue in some of your comments is that you seem to be
looking at the complexity associated with comparing identifiers, and
ignorng complexity associated with producing them.  This is the factor
I am more concerned about, since it means that the OAM sender has
to know more about who will be receiving the OAM message than would
otherwise be the case.

[MB] That is exactly my point.  The sender of the message defines the format of the identifier and must understand how to administer the addresses.  The receiver only has to know the value of the binary string being received.

   I also want to address your last comment, as well as some of the
implications of several of your other comments.  Even if we retain the
ICC identifiers, and do not define how to support both identifiers in the
same OAM exchange in this version, this does not mean we will - as
you say - "never support multi-operator deployments."

   There is always the potential for a new version to be written to address
new requirements.

[MB] This is not a "new requirement".  When the requirements draft was being developed it was agreed to keep the requirements at a high level to allow more rapid approval.  This is one of the many more detailed requirements that was never documented.  However, I must again point out that we have a requirement to allow an operator to select the use of either an IP or ICC based identifier.  We must also support multi operator deployments.  This clearly implies that mixed identifier types must be supported.

   Finally, it would not be the case - even if we did add the functionality
we are discussing - that we would support multiple-operator deployments
"in the same way the SDH, OTN and PBB-TE do" - since these do not
include both ICC and Global identifiers either.

--
Eric

PS - bottom-of-stack peeking is not unusual at boundary devices; some
operators do it already in order to make sure their services are not being
used in any way that is inconsistent with the SLA that is in-place.  I am
also curious as to how OAM works in scenarios where court-ordered
wire tapping or data mirroring is going on.  But these are different topics
about which I am just curious.  I am even more curious as to what the
process is for getting an ICC.  Can I get one myself?  Can jusy anyone
get one?

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 02, 2011 12:08 AM
To: Eric Gray
Cc: John E Drake; [email-masked]; [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Importance: High

Eric,

Regards,

Malcolm

29/04/2011 11:47 AM

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

[MB] Two points: 1) How can it be the same if we have a difference in the treatment of OAM and data packets.   2) How are OAM packets identified, is the boundary node required to examine the bottom of stack label to for the value 13?  This appears to be a deviation from "normal" MPLS forwarding behaviour.

[MB]  In the case of CRC modification the same process is performed on every packet, no difference between OAM and data packets.

[MB] Two points:  MPLS-TP forwarding must not rely on the presence of an IP forwarding function. 2) I do not understand (or accept) your assertion that nodes "purpose built for IP forwarding  to be able to map OAM message identifiers to "strange" identifiers".  All that "sink" needs to do is to compare the received binary string to the expected binary string to determine if the OAM packet is being received from the expected source.  I agree that in the OSS it may be desirable for the OSS to be able to interpret both identifier formats - but the nodes responsible for forwarding do not need to understand or interpret the identifier.

[MB]  As discussed at the SG15 meeting and documented in TD458/PLEN an interworking function will not be required.  Interworking functions create complexity and should not be used.

[MB] Interworking results in piece-wise OAM and prevents end to end integrity checks.

[MB] Please remember the discussion at the last SG15 meeting as documented in TD458/PLEN.  If end to end OAM between regions that run RFC based OAM and G.8113.1 based OAM will use the RFC version.  i.e. An interworking function is not required.

[MB]  It is common/mandatory in all existing transport networks to be able to check the end to end integrity of a connection.

[MB]  So in your view MPLS-TP will never support multi-operator deployments in the same way the SDH, OTN and PBB-TE do?

--
Eric

________________________________

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

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

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.

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 -

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: Eric Gray <[email-masked]>
Date: Mon, 9 May 2011 13:49:51 -0400

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 02, 2011 9:46 AM
To: Eric Gray; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Importance: High

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 -

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: Eric Gray <[email-masked]>
Date: Mon, 9 May 2011 13:53:57 -0400

From: Eric Gray
Sent: Wednesday, May 04, 2011 12:44 PM
To: [email-masked]'
Cc: John E Drake; [email-masked]; [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Hi Malcolm,

--
Eric

Eric,

Malcolm

02/05/2011 10:06 AM

To

Malcolm,

--
Eric

Eric,

Regards,

Malcolm

29/04/2011 11:47 AM

To

--
Eric

Malcolm,

Thanks,

John

Sent from my iPhone

John,

Regards,

Malcolm

27/04/2011 06:53 PM

To

Malcolm,

Thanks,

John

Sent from my iPhone

Eric,

Regards,

Malcolm

27/04/2011 12:11 PM

To

Subject

All -

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 May 2011 13:53:03 -0400

From: Eric Gray
Sent: Friday, May 06, 2011 1:38 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Malcolm,

    I don't think anyone is objecting to use of mixed identifiers in a subsequent
set of specifications.  Where the strongest objections are coming up is in the
question of why this is needed for the current version(s).

    However convenient some may feel it is, to be able to use mixed identifiers
in uncommon cases involving inter-carrier OAM, it's non-trivial to work through
the implications.

    And there is little point in doing a thing if there are serious and legitimate
concerns about the implications.

    One thing that is a problem (and this is just one thing), is that the folks who
use IP-based identifiers also tend to use signaling.  It is for this reason that it
is important that IP-based identifiers can be predictably derived from information
known to signaling entities.

    The paradigm associated with ICC identifier use appears to be significantly
different.  ICC identifiers apparently need to be configured in every case, either
by an operator, or by an OSS.  If there is signaling involved, it is clearly not of
the sort that a peering IP-based carrier would be participating in.

    There are a number of issues that need to be worked through in order to be
able to understand all of the implications of having to configure ICC information
in devices that may be part of a service in one instance and not part of it in the
next (as a result of dynamic changes) - or vice versa.

    There is also the issue that we've previously discussed in gory detail with
just how much - and what kinds - of OAM will be allowed between carriers.

    I am not sure that you (or many others involved in this discussion) would be
familiar with this previous discussion, as it took place on IETF mailing lists as
much as a decade ago.

    It is certainly not clear that there is any reason why a carrier would want to
expose their network devices to potential OAM-based attack by a competing
carrier.  In fact, it does not seem too likely that any carrier would be willing to
allow even legitimate exploration of their network internals by another carrier.

    Chances are good that an IP-based service provider would be willing only to
expose the devices that provide ingress/egress to/from their network to another
carrier.  For this case, since these points are very likely to be relatively static,
it seems much more likely that the IP-based carrier could be persuaded to
configure whatever ICC identifiers the other carrier wants them to use - for just
these devices - than that they would be willing to configure ICC identifiers in a
much larger subset of their network.

    Two things to note about this:

1) If the IP-based carrier is unwilling or unable to do this, then there is no basis
    for assuming they would be able to support the mixed identifier case either.
2) This approach works equally well for the intra-carrier case (where a carrier
    is transitioning their network from devices that natively use one identifier type
    to network devices that natively use the other).

    From what I understand, this is a frequently used operating model already.

    Taking these (and other) factors into account, support for the mixed identifier
case doesn't appear to be immediately necessary, would (at best) be convenient
in what appears to be a very uncommon case, and would only serve to delay the
progress of work on identifiers for the much more common cases.

Hi Eric,

On your comments:

Regards,

Malcolm

04/05/2011 12:44 PM

To

Hi Malcolm,

--
Eric

Eric,

Malcolm

02/05/2011 10:06 AM

To

Malcolm,

--
Eric

Eric,

Regards,

Malcolm

29/04/2011 11:47 AM

To

--
Eric

Malcolm,

Thanks,

John

Sent from my iPhone

John,

Regards,

Malcolm

27/04/2011 06:53 PM

To

Malcolm,

Thanks,

John

Sent from my iPhone

Eric,

Regards,

Malcolm

27/04/2011 12:11 PM

To

Subject

All -

---

From: Eric Gray <[email-masked]>
Date: Mon, 9 May 2011 14:03:32 -0400

From: Eric Gray 
Sent: Monday, May 02, 2011 11:56 AM
To: [email-masked]'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?

Manuel,
 
    There's at least two polar models for new equipment deployment in this case:
 
1) folks who have both IP/MPLS equipment and transport service equipment who
    view their existing deployment as consisting mostly of IP/MPLS and are looking 
    to buy new equipment (or add features to existing equipment) to allow them to 
    phase out aging transport equipment in favor of an all IP/MPLS network.
2) folks who have a network that they view as being dominated by transport and who
    want to buy IP equipment to (gradually?) replace this equipment and increase the
    compatibility of their network with what they see as a growing demand for IP and
    MPLS.
 
It's tempting to add a third deployment model for the folks who have acquired pre-
standard equipment and want all standards to be compatible with this equipment.
However, we've been assured that there will not be an interworking requirement to
support deployment of standards-based equipment and pre-standard deployment
- so this case seems to be irrelevant.
 
    In the first deployment model, we replace the transport equipment and move 
transport applications over to MPLS-TP.  Since transport equipment is being end-
of-lifed in any case, the capital investment we want to protect is the existing IP and
MPLS deployment.
 
    In the second deployment model, we seem to want to protect the existing network
throughout the transformation process, by front-loading additional functionality into the
new equipment to be installed.  While this facilitates the first phase of transformation,
it does so by adding features and capabilities that we can be pretty sure we will not
need after the transformation is complete.
 
    While I refer to these two scenarios as separate, they are in fact the result of 
network operators at different points in a transformation from packet based services
provided by a predominantly transport network to a predominantly packet network
that provides support for a small minority of applications that require transport-like
services.
 
    Clearly the further a network operator is along in the process, the more reluctant
they will be to find additional complexity in new capital investment that is important
only for a diminishingly small part of their network and will be obsolete in fairly short
order.
 
    Please see additional comments below...

Dear All,

Thanks,

Manuel

Malcolm,

EG> Focus on the data plane is an one way to look at this.  Unfortunately
    it does not help us much since we have to figure out how this stuff is
    supposed to get into the data plane, and how a maintenance entity
    is supposed to be configured to recognize it once it arrives from the 
    data-plane.

    Simply looking at this as data-plane "stuff" would quickly get us in
    trouble with our colleagues that have to handle the related needs to
    get it there and recover it once it has arrived.

EG> It would be sufficient, but non-trivial to specify in a standard.  It is 
    also not particularly trivial to implement.

[MP:] What happens today when a node receives any format that it doesn't support? 
      Would it result in a confusion / wrong comparison?

EG> I don't think specifying that an unsupported format will be discarded
    (perhaps with an error report) - which is the way that unsupported 
    objects and formats are dealt with generally (as long as it's possible
    to detect this) - is what we want to do.

George, 

EG> In the inter-AS case generally, the best form of identifier is a Global 
    Identifier, simply because - by definition - you have a different AS for
    the two (or more) portions of the network.

Regards, 

Malcolm 

25/04/2011 05:16 PM 

	To	<[email-masked]> 
	cc
	Subject

All -