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

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 17:35:10 -0800

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

---

From: Tarek Saad <[email-masked]>
Date: Wed, 26 Feb 2020 18:34:17 +0000

Thank you Martin for reviewing the document and providing comments. We have uploaded version -09 that addresses them.
Please see inline for responses.

On 2/19/20, 8:35 PM, "Martin Vigoureux via Datatracker" <[email-masked]> wrote:

    
    
    Hello

           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.
[TS]: Indeed. Corrected now:
NEW:
           3.1.1.  IPv4 B-SFRR-Ready Extended ASSOCIATION ID  . . .   7
           3.1.2.  IPv6 B-SFRR-Ready Extended ASSOCIATION ID  . . .   8
    
    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.
[TS]: we don’t deviate from the recommendations in rfc6780. We explicitly added this in the text too.
NEW:
   The Extended ASSOCIATION object's Global Association Source MUST be
   set according to the rules defined in [RFC6780].
END
    
    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.
[TS]: Indeed. We revised to make it explicit for B-SFRR-Ready Extended ASSOCIATION ID too.
NEW:
3.1.1.  IPv4 B-SFRR-Ready Extended ASSOCIATION ID

   The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association
   type is carried inside the IPv4 Extended ASSOCIATION object and has
   the following format:

and

3.1.2.  IPv6 B-SFRR-Ready Extended ASSOCIATION ID

   The IPv6 Extended ASSOCIATION ID for the B-SFRR-Ready association
   type is carried inside the IPv6 Extended ASSOCIATION object and has
   the following format:
END
    
    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.
[TS]: this was modified to check against Bypass_Source_IPv4/6_Address
NEW:
   Note, when forwarding an RSVP Resv message upstream, the PLR node
   SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
   Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address field
   matches any of the PLR node addresses.
END

    By the way, Bypass_Destination_Address does not exist per se in your spec, only
    Bypass_Destination_IPv4_Address and Bypass_Destination_IPv6_Address
[TS]: yes, this was revised to mention Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address accordingly.

[TS]: this text was revised to provide more clarity:
NEW:
   The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
   ID is set to a common object that will be applied to all LSPs
   associated with the Bypass_Group_Identifiers that are carried in the
   B-SFRR-Active Extended ASSOCIATION ID.
END

Regards,
Tarek