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
