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

From: "Susan Hares" <[email-masked]>
Date: Tue, 5 Apr 2022 20:03:52 -0400

Jeffrey and Hooman: 

This adoption call runs until 4/8/2022.  The reason I have extended the 

adoption call is to determine what interaction there is between 

draft-hb-idr-sr-p2mp-policy-04.txt (which has interest in IDR) and 

draft-ietf-bess-bgp-multicast-controller-07.txt (adopted by BESS).  

I need your input on these questions in order to advise BESS, PIM, and IDR 

WG-chairs + WGS on the status of these drafts.   Please let me know if I am 

Unclear on my questions. 

This is the first of 3 lengthy technical messages.   

You indicated in 

https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/

"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 draft-ietf-bess-(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."

This post examines the TEA attribute discussion in section 3.1 of 

draft-ietf-bess-bgp-multicast-controller-07.txt draft. 

Section 3.1 specifies  two types of tunnels for TEA (RFC9012):

any encapsulation (3.1.1) and load balancing (3.1.2) 

plus interactions with PMSI (section 3.1.3), and 

4 Sub-TLVs.  In section 3.4.3 you provide signaling for the 

Policy to enter this tree, but you do not indicate how the 

two different tunnel types interact with

the tunnel types defined in draft-ietf-idr-segment-routing-te-policy-15.txt 

Section 2.4.4 of draft-ietf-idr-segment-routing-te-policy-15.txt

contains a new tunnel type: SR Policy and two groups of 

subTLVs: weight SubTLV and segment SubTLVS (A-K). 

1) how do the 3 Tunnel types interact? 

(all encapsulation, load balancing, and SR Policy type)

Please include in your discussion where this interaction is 

Described in the text. 

2)  How do these 3 tunnel types interact with the 

PMSI tunnels or Source-Active AD routes (types 1-3),

or ASM SPT (type 5) or C-multicast overlays (Type 6-7)? 

This is  (section 3.1.3)?  

3) draft-bess-bgp-multicast-controller states in section 1.7

on sr-p2mp: 

"An SR- Point-to-Multipoint (SR P2MP) policy is used to 

Define and instantiate a P2MP tree which is computed by a 

Controller." 

Section 3.4.2 defines the SR P2MP policy as  BGP 

Community container in the BGP Wide communities which 

Contains candidate path preference + TLVS.  

You state in section 3.4.2 

"The replicate state route for replication segments signaled to the 

root is also used to signal (parts of) the SR P2MP Policy - 

the policy name, the set of leaves [..optional], the preference of CP

and other information". 

3a) Are you proposing translating this from the SR Policy or what? 

3b) how are the atoms used in the policy? 

4) Give an example of how a simple scenario might be implemented

With section 3.4.3.1 and 3.4.3.2? 

Thank you, Sue 

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

[+ 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

[External Email. Be cautious of content]

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: 

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

In your comments for this call please consider: 

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.

1)  Does this technology support the SR P2MP features 

that distributes candidate paths which connect 

a multicast distribution tree (tree to leaves). 

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

2) Is the technology correctly specified for the 

NLRI (AFI/SAFI) and the tunnel encapsulation attribute 

additions (sections 2 and 3)? 

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.

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? 

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

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

via BGP? 

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: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2022 03:04:56 +0000

Hi Sue,

