Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-03-27
16 Jim Guichard Changed action holders to Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella
2024-03-27
16 Jim Guichard AD review comments === https://mailarchive.ietf.org/arch/msg/mpls/xoPc-KRuGp_i4BRCjtmyzdjSn3Y/ ===
2024-03-27
16 (System) Changed action holders to Andrew Alston, Chandrasekar R, Tarek Saad, Ina Minei, Dante Pacella (IESG state changed)
2024-03-27
16 Jim Guichard IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2024-03-20
16 Cindy Morgan Shepherding AD changed to Jim Guichard
2024-02-09
16 Carlos Pignataro Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list.
2024-02-04
16 Daniam Henriques Request for Last Call review by RTGDIR is assigned to Carlos Pignataro
2024-02-01
16 Andrew Alston Requested Last Call review by RTGDIR
2024-02-01
16 Andrew Alston IESG state changed to AD Evaluation from Publication Requested
2023-12-22
16 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-16.txt
2023-12-22
16 (System) New version approved
2023-12-22
16 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2023-12-22
16 Chandrasekar R Uploaded new revision
2023-08-22
15 Nicolai Leymann
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 …
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.

2023-08-22
15 Nicolai Leymann IETF WG state changed to Submitted to IESG for Publication from WG Document
2023-08-22
15 Nicolai Leymann IESG state changed to Publication Requested from AD is watching
2023-08-22
15 Nicolai Leymann
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 …
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.

