Re: [spring] Understanding the replication draft

[Rishabh Parekh <[e-mail]>]

Jingrong,
Your understanding is essentially correct. Think of a Replication function
at a node represented by the function portion of SRV6 SID with Replication
context either in arg or in the function itself. In the simplest case,as
you illustrated, replication to a downstream node is just constructing a
SRv6 SID with downstream locator + downstream replication function +
replication context (optional) and putting it in the DA of IPv6 packet. If
the downstream node is remote and the packet has to take a specific path
(not the IGP shortest path) to the node, the downstream replication SID
will be somewhere in SRH.

-Rishabh

On Thu, Jul 16, 2020 at 3:45 AM Xiejingrong (Jingrong) <
[e-mail]> wrote:

> (Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402
> are used and are the key to understand, so I would  expect points from the
> SPRING WG).
>
>
>
> Hi Rishabh,
>
>
>
> Thanks for your response!
>
>
>
> Let me try to understand the applicability of SRv6 first, and move to the
> other points afterwards.
>
>
>
> I read the appendix A.1 in <draft-voyer-pim-sr-p2mp-policy-02>, and still
> have difficulty to understand the processing of multicast packet.
>
>
>
>    o  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
>
>       delivers the payload.  For replication to R6, R2 performs a PUSH
>
>       operation of N-SID6, to send <N-SID6,T-SID1> label stack to R3.
>
>       R3 is the penultimate hop for N-SID6; it performs penultimate hop
>
>       popping, which corresponds to the NEXT operation and the packet is
>
>       then sent to R6 with <T-SID1> in the label stack.  For replication
>
>       to R7, R2 performs a PUSH operation of N-SID7, to send
>
>       <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
>
>       towards R7.  R4 is the penultimate hop for N-SID6; it performs
>
>       penultimate hop popping, which corresponds to the NEXT operation
>
>       and the packet is then sent to R7 with <T-SID1> in the label
>
>       stack.
>
>
>
> When considering SRv6, The “PUSH operation of N-SID6” and the “PUSH
> operation of N-SID7” are not clear to me.
>
>
>
> Seems that <N-SID6,T-SID1> and <N-SID7,T-SID1> are only for SR-MPLS, where
> T-SID1 is locally meaningful, and N-SID is globally reachable.
>
>
>
> I try to understand what’s the shape of each packet – pkt12, pkt23, pkt36,
> pkt25, pkt47 in this example when using SRv6.
>
>
>
>                     R3----(pkt36)----R6
>
>                     /
>
>                  (pkt23)
>
>                   /
>
> R1----(pkt12)----R2----(pkt24)----R4----(pkt47)----R7
>
>
>
> And this is my assumption:
>
> Pkt12: (SA=R1, DA=R2_RepSID) (C-multicast pkt)
>
> Pkt23/Pkt36: (SA=R1, DA=R6_RepSID) (C-multicast pkt)
>
> Pkt24/Pkt47: (SA=R1, DA=R7_RepSID) (C-multicast pkt)
>
>
>
> Is that correct ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Rishabh Parekh [mailto:[e-mail]]
> *Sent:* Thursday, July 16, 2020 4:46 AM
> *To:* Xiejingrong (Jingrong) <[e-mail]>
> *Cc:* Jeff Tantsura <[e-mail]>; Dhruv Dhody <
> [e-mail]>; [e-mail]; [e-mail];
> Alexander Vainshtein <[e-mail]>
> *Subject:* Re: [spring] Understanding the replication draft
>
>
>
> Jingrong,
>
>
>
> Replies inline.
>
>
>
> 1)       About the distinction of Replication-ID and Replication-SID, and
> their usage.
>
> If there is an SID block specially reserved for the P2MP Transport on each
> of the Replication Node, and such SID block (on each Replication Node) is
> advertised through west-east protocol like IGP/BGP,
>
> and then the north-south controller (like PCE) can use the
> “Replication-ID” and “Node-ID” only, but don’t need to use
> “Replication-SID” when populating the “Tree” information to each
> “Replication Node” ?
>
> In that way, the Controller doesn’t need to allocate (and manage) each of
> the Replication-SID (Say 1000 Replication-SID)  for  each Replication Node
> (Say 100 nodes).
>
>
>
> As we try to make the distinction clear in the draft, Replication segment
> is a logical segment that needs to be explicitly instantiated on the node
> either by PCE or by some other mechanism (maybe local config?). The
> Replication SID has to be assigned when the Replication segment (with a
> Replication-ID) is created on the node. Note Replication Segments can be
> created and deleted over time. and So, there is no pre-allocated block of
> Replication SIDs that can be announced in IGP or BGP. Effectively, the
> entity managing Replication segments has to manage the Replication SIDs.
>
>
>
> 2)       About the Replication Segment illustration.
>
> The rev-04 add a section “Illustration of a Replication Segment” in
> appendix, it is very clear and useful.
>
> To me, the “Replication State” is more like a “forwarding state”, and I
> think it will be helpful to understand the whole solution if:
>
> a) there is a description/Illustration about the building procedure of the
> “forwarding state” ---- What’s the information each Replication Node
> receives from the controller, and how each node builds its own forwarding
> state.
>
> b) there is a description/Illustration about the processing of multicast
> packet on the whole path of the P2MP tree.
>
>
>
> Illustrations of how packets and handed on a P2MP tree built by stitching
> Replication segments have been added in latest revision 02 of PIM WG draft:
> https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
>
> We have drafts on PCEP and BGP protocol extensions to instantiate
> Replication segments.
>
>
>
>
>
> 3)       About the applicability of SR-MPLS and SRv6.
>
> The rev-04 says “Replication segments apply equally to both SR-MPLS and
> SRv6 instantiations of Segment Routing.”.
>
> I am not sure if this document will cover SRv6 as well, but if it does,
> then I would like to see the same level of consideration as SR-MPLS.
>
>
>
>
>
>  Yes, we will have the same level of details for SRv6 Replication too.
>
>
>
> -Rishabh
>