Please see zzh> below.

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Tuesday, April 5, 2022 8:04 PM
To: [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute

Jeffrey and Hooman:

You indicated in
https://mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/8k4Pkcg0aqIwPFbSULXepsaHDSw/__;!!NEt6yMaO-gk!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60NV8pr-N$>

"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

Zzh> These are two new tunnels (that are SR-agnostic); other existing tunnels can also be used.
Zzh> I now realize that I missed listing an SR-specific tunnel type "Segment List tunnel" in this section. It is discussed in section 3.4.3.1 and in the IANA section.

Zzh> Let me refer to draft-ietf-bess-bgp-multicast-controller as draft-bess, and refer to draft-hb-idr-sr-p2mp-policy as draft-hb.

zzh> There is no interaction with PMSI. Section 3.1.3 mentioned S-PMSI route because of this:
zzh> the bgp-multicast draft is about hop-by-hop signaling and it uses S-PMSI route to signal state for MP2MP upstream traffic, but the bgp-multicast-controller draft does not use S-PMSI route as the Replication State route can be used to signal state for both downstream and upstream traffic.

zzh> The "anyencap" and "load-balancing" tunnel types are not related to draft-ietf-idr-segment-routing-te-policy at all.
Zzh> The "segment list" tunnel "has a Segment List sub-TLV as specified in Section 2.4.4 of [I-D.ietf-idr-segment-routing-te-policy]", as described in in 3.4.3.1.

Zzh> draft-bess does not use SR Policy tunnel type even for SR-P2MP.

Zzh> They don't interact with those. 3.1.3 does not refer to those route types.

Zzh> In draft-bess, we did not define a separate route to encode the policy information. Rather, the policy information is encoded in a wide community that is attached to the replication state route for the tree root.
Zzh> In the offline discussion with the draft-hb co-authors long time ago, I did indicate that draft-bess can also take their approach to use a different route instead of using wide community. I alluded to that again in one of the emails for this adoption call.

Zzh> A policy has a name and a list of tree leaves among other things. As described in 3.4.2, a string atom can encode the policy name, and a prefix list atom can encode the set of leaves.
Zzh> Again, the policy can be encoded in a new route instead of a wide community (to align with draft-hb).

Zzh> Consider a tree node that has two replication branches. Branch 1 is to a downstream node1 with a node sid (label) 101; branch 2 is to another downstream node2 with a node sid (label) 102. Suppose that the path to node1 does not matter, but to node2 we want to use a particular path represented by a segment list <151, 152, 102>. Suppose traffic sent to this node on the tree has incoming tree sid/label 1000, and traffic replicated to node1 and node2 has tree sid/label 1001 and 1002 respectively (the same tree sid/label 1000 could also be used for all incoming/outgoing traffic, depending on the operator's choice - this is discussed in section 1.4).

Zzh> With the 3.4.3.1 approach, the tunnel encapsulation attribute (TEA) that is attached to the Replication State route will include three tunnels:
Zzh> 1) tunnel 1 for upstream information: anyencap tunnel; rpf sub-tlv (to indicate this is for upstream - section 3.1.4); tree-label-stack sub-tlv with label 1000 (section 3.1.5)
Zzh> 2) tunnel 2 for replication branch 1 to node1: segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <101, 1001>
Zzh> 3) tunnel 3 for replication branch 2 to node2: segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <151, 152, 102, 1002>

Zzh> With this TEA encoding, the receiving node programs its forwarding state so that incoming traffic with sid/label 1000 will be replicated to two downstream nodes using segment list <101, 1001> and <151, 152, 102, 1002> respectively.
Zzh> Encoding the upstream information as a tunnel has the advantage that in case of MP2MP, that upstream tunnel will also encode outgoing information for upstream traffic (from tunnel leaves towards root and other leaves), and a downstream tunnel will also have tree-label-stack sub-tlv to encode incoming information for upstream traffic.

Zzh> Section 3.4.3.2 of draft-bess basically says there could be another way to encode the replication information as specified in draft-hb. That section was added as an (unfinished/unsuccessful) attempt to consolidate both draft-bess and draft-hb approaches.
Zzh> In this example, my understanding of draft-hb approach is that three routes are needed (in addition to the route for the policy information):
Zzh> 1) a "Replication Segment Binding Sid" route; its NLRI will encode the incoming SID (1000 in this example). This is specified in 3.1.2 of draft-hb.
Zzh> 2) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 1
Zzh> 3) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 2

