Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-07

Summary: Has 2 DISCUSSes. Needs 2 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2019-12-04)
I think there's a lot of SHOULDs in this document that, if ignored,
would cause the implementation to fail to achieve its stated purpose
(elimination of stale state retention).  Therefore, I don't understand
why they are given as SHOULD rather than MUST.  I have noted many (but
probably not all) such instances in the COMMENT section.
Comment (2019-12-04)
Thanks for this document; the core procedures seem solid and
well-thought-out.

I agree with Barry's comment.

Section 1

Just to check my understanding: since we only mention the bypass-tunnel
mode of RFC 4090 FRR, I infer that the detour LSPs do not need separate
handling, since they have a one-to-one correspondence with the main LSP,
which RI-RSVP is already tracking explicitly?

Section 4.1

   A node supporting [RFC4090] facility protection FRR MAY set the RI-
   RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling
   Techniques [RFC8370] only if it supports all the extensions specified

nit: Section 3.1, no?

   in the rest of this document.  A node supporting [RFC4090] facility
   bypass FRR but not supporting the extensions specified in this
   document MUST reset the RI-RSVP capability (I bit) in the outgoing
   Node-ID based Hello messages.  Hence, this document updates [RFC4090]
   by defining extensions and additional procedures over facility
   protection FRR defined in [RFC4090] in order to advertise RI-RSVP
   capability [RFC8370].

This sounds like it is changing the semantics of the I bit that was
already defined, to mean support for more extentions than it originally
was used for.  How is this backwards compatible (that is, how will an
implementation know that the peer supports this updated semantics vs.
the original semantics)?
[I think this is exactly the core of Alvaro's Discuss point, which I
support.]

Section 4.2.1

   -  The PLR MUST also include its router ID in a Node-ID sub-object in
      RRO object carried in a Path message.  While including its router
      ID in the Node-ID sub-object carried in the outgoing Path message,
      the PLR MUST include the Node-ID sub-object after including its
      IPv4/IPv6 address or unnumbered interface ID sub-object.

Remind me why the ordering is important?

Section 4.2.3

   A node receiving Path messages should determine whether they contain
   a B-SFRR-Ready Extended Association object with the Node-ID address
   of the PLR as the source and its own Node-ID as the destination.  In

To be clear, the node receiving Path messages is just looking for
whether its Node-ID is the destination in the B-SFRR-Ready Extended
Association object, and treating the source address as the Node-ID of
the PLR; the node does not a priori know that this other node is "the
PLR", right?  This should probably be reworded, if so.

   If a matching B-SFRR-Ready Extended Association object is found in
   the Path message and if there is an operational remote signaling
   adjacency with the PLR that has advertised RI-RSVP capability (I-bit)
   [RFC8370] in its Node-ID based Hello messages, then the node SHOULD
   consider itself as the MP for the corresponding PLR.  The matching

"corresponding PLR" for this specific LSP, right?

Section 4.2.4

   -  The MP later receives a Path with no matching B-SFRR-Ready
      Extended Association object corresponding to the PLR's IP address
      contained in the Path RRO, or

Again, this is for the specific LSP in question?

   -  The MP receives a PathTear, or

(and some scoping may be needed here, too -- *any* PathTear is probably
too broad a criterion)

   Unlike the normal path state that is either locally generated on the
   ingress or created by a Path message from the Phop node, the "remote"

I'm not sure why the ingress case is a relevant comparison; the ingress
is not ever going to be the MP, is it?

Section 4.3.3

      protection.  As B had previously signaled NP availability by
      including B-SFRR-Ready Extended Association object, C SHOULD
      remove the B-SFRR-Ready Extended Association object containing
      Association Source set to B from the Path message and trigger a
      Path to D.

This is only a SHOULD-level requirement.  How does D learn to clean up
the associated state if the SHOULD is ignored?

Section 4.4

   does not require the receiving node to unconditionally delete the LSP
   state immediately.  For this, B SHOULD add a new optional CONDITIONS
   object in the PathTear.  The CONDITIONS object is defined in
   Section 4.4.3.  If node C also understands the new object, then C
   SHOULD delete LSP state only if it is not an NP-MP - in other words C
   SHOULD delete LSP state if there is no "remote" PLR path state on C.

This is only a SHOULD-level requirement, but won't C tear down the whole
LSP if the CONDITIONS are not {present and understood}?  Similarly, what
happens if C does not understand the CONDITIONS object -- won't the
whole LSP be torn down?

Section 4.4.3

I'd probably have an introductory note that CONDITIONS is intended to
see generic usage, and we only define one ('M') condition in this
document.
Also, what's the mnemonic for choosing 'M'?

Section 4.5

   5. On D there would be a remote signaling adjacency with B and so D
      SHOULD accept the "Remote" PathTear and delete the PSB and RSB
      states corresponding to the LSP.

Just to check my understanding: this would also tear down any other LSPs
that were using the same node protection path through F, right?

Section 4.5.2

   When a PLR router that has already made NP available detects a change
   in the RRO carried in the Resv message indicating that the router's
   former NP-MP is no longer present in the LSP path, then the router
   SHOULD send a "Remote" PathTear directly to its former NP-MP.

Why is this only SHOULD?  Won't the former NP-MP retain stale state
otherwise?

   The new RRO of the LSP carried in the Resv will not contain C.  When
   A processes the Resv with a new RRO not containing C - its former NP-
   MP, A SHOULD send a "Remote" PathTear to C.  When C receives the

