Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Huaimo,

I snipped other text to focus on the scaling aspect.

Please see zzh> below.


2. Regardless which WG is the right home, this is not a practical solution - you won't be able to encode much of the tree in the data packet even when you use uSID. If you want to remove the per-tree state in the network and still achieve effective replication, you either do BIER or BIER-TE (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-te-arch%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895958398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ga2B%2Fgo%2B7POZhifAUyNItFh52LBZqzwMH1HUXBRFHrY%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-bier-te-arch*2F&amp;data=04*7C01*7Chuaimo.chen*40futurewei.com*7C41c897da80ec41896e9f08d8b72a5ebc*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637460739895958398*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=ga2B*2Fgo*2B7POZhifAUyNItFh52LBZqzwMH1HUXBRFHrY*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!XtcZVAo71noKAJl9dZ6Qg9nq7_dJ9mL8pQtU5ytJJg3dUEUXjdk2HSA-786i6W0t$>). BIER-TE would scale better than this.
[HC]: This should be a practical solution.
The reasons include:
1) This provides an alternative solution for multicast using SR.
For people operating a network with SR, they do not need to deploy
BIER-TE. This may reduce their Opex to Capex.

Zzh> BIER-TE is just a better way to encode multicast tree in a data packet. It does not mean that BIER-TE is not (or not suitable for) SR. But that's a side point.

2) The scalabilities of this (called SR-P2MP) and BIER-TE depend on different
factors such as SID compression for SR-P2MP and BitPositions encoding for
BIER-TE. Consider an explicit multicast tree traversing through N links,
there are N SIDs in SR-P2MP, and N BitPositions in BIER-TE.

Zzh> As a side node, we should avoid calling this SR-P2MP. Both in Spring and PIM, SR-P2MP already refers to the replication segment based architecture that is different from this. Should not call it SRv6-P2MP either, as the same SR-P2MP architecture can apply to SRv6 forwarding plane as well (the SR-P2MP co-authors already had an internal revision about SRv6 forwarding plane - the posting was delayed due to non-technical reasons - basically both the Replication Segment ID and transportation from an upstream node to a downstream node are encoded as an IPv6 address).

Assume that the size of compressed SID is u bits, the overhead of SR-P2MP is N*u bits.

Zzh> Plus the uSID-Block-ID, for each SRv6 SID that is needed? More below.
Suppose that the size of SI and BitString are s and b bits respectively, and
the maximum number of possible BitPositions is M bits, the overhead of BIER-TE
is M bits if a maximum BitString is used,
(in this case, M may greater than N*u. For example, when M = 10k, u = 40,
M > N*u for N < 10k/40)
up to N*(s+b) if bit sets are used.
(in this case, N*(s+b) may greater than N*u. For example, when b = 64, s = 10,
u = 40, N*(s+b) > N*u )

zzh> Do you mean "M = 10, 000"?
zzh> The overhead consideration should be on a per-packet base. How much of a sub-tree can you encode in *one* packet with a header of a certain size? Your calculation does not seem be for that (and I have trouble following it).
Zzh> Additionally, the text seems to assume/imply that there is a continuous block of uSIDs. But with 40-bit uSIDs, you can only put two uSIDs in an SRv6 SID? How large would the segment list be if you want to encode a reasonably sized sub-tree?

3. If this did not involve new forwarding scheme (i.e. new hardware) one could argue that multiple solutions could be developed. But given that this does need new hardware and does not do better than alternatives (e.g. BIER-TE), why bother.
[HC]: It seems that both SR-P2MP and BIER-TE are involved with new forwarding schemes.

Zzh> Because of new forwarding schemes, BIER went through the process of forming a new WG, and BIER-TE was originally on the experimental track. More importantly, my earlier point is that the new scheme should scale better (at least as well) for it to be worthy.
Zzh> Jeffrey


Juniper Business Use Only


Juniper Business Use Only