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

From: Ines Robles via Datatracker <[email-masked]>
Date: Fri, 08 Oct 2021 15:19:30 -0700

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.

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Fri, 15 Oct 2021 18:21:00 +0900 (KST)

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" <[email-masked]>
To:      <[email-masked]>; 
Cc:      <[email-masked]>;   <[email-masked]>;   <[email-masked]>; 
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,

Summary:

Major Issues: Not found
Minor Issues: Not found
Nits:

Ines.

-- 
last-call mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/last-call

---

From: Ines Robles <[email-masked]>
Date: Fri, 15 Oct 2021 12:39:34 +0300

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 <[email-masked]> wrote:

> 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:
> Cc:      <[email-masked]>;   <[email-masked]>;   <
> [email-masked]>;
> =>

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Mon, 18 Oct 2021 16:24:48 +0900 (KST)

Hi,&nbsp;

A new version of draft-ietf-teas-gmpls-signaling-smp has been uploaded at:
https://www.ietf.org/archive/id/draft-ietf-teas-gmpls-signaling-smp-08.txt&nbsp;
(A diff from the previous version is available at:&nbsp;
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-signaling-smp-08)&nbsp;

This document reflects the review comments from Tom Petch and Ines Robles. We don't have any outstanding issues to address at this stage.

The co-authors of this draft would be grateful if this document could be taken to the next level

Best regards,

-----Original Message-----
From: "Ines Robles" &lt;[email-masked]&gt;
To: "Jeong-dong Ryoo" &lt;[email-masked]&gt;;
Cc: &lt;[email-masked]&gt;; &lt;[email-masked]&gt;; &lt;[email-masked]&gt;; &lt;[email-masked]&gt;;
Sent: 2021-10-15 (금) 18:42:35 (UTC+09:00)
Subject: Re: [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07

Dear&nbsp;Jeong-dong,

Best Regards,

Ines.&nbsp;

On Fri, Oct 15, 2021 at 12:21 PM Jeong-dong Ryoo &lt;[email-masked] mailto:[email-masked]&gt; 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 ofa shared mesh protection (SMP) mechanismNEW:TU-T Recommendation G.808.3 [G808.3] defines the generic aspects ofa shared mesh protection (SMP) mechanism, which are not specific toa particular network technology in terms of architecture types,preemption principle, and path monitoring methods, etc.&nbsp; &nbsp;#2: Add the following new sentence after the sentence you indicated:&nbsp;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&nbsp; &nbsp; &nbsp; called the "secondary LSP") used to recover another primary&nbsp; &nbsp; &nbsp; working LSP (hereby called the "protected LSP")NEW:(1) the ability to identify a "secondary protecting LSP"&nbsp; &nbsp; &nbsp; (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1,&nbsp; hereby&nbsp; &nbsp; &nbsp; called the "secondary LSP") used to recover another "primary&nbsp; &nbsp; &nbsp; working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1,&nbsp;&nbsp; &nbsp; &nbsp; hereby called the "protected LSP").#5:OLD:&nbsp; &nbsp;The security threats discussed in [RFC4872] also apply to this&nbsp; &nbsp;document.&nbsp; Additionally, it may be possible to cause disruption to&nbsp; &nbsp;traffic on one protecting LSP by targeting a link used by the primary&nbsp; &nbsp;LSP of another, higher priority LSP somewhere completely different in&nbsp; &nbsp;the network.&nbsp; To prevent such an additional risk factor, it is&nbsp; &nbsp;important not only to use security mechanisms as discussed in&nbsp; &nbsp;[RFC4872] but also to preserve privacy of information about&nbsp; &nbsp;protecting LSPs within the network.NEW:&nbsp; &nbsp;Since this document makes use of the exchange of RSVP messages&nbsp; &nbsp;including a Notify message, the security threats discussed in [RFC4872]&nbsp; &nbsp;also apply to this document.&nbsp;&nbsp; &nbsp;Additionally, it may be possible to cause disruption to&nbsp; &nbsp;traffic on one protecting LSP by targeting a link used by the primary&nbsp; &nbsp;LSP of another, higher priority LSP somewhere completely different in&nbsp; &nbsp;the network. For example, in Figure 1, assume that the preemption&nbsp; &nbsp;priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] and&nbsp; &nbsp;the protecting LSP [H,E,F,G,K] is being used to transport traffic.&nbsp; &nbsp;If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted.&nbsp; &nbsp;To prevent such an additional risk factor, it is&nbsp; &nbsp;important not only to use security mechanisms as discussed in&nbsp; &nbsp;[RFC4872] but also to preserve privacy of information about&nbsp; &nbsp;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:&nbsp; "Ines Robles via Datatracker" &lt;[email-masked] mailto:[email-masked]&gt;To:&nbsp; &nbsp; &nbsp; &lt;[email-masked] mailto:[email-masked]&gt;;Cc:&nbsp; &nbsp; &nbsp; &lt;[email-masked] mailto:[email-masked]&gt;;&nbsp; &nbsp;&lt;[email-masked] mailto:[email-masked]&gt;;&nbsp; &nbsp;&lt;[email-masked] mailto:[email-masked]&gt;;Sent:&nbsp; 2021-10-09 (토) 07:20:42 (UTC+09:00)Subject: [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07Reviewer: Ines RoblesReview result: Has NitsHello,I have been selected as the Routing Directorate reviewer for this draft. TheRouting Directorate seeks to review all routing or routing-related drafts asthey pass through IETF last call and IESG review, and sometimes on specialrequest. The purpose of the review is to provide assistance to the Routing ADs.For more information about the Routing Directorate, please seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirAlthough these comments are primarily for the use of the Routing ADs, it wouldbe helpful if you could consider them along with any other IETF Last Callcomments that you receive, and strive to resolve them through discussion or byupdating the draft.Document: draft-ietf-teas-gmpls-signaling-smp-07Reviewer: Ines RoblesReview Date: 2021-10-08IETF LC End Date: 2021-10-08Intended Status: Standards TrackSummary:This document updates RFC 4872 to provide the extensions to the GeneralizedMulti-Protocol Label Switching (GMPLS) signaling to support the control of theShared Mesh Protection.I did not find major issues, I have some questions/comments.Major Issues: Not foundMinor Issues: Not foundNits:1- Section 1: Which are the generic aspects of SMP signaling? Maybe it would benice 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 benice to add examples of resources that can be shared between the nodes E, F andG.3- Section 4, page 5: Maybe? the intermediate node MUST send.... =&gt; theintermediate node (node E) MUST send...4- Section 4, page 6: ... with a new sub-code "Shared resourcesunavailable"=&gt;... with a new sub-code "Shared resources unavailable"(TBD1)...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ... with a new sub-code "Shared resources available" =&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ... with a new sub-code "Shared resources available"&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (TBD2)...4- Section 4, page 6: Maybe it would be nice to associate with an example thefive points outlined on how LSPs using SMP can be signaled in an interoperablefashion, e.g.&nbsp;..(1) the ability to identify a "secondary protecting LSP", from Figure 1,&nbsp;which would be the secondary LSP "E,F,G"?5- Section 7: The Security considerations do not explain clearly how theRFC4872-security-considerations applies to the Shared Mesh Protection and tothe preemption priority.Thanks for this document,Ines.--last-call mailing [email-masked] mailto:[email-masked]://www.ietf.org/mailman/listinfo/last-call https://www.ietf.org/mailman/listinfo/last-call