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

[Ballot comment]
Thank you very for writing this document - it solves an important operational issue in a clean and elegant manner.

I don't have anything to add, other than supporting John Scudder's DISCUSS and also thanking him for such a comprehensive review...

Writeup for draft-ietf-mpls-ri-rsvp-frr-04.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - Standards Track indicated on the title page.
The specification should be on the Standards Track since it specifies
new protocol, protocol procedures and assigns new code points
from an IANA registry that require Standards Action.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Fast Reroute for RSVP-TE defines two different methods for local repair
  to reroute LSP traffic over a backup tunnel. The document defines a
  extension which enhances the facility backup and makes it independent
  from the refresh-interval.

Working Group Summary

  This is an update to RFC4090.

Document Quality

  The document went through several reviews and updates based
  on the feedback. There were some concerns on adding complexity
  to RSVP-TE as protocol which were addressed during the
  discussion on the WG Mailing List.

Personnel

  Nicolai Leymann is the Document Shepherd.
  James Guichard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has carefully reviewed the specification
  during WG last call and subsequently checked all diffs. Comments
  on the mailing list were addressed in the last version. The document
  shepherd believes that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd has no concerns about the depth and breadth of the
  reviews performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document does not require a specific review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The shepherd does not have any concerns about the document.

  All comments that were raised during the IESG review have been
  addressed in the most recent version of the draft. There are no
  open issues left and the draft is ready for publication.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There were no specific discussions or conclusions in the WG.

(9) 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? 

  There is solid consensus of all people who have reviewed and
  contributed to the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None errors found. Two unused references and one outdated, these
  nits should be addressed the next time the document is updated
  e.g. after the RTG Dir review.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define a data model nor does it allocate new
  media types and URI types.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative refrences are, with one exception, are to existing
  RFCs. One normative refrence, draft-ietf-mpls-summary-frr-rsvpte-01,
  is to a MPLS wg draft. This draft is ready to be progressed.
  The draft is also outdated, and this will be addressed the next
  time the document is updated  e.g. after the RTG Dir review.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  none.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no status change of any other documents when this
  document is published.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA consideration are straight forward and clearly written.
Only one code point is requested from an already existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are being defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal reviews necessary.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-mpls-ri-rsvp-frr-18
CC @jgscudder

Thanks for this document. It's a dense read for someone like me who is not an expert in RSVP, but it seems important, useful, and carefully done. I appreciate the precise and detailed work.

I have one concern I've flagged as a DISCUSS point, which may turn out not to be a big deal if I've just misunderstood some nuance, but in any case, we should talk through it. I also have some other comments I hope might be helpful.

## DISCUSS

### Section 4.1

  A node supporting facility backup protection [RFC4090] MUST set the
  RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE
  Scaling Techniques [RFC8370] only if it supports all the extensions
  specified in the rest of this document. 
 
I have several concerns about this. At least some of them probably relate to my limited expertise in the subject area, but maybe I can at least expose some areas where additional explanation might be helpful in the document.

First and foremost, as written this sentence doesn't seem like it's achievable in practice. Couldn't there be a legacy router in the field that supports both RFC 4090 and RFC 8370? Wouldn't that router then advertise the I bit, at least in some circumstances?

Second, this MUST seems to conflict with a SHOULD in section 4.6.1, which says,

  An implementation supporting RI-RSVP-FRR extensions SHOULD set the
  flag "Refresh interval Independent RSVP" or RI-RSVP flag in the
  CAPABILITY object carried in Hello messages as specified in RSVP-TE
  Scaling Techniques [RFC8370].
 
It makes me wonder if the section 4.1 paragraph should be more like this.

NEW:
  A node supporting facility backup protection [RFC4090] MUST NOT set the
  RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE
  Scaling Techniques [RFC8370] unless it supports all the extensions
  specified in the rest of this document. 

(Although even though that might be clearer, the first point stands, that it might not be achievable.)

Third, moving on to the end of the paragraph,

  Procedures for backward compatibility (see Section 4.6.2.3 of this
  document) delves on this in detail.

As far as I can tell, despite the title of Section 4.6.2, Subsection 4.6.2.3 isn't a procedure for backward compatibility, it's a warning about the terrible things that can happen if some node in the network is incompatible.

Is all of this right? That there could be a legacy node in the network, with no way to detect that it doesn't comply with the present specification, and that terrible things such as 4.6.2.3 describes, could happen as a result?

