Skip to main content

Last Call Review of draft-ietf-mpls-sfl-control-03
review-ietf-mpls-sfl-control-03-rtgdir-lc-venaas-2023-08-09-00

Request Review of draft-ietf-mpls-sfl-control
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-08-15
Requested 2023-08-01
Requested by Andrew Alston
Authors Stewart Bryant , George Swallow , Siva Sivabalan
I-D last updated 2023-08-09
Completed reviews Rtgdir Last Call review of -03 by Stig Venaas (diff)
Opsdir Last Call review of -04 by Joel Jaeggli
Secdir Last Call review of -04 by Charlie Kaufman
Genart Last Call review of -04 by Ines Robles
Tsvart Last Call review of -04 by Michael Scharf
Comments
Please assign to Adrian Farrel if he will accept it.
Assignment Reviewer Stig Venaas
State Completed
Request Last Call review on draft-ietf-mpls-sfl-control by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/eWaHS2edM__IdzaXTWX5tC0XUBI
Reviewed revision 03 (document currently at 04)
Result Has nits
Completed 2023-08-09
review-ietf-mpls-sfl-control-03-rtgdir-lc-venaas-2023-08-09-00
The only somewhat substantial comment I have is regarding this:

In section 3.1:
   Editors Note - We need to revisit the RFC6374 errors and the protocol
   to see if we need some more error codes.
Has this been done? This note should be removed before publication.

The remaining comments are all editorial.


In abstract:
   extend the lifetime of such labels.  It is not the only control
   protocol that might be used to support SFL, but it has the benefit of
   being able to be used without modifying of the existing MPLS control
                                      ^^^^^^^^^^^^
   protocols.  The existence of this design is not intended to restrict

Should say “modifying the existing” or “modification of the”
Same in section 1.

I don’t think there should be normative language in the abstract. It has MUST and SHOULD.


In section 3.1. Missing period at the end.
   0x3: SFL Withdraw-Ack. This indicates that the responder has
   received the Withdraw message and will withdraw the SFLs

   1 (Request (R))  Indicates to the Querier that this member of the
                  SFL batch is requested.  Where a value is specified
                  in the request, but the Responder is unable honour
                                                         ^^^^^^^
                  that request, no SFL is allocated and the
                  corresponding A flag MUST be cleared.
Should be “Is unable to honour”

In 3.2.1:
   If the Responder is unable to allocate all of the requested SFLs it
   MUST respond with a response code of SFL-Unable.  The Querier MUST
   determine whether the allocated SFLs were adequate for its purposes
   and MUST send a withdraw if there are not adequate.  A Querier MUST
                              ^^^^^^^^^^
   NOT attempt to hoard labels in the hope that the residual labels
   needed may become available in the future.
“if they are not adequate”?

In section 4:

4.  Return Path

   Where the LSP (or other MPLS construct) is multi-point to point, or
   multi-point to multi- point the RFC6374 Address TLV MUST be included
   in Query packet, even if the response is requested in-band, since
   this is needed to provide the necessary return address for this
   request.

Remove space “multi- point”.