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

[Huaimo Chen <[e-mail]>]

Hi Jeffrey,

    Thanks for your further comments.
    My responses are inline below with prefix [HC3].

Best Regards,
Huaimo

________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Sunday, January 24, 2021 11:26 PM
To: Huaimo Chen <[e-mail]>; Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; Stig Venaas <[e-mail]>; [e-mail] <[e-mail]>; 'Toerless Eckert' <[e-mail]>
Subject: RE: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01


Hi Huaimo,



Please see zzh2> below. I trimmed some text.





Zzh> Plus the uSID-Block-ID, for each SRv6 SID that is needed? More below.

[HC2]: The size of compressed SID (u bits) is the average size of

a compressed SID. If compressing method uses uSID-Block-ID, it is considered

in the average size. There are a few of methods for compressing SIDs.

They may have different compression rates.



Zzh2> Before WG adoption, the draft needs to have details spelled out with one of the compression methods. I don’t think it scales even w/ compression, but it’s a non-starter at all w/o compression.

[HC3]: The details about one compression method is posted in one of my
previous responses.
I believe that it is scalable with compression. The details in the example
of one compression method illustrated, on average, one link on a multicast
tree uses 32 bits. This can be improved to 20 bits per link.
It can be a starter without compression in the following way.
For a P2MP/multicast path/tree, the tree can be "split" into multiple sub-trees
such that each of the sub-trees can be encoded in the segment list of the
finite size.



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”?

[HC2]: This is an example value for M. For a network with 10k links, there are 20k bitpositions.

On average, the maximum bitposition is around 10k.



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).

[HC2]: With overhead M bits in a packet, M/u links can be encoded.



Zzh2> I assume you won’t have 10k bits in a packet for encoding the (sub-)tree, right? So the key is how many bits in one packet you can use for encoding the (sub-)tree, and how many leaf/replication nodes you can fit in.

[HC3]: This is for the case where the overhead in a BIER-TE packet is 10k bits
when one BitString without any set is used. For the same overhead, how many links
can be encoded.



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?

[HC2]: "assume" is used to name a variable such as "assume" that

the size of compressed SID is u bits. Here u is a variable for the

the size of compressed SID on average. Some example values for the

variables are given. There seems no imply.

There are a few of methods for compressing SIDs. The method using uSIDs

is one of them. The size of the segment list for a sub-tree is u*N bits,

where N is the number of links on the sub-tree.



Zzh2> How about putting some uSID details in the draft as I mentioned in the other email?

[HC3]: We will add some details in the draft.

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.

Zzh2> SR-P2MP with MPLS does NOT involve new forwarding scheme at all. It’s the same as existing mLDP/RSVP-TE P2MP in the forwarding plane. For SRv6 replication segment, it’s also “like” existing MPLS P2MP in that part of the IPv6 address is used as lookup key just like a label (and that is not different from the SRv6 VPN).

[HC3]: It should be a new forwarding scheme for SRv6 replication segment.
Under the network programming, replication SID is a new type of SID.
It will have a new program/procedure for the behavior of this new SID
even though it is “like” existing MPLS P2MP.

Zzh2> The scheme in draft-chen is so much different - it encodes a sub-tree and forwarding is certainly more complicated. If it does scale well, then  it is worth it even as a new forwarding scheme, but that has not been concluded.

[HC3]: Under the network programming, the behavior of the forwarding
is a new program/procedure, which uses existing encap with the SIDs of a
sub-tree. It seems not that complicated.

Zzh2> BIER-TE is a new forwarding scheme, but it is by far the best per-tunnel TE solution for multicast that does not have per-tunnel state inside the network, and it went through due scrutiny. Draft-chen needs to be scrutinized as well, and it needs to show that it does better to proceed as yet another new forwarding scheme.

[HC3]: Whether it is the best depends on a number of factors, some of them
are explained in previous responses.

Zzh2> Jeffrey

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.

[HC2]: The new forwarding scheme (or say forwarding behavior) in our draft

can be defined in a small program/procedure in the network programming. This

is very different from that in BIER, where a new WG is formed.

We will update the draft to address your concerns and make it clearer.

Your earlier point is responded in my previous response.



Zzh> Jeffrey



Juniper Business Use Only



Juniper Business Use Only



Juniper Business Use Only


Juniper Business Use Only