(I see Ketan Talaulikar raised a related concern in his RTGDIR review.)

[Ballot comment]
## COMMENT

### RTGDIR review

Please take a look at Ketan Talaulikar's RTGDIR review that was posted yesterday, (https://mailarchive.ietf.org/arch/msg/rtg-dir/PRZJa7LH9b3J1aRFo3BvYZ3DQUQ/). I won't repeat his points here, other than the one that appeared in my DISCUSS, but please consider all of them.

### Section 4.3.3, use of RFC 2119 keyword in example

You have a number of sections that include examples. The examples are very helpful for understanding the specification, thank you! However, you use RFC 2119/BCP 14 keywords in the examples, and I think you shouldn't. Those keywords are reserved for specifying procedures, and an example isn't specifying procedure, it's demonstrating it.

I'll call out each example separately but only provide the explanation here.

In this section, what I noticed was,

  1.  When C receives a Conditional PathTear from B, it decides to
      retain LSP state as it is the NP-MP of the PLR A.  C also MUST
      check whether Phop B had previously signaled availability of node
      protection.  As B had previously signaled NP availability by
      including B-SFRR-Ready Extended Association object, C MUST remove
      the B-SFRR-Ready Extended Association object containing
      Association Source set to B from the Path message and trigger a
      Path to D.

There are various ways this could be rewritten, the absolute easiest would be to simply substitute "must" for "MUST", although it would be cleaner to fully rewrite in terms of actions instead of expectations, as in,

NEW:
  1.  When C receives a Conditional PathTear from B, it decides to
      retain LSP state as it is the NP-MP of the PLR A.  It also
      checks whether Phop B had previously signaled availability of node
      protection.  As B had previously signaled NP availability by
      including B-SFRR-Ready Extended Association object, C removes
      the B-SFRR-Ready Extended Association object containing
      Association Source set to B from the Path message and triggers a
      Path to D.

### Section 4.4.3, RFC 2119 keyword misuse

  As any implementation that does not support Conditional PathTear MUST
  ignore the new object but process the message as a normal PathTear
  without generating any error, the Class-Num of the new object MUST be
  10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]).

I think the first MUST is unnecessary since you're stating a need, not a requirement. The need is fulfilled as a natural consequence of your choice of code point and the underlying requirement from RFC 2205. The second MUST is also unnecessary, you are not telling the implementer anything, you're just explaining why you chose the type code you did.

One possible fix would be to delete the paragraph, but it's probably nicer to the reader if you leave the explanation in place. Perhaps something like,

NEW:
  Any implementation that does not support Conditional PathTear needs
  to ignore the new object but process the message as a normal PathTear
  without generating any error. For this reason, the Class-Num of the
  new object follows the pattern 10bbbbbb where 'b' represents a bit.
  (The behavior for objects of this type is specified in Section 3.10
  of [RFC2205]).

### Section 4.5, clarification of requirement

  If the ingress wants to tear down the LSP because of a management
  event while the LSP is being locally repaired at a transit PLR, it
  would not be desirable to wait till the completion of backup LSP
  signaling to perform state cleanup.  To enable LSP state cleanup when
  the LSP is being locally repaired, the PLR MUST send a "Remote"
  PathTear message instructing the MP to delete the PSB and RSB states
  corresponding to the LSP.  The TTL in the "Remote" PathTear message
  MUST be set to 255.
 
In this paragraph, I am unclear exactly what the sentence "To enable LSP state cleanup when the LSP is being locally repaired, the PLR MUST send a "Remote" PathTear message instructing the MP to delete the PSB and RSB states corresponding to the LSP" is telling me. My best guess is,

NEW:
  If the ingress wants to tear down the LSP because of a management
  event while the LSP is being locally repaired at a transit PLR, it
  would not be desirable to wait till the completion of backup LSP
  signaling to perform state cleanup.  In this case, the PLR MUST send
  a "Remote" PathTear message instructing the MP to delete the PSB and
  RSB states corresponding to the LSP.  The TTL in the "Remote"
  PathTear message MUST be set to 255. Doing this enables LSP state
  cleanup when the LSP is being locally repaired,

Is that rewrite faithful to what you intended? If so, I suggest using it, or any other rewrite of your choosing that clarifies matters. In particular, my intent in the rewrite is to make it clear that the PLR is unequivocally required to do this, which IMO wasn't clear before.

