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

From: Stig Venaas <[email-masked]>
Date: Mon, 11 Jan 2021 11:53:48 -0800

Hi all

We discussed the draft draft-chen-pim-srv6-p2mp-path-01 in the last wg
meeting. We did do an adoption call in the meeting, but we also would
like to get input on the mailing list.

Please respond by January 25th whether you believe this document
should be adopted.
The document can be found at
https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01

Regards,
Stig

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 11 Jan 2021 21:24:41 +0000

Hi Everyone,

    Happy New Year.
    I believe it should be adopted.

Best Regards,
Huaimo as co-author
________________________________
From: pim <[email-masked]> on behalf of Stig Venaas <[email-masked]>
Sent: Monday, January 11, 2021 2:53 PM
To: [email-masked] <[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document
should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C8c1466687fbf486d4d9008d8b66aa821%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459916499016187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EnYWhp4pSKR3nmT6MJoh9CPE2ZNjjGyjNTutzoOdiFc%3D&amp;reserved=0

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C8c1466687fbf486d4d9008d8b66aa821%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459916499016187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=J8M%2Fkfx7lKF1fWChCO%2FnikCvbpWj%2ByL28Jh0HGyU4iU%3D&amp;reserved=0

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 12 Jan 2021 11:03:23 +0800

Hi, All:

I support its adoption as co-author. It provides one alternative approach
for p2mp multicast solution.

Best Regards

Aijun Wang

China Telecom

From: pim  <mailto:&lt;[email-masked]&gt;> <[email-masked]> on
behalf of Stig Venaas  <mailto:&lt;[email-masked]&gt;> <[email-masked]>

To: [email-masked] <mailto:[email-masked]>   <mailto:&lt;[email-masked]&gt;>
<[email-masked]>

Hi all

Please respond by January 25th whether you believe this document
should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.iet
f.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01&amp;data=04%7C01%7Chuaimo.ch
en%40futurewei.com%7C8c1466687fbf486d4d9008d8b66aa821%7C0fee8ff2a3b240189c75
3a1d5591fedc%7C1%7C0%7C637459916499016187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=En
YWhp4pSKR3nmT6MJoh9CPE2ZNjjGyjNTutzoOdiFc%3D&amp;reserved=0>
&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C8c1466687fbf486d4d9008d8b6
6aa821%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459916499016187%7CUnk
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
CI6Mn0%3D%7C1000&amp;sdata=EnYWhp4pSKR3nmT6MJoh9CPE2ZNjjGyjNTutzoOdiFc%3D&am
p;reserved=0

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked] <mailto:[email-masked]> 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.o
rg%2Fmailman%2Flistinfo%2Fpim
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.co
m%7C8c1466687fbf486d4d9008d8b66aa821%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
7C0%7C637459916499016187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=J8M%2Fkfx7lKF1fWChC
O%2FnikCvbpWj%2ByL28Jh0HGyU4iU%3D&amp;reserved=0>
&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C8c1466687fbf486d4d9008d8b6
6aa821%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637459916499016187%7CUnk
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
CI6Mn0%3D%7C1000&amp;sdata=J8M%2Fkfx7lKF1fWChCO%2FnikCvbpWj%2ByL28Jh0HGyU4iU
%3D&amp;reserved=0

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 Jan 2021 22:29:35 -0500

I support WG adoption.

Thanks

Gyan

On Mon, Jan 11, 2021 at 2:54 PM Stig Venaas <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/pim
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 12 Jan 2021 15:06:58 +0000

Hi Stig

And happy new year all!

Is PIM WG really the right place for this draft? After all this draft is trying to introduce a new segment type for the leaf router. I would imagine the work needs to start in the SPRING WG to understand what is a leaf segment type and understand the complications of this segment type in the bigger picture of segment routing.

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

We discussed the draft draft-chen-pim-srv6-p2mp-path-01 in the last wg meeting. We did do an adoption call in the meeting, but we also would like to get input on the mailing list.

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01

Regards,
Stig

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 12 Jan 2021 18:46:02 +0000

I object to the adoption, for the following reasons:

1. As Hooman pointed out, this should first be discussed in the SPRING WG first, and perhaps homed there.
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://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/). BIER-TE would scale better than this.
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.

BTW, the encoding scheme in this solution is similar to https://tools.ietf.org/html/draft-zhang-qos-ospf-01#section-6.1.3. Of course, that one is for control plane only.

Jeffrey

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

[External Email. Be cautious of content]

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01__;!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp$

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on$

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on$

Juniper Business Use Only

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 12 Jan 2021 11:56:24 -0800

+1 to Jeffrey and Hooman

Cheers,
Jeff

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 16 Jan 2021 01:32:14 +0000

Hi Jeffrey,

    My responses are inline below with prefix [HC].

Best Regards,
Huaimo on behalf of authors

________________________________
From: pim <[email-masked]> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: Tuesday, January 12, 2021 1:46 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked] <[email-masked]>; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

1. As Hooman pointed out, this should first be discussed in the SPRING WG first, and perhaps homed there.
[HC]: It seems that this should be discussed in the PIM WG first.
The reasons include:
1) The PIM WG has agreed with the SPRING WG to work on multicast+spring
work which is why draft-ietf-pim-sr-p2mp-policy is adopted.
2) This is about multicast.
3) For the document focusing on one topic (called X) and related to
another topic (called Y), it is better to discuss it in the WG for X.
For example, RFC 4203 OSPF Extensions in Support of GMPLS, focusing
on GMPLS and related to OSPF, its home WG is CCAMP, not OSPF.
Similarly, the home WG for this should be PIM, not SPRING.

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). 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.
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.
Assume that the size of compressed SID is u bits, the overhead of SR-P2MP
is N*u bits.
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 )

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.

BTW, the encoding scheme in this solution is similar to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-qos-ospf-01%23section-6.1.3&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9zwA%2B%2FblwWrvpWEmh5K%2Fu9nrdExX4jX%2BqavjP9T1sKk%3D&amp;reserved=0. Of course, that one is for control plane only.
[HC]: The functions of the two encodings are the same, which are
to represent a P2MP tree.
But they are different in some aspects such as contents, semantics.

Jeffrey

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hnpkKlA9Rd3%2B9%2FGdveetHJB1ZBhEhVOhc0FCH6PDytk%3D&amp;reserved=0

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0

_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0

_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0

---

