Definition of an IS-IS Link Attribute Sub-TLV
draft-ietf-isis-link-attr-03

[Ballot comment]
Gen-ART Review by David Black.

  This draft is basically ready for publication, but has nits
  that should be fixed before publication.

  This is a short draft that defines a link attributes extension
  to IS-IS plus the first two attributes that it carries.  One has
  to be an IS-IS expert to fully understand this draft - that's
  quite reasonable for this sort of draft.

  idnits 2.03.11 finds the downref noted in the Last Call, flags
  [IS-IS] as a possible downref (as an ISO standard it's definitely
  not a downref), and says that page 4 has 59 lines (vs. 58 max).

[Ballot discuss]
Section 7.1., paragraph 5:
>    [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
>              System (IS-IS) Extensions for Traffic Engineering (TE)",
>              RFC 3784, June 2004.

  DISCUSS: DOWNREF to Informational RFC.

[Ballot discuss]
The semantics for these two flags are not defined well enough for the
specification to be clear.  What does an implementation do if a link
is part of some local protection?  No reference is given to the
process of computing a protection path so it is not well defined what
an excluded link should not be included in.

[Ballot discuss]
In Section 2, you say,

  The Link-attribute sub-type is 19 (to be assigned by IANA) and has a
  length of 2 octets.

I think that you mean,

  The Link-attribute sub-type is 19 (to be assigned by IANA). The
  length attribute associated with this sub-TLV's value is set to
  2 octets. 

Also, in the following paragraph you say:

  This sub-TLV is OPTIONAL and MUST appear at most once for a single IS
  neighbor.  If a received LSP contains more than one Link-Attribute
  Sub-TLV, an implementation MAY decide to consider only the first
  encountered instance.

It seems that the two sentences contradict each other. Also, did you mean
to say "LSP"?

[Ballot discuss]
In Section 2, you say,

  The Link-attribute sub-type is 19 (to be assigned by IANA) and has a
  length of 2 octets.

I think that you mean,

  The Link-attribute sub-type is 19 (to be assigned by IANA). The
  length attribute associated with this sub-TLV's value is set to
  2 octets. 

Also, in the following paragraph you say:

  This sub-TLV is OPTIONAL and MUST appear at most once for a single IS
  neighbor.  If a received LSP contains more than one Link-Attribute
  Sub-TLV, an implementation MAY decide to consider only the first
  encountered instance.

It seems that the two sentences contradict each other. Also, did you mean
to say "LSP"?

I thought I had put this on the 3/8 telechat, but I screwed up.  I'll put it on the telechat after the IETF.  I won't be AD any more, but hopefully the document will get approved.

The downrefs have been mentioned in the Last Call.

IANA Last Call Comments:

Upon approval of this document, IANA understands that there are
two actions  that need to be completed.

First, in the IS-IS TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints

a new registration is to be added to the subregsitry titled: Sub-TLVs
for TLV  22:

Type Description
---- -------------------------
tbd Link-attributes

The IANA notes that the author suggest a value of 19 for this sub-TLV.

Second, in the IS-IS TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints

a new registry is to be created, directly after the subregsitry titled: Sub-
TLVs for TLV 22.

This registry will be titled:

TLV 22 link-attribute bit values
--------------------------------
Values are to be allocated by the Standards Action process and Early
Allocation  is permitted.

The initial values in the TLV 22 link-attribute bit values subregistry will be:

Value Name
----- ----
0x1 Local Protection Available
0x2 Link Excluded from Local Protection

IANA understands that these are the only actions required upon approval
of this  document.

Further values are to be allocated by the Standards Action process
defined in [RFC2434], with Early Allocation (defined in [RFC4020])
permitted.

IANA Last Call Comments:

Upon approval of this document, IANA understands that there are
two actions  that need to be completed.

First, in the IS-IS TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints

a new registration is to be added to the subregsitry titled: Sub-TLVs
for TLV  22:

Type Description
---- -------------------------
tbd Link-attributes

The IANA notes that the author suggest a value of 19 for this sub-TLV.

Second, in the IS-IS TLV Codepoints registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints

a new registry is to be created, directly after the subregsitry titled: Sub-
TLVs for TLV 22.

This registry will be titled:

TLV 22 link-attribute bit values
--------------------------------
Values are to be allocated by the Standards Action process and Early
Allocation  is permitted.

The initial values in the TLV 22 link-attribute bit values subregistry will be:

Value Name
----- ----
0x1 Local Protection Available
0x2 Link Excluded from Local Protection

IANA understands that these are the only actions required upon approval
of this  document.

Further values are to be allocated by the Standards Action process
defined in [RFC2434], with Early Allocation (defined in [RFC4020])
permitted.

To: jpv@cisco.com,sprevidi@cisco.com,isis-chairs@tools.ietf.org
Subject: draft-ietf-isis-link-attr
Fcc: +iesg

Hi,

  I'm following up on Alex's AD Review comments from July 2005 -
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=39189

  Dave told me that this was all taken care of with a document update,
but I haven't seen the new I-D - perhaps it was accidentally never
submitted?

  In addition to Alex's comments, I have a couple of minor details:

- It might be nice to point out that the length field is always 2.

- How does one get another bit assigned?  What if I want to define
  something that uses 0x8?  Should there be an IANA registry?
  What rules should be applied (since it's a limited size, I'd
  recommend Expert Review or Standards Action or maybe
  IETF Consensus).

Thanks,
  Bill

AD Comments sent on 19-Jul-2005:

>                Definition of an IS-IS Link Attribute sub-TLV
>                                     
>                      draft-ietf-isis-link-attr-01.txt
>   
> Abstract
>   
>    This document defines a sub-TLV called "Link-attributes" carried
>    within the TLV 22 and used to flood some link characteristics.

Ed: some? ;) smth like "various traffic-engineering related link
characteristics" instead?

