Re: [Last-Call] [spring] Rtgdir last call review of draft-ietf-spring-sr-replication-segment-10

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

 



Many thanks Rishabh for addressing my comments.

BR,
Ines.

On Wed, Dec 7, 2022 at 2:29 AM Rishabh Parekh <rishabhp@xxxxxxxxx> wrote:
Ines,

Please find my replies inline below @ [RP]


1- Requirements Language section should add RFC 8174, i.e. "...."NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here."

[RP] We will update in the next revision.
 
2- There is no terminology section. It would be nice to have a terminology
section where inform to the reader which document to read to understand the
terminology not defined in the document e.g. "..the operations NEXT, PUSH are
defined in RFC8402 and the POP operation in RFC...; H.Encaps.Red is defined in
....."

[RP] We can add a terminology section to define new terms introduced in this draft, but I am not sure if we can list all the terms defined in other documents referenced in this draft.
 
3- Page 3: "Replication-ID can be a 32-bit number, but it can be extended or
modified as required... " -> to which limit can be extended?
 
[RP] There is no "limit" as such. What the document means is that Replication-ID can be defined by the use case of Replication segments. For example, SR P2MP Policy draft (Section 3) uses <Root, Tree-ID> policy identifier as Replication-ID of replication segments that are instantiated for a P2MP policy.


4- Question: since the replication state of the nodes can change over time. Is
it possible that in some particular circumstances this change could trigger a
loop in the replication segment? or this is not possible?
 
[RP] Replication within a single replication segment is loop free as long as SIDs in segment list used to guide a packet from Replication node to dowstrean modes are loop free. When replication segments are stitched together for SR P2MP policy, it is upto the controller (PCE) to ensure the P2MP tree is loop free.


5- The security considerations states: "There are no additional security risks
introduced by this design". Additional to what features? This is not clear to
me. Perhaps it would be nice to rephrase it to something like: "The security
considerations outlined in RFC 8402, RCF... also applies to this document"?
 
[RP] Sure. We will rephrase the text in the next revision.

Nits/editorial comments:

6- Page 7: all the Must and SHOULD... => all the MUST and SHOULD?
[RP] If you are referring to the introductory text of Implementation Status section, it was taken verbatim from Section 2.1 of RFC 7942 where these words are not capitalized and I don't think they need to be since this section is to be removed before publication.

7- Page 11- Figure 1: It would be nice if the caption of the figure could be
descriptive
[RP]  I agree - "Figure 1: Figure 1" does not describe anything :) Will fix in the next revision. 

8- Page 13 Paragraph 8 and 9: End.Replcate => End.Replicate?
[RP] We will fix the typos in the next revision.



 Thanks for a thorough review,
-Rishabh
-- 
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