Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
draft-ietf-mpls-rsvpte-attributes-05

[Ballot comment]
Comprehensibility comments from Gen-ART reviewer:

Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005
...
Additionally, I had a lot of trouble actually parsing much of the document,
I am not going to site every single instance, but some examples are listed
below.  I think an editorial pass is needed to enhance the comprehensibility
of the text.

Minor comments
1) Way too much acronyms in the abstract ...
2) Took me several reads to be able to parse the following text:

    .... Because of the nature of the TLV
    construction the object is flexible and allows the future definition
    of:
    - further bit flags if further, distinct uses are discovered
    - arbitrary options and attributes parameters carried as individual
      TLVs.

suggest:

    The new RSVP-TE message object is quite flexible, due to the use of the
    TLV format and allows:
    - future specification of bit flags
    - additional options and atttribute paramerters carried in TLV format.

"if further, distinct uses are discovered" and "arbitrary options and attributes"
sounds like an open invitation for folks to invent new things without good reason ...

3) This text was confusing:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object will pass it on unaltered
  because of the C-Num.

suggest:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object is required to pass it on unaltered,
  as the C-Num indicates that the LSR should pass the object on transparently.

[Ballot discuss]
Gen-ART reviewer says "Not Ready". Main issue is IANA considerations
as in Russ's Discuss, but there is also a problem of comprehensibility.
If we leave that to the RFC copy-editor, the meaning may get distorted.
However,I have moved the comprehensibility issues into a Comment.

Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005



In summary, I don't think this document is ready for publication.

Major comment is that I find the IANA section inadequate. It seems to
be introducing a new namespace for IANA to take care of, but no rules
on how new values are allocated.  It seems to indicate that an RFC
number is needed in section 10.3, but I think this needs to be more
specific.  The text in other places of the document are not so
clear at what constitues a reason for allocating new bit flags, etc.,
so in the IANA section, I think there needs to be explicit text on the
the mechanisms for specifying and definting them.

[Ballot discuss]
Gen-ART reviewer says "Not Ready". Main issue is IANA considerations
as in Russ's Discuss, but there is also a problem of comprehensibility.
If we leave that to the RFC copy-editor, the meaning may get distorted.

Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005



In summary, I don't think this document is ready for publication.

Major comment is that I find the IANA section inadequate. It seems to
be introducing a new namespace for IANA to take care of, but no rules
on how new values are allocated.  It seems to indicate that an RFC
number is needed in section 10.3, but I think this needs to be more
specific.  The text in other places of the document are not so
clear at what constitues a reason for allocating new bit flags, etc.,
so in the IANA section, I think there needs to be explicit text on the
the mechanisms for specifying and definting them.

Additionally, I had a lot of trouble actually parsing much of the document,
I am not going to site every single instance, but some examples are listed
below.  I think an editorial pass is needed to enhance the comprehensibility
of the text.

Minor comments
1) Way too much acronyms in the abstract ...
2) Took me several reads to be able to parse the following text:

    .... Because of the nature of the TLV
    construction the object is flexible and allows the future definition
    of:
    - further bit flags if further, distinct uses are discovered
    - arbitrary options and attributes parameters carried as individual
      TLVs.

suggest:

    The new RSVP-TE message object is quite flexible, due to the use of the
    TLV format and allows:
    - future specification of bit flags
    - additional options and atttribute paramerters carried in TLV format.

"if further, distinct uses are discovered" and "arbitrary options and attributes"
sounds like an open invitation for folks to invent new things without good reason ...

3) This text was confusing:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object will pass it on unaltered
  because of the C-Num.

suggest:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object is required to pass it on unaltered,
  as the C-Num indicates that the LSR should pass the object on transparently.

[Ballot discuss]
Individually, the comments listed here wouldn't necessarily add up to a Discuss in my mind, but taken as a whole I think they do. In general, I think the document needs one more pass to clean some of these issues up. If it will help, I can break these down into what I consider more editorial, and those which I believe are more fundamental.


>    This document distinguishes between options and attributes that are
>    only required at key LSRs along the path of the LSP, and those that
>    must be acted on by every LSR along the LSP. Two LSP Attributes
>    objects are defined in this document: the first may be passed
>    transparently by LSRs that do not recognize it, the second must cause
>    LSP setup failure with the generation of a PathErr message with an
>    appropriate Error Code if an LSR does not recognize it.

"must" cause or "will" cause. Must (even without capital letters) implies that this is new functionality, though I think this is a statement about existing functionality.