(I'm not sure that I'd use the normative "SHOULD" here.)

   "Remote" PathTear for its PSB state, C will send a normal PathTear
   downstream to D and delete both the PSB and RSB states corresponding
   to the LSP.  As D has already received backup LSP signaling from B, D
   will retain control plane and forwarding states corresponding to the
   LSP.

Remind me where this behavior of D is specified (to ignore the PathTear
since it already got the backup LSP signaling).  It's intuitive/obvious,
but I forget where it's written down.

Section 4.6

   Note that for LSPs requesting only link protection, the PLR and the
   LP-MP need to support the extensions.

I think this comparison would be more poigniant if the word "only" was
inserted, for "only the PLR and the LP need to support".

Section 4.6.2

To double-check: the procedures in the subsections only apply when the
ingress has requested protection, right?

Section 4.6.2.2

   -  If the node reduces the refresh time from the above procedures, it
      SHOULD also not execute MP procedures specified in Section 4.3 of
      this document.

Just to check: a reduced refresh time in either Resv *or* Path suffices
to prohibit *all* the MP procedures?

Section 5

Aren't there more documents whose security considerations are also
relevant (e.g., RFC 8370, RFC 2961, etc.)?

Why is utilizing the authentication key for Node-ID Hello messages with
TTL>1 only a MAY and not a SHOULD?

I'd also suggest to acknowledge the inherent risk when sending
non-immediate-neighbor Hellos that the intermediate could tamper with
them and disrupt the connection (though any such intermediate is in a
position to do worse mischief).

If we're going to (per my Discuss) keep all the SHOULDs and not MUSTs,
we should talk about how failing to follow the SHOULDs will lead to
increased state usage on peer nodes and potentially DoS.

It would be reasonable to mention that we have a solid negotiation story
so that we don't expect to send conditional PathTears to nodes that
don't comprehend them, which reduces the risk of misinterpretation and
having a LSP get torn down unnecessarily.

Section 6

When reading Section 4.4.3 I had the distinct impression that the
"Reserved" field was intended to have future flags allocated from it.
Wouldn't it make sense to create a registry with which to do so?
If I was wrong about this, I might have to revise my previous comments
on that section.

Alvaro Retana Discuss

Discuss (2019-12-02)
§4.1 (Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability) says:

   A node supporting [RFC4090] facility protection FRR MAY set the RI-
   RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling
   Techniques [RFC8370] only if it supports all the extensions specified
   in the rest of this document.  A node supporting [RFC4090] facility
   bypass FRR but not supporting the extensions specified in this
   document MUST reset the RI-RSVP capability (I bit) in the outgoing
   Node-ID based Hello messages.  Hence, this document updates [RFC4090]
   by defining extensions and additional procedures over facility
   protection FRR defined in [RFC4090] in order to advertise RI-RSVP
   capability [RFC8370].

I understand the intent: advertise the I bit if this specification is supported, and don't if it is not.  However, the second sentence cannot be normative ("MUST reset the RI-RSVP capability") because, by definition, a node that doesn't support this specification won't implement anything in it.  IOW, this document can't mandate a behavior for nodes that may not be aware of it.

The conditions for supporting RI-RSVP from rfc8370/§3 don't contemplate this specification (obviously!), which means that nodes that conform to rfc8370 may advertise the capability without supporting this document.  Note that rfc8370 doesn't even mention rfc4090, so the setting of the I bit seems independent to it too.

I am balloting DISCUSS because the correct setting of the RI-RSVP capability is essential to the operation described in this document.
Comment (2019-12-02)
- Why doesn't this document formally Update rfc8370?  §4.2.1 "specifies...additional procedures to support RI-RSVP"

Deborah Brungard Yes

Alissa Cooper No Objection

Comment (2019-12-03)
Please respond to the Gen-ART review.

Roman Danyliw No Objection

Comment (2019-12-05)
Section 5. Recommend adding language about using more modern HMAC algorithms than those suggested in RFC2747.  For example: 

OLD:
The security considerations pertaining to the original RSVP protocol
[RFC2205], [RFC3209] and [RFC5920] remain relevant.

NEW:
The security considerations pertaining to the original RSVP protocol [RFC2205], [RFC3209] and [RFC5920] remain relevant.  When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA-512 [RFC2104][SHS] SHOULD be used when computing the keyed message digest where possible.


   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [SHS]      National Institute of Standards and Technology (NIST),
              FIPS Publication 186-3: Digital Signature Standard,
              October 2008.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Barry Leiba No Objection

Comment (2019-12-04)
There are numerous problems with the use and absence of articles (“the”, “a”, “an”) throughout the document: articles are missing when they should be there, “the” is used when an indefinite article should be, and so on.  That made it a harder read than it should have been.  The RPC will fix it during editing, but maybe the AD should add an RFC Editor Note to alert them to be particularly watchful for these issues.

Adam Roach No Objection

Comment (2019-12-04)
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  > document are to be interpreted as described in RFC-2119 [RFC2119].

Please update to use the boilerplate specified by RFC 8174.

Magnus Westerlund No Objection

Ignas Bagdonas No Record

Warren Kumari No Record

Alexey Melnikov No Record

Martin Vigoureux No Record

Éric Vyncke No Record