Subject: [Gen-art] Genart last call review of draft-ietf-teas-gmpls-signaling-smp-10

From: Dale Worley via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 19:10:06 -0800

Reviewer: Dale Worley
Review result: Ready with Nits

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-teas-gmpls-signaling-smp-10
Reviewer:  Dale R. Worley
Review Date:  2020-02-02
IETF LC End Date:  2020-02-03
IESG Telechat date:  not known

Summary:

    This draft is basically ready for publication, but has nits that
    should be fixed before publication.

Minor technical issue:

   These end nodes, in case
   of a failure of the working LSP, MUST avoid trying to switch the
   traffic to these protection LSPs that have been configured to use the
   shared resources and try switching the traffic to other protection
   LSPs, if available.

It seems like this behavior is guaranteed without this specific
requirement:  The node that detects the resource failure will signal
"Shared resources unavailable" to the end nodes of any lower-priority
LSPs that use the failed resources.  Thus, the end nodes will not try
to switch the traffic of the working LSP to any of "these LSPs"
(lower-priority LSPs).  And consequently, they will try to switch the
traffic to other protection LSPs.

Indeed, it seems like the intermediate node should signal "Shared
resources unavailable" to the end nodes of all protecting LSPs that
use the failed resource, regardless of the LSPs' priorities -- all of
them are non-functional.

I suspect there is some complexity here that I do not understand.  It
may be worth describing that more explicitly.

Nits/editorial comments:

1.  Introduction

   The recovery resources for the
   protecting LSPs are pre-reserved during the provisioning phase, and
   explicit restoration signaling is required to activate (i.e., commit
   resource allocation at the data plane) a specific protecting LSP
   instantiated during the provisioning phase.

At first, I misunderstood this to have the final "during the
provisioning phase" modify "explicit restoration signaling is
required".  After re-reading it, I think that cannot be grammatically
correct, and "during the provisioning phase" is part of "instantiated
during the provisioning phase".  But my confusion could have been
avoided if the text was amended to "... a specific protecting LSP
*that* was instantiated during the provisioning phase."

   o  updates the definition of the 16-bit Reserved field [RFC4873] of
      the PROTECTION object to take the new SMP type into account (see
      Section 6.3).

At first sight, this doesn't make sense -- how does adding SMP change
how the bits of an unused field are used?  The concept is that SMP
signaling *uses* that field.  So it would be clearer to say e.g.

   o  updates the definition of the 16-bit Reserved field [RFC4873] of
      the PROTECTION object to allocate 8 bits to signal the SMP
      preemption priority (see Section 6.3).

2.  Conventions Used in This Document

   In addition, the reader is assumed to be familiar with the
   terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372
   [RFC6372].

presumably for consistency you want to say

   In addition, the reader is assumed to be familiar with the
   terminology used in RFC 4872 [RFC4872], RFC 4426 [RFC4426], and RFC 6372
   [RFC6372].

Although there seems to be a style question, as the forms "RFC xyzw
[RFCxyzw]" and "[RFCxyzw]" (both as nouns) are both used frequently in
this document.  Resolving this is probably something the Editor can
handle best.

3.  SMP Definition

   Pre-configuring but not activating a
   protecting LSP allows the common link and node resources in the
   protecting LSP to be shared by multiple working LSPs that are
   physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.)
   disjoint.

If I understand this correctly, the point is that multiple working
LSPs may have protecting LSPs that are not disjoint, on the assumption
that only one of the protecting LSPs will be active at a time.  But
this wording doesn't seem to mean that to me.  Perhaps:

   Pre-configuring but not activating
   protecting LSPs allows link and node resources to be shared by
   the protecting LSPs of multiple working LSPs (that are
   physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.)
   disjoint and thus unlikely to fail simultaneously).

Perhaps that could be simplified to:

   Pre-configuring but not activating
   protecting LSPs allows link and node resources to be shared by
   the protecting LSPs of multiple working LSPs (that are
   themselves disjoint and thus unlikely to fail simultaneously).

4.  Operation of SMP with GMPLS Signaling Extension

At the end of section 4, it seems desirable to further describe the
processing which it seems to me must happen:  If F fails to allocate
the protection resource, it sends a failure message to E, which causes
E to remove the protection allocation, and then send a failure message
to A.  And so on for further nodes in the LSP.

5.  GMPLS Signaling Extension for SMP

   The following subsections detail how LSPs using SMP can be signaled
   in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC
   3473 [RFC3473]).  This includes:

As the first sentence is constructed, the "This" in the second
sentence doesn't have a clear referent.  The most plausible referent
is the GMPLS RSVP-TE extensions, but those do not "include" point (5)
in the following link, since the extensions aren't directly involved
in activation.  I think the sense would be improved if "This includes"
was replaced by "This signaling [or method] system enables".

5.1.  Identifiers

   The LSP ID, however,
   MUST be different to distinguish between the protected LSP carrying
   normal traffic and the secondary LSP.

You probably want to omit "carrying normal traffic" as it's not clear
what "normal" traffic is from the preceding text in the document.  It
seems that it could only mean "traffic being carried by a protected
LSP", and in that case it's redundant.  Although perhaps "normal
traffic" is a known term.

5.3.  Signaling Secondary LSPs

   Support for extra traffic in SMP is for further study.  Therefore,
   mechanisms to set up LSPs for extra traffic are also for further
   study.

In the second sentence, you probably want to use the conventional
phrase "are outside the scope of this document" in place of "are also
for further study".

5.4.  SMP Preemption Priority

   In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE
   object can be used by GMPLS to control LSP preemption, but, they are
   not used by the APS to resolve the competition among multiple
   protecting LSPs.

This is probably clear to people who fully understand all of these
protocols.  But naively, I see that in SMP, GMPLS does not do LSP
preemption.  Then the interpretation is that GMPLS distributes the
Setup and Holding priorities, which APS then uses to resolve
competition that arises during preemption.  But the last clause states
that APS does not use those priorities.  I suspect that "In SMP,
... can be used by GMPLS to control LSP preemption" doesn't mean what
I think it does (that is, control how APS does preemption).  Perhaps
there is a better way of phrasing it.

   When resource competition among
   multiple protecting LSPs occurs, the APS protocol will use their
   priority values to resolve the competition.

Since this section introduces the priority field, it's worth stating
here "A lower value has a higher priority." or appending "..., with a
lower value indicating a higher priority.".

   In SMP, a preempted LSP MUST NOT be torn down.

Perhaps "torn down" has a specific meaning, but naively, a preempted
LSP has its resources de-allocated, and so is "torn down".  I think
you could make this clearer as

   In SMP, a preempted LSP MUST NOT be torn down even after its
   resources have been deallocated.

But perhaps there is a more specific term that could be used instead
of "torn down".

5.5.  Notifying Availability of Shared Resources

   When the shared resources become unavailable, including a case of the
   shared resources failure, [...]

Perhaps clearer as

   When any shared resources become unavailable for any other reason
   (e.g. failure of the shared resources), [...]

5.6.  SMP APS Configuration

   In order to allow exchange of APS protocol messages, an APS channel
   has to be configured between adjacent nodes along the path of the SMP
   protecting LSP.  This should be done before any SMP protecting LSP
   has been set up by other means than GMPLS signaling which are
   therefore outside the scope of this document.

This is unclear to me.  Does "by other means than GMPLS signaling"
modify "SMP protecting LSP has been set up", as it appears to?  It
seems to me to be likely that the meaning is

   This is done by other means than GMPLS signaling, before any SMP
   protecting LSP has been set up.  This means is outside the scope of
   this document.

--

   Therefore, additional requirements
   for APS configuration are outside the scope of this document.

I think this can be clarified as

   Therefore, there are likely additional requirements
   for APS configuration which are outside the scope of this document.

10.  Contributor

   The following person contributed significantly to the content of this
   document and should be considered as a co-author.

This is an unusual statement.  Presumably there is a good reason the
expedient of listing Yuji Tochio as a co-author has not been taken.

[END]

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Wed, 09 Feb 2022 15:47:18 +0900 (KST)

Hi Dale,

Thank you for your detailed review and many valuable suggestions.

Please find responses inline below starting with [JR].

Best regards,

Jeong-dong

