[mpls] Martin Vigoureux's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)

[Martin Vigoureux via Datatracker <[e-mail]>]

Martin Vigoureux has entered the following ballot position for
draft-ietf-mpls-summary-frr-rsvpte-08: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-summary-frr-rsvpte/



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

Hello

it's getting late here so please dismiss any tiredness induced comment.

       3.1.1.  IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID  . . .   7
       3.1.2.  IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID  . . .   8
IPv4 and IPv6 appear twice. Not sure the second is needed.

You leave unspecified how to set the Global Association Source of Extended
ASSOCIATION object. If it is as in 6780 then I suggest to explicitly say it.
Indeed you explicitly refer to 4872 for the three other fields.

It might be a stupid thing to do, but the text is not clear on whether an IPv4
B-SFRR-Ready Extended ASSOCIATION ID can be added as the Extended Association
ID of an IPv6 Extended ASSOCIATION object and vice versa. Text is clear for
B-SFRR-Active however.

Why the MP does the test on the Bypass_Destination_Address:
   When forwarding an RSVP Path message downstream, the MP SHOULD remove
   any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association
   ID contains Bypass_Destination_Address matching the MP node address.
while the PLR does it on the association source (and not on the
Bypass_Source_Address):
   Note, when forwarding an RSVP Resv message upstream, the PLR node
   SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
   Association Source matches the PLR node address.

By the way, Bypass_Destination_Address does not exist per se in your spec, only
Bypass_Destination_IPv4_Address and Bypass_Destination_IPv6_Address

   The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
   ID is set to the common RSVP_HOP that was used by the PLR in
   Section 3.3 of this document.
There is no mention of RSVP_HOP in Section 3.3