From: Xufeng Liu <[email-masked]>
Date: Sat, 16 Jan 2021 10:59:17 -0500

Support adoption.

Thanks,
- Xufeng

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sun, 17 Jan 2021 21:17:05 +0000

Hi Huaimo

Since you are answering my concerns as well in this email I will add my two cent.

1.            "The PIM WG has agreed with the SPRING WG to work on multicast+spring work which is why draft-ietf-pim-sr-p2mp-policy is adopted."

HB> This is not my understanding, chairs please clarify the confusion here, it is important to have a clear mandate for the WG.

This is why the chairs insisted for the adaptation of draft-ietf-spring-sr-replication-segment first before the pim working group adopted draft-ietf-pim-sr-p2mp-policy. The draft-ietf-pim-sr-p2mp-policy only talks about how a P2MP tree is built via candidate paths and the PCE etc... and it uses the replication segment, which is being worked on in the spring WG, as its building block.

I think it is very important to clarify the SID concept introduced in this draft with spring first.

Thanks

Hooman

From: Huaimo Chen <[email-masked]>
Sent: Friday, January 15, 2021 8:32 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,

________________________________
From: pim <[email-masked]<mailto:[email-masked]>> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>
Sent: Tuesday, January 12, 2021 1:46 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Jeffrey

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0

---

From: Michael McBride <[email-masked]>
Date: Mon, 18 Jan 2021 00:04:49 +0000

Hi Hooman,

Thanks for the comments. I'd recommend we follow the same path as was done with sr-p2mp-policy, ie, we continue the call for adoption in pim and see if there is support. If no wg support we drop it. If there is support, we (actually Stig since I'm on the draft) will contact the spring chairs before adoption. The spring chairs have been more than happy for pim to take on spring+mcast work. It was our AD, not spring or pim chairs, who requested we hold off and wait for the replication-segment draft before pim adoption. Like you, they may suggest that this srv6-p2mp draft should also have a base SID concept draft done in spring.

Stig should take it from here.

mike

From: pim <[email-masked]> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Sunday, January 17, 2021 1:17 PM
To: Huaimo Chen <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Huaimo

Thanks

Hooman

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 15, 2021 8:32 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-te-arch%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439791300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=AioRMsWLJHy3ff2on0C%2FrYnyHFnW96VsK1aU%2FBrC%2Fmo%3D&reserved=0>). BIER-TE would scale better than this.

BTW, the encoding scheme in this solution is similar to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-qos-ospf-01%23section-6.1.3&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9zwA%2B%2FblwWrvpWEmh5K%2Fu9nrdExX4jX%2BqavjP9T1sKk%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-qos-ospf-01%23section-6.1.3&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439801296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=YPQiLAmuED%2B27xK%2B0Ea9ECxh21yTToMkDrafBJEPR9s%3D&reserved=0>. Of course, that one is for control plane only.
[HC]: The functions of the two encodings are the same, which are
to represent a P2MP tree.
But they are different in some aspects such as contents, semantics.

Jeffrey

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hnpkKlA9Rd3%2B9%2FGdveetHJB1ZBhEhVOhc0FCH6PDytk%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439801296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=685QycQWUh6cfDeNPoOsUMTY%2BQHqaHBplm5PxAQELZE%3D&reserved=0>

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439811288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MLih2bmdXO15Dz%2FA56JlHKD5eY28mThnhaGMeRo9gWI%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439811288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MLih2bmdXO15Dz%2FA56JlHKD5eY28mThnhaGMeRo9gWI%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C39d40656a24546dd773e08d8bb2d45ab%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465150439821286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XOHOeq%2Fb4ip20W%2BKnN8AMPq6y25lBSkY9Rv30AG1KUU%3D&reserved=0>

---

From: Huzhibo <[email-masked]>
Date: Mon, 18 Jan 2021 12:26:47 +0000

I support the adoption.

Thanks
Zhibo Hu

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: Yanhe Fan <[email-masked]>
Date: Mon, 18 Jan 2021 08:12:39 -0500

> I support it as a co-author.
>

Thanks,
Yanhe

> meeting. We did do an adoption call in the meeting, but we also would like
> to get input on the mailing list.
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 18 Jan 2021 17:40:04 +0000

I support the adoption. No doubt this draft should also be discussed in SPRING, but PIM appears to be the right home.

Thanks,
Haoyu

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hnpkKlA9Rd3%2B9%2FGdveetHJB1ZBhEhVOhc0FCH6PDytk%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf35ab589d3944ef53fac08d8bb44b62c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465251126823493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=aIaK%2BEyL8282N%2FwnMqu1%2F7YtIB%2FNy08sTDQacB9q1dI%3D&reserved=0>

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf35ab589d3944ef53fac08d8bb44b62c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465251126823493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ddi%2BK9tSKb4TJ6orShn3ugRyCk77FRCVeHKIGd9ZLHo%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf35ab589d3944ef53fac08d8bb44b62c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465251126833491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=j6OcPXn2L%2F6ZfxuWn9aJWhWyWOSB6L8kc4AdU1Odfwg%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf35ab589d3944ef53fac08d8bb44b62c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465251126843486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=KRhDHgNGB9BiPrqCGvxZxDVpPSVuNaMi6g6DmrDTDvo%3D&reserved=0>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 Jan 2021 18:17:38 +0000

+1.

Linda Dunbar

