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

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

1)  Does this technology support the SR P2MP features

that distributes candidate paths which connect

a multicast distribution tree (tree to leaves).

 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

2) Is the technology correctly specified for the

NLRI (AFI/SAFI) and the tunnel encapsulation attribute

additions (sections 2 and 3)?

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.

3) Does the P2MP policy operation (section 4)

provide enough information for those implementing this

technology and those deploying the technology?

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

4) Do you think this multicast technology is a good

Place to start for P2MP policy advertisement via BGP?

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

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

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) <
andrew.stone@nokia.com> wrote:

> 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 <idr-bounces@ietf.org> on behalf of Susan Hares <
> shares@ndzh.com>
> *Date: *Thursday, March 10, 2022 at 10:29 AM
> *To: *"idr@ietf.org" <idr@ietf.org>
> *Subject: *Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) -
> Adoption call
>
>
>
> 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:idr-bounces@ietf.org] *On Behalf Of *Susan Hares
> *Sent:* Thursday, March 10, 2022 9:55 AM
> *To:* idr@ietf.org; pim@ietf.org; bess@ietf.org
> *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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*

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