Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07

[Ines Robles <[e-mail]>]

Dear Jeong-dong,

Thank you very much for addressing my comments. I agree with all of them.

Best Regards,

Ines.

On Fri, Oct 15, 2021 at 12:21 PM Jeong-dong Ryoo <[e-mail]> wrote:

> Dear Ines,
>
> Thank you for your review and for giving us your comments.
>
> The co-authors of this draft have discussed, and we think all of your
> comments should be reflected. We are proposing text modifications as shown
> below:
>
> #1:
> OLD:
> ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
> a shared mesh protection (SMP) mechanism
> NEW:
> TU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
> a shared mesh protection (SMP) mechanism, which are not specific to
> a particular network technology in terms of architecture types,
> preemption principle, and path monitoring methods, etc.
>
> #2: Add the following new sentence after the sentence you indicated:
>  Examples of shared resources include the capacity of a link and the
> cross-connects in a node.
>
> #3: Modify the text as you suggested
>
> #4-1: Modify the text as you suggested
>
> #4-2:
> OLD:
> (1) the ability to identify a "secondary protecting LSP" (hereby
>       called the "secondary LSP") used to recover another primary
>       working LSP (hereby called the "protected LSP")
> NEW:
> (1) the ability to identify a "secondary protecting LSP"
>       (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1,  hereby
>       called the "secondary LSP") used to recover another "primary
>       working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1,
>       hereby called the "protected LSP").
>
> #5:
> OLD:
>    The security threats discussed in [RFC4872] also apply to this
>    document.  Additionally, it may be possible to cause disruption to
>    traffic on one protecting LSP by targeting a link used by the primary
>    LSP of another, higher priority LSP somewhere completely different in
>    the network.  To prevent such an additional risk factor, it is
>    important not only to use security mechanisms as discussed in
>    [RFC4872] but also to preserve privacy of information about
>    protecting LSPs within the network.
> NEW:
>    Since this document makes use of the exchange of RSVP messages
>    including a Notify message, the security threats discussed in [RFC4872]
>    also apply to this document.
>
>    Additionally, it may be possible to cause disruption to
>    traffic on one protecting LSP by targeting a link used by the primary
>    LSP of another, higher priority LSP somewhere completely different in
>    the network. For example, in Figure 1, assume that the preemption
>    priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] and
>    the protecting LSP [H,E,F,G,K] is being used to transport traffic.
>    If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted.
>    To prevent such an additional risk factor, it is
>    important not only to use security mechanisms as discussed in
>    [RFC4872] but also to preserve privacy of information about
>    protecting LSPs within the network.
>
> If you have any comments on the proposed changes, please let us know.
>
> Best regards,
>
> Jeong-dong (on behalf of co-authors)
>
>
>
> -----Original Message-----
> From:  "Ines Robles via Datatracker" <[e-mail]>
> To:      <[e-mail]>;
> Cc:      <[e-mail]>;   <[e-mail]>;   <
> [e-mail]>;
> Sent:  2021-10-09 (토) 07:20:42 (UTC+09:00)
> Subject: [Last-Call] Rtgdir last call review of
> draft-ietf-teas-gmpls-signaling-smp-07
>
> Reviewer: Ines Robles
> Review result: Has Nits
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
> Routing Directorate seeks to review all routing or routing-related drafts
> as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
> For more information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion
> or by
> updating the draft.
>
> Document: draft-ietf-teas-gmpls-signaling-smp-07
> Reviewer: Ines Robles
> Review Date: 2021-10-08
> IETF LC End Date: 2021-10-08
> Intended Status: Standards Track
>
> Summary:
>
> This document updates RFC 4872 to provide the extensions to the Generalized
> Multi-Protocol Label Switching (GMPLS) signaling to support the control of
> the
> Shared Mesh Protection.
>
> I did not find major issues, I have some questions/comments.
>
> Major Issues: Not found
> Minor Issues: Not found
> Nits:
>
> 1- Section 1: Which are the generic aspects of SMP signaling? Maybe it
> would be
> nice to add "Only the generic aspects (such as....) for signaling SMP..."
>
> 2- Section 4: "...resource sharing along nodes E, F and G..." Maybe it
> would be
> nice to add examples of resources that can be shared between the nodes E,
> F and
> G.
>
> 3- Section 4, page 5: Maybe? the intermediate node MUST send.... => the
> intermediate node (node E) MUST send...
>
> 4- Section 4, page 6: ... with a new sub-code "Shared resources
> unavailable"=>... with a new sub-code "Shared resources
> unavailable"(TBD1)...
>                       ... with a new sub-code "Shared resources available"
> =>
>                       ... with a new sub-code "Shared resources available"
>                       (TBD2)...
>
> 4- Section 4, page 6: Maybe it would be nice to associate with an example
> the
> five points outlined on how LSPs using SMP can be signaled in an
> interoperable
> fashion, e.g.
>  ..(1) the ability to identify a "secondary protecting LSP", from Figure 1,
>  which would be the secondary LSP "E,F,G"?
>
> 5- Section 7: The Security considerations do not explain clearly how the
> RFC4872-security-considerations applies to the Shared Mesh Protection and
> to
> the preemption priority.
>
> Thanks for this document,
>
> Ines.
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>