Subject: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 09:55:29 -0500

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: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 14 Mar 2022 15:34:53 +0000

Hi All

As an co-author of this draft I support this draft.

Currently there is no answer for multicast in a segment routing domain, enabling traditional multicast protocols will create an overhead which is not acceptable.

Clean/Lean network from control point of view is the key of future network deployments. This means simplifications of the control plane overlay and of course single IGP underlay. P2MP policy provides this.

P2MP policy is a controller specific policy where the controller learns of the root and the leaves of the tree and calculates the Tree and downloads the appropriate replication segments on the path of the tree. To program the policy and its replication segments there are 2 technologies, PCEP and BGP. As we all know it comes down to the operator choice to implement one or the other or both in the network.

In addition the strength of this draft is reusing the unicast BGP SR TE Policy infrastructure, objects and SUB-TLVs. This draft basically enhances BGP SR TE Policy to P2MP policy.

>From NLRI point of view there are 2 NLRI one for P2MP policy and its candidate paths, which is relevant to the root (head-end) and another for downloading the replication segments which are the forwarding entities and sid-list. There was no need to download the P2MP policy and the candidate paths on the transit and the leaves hence why the separation creates a clean and optimised solution.

Regards

Hooman

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

Cheers, Susan Hares

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Thu, 17 Mar 2022 00:45:31 +0000

Hi,

I fully support this document for WG adoption.

Yes, it does.

Yes, it is correctly specified. The text can be improved if needed once adopted.

Yes, it does. Again the text can be refined once adopted.

Yes.

This SR P2MP policies should be able to be advertised in BGP as an option, just like it is done for unicast SR policies.

Thanks.
Jorge

From: BESS <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 10, 2022 at 6:56 AM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: [bess] 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)

Cheers, Susan Hares

---

From: "Kundu, Tanmoy (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Mon, 21 Mar 2022 16:49:35 +0000

I support.

Thanks,
Tanmoy

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

Cheers, Susan Hares

---

From: "Arvind Venkateswaran (arvvenka)" <[email-masked]>
Date: Mon, 21 Mar 2022 16:53:32 +0000

Support.

Thanks,
Arvind.

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

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

---

From: "Serge Krier (sekrier)" <[email-masked]>
Date: Mon, 21 Mar 2022 17:38:35 +0000

Hi bess & idr WG's,

As co-author, I support this draft.

Regards,
Serge.

________________________________
From: BESS <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Thursday, March 10, 2022 15:55
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

via BGP?

Cheers, Susan Hares

---

From: "Rajarathinam, Saranya (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Mon, 21 Mar 2022 17:42:22 +0000

I support.

Thanks
Saranya

From: pim On Behalf Of Kundu, Tanmoy (Nokia - US/Sunnyvale)
Sent: Monday, March 21, 2022 9:50 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pim] [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

I support.

Thanks,
Tanmoy

Cheers, Susan Hares

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 22 Mar 2022 03:33:55 +0000

Support adoption of this draft.

Cheers, Susan Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 22 Mar 2022 07:07:57 +0000

Hi Sue and authors,

I've read the latest version of this document and have some questions,

I understand this document provides one mechanism to build P2MP Trees using the tree SIDs and the unicast SR SIDs.  While it is not quite clear to me how much it is analogous to SR policy, and whether BGP is the suitable tool for its provisioning.

1.       This document introduces 3 route types. The first route type is provisioned to the headend node (the root node), the second route type is used to provision the replication SID on each replication node individually, and the third route type is used to progress each outgoing interface individually for a replication cross connect.  This is different from SR Policy which only needs to be provisioned on the headend nodes of the path, and it seems that this is an extension to BGP for the provisioning of individual transit nodes and interfaces with different information.

2.       In this document, a P2MP candidate path carried in BGP tunnel encaps attribute consists of several path instances, one of the path instance is active, the others are used as backup paths. And under a path instance, it may contain a protection segment list.

While in BGP SR Policy,  the tunnel encaps attribute consists of multiple segment lists under one candidate path, and all the segment lists are used for load balancing purpose. Different candidate paths can be used as either active or backup paths, but they are carried with different SR Policy NLRIs. Since this document says it reuses the concept of candidate path, It would be helpful if it could highlight the difference from SR Policy candidate path in the structure.

Best regards,
Jie

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

Cheers, Susan Hares

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 22 Mar 2022 07:34:47 +0000

Hi Jie

Inline

Thanks
Hooman

From: Idr <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 22, 2022 3:08 AM
To: Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [pim] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

Hi Sue and authors,

HB> P2MP policy itself can be used to create a tree or it can be used for ingress replication. There was a very lengthy discussion in SPRING and PIM and we decided to put the replication segment in the SPRING as replication segment has the segment-List for each OIF which can use the source routing concept for each OIF.

HB> please have a look at the draft draft-ietf-spring-sr-replication-segment-07 - SR Replication Segment for Multi-point Service Delivery<https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/> and draft-voyer-pim-sr-p2mp-policy-02 - Segment Routing Point-to-Multipoint Policy (ietf.org)<https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/> for details

HB> this is why we have 3 route type. The P2MP policy is really created a policy for PMSIs to steer the traffic into the tree, whether it is a tree or source replication.

HB> the replication SID route type is really use to build the replication state at the replicating node and the IIF and OIF information and not the segment-list itself

HB> the last route type which builds the segment-list it self is more inline with SR Policy and is using most of that concept.

HB> again for multicast the segment-list is really the OIF of the replication segment and the source routing comes in from one replication segment to the next replication segment.

HB> yes correct, if you go with the explanation above, the policy is the steering point into the Tree and first replication segment. Hence at the head end (p2mp policy) we needed the concept of candidate path redundancy. Each candidate path is a separate tree (tree or source replication) with the one with highest preference being the active tree. Again because we are trying to bring redundancy to a tree, the entire tree and its replication segments need to be part of a unique candidate path. Each tree/candidate path can be globally optimize, hence the path instance. Where a new path instance is created for that tree/candidate path and the MBB procedure will move the traffic from one path instance to the next. We tried to leverage the SR policy for programming of the OIFs which are in par more with source routing and sr policy.

Best regards,
Jie

Cheers, Susan Hares

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 24 Mar 2022 18:29:34 +0000

Dear all,
I support the adoption of this draft. It completes the Segment Routing toolkit by adding support for P2MP trees. Our customers are asking for a solution that complements the unicast SR policy using BGP control plane advertisement.

I added a few elements of response inline below.

Regards,
Mustapha.

MA> Yes.

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?
MA> Yes. The NRLI is structured with a set of information to specify segment list at origination and replication points.

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?
MA> There is a good starting point. I am sure the working group members will enhance it.

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?
MA> Yes. This complements the SR P2P (unicast) policy specification.

5) Do you think this SR P2MP policies should not be advertised
via BGP?
MA> BGP is a good control plane for SR P2MP policies and complements the BGP unicast policy specification.

Cheers, Susan Hares