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

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

Hi Jie

Inline

Thanks
Hooman

From: Idr  On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 22, 2022 3:08 AM
To: Susan Hares ; i...@ietf.org; p...@ietf.org; bess@ietf.org
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
 and draft-voyer-pim-sr-p2mp-policy-02 - Segment Routing Point-to-Multipoint 
Policy 
(ietf.org) 
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:pim-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: i...@ietf.org; p...@ietf.org; 
bess@ietf.org
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) 

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

[Dongjie (Jimmy)]

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:pim-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, March 10, 2022 10:55 PM
To: i...@ietf.org; p...@ietf.org; bess@ietf.org
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess