Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-identifiers-06.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 12 Jul 2011 22:23:09 +0100

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-tp-identifiers-06.txt
Reviewer: Ben Niven-Jenkins
Review Date: 12 July 2011
IETF LC End Date: 11 July 2011
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
In general the document is well written, however it defines the format for a number of different identifiers some of which are related to others in various ways and it is difficult from reading the document to easily get an idea of the "big picture" of how the relationship between the different identifiers which are defined.

For example section 5.1 defines the format for a Tunnel_ID and then goes on to state "When an MPLS-TP Tunnel is configured, it MUST be assigned a unique IF_ID at each endpoint.  As usual, the IF_ID is composed of the local Node_ID concatenated with a 32-bit IF_Num." However, the definition of Tunnel_ID does not contain an IF_ID so it is not obvious to me from reading the draft what the relationship is between the Tunnel_ID for a tunnel and the IF_ID for the same tunnel and the circumstances when Tunnel_ID is the appropriate identifier versus when IF_ID is the appropriate identifer.

Section 7.3 contains a simple diagram and uses it to show how the identifiers are formed for a Pseudowire Segment Endpoint ID and it may be useful to have a similar but expanded diagram at the beginning of the document to show the different types of identifier that are defined, their scope within a network and how they relate to one another.

Please also note that I reviewed this document without reading all the MPLS-TP related OAM documents and so some of my questions may have been answered if I had done so (e.g. minor issue 5 below).

Minor Issues:
Some of the following "Minor Issues" are more questions for my understanding and suggestions rather than "pure" issues as such but they are more substantial than nits so I included them here.

1) Section 4 states that "The Node_ID is a unique 32-bit value" and that "The IF_Num is a 32-bit unsigned integer"

Additionally both Tunnel_Num and LSP_Num are declared to be unsigned integers but no other fields (except IF_Num mentioned above) are. 

Is that meant to signify that Node_IDs (for example) are signed values or is it because they are fields with a structured value (e.g. an IPv4 address?) or some other reason such as it is expected to impact how they are represented on the wire?

2) The document makes several references to using an "A1/Z9 convention", while it can be inferred that A1 and Z9 refer to either end of a connection, is there a definitive reference for this convention as it is not one I am familiar with and a search using a well known search engine just returned results that linked this draft?

3) Section 5.2.1 states:
   Thus the format of an MPLS-TP co-routed bidirectional LSP_ID 
   is:

      A1-{Node_ID::Tunnel_Num}::Z9-
      {Node_ID::Tunnel_Num}::LSP_Num

   Note that the uniqueness of identifiers does not depend on 
   the A1/Z9 sort ordering.  Thus the identifier

      Z9-{Node_ID::Tunnel_Num}::A1-
      {Node_ID::Tunnel_Num}::LSP_Num

   is synonymous with the one above.

I can see how the A1/Z9 sort ordering can generate different values for LSP_ID and that as they are both referring to the same LSP they are synonymous with one another. Is there any requirement for an application to be able to translate from one possible LSP_ID to another synonymous LSP_ID for the same LSP? Should there be an explicit mention that applications MUST treat both forms as identical?

4) Section 5.3 states
      *  Extended Tunnel_ID = A1-Node_ID
      *  Tunnel Sender Address = A1-Node_ID

RFC3209 states:
      Extended Tunnel ID

         A 32-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv4 address here as a
         globally unique identifier.

Which I interpret to mean that the Extended Tunnel_ID and the Tunnel Sender Address may not be identical (as RFC3209 does not mandate that Extended Tunnel ID be the same as the Tunnel Sender Address), in which case which should be used for the Node_ID?

[I note that section 5.3 is not normative text but I think it is a useful example to aid interoperability and therefore being clear on the mappings is worthwhile]

5) Section 7.1.1 - The format of MPLS-TP Section MEG ID chosen means that there can only ever be a single MEG per pair of Interfaces on a section. Is that an architectural constraint that is acceptable or are there possible use cases where multiple MEGs may need to exist between a pair of interfaces on a section? E.g. could there be a use case which requires a MEG to do CV/CC and a separate MEG to do performance management (or would that be implemented as two MEPs in the same MEG?)

6) In a number of places the document describes two types of identifier format, one for local scope within an ASN and one for global scope (by prefixing the local identifier with the Global_ID for the ASN it is within).

What is the reason for the two types having different lengths, rather than using Global_ID of 0 to signify an identifier with local scope - is it to save the 4 octets of Global_ID or is there another reason for having a different length ID for local Vs global scopes?