Zzh> The main difference is that one route is used for each upstream/downstream in draft-hb while in draft-bess, a single route is used with a TEA encoding all upstream/downstream information. I suppose there are pros and cons for each way, and I'll not get into which is better in this email, but one thing to notice is that the draft-hb way is not MP2MP friendly (obviously it is "out of scope" now, but it's good to be extensible).
Zzh> Thanks.
Zzh> Jeffrey

Thank you, Sue

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

[+ 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]<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

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]<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

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$>

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!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60HRG_456$> 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!WSzsQHy_SUQ2pW3C3graivvjrJLm2JLEVtUPyAYkHx-uuWaJLG17XPp60IkA8lid$> 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: Thu, 7 Apr 2022 03:41:10 +0000

Hi Sue/Jeffrey

As I am sure Jeffrey knows MP2MP is out of scope of SR-P2MP-Policy as the architectural draft name very clearly points this out.

draft-ietf-pim-sr-p2mp-policy

This document describes an architecture to construct a Point-to-
   Multipoint (P2MP) tree to deliver Multi-point services in a Segment
   Routing domain.  A SR P2MP tree is constructed by stitching a set of
   Replication segments together.  A SR Point-to-Multipoint (SR P2MP)
   Policy is used to define and instantiate a P2MP tree which is
   computed by a PCE.
Again I want to point out the main vision behind SR-P2MP-POLICY. Simplicity and providing the providers a set of simple tools with low learning curve to deploy multicast services in their Segment Routing networks.
Even from standardization point of view that is the goal, hence specific, simplified methods are preferred over methods that are trying to address all multicast transport types.

Thanks
Hooman

From: Idr <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Wednesday, April 6, 2022 11:05 PM
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2022 03:43:12 +0000

Hi Sue,

In the following email I said:

    "The main difference is that one route is used for each upstream/downstream in draft-hb while in draft-bess, a single route is used with a TEA encoding all upstream/downstream information. I suppose there are pros and cons for each way ..."

