(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:risha...@gmail.com]
Sent: Thursday, July 16, 2020 4:46 AM
To: Xiejingrong (Jingrong) <xiejingr...@huawei.com>
Cc: Jeff Tantsura <jefftant.i...@gmail.com>; Dhruv Dhody
<dhruv.i...@gmail.com>; bruno.decra...@orange.com; spring@ietf.org; Alexander
Vainshtein <alexander.vainsht...@rbbn.com>
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
