Re: [pim] [spring] Understanding the replication draft

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Rishabh,

Thanks a lot for your confirmation!
Hopefully these clarifications could be reflected in the upcoming update (when they will be WG documents in SPRING and PIM, and congratulations!).
I look forward to further discussions after that.

Thanks
Jingrong

From: Rishabh Parekh [mailto:[e-mail]]
Sent: Friday, July 17, 2020 12:42 AM
To: Xiejingrong (Jingrong) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [spring] Understanding the replication draft

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]<mailto:[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]<mailto:[e-mail]>]
Sent: Thursday, July 16, 2020 4:46 AM
To: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>
Cc: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Alexander Vainshtein <[e-mail]<mailto:[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