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

[Ben Niven-Jenkins <[e-mail]>]

George,

Please see inline.

On 20 Jul 2011, at 20:06, George Swallow wrote:
> On 7/12/11 5:23 PM, "Ben Niven-Jenkins" <[e-mail]> wrote:
> 
> <snip>
> 
>> 
>> 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.
> 
> 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.

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

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

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

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.

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

OK.

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

Great, thanks.

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

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.

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

OK, I'm fine with that too.

Thanks
Ben

>> 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"?
> 
> Ok.
> 
>> 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.
> 
> Good.
> 
>> 
>> 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)/
> 
> Ok.
> 
>> 4) Similarly, Section 5.1 s/Specifically a Tunnel_Num/Specifically a Tunnel
>> Number (Tunnel_Num)/
> 
> 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
>> (LSP_Num)/ 
> 
> Ok.
> 
>> 7) Section 6 s/SAAI/SAII/ (occurs twice in that section)
> 
> Hum, must be my slight dyslexia.
> 
>> 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"
> 
> This is cruft left from when we were calling S-Pes MEPs.  Will delete.
> 
> ...George
> 
>> Ben
>> 
>