If it is considered better to use multiple routes for some scenarios (e.g., when there are many replication branches), draft-bess can handle that as well. Revision -06 had the following text in section 1.3 https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-06#section-1.3:

   Suppose that for a particular tree, there are two downstream routers
   D1 and D2 for a particular upstream router U.  A controller C may
   send two Leaf A-D routes to U, as if the two routes were originated
   by D1 and D2 but reflected by the controller.  Alternatively, C could
   just send one route to U, with the Upstream Router's IP Address field
   set to U's IP address and the TEA specifying both the two downstreams
   and its upstream (see Section 3.1.4<https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-06#section-3.1.4>).  In this case, the Originating
   Router's Address field of the Leaf A-D route is set to the
   controller's address.

Although revision -07 only uses one route (the red text) but it is easy to add the purple text back to allow multiple routes. In that case, instead of one route for each replication branch as in draft-hb, each route in draft-bess may use TEA to encode multiple branches for flexibility.

(Note: in -07 the Leaf A-D route is replaced with Replication State route to remove unnecessary MVPN tie as much as much as possible).

Thanks.
Jeffrey

Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang
Sent: Wednesday, April 6, 2022 11:05 PM
To: Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2022 12:40:21 +0000

Hi,

Please see zzh2> below.

Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Sent: Wednesday, April 6, 2022 11:41 PM
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 - TEA attribute

Hi Sue/Jeffrey

Zzh2> Of course; but it would be nice to have a base mechanism that can be easily extended to cover MP2MP. Draft-bess does have that.

Zzh2> draft-bess does have a lot of contents, but its method is *not* more complicated than draft-hb when it comes to a particular multicast tree like SR-P2MP. Section 1.7 and 3.4 in draft-bess cover SR-P2MP based on the generic mechanism (which is actually not much different from draft-hb's SR-specific approach besides how policy info is signaled, but as I said we can take draft-hb approach for signaling the policy info).

Zzh2> I can understand the desire to have a separate short spec that covers SR-P2MP only and I am fine with that, but it's still good to align/consolidate the approaches. In fact, some of my initial comments (and the thoughts that we might allow two ways of SR-P2MP signaling with BGP) were based on my understanding of draft-hb-02. Now I see the significant changes in -03 (of one route for each upstream/downstream) and I think draft-hb method is actually becoming similar to the draft-bess method (especially if we add back the per-downstream route that was in draft-bess-06 but removed in draft-bess-07) so we really need to think if we should have a single consolidate approach.

Zzh2> I will send out separate email to further comment on the Tunnel Encapsulation Attribute (TEA) encoding in draft-hb.

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks
Hooman

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 7 Apr 2022 16:23:33 +0000

Hi Jeffrey

I think there is a need to refresh our memory here and a bit of history

We collaborated many times with yourself over period of 2 years or so trying to come up with a compromise, the final result on all collaborations was for us to dump the draft-hb-sr-p2mp-policy and join the draft ietf-bess as it is trying to address all tunnel types and northbound and southbound communication.

This is something that was not acceptable as we wanted a draft that flows draft-ietf-idr-segment-routing-te-policy closely. To ensure rapid deployment of this technology.

I am glad to see you understand the merits of having a stand alone draft for P2MP policy now.

That said I see a need to provide some content to the WG to understand the technical point/history/consolidation of SR P2MP technology

  1.  Technical aspects: draft-hp-idr-sr-p2mp-policy is a south bound interface from the controller to the routers. It programs the candidate paths and replication segments on the node. In addition for efficiency it programs each OIF separately. On the north bound we feel that a BGP Route Reflector node that connects the controller to the overlay protocol between the Leaves and the Root node as explained in draft-ietf-bess-mvpn-evpn-sr-p2mp-04<https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-04> is sufficient enough for the controller to build its tree.
     *   As previously mentioned numerous times, simplicity is the key here. Operators are already familiar with draft-ietf-idr-segment-routing-te-policy and how it builds the segment list, "WHY REINVENT THE WHEEL"?  As such the implementation time, learning curve for draft-hb-idr-sr-p2mp-policy will be minimal, including deploying this technology in a network that is already using the draft-ietf-idr-segment-routing-te-policy. Multicast is complicated enough and the architects of the P2MP policy and P2MP replication segment have been pushing to simplify the technology and keep it close to unicast to allow ease of understanding and rapid deployment.
  2.  Collaboration: draft-hb-idr-sr-p2mp-policy was written and explained to all the parties involved in the P2MP Policy and Replication Segment architectural drafts at the time of upload to IETF on OCT 28 2019 including Jeffrey. As per point 1 there was a collaboration and agreement that there is a need to keep the SR-P2MP-Policy in par with segment-routing-te-policy. After this draft was communicated to various participants that were working on the P2MP SR technology, draft-bess-bgp-multicast-controller was updated to include P2MP SR policy. Note that bgp-multicast-controller draft started with mLDP/PIM originally  Diff: draft-ietf-bess-bgp-multicast-controller-02.txt - draft-ietf-bess-bgp-multicast-controller-03.txt<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-bgp-multicast-controller-03.txt>. This inclusion of P2MP policy was after draft-bess was adopted we had no idea about the inclusion of P2MP policy at the time that the draft was updated nor there was any collaboration with us at the time of upload (Other authors of draft-hb-idr-sr-p2mp-policy can speak for themselves). Some-time in 2021 we were approached by the author of bgp-multicast-controller with the idea of how the bgp-multicast-controller draft is addressing north bound and south bound and different underlay transport tunnel types and our reaction was interesting, but we feel there is a need for a south bound only implementation close to segment-routing-te-policy as per explanation in #1. Hence we came to a conclusion and agreement to go forward with both approaches.

     *   I am not sure about ietf rules and how new concepts or technology types can be added to an already adopted draft without collaboration. For example, does this mean if we grab draft-hb-idr-sr-p2mp-policy and add it in a section of draft-ietf-bess-mvpn-evpn-sr-p2mp which is already adopted and it would be acceptable?
     *   We have added many comments from Jeffrey to the draft-hb-idr-p2mp-policy including removing some route types etc... to make the draft acceptable to the authors of draft-ietf-bess-bgp-multicast-controller.
  1.  Timing: The feedback from Jeffrey was after the adoption call was over, was a great surprise to us as per point 2.b, and until March 24 (last day of adoption call) there was no technical concerns.

Thanks
Hooman
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Thursday, April 7, 2022 8:40 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[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 - TEA attribute

Hi,

Please see zzh2> below.

Juniper Business Use Only
From: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 6, 2022 11:41 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; 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 - TEA attribute

Hi Sue/Jeffrey

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks
Hooman

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2022 22:12:12 +0000

Hi Hootman,

Please see zzh3> below.

Sent: Thursday, April 7, 2022 12:24 PM

Hi Jeffrey

Zzh3> We did collaborate many times and indeed my preference has been to have a single comprehensive solution, and I have indicated my compromises (more below).

Zzh3> draft-hb-02 was more aligned with draft-ietf-idr-segment-routing-te-policy and I did accept that if we have to have two flavors of Tunnel Encapsulation Attributes and two documents that's fine. That is reflected in 3.4.3 of draft-bess-07.

Zzh3> Correction - it is not "now" - I had understood your consideration and accepted the compromise on the TEA and two drafts; what I am discussing as part of this adoption call is trying to consolidate on the other aspects - single SAFI and aligned route types; but additionally, after seeing changes in draft-hb-03, I am now inclined to try to align the TEA for both drafts (instead of having two flavors).

  1.  Technical aspects: draft-hp-idr-sr-p2mp-policy is a south bound interface from the controller to the routers. It programs the candidate paths and replication segments on the node. In addition for efficiency it programs each OIF separately. On the north bound we feel that a BGP Route Reflector node that connects the controller to the overlay protocol between the Leaves and the Root node as explained in draft-ietf-bess-mvpn-evpn-sr-p2mp-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-04__;!!NEt6yMaO-gk!SZ6fBV78RVeerbEiwTHJm5xnDeGhPZiZCXe3ApEdhg1uKUkJMWxEZBmvnehCWFkW$> is sufficient enough for the controller to build its tree.

Zzh3> The SR-P2MP sections in draft-bess (1.7 and 3.4) does the same and are not complicated. As I said I am fine with having a separate spec but we should align the approaches (SAFI, route types, TEAs). I have made compromises in draft-bess for that alignment as well.
Zzh3> There is a generic way of signaling multicast state for IP/mLDP/whatever trees as specified in draft-bess. Using it for SR-P2MP is not re-inventing the wheel. The "segment list" tunnel type for SR-P2MP in draft-bess *reuses* the "segment list" defined in draft-ietf-idr-segment-routing-te-policy.

  1.  Collaboration: draft-hb-idr-sr-p2mp-policy was written and explained to all the parties involved in the P2MP Policy and Replication Segment architectural drafts at the time of upload to IETF on OCT 28 2019 including Jeffrey. As per point 1 there was a collaboration and agreement that there is a need to keep the SR-P2MP-Policy in par with segment-routing-te-policy. After this draft was communicated to various participants that were working on the P2MP SR technology, draft-bess-bgp-multicast-controller was updated to include P2MP SR policy. Note that bgp-multicast-controller draft started with mLDP/PIM originally  Diff: draft-ietf-bess-bgp-multicast-controller-02.txt - draft-ietf-bess-bgp-multicast-controller-03.txt<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-bess-bgp-multicast-controller-03.txt__;!!NEt6yMaO-gk!SZ6fBV78RVeerbEiwTHJm5xnDeGhPZiZCXe3ApEdhg1uKUkJMWxEZBmvnT98rT3u$>. This inclusion of P2MP policy was after draft-bess was adopted we had no idea about the inclusion of P2MP policy at the time that the draft was updated nor there was any collaboration with us at the time of upload (Other authors of draft-hb-idr-sr-p2mp-policy can speak for themselves). Some-time in 2021 we were approached by the author of bgp-multicast-controller with the idea of how the bgp-multicast-controller draft is addressing north bound and south bound and different underlay transport tunnel types and our reaction was interesting, but we feel there is a need for a south bound only implementation close to segment-routing-te-policy as per explanation in #1. Hence we came to a conclusion and agreement to go forward with both approaches.

Zzh3> The 2021 timeline is *definitely wrong*. I remember discussing with some co-authors of P2MP Policy and Replication Segment architectural drafts *in person* before covid on how to use bgp-multicast-controller draft to signal SR-P2MP, and I definitely have discussed with you before 2021 (I'll try to dig out some email).

Zzh3> Using existing procedures in an adopted draft to support new but similar functionalities should be fine (there is no fundamental difference between mLDP tunnel and SR-P2MP). As I have repeatedly stated, I am fine with having a separate spec for SR-P2MP but we should try to consolidate the approaches for multicast tree setup signaling. In other words, I am fine with moving the SR-P2MP text out of draft-bess if we can agree on a consolidated approach.

Zzh3> draft-hb and draft-ietf-bess-mvpn-evpn-sr-p2mp are for different purposes, so your analogy does not apply.

Zzh3> and we have done the same on draft-bess side.

Zzh3> I had admitted that *it is my fault* that I missed the adoption deadline (I had not got to follow on this topic for a while). I will leave that to the chairs.
Zzh3> Thanks.
zzh3> Jeffrey

Thanks
Hooman
From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 7, 2022 8:40 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; 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 - TEA attribute

Hi,

Please see zzh2> below.

Hi Sue/Jeffrey

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks
Hooman

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: Susan Hares <[email-masked]>
Date: Fri, 8 Apr 2022 22:05:26 +0000

Jeffrey:

See comments below

IDR is interested in the clear definition of the BGP TEA + NLRI.
I find both drafts need to have clear definitions of:

a)       BGP Tunnel Encapsulation (RFC9012) definitions

b)      what NLRIs are supported

c)       Error handling

d)      BGP scaling properties

