Bruno, One clarification: BTW, there may be two typos in the draft: > "R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the > payload." > :s/R-SID1/R-SID6 > > OLD: Replication State: > R2: <R-SID1->L12>" > > NEW: Replication State: > R2: <R-SID2, L12>" > > We did not want L12 to be mistaken as a SID and hence the "<R-SID2->L12>" convention (indicating push R-SID2 and send on interface L12) as compared to "<N-SID6, R-SID6>" where both elements are SIDs.
-Rishabh On Wed, Jul 15, 2020 at 2:04 PM Rishabh Parekh <risha...@gmail.com> wrote: > Bruno, > Replies inline @ [RP] > > > >> [Bruno] Agreed, in this specific case, you don't need the SID on the >> _packet_. >> - Still the PCE/configuration CLI/YANG need a way to identify this >> interface and it could be via a SID (e.g. both local adjacency SID and >> global nodes SID (assuming PHP) seems to work, depending on needs) >> - It seems to me that SR Policy draft is in the same situation, and they >> still call this an SR Policy. >> But that's a detail. >> >> [RP] We are on the same page. An explicit interface can be identified in > different ways. > > >> [...] >> >> > > >> > > ------- >> > > >> > > " o When the Active Segment [RFC8402] is the Replication SID. In >> this >> > > >> > > case, the operation for a replicated copy is CONTINUE." >> > > >> > > >> > > >> > > "CONTINUE" would mean that the segment is not a local segment. >> > > >> > > So the document really needs to clarify whether the replication >> > SID/segment is a local segment, or a global segment, or something new >> to be >> > defined.. >> > > >> > > >> > The CONTINUE operation just captures the label swap for each >> > replication, with just the Downstream Replication SID in the simplest >> > case. >> >> "CONTINUE: the active segment is not completed; hence, it remains >> active. In SR-MPLS, the CONTINUE operation is implemented as a SWAP >> of the top label [RFC3031]. In SRv6, this is the plain IPv6 >> forwarding action of a regular IPv6 packet according to its >> destination address." >> https://tools.ietf.org/html/rfc8402#section-2 >> >> 1) SR terminology >> Given that I think that we agreed that the replication segment is a local >> segment (i.e. local to one node), I don't see how it could continue once >> used. As we used it on the single node which understand it, it needs to be >> terminated (NEXT). >> >> 2) Data plane >> 2.a) SR-MPLS >> I don't see a label swap. I see a pop of the BSID/replication SID and a >> push of the list of SID in the SR-policy. As described in >> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-08#section-8.3 >> "Let us assume that headend H has a valid SR Policy P of Segment-List >> <S1, S2, S3> and BSID B. >> >> When H receives a packet K with label stack <B, L2, L3>, H pops B and >> pushes <S1, S2, S3> and forwards the resulting packet according to >> SID S1." >> >> 2.b) SRv6 >> Quoting RFC 8402 (above): "In SRv6, this is the plain IPv6 >> forwarding action of a regular IPv6 packet according to its >> destination address" >> I don't see how this can translate in a specific SR action (here >> "replication" on the replication node. ) But since there is no SRv6 >> specific text in the draft, it's hard to guess. >> > >> >> Note that my understanding seems to match your new text/illustration in >> appendix: there is no CONTINUE operation on a replication SID. Only NEXT >> operation: >> " R2, as Leaf, performs NEXT operation, pops R-SID2 label and delivers >> the payload." >> "R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the >> payload." >> "R7, as Leaf, performs NEXT operation, pops R-SID7 label and delivers the >> payload." >> >> > [RP] I see you point. We shall re-word the text around this area in a > future WG document (probably in rev 01). > > >> BTW, there may be two typos in the draft: >> "R6, as Leaf, performs NEXT operation, pops R-SID1 label and delivers the >> payload." >> :s/R-SID1/R-SID6 >> >> OLD: Replication State: >> R2: <R-SID1->L12>" >> >> NEW: Replication State: >> R2: <R-SID2, L12>" >> >> > [RP] Thanks for catching these. We will fix them in rev 00 of WG document. > > >> Thanks, >> Regards, >> --Bruno >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
