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

[Rishabh Parekh <[e-mail]>]

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
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-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