From: pim <[email-masked]> On Behalf Of Haoyu Song
Sent: Monday, January 18, 2021 11:40 AM
To: [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Thanks,
Haoyu

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hnpkKlA9Rd3%2B9%2FGdveetHJB1ZBhEhVOhc0FCH6PDytk%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219979692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QltQIPrs3H6S1oSQughEwX8aEkGOYS4XC0Xrfw8Xd50%3D&reserved=0>

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219989689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UASr8JpDc6Nuv3L5JuOZCz7uuio64oFUahxf7HnA1mY%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219999683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U5g9VU%2FiFso7TQkZCjvNHFx9lLsCaqQZeVwnhDK2It4%3D&reserved=0>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219999683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bvvBlGCX6XS86P92stPT2BYwPNTw662yDRhRWcgxrps%3D&reserved=0>

---

From: LEI LIU <[email-masked]>
Date: Tue, 19 Jan 2021 09:28:43 -0800

I support the adoption.

Thanks,
Lei

On Mon, Jan 18, 2021 at 10:17 AM Linda Dunbar <[email-masked]>
wrote:

> +1.
>
>
>
> Linda Dunbar
>
>
>
> *From:* pim <[email-masked]> *On Behalf Of * Haoyu Song
> *Sent:* Monday, January 18, 2021 11:40 AM
> *To:* [email-masked]
> *Subject:* Re: [pim] pim wg adoption call for
> draft-chen-pim-srv6-p2mp-path-01
>
>
>
> I support the adoption. No doubt this draft should also be discussed in
> SPRING, but PIM appears to be the right home.
>
>
>
> Thanks,
>
> Haoyu
>
>
>
> Is PIM WG really the right place for this draft? After all this draft is
> trying to introduce a new segment type for the leaf router. I would imagine
> the work needs to start in the SPRING WG to understand what is a leaf
> segment type and understand the complications of this segment type in the
> bigger picture of segment routing.
>
> Thanks
> Hooman
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219979692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QltQIPrs3H6S1oSQughEwX8aEkGOYS4XC0Xrfw8Xd50%3D&reserved=0>
>
> Regards,
> Stig
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219989689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UASr8JpDc6Nuv3L5JuOZCz7uuio64oFUahxf7HnA1mY%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219999683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U5g9VU%2FiFso7TQkZCjvNHFx9lLsCaqQZeVwnhDK2It4%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1f46719f360e4087b8ac08d8bbd81e7d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637465884219999683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bvvBlGCX6XS86P92stPT2BYwPNTw662yDRhRWcgxrps%3D&reserved=0>

-- 
-- 
__________________________________
Best Regards,

Sincerely Yours,
Lei Liu, Ph.D
--------------------
Photonic Transport Network Laboratory,
KDDI R&D Laboratories Inc.,
2-1-15 Ohara Fujimino-shi, Saitama, Japan
TELE: +81-49-278-7536
FAX: +81-49-278-7510
ZIP: 356-8502
E-mail: [email-masked] / [email-masked]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 19 Jan 2021 18:23:17 +0000

Hi Mike,

Where to home the work is mainly a formality. While the situation between sr-p2mp and draft-chen are actually different, as long as spring and pim agrees where to do the work it is fine.

I see lot of email of simple support. However, the technical concerns about scaling has not settled. Huaimo replied to my email and I have not got back but I will.

Jeffrey

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Sunday, January 17, 2021 7:05 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Huaimo Chen <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Hooman,

mike

From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Sunday, January 17, 2021 1:17 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Huaimo

Thanks

Hooman

Hi Jeffrey,

Best Regards,

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&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439791300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=AioRMsWLJHy3ff2on0C*2FrYnyHFnW96VsK1aU*2FBrC*2Fmo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QEN-vx06$>). BIER-TE would scale better than this.

BTW, the encoding scheme in this solution is similar to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-qos-ospf-01%23section-6.1.3&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9zwA%2B%2FblwWrvpWEmh5K%2Fu9nrdExX4jX%2BqavjP9T1sKk%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-zhang-qos-ospf-01*23section-6.1.3&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439801296*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=YPQiLAmuED*2B27xK*2B0Ea9ECxh21yTToMkDrafBJEPR9s*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QNRDtUjh$>. Of course, that one is for control plane only.
[HC]: The functions of the two encodings are the same, which are
to represent a P2MP tree.
But they are different in some aspects such as contents, semantics.

Jeffrey

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, January 12, 2021 10:07 AM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Stig

And happy new year all!

Thanks
Hooman

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Stig Venaas
Sent: Monday, January 11, 2021 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-pim-srv6-p2mp-path-01__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=hnpkKlA9Rd3%2B9%2FGdveetHJB1ZBhEhVOhc0FCH6PDytk%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-chen-pim-srv6-p2mp-path-01__*3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAwGrxmMp*24&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439801296*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=685QycQWUh6cfDeNPoOsUMTY*2BQHqaHBplm5PxAQELZE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QH562piI$>

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fpim__*3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on*24&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439811288*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=MLih2bmdXO15Dz*2FA56JlHKD5eY28mThnhaGMeRo9gWI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QN5ZP1W6$>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim__%3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on%24&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=G2d%2BJHw6fKQ40dcEwqNQxD1hxQ1t49DY01CoU%2FpS1BI%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fpim__*3B!!NEt6yMaO-gk!VkCfh1h85mTSck3dXz4-Zl2ILoIBABk6FDbg8CYXKvteZ3OpsWdLRkneAzd9s0on*24&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439811288*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=MLih2bmdXO15Dz*2FA56JlHKD5eY28mThnhaGMeRo9gWI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QN5ZP1W6$>

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C41c897da80ec41896e9f08d8b72a5ebc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637460739895968353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vrmXuMS3ljbC58tgZT8fKqSY4MS2xORo%2FmpOz4%2FDi7k%3D&amp;reserved=0<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fpim&data=04*7C01*7Cmichael.mcbride*40futurewei.com*7C39d40656a24546dd773e08d8bb2d45ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637465150439821286*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=XOHOeq*2Fb4ip20W*2BKnN8AMPq6y25lBSkY9Rv30AG1KUU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Uunzl_OgHsn6_BwXgFneNbMziOfHzOhd1EmdnD-fWjHqix9ulpFZoC54QNTWY8Dc$>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 19 Jan 2021 19:25:21 +0000

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.

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.

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.

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?

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

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 19 Jan 2021 13:53:50 -0800

I object for the same reasons as Jeffrey.

-Rishabh

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 21 Jan 2021 03:13:29 +0000

I support the adoption. 

Thanks, 
Shunwan

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jan 2021 15:45:05 +0000

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. Additionally, the network programming is fairly complex. 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.

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

Thanks,
Acee

From: pim <[email-masked]> on behalf of Rishabh Parekh <[email-masked]>
Date: Tuesday, January 19, 2021 at 4:54 PM
To: Stig Venaas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

-Rishabh

On Mon, Jan 11, 2021 at 11:54 AM Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:
Hi all

Regards,
Stig

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 21 Jan 2021 17:40:48 +0000

Agree with scale issue being raised in thread. I do not think document is ready to be adopted yet.  Before going ahead with adoption, it may be good to clear questions in list .

Do not support the adoption at this point of time.

From: pim <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Thursday, January 21, 2021 at 7:46 AM
To: Rishabh Parekh <[email-masked]>, Stig Venaas <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Thanks,
Acee

-Rishabh

Regards,
Stig

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 Jan 2021 01:54:10 +0000

Hi all,

I have read the document and the presentation slides.
I think it is a clear proposal to solve some clear problems of existing approaches.

Comparing to IR, this proposal can do a stateless replication (say 10x replication) in 1 packet, thus increase the scalability of IR to 10X.
It can be seen as an extension to IR (a 1x replication), and the cost to scale to 10x replication is very deterministic and smooth.
It can be combined with IR seamlessly.
For example, IR could support a stateless 100x replication from an Ingress router to 100 Egress routers.
Then, this proposal could support a stateless 1000x replication using the combination of IR * SR-P2MP.

Contrary to the concern of scalability, I think this proposal has a linear scalability improvement comparing to IR-only, and therefore I support the adoption of this document.

To authors, it may be useful to clarify the scope and add some text about scalability consideration in the document.

Regards,
Jingrong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: wangyali <[email-masked]>
Date: Fri, 22 Jan 2021 10:04:33 +0000

Hi all,

Explicit Multicast path with SRv6 is an interesting topic. The tradeoff of packet overhead has been clearly discussed in the ML. Support WG adoption.

Best regards,
Yali

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 22 Jan 2021 13:53:58 +0000

I don't see a consensus on this yet on the mailing list.

It would help if a specific illustration of SRv6 header with SRHs to encode the following tree of 4 leaves and 3 replication points (from the draft itself):

                      [L1]                  R Ingress/Root
                      /                    Li Egress/Leaf
                     /                     Pi Transit Node
                    /
                  [P2]------[L2]
                  /
                 /
                /
     [R]------[P1]                [L3]
                \                /
                 \              /
                  \            /
                  [P3]------[P4]------[L4]

            Figure 1: SR P2MP Path from R to L1, L2, L3 and L4

In other words, translate <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m> into a real IPv6 header with multiple IPv6 addresses in the SRH (using the 40-bit uSID that Huaimo mentioned), and calculate the header size.

Jeffrey

-----Original Message-----
From: pim <[email-masked]> On Behalf Of wangyali
Sent: Friday, January 22, 2021 5:05 AM
To: Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all,

Best regards,
Yali

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01__;!!NEt6yMaO-gk!VSgYDCLf6UPdJ2QkgsJqOBJFepRrAUZ6R6YbriTZxkjO1TtMMrciWjnBDZhPwVL3$

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!VSgYDCLf6UPdJ2QkgsJqOBJFepRrAUZ6R6YbriTZxkjO1TtMMrciWjnBDTmCR2Xr$

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!VSgYDCLf6UPdJ2QkgsJqOBJFepRrAUZ6R6YbriTZxkjO1TtMMrciWjnBDTmCR2Xr$

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 22 Jan 2021 14:19:37 +0000

With IR, you don't need any of the following:

1. encoding (sub-)tree in the packet
2. core routers supporting the new forwarding behavior (i.e. new ASIC)

I am less concerned with edge devices having to support new forwarding behavior because they typically are capable of doing that w/o new ASIC; but core routers are more difficult with that, so we need to be careful with solutions requiring new forwarding behavior.

You mentioned 10x replication with draft-chen. That's 10 leaves but you also need to encode replication points. As I mentioned in the other email, it's good to see a concrete illustration of the SRv6 header.

Back to my original comment - how does it compare to BIER-TE, and do we really need another solution that requires new  ASIC on core routers.

Jeffrey

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 21, 2021 8:54 PM
To: Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all,

Regards,
Jingrong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Please respond by January 25th whether you believe this document should be adopted.
The document can be found at
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01__;!!NEt6yMaO-gk!X-bfbdJ7YKP527XztGdWD_d7FiiEJ138T4nEbEwJB0s-KGZNWzndp6TBzStPkbf-$

Regards,
Stig

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!X-bfbdJ7YKP527XztGdWD_d7FiiEJ138T4nEbEwJB0s-KGZNWzndp6TBzQoYlD8B$

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!X-bfbdJ7YKP527XztGdWD_d7FiiEJ138T4nEbEwJB0s-KGZNWzndp6TBzQoYlD8B$

---

From: "Ehsan Hemmati (ehemmati)" <[email-masked]>
Date: Fri, 22 Jan 2021 18:45:28 +0000

I do agree with Jeffrey and Object to adoption for the same reason.

Ehsan

On Jan 22, 2021, at 6:19 AM, Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>> wrote:

Jeffrey

-----Original Message-----
From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, January 21, 2021 8:54 PM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all,

Regards,
Jingrong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 22 Jan 2021 22:10:09 +0000

Hi Jeffrey,

    Thank you very much for your comments.
    My responses are inline below with prefix [HC].
    The figures for the DA and IPv6 header are attached in .txt file since their formats may be changed below for some email clients.
    BTW, the previous emails with .PDF file could not go through PIM (held since it is too big).

Best Regards,
Huaimo
________________________________
From: pim <[email-masked]> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: Friday, January 22, 2021 8:53 AM
To: wangyali <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

                      [L1]                  R Ingress/Root
                      /                    Li Egress/Leaf
                     /                     Pi Transit Node
                    /
                  [P2]------[L2]
                  /
                 /
                /
     [R]------[P1]                [L3]
                \                /
                 \              /
                  \            /
                  [P3]------[P4]------[L4]

In other words, translate <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m> into a real IPv6 header with multiple IPv6 addresses in the SRH (using the 40-bit uSID that Huaimo mentioned), and calculate the header size.
[HC]: There are a few of methods for compressing SIDs.
The following is the DA and IPv6 header using G-SRv6 compression method
https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/
for <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m>.
Node R sends a packet with the IPv6 header to the DA.

Destination Address (DA):
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         2001:db9:0:0 (Common Prefix)                          |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            P1 ID              |       2       |       7       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Header:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Header   |  Hdr Ext Len  |  Routing Type | Segments Left |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Last Entry   |      Flags    |              Tag              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            P4 ID              |       2       |       2       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L3 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L4 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Padding                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            P2 ID              |       2       |       2       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            P3 ID              |       1       |       3       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L1 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L2 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On average, the size u of a compressed SID is 32 bits in this case.

Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 22 Jan 2021 22:21:01 +0000

Hi Acee,

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.

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.

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,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 22 Jan 2021 22:28:12 +0000

Hi Huaimo,

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

Hi Acee,

Best Regards,
Huaimo

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.

