[Lsr] Benjamin Kaduk's Discuss on draft-ietf-lsr-isis-rfc5306bis-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-isis-rfc5306bis-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 3.2 notes that "the presence of [the Restart] TLV indicates that
the sender supports the functionality defined in this document".  But,
while that was true for RFC 5306, I don't see how it can be true for the
extended functionality that's new in this document.  It seems on first
look that the need for a PR to be acknowledged by a PA means that the
routers in question will be able to properly determine full feature
support at runtime, in which case this is essentially an editorial
issue, but I would like to make sure it's received enough thought, so am
raising it as a Discuss point to get the needed discussion.
(We will still need to change this text to reflect reality, though.)
It's also unclear to me if we need to give more description of the
behavior when a router planning to restart does not receive (all) the
necessary PAs -- does it cancel the planned restart?  Fall back to the
regular RR usage?

It looks like there's an internal inconsistency between Section 3.2
("[w]hen transmitting a TLV multiple flags MUST NOT be set.") and
Section 3.3.2 ("the IIH is retransmitted with both RR and SA bits set").


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Abstract

Four paragraphs is perhaps pushing it a bit, for RFC style.  It might
also be nice to avoid starting two sentences with "This document
additionally describes", e.g., as Barry suggests.

It also seems a little mismatched to me to differentiate between
"restart while maintaining forwarding plane state" and "restarting",
since in Section 2 we make the convention that "restarting" means that
forwarding state is maintained definitionally.

Section 1

   In the case of a restarting router process, the first of these is
   highly undesirable, but the second is essential in order to ensure
   synchronization of the LSP database.

Is the convention introduced in section 2 about preserving forarding
state intended to apply here?

Section 3.2.3

   Neighbors of the router which has signaled planned restart SHOULD
   maintain the adjacency in a planned restart state until it receives
   an IIH with the RR bit set, receives an IIH with both PR and RR bits
   clear, or the adjacency holding time expires - whichever occurs
   first.

When might a router want to ignore the SHOULD (and how so)?

   c.  on a Point-to-Point circuit, transmission of LSPs, CSNPs, and
       PSNPs MAY be suppressed.  It is expected that the PDUs will not
       be received.

Are there any security considerations here (e.g., a spoofed PR flag
would cause suppression of updates and potentially DoS)?

Section 4.1

I'm a little surprised to see "RX PA" under the "Running Router" table,
since I thought the "running" categorization was supposed to imply that
it was not going to restart (which would be a "restarting router").  If
the categorizations are exclusive, then receiving PA would be an error
condition.

Section 6

I think we should go a bit further about the false-IIH with PR bit set,
since there is not a protocol mechanism to apply any sanity check to the
hold time that the recipient is obligated to apply (overriding local
policy).  Such spoofed values could be unreasonably large, and it may be
prudent to have a policy filter that rejects implausible values.
Even if such a policy is present, it seems that a series of spoofed IIHs
with PR set could force an adjacency to be maintained (absent topology
changes), by cancelling the PR-bit and then sending a new PR-bit in
quick succession.

Relatedly, Section 3.2.1's description of the RR/RA bits notes that:
      "This procedure allows the restarting router to cause the neighbor
       to maintain the adjacency long enough for restart to successfully
       complete, while also preventing repetitive restarts from
       maintaining an adjacency indefinitely."
It doesn't seem that this property (preventing repetitive restarts from
maintaining an adjacency indefinitely) still holds for PR/PA with a
neighbor router that is (mis)behaving in a certain way.  Explicitly
noting this disparity seems reasonable to me.