Skip to main content

GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-12

Yes


No Objection

Alvaro Retana
Andrew Alston
Erik Kline
Murray Kucherawy
Zaheduzzaman Sarker

No Record

Martin Duke

Summary: Has enough positions to pass.

John Scudder Yes

Comment (2022-04-06 for -11)
I just noticed that RFC 4873 has:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|   Reserved    | Seg.Flags |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But this draft has:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|   Reserved    | Seq.Flags |   Reserved    | Preempt Prio  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Seg" with a G got changed into "Seq" with a Q. I assume that was a typo and should be corrected.

Alvaro Retana No Objection

Andrew Alston No Objection

Erik Kline No Objection

Francesca Palombini No Objection

Comment (2022-04-05 for -11)
Thank you for the work on this document.

Only one comment: I had the same reaction as Paul, I believe it would have been good to create IANA registries for the LSP (Protection Type) Flags, although that is really a comment on RFC 4872 (which by the way already uses what I consider IANA-compliant terminology by stating "The following values are defined.  All other values are reserved."). But since this is a general comment, which can make more sense if other flags are expected to be defined in the future, I leave it up to the working group and AD to make the best choice.

Francesca

Lars Eggert No Objection

Comment (2022-04-05 for -11)
Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
needed? What text is copied from an older RFC?

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/sVz7p-OqBMRBhxHaqKo9667CRd8).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Section 4. , paragraph 8, nit:
> hase several secondary LSPs in an efficient manner, and (5) the capability to
>                             ^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.5. , paragraph 2, nit:
> does not need the shared resources any more. Upon receipt of this Notify mess
>                                    ^^^^^^^^
Did you mean the adverb "anymore"?

Section 5.6. , paragraph 3, nit:
> t to 0x04 (1:N Protection with Extra- Traffic), 0x08 (1+1 Unidirectional Pro
>                                ^^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Murray Kucherawy No Objection

Paul Wouters No Objection

Comment (2022-04-04 for -11)
I came in a bit late as incoming AD, but happy to see that most review comments were addressed. I think the wording about the Reserved Field changes could be improved a little (there are 4 different Reserved fields, although only one is 16 bit in size), although it is clear enough to understand which field was meant.

It would have been nice if the "Notification and Operational Bits" had been an IANA registry, so it could have been updated more clearly without repeating a lot of text from the RFC being updated. Especially if more bits are going to be used in the future. But it is a bit late for that now as it would require more updated text for the generic handling of the bits along with fields in the IANA registry for the bit specific behaviours (eg the setting of N and O bit)

Robert Wilton (was Discuss) No Objection

Comment (2022-04-27)
Thanks for addressing my discuss in -12.

Roman Danyliw No Objection

Comment (2022-04-06 for -11)
Thank you to David Mandelberg for the SECDIR review.

** Section 6.3

   In order to indicate the SMP preemption priority, the 16-bit Reserved
   field [RFC4873] of the PROTECTION object is redefined.  The last 32
   bits in the PROTECTION object defined in [RFC4873] are updated as
   follows:


I had trouble following the references in the above text to understand what exactly was being updated.  John Scudder help me understand the follow:

RFC 4872 reserved a 32-bit field in the PROTECTION object header. Subsequently, RFC 4873 allocated several fields from that field, and left the remainder of the bits reserved. This specification further allocates the preemption priority field from those formerly-reserved bits.

I’d recommend included text to this effect.

** Concur with Paul and Francesca that a registry for LSP (Protection Type) Flag would be helpful.

** Section 8.

For this reason, 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.

How would one "preserve the privacy of information about protecting LSPs"?  Is this equivalent to acknowledging that detailed knowledge of a network's topology can help an attacker better target or improve the efficacy of an attack?

Warren Kumari No Objection

Comment (2022-04-06 for -11)
I'd like to thank the authors for this document -- I found it a useful, well written, and easy read.

I'd especially like to thank Dan Romascanu for his OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-teas-gmpls-signaling-smp-10-opsdir-lc-romascanu-2022-02-01/), and for the subsequent conversation. 
The text which was added to the Introduction section improved the document.

Zaheduzzaman Sarker No Objection

Éric Vyncke No Objection

Comment (2022-04-04 for -11)
Thank you for the work put into this document. 

Please find below a very minor non-blocking COMMENT point, feel free to ignore.

Special thanks to Vishnu Beeram for the shepherd's write-up including the WG consensus. 

I hope that this helps to improve the document,

Regards,

-éric

## Section 1

While slightly out of context of this document, the operational differences between between SMP and SMR would have been a plus. The last sentence of section 3 would have been better in this introduction IMHO, but this is a matter of taste ;-)

Martin Duke No Record