I think you have a future in Product Management.

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

Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 22 Jan 2021 22:46:28 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Tuesday, January 19, 2021 2:25 PM
To: Huaimo Chen <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked] <[email-masked]>; 'Toerless Eckert' <[email-masked]>
Subject: RE: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Huaimo,

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-bier-te-arch*2F%26data%3D04*7C01*7Chuaimo.chen*40futurewei.com*7C41c897da80ec41896e9f08d8b72a5ebc*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637460739895958398*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3Dga2B*2Fgo*2B7POZhifAUyNItFh52LBZqzwMH1HUXBRFHrY*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!XtcZVAo71noKAJl9dZ6Qg9nq7_dJ9mL8pQtU5ytJJg3dUEUXjdk2HSA-786i6W0t%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Ccb763f1ab68640c81cae08d8bcb00020%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466811408056135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7HFc8smoleStwsswtmQRyfnKyJH8OFK3yl9zglHdNH0%3D&reserved=0>). BIER-TE would scale better than this.

The reasons include:

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.

[HC2]: This depends on a number of factors. Some of them are explained in the previous response.

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

[HC2]:  We will change the name/term SR-P2MP to a different one in the updated draft.

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

M > N*u for N < 10k/40)

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.

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

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

[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

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 22 Jan 2021 22:54:39 +0000

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) <[email-masked]>
Sent: Friday, January 22, 2021 5:28 PM
To: Huaimo Chen <[email-masked]>; Rishabh Parekh <[email-masked]>; Stig Venaas <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Huaimo,

Hi Acee,

Best Regards,

Huaimo

Thanks,
Acee

Thanks,

Acee

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 25 Jan 2021 03:33:41 +0000

Hi WG,

This document provides a valid solution for stateless multicast based on SRv6 NP and encodes P2MP tree into a packet to steer the flow in an indicated path.
I support the adoption of this document. 

Best
Xuesong