Nits:

1) The Abstract & Introduction both state:

   This document
   defines identifiers for MPLS-TP management and OAM functions suitable
   to IP/MPLS conventions.

I'm not really sure what being "suitable to" means, maybe you really meant "compatible with"?

2) Section 3 also states:
   ASN 0 is reserved and cannot be assigned.  A Global_ID of zero means
   that no Global_ID is specified.

However ASN 0 is assigned to mean that no Global_ID is used, therefore, consider rewording to something like:

   ASN 0 is reserved and cannot be assigned to an operator.  An identifier 
   containing a Global_ID of zero means that no Global_ID is specified.

3) Section 5 in the middle of the first paragraph. To keep consistent with the style of the earlier paragraphs (which I like):

s/The Tunnel_ID/The Tunnel Identifier (Tunnel_ID)/

4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a Tunnel Number (Tunnel_Num)/

5) Section 5.1 in the 2nd example s/Global_Id/Global_ID/

6) Section 5.2.1 s/Specifically an LSP_Num/Specifically an LSP Number (LSP_Num)/ 

7) Section 6 s/SAAI/SAII/ (occurs twice in that section)

8) Section 7.2.2 states
   Thus a MEP_ID
   used in end-to-end for a Pseudowire T-PE takes the form

      AGI::Global_ID::Node_ID::AC_ID

I don't know what is meant by "used in end-to-end"

Ben

---

From: George Swallow <[email-masked]>
Date: Wed, 20 Jul 2011 15:06:47 -0400

Ben -

See inline:

On 7/12/11 5:23 PM, "Ben Niven-Jenkins" <[email-masked]> wrote:

<snip>

> In general the document is well written, however it defines the format for a
> number of different identifiers some of which are related to others in various
> ways and it is difficult from reading the document to easily get an idea of
> the "big picture" of how the relationship between the different identifiers
> which are defined.

I would like to avoid becoming another framework document, so I am a bit
reticent to do that.  I also don't want to overly constrain implementations.
See below.

> For example section 5.1 defines the format for a Tunnel_ID and then goes on to
> state "When an MPLS-TP Tunnel is configured, it MUST be assigned a unique
> IF_ID at each endpoint.  As usual, the IF_ID is composed of the local Node_ID
> concatenated with a 32-bit IF_Num." However, the definition of Tunnel_ID does
> not contain an IF_ID so it is not obvious to me from reading the draft what
> the relationship is between the Tunnel_ID for a tunnel and the IF_ID for the
> same tunnel and the circumstances when Tunnel_ID is the appropriate identifier
> versus when IF_ID is the appropriate identifer.

I will remove this text.  It is one example where I have an implementation
in mind, but now that you've caused me to think about it, there are other
possibilities here.

> Section 7.3 contains a simple diagram and uses it to show how the identifiers
> are formed for a Pseudowire Segment Endpoint ID and it may be useful to have a
> similar but expanded diagram at the beginning of the document to show the
> different types of identifier that are defined, their scope within a network
> and how they relate to one another.
> 
> Please also note that I reviewed this document without reading all the MPLS-TP
> related OAM documents and so some of my questions may have been answered if I
> had done so (e.g. minor issue 5 below).
> 
> Minor Issues:
> Some of the following "Minor Issues" are more questions for my understanding
> and suggestions rather than "pure" issues as such but they are more
> substantial than nits so I included them here.
> 
> Additionally both Tunnel_Num and LSP_Num are declared to be unsigned integers
> but no other fields (except IF_Num mentioned above) are.
> 
> Is that meant to signify that Node_IDs (for example) are signed values or is
> it because they are fields with a structured value (e.g. an IPv4 address?) or
> some other reason such as it is expected to impact how they are represented on
> the wire?

Would it satisfy you if I just say that they are all unsigned integers?
 
> 2) The document makes several references to using an "A1/Z9 convention", while
> it can be inferred that A1 and Z9 refer to either end of a connection, is
> there a definitive reference for this convention as it is not one I am
> familiar with and a search using a well known search engine just returned
> results that linked this draft?

Apparently there is an A/Z convention used by the ITU.  I used A1 Z9 because
then most (now all, since the ICC got moved out) of the fields are numbers
(make that unsigned integers ;-).

> I can see how the A1/Z9 sort ordering can generate different values for LSP_ID
> and that as they are both referring to the same LSP they are synonymous with
> one another. Is there any requirement for an application to be able to
> translate from one possible LSP_ID to another synonymous LSP_ID for the same
> LSP? Should there be an explicit mention that applications MUST treat both
> forms as identical?

