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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux