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

[Huaimo Chen <[e-mail]>]

Hi Acee,

    Thank you very much for your suggestions below. We will update the draft with more details as you suggested.

Acee: "I’d thought of splitting the MDT as well after I’d commented. This should be elaborated on more in the draft. Note that the sub-trees are not necessarily disjoint."

Best Regards,
Huaimo
________________________________
From: Acee Lindem (acee) <[e-mail]>
Sent: Friday, January 22, 2021 5:28 PM
To: Huaimo Chen <[e-mail]>; Rishabh Parekh <[e-mail]>; Stig Venaas <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01


Hi Huaimo,



From: Huaimo Chen <[e-mail]>
Date: Friday, January 22, 2021 at 5:21 PM
To: Acee Lindem <[e-mail]>, Rishabh Parekh <[e-mail]>, Stig Venaas <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01



Hi Acee,



    Thank you very much for your comments.

    My responses are inline below with prefix [HC].



Best Regards,

Huaimo



I think the concept of the ingress node encoding the complete MDT in the segment

list is flawed and won’t scale. At some point, the segment list is finite.

[HC]: In Segment Rouging (SR), for an explicit point-to-point (P2P) path/tunnel

from an ingress to an egress,  the ingress node encodes the path in the segment

list. This should improve the network scalability since there is no per-path state

in the core of the network.

For an explicit point-to-multipoint (P2MP) path/tree (or say MDT),

it seems natural for the ingress node of the P2MP path to encode the P2MP path

in the segment list. This should also improve the network scalability since

there is no per-P2MP-path (or say per-MDT-tree) state in the core of the network.

For a P2MP path/tree, its ingress node does not have to encode the complete

MDT in the segment list. If the tree has a few separated sub-trees from the ingress,

for each of these sub-trees, the ingress node encodes it in a separated

segment list and sends the multicast packet with the segment list for the

sub-tree to the next hop node along the link on the sub-tree.

Regarding to the finite size of the segment list, for a P2MP 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.



I’d thought of splitting the MDT as well after I’d commented. This should be elaborated on more in the draft. Note that the sub-trees are not necessarily disjoint.



Additionally, the network programming is fairly complex.

[HC]: The document on the network programming is on its way to be a RFC after WGLC.

With the network programming, a function may be defined by a program/procedure

for a SID or a set of SIDs. It seems easy to add a new function in this way.



I think you have a future in Product Management.





Finally, a separate multicast SID must be provisioned and advertised for every

multicast egress or replication node. Please let me know if I’m missing something.

[HC]: A separate multicast SID must be provisioned for every replication node

and a central controller such as PCE knows the SID on the node.

It seems that this is similar to a replication SID for every replication node.

We will update the draft with some details accordingly to address your concerns.



Thanks – I’m more familiar with IR solutions than the replication SID solution. I’ll need to look at what it is compared against.



Thanks,
Acee





I don’t support WG adoption. For those supporting adoption, I’d ask if you plan to actually implement this.



Thanks,

Acee