Hi Fan,
Sorry for the late response. Please see zzh> below.
From: Yangfan (IP Standard) <shirley.yang...@huawei.com>
Sent: Monday, May 17, 2021 9:20 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; 'Rishabh Parekh'
<risha...@gmail.com>
Cc: Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; 'Rishabh Parekh
(riparekh)' <ripar...@cisco.com>; 'Arvind Venkateswaran (arvvenka)'
<arvve...@cisco.com>; 'spring@ietf.org' <spring@ietf.org>
Subject: RE: [spring] RE: Comments on draft-geng-spring-sr-redundancy-protection
[External Email. Be cautious of content]
Hi Jeffrey,
To summarize the discussions a bit, I have two questions and hope to hear your
comments and clarifications.
Q1: Are there any questions for clarifications or open issues with the current
solution of redundancy-SID+Merging-SID+redundancy policy? If so, we would like
to clarify them first.
Zzh> No.
Q2:
Figure 1 in draft-geng-spring-sr-redundnacy-protection is the typical topology
for Redundancy Protection in SR domain, as shown below.
ingress------A (R)-------B-------D(M)-------egress
+------C------------+
+----E-------+
Could you please explain how exactly Tree-SID solution is used in data plane
for redundancy protection? For example, how the SR SID List is assigned, how
the packet is encapsulated and forwarded from R1 to R2 in data plane, how
Tree-SID and Replication SID are configured on network nodes, etc.
Zzh> I sort of replied in my late response to the other email, but let me reply
here as well because that thread was indeed getting very deep.
Zzh> I changed the letters so that we can distinguish between node
representation and function representation. A is the redundancy node and D is
merging node. I also added another node E.
Zzh> Let’s say that we’ll only make two copies for D to receive. A and D have
replication segment R installed. R on A simply says “make two copies, one
through B and one through C”. B/C do not need any state because A is simply
going to tunnel through B/C respectively. R on D simply says “I am a leaf so I
just pop R”.
Zzh> The ingress will send packets with SL <A, R, M>. SID A gets the packet to
A, who sees R and do the replication (R is not popped by A). D sees R in the SL
and pops R (this is the replication segment behavior on a leaf). It then sees M
and do the merging. Alternatively, A could pop R so D will see M directly and
do the merging.
Zzh> Now let’s say we want to make three copies. The ingress will still send
the same SL. R on A now says “tunnel one copy to D through B and send one copy
to C” and C now also has R installed, saying “send one copy to D directly and
another copy to D via E”. Now three copies will arrive on D (with A/C each
replicating once). D sees R SID and pops the R SID (as the behavior of
replication segment on leaf). It then sees M and do the merging.
Zzh> The replication is pure SR-P2MP behavior (assuming A does not need to add
FI/SN). M is pure non-topological merging behavior (relying on the FI/SN added
by the ingress node).
Zzh> Thanks.
Zzh> Jeffrey
I don’t think I understand the entire forwarding flow correctly. In fact we are
very interested in Tree-SID solution as it has been adopted as a WG work. It
would be very helpful if you or anyone can provide a detailed illustration or
comparison, for instance like the way of the Appendix in replication SID/Tree
SID drafts.
Looking forward to your reply!
Best,
Fan
Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