-----Original Message-----
From:  "Dale Worley via Datatracker" <[email-masked]>
To:      <[email-masked]>; 
Cc:      <[email-masked]>;   <[email-masked]>;   <[email-masked]>; 
Sent:  2022-02-03 (목) 12:11:06 (UTC+09:00)
Subject: [Last-Call] Genart last call review of draft-ietf-teas-gmpls-signaling-smp-10

Reviewer: Dale Worley

Summary:

Minor technical issue:

   These end nodes, in case

[JR] The first paragraph in Section 5.5 is for a lower priority protecting LSP that is being preempted, and the second paragraph, which contains the text you quoted, is for any lower priority protecting LSPs that are affected by the unavailable shared resources. As you expressed, I also agree with you that the current text needs to be described more explicitly.  I propose the following update for the  second paragraph: 

OLD:
   When the shared resources become unavailable, including a case of the
   shared resources failure, the same Notify message MUST also be
   generated by the intermediate node to all the end nodes of the
   protecting LSPs that have lower SMP preemption priorities than the
   one that has occupied the shared resources.  These end nodes, in case
   of a failure of the working LSP, MUST avoid trying to switch the
   traffic to these protecting LSPs that have been configured to use the
   shared resources and try switching the traffic to other protection
   LSPs, if available.

NEW:
   When a protecting LSP occupies the shared resources and they become
   unavailable, the same Notify message MUST also be
   generated by the intermediate node to all the end nodes of the
   protecting LSPs that have lower SMP preemption priorities than the 
   one that has occupied the shared resources. In case the shared resources 
   become unavailable due to a failure, the same Notify message MUST be 
   generated by the intermediate node to all the end nodes of the protecting 
   LSPs that have been configured to use the shared resources. 
   These end nodes, in case of a failure of the working LSP, MUST avoid 
   trying to switch the traffic to these protection LSPs that have been 
   configured to use the shared resources and try switching the traffic to 
   other protecting LSPs, if available.

Nits/editorial comments:

1.  Introduction

[JR] Sorry for the confusion. It will be corrected as you suggested.

[JR] Indeed, it doesn't make any sense. We forgot to correct it after we did copy & paste the text above. It was a mistake and will be corrected as you suggested.

[JR] The form "RFC XXXX [RFCXXXX]" is used when RFC XXXX is referenced first, and after that, the form "[RFCXXXX]" is used in the rest of the document consistently. This style was suggested by one IETF expert when I first wrote an RFC. Since then, I have stuck to this way. Yes, the Editor can handle it best. I will leave it as is for the time being.

3.  SMP Definition

[JR] Yes, your text reads better. 

[JR] Current SMP APS protocol has not defined a failure message sent by an intermediate node to deallocate the resources. Instead, the end node is supposed to start a procedure to release the resources.  The following text can be added at the end of Section 4:
   If node E fails to allocate the protection resource, it MUST send a message to notify node A (see Section 5.5). 
   Then, node A will stop bridging and selecting the traffic to/from the protecting LSP and proceed with the 
   procedure of removing the protection allocation according to the APS protocol.

[JR] It will be corrected as you suggested. Thanks.

5.1.  Identifiers

   The LSP ID, however,

[JR] The term came from the other SDO's language. "carrying normal traffic" will be omitted as you suggested. In the meantime, there are a few other places where "normal traffic" is used. They will be corrected. 

[JR] It will be corrected as you suggested.

[JR] Indeed, the current text is miswritten and misleading. "In SMP," should be removed.  

[JR] Yes, the sentence you suggested will be added. 

[JR] I couldn't come up with a more specific term. Maybe a generic term might be used instead as there is an appended phrase. How about the following (I am not sure if "terminate" can be generic here):
   In SMP, a preempted LSP MUST NOT be terminated even after its 
   resources have been deallocated.  

Perhaps clearer as

[JR] Please, see my previous comment and text proposal in "Minor technical issue". 

--

[JR] Thank you for the text suggestion. Your text reads better and will be incorporated.

10.  Contributor

[JR] He refused to put his name on the front page. The reason I was told was that there were limits to the extent of his role and participation in different SDOs due to his company's internal policy. 

[END]

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