RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels
draft-ietf-mpls-summary-frr-rsvpte-09
Yes
(Deborah Brungard)
No Objection
Roman Danyliw
(Alissa Cooper)
(Magnus Westerlund)
(Suresh Krishnan)
Note: This ballot was opened for revision 08 and is now closed.
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment
(2020-02-16 for -08)
Sent
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (even if non blocking, I would appreciate it if authors sent a response). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3.1.1 and other places -- Is there any reason why the "Reserved field" does not specify "to be set to 0 when sending and ignored on received" ? -- Section 3.1 -- The flow is a little strange IMHO, there is text at the end of 3.1.2 that probably applies to the whole section 3.1. If this is the case, then may I suggest to have a subsection 3.1.3 ? -- Section 4 -- Is the number "11bbbbbb" be understood as a binary number ? Is "ignoring and passing" the object enough for backward compatibility? I am not an MPLS TE expert at all... but I find this section a little light: I assume that this object must be understand by the remote side of the "FRR tunnel".
Deborah Brungard Former IESG member
Yes
Yes
(for -08)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2020-02-19 for -08)
Not sent
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -08)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(2020-02-19 for -08)
Sent
§3 reads: The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that egress the same protected interface and are protected by the same bypass tunnel. This minimizes the number of bypass tunnel SFRR groups, and optimizes the amount of signaling needed between the PLR and the MP after FRR. The PLR MUST ensure all protected LSP(s) that are assigned the same Bypass_Group_Identifier use the same modified tunnel sender address for the backup path identification after FRR as described in [RFC4090]. The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that share the egress link, and bypass tunnel as long as the protected LSP(s) have the common group attributes, including the modified tunnel sender address used for backup path identification as described in [RFC4090]. There is some redundancy in the first and third paragraphs, and "to ensure" is not an action that should be standardized, perhaps: The PLR MUST assign the same Bypass_Group_Identifier to all protected LSP(s) that use the same modified tunnel sender address for the backup path identification after FRR as described in [RFC4090]. The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that egress the same protected interface and are protected by the same bypass tunnel, as long as the protected LSP(s) have common group attributes. This minimizes the number of bypass tunnel SFRR groups, and optimizes the amount of signaling needed between the PLR and the MP after FRR.
Barry Leiba Former IESG member
No Objection
No Objection
(2020-02-11 for -08)
Sent
Thanks for the work on this. I have a couple of minor substantive comments and a number of editorial ones. Substantive, but minor: — Section 3.1.1 and throughout — Should the “reserved” fields, which say, “Reserved for future use,” also add the customary, “MUST be set to zero and ignored on receipt”? — Section 3.1.2 — The MESSAGE_ID object flags SHOULD be cleared when transmitted by the PLR and ignored when received at the MP. Why SHOULD and not MUST? How do things interoperate properly if this isn’t done, and what reasons might there be for not doing it? Editorial: — Section 1 — Please expand “LER”, “LSP”, and “LSR” on first use. — Section 3 — For example, in the context of GMPLS-controlled LSP(s), the object is used to associate recovery LSPs with the LSP they are protecting. There might be a number agreement problem here: as it’s written, it implies that multiple recovery LSPs might protect a single LSP, and a single ASSOCIATION object is used for all of them. If that’s the case, then no change is needed. But it’s likely that you want to make everything either singular or plural: “the objects are used to associate recovery LSPs with the LSPs they are protecting.” ...or... “the object is used to associate a recovery LSP with the LSP it is protecting.” — Sections 3.2.1 and 3.2.2 — Bypass_Group_Identifier: 32 bits The Bypass_Group_Identifier that is previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. 1. I would say “32 bits each”. 2. The definite article (“The Bypass_Group_Identifier”) doesn’t go with the fact that there can be more than one of them. Also “is” doesn’t go with “previously”. So, maybe: NEW Bypass_Group_Identifier: 32 bits each A Bypass_Group_Identifier that was previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. END — Section 3.4 — Upon detection of the fault (egress link or node failure) Was there a fault we were talking about? Or should it be “a fault”? — Section 3.4.2 — each protected LSP associated with each Bypass_Group_Identifier, as if it received an individual RSVP Path messages for that LSP. Make it, “as if it had received an individual RSVP Path message”. — Section 5 — When using procedures defined in this document, FRR (or the reroute of protected LSP(s) on to the bypass tunnel) can be activated on per group of protected LSP(s). I can’t parse “can be activated on per group”, and, hence, don’t understand it. Can you fix it?
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-02-19 for -08)
Sent
Nice and simple. Thanks! RFC 2961 says that MESSAGE_ID objects are "always generated and processed over a single hop between RSVP neighbors", but IIRC the PLR and MP need not be immediate neighbors. Has this restriction from RFC 2961 already been lifted by some other document that we can reference (e.g., in Section 3.1.x where we say "a MESSAGE_ID object as defined by [RFC2961]")? Is it generally understood that "Reserved for future use." means "set to zero on transmit and ignore on receipt, until further notice"? Section 1 similar number of LSPs that ingress on the same link. In the event of the failure of the link or neighbor node, the RSVP-TE control plane of the node when acting as a PLR becomes busy rerouting protected LSPs signaling over the bypass tunnel(s) in one direction, nit: I think there's a singular/plural (possessive?) mismatch near "LSPs". Section 3 The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that egress the same protected interface and are protected by the same bypass tunnel. This minimizes the number of bypass tunnel SFRR groups, and optimizes the amount of signaling needed between the PLR and the MP after FRR. [...] The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that share the egress link, and bypass tunnel as long as the protected LSP(s) have the common group attributes, including the modified tunnel sender address used for backup path identification as described in [RFC4090]. Is one of these a superset of the other? The MP maintains the PLR group assignments learned via signaling, and acknowledges the group assignments via signaling. Once the PLR receives the acknowledgment, FRR signaling can proceed as group based. nit: "group-based" is (1) hyphenated, and (2) an adjective, so we need a noun to hang it off of. The PLR node that supports Summary FRR procedures adds an Extended ASSOCIATION object with B-SFRR-Ready Extended Association ID in the nit: I'd suggest s/The/A/ since there's probably more than one PLR node that meets these criteria, globally. Section 3.1.2 to [RFC2961]. The MESSAGE_ID object flags SHOULD be cleared when transmitted by the PLR and ignored when received at the MP. When might this SHOULD be ignored? (Are there cases where a MP might assign semantics to a received flag that was not intentionally set by the PLR with intent to induce those semantics?) Resv message (with exception of the MESSAGE_ID). If the fields do not match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a subsequent refresh, the PLR node MUST consider the protected LSP as not Summary FRR capable. This "absent in a subsequent refresh" makes me wonder about race conditions where the PLR tries to refresh and the MP removes the B-SFRR-Ready nature in its Resv, but the PLR attempts to engage the bypass before the Resv makes its way to the PLR -- the PLR thinks the bundled protection is active but the MP does not. Is this just "normal operation" and not worth worrying about? Section 3.2.x The Bypass_Group_Identifier that is previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. nit: s/is/was/ (I think?) Replacement TIME_VALUES object to be applied to all LSPs associated with each of the following Bypass_Group_Identifiers after receiving the B-SFRR-Active Extended ASSOCIATION Object. nit: s/following/preceding/ (I think?) Section 3.3 The facility backup method introduced in [RFC4090] takes advantage of MPLS label stacking (PLR imposing additional MPLS label post FRR) to allow rerouting of protected traffic over backup path. The backup nit: s/over backup path/over the backup path/ Section 3.3.2 Note, an MP may receive more than one RSVP Path message with the B- SFRR-Ready Extended ASSOCIATION object from different upstream PLR node(s). In this case, the MP node is expected to save all the received MESSAGE_IDs from the different upstream PLR node(s). After a failure, the MP node determines and activates the associated Summary Refresh ID to use once it receives and processes the RSVP Path message containing B-SFRR-Active Extended ASSOCIATION object that is signaled over the bypass tunnel from the PLR, as described Section 3.4 What is a "Summary Refresh ID" and where is it defined? I don't see it either here or in RFC 2961. Section 3.4 The PLR MUST signal non-Summary FRR capable LSPs over the bypass tunnel before signaling the Summary FRR capable LSPs. This is needed to allow for the case where the PLR node recently changed a bypass assignment and the MP has not processed the change yet. Talking through this, there's two main cases for "changed a bypass assignment", right -- "added an LSP to a group" and "removed an LSP from a group"? For the "removed from a group" case I see how this helps, since the PLR sends an explicit change and the MP can assume that the explicit change overrides any former group membership. But I'm not sure how/whether this helps with the "added to a group" change. Section 3.4.1 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. I see something more plausible as a target for this reference in Section 3.2(.x) than in Section 3.3(.x). Section 3.4.2 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended ASSOCIATION ID. 2. The TIME_VALUES object is copied from the TIMES_VALUE field in the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES nit: I suggest using a parallel linguistic construction for all the steps (e.g., always or never include "from the <FOO> field in"). Section 5 When using procedures defined in this document, FRR (or the reroute of protected LSP(s) on to the bypass tunnel) can be activated on per group of protected LSP(s). This allows an intruder to potentially impact and manipulate a set of protected LSP that are assigned to the same bypass tunnel group. I'd consider saying something about how "new attacks enabled by these mechanisms would also be possible without these mechanisms, just at a higher cost in signalling messages" (with the possible exception of the race condition I mentioned earlier).
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -08)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(2020-02-19 for -08)
Sent
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
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-02-19 for -08)
Sent
Thanks for quickly addressing the nits/comments from the TSV-ART review (Gorry thanks for the review!)!
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -08)
Not sent