Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 10:27:40 -0500

IDR WG: 

If you just wish to respond to the IDR list, 

you may respond to this email on the adoption call. 

Cheers, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

This begins a 2 week WG adoption call for: 

draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022) 

You can obtain the draft at: 

https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider: 

1)  Does this technology support the SR P2MP features 

that distributes candidate paths which connect 

a multicast distribution tree (tree to leaves). 

2) Is the technology correctly specified for the 

NLRI (AFI/SAFI) and the tunnel encapsulation attribute 

additions (sections 2 and 3)? 

3) Does the P2MP policy operation (section 4) 

provide enough information for those implementing this 

technology and those deploying the technology? 

4) Do you think this multicast technology is a good

Place to start for P2MP policy advertisement via BGP? 

5) Do you think this SR P2MP policies should not be advertised 

via BGP? 

Cheers, Susan Hares

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 14 Mar 2022 15:15:51 +0000

Hi IDR,

As co-author, support adoption.

(1) yes. The solution builds on the existing patterns laid out by unicast SR Policy, adding support for multiple egress SID lists to establish the mulicast tree in a straight forward manner to achieve draft-ietf-pim-sr-p2mp-policy. Considerations of protection and optimization are embedded in the document.

(2) yes. The NLRI definition has been simplified to contain only minimum fields as required. The separation of policy vs replication segment vs outgoing segments simplifies the understanding and troubleshooting routes for headend vs root/transit/leaf, as well as the BGP message exchange overhead needed to perform simple path updates. The TEA for replication segment route is following the unicast model but tweaked slightly to carry protection info.

(3) In general, yes. More text and/or examples for section 4.3 global optimization is likely required, which could be added as the document becomes more refined.

(4) yes. As mentioned, the building blocks taken from unicast, combined with the route decoupling solves the sr-p2mp/replication segment architecture in BGP in a consistent manner.

(5) I think the capability to advertise in BGP should exist. While an alternative mechanism is certainly PCEP, which is also progressing in PCE WG, but as experienced with unicast there are different preferences and operational considerations with using BGP vs PCEP to inject tunnel state into the network. This draft permits those who wish to use BGP, likely already coming from unicast, to follow the same paradigm but with multicast.

Thanks
Andrew

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 10, 2022 at 10:29 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Mar 2022 00:43:03 -0400

Hi Sue & IDR WG

I support WG adoption.

This document provides the final building block to complete the SR P2MP
solution using replication SIDs that are stitched together via Tree SID to
instantiate the SR P2MP tree, and now this draft which provides the SR-TE
policy P2MP variant  to finally instantiate the SR P2MP MDT.

SR Replication segment
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment

SR P2MP policy
https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-04

PCEP extension for SR P2MP policy
https://datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-03

SR Policy
https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20

 Yes.  As stated about this draft provides an P2MP extension to SR-TE
policy draft

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

I think it would be appropriate to change the name of the draft so it
reflects as stated in the introduction that this draft is a P2MP variant or
extension to SR-TE policy

OLD

Advertising p2mp policies in BGP

draft-hb-idr-sr-p2mp-policy-04

NEW

Advertising Segment Routing p2mp policies in
BGPdraft-hb-idr-sr-p2mp—te-policy-04

This draft defines a new AFI/SAFI for P2MP as part of the SR-TE extension
to support P2MP.

As SR-TE already uses RFC 9012 BGP tunnel encapsulation attribute and color
extended community this draft as this draft is a variant It as well
utilizes the tunnel encapsulation attribute section 3.2.

 I think the section is a good start but needs more details for
implementation

 Yes I think it’s appropriate to create a variant of current SR-TE policy
draft  to support P2MP

via BGP?

I think this is a data plane forwarding construct and not MVPN control
plane and this draft is in fact a variant or SR-TE policy which uses BGP to
advertise the SR-TE policy so now this draft does exactly the same using
the same semantics using BGP but now to advertise the SR P2MP replication
SID and Tree SID NLRI.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

Kind Regards

Gyan