2023-07-25
15 Nicolai Leymann Tag Revised I-D Needed - Issue raised by IESG cleared.
2023-07-06
15 (System) Changed action holders to Andrew Alston (IESG state changed)
2023-07-06
15 Cindy Morgan IESG state changed to AD is watching from Dead
2023-06-21
15 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-15.txt
2023-06-21
15 (System) New version approved
2023-06-21
15 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2023-06-21
15 Chandrasekar R Uploaded new revision
2023-06-21
14 (System) Document has expired
2023-06-21
14 (System) IESG state changed to Dead from AD is watching
2022-12-18
14 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-14.txt
2022-12-18
14 (System) New version approved
2022-12-18
14 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad , mpls-chairs@ietf.org
2022-12-18
14 Chandrasekar R Uploaded new revision
2022-06-19
13 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-13.txt
2022-06-19
13 (System) New version approved
2022-06-19
13 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2022-06-19
13 Chandrasekar R Uploaded new revision
2022-03-23
12 Amy Vezza Shepherding AD changed to Andrew Alston
2021-12-19
12 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-12.txt
2021-12-19
12 (System) New version approved
2021-12-19
12 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2021-12-19
12 Chandrasekar R Uploaded new revision
2021-06-20
11 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-11.txt
2021-06-20
11 (System) New version approved
2021-06-20
11 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2021-06-20
11 Chandrasekar R Uploaded new revision
2021-03-10
10 Cindy Morgan Shepherding AD changed to Martin Vigoureux
2020-12-18
10 Alvaro Retana [Ballot comment]
[Thank you for addressing my DISCUSS.]
2020-12-18
10 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2020-12-18
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-12-18
10 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-10.txt
2020-12-18
10 (System) New version approved
2020-12-18
10 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Dante Pacella , Ina Minei , Tarek Saad
2020-12-18
10 Chandrasekar R Uploaded new revision
2020-11-24
09 Deborah Brungard IESG state changed to AD is watching from Dead
2020-11-22
09 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-09.txt
2020-11-22
09 (System) New version approved
2020-11-22
09 (System) Request for posting confirmation emailed to previous authors: Chandrasekar R , Tarek Saad , Dante Pacella , Ina Minei
2020-11-22
09 Chandrasekar R Uploaded new revision
2020-11-17
08 Benjamin Kaduk
[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 …
[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.
2020-11-17
08 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2020-11-17
08 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-08.txt
2020-11-17
08 (System) New version approved
2020-11-17
08 (System) Request for posting confirmation emailed to previous authors: Tarek Saad , Dante Pacella , Ina Minei , Chandrasekar R
2020-11-17
08 Chandrasekar R Uploaded new revision
2020-10-08
07 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2020-10-08
07 Tero Kivinen Assignment of request for Last Call review by SECDIR to Dacheng Zhang was marked no-response
2020-09-16
07 (System) Document has expired
2020-09-16
07 (System) IESG state changed to Dead from AD is watching
2020-09-15
07 Deborah Brungard Tag Revised I-D Needed - Issue raised by IESG set. Tag Revised I-D Needed cleared.
2020-09-15
07 Deborah Brungard IETF WG state changed to WG Document from Submitted to IESG for Publication
2020-09-15
07 Deborah Brungard During IESG review, two Discusses raised. Authors have not responded to any requests to discuss.
2020-09-15
07 Deborah Brungard IESG state changed to AD is watching::Revised I-D Needed from IESG Evaluation::Revised I-D Needed
2020-02-03
07 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2020-01-19
07 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Victor Kuarsingh was marked no-response
2019-12-05
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-12-05
07 Roman Danyliw
[Ballot comment]
Section 5. Recommend adding language about using more modern HMAC algorithms than those suggested in RFC2747.  For example:

OLD:
The security considerations …
[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.
2019-12-05
07 Roman Danyliw Ballot comment text updated for Roman Danyliw
2019-12-05
07 Roman Danyliw
[Ballot comment]
Section 5. Recommend adding language about using more modern HMAC algorithms than those suggested in RFC2747.  For example:

OLD:
The security considerations …
[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.
2019-12-05
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-12-04
07 Benjamin Kaduk
[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 …
[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.
2019-12-04
07 Benjamin Kaduk
[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: …
[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.
2019-12-04
07 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-12-04
07 Barry Leiba
[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 …
[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.
2019-12-04
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-12-04
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-12-04
07 Adam Roach
[Ballot comment]
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  > …
[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.
2019-12-04
07 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-12-03
07 Alissa Cooper [Ballot comment]
Please respond to the Gen-ART review.
2019-12-03
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-12-03
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-12-03
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-12-02
07 Alvaro Retana
[Ballot discuss]
§4.1 (Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability) says:

  A node supporting [RFC4090] facility protection FRR MAY …
[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.
2019-12-02
07 Alvaro Retana [Ballot comment]
- Why doesn't this document formally Update rfc8370?  §4.2.1 "specifies...additional procedures to support RI-RSVP"
2019-12-02
07 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2019-11-12
07 Cindy Morgan Placed on agenda for telechat - 2019-12-05
2019-11-12
07 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2019-11-12
07 Deborah Brungard Ballot has been issued
2019-11-12
07 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2019-11-12
07 Deborah Brungard Created "Approve" ballot
2019-11-12
07 Deborah Brungard Ballot writeup was changed
2019-11-05
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-11-04
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-11-04
07 Sabrina Tanamal
(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 …
(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
2019-10-30
07 Reese Enghardt Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Theresa Enghardt. Sent review to list.
2019-10-28
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2019-10-28
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2019-10-25
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dacheng Zhang
2019-10-25
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dacheng Zhang
2019-10-24
07 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2019-10-24
07 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2019-10-22
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-10-22
07 Amy Vezza
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 …
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)



2019-10-22
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-10-22
07 Deborah Brungard Last call was requested
2019-10-22
07 Deborah Brungard Ballot approval text was generated
2019-10-22
07 Deborah Brungard Ballot writeup was generated
2019-10-22
07 Deborah Brungard IESG state changed to Last Call Requested from Expert Review
2019-10-22
07 Deborah Brungard Last call announcement was generated
2019-09-03
07 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-07.txt
2019-09-03
07 (System) New version approved
2019-09-03
07 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Tarek Saad , Chandrasekar R , Dante Pacella
2019-09-03
07 Chandrasekar R Uploaded new revision
2019-08-02
Jenny Bui Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-mpls-ri-rsvp-frr
2019-08-02
Jenny Bui Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-mpls-ri-rsvp-frr
2019-06-20
06 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-06.txt
2019-06-20
06 (System) New version approved
2019-06-20
06 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Tarek Saad , Chandrasekar R , mpls-chairs@ietf.org, Dante Pacella
2019-06-20
06 Chandrasekar R Uploaded new revision
2019-05-16
05 Deborah Brungard Waiting for authors to respond to RTG Dir review comments.
2019-04-11
05 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Julien Meuric.
2019-03-20
05 Deborah Brungard Julien will do RTG Dir review.
2019-03-20
05 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2019-02-24
05 Min Ye Request for Last Call review by RTGDIR is assigned to Julien Meuric
2019-02-24
05 Min Ye Request for Last Call review by RTGDIR is assigned to Julien Meuric
2019-02-22
05 Deborah Brungard Requested Last Call review by RTGDIR
2019-02-22
05 Nicolai Leymann
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 …
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.

2019-02-22
05 Nicolai Leymann Responsible AD changed to Deborah Brungard
2019-02-22
05 Nicolai Leymann IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-02-22
05 Nicolai Leymann IESG state changed to Publication Requested from I-D Exists
2019-02-22
05 Nicolai Leymann IESG process started in state Publication Requested
2019-02-22
05 Nicolai Leymann Changed consensus to Yes from Unknown
2019-02-22
05 Nicolai Leymann Intended Status changed to Proposed Standard from None
2019-02-08
05 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-05.txt
2019-02-08
05 (System) New version approved
2019-02-08
05 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Tarek Saad , Chandrasekar R , Dante Pacella
2019-02-08
05 Chandrasekar R Uploaded new revision
2019-01-18
04 Nicolai Leymann
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 …
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.

2018-08-09
04 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-04.txt
2018-08-09
04 (System) New version approved
2018-08-09
04 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Tarek Saad , Chandrasekar R , Dante Pacella
2018-08-09
04 Chandrasekar R Uploaded new revision
2018-04-04
03 Nicolai Leymann IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2018-02-10
03 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-03.txt
2018-02-10
03 (System) New version approved
2018-02-10
03 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Tarek Saad , Chandrasekar R , Dante Pacella
2018-02-10
03 Chandrasekar R Uploaded new revision
2017-08-11
02 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-02.txt
2017-08-11
02 (System) New version approved
2017-08-11
02 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Dante Pacella , Chandrasekar R , Tarek Saad
2017-08-11
02 Chandrasekar R Uploaded new revision
2017-04-28
01 Loa Andersson Notification list changed to Nicolai Leymann <n.leymann@telekom.de>
2017-04-28
01 Loa Andersson Document shepherd changed to Nicolai Leymann
2017-02-12
01 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-01.txt
2017-02-12
01 (System) New version approved
2017-02-12
01 (System) Request for posting confirmation emailed to previous authors: "Tarek Saad" , "Ina Minei" , mpls-chairs@ietf.org, "Chandrasekar R" , "Dante Pacella"
2017-02-12
01 Chandrasekar R Uploaded new revision
2016-08-15
00 Loa Andersson This document now replaces draft-chandra-mpls-ri-rsvp-frr instead of None
2016-08-15
00 Chandrasekar R New version available: draft-ietf-mpls-ri-rsvp-frr-00.txt