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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Jie

Inline

Thanks
Hooman

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

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.





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.



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.

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

From: pim [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [pim] 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