### Section 4.5.1, clarification of requirement

  If local repair fails on the PLR after a failure, then this MUST be
  considered as a case for cleaning up LSP state from the PLR to the
  Egress.  The PLR achieves state cleanup by sending "Remote" PathTear
  to the MP.  The MP MUST delete the states corresponding to the LSP
  also propagate the PathTear downstream thereby achieving state
  cleanup from all downstream nodes up to the LSP egress.  Note that in
  the case of link protection, the PathTear MUST be directed to the LP-
  MP's Node-ID IP address rather than the Nhop interface address.
 
Similar to the previous case, the combination of the RFC 2119 keyword with the casual writing style leaves the intent of the requirement unclear to me. Here's an attempt at a rewrite, in the same spirit.

NEW:
  If local repair fails on the PLR after a failure, the PLR MUST send a
  "Remote" PathTear to the MP.  The purpose of doing this is to clean
  up LSP state from the PLR to the Egress. Upon receiving the PathTear,
  the MP will delete the states corresponding to the LSP and also
  propagate the PathTear downstream thereby achieving state cleanup
  from all downstream nodes up to the LSP egress.  Note that in the
  case of link protection, the PathTear MUST be directed to the LP-
  MP's Node-ID IP address rather than the Nhop interface address.

Note that I removed the second MUST, on the assumption that you aren't specifying a new requirement for the MP, but stating the natural consequence of a requirement you've already specified elsewhere. Please double-check that I haven't broken something!

### Section 4.5.2, use of RFC 2119 keyword in example

As with my 4.3.3 comment. In this case my suggestion is,

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

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

### Section 4.5.3.1, I'm confused

  If an LSP is preempted on an LP-MP after its Phop or the incoming
  link has already failed
 
Why "Phop or the incoming link" and not just "incoming link"? It's a link-protecting merge point, so why does it care about the failure of an upstream *node*? Also, this seems as though it conflicts with the title of the subsection, which is "Preemption on LP-MP after Phop Link Failure" and not "... after Phop or Phop Link Failure".

Could it be rewritten as follows?

  If an LSP is preempted on an LP-MP after its Phop
  link has already failed

### Section 4.5.3.2, I'm still confused but in the other direction

  If an LSP is preempted on an NP-MP after its Phop link has already
  failed
 
If it's a node-protecting merge point, shouldn't this one care about the Phop as well as the Phop link? (Also in the title of the subsection.)

### Section 4.5.3.2, use of RFC 2119 keyword in example

As with my 4.3.3 comment. In this case my suggestion is,

OLD:
  3.  As the only reason for C having retained state after Phop node
      failure was that it was an NP-MP, C MUST send a normal PathTear to
      D and delete its PSB state also.  D would also delete the PSB and
      RSB states on receiving a PathTear from C.

NEW:
  3.  As the only reason for C having retained state after Phop node
      failure was that it was an NP-MP, C sends a normal PathTear to
      D and deletes its PSB state also.  D would also delete the PSB and
      RSB states on receiving a PathTear from C.

### Section 4.6, ALL CAPS

I probably wouldn't even flag this if I weren't doing a full review already, but

  DOES NOT support RI-RSVP-FRR extensions.  Note that for LSPs

Although RFC 2119 doesn't forbid the use of all caps for non-reserved keywords, it's often considered to be inadvisable. I would suggest,

NEW:
  does not support RI-RSVP-FRR extensions.  Note that for LSPs

### Section 4.6.1, SHOULD set

  An implementation supporting RI-RSVP-FRR extensions SHOULD set the
  flag "Refresh interval Independent RSVP" or RI-RSVP flag in the
  CAPABILITY object carried in Hello messages as specified in RSVP-TE
  Scaling Techniques [RFC8370].
 
Depending on the resolution of my DISCUSS point, I guess you might want to revisit this SHOULD.

### Section 4.6.2.1, use of RFC 2119 keyword in example

As with my 4.3.3 comment. In this case my suggestion is,

OLD:
  -  A and B MUST reduce the refresh time to the default short refresh
      interval of 30 seconds and trigger a Path message

  -  If B is not an MP and if Phop link of B fails, B cannot send
      Conditional PathTear to C but MUST time out the PSB state from A
      normally.  Note that B can time out the PSB state A normally only
      if A did not set long refresh in the TIME_VALUES object carried in
      the Path messages sent earlier.

