Definition of a Record Route Object (RRO) Node-Id Sub-Object
draft-ietf-mpls-nodeid-subobject-07

From: rfc-editor@rfc-editor.org
Subject: AUTH48 [AH]: RFC 4561  NOW AVAILABLE
Date: Tue, Jun 13 16:38:50
To: jpv@cisco.com, zali@cisco.com, msiva@cisco.com
Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, rfc-editor@rfc-editor.org

[Ballot comment]
(based on Gen-ART review by John Loughney)

Section 3 says:
  In this document, we define the following new flag:

  Node-id: 0x20

There seems to be no registry for this flag space, and backtracking
to RFC 4090 and 3209 suggests that there are lots of flag valuess in
RSVP-TE with no registry. There's surely a risk of mistakes as a result.

There are boilerplate nits that the RFC Editor will catch.

[Ballot comment]
The document says:

A node MUST use
        the same address consistently. Once an address is used in RRO's
        IPv4 or IPv6 subobject, it SHOULD always be used for the
        lifetime of the LSP.

This MUST doesn't seem like an RFC 2119 MUST; it seems like operational
advice.  It is also not entirely clear what the scope of consistency is.
Clearly it my have both v4 anv v6 addresses; may it use different node-ids
for the different address families?  Or is this intended to apply only
for the lifetime of an LSP?

Substantial:

  In section 3, in the following para--

  > An implementation MAY either decide to support of one the following
  > options:

  --not clear language and not clear what the "MAY" specifies.
  There should be a description of what implementation supporting this
  spec MUST do so that other nodes can leverage that.

Editorial:

  - poor general formatting, affects readability, please fix

  - Section 1 "Terminology":
      "CSPF" defined, but not used
      ditto for "NHOP bypass tunnel"
      ditto for "NNHOP bypass tunnel"

  - Section 2:

      The illustration is not captioned, though references to Figure 1 are
      made in the document.

  - Section 3. Non-ASCII characters in the following para:
>
> As mentioned above, the limitation that we need to address is the
> generality of the contents of the RRO IPv4 and IPv6 subobjects, as
> defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobjects
> along with two flags (namely the (Local Protection Available÷ and
> (Local protection in use÷ bits). Moreover, other bits have been
> specified in [FAST-REROUTE] and [SOFT-PREEMPTION].

please check throughout the document.

> Authors' Address:

Should be "Addresses"