Once we get to these things, then it would be important to
look at use cases from operators (5G or other) looking to deploy
these multicast applications to determine if error handling
and scaling works.

After we the basics of BGP mechanisms, then we need
PIM + BESS review to make sure MVPN works well with SR.

Sue

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

[Sue-2]:

a)       Your text should specify which AFI/SAFI's these two new tunnel types can be attached to

b)      Your text does not describe which other tunnels can co-exist with these 2 new tunnel types.
Please add a complete list to your draft.

zzh> There is no interaction with PMSI. Section 3.1.3 mentioned S-PMSI route because of this:
zzh> the bgp-multicast draft is about hop-by-hop signaling and it uses S-PMSI route to signal state for MP2MP upstream traffic, but the bgp-multicast-controller draft does not use S-PMSI route as the Replication State route can be used to signal state for both downstream and upstream traffic.
[Sue-2] Are you implying interoperability with the S-PMSI route in the text:
"Since different upstream and downstream labels need to be used,
A new "Receiving MPLS Label Stack" of type TBD is added as a tunnel
Sub-TLV in addition to the existing  MPLS Label Stack sub-TLV."

If so, please define the interoperability clearly in your draft with an example.
If you are not describing interoperability, what is the new sub-TLV used for.

zzh> The "anyencap" and "load-balancing" tunnel types are not related to draft-ietf-idr-segment-routing-te-policy at all.
[Sue-2]: Then what does this text refer to in 3.4.3.1
"In this method, a TEA with tunnels being replication branches as specified in earlier sections
Can be used just as in non SR-P2NP?"