NEW:
  -  A and B reduce the refresh time to the default short refresh
      interval of 30 seconds and trigger a Path message

  -  If B is not an MP and if Phop link of B fails, B cannot send
      Conditional PathTear to C but times out the PSB state from A
      normally.  Note that B can time out the PSB state A normally only
      if A did not set long refresh in the TIME_VALUES object carried in
      the Path messages sent earlier.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
** Section 5
  When using RSVP
  Cryptographic Authentication [RFC2747], more robust algorithms
  [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed
  message digest where possible.

I don’t intended to open the generic topic of RSVP authentication.  However, I need help understanding the proposed guidance on cryptographic authentication.

RFC2104 specifies the core HMAC construction and HMAC-MD5

RFC2747 says “HMAC-MD5 is required as a baseline to be universally included in RSVP implementations providing cryptographic authentication, with other proposals optional”

FIPS-180-3 = specifies SHA-1, SHA-256, SHA-384, and SHA-512

What exactly is the recommendation on the “more robust algorithms … where possible”?  Across all the referenced drafts, HMAC-MD5, -SHA1, -SHA256, -SHA386 and -SHA512 were cited. 

Is this document intending to recommend MD5 and SHA1 as “robust algorithms”? My recommendation would be that implementations using RSVP Cryptographic Authentication SHOULD use HMAC-256/-386/-512.  Based on the RFC2747, HMAC-MD5 remains MTI.

[Ballot comment]
Thanks to Reese Enghardt for the GENART review.

Idnits reports:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

  == Unused Reference: 'RFC3936' is defined on line 1166, but no explicit
    reference was found in the text

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-mpls-ri-rsvp-frr-185

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. *BUT* is it completely outdated as it contains `Deborah Brungard is the Responsible Area Director`....

I hope that this review helps to improve the document,

Regards,

-éric



# COMMENTS (non-blocking)

## Please fix the ID-NITS

RFC 3936 is in the reference but I cannot find a use of this reference in the text...

## Section 4.2.1

Was `RRO` defined before ?

## Section 4.4.3

s/and should be set to eight./and MUST be set to eight./ ? Plus add some text about the receiver procedure when length is different than 8.

[Ballot comment]
1.  FIPS 180 has been up issued in 2015:  https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf .

2.  Security Considerations:  "When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed message digest where possible."  This sentence is confusing to me. 
  a.  It would seem like the 'SHOULD' should be a 'MUST'?  RFC2747 uses HMAC-MD5 which is well beyond its end of life, or HMAC-SHA1, which isn't deprecated yet, but NIST has plans to deprecate. 
  b.  In addition, the position of the references to RFC 2104 and FIPS 180 in the sentence adds to the confusion - I would suggest moving them to the end of the sentence.

3.  general, and only because there is another comment on this:  'let us assume' is commonly used in mathematical proofs.  However, I have no idea how common it is in the IETF RFCs, much less routing RFCs.

[Ballot comment]
1.  FIPS 180 has been up issued in 2015:  https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf .

2.  Security Considerations:  "When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed message digest where possible."  This sentence is confusing to me. 
would seem like the 'SHOULD' should be a 'MUST'?  RFC2747 uses HMAC-MD5 which is well beyond its end of life, or HMAC-SHA1, which isn't deprecated yet, but NIST has plans to deprecate.  In addition, the position of the references to RFC 2104 and FIPS 180 in the sentence adds to the confusion - I would suggest moving them to the end of the sentence.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-ri-rsvp-frr-18

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.



#GENERIC COMMENTS
#================
## This draft is well written and provides a good context and details of the problem
space, procedures and technologies. Only few non blocking COMMENTS for consideration.


#DETAILED COMMENTS
#=================

253   In the topology in Figure 1, let us consider a large number of LSPs
254   from A to D transiting B and C.  Assume that refresh interval has
255   been configured to be long of the order of minutes and refresh
256   reduction extensions are enabled on all routers.

258   Also let us assume that node protection has been configured for the
259   LSPs and the LSPs are protected by each router in the following way

suggested a small rewrite to make te text sound more procedural and avoids the word 'us':

"In the topology depicted in Figure 1, consider a significant number of
LSPs (Label Switched Paths) from node A to node D, transiting through nodes B and C.
Assume that the refresh interval is set to be relatively long, on the
order of minutes, and that refresh reduction extensions are enabled on all routers.

Additionally, assume that node protection has been configured for these
LSPs. Each router protects the LSPs in the following manner:
"

368   However, if a node supporting facility backup
369   protection [RFC4090] does set the RI-RSVP capability (I bit) but does
370   not support all the extensions specified in the rest of this
371   document, then it leaves room for stale state to linger around for an
372   inordinate period of time given the long refresh intervals
373   recommended by [RFC8370] or disruption of normal FRR operation.

WHat about following rewrite for this text blob:
"However, if a node that supports facility backup protection [RFC4090] sets
the RI-RSVP capability (I bit) but does not support all the extensions
specified in this document, it may result in lingering stale states
due to the long refresh intervals recommended by [RFC8370].
This can also disrupt normal Fast Reroute (FRR) operations.
"

1100   All assignments in this sub-registry are to be performed via
1101   Standards Action.

Would "IETF Review" not be a better less restrictive fit for the IANA assignment procedure?
https://www.rfc-editor.org/rfc/rfc8126.html#section-4

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-ri-rsvp-frr-17. If any part of this review is inaccurate, please let us know.

IANA has a question about the second action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Class Names, Class Numbers, and Class Types registry in the Resource Reservation Protocol (RSVP) Parameters registry group located at:

https://www.iana.org/assignments/rsvp-parameters/

a single new registration will be made from the 128-183 range as follows:

Class Number: [ TBD-at-Registration ]
Class Name: CONDITIONS
Reference: [ RFC-to-be ]

Second, Section 6.2 of the current draft states: "the allocation of the Merge-point condition bit or M-bit (see Section 4.4 of this document) will also be done by IANA.

Flag: 0x1 Name: Merge-point condition bit or M-bit"

IANA Question --> Is this to be a new registry or a sub-registry in the Resource Reservation Protocol (RSVP) Parameters registry group located at:

https://www.iana.org/assignments/rsvp-parameters/

If not, can the draft be more specific about where this registration should be made.

If so, could the draft provide the information needed for the establishment of a new registry or sub-registry? Please see RFC8126 for guidance.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-05-16):