>
> 1.1 Applicability to Generalized MPLS
>
>    The RSVP-TE signaling protocol also forms the basis of a signaling
>    protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
>    [RFC3473]. The extensions described in this document are intended to
>    be equally applicable to MPLS and GMPLS.

Are they "intended" to be applicable to both, or is this document actually defining them to be applicable to both?

>    Each TLV is encoded as follows.
>
>    0                  1                  2                  3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Type              |          Length              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                              |
>    //                            Value                            //
>    |                                                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Type
>
>          The identifier of the TLV.
>
>      Length
>
>          The length of the value field in bytes. Thus if no value
>          field is present the length field contains the value zero.
>          Each value field must be zero padded at the end to take it
>          up to a four byte boundary - the padding is not included in
>          the length so that a one byte value would be encoded in an
>          eight byte TLV with length field set to one.

The padding here seems unnecessarily complex. I am left to wonder whether a 4 byte Value field should have a Length of 1,2,3 or 4 (or any of the above). Personally, I think any word-alignment gains achieved by forcing the Value to be divisible by 4 here are outweighed by the interoperability overhead necessary to ensure that this is interpreted correctly by all parties.

>
>      Value
>
>          The data for the TLV padded as described above.
>
> 3.1 Attributes Flags TLV
>
>    This document defines only one TLV type value. Type 1 indicates the
>    Attributes Flags TLV. Other TLV types may be defined in future with
>    type values assigned by IANA.

A direct reference to the IANA consideration section that deals with this would be nice here.

>
> Farrel, Papadimitriou, Vasseur and Ayyangar                      Page 5
> ?
> draft-ietf-mpls-rsvpte-attributes-04.txt                      July 2004
>
>    The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object
>    and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5.
>    The bits in the TLV represent the same attributes regardless of which
>    object carries the TLV. Documents that define individual bits MUST
>    specify whether the bit may be set in one object or the other, or
>    both. It is not expected that a bit will be set in both objects on a
>    single Path message at the same time, but this is not ruled out by
>    this document.
>
>    The Attributes Flags TLV value field is a variable length array of
>    flags numbered from the MSB as bit zero. The length field for this
>    TLV is always a multiple of 4 bytes, regardless of the number bits
>    carried.
>
>    Unassigned bits are considered as reserved and MUST be set to zero
>    on transmission by the originator of the object. Bits not contained
>    in the TLV MUST be assumed to be set to zero. If the TLV is absent
>    either because it is not contained in the LSP_ATTRIBUTES or LSP_
>    REQUIRED_ATTRIBUTES object, or because those objects are themselves
>    absent, all processing MUST be performed as though the bits were
>    present and set to zero.

Would it be simpler and sufficient just to say that unassigned bits are set to zero on transmission and ignored upon receipt?

>
>    No bits are defined in this document. The assignment of bits is
>    managed by IANA.

Again, a direct reference to IANA would be nice.

> 5. LSP_REQUIRED_ATTRIBUTES Object
>
>    The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes
>    required in support of an LSP, or to indicate the nature or use of
>    an LSP where that information MUST be inspected at each transit LSR.
>    Specifically, each transit LSR MUST examine the attributes in the
>    LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object
>    transparently.

If, after examination of the attribute at the LSR, it is determined that the object should be forwarded transparently, is that a protocol violation? Probably not, though the text above might spark such a debate.

>    There is a one-to-one correspondence between bits in the Attributes
>    Flags TLV and the RRO Attributes Subobject. If a bit is only required
>    in one of the two places, it is reserved in the other place. See
>    the procedures sections, below, for more information.
>
>    0                  1                  2                  3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Type    |    Length    |          Reserved            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                              |
>    //                      Attribute Flags                      //
>    |                                                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I don't understand the advantage of creating a subobject TLV format with one-byte Type and Length here, particularly given that the Value is the same number-space as the Main TLV. Why not just use the same TLV format and rules that have already been defined? Is there some intended used of the Reserved field or desire to keep the Type field small?