You must specifically define the Tunnel types and NLRIs your use of TEA applies to.

Zzh> The "segment list" tunnel "has a Segment List sub-TLV as specified
in Section 2.4.4 of [I-D.ietf-idr-segment-routing-te-policy]", as described in in 3.4.3.1.

Zzh> draft-bess does not use SR Policy tunnel type even for SR-P2MP.
[Sue-2] Why are you mentioning draft-hb-idr-sr-p2mp in the text?
draft-hb-idr-sr-p2mp specifies:

a)       New NLRI (AFI=1/SAFI-SR-P2MP) or (AFI=2/SAFI-SR-P2MP)
Format:  route-type, length, TLVS - with 3 route types (1-3)

b)      New NLRI is associated with 2 new Tunnel types

(P2MP-Policy and Replication segment)

Your draft specifies in section 3.3-3.4

a)       Tunnel type = Any Encapsulation, Load-balancing

b)      NLRIs - replication state NLRI (section 3.3)

[Not indicated which AFI/SAFI it works for]

Replication state (types 1-2)

Zzh> They don't interact with those. 3.1.3 does not refer to those route types.
[Sue-2]: Are you implying interoperability with
S-PMSI A-D routes in section 3.1.3?  It is unclear.

Zzh> In draft-bess, we did not define a separate route to encode the policy information.
Rather, the policy information is encoded in a wide community that is attached to the replication state route for the tree root.
[Sue-2]: Using Wide-Community to attached P2MP Policy is
a useful addition to the BGP capabilities.   Did you plan an interaction with
SR-Policy defined in draft-ietf-idr-segment-routing-te-policy-15.txt?