From: The IESG
To: IETF-Announce
CC: Nicolai Leymann , draft-ietf-mpls-ri-rsvp-frr@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, n.leymann@telekom.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Refresh-interval Independent FRR Facility Protection) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Refresh-interval Independent
FRR Facility Protection'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-05-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines two
  local repair techniques to reroute Label Switched Path (LSP) traffic
  over pre-established backup tunnel.  Facility backup method allows
  one or more LSPs traversing a connected link or node to be protected
  using a bypass tunnel.  The many-to-one nature of local repair
  technique is attractive from scalability point of view.  This
  document enumerates facility backup procedures in RFC 4090 that rely
  on refresh timeout and hence make facility backup method refresh-
  interval dependent.  The RSVP-TE extensions defined in this document
  will enhance the facility backup protection mechanism by making the
  corresponding procedures refresh-interval independent and hence
  compatible with Refresh-interval Independent RSVP (RI-RSVP) specified
  in RFC 8370.  Hence, this document updates RFC 4090 in order to
  support RI-RSVP capability specified in RFC 8370.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3672/
  https://datatracker.ietf.org/ipr/2580/
  https://datatracker.ietf.org/ipr/3671/

Writeup for draft-ietf-mpls-ri-rsvp-frr-04.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - Standards Track indicated on the title page.
The specification should be on the Standards Track since it specifies
new protocol, protocol procedures and and assigns new code points
from an IANA registry that require Standards Action.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Fast Reroute for RSVP-TE defines two different methods for local repair
  to reroute LSP traffic over a backup tunnel. The document defines a
  extension which enhances the facility backup and makes it independent
  from the refesh-interval.

Working Group Summary

  This is an update to RFC4090.

Document Quality

  The document went through several reviews and updates based
  on the feedback. There were some concerns on adding complexity
  to RSVP-TE as as protocol which were addressed during the
  dicussion on the WG Mailing List.

  An implementation poll has been sent to the working group list and
  the Shepherd Write-Up  will be updated as we receive further
  information.


