Re: [bess] [Idr] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02
All, Looking at all the drafts mentioned I do think there are actually two different scenarios being considered and perhaps it is actually beneficial to treat them separately. Original draft allowed to signal link bw in situations where you peer from different boxes. Path hiding is not an issue. Most likely such signalling is to be done in respect to underlay. However newer proposals aim to enhance the overlay behaviour where via one or the other technique path hiding issue of BGP is addressed. Inter-AS option C is also an overlay so I would recommend to think twice before influencing base idea with this deployment scenario. To conclude let's also realize that link bw is actually not a property of a path as it is a property of the next hop binded to such path (how easy or difficult it is to get to such next hop). And here I must say that the draft Kaliraj & Minto proposed draft-kaliraj-idr-multinexthop-attribute could possibly be used as a vehicle for its encoding. The clear benefit for such perspective is ability to signal helper next hops addresses with their link bw metrics possible hashing spread without need to explode BGP with lot's of paths respectively if that is done by add-paths or RD prepend. Thx, Robert On Mon, Jun 26, 2023 at 11:44 PM Alvaro Retana wrote: > On June 26, 2023 at 5:27:39 PM, Jeff Tantsura wrote: > > Jeff: > > > Over the last couple of years I have reached out to the authors of the > > original draft at least twice with a request to refresh the draft and > bring > > the necessary changes in, without much success though. > > > ... > > Note that there’s also an EVPN specific draft (standard track). > > That made me go look -- I found two related documents! Are these what > you're referring to? > >https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw >https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb > > > > I’d be happy to volunteer to help managing the mess ;-) > > I know the idr/bess-chairs are listening. ;-) > > > Alvaro. > > ___ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Idr] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02
Hi All, > Despite this divergence in already deployed implementations, in order that > implementations work with each other, we will require some specified > procedures with knobs etc. In fact, we have an offline thread initiated on > this. That’s right, we have initiated discussions with @Satya Mohanty (satyamoh)<mailto:satyamoh=40cisco@dmarc.ietf.org> on this. We are working towards making Juniper implementation interop with others by accepting non-transitive version of the link bandwidth community as currently specified in the expired draft. Also, we agree we need to come up with new procedures for supporting both transitive and non-transitive link bandwidth extended communities in the updated draft. Satya has kindly agreed to co-ordinate between the current authors and us. The code point taken by Jeff is also towards this effort and it represents the transitive version of the link bandwidth extended community that Juniper currently uses. Discussion with Satya is also about updating this code point in the new draft. > Therefore, the transitivity requirement that you mention here really only > applies to a case where the next-hop is unchanged when advertising the BGP > update across the EBGP boundary. Correct, example: Inter AS option C deployments. Thanks & Regards, Reshma Das Juniper Business Use Only From: Idr on behalf of Satya Mohanty (satyamoh) Date: Friday, June 23, 2023 at 11:32 AM To: Robert Raszuk , Alvaro Retana Cc: i...@ietf.org , bess@ietf.org , idr-cha...@ietf.org Subject: Re: [Idr] [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02 [External Email. Be cautious of content] Hi Alvaro and Robert, Thanks to both for your review. I am in agreement that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07__;!!NEt6yMaO-gk!DFTurGTc2xLLrvfyL45fndvmwHNDlw4ahmUyBNczNOmMJ7ANZQieC0LgL5iCY7c93lCwSb8N7tFWMzw8y0Mp-6jkuXO6blw$> needs to be refreshed. Please see inline From: Idr on behalf of Robert Raszuk Date: Thursday, June 22, 2023 at 11:58 AM To: Alvaro Retana Cc: i...@ietf.org , bess@ietf.org , idr-cha...@ietf.org Subject: Re: [Idr] [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02 Hi, > I agree that the use case presented should be addressed, but I don't think > the document is ready for WGLC, Indeed. In fact it is clear by now that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07__;!!NEt6yMaO-gk!DFTurGTc2xLLrvfyL45fndvmwHNDlw4ahmUyBNczNOmMJ7ANZQieC0LgL5iCY7c93lCwSb8N7tFWMzw8y0Mp-6jkuXO6blw$> needs to be rewritten to accommodate both 4 octet ASNs (instead of proposing use of AS_TRANS) as well as define support for transitive community use. Yes, we should accommodate the 4-byte ASNs. Regarding the transitivity, please see below. On the last one inspection of the IANA registry reveleas subtype 0x04 as "Juniper Transitive Link Bandwidth" and the date 25th April 2023. [cid:ii_lj7i5vi70] Interesting especially that I do not recall any discussions in IDR about this this year ... I also did not notice this, although as per earlier conversations with Juniper folks, I was aware that LB is implemented as transitive there. On the other hand, Cisco, Arista etc. have implemented it as per the above draft i.e. optional non-transitive. Also, as per the draft, when the next-hop is reset, the received LB should be removed. This imposition, however, does allow regenerating a new LB that will be associated with the new advertised next-hop and that’s what is done in some of the implementations that I know of. Therefore, the transitivity requirement that you mention here really only applies to a case where the next-hop is unchanged when advertising the BGP update across the EBGP boundary. Despite this divergence in already deployed implementations, in order that implementations work with each other, we will require some specified procedures with knobs etc. In fact, we have an offline thread initiated on this. Cheers, R. On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana mailto:aretana.i...@gmail.com>> wrote: Hi! I took a look at this document. I agree that the use case presented should be addressed, but I don't think the document is ready for WGLC, or even necessary (see below). In fact, I'm having a hard time understanding how it can progress if it depends on an expired draft, the proposed changes are not specific, etc. The meat of the document (beyond the explanation of the use case) is (from §1): The new use-case mandates that the router calculates the aggregated link-bandwidth, regenerate the DMZ link bandwidth extended community, and advertise it to EBGP peers. I-D.ietf-idr-link-bandwi
Re: [bess] [Idr] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02
Hi Alvaro and Robert, Thanks to both for your review. I am in agreement that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to be refreshed. Please see inline From: Idr on behalf of Robert Raszuk Date: Thursday, June 22, 2023 at 11:58 AM To: Alvaro Retana Cc: i...@ietf.org , bess@ietf.org , idr-cha...@ietf.org Subject: Re: [Idr] [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02 Hi, > I agree that the use case presented should be addressed, but I don't think > the document is ready for WGLC, Indeed. In fact it is clear by now that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to be rewritten to accommodate both 4 octet ASNs (instead of proposing use of AS_TRANS) as well as define support for transitive community use. Yes, we should accommodate the 4-byte ASNs. Regarding the transitivity, please see below. On the last one inspection of the IANA registry reveleas subtype 0x04 as "Juniper Transitive Link Bandwidth" and the date 25th April 2023. [cid:ii_lj7i5vi70] Interesting especially that I do not recall any discussions in IDR about this this year ... I also did not notice this, although as per earlier conversations with Juniper folks, I was aware that LB is implemented as transitive there. On the other hand, Cisco, Arista etc. have implemented it as per the above draft i.e. optional non-transitive. Also, as per the draft, when the next-hop is reset, the received LB should be removed. This imposition, however, does allow regenerating a new LB that will be associated with the new advertised next-hop and that’s what is done in some of the implementations that I know of. Therefore, the transitivity requirement that you mention here really only applies to a case where the next-hop is unchanged when advertising the BGP update across the EBGP boundary. Despite this divergence in already deployed implementations, in order that implementations work with each other, we will require some specified procedures with knobs etc. In fact, we have an offline thread initiated on this. Cheers, R. On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana mailto:aretana.i...@gmail.com>> wrote: Hi! I took a look at this document. I agree that the use case presented should be addressed, but I don't think the document is ready for WGLC, or even necessary (see below). In fact, I'm having a hard time understanding how it can progress if it depends on an expired draft, the proposed changes are not specific, etc. The meat of the document (beyond the explanation of the use case) is (from §1): The new use-case mandates that the router calculates the aggregated link-bandwidth, regenerate the DMZ link bandwidth extended community, and advertise it to EBGP peers. I-D.ietf-idr-link-bandwidth expired in 2018. I have seen no indication from the authors that it will be refreshed. I know that implementations exist, but that is orthogonal to the need to reference this document as Normative. I think we should refresh the above. We had requested a refresh in 2018 when draft-ietf-bess-ebgp-dmz was published. It was refreshed. The rest of the document is mostly dedicated to describing the use case, but the description of the actions is loose (at best); for example, there is no specification about how "the router calculates the aggregated link-bandwidth". Yes, we can all guess/assume what it means, but that needs to be documented. Ack. We can put a text in the document, mentioning this. Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from this document could be covered there. In fact, there is already a hint to the ability to regenerate the community based on received information (from §3): Alternatively CEs of the site, when advertising IP routes to PE1 and PE2, could add the link bandwith community to these advertisements, in which case PE1 and PE2, when originating VPN-IP routes, would use the bandwidth value from the IP routes they received from the CEs to construct the link bandwidth community carried by these VPN-IP routes. In summary, given that this document depends on I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be "merged" into it. Yes, although regeneration is hinted, the distinguishing aspect is the aggregation in our draft. We can certainly merge both (need to discuss with other authors) and list it as a use-case just as you mentioned. But important thing now is to make the original draft active. Alvaro. Best, --Satya On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) (matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>) wrote: Hi IDR WG The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02 (draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and load-balancing<https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/>), for