Zzh> In the offline discussion with the draft-hb co-authors long time ago,
I did indicate that draft-bess can also take their approach to use a different
route instead of using wide community. I alluded to that again in one of the emails for this adoption call.
[Sue-2] Routes (NLRI with embedded information)
And wide communities have different error handling.
Some operational networks prefer one versus the other.

3b) how are the atoms used in the policy?
Zzh> A policy has a name and a list of tree leaves among other things.
As described in 3.4.2, a string atom can encode the policy name, and a prefix list atom can encode the set of leaves.
Zzh> Again, the policy can be encoded in a new route instead of a wide community (to align with draft-hb).
[Sue-2] Agreed, the key difference is the choice of error-handling.

Zzh> Consider a tree node that has two replication branches.
Branch 1 is to a downstream node1 with a node sid (label) 101;
branch 2 is to another downstream node2 with a node sid (label) 102.
[Sue diagram]
                Node-top (node-3)
         ====================
SR-1a    | SR-1b |      SR-2a  | | SR-2b (segment routing tunnels)
              |            |                  | |
          --------------            --------------
        Node-1                        node-2

Suppose that the path to node1 does not matter,
but to node2 we want to use a particular path
represented by a segment list <151, 152, 102>.
[Sue- Let's denote SR-tunnel as SR-2b]

Suppose traffic sent to this node [node-3] on the tree has incoming tree sid/label 1000,
and traffic replicated to node1 and node2 has tree sid/label 1001 and 1002
respectively (the same tree sid/label 1000 could also be used
for all incoming/outgoing traffic, depending on the operator's choice
- this is discussed in section 1.4).
[Sue: I'm a bit confused - so I added the specific identifiers:
Node-3 - incoming label 1000:
outgoing labels: 1001 toward node-1 on SR-1a and SR-1b.
outgoing labels: 1002 toward node-2 on SR-2b, but not on SR-2a
[Please let me know if I have this diagram correct]

Zzh> With the 3.4.3.1 approach, the tunnel encapsulation attribute (TEA)
that is attached to the Replication State route will include three tunnels:
Zzh> 1) tunnel 1 for upstream information: any encap tunnel;
rpf sub-tlv (to indicate this is for upstream - section 3.1.4);
tree-label-stack sub-tlv with label 1000 (section 3.1.5)
[Does this go on all 4 SR tunnels [SR-1a, SR-1B, SR-2A, and SR-2B?]
Since these are TLVs in the TEA, what AFI/SAFI does this tunnel support?

Zzh> 2) tunnel 2 for replication branch 1 to node1:
segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <101, 1001>
[Sue] If there are two branches for node 1, would be receive the same segment list?

Zzh> 3) tunnel 3 for replication branch 2 to node2:
segment list tunnel; segment-list sub-tlv (3.4.3.1) with segment list <151, 152, 102, 1002>
[Sue] My understanding is that 2a, does not have these segments
And 2b does.