Personnel

  Nicolai Leymann is the Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has carefully reviewed the specification
  during WG last call and subsequently checked all diffs. Comments
  on the mailing list were addressed in the last version. The document
  shepherd believes that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd has no concerns about the depth and breadth of the
  reviews performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document does not require a specific review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The shepherd does not have any concerns about the document.

  All comments that were raised during the IESG review have been
  addressed in the most recent version of the draft. There are no
  open issues left and the draft is ready for publication.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There were no specific discussions or conclusions in the WG.

(9) 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? 

  There is solid consensus of all people who have reviewed and
  contributed to the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None errors found. Two unsused references and one outdated, these
  nits should be addressed the next time the document is updated
  e.g. after the RTG Dir review.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define a data model nor does it allocate new
  media types and URI types.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative refrences are, with one exception, are to existing
  RFCs. One normative refrence, draft-ietf-mpls-summary-frr-rsvpte-01,
  is to a MPLS wg draft. This draft is ready to be progressed.
  The draft is also outdated, and this will be addressed the next
  time the document is updated  e.g. after the RTG Dir review.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  none.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no status change of any other documents when this
  document is published.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA consideration are straight forward and clearly written.
Only one code point is requested from an already existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are being defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal reviews necessary.

Writeup for draft-ietf-mpls-ri-rsvp-frr-04.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - Standards Track indicated on the title page.
The specification should be on the Standards Track since it specifies
new protocol, protocol procedures and and assigns new code points
from an IANA registry that require Standards Action.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Fast Reroute for RSVP-TE defines two different methods for local repair
  to reroute LSP traffic over a backup tunnel. The document defines a
  extension which enhances the facility backup and makes it independent
  from the refesh-interval.

Working Group Summary

  This is an update to RFC4090.

Document Quality

  The document went through several reviews and updates based
  on the feedback. There were some concerns on adding complexity
  to RSVP-TE as as protocol which were addressed during the
  dicussion on the WG Mailing List.

  An implementation poll has been sent to the working group list and
  the Shepherd Write-Up  will be updated as we receive further
  information.


Personnel

  Nicolai Leymann is the Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has carefully reviewed the specification
  during WG last call and subsequently checked all diffs. Comments
  on the mailing list were addressed in the last version. The document
  shepherd believes that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd has no concerns about the depth and breadth of the
  reviews performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document does not require a specific review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The shepherd does not have any concerns about the document.

  All comments that were raised during the IESG review have been
  addressed in the most recent version of the draft. There are no
  open issues left and the draft is ready for publication.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There were no specific discussions or conclusions in the WG.

(9) 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? 

  There is solid consensus of all people who have reviewed and
  contributed to the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None errors found. Two unsused references and one outdated, these
  nits should be addressed the next time the document is updated
  e.g. after the RTG Dir review.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define a data model nor does it allocate new
  media types and URI types.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative refrences are, with one exception, are to existing
  RFCs. One normative refrence, draft-ietf-mpls-summary-frr-rsvpte-01,
  is to a MPLS wg draft. This draft is ready to be progressed.
  The draft is also outdated, and this will be addressed the next
  time the document is updated  e.g. after the RTG Dir review.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  none.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no status change of any other documents when this
  document is published.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA consideration are straight forward and clearly written.
Only one code point is requested from an already existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are being defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal reviews necessary.

[Ballot discuss]
[no significant changes from -07 to -08, so refreshing what version the
datatracker thinks this position applies to]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
>  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.

[Ballot discuss]
§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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mpls-ri-rsvp-frr-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Class Names, Class Numbers, and Class Types registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at:

https://www.iana.org/assignments/rsvp-parameters/

a new class number from the range 128-183 will be registered as follows:

Class Number: [ TBD-at-Registration ]
Class Name: CONDITIONS
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-11-05):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-ri-rsvp-frr@ietf.org, mpls-chairs@ietf.org, n.leymann@telekom.de, Nicolai Leymann
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Refresh-interval Independent FRR Facility Protection) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Refresh-interval Independent
FRR Facility Protection'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
  local repair techniques to reroute Label Switched Path (LSP) traffic
  over pre-established backup tunnel.  Facility backup method allows
  one or more LSPs traversing a connected link or node to be protected
  using a bypass tunnel.  The many-to-one nature of local repair
  technique is attractive from scalability point of view.  This
  document enumerates facility backup procedures in RFC 4090 that rely
  on refresh timeout and hence make facility backup method refresh-
  interval dependent.  The RSVP-TE extensions defined in this document
  will enhance the facility backup protection mechanism by making the
  corresponding procedures refresh-interval independent and hence
  compatible with Refresh-interval Independent RSVP (RI-RSVP) specified
  in RFC 8370.  Hence, this document updates RFC 4090 in order to
  support RI-RSVP capability specified in RFC 8370.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3672/
  https://datatracker.ietf.org/ipr/2580/
  https://datatracker.ietf.org/ipr/3671/