On Mon, Mar 14, 2022 at 11:16 AM Stone, Andrew (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> (1) yes. The solution builds on the existing patterns laid out by unicast
> SR Policy, adding support for multiple egress SID lists to establish the
> mulicast tree in a straight forward manner to achieve
> draft-ietf-pim-sr-p2mp-policy. Considerations of protection and
> optimization are embedded in the document.
>
>
>
> (2) yes. The NLRI definition has been simplified to contain only minimum
> fields as required. The separation of policy vs replication segment vs
> outgoing segments simplifies the understanding and troubleshooting routes
> for headend vs root/transit/leaf, as well as the BGP message exchange
> overhead needed to perform simple path updates. The TEA for replication
> segment route is following the unicast model but tweaked slightly to carry
> protection info.
>
>
>
> (3) In general, yes. More text and/or examples for section 4.3 global
> optimization is likely required, which could be added as the document
> becomes more refined.
>
>
>
> (4) yes. As mentioned, the building blocks taken from unicast, combined
> with the route decoupling solves the sr-p2mp/replication segment
> architecture in BGP in a consistent manner.
>
>
>
> (5) I think the capability to advertise in BGP should exist. While an
> alternative mechanism is certainly PCEP, which is also progressing in PCE
> WG, but as experienced with unicast there are different preferences and
> operational considerations with using BGP vs PCEP to inject tunnel state
> into the network. This draft permits those who wish to use BGP, likely
> already coming from unicast, to follow the same paradigm but with multicast.
>
>
>
> Thanks
>
> Andrew
>
>
>
> *From: *Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Thursday, March 10, 2022 at 10:29 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> IDR WG:
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 21 Mar 2022 14:17:39 +0000

Hi working group,

As a co-author, I support the adoption of this work.

Sue, the questions are covered by Andrew and peer as co-author. Let us know if you have more questions.

Thanks
Dan

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 10, 2022 at 10:27 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXT]Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Mon, 21 Mar 2022 22:02:35 +0000

Hi Sue,

I support adoption of the draft.  Below is the response for specific consideration asked for each point:

1.      On lines similar to SR policy advertisement in BGP, draft extends BGP procedures to download SR P2MP policy and reuses the concept of a candidate path. It supports P2MP policy route, replication segment route and OIFs route of replication segment to create multicast distribution tree.

2.      Yes its defined correctly with different route types advertising tree information. Below are the important aspects

a.      Procedures avoid downloading all OIFs in single BGP route, hence avoiding complex TEA attribute.

     *   Individual OIF can be added, modified and withdrawn. No complete tree download each time.

c.       BGP packing efficient allowing distinct trees replication segments and OIFs packed in single update.

3.      Route types provide

a.      P2MP tree information to head end

b.      Replication segment information to replication node

c.       OIF information

4.      Any deployment which uses BGP advertisement for P2P SR policy should have similar procedures to download P2MP trees from controller. SO yes, such procedures are required.

5.      No, due to reasons stated in point 4.

Regards

Swadesh

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 10, 2022 at 7:29 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 22 Mar 2022 07:33:01 -0400

Swadesh:

Thank you your clear responses to my questions. 

Sue 

From: Swadesh Agrawal (swaagraw) [mailto:[email-masked]] 
Sent: Monday, March 21, 2022 6:03 PM
To: Susan Hares; [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi Sue,

b.	Individual OIF can be added, modified and withdrawn. No complete tree download each time.

Regards
Swadesh

IDR WG: 

Cheers, Sue 

via BGP? 

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Mar 2022 10:29:39 +0000

I am sorry for responding late. I somehow missed this.

I think we should discuss the relationship with daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[External Email. Be cautious of content]

IDR WG:

Cheers, Sue

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 9:55 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>

Cheers, Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 25 Mar 2022 07:16:45 -0400

Jeffrey: 

If this is process question, then 

a) this call was given 2 weeks ago to IDR and BESS.  

b)I check with BESS chairs and they agreed to adoption call with BESS
copied. 

If you are concerned about specific technical issues, please provide
detailed comments today as the 2 week adoption call closed yesterday. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares; [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
Adoption call

I think we should discuss the relationship with
daft-ietf-bess-bgp-multicast-controller further before adopting this.

Thanks.
Jeffrey

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
Adoption call

IDR WG: 

Cheers, Sue 

https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr
-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCk
FZJodxFk8aTGCpYg34$> 

via BGP? 

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Mar 2022 11:49:28 +0000

Hi Sue,

I am not questioning the process. Indeed, it is my own fault that I missed this.

I sent my email in a hurry after I realized that I missed it. I am in the middle of providing more comments now - will send out later today.

Thanks.
Jeffrey

Juniper Business Use Only
From: Susan Hares <[email-masked]>
Sent: Friday, March 25, 2022 12:17 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Jeffrey:

If this is process question, then
a) this call was given 2 weeks ago to IDR and BESS.
b)I check with BESS chairs and they agreed to adoption call with BESS copied.

If you are concerned about specific technical issues, please provide detailed comments today as the 2 week adoption call closed yesterday.

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Thanks.
Jeffrey

Juniper Business Use Only
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:28 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Mar 2022 14:47:20 +0000

[+ BESS, PIM]

Hi,

I realized that in a hurry I did not respond to the specific questions below. Please see zzh> next to the questions.

Looks like that there are some comments on BESS/PIM list and I will go through those to see if I have any addition/follow-up on those.

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/ is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/ why it was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way.

