Re: [Gen-art] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07

[Tarek Saad <[e-mail]>]

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" <[e-mail]> 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