The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-mpls-summary-frr-rsvpte: RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels (None - IETF stream)

Writeup for draft-ietf-mpls-ri-rsvp-frr-04.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - Standards Track indicated on the title page.
The specification should be on the Standards Track since it specifies
new protocol, protocol procedures and and assigns new code points
from an IANA registry that require Standards Action.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Fast Reroute for RSVP-TE defines two different methods for local repair
  to reroute LSP traffic over a backup tunnel. The document defines a
  extension which enhances the facility backup and makes it independent
  from the refesh-interval.

Working Group Summary

  This is an update to RFC4090.

Document Quality

  The document went through several reviews and updates based
  on the feedback. There were some concerns on adding complexity
  to RSVP-TE as as protocol which were addressed during the
  dicussion on the WG Mailing List.

  An implementation poll has been sent to the working group list and
  the Shepherd Write-Up  will be updated as we receive further
  information.


Personnel

  Nicolai Leymann is the Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has carefully reviewed the specification
  during WG last call and subsequently checked all diffs. Comments
  on the mailing list were addressed in the last version. The document
  shepherd believes that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd has no concerns about the depth and breadth of the
  reviews performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document does not require a specific review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The shepherd does not have any concerns about the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There were no specific discussions or conclusions in the WG.

(9) 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? 

  There is solid consensus of all people who have reviewed and
  contributed to the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None errors found. Two unsused references and one outdated, these
  nits should be addressed the next time the document is updated
  e.g. after the RTG Dir review.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define a data model nor does it allocate new
  media types and URI types.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative refrences are, with one exception, are to existing
  RFCs. One normative refrence, draft-ietf-mpls-summary-frr-rsvpte-01,
  is to a MPLS wg draft. This draft is ready to be progressed.
  The draft is also outdated, and this will be addressed the next
  time the document is updated  e.g. after the RTG Dir review.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  none.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no status change of any other documents when this
  document is published.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considderation are straight forward and clearly written.
Only one code point is requested from an already existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are being defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal reviews necessary.

Writeup for draft-ietf-mpls-ri-rsvp-frr-04.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard - Standards Track indicated on the title page.
The specification should be on the Standards Track since it specifies
new protocol, protocol procedures and and assigns new code points
from an IANA registry that require Standards Action.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Fast Reroute for RSVP-TE defines two different methods for local repair
  to reroute LSP traffic over a backup tunnel. The document defines a
  extension which enhances the facility backup and makes it independent
  from the refesh-interval.

Working Group Summary

  This is an update to RFC4090.

Document Quality

  The document went through several reviews and updates based
  on the feedback. There were some concerns on adding complexity
  to RSVP-TE as as protocol which were addressed during the
  dicussion on the WG Mailing List.

  An implementation poll has been sent to the working group list and
  the Shepherd Write-Up  will be updated as we receive further
  information.


Personnel

  Nicolai Leymann is the Document Shepherd.
  Deborah Brungard is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has carefully reviewed the specification
  during WG last call and subsequently checked all diffs. Comments
  on the mailing list were addressed in the last version. The document
  shepherd believes that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd has no concerns about the depth and breadth of the
  reviews performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document does not require a specific review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The shepherd does not have any concerns about the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. There were no specific discussions or conclusions in the WG.

(9) 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? 

  There is solid consensus of all people who have reviewed and
  contributed to the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None errors found. Two unsused references and one outdated, these
  nits should be addressed the next time the document is updated
  e.g. after the RTG Dir review.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not define a data model nor does it allocate new
  media types and URI types.

(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative refrences are, with one exception, are to existing
  RFCs. One normative refrence, draft-ietf-mpls-summary-frr-rsvpte-01,
  is to a MPLS wg draft. This draft is ready to be progressed.
  The draft is also outdated, and this will be addressed the next
  time the document is updated  e.g. after the RTG Dir review.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  none.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no status change of any other documents when this
  document is published.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considderation are straight forward and clearly written.
Only one code point is requested from an already existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are being defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal reviews necessary.