Zzh> It is one way to use BGP to support that. The bess draft specifies another way.

Zzh> The specified SAFI and tunnel encapsulation attribute additions are one way for the BGP signaling for SR-P2MP. The bess draft specifies another way.

Zzh> Both ways are good place to start. We just need to figure out how to proceed with the two proposals.

Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to discuss the two ways and figure out how to proceed. The authors have discussed before though we have not reached consensus.
Zzh> Thanks!
Zzh> Jeffrey

Cheers, Susan Hares

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Mar 2022 15:34:00 +0000

Hi All

HB> yes there was discussion and there was no consensus to merge the 2 drafts as their approach is widely different. The authors of this draft have kept the implementation very close to unicast BGP SR Policy for the segment list, which simplifies the implementation and deployment of the technology. As you said there seems to be two way to download this policy and the segment list and we can work on both.
Given the solid support I don't see why the adoption of this draft should  be delayed because of these arguments.

Thanks
Hooman

From: pim <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]' <[email-masked]>; 'BESS' <[email-masked]>
Subject: Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[+ BESS, PIM]

Hi,

Juniper Business Use Only
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 6:30 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 28 Mar 2022 05:39:30 +0000

WG,

I agree with Jeffrey that the BESS adopted draft draft-ietf-bess-bgp-multicast-controller provides
Solution in the same problem space. It is good to discuss the two drafts before adopting
draft-hb-idr-sr-p2mp-policy in IDR.

Rgds
Shraddha

Sent: Friday, March 25, 2022 8:17 PM

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSIG0DaUH9$> is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSICdM0D1B$> why it was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way.

Cheers, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 10:46:46 +0200

Hi,

It also needs to be observed that
draft-ietf-bess-bgp-multicast-controller has a broader scope and also
covers mLDP functionality what may be extremely useful for networks which
are not green field and would like to transition from current to new
multicast trees.

Having solution in IDR which covers multicast tree setup partially and at
the same time a more complete one which has been already adopted and is
progressing as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which
are used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS
with draft-ietf-bess-bgp-multicast-controller since that WG is center of
gravity for all VPN/multi-tenant multicast related work.

Kind regards,
Robert

On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> WG,
>
>
>
> I agree with Jeffrey that the BESS adopted draft
> draft-ietf-bess-bgp-multicast-controller provides
>
> *From:* Idr <[email-masked]> *On Behalf Of * Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 8:17 PM
> *To:* Susan Hares <[email-masked]>; [email-masked]
> *Cc:* [email-masked]' <[email-masked]>; 'BESS' <[email-masked]>
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> [+ BESS, PIM]
>
>
>
> Hi,
>
>
>
> I realized that in a hurry I did not respond to the specific questions
> below. Please see zzh> next to the questions.
>
>
>
> Looks like that there are some comments on BESS/PIM list and I will go
> through those to see if I have any addition/follow-up on those.
>
>
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 6:30 AM
> *To:* Susan Hares <[email-masked]>; [email-masked]
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 10:28 AM
> *To:* [email-masked]
> *Subject:* Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> IDR WG:
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/__;!!NEt6yMaO-gk!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$>
>
>
>
> Zzh> I want to point out that
> https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSIG0DaUH9$>
> is another way to do the same. I also explained in
> https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!VA2RfAmcBA46YljU7KP0svRjk7kWVgXhzfsGzul45PZ5GQ32gWZgaclSICdM0D1B$>
> why it was in the bess WG.
>
> Zzh> In addition, the bess draft supports **other** multicast trees (IP,
> mLDP besides SR-P2MP) using a consistent way.
>
>
>
> Zzh> The specified SAFI and tunnel encapsulation attribute additions are
> one way for the BGP signaling for SR-P2MP. The bess draft specifies another
> way.
>
>
>
> Zzh> I do think BGP signaling for SR P2MP is appropriate. We just need to
> discuss the two ways and figure out how to proceed. The authors have
> discussed before though we have not reached consensus.
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
>
>
> Cheers, Susan Hares
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 28 Mar 2022 09:26:07 +0000

Hi,

I have always had my opinion that Multicast Tree Building procedure is a very dynamic procedure, however BGP is skilled at stable-data (like prefix, or aggregated MVPN state on edge of a provider) driven “PUSH” thing.

I have almost forget the detail of the draft-ietf-bess-bgp-multicast-controller through I had read it long ago.

I would suggest that the relationship of the draft-ietf-bess and the polling draft can be re-evaluated.

Thanks,
Jingrong

