Hi Theresa,
Happy new year!
Thanks for your thorough review and comments. We have reviewed them, and provided responses inline below. Please let us know if you have further comments.
On 12/16/19, 9:32 AM, "Theresa Enghardt via Datatracker" <noreply@xxxxxxxx> wrote:
Reviewer: Theresa Enghardt
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-mpls-summary-frr-rsvpte-07
Reviewer: Theresa Enghardt
Review Date: 2019-12-16
IETF LC End Date: 2019-12-25
IESG Telechat date: Not scheduled for a telechat
Summary: This document is well-written and almost ready for publication. There
are just a few minor points that should be addressed to make the contributions
of this document clearer to non-experts.
Major issues: None.
Minor issues:
After the motivation and problem statement (control plane gets overwhelmed),
the current text does not introduce what a bypass tunnel assignment group is or
give a high-level summary of what the solution to the problem is. To make the
text easier to understand, consider including a brief summary by adding some
text like the following: "Right now, for each LSP the FRR is signaled
individually. With the extension defined in this document, a PLR can assign
multiple LSPs to a bypass tunnel assignment group and communicate this
information to the MP, such that upon failure, the LSP only has to send one
message per LSP."
[TS]: it seems useful. We can add this to the introduction section 1 as:
NEW:
" [...]
large number of protected LSPs that traverse the same PLR and Merge
Point (MP) nodes.
+ Right now, for each protected LSP the FRR is signaled
+ individually. With the extension defined in this document, a PLR can assign
+ multiple LSPs to a bypass tunnel assignment group and communicate this
+ information to the MP, such that upon failure, the LSP only has to send one
+ message per bypass tunnel group."
>> Is the bypass tunnel assignment group or bypass group
>> identifier a new concept or has it already existed at the PLR, but now it is
>> additionally communicated to the MP?
[TS]: the per bypass tunnel group is a new concept introduced in this document.
"[…] to enable a MP node to become aware
of the PLR node's bypass tunnel assignment group" sounds like it has existed
before. In this case, it would be good to provide a reference where it has been
defined.
[TS]:
OLD:
[...] to enable a MP node to
become aware of the PLR node's bypass tunnel assignment group and
allow the FRR procedures between PLR node and MP node to be signaled
and processed on groups of protected LSPs.
NEW:
The extensions defined in this document update the procedures defined
in [RFC4090] for facility backup protection and enable the PLR and MP nodes to
signal and activate FRR on per bypass group of protected LSP(s).
Is the Summary Refresh procedure mentioned in the last paragraph of the
Introduction the same as the solution introduced above, i.e., signaling the
bypass tunnel for multiple LSPs, or is this another MPLS mechanism that is
being extended? In other words, is this solving the same problem (communicating
backup tunnels for multiple LSPs after a node or link has failed) or is this
solving a different but related problem?
[TS]: Summary Refresh is an existing solution (RFC2961) that allows reduction in the amount of soft-state refresh signaling between neighboring RSVP nodes by exchanging only ID(s) - as opposed to exchanging full RSVP Path and Resv messages. The Summary FRR procedures introduced in this document build on those concepts to allow further reduction in the signaling that occurs between PLR and MP after FRR and continue to use Summary refresh to refresh the soft-state after rerouting the signaling over the bypass tunnel.
Was it previously not possible to
exchange MESSAGE_ID information for rerouted Path and Resv states? Consider
changing the beginning of this paragraph to make it clear whether another
mechanism is introduced or whether this just provides more details on the
mechanism that was already mentioned.
[TS]: Yes, previously the MESSAGE_ID can be exchanged for each protected LSP between neighboring RSVP nodes. Using Summary FRR procedures defined in this document, the MESSAGE_ID can be exchanged per bypass tunnel group.
3. Extensions for Summary FRR Signaling
Does the previously defined RSVP ASSOCIATION object only allow to associate one
LSP to one backup tunnel, and now the extension allows to signal multiple LSPs
to the same backup tunnel? Consider stating this explicitly.
[TS]: The Association Type defined in RFC4872 and RFC49873 are specific to end-to-end and per segment LSP protection recovery and do not apply to the facility backup protection as defined in RFC4090. Hence, this document is defining a new Association type for the RSVP ASSOCIATION object to carry the needed information to do the per bypass tunnel group association.
3.3
"the PLR MUST ensure bypass tunnel assignment can satisfy the protected LSP MTU
requirements post FRR" - Is there an existing mechanism to do this?
[TS]: Section 2.6 in RFC3209 describes a mechanism to determine whether a node should fragment or drop a packet that exceeds the Path MTU as discovered using RSVP signaling on primary LSP path. A PLR can leverage the RSVP discovered Path MTU on the backup and primary LSP path to ensure MTU is not exceeded after rerouting traffic on to the bypass tunnel.
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.4 of this document."
→ "was used by the PLR in Section 3.4"? But this text is in 3.4. Is this really
referencing to the same section? Or, as RSVP_HOP has been mentioned in the
previous sections, is the intention to refer back to a previous section?
[TS]: this was a typo. The correct section is 3.3 and will be corrected.
5. Security Considerations
"slightly more information could be deduced about the state of the network"?
Consider providing one or two examples of additional information that could be
deduced. What could be the impact of an adversary deducing this information?
[TS]: A possible implication is:
when using producers defined in this document, FRR (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 possibly impact and manipulate a set of protected LSP that are assigned to the same group.
Nits/editorial comments:
Introduction:
"MP" is currently expanded on second use, should be on first use
"when the failure affects large number of protected LSPs" -> "when the failure
affects a large number of protected LSPs" Consider expanding "LER"
3.4.2
"and that would have exchanged in a Path message sent to the MP" -> "and that
would have been exchanged in a Path message sent to the MP"?
[TS]: suggestion accepted and will be updated.
Regards,
Tarek
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