In general I do not see a need to translate, but in a few case there will
be.  But not all implementations of MPLS-TP may have those cases.

For example, the on demand cv draft uses a source/destination format for the
LSP-ID.  This is done from the sender-of-the-ping's point of view.  It was
done this way to ensure that when you get to a node you are tracing in the
correct direction.  But MPLS-TP in a *pure* transport environment will most
likely not use on demand cv.

I can also see it being useful to be able to list out the tunnels and lsps
sourced a particular node in order of their destinations with those
appearing first in the order.  But again something that is not necessary.

> Which I interpret to mean that the Extended Tunnel_ID and the Tunnel Sender
> Address may not be identical (as RFC3209 does not mandate that Extended Tunnel
> ID be the same as the Tunnel Sender Address), in which case which should be
> used for the Node_ID?
> 
> [I note that section 5.3 is not normative text but I think it is a useful
> example to aid interoperability and therefore being clear on the mappings is
> worthwhile]

I'll add some text:

      "RFC 3209 allows some flexibility in how the Extended Tunnel ID
      is chosen and a direct mapping is not mandated.  One
      convention that is often used, however, is to populate this
      field with the same value as the Tunnel Sender Address.  The
      examples below follow that convention.  Note that these are
      only examples."

> 5) Section 7.1.1 - The format of MPLS-TP Section MEG ID chosen means that
> there can only ever be a single MEG per pair of Interfaces on a section. Is
> that an architectural constraint that is acceptable or are there possible use
> cases where multiple MEGs may need to exist between a pair of interfaces on a
> section? E.g. could there be a use case which requires a MEG to do CV/CC and a
> separate MEG to do performance management (or would that be implemented as two
> MEPs in the same MEG?)

>From a management point of view you are just looking at two parameters of
the same MEG, no?  The messages are separated via ACH, so I don't see the
issue.

> 6) In a number of places the document describes two types of identifier
> format, one for local scope within an ASN and one for global scope (by
> prefixing the local identifier with the Global_ID for the ASN it is within).
> 
> What is the reason for the two types having different lengths, rather than
> using Global_ID of 0 to signify an identifier with local scope - is it to save
> the 4 octets of Global_ID or is there another reason for having a different
> length ID for local Vs global scopes?

I think the only place where this has any significance is in CV where if you
keep the check value in very high speed RAM you want to keep the state per
session small as possible.  I debated this several times with myself, my
co-authors and others.  This is where the consensus came out.
 
> I'm not really sure what being "suitable to" means, maybe you really meant

Ok.

>    containing a Global_ID of zero means that no Global_ID is specified.

Good.

> 
> 3) Section 5 in the middle of the first paragraph. To keep consistent with the
> style of the earlier paragraphs (which I like):
> 

Ok.

> 4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a Tunnel

Ok.

> 5) Section 5.1 in the 2nd example s/Global_Id/Global_ID/

Ok.

> 6) Section 5.2.1 s/Specifically an LSP_Num/Specifically an LSP Number

Ok.

> 7) Section 6 s/SAAI/SAII/ (occurs twice in that section)

Hum, must be my slight dyslexia.

> I don't know what is meant by "used in end-to-end"

This is cruft left from when we were calling S-Pes MEPs.  Will delete.

...George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 22 Jul 2011 19:13:59 +0100

George,

Please see inline.

> reticent to do that.  I also don't want to overly constrain implementations.

OK I have no problem with not having such extra material, readers will just have to work their brain a bit harder.

> Would it satisfy you if I just say that they are all unsigned integers?

I think if you are going to declare the type of some you should declare the type of them all. Alternatively if there is no real significance to them being unsigned integers I'm happy with the document just referring to them as "32-bit values".

> (make that unsigned integers ;-).

OK, it does sound like the sort of thing ITU would have a convention for but I wasn't familiar with it. Rereading the document I can see that section 1.3 does in fact introduce the A/Z concept which is probably sufficient if there isn't an easy document to reference because it is more of a convention that a definition as such.

> appearing first in the order.  But again something that is not necessary.

OK.

>      examples below follow that convention.  Note that these are

Great, thanks.

> the same MEG, no?  The messages are separated via ACH, so I don't see the

Fine, I wasn't sure myself whether it was actually an issue but I thought I'd raise it because it could be an unintentional limitation. If you're happy it isn't, I'm fine with that.

> co-authors and others.  This is where the consensus came out.

OK, I'm fine with that too.

Thanks
Ben