> Table of contents
> 
>    1. Introduction...................................................2
>    2. Link-attributes sub-TLV format.................................2
>    3. Interoperability with routers non supporting this capability...3
>    4. Security considerations........................................3
>    5. IANA considerations............................................3
>    6. Intellectual Property Considerations...........................3
>    7. Acknowledgments................................................4
>    8. References.....................................................4
>      8.1 Normative references.......................................4
>      8.2 Informative references.....................................4
>    9. Authors' Addresses.............................................5
>    Full Copyright Statement..........................................5
> 
> 
> 1. Introduction
>   
>    [IS-IS] specifies the IS-IS protocol (ISO 10589) with extensions to
>    support IPv4 in [IS-IS-IP]. A router advertises one or several Link
>    State Protocol data units which are composed of variable length
>    tuples called TLVs (Type-Length-Value).
>   
>    [IS-IS-TE] defines a set of new TLVs whose aims are to add more
>    information about links characteristics, increase the range of IS-IS
>    metrics and optimize the encoding of IS-IS prefixes. 
>   
>    This document defines a new sub-TLV named "Link-attributes" carried
>    within the extended IS reachability TLV (type 22) specified in [IS-
>    IS-TE].
>   
> 2. Link-attributes sub-TLV format
>   
>    The link-attribute sub-TLV is carried within the TLV 22 and has a
>    format identical to the sub-TLV format used by the Traffic
>    Engineering Extensions for IS-IS [IS-IS-TE]: 1 octet of sub-type, 1
>    octet of length of the value field of the sub-TLV followed by the
>    value field in this case, a 16 bit flags field.
>   
>    The Link-attribute sub-type is 19 (to be assigned by IANA) and has a
>    length of 2 octets.
>   
>    This sub-TLV is OPTIONAL and MAY appear at most once for a single IS
>    neighbor.

what if it appears more than once?

>    The following bits are defined:
>   
>
>
> 
> 
> Vasseur and Previdi                                          [Page 2]
>
> draft-ietf-isis-link-attr-01.txt                              May 2005
>
>    Local Protection Available (0x01). When set, this indicates that the
>    link is protected by means of some local protection mechanism (e.g
>    [FRR]).
>   
>    Link excluded from local protection path (0x02). When set, this link
>    SHOULD not be included in any computation of a repair path by any
>    other router in the routing area. The triggers for setting up this
>    bit are out of the scope of this document.

Ed: An example could be manual configuration?

>    Such link characteristics has several applications such as
>    constrained shortest path computation for a Traffic Engineering Label
>    Switched (TE LSP) path or the triggering of specific actions in the
>    context of IS-IS SPF computation.

Hmmm... such as?

>    Local maintenance required (0x04). When set, this indicates that the
>    link will be put out of service and will consequently be shortly
>    unavailable. The set of actions triggered by other nodes is out of
>    the scope of this document. An example of the usage of this bit is
>    provided in [GR-SHUT].

I'm concerned about the "can be used for many things, but here's one"
semantics definition. If it's used for GR-SHUT, can we say it's used for
GR-SHUT and define another bit when we need the next thing among many?

> 3. Interoperability with routers non supporting this capability
> 
>    A router not supporting the link-attribute sub-TLV MUST just silently
>    ignore this sub-TLV.

Ed: they won't see this "MUST", so probably "will" instead ? ;)

>    Where the information in the link attributes sub-TLV is used to
>    affect the IS-IS SPF calculation, additional information indicating
>    which routers are using this information is required to insure such
>    usage does not result in loops or black holes. How this additional
>    information is conveyed is outside the scope of this document.

Ouch!

So we're saying "one could use this to affect spf, but we aren't telling
how, and if we did that, we'd need much more stuff to avoid problems,
but we're not specifying that either"...

> 4. Security considerations
> 
>    No new security issues are raised in this document.

SEC ADs will probably point out that at least:

- giving out more info about network topology, hence a listener will be
  able to tell more about the network

- spoofing LSPs with those TLVs may lead to false network fluctuations and
  such

Not a problem, just need to document.

The rest seems fine.