Zzh> With this TEA encoding, the receiving node programs its forwarding state
so that incoming traffic with sid/label 1000 will be replicated to
two downstream nodes using segment list <101, 1001> and <151, 152, 102, 1002> respectively.
[Sue] would you expand this to include 2 SR tunnels from node-3 to node-1,
And node-3 to node-2.

Zzh> Encoding the upstream information as a tunnel has the advantage that in case of MP2MP,
that upstream tunnel will also encode outgoing information for upstream traffic
(from tunnel leaves towards root and other leaves), and a downstream tunnel
will also have tree-label-stack sub-tlv to encode incoming information for upstream traffic.
[Sue]: Yes - but the cost for the P2MP case is more information.
The MP2MP versus P2MP has definite trade-offs.

Zzh> Section 3.4.3.2 of draft-bess basically says there could be another way to
encode the replication information as specified in draft-hb.
That section was added as an (unfinished/unsuccessful) attempt
to consolidate both draft-bess and draft-hb approaches.
[Sue]: I'm glad to hear we have room between the authors to
Consolidate on BGP TEA mechanisms and Route Mechanisms.
The MP2MP versus P2MP methodology may differ.

Zzh> In this example, my understanding of draft-hb approach is that three routes are needed
(in addition to the route for the policy information):
Zzh> 1) a "Replication Segment Binding Sid" route; its NLRI will encode the incoming SID (1000 in this example). This is specified in 3.1.2 of draft-hb.
Zzh> 2) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 1
Zzh> 3) a "Replication segment Route OIF" route (3.1.3) , with a TEA that has a single tunnel of type Replication-Segment-oif (3.2.3) for branch 2
Sue:  I will ask draft-hb-idr-sr-p2mp-policy authors to confirm your understanding.

Zzh> The main difference is that one route is used for each upstream/downstream in draft-hb while in draft-bess, a single route is used with a TEA encoding all upstream/downstream information.
I suppose there are pros and cons for each way, and I'll not get into which is better in this email, but one thing to notice is that the draft-hb way is not MP2MP friendly (obviously it is "out of scope" now, but it's good to be extensible).
[Sue-2  The MP2MP extensibility via PIM mechanisms can cost more complexity in the methodology.
P2MP may be the only function desired by some network operators.
What's important now is to have a clear definition of the tradeoffs.

Zzh> Thanks.
Zzh> Jeffrey

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares

---

From: Susan Hares <[email-masked]>
Date: Fri, 8 Apr 2022 22:22:19 +0000

Hooman and Jeffrey:

MP2MP and P2MP are different scopes with different implementation and deployment costs.
The IDR WG showed interest in the P2MP stand-alone in the adoption call,
And the draft-hb-idr-sr-p2mp-policy work.   Bess has shown interested in
draft-bess-bgp-multicast-controller.

Let's harmonize these two drafts now so that you can both go forward quickly
with this useful technology for evolving networks.
The IDR focus is on the common BGP mechanisms such as:

b)      Communities (Wide and Extended)

c)       what NLRIs are supported

d)      Error handling

e)      BGP scaling properties

Let's see what do get clear BGP definitions next week.

It would be cool to try to minimize duplicate BGP functions - even with 2 different multicast functions.

Cheers, Sue

From: Bidgoli, Hooman (Nokia - CA/Ottawa) [mailto:[email-masked]]
Sent: Wednesday, April 6, 2022 11:41 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[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 - TEA attribute

Hi Sue/Jeffrey

Thanks
Hooman

Hi Sue,

Please see zzh> below.

Jeffrey and Hooman:

You indicated in

Thank you, Sue

[+ BESS, PIM]

Hi,

Thanks.
Jeffrey

IDR WG:

Cheers, Sue

Cheers, Susan Hares