Eric, Please find my comments @ [RP2] On Wed, Aug 2, 2023 at 8:11 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote:
> Thank you, Rishabh, for your quick reply. I had a look at the revised -16. > > > > As you know, all my points were and are just non-blocking comments, see > below for EV> > > > > Regards > > > > -éric > > > > *From: *Rishabh Parekh <risha...@gmail.com> > *Date: *Monday, 31 July 2023 at 22:05 > *To: *Eric Vyncke <evyn...@cisco.com> > *Cc: *The IESG <i...@ietf.org>, " > draft-ietf-spring-sr-replication-segm...@ietf.org" < > draft-ietf-spring-sr-replication-segm...@ietf.org>, " > spring-cha...@ietf.org" <spring-cha...@ietf.org>, "spring@ietf.org" < > spring@ietf.org>, "Mankamana Mishra (mankamis)" <manka...@cisco.com> > *Subject: *Re: [spring] Éric Vyncke's No Objection on > draft-ietf-spring-sr-replication-segment-15: (with COMMENT) > > > > Eric, > > I have addressed your comments and nits in latest revision of draft. > > > > Thanks, > > -Rishabh > > > > On Fri, Jun 30, 2023 at 9:45 AM Rishabh Parekh <risha...@gmail.com> wrote: > > Eric, > > > > Please find my responses below. > > > > Thanks, > > -Rishabh > > > > On Wed, Jun 28, 2023 at 2:17 AM Éric Vyncke via Datatracker < > nore...@ietf.org> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-spring-sr-replication-segment-15: No Objection > > > > > # COMMENTS > > ## Section 1 > > The reader would probably welcome use case of this protocol: is it for > multicast ? or more like a span port for monitoring/troubleshooting ? > > Waiting until section 3 is not really reader friendly. > > > > [RP] I will add some text about uses cases in the Introduction in the next > revision. > > > > EV> Yes, I saw the section 1.2 even if, to be honest, if you are not an > expert in the domain, then it is complex to read and understand > > EV> May I also suggest to move the use case before the terminology ? > > [RP2] The Use Case sub-section does use some terms defined in Terminology Section (like Root, Leaf). IMO, it might be better to leave it as it is now. > > > ## Section 2.2 > > In the 2nd paragraph, is the segment left field also decremented ? > > > > [RP] No, the SL in SRH is not decremented because the Downstream > Replication SID that is put in the IPv6 DA field for a replication comes > from the Replication State, not SRH. > > > > EV> so the SID list is unchanged and the next node will process it again, > this does make sense indeed if it goes down a replication tree > > [RP2] There is no need for a SID list to steer a packet using a Replication segment. As I have tried to explain, a Replication node uses an incoming local Replication SID (in DA of IPv6 header), to lookup a Replication state. Each branch (replication) in that state has a downstream Replication SID, relevant at the downstream child node, and an optional segment list (in case the replicated packet has to be steered to a remote downstream node on a specific path). If there is a segment list on a branch, then a H.Encaps (i.e. one more IPv6 encapsulation) is used to steer the replicated packet on a specific path to the downstream node. This is illustrated in SRv6 example in Appendix A.2 .The only use case of a SID list (along with Replication SID in IPv6 DA), is for "context" SID used to process the payload (that was encapsulated at Root node) at a Leaf/Bud Node. In this case, the transit Replication nodes do not process these "context" SIDs. This is described in SRv6 pseudo-code and Notes in Section 2.2.1.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
