Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions
RFC 5786

Received changes through RFC Editor sync (changed abstract to 'OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]')

[Ballot comment]
Section 3., paragraph 0:
> 3. Rejected Potential Solution

  This section would make a good appendix.


Section 4.1., paragraph 6:
>    The Node IPv4 Local Address sub-TLV length is in octets. It is the
>    sum of all n IPv4 Address encodings in the sub-TLV where n is the
>    number of local addresses included in the sub-TLV.

  You mean: sum of the *lengths* of all n IPv4 encodings (each of which
  is 5 octets.)


Section 4.1., paragraph 10:
>    This encoding consumes (PrefixLength +
>    31) / 32) 32-bit words.

  The length calculation needs to be rounded up to be accurate.


Section 4.1., paragraph 11:
>    The Node IPv6 Local Address sub-TLV length is in octets. It is the
>    sum of all n IPv6 Address encodings in the sub-TLV where n is the
>    number of local addresses included in the sub-TLV.

  "sum of *lengths*" (see above)

[Ballot comment]
In the IANA considerations section:

>  IANA is requested to maintain the registry for the sub-TLVs of the
  node attribute TLV and reserve value 1 for Node IPv4 Local Address
  sub-TLV and value 2 for Node IPv6 Local Address sub-TLV.

'... to create and maintain the resgistry ...' seems more appropriate.

[Ballot comment]
On page 6:
  PrefixOptions is an 8-bit field describing various capabilities
  associated with the prefix [RFC5340].

I think a pointer to Appendix A.4.1.1 in RFC 5340 would be helpful here.

4.2. Operation

  The node attribute TLV must appear in exactly one TE LSA originated
  by a router. Furthermore, only one node attribute TLV must be
  advertised in such a LSA. A node attribute TLV must carry at most one
  Node IPv4 Local Address sub-TLV and at most one Node IPv6 Local
  Address sub-TLV.

It looks like this section should be using "MUST"s instead of "must"s.

[Ballot comment]
Voting "Yes" but please consider fixing these nits...

Section 2.1
  For the above reasons this document proposes an enhancement to OSPF
  TE extensions to advertise the local addresses of a node.
s/proposes/defines/
---
Section 4.1
  The Node IPv4 Local Address sub-TLV length is in octets. It is the
  sum of all n IPv4 Address encodings in the sub-TLV where n is the
  number of local addresses included in the sub-TLV.
The use of "sum" is confusing. Perhaps "sum of the lengths"?
---
Section 4.1
  The Node IPv6 Local Address sub-TLV length is in octets. It is the
  sum of all n IPv6 Address encodings in the sub-TLV where n is the
  number of local addresses included in the sub-TLV.
Ditto
---
Section 4.2
  The node attribute TLV must appear in exactly one TE LSA originated
  by a router. Furthermore, only one node attribute TLV must be
  advertised in such a LSA. A node attribute TLV must carry at most one
  Node IPv4 Local Address sub-TLV and at most one Node IPv6 Local
  Address sub-TLV.
I thought that the node attribute TLV was optional, so this looks off. I also wonder if this can be reworded in 2119 langauge.
  The node attribute TLV MUST NOT appear in more than one TE LSA
  originated by a router. Furthermore, such an LSA MUST NOT include
  more than one node attribute TLV. A node attribute TLV MUST NOT carry
  more than one of each of the Node IPv4 Local Address sub-TLV and the
  Node IPv6 Local Address sub-TLV.
---

IANA questions/comments:

AUTHORS: please see our question about Action 2.

ACTION 1:

A new assignment in "Top level Types in TE LSAs" at
http://www.iana.org/assignments/ospf-traffic-eng-tlvs/

Value Top Level Types Reference
----------- ---------------- ---------
5 Node [RFC-ospf-te-node-addr-06]


ACTION 2:

A new sub-registry at
http://www.iana.org/assignments/ospf-traffic-eng-tlvs/

Registry Name: Types for sub-TLVs of TE Node TLV (Value 5)
Reference: [RFC-ospf-te-node-addr-06]
Range Registration Procedures Notes
------------ --------------------------------- --------------------
0-32767 Standards Action
32768-32777 Experimental Use IANA does not assign


Registry:
Value Sub-TLV Reference
----------- ------------------------------------ ---------
0 Reserved [RFC-ospf-te-node-addr-06]
1 Node IPv4 Local Address sub-TLV [RFC-ospf-te-node-addr-06]
2 Node IPv6 Local Address [RFC-ospf-te-node-addr-06]
3-32767 Unassigned
32768-32777 Experimental use
[RFC-ospf-te-node-addr-06]
32778-65535 Reserved [RFC-ospf-te-node-addr-06]

QUESTION: Is value "0" reserved or available for assignment?

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes - I've reviewed it myself several times.

    Do you have any concerns about the depth or
    breadth of the reviews that have been performed?
   
    No

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any event,
    if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No

  5. How solid is the WG consensus behind this document? Does it represent
    the strong concurrence of a few individuals, with others being silent,
    or does the WG as a whole understand and agree with it?

    The draft has been around for several years and evolved to allow its
    applicability to ASON routing. I see no barriers to standardization.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items?
idnits 2.11.11

tmp/draft-ietf-ospf-te-node-addr-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
    Standard


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 1 warning (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------


  8. Is the document split into normative and informative references?

    Yes

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state? (note
    here that the RFC editor will not publish an RFC with normative
    references to IDs, it will delay publication until all such IDs
    are also ready for publication as RFCs.)

    No

  9. What is the intended status of the document? (e.g., Proposed Standard,
    Informational?)

    Proposed Standard

10. For Standards Track and BCP documents, the IESG approval announcement
    includes a write-up section with the following sections:

    * Technical Summary

      This draft extends OSPF TE to advertise addresses and prefixes without
      the overhead of the TE link sub-TLV or relegation to host addresses.

    * Working Group Summary

      There is no opposition to the draft and  at least on CCAMP draft has
      it as a normative reference.

    * Protocol Quality

      The TLV and sub-TLV definitions and conventions for advertisement
      of IPv4 and IPv6 addresses are consistent with OSPF and OSPFv3. This
      encoding is both straight forward and concise.