Re: [spring] draft-voyer-spring-sr-replication-segment-03

[Rishabh Parekh <[e-mail]>]

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.
>
>