Hi Gyan, Gyan2> What is the advantage of using TEA encoding as opposed to existing PTA RFC 6513 & RFC 6514 MVPN signaling?
This is about using procedures in draft-ietf-bess-bgp-multicast-controller to set up (s,g) forwarding state in a VRF, as an alternative to BGP-MVPN. As described in https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-09#section-2, instead of ingress/egress PE figuring out the (s,g) state based on BGP-MVPN signaling and PIM signaling (for local OIFs to CEs), they simply take instructions from a control on what tunnel branches and which local OIFs to use – as if an operator is configuring them statically. This allows the PEs to be very dumb and simple. From that point of view, there is no difference between “underlay” and “overlay” and the TEA is perfect to encode that information – each “tunnel” in the TEA is a replication branch. That section does have the following that makes use of the PTA (attached to MCAST-TREE NLRIs for programing VRF (s,g) forwarding state): The Replication State route may also have a PMSI Tunnel Attribute (PTA) attached to specify the provider tunnel while the TEA specifies the local PE-CE interfaces where traffic need to be sent out. This not only allows provider tunnel without a binding SID (e.g., in a non-SR network) to be specified without explicitly listing its replication branches, but also allows the service controller for MVPN overlay state to be independent of provider tunnel setup (which could be from a different transport controller or even without a controller). Jeffrey Juniper Business Use Only From: Gyan Mishra <[email protected]> Sent: Thursday, April 28, 2022 12:19 AM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: BESS <[email protected]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]>; Susan Hares <[email protected]>; [email protected]; [email protected] Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] Hi Jeffrey Please see Gyan2> On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Hi Gyan, Please see zzh2> below. Juniper Business Use Only From: Gyan Mishra <[email protected]<mailto:[email protected]>> Sent: Friday, April 8, 2022 8:48 PM To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] Hi Jeffrey Please see Gyan> On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Hi Gyan, Please see zzh> below for my view. Juniper Business Use Only From: Gyan Mishra <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 29, 2022 10:31 AM To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [bess] [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] Dear authors Can you describe in more detail the relationship and interaction between the two SR P2MP variants below: Defines new SAFI for SR P2MP variant https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-04__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3jKh83Sr$> zzh> draft-ietf-bess-bgp-multicast-controller (referred to as draft-bess) defines a SAFI and different route types of that SAFI to setup replication state on IP/mLDP/SR-P2MP tree nodes. One of the route types is for SR-P2MP purposes. Zzh2> Correction – the MCAST-TREE SAFI is defined in draft-ietf-bess-bgp-multicast. Gyan> Ack Zzh> draft-hb-idr-sr-p2mp-policy (draft in this adoption call, referred to as draft-hb) defines a different SAFI and route types for the same SR-P2MP purposes. Gyan> The adoption call draft is aligned with SR-TE policy as P2MP extension for simplicity for operators which I agree makes sense. Does this draft utilize all the drafts below Tree sid / Replication sid and SR P2MP MVPN procedures for auto discovery etc. Zzh> Both drafts are for realizing the two tree-sid drafts mentioned below; both can be used for draft-ietf-bess-mvpn-evpn-sr-p2mp. Gyan> Ack Zzh> As I mentioned before, both draft-bess and draft-hb have its own considerations. The biggest difference is how the replication information is encoded in the Tunnel Encapsulation Attribute (TEA). Gyan> Ack Zzh> I can understand that the IDR/PIM/BESS WGs may decide to accept both ways of encoding replication information in the TEA, but I believe we should share SAFI and route types between the two drafts – only the TEA would be different. Gyan> Both the BESS and IDR adoption draft are vastly different solutions that have very different goals I don’t see any reason or need to have similarities as far as TEA or SAFI encodings or usage. The BGP controller draft has a very wide scope, but also is more of an alternative approach as it introduces new extensibility idea of utilizing TEA and wide communities encoding to make the solution RFC 6513 and 6514 MVPN signaling independent. That is a drastic change for scalability for operations traditional use of multicast X-PMSI P-Tree leveraging the separation of control plane from forwarding plane with RR using traditional MVPN procedures. As the ideas from the BESS draft as it builds on the BGP Multicast draft is to eliminate soft state tree building protocols and with the move towards hard state, thus the signaling paradigm change from traditional MVPM procedures to alternate TEA and wide community encoding. Am I reading that correctly as the goals of the BESS draft? Zzh2> Not really 😊 Gyan> Ok The BESS document also mentions that the solution can be used for underlay and overlay trees as replacement for MVPN signaling. For underlay trees are you referring to GTM? I have many more questions about the BESS draft and will ask in a new thread. Zzh2> draft-ietf-bess-bgp-multicast-controller was initially intended to build traditional IP multicast trees (w/o any VPN specifics) and mLDP tunnels (started in September 2017) with calculation on and signaling from controllers. SR-P2MP was added in -03 (July 2020) because the generic mechanism for IP/mLDP trees can be used for SR-P2MP as well. These can all be considered as underlay. Gyan> Ack Zzh2> Overlay support – as an MVPN replacement – was added in -06 (February 2021), but the concept is *not different* from underlay at all – we’re just setting up (s, g) IP multicast state in VRFs, with downstream nodes including remote VRFs connected by some sort of tunnels. That is not different from setting up state in global table at all. Gyan2> Ack Gyan2> What is the advantage of using TEA encoding as opposed to existing PTA RFC 6513 & RFC 6514 MVPN signaling? Zzh2> Thanks. Zzh2> Jeffrey Zzh> Jeffrey Defines Tree SID stitching of replication SID SR policy P2MP variant https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-voyer-pim-sr-p2mp-policy-00__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3gdi0hAB$> Replication SID https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3smIMNzh$> Defines new SR P2MP PTA using MVPN procedures https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3g-W3jH0$> Kind Regards Gyan On Mon, Mar 28, 2022 at 3:39 PM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Hi, 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 major difference between the two ways is on #3. Indeed, we could not reach consensus – there are two ways of encoding the TEA and each has its own considerations. The draft-ietf-bess way (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. I want to initiate a discussion and I can understand that WGs may eventually choose to allow both ways for #3. Even so, I think we should strive for consistent approach at least for #1 and #2 (and for that I am not saying that draft-ietf-bess way must be used). For example, use the same SAFI and route types for both ways, but use different TEA encoding methods. Thanks. Jeffrey Juniper Business Use Only From: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>> Sent: Friday, March 25, 2022 11:34 AM To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: '[email protected]<mailto:[email protected]>' <[email protected]<mailto:[email protected]>>; 'BESS' <[email protected]<mailto:[email protected]>> Subject: RE: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call [External Email. Be cautious of content] Hi All 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. HB> yes there was discussion and there was no consensus to merge the 2 drafts as their approach is widely different. The authors of this draft have kept the implementation very close to unicast BGP SR Policy for the segment list, which simplifies the implementation and deployment of the technology. As you said there seems to be two way to download this policy and the segment list and we can work on both. Given the solid support I don’t see why the adoption of this draft should be delayed because of these arguments. Thanks Hooman From: pim <[email protected]<mailto:[email protected]>> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, March 25, 2022 10:47 AM To: Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: '[email protected]<mailto:[email protected]>' <[email protected]<mailto:[email protected]>>; 'BESS' <[email protected]<mailto:[email protected]>> Subject: Re: [pim] [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 protected]<mailto:[email protected]>> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, March 25, 2022 6:30 AM To: Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>> On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 10:28 AM To: [email protected]<mailto:[email protected]> 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 protected]] On Behalf Of Susan Hares Sent: Thursday, March 10, 2022 9:55 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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!TfiPI1NfecN3db3pj6WZ8paxUr4s6OvmVZ91mapddPFeCkFZJodxFk8aTGCpYg34$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast-controller/__;!!NEt6yMaO-gk!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGazDpUZk$> 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!S33KKHGKJVywLaE5hTpBZvb2Og_8GrdduTTT-6xmknLUl8Yylk7RNo3lGW1pXg_c$> 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 _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3t2xHmG0$> -- [Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3l4bzk3s$> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RiHtqGntIPhoemdxe2yBGpMBQILKyyj3TMv6dkbc_ucJ3OqtTJdthtFCYzd2wPtC$> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Tvnc-w7uwkJv79QNGutNiQGYzxGECmu21Ktr6Gw1Vjj5GqUslaeyHwwia2jlEeSo$> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
