Hi Jeffrey Please see Gyan2>
On Tue, Apr 12, 2022 at 11:02 AM Jeffrey (Zhaohui) Zhang <[email protected]> wrote: > Hi Gyan, > > > > Please see zzh2> below. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra <[email protected]> > *Sent:* Friday, April 8, 2022 8:48 PM > *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 Gyan> > > > > > > On Tue, Apr 5, 2022 at 7:38 PM Jeffrey (Zhaohui) Zhang <[email protected]> > wrote: > > Hi Gyan, > > > > Please see zzh> below for my view. > > > > > > Juniper Business Use Only > > *From:* Gyan Mishra <[email protected]> > *Sent:* Tuesday, March 29, 2022 10:31 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]* > > > > > > 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 <zzhang= > [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]> > *Sent:* Friday, March 25, 2022 11:34 AM > *To:* Jeffrey (Zhaohui) Zhang <[email protected]>; Susan Hares < > [email protected]>; [email protected] > *Cc:* '[email protected]' <[email protected]>; 'BESS' <[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]> *On Behalf Of *Jeffrey (Zhaohui) Zhang > *Sent:* Friday, March 25, 2022 10:47 AM > *To:* Susan Hares <[email protected]>; [email protected] > *Cc:* '[email protected]' <[email protected]>; 'BESS' <[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]> *On Behalf Of *Jeffrey (Zhaohui) Zhang > *Sent:* Friday, March 25, 2022 6:30 AM > *To:* Susan Hares <[email protected]>; [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]> *On Behalf Of *Susan Hares > *Sent:* Thursday, March 10, 2022 10:28 AM > *To:* [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] <[email protected]>] *On > Behalf Of *Susan Hares > *Sent:* Thursday, March 10, 2022 9:55 AM > *To:* [email protected]; [email protected]; [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] > https://www.ietf.org/mailman/listinfo/bess > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!RNg1gSHc7bgU2dou9enCSiVF-PXIWQ2Wk4mTxBBHjYxjFPb_mdHB9D5C3t2xHmG0$> > > -- > > [image: 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]* <[email protected]> > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] > <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RiHtqGntIPhoemdxe2yBGpMBQILKyyj3TMv6dkbc_ucJ3OqtTJdthtFCYzd2wPtC$> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