-----Original Message-----
From: pim [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Tuesday, January 12, 2021 3:54 AM
To: [email-masked]
Subject: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi all

Regards,
Stig

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 25 Jan 2021 04:04:00 +0000

Hi Huaimo,

The -01 revision is only based on the regular SRv6 SID, not uSID. In my earlier question, I was assuming uSID will be used and your example is also provided with uSID (I think). Even with uSID:

  1.  It takes two IPv6 addresses (256 bits) in SRH (with a 64-bit header itself) in addition to the IPv6 header to encode the 4 leaves with 3 replication points in your example. If uSID is not used then it takes even more bits. I am not convinced that is a scalable solution and I doubt that I am alone.
  2.  The draft needs to be updated with uSID details. For example, whether a uSID block ID is needed in each IPv6 address in the SRH, and when/why padding is needed in the encoding. More questions will come after the details are provided.

Given this, I am even more convinced that that draft is not ready for adoption. It first needs to extended with uSID details and we still need to discuss the scaling property.

Jeffrey

From: Huaimo Chen <[email-masked]>
Sent: Friday, January 22, 2021 5:10 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,
Huaimo
To: wangyali <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

                      [L1]                  R Ingress/Root
                      /                    Li Egress/Leaf
                     /                     Pi Transit Node
                    /
                  [P2]------[L2]
                  /
                 /
                /
     [R]------[P1]                [L3]
                \                /
                 \              /
                  \            /
                  [P3]------[P4]------[L4]

IPv6 Header:
  0                   1                   2                   3

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 25 Jan 2021 04:26:37 +0000

Hi Huaimo,

Please see zzh2> below. I trimmed some text.

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.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

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.

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

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

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.

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.

Zzh2> Jeffrey

Zzh> Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 25 Jan 2021 13:59:11 +0000

Hi,

I missed that you referred to "Generalized SRv6 Network Programming for SRv6 Compression". If that's what draft-chen is based on then draft-chen should be extended with relevant (vs. uSID) details, but then a related question is what is the status of that draft in the Spring WG, especially given the ongoing uSID work?

Note that the above does not change the scaling property.

Jeffrey

From: pim <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Sunday, January 24, 2021 11:04 PM
To: Huaimo Chen <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Huaimo,

Jeffrey

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 22, 2021 5:10 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,
Huaimo

                      [L1]                  R Ingress/Root
                      /                    Li Egress/Leaf
                     /                     Pi Transit Node
                    /
                  [P2]------[L2]
                  /
                 /
                /
     [R]------[P1]                [L3]
                \                /
                 \              /
                  \            /
                  [P3]------[P4]------[L4]

https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/__;!!NEt6yMaO-gk!TOoWyso7GdxJ13_OcGoZfz7dL0iJ01_zJUmMk9AicZQWhACefd4kuZWppq929ixx$>

IPv6 Header:
  0                   1                   2                   3

Jeffrey

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 25 Jan 2021 08:42:09 -0800

I do not support adoption of this draft.

I agree with Jeffrey, Hooman, and Acee's concerns. Let me add my own.

The IETF, as a global standards body, should strive to standardize the
minimum set of necessary solutions to solve the issues at hand, not strive
to standardize every solution imagined for each issue. Otherwise our value
is reduced to chaff.

I had an early IETF Mentor (1990's) tell me that our primary
responsibility in the IETF is not just to come up with good ideas, but it
was to stop the bad ones. He went on to say bad ideas are like zombies;
they just keep coming back with new faces. This draft does not introduce
anything new or novel. Solutions like this have been proposed before.
Wrapping it in SR doesn't make it novel.

This isn't the first draft I've heard defended with "because SRv6" as some
silly justification. Sorry, but that is not a technical argument, and makes
no sense at all. Ethernet is ubiquitous, so should the IEEE just create
Ethernet extension headers to address every existing forwarding model? No,
they stay in their lane, add a next-proto pointer and pass it on. Can you
imagine the hardware manufactures' nightmares this would cause otherwise?
Not because it's technically challenging, but because the cost to support
every possible way of solving the same problem, because "Ethernet", would
be prohibitively expensive. As silly as this may sound, this is exactly
what is currently taking place with SRv6.

I am not suggesting SRv6 extension headers have no value, or are missguided
- far from it. It was my hope that the vision for SRv6 was an opportunity
to allow for rapid innovation in the forwarding plane where no current
solution existed. Or, if possible, create a better solution. But wrapping
an old idea in SRv6 doesn't make it novel. Even wrapping an existing
solution in SRv6 doesn't make it novel. On the contrary, it only undermines
the primary architecture that has been the model for the IETF for decades;
Layers.

And of all the layers we are charged to support in the IETF, the forwarding
plane, as I've been told from countless ADs, IAB members, etc, is rather
sacred. Any changes to the forwarding plane need to be carefully
scrutinized before being allowed to advance. I believe this same scrutiny
needs to be applied to every SRv6 forwarding extension proposed. You don't
get a pass simply by riding on top of SRv6. You are still modifying the
forwarding plane in ways that could eventually make the decades of work
from the IETF worthless. We need to strive for clarity, not confusion, and
our arguments need to remain honest, and technically focused.

- Shep

On Mon, Jan 25, 2021 at 5:59 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> Hi,
>
>
>
> I missed that you referred to “Generalized SRv6 Network Programming for
> SRv6 Compression”. If that’s what draft-chen is based on then draft-chen
> should be extended with relevant (vs. uSID) details, but then a related
> question is what is the status of that draft in the Spring WG, especially
> given the ongoing uSID work?
>
>
>
> *From:* pim <[email-masked]> *On Behalf Of * Jeffrey (Zhaohui) Zhang
> *Sent:* Sunday, January 24, 2021 11:04 PM
> *To:* Huaimo Chen <[email-masked]>; Stig Venaas <
> [email-masked]>; [email-masked]
> *[External Email. Be cautious of content]*
>
>
>
> Hi Huaimo,
>
>
>
> The -01 revision is only based on the regular SRv6 SID, not uSID. In my
> earlier question, I was assuming uSID will be used and your example is also
> provided with uSID (I think). Even with uSID:
>
>
>
>    1. It takes two IPv6 addresses (256 bits) in SRH (with a 64-bit header
>    itself) in addition to the IPv6 header to encode the 4 leaves with 3
>    replication points in your example. If uSID is not used then it takes even
>    more bits. I am not convinced that is a scalable solution and I doubt that
>    I am alone.
>    2. The draft needs to be updated with uSID details. For example,
>    whether a uSID block ID is needed in each IPv6 address in the SRH, and
>    when/why padding is needed in the encoding. More questions will come after
>    the details are provided.
>
>
>
> Given this, I am even more convinced that that draft is not ready for
> adoption. It first needs to extended with uSID details and we still need to
> discuss the scaling property.
>
>
>
> Jeffrey
>
>
>
> *From:* Huaimo Chen <[email-masked]>
> *Sent:* Friday, January 22, 2021 5:10 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Stig Venaas <
> [email-masked]>; [email-masked]
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
>     The figures for the DA and IPv6 header are attached in .txt file since
> their formats may be changed below for some email clients.
>
> ------------------------------
>
> *From:* pim <[email-masked]> on behalf of Jeffrey (Zhaohui) Zhang <
> zzhang=[email-masked]>
> *Sent:* Friday, January 22, 2021 8:53 AM
> *To:* wangyali <[email-masked]>; Stig Venaas <[email-masked]>;
> [email-masked] <[email-masked]>
> It would help if a specific illustration of SRv6 header with SRHs to
> encode the following tree of 4 leaves and 3 replication points (from the
> draft itself):
>
>                       [L1]                  R Ingress/Root
>                       /                    Li Egress/Leaf
>                      /                     Pi Transit Node
>                     /
>                   [P2]------[L2]
>                   /
>                  /
>                 /
>      [R]------[P1]                [L3]
>                 \                /
>                  \              /
>                   \            /
>                   [P3]------[P4]------[L4]
>
> In other words, translate <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m>
> into a real IPv6 header with multiple IPv6 addresses in the SRH (using the
> 40-bit uSID that Huaimo mentioned), and calculate the header size.
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-for-cmpr/__;!!NEt6yMaO-gk!TOoWyso7GdxJ13_OcGoZfz7dL0iJ01_zJUmMk9AicZQWhACefd4kuZWppq929ixx$>
>

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 25 Jan 2021 16:45:01 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo

Sent: Sunday, January 24, 2021 11:26 PM

Hi Huaimo,

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.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

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.

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

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.

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

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

Zzh2> Jeffrey

Zzh> Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 26 Jan 2021 03:08:25 +0000

Hi Huaimo,

Let me pull two points to the top of this email.

[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.
Zzh3> BIER-TE won't use 10k bits in the packet. It will use a finite number of bits (e.g. 512 bits or  1024 bits) with multiple sets, just like you break the entire tree into different sub-trees. The comparison is, say with 1024 bits as encoding space, how many nodes/links can each solution encode. I don't see how draft-chen can do better.

[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.
Zzh3> The general SRv6 network programing idea is that an IPv6 address is broken into the locator part and func/arg part. The locator part gets traffic to a node and the func/argc part is looked up to decide what to do next. SRv6-P2MP follows that perfectly, so *nothing is new*. When I said it is "like" existing MPLS P2MP, I should also have said that it uses *existing* SRv6 mechanism.
Zzh3> Jeffrey

From: Huaimo Chen <[email-masked]>
Sent: Monday, January 25, 2021 11:45 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,
Huaimo

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

Hi Huaimo,

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

even though it is "like" existing MPLS P2MP.

Zzh2> Jeffrey

Zzh> Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 27 Jan 2021 03:38:44 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo
Sent: Monday, January 25, 2021 10:08 PM

Hi Huaimo,

can be encoded.

Zzh3> BIER-TE won’t use 10k bits in the packet. It will use a finite number of bits (e.g. 512 bits or  1024 bits) with multiple sets, just like you break the entire tree into different sub-trees. The comparison is, say with 1024 bits as encoding space, how many nodes/links can each solution encode. I don’t see how draft-chen can do better.

[HC4]: For a network with 4k nodes, there can be about 32k links and 64k BitPositions.

When we use 1024 bits with multiple sets in the packet header,
the number of sets and the size of the set need to represent 64k BitPositions,
but 1024 bits contains a sub-tree that can be encoded in 1024 bits.
If the size of the set is 64 bits, the number of sets needs to be 10 bits.
Each set is encoded using 74 (64 bits for BitString + 10 bits for SI) bits.
1024 bits can contain 1024/74 = 13 sets.
For a sub-tree traversing 13 links with BitPositions in 13 sets,
1024 bits encodes 13 links of this sub-tree in BIER-TE.
With a good SID compression, the size of compressed SID can be 21 bits
(12 bits for node IDs, 3 bits for branches, 6 bits for number of SIDs),
1024 bits can encode 1024/21 = 48 links/nodes of a sub-tree in draft-chen.

Zzh3> The general SRv6 network programing idea is that an IPv6 address is broken into the locator part and func/arg part. The locator part gets traffic to a node and the func/argc part is looked up to decide what to do next. SRv6-P2MP follows that perfectly, so *nothing is new*. When I said it is “like” existing MPLS P2MP, I should also have said that it uses *existing* SRv6 mechanism.

Zzh3> Jeffrey

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

previous responses.

finite size.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

can be encoded.

Zzh2> Jeffrey

Zzh> Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 28 Jan 2021 02:13:23 +0000

Hi Huamo,

"For a network with 4k nodes", how large could a multicast tree be, and with draft-chen, how do you encode that tree in packets? How many copies would you send if each copy is only for a sub-tree?

A large network can be divided into BIER sub-domains, each with a smaller bitstring. If you use tunnel segmentation then you can have efficient replication all the way through (though the segmentation points will have per-tree state). If you don't want to use segmentation, the ingress can tunnel one copy to each sub-domain and inside each sub-domain you can have efficient replication.

Jeffrey

From: Huaimo Chen <[email-masked]>
Sent: Tuesday, January 26, 2021 10:39 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked]; 'Toerless Eckert' <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,
Huaimo

Hi Huaimo,

can be encoded.

Zzh3> Jeffrey

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 25, 2021 11:45 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

previous responses.

finite size.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

can be encoded.

Zzh2> Jeffrey

Zzh> Jeffrey

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 Jan 2021 08:48:25 -0500

All,

Huaimo has provided some valuable responses to scaling issues.  One point
to note as far as scaling is that most all provider run Jumbo frames 9216
MTU and IPv4 length is 16 bits which can support up to 65,535 size packet.

IPv6 header natively supports a 16 bit header length which is the same as
IPv4.

RFC 2765 specifies a hbh options Jumbo payload option that carried a 32 bit
length field 65,536 and 4,294,967,295 octets in length. Packets with such
long payloads are referred to as

   "jumbograms".

All router and switch vendors today support super jumbo which is payload
length between 9000 and 65535 capping today at 9216.

In the future as memory and buffer sizes increase in hardware fixed
function ASIC FPGA or programmable NPU  for packet IO processing the sizes
will eventually jump to 65535.  The next big step will be jumbo grams.  😀

With SRv6 unlike SR-MPLS traditional MPLS based PTA cannot be leveraged
such as RAVP-TE or mLDP, so the options for P2MP MDT is very limited and If
you don’t want the source node overhead of IR or SR replication SID, you
just have BIER as your only option.

Operators love having options and this draft provisss a valuable option
that does not require expensive upgraded to support BFR BIER.

I support WG adoption as stated and as this draft is very promising for
operators as an SRv6 “BIER alternative”.

Thanks

Gyan

On Wed, Jan 27, 2021 at 9:13 PM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> Hi Huamo,
>
>
>
> “For a network with 4k nodes”, how large could a multicast tree be, and
> with draft-chen, how do you encode that tree in packets? How many copies
> would you send if each copy is only for a sub-tree?
>
>
>
> A large network can be divided into BIER sub-domains, each with a smaller
> bitstring. If you use tunnel segmentation then you can have efficient
> replication all the way through (though the segmentation points will have
> per-tree state). If you don’t want to use segmentation, the ingress can
> tunnel one copy to each sub-domain and inside each sub-domain you can have
> efficient replication.
>
>
>
> Jeffrey
>
>
>
> *Sent:* Tuesday, January 26, 2021 10:39 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Jeffrey (Zhaohui)
> Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia -
> CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>;
> [email-masked]; 'Toerless Eckert' <[email-masked]>
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Monday, January 25, 2021 10:08 PM
> *To:* Huaimo Chen <[email-masked]>; Jeffrey (Zhaohui) Zhang <
> zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa)
> <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked] <
> [email-masked]>; 'Toerless Eckert' <[email-masked]>
> *Subject:* RE: [pim] pim wg adoption call for
> Zzh3> BIER-TE won’t use 10k bits in the packet. It will use a finite
> number of bits (e.g. 512 bits or  1024 bits) with multiple sets, just like
> you break the entire tree into different sub-trees. The comparison is, say
> with 1024 bits as encoding space, how many nodes/links can each solution
> encode. I don’t see how draft-chen can do better.
>
> Zzh3> The general SRv6 network programing idea is that an IPv6 address is
> broken into the locator part and func/arg part. The locator part gets
> traffic to a node and the func/argc part is looked up to decide what to do
> next. SRv6-P2MP follows that perfectly, so **nothing is new**. When I
> said it is “like” existing MPLS P2MP, I should also have said that it uses *
> *existing** SRv6 mechanism.
>
> Zzh3> Jeffrey
>
>
>
> *Sent:* Monday, January 25, 2021 11:45 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Jeffrey (Zhaohui)
> Zhang <zzhang=[email-masked]>; Bidgoli, Hooman (Nokia -
> CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>;
> [email-masked]; 'Toerless Eckert' <[email-masked]>
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Sunday, January 24, 2021 11:26 PM
> *To:* Huaimo Chen <[email-masked]>; Jeffrey (Zhaohui) Zhang <
> zzhang=[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa)
> <[email-masked]>; Stig Venaas <[email-masked]>; [email-masked] <
> [email-masked]>; 'Toerless Eckert' <[email-masked]>
> *Subject:* RE: [pim] pim wg adoption call for
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 Jan 2021 08:50:54 -0500

See IPv6 Jumbo grams in IANA IPv6 parameters codepoint.

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

0xC2 11 0 00010 Jumbo Payload [RFC2675 <https://www.iana.org/go/rfc2675>]

On Thu, Jan 28, 2021 at 8:48 AM Gyan Mishra <[email-masked]> wrote:

> RFC 2765 specifies a hbh options Jumbo payload option that carried a 32
> bit length field 65,536 and 4,294,967,295 octets in length. Packets with
> such long payloads are referred to as
>
>    "jumbograms".
>
>
>> zzhang=[email-masked]>; Bidgoli, Hooman (Nokia -
>> [email-masked] <[email-masked]>; 'Toerless Eckert' <[email-masked]>
>> zzhang=[email-masked]>; Bidgoli, Hooman (Nokia -
>> [email-masked] <[email-masked]>; 'Toerless Eckert' <[email-masked]>
>> 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/
>> 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).
>>

*Gyan Mishra*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Jan 2021 15:45:09 +0000

Hi Gyan,

From: pim <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Thursday, January 28, 2021 at 8:48 AM
To: "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
Cc: Toerless Eckert <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

All,

Huaimo has provided some valuable responses to scaling issues.  One point to note as far as scaling is that most all provider run Jumbo frames 9216 MTU and IPv4 length is 16 bits which can support up to 65,535 size packet.

IPv6 header natively supports a 16 bit header length which is the same as IPv4.

RFC 2765 specifies a hbh options Jumbo payload option that carried a 32 bit length field 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as

   "jumbograms".

All router and switch vendors today support super jumbo which is payload length between 9000 and 65535 capping today at 9216.

In the future as memory and buffer sizes increase in hardware fixed function ASIC FPGA or programmable NPU  for packet IO processing the sizes will eventually jump to 65535.  The next big step will be jumbo grams.  😀

With SRv6 unlike SR-MPLS traditional MPLS based PTA cannot be leveraged such as RAVP-TE or mLDP, so the options for P2MP MDT is very limited and If you don’t want the source node overhead of IR or SR replication SID, you just have BIER as your only option.

Operators love having options and this draft provisss a valuable option that does not require expensive upgraded to support BFR BIER.

But you will require an even more expensive upgrade to support the SRv6 network function to process the MDT subtree in the segment list.

Acee

I support WG adoption as stated and as this draft is very promising for operators as an SRv6 “BIER alternative”.

Thanks

Gyan

On Wed, Jan 27, 2021 at 9:13 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Huamo,

“For a network with 4k nodes”, how large could a multicast tree be, and with draft-chen, how do you encode that tree in packets? How many copies would you send if each copy is only for a sub-tree?

A large network can be divided into BIER sub-domains, each with a smaller bitstring. If you use tunnel segmentation then you can have efficient replication all the way through (though the segmentation points will have per-tree state). If you don’t want to use segmentation, the ingress can tunnel one copy to each sub-domain and inside each sub-domain you can have efficient replication.

Jeffrey

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 26, 2021 10:39 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Stig Venaas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] pim wg adoption call for draft-chen-pim-srv6-p2mp-path-01

Hi Jeffrey,

Best Regards,
Huaimo

Hi Huaimo,

can be encoded.

Zzh3> Jeffrey

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

previous responses.

finite size.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

can be encoded.

Zzh2> Jeffrey

Zzh> Jeffrey

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jan 2021 12:19:27 -0800

Thanks for great discussion, please keep it going. It is refreshing to have
technical discussions on the list.

The adoption deadline has ended, and at least for now, there is not a rough
consensus for adoption.

Please continue the discussion on the pim wg list, and it may be worth
discussing in spring as well. We will reconsider adoption if based on
further discussion and draft revisions, there may be a rough consensus. The
key thing is to consider why several people are currently opposed to
adoption, and see if any of the issues raised can be addressed.

It is also possible that some of the work should be done in spring, or at a
minimum that we get input from spring, so authors, please try to get input
on the draft there.

Regards,
Stig

On Thu, Jan 28, 2021 at 7:45 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Hi Gyan,
>
>
>
> *From: *pim <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Thursday, January 28, 2021 at 8:48 AM
> *To: *"Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
> *Cc: *Toerless Eckert <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [pim] pim wg adoption call for
> But you will require an even more expensive upgrade to support the SRv6
> network function to process the MDT subtree in the segment list.
>
>
>
> Acee
>
>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 Jan 2021 18:27:32 -0500

Understood.

What is nice about SRv6 is you have the PHP function to support PE’s not
yet SRv6 capable SRH processing as well as SRv6-BE w/o SRH that you can
phase your brown field deployments to being fully SRv6 capable  over time
so you don’t have to upgraded all nodes all at once unless you are building
a brand new greenfield core.

Kind Regards

Gyan

On Thu, Jan 28, 2021 at 10:45 AM Acee Lindem (acee) <[email-masked]> wrote:

> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 29 Jan 2021 03:15:31 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo

Sent: Wednesday, January 27, 2021 9:13 PM

Hi Huamo,

[HC5]: “For a network with 4k nodes” is for comparing/discussing scalabilities
of two solutions. In general, a large network seems used to compare/discuss
scalabilities.
The following is some discussions/comparisons on scalabilities using
a small network.
For a network (or sub-domain) with 0.25k nodes, there can be 2k links and
4k BitPositions.
When we use 1024 bits with multiple sets in the packet header,
the number of sets and the size of the set need to represent 4k BitPositions,
but 1024 bits contains a sub-tree that can be encoded in 1024 bits.
If the size of the set is 64 bits, the number of sets needs to be 6 bits.
Each set is encoded using 70 (64 bits for BitString + 6 bits for SI) bits.
1024 bits can contain 1024/70 = 14 sets.
For a sub-tree traversing 14 links with BitPositions in 14 sets,
1024 bits encodes 14 links of this sub-tree in BIER-TE.
With a good SID compression, the size of compressed SID can be 17 bits
(8 bits for node IDs, 3 bits for branches, 6 bits for number of SIDs),
1024 bits can encode 1024/17 = 60 links/nodes of a sub-tree in draft-chen.
For a big multicast tree crossing a large network, it will be split into
a number of sub-trees by both solutions such that each of the sub-trees
can be encoded in a finite space such as 1024 bits.
It seems that there may be more sub-trees in BIER-TE.
In general, more sub-trees means more copies.

[HC5]: Dividing a large network into small BIER sub-domains seems not help
much according to the above discussions/comparisons. In addition, it has the
following side effects:
1) More network OAMs (planning division, doing division),
2) More states in the network (per-tree states in domain borders), and
3) More work for having an end-to-end (E2E) multicast tree (i.e., multicast
tree crossing the network) since we need to have a number of sub-multicast
trees in some sub-domains and stitch them together to form the E2E multicast
tree.

Jeffrey

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

can be encoded.

Zzh3> Jeffrey

Hi Jeffrey,

Best Regards,

Huaimo

Hi Huaimo,

previous responses.

finite size.

M > N*u for N < 10k/40)

u = 40, N*(s+b) > N*u )

can be encoded.

Zzh2> Jeffrey

Zzh> Jeffrey