>
>      Type
>
>          0x??  TBD  RRO Attribute Subobject
>
>      Length
>
>          The Length contains the total length of the subobject in bytes,
>          including the Type and Length fields.  This length must be a
>          multiple of 4 and must be at least 8.
>
>      Attribute Flags
>
>          The attribute flags recorded for the specific hop.
>
> 7.3 Procedures
>
> 7.3.1 Subobject Presence Rules
>
>    The Attributes subobject is pushed onto the RECORD_ROUTE object
>    immediately prior to pushing the node's IP address or link
>
> Farrel, Papadimitriou, Vasseur and Ayyangar                      Page 10
> ?
> draft-ietf-mpls-rsvpte-attributes-04.txt                      July 2004
>
>    identifier. Thus, if label recording is being used, the Attributes
>    subobject SHOULD be pushed onto the RECORD_ROUTE object after the
>    Record Label subobject(s).
>
>    A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE
>    object without also pushing an IPv4, IPv6 or Unnumbered Interface ID
>    subobject.
>
>    This means that an Attributes subobject is bound to the LSR
>    identified by the subobject found in the RRO immediately before the
>    Attributes subobject.
>
>    If the new subobject causes the RRO to be too big to fit in a Path
>    (or Resv) message, the processing MUST be as described in [RFC3209].

A quick summary of what this means, or section within 3209 would be a nice gesture for the reader.

>
>    If more than one Attributes subobject is found between a pair of
>    subobjects that identify LSRs, only the first one found (that is, the
>    nearest to the stop of the stack) SHALL have any meaning within the
>    context of this document. All such subobjects MUST be forwarded
>    unmodified by transit LSRs.
>
> 7.3.2 Reporting Compliance with LSP Attributes
>
>    To report compliance with an attribute requested in the Attributes
>    Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in
>    the Attributes subobject. To report non-compliance, an LSR MAY clear
>    the corresponding bit in the Attributes subobject.
>
>    The requirement to report compliance MUST be specified in the
>    document that defines the usage of any bit. This will reduce to a
>    statement of whether hop-by-hop acknowledgement is required.

So, each implementation will have to keep a list of which bits it should react to, and which it shouldn't? This seems to be rife with interop headaches. Why not just mandate the MUST here and force the follow-on documents to inherit this? Or, split the bits into different attributes (hop-by-hop or not hop-by-hop)?

>
>    IANA is requested to manage the space of attributes bit flags
>    numbering them in the usual IETF notation starting at zero and
>    continuing through 2039.

So, there are up to 2039 individual bits allowed? Isn't that a bit of overkill?

[Ballot comment]
Gen-ART reviewer says "Not Ready". Main issue is IANA considerations
as in Russ's Discuss, but there is also a problem of comprehensibility.
If we leave that to the RFC copy-editor, the meaning may get distorted.

Document: draft-ietf-mpls-rsvpte-attributes-04.txt
Review: John Loughney
Date: 2 mars 2005



In summary, I don't think this document is ready for publication.

Major comment is that I find the IANA section inadequate. It seems to
be introducing a new namespace for IANA to take care of, but no rules
on how new values are allocated.  It seems to indicate that an RFC
number is needed in section 10.3, but I think this needs to be more
specific.  The text in other places of the document are not so
clear at what constitues a reason for allocating new bit flags, etc.,
so in the IANA section, I think there needs to be explicit text on the
the mechanisms for specifying and definting them.

Additionally, I had a lot of trouble actually parsing much of the document,
I am not going to site every single instance, but some examples are listed
below.  I think an editorial pass is needed to enhance the comprehensibility
of the text.

Minor comments
1) Way too much acronyms in the abstract ...
2) Took me several reads to be able to parse the following text:

    .... Because of the nature of the TLV
    construction the object is flexible and allows the future definition
    of:
    - further bit flags if further, distinct uses are discovered
    - arbitrary options and attributes parameters carried as individual
      TLVs.

suggest:

    The new RSVP-TE message object is quite flexible, due to the use of the
    TLV format and allows:
    - future specification of bit flags
    - additional options and atttribute paramerters carried in TLV format.

"if further, distinct uses are discovered" and "arbitrary options and attributes"
sounds like an open invitation for folks to invent new things without good reason ...

3) This text was confusing:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object will pass it on unaltered
  because of the C-Num.

suggest:

4.2 Generic Processing Rules for Path Messages

  An LSR that does not support this object is required to pass it on unaltered,
  as the C-Num indicates that the LSR should pass the object on transparently.

[Ballot discuss]
The IANA Considerations are not sufficient.  Section 10 define a
  new TLV space, but the rules for making additional assignments are
  not provided.  Further, section 10.5 does not indicate which IANA
  registry should be used to assign the new error code values.

[Ballot comment]
Section 1.1 says:
  >
  > The RSVP-TE signaling protocol also forms the basis of a signaling
  > protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and
  > [RFC3473]. The extensions described in this document are intended to
  > be equally applicable to MPLS and GMPLS.
  >
  I would like to see the title and abstract reflect this situation.