From: pim [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, March 28, 2022 4:47 PM
To: Susan Hares <[email-masked]>
Cc: [email-masked]; Shraddha Hegde <shraddha=[email-masked]>; [email-masked]; BESS <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Subject: Re: [pim] [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi,

It also needs to be observed that  draft-ietf-bess-bgp-multicast-controller has a broader scope and also covers mLDP functionality what may be extremely useful for networks which are not green field and would like to transition from current to new multicast trees.

Having solution in IDR which covers multicast tree setup partially and at the same time a more complete one which has been already adopted and is progressing as a WG document is never a good thing.

Besides I am puzzled since when IDR is accepting protocol extensions which are used to setup multicast distribution trees ?

When the first version of the draft was written (Sep 2017) we went to BESS with draft-ietf-bess-bgp-multicast-controller since that WG is center of gravity for all VPN/multi-tenant multicast related work.

Kind regards,
Robert

On Mon, Mar 28, 2022 at 7:39 AM Shraddha Hegde <shraddha=[email-masked]<mailto:[email-masked]>> wrote:
WG,

Rgds
Shraddha

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; 'BESS' <[email-masked]<mailto:[email-masked]>>

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Mar 2022 19:39:08 +0000

Hi,

When it comes to SR-P2MP state downloading, there are three aspects involved here:

  1.  NLRI to encode policy information
  2.  NLRI to encode <tree/path/instance, node> identification
  3.  Tunnel Encapsulation Attribute (TEA) that encodes actual replication branches

The major difference between the two ways is on #3. Indeed, we could not reach consensus - there are two ways of encoding the TEA and each has its own considerations. The draft-ietf-bess way (even when used for SR-P2MP) is aligned with other non-SR multicast trees (IP/mLDP) for a unified approach, while draft-hb is aligned to unicast BGP SR policy.

I want to initiate a discussion and I can understand that WGs may eventually choose to allow both ways for #3. Even so, I think we should strive for consistent approach at least for #1 and #2 (and for that I am not saying that draft-ietf-bess way must be used). For example, use the same SAFI and route types for both ways, but use different TEA encoding methods.

Thanks.

Jeffrey

Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Sent: Friday, March 25, 2022 11:34 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]' <[email-masked]>; 'BESS' <[email-masked]>
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

Hi All

Thanks
Hooman

From: pim <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, March 25, 2022 10:47 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>; 'BESS' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Zzh> I want to point out that https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$> is another way to do the same. I also explained in https://mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$> why it was in the bess WG.
Zzh> In addition, the bess draft supports *other* multicast trees (IP, mLDP besides SR-P2MP) using a consistent way.

Cheers, Susan Hares

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 29 Mar 2022 10:30:42 -0400

Dear authors

Can you describe in more detail the relationship and interaction between
the two SR P2MP variants below:

Defines new SAFI for SR P2MP variant
https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04

Does this draft utilize all the drafts below Tree sid / Replication sid and
SR P2MP MVPN procedures for auto discovery etc.

Defines Tree SID stitching of replication SID SR policy P2MP variant
https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00

Replication SID

Defines new SR P2MP PTA using MVPN procedures
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp

Kind Regards

Gyan

On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> The major difference between the two ways is on #3. Indeed, we could not
> reach consensus – there are two ways of encoding the TEA and each has its
> own considerations. The draft-ietf-bess way (even when used for SR-P2MP) is
> aligned with other non-SR multicast trees (IP/mLDP) for a unified approach,
> while draft-hb is aligned to unicast BGP SR policy.
>
>
>
> I want to initiate a discussion and I can understand that WGs may
> eventually choose to allow both ways for #3. Even so, I think we should
> strive for consistent approach at least for #1 and #2 (and for that I am
> not saying that draft-ietf-bess way must be used). For example, use the
> same SAFI and route types for both ways, but use different TEA encoding
> methods.
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
>
>
> *From:* Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
> *Sent:* Friday, March 25, 2022 11:34 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Susan Hares <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> HB> yes there was discussion and there was no consensus to merge the 2
> drafts as their approach is widely different. The authors of this draft
> have kept the implementation very close to unicast BGP SR Policy for the
> segment list, which simplifies the implementation and deployment of the
> technology. As you said there seems to be two way to download this policy
> and the segment list and we can work on both.
>
> Given the solid support I don’t see why the adoption of this draft should
> be delayed because of these arguments.
>
>
>
> Thanks
>
> Hooman
>
>
>
> *From:* pim <[email-masked]> *On Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* Friday, March 25, 2022 10:47 AM
> *Subject:* Re: [pim] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to
> 3/24/2022) - Adoption call
>
>
>
> [+ BESS, PIM]
>
>
>
> Hi,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$>
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/KObeSgKPu3HRbd0ZN7L7fWq_Eto/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$>
-- 

*Gyan Mishra*

*M 301 502-1347*