Neeraj: Thank you for adding the BGP error handling to your text.
If I understand your addition in -23, this draft treats a malformed BGP Community as “attribute discard”. Malformed Extended Community: If a PE detects a malformed EVPN Link Bandwidth Extended Community, for example because the "Value-Units" has a value other than 0x00 or 0x01, it MUST ignore the extended community and handle the BGP route as it would if it was received without this extended community.¶<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-23#section-4.1.1-1.3.1> Does “ignore” mean you discarding the extended community attribute and not forwarding it to another peer? Here’s the “attribute discard text from RFC7606”: For any malformed attribute that is handled by the "attribute discard" instead of the "treat-as-withdraw" approach, it is critical to consider the potential impact of doing so. In particular, if the attribute in question has or may have an effect on route selection or installation, the presumption is that discarding it is unsafe unless careful analysis proves otherwise. The analysis should take into account the tradeoff between preserving connectivity and potential side effects. Cheerily, Sue From: Neeraj Malhotra <neeraj.i...@gmail.com> Sent: Monday, October 21, 2024 12:19 PM To: Susan Hares <sha...@ndzh.com> Cc: BESS <bess@ietf.org>; bess-cha...@ietf.org Subject: Re: [bess] draft-ietf-bess-evpn-unequal-lb-22 Hi Susan, Many thanks for the review and comments below. All of the comments below are incorporated into revision 23. Thanks, Neeraj External (neeraj.i...@gmail.com<mailto:neeraj.i...@gmail.com>) Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzFlNzhjZjdlYzA0MTBiN2I2OWNlODdkZWM5ZDJlM2I0LzE3Mjk1Mjc1NTIuNjI2OTM0Mw==#key=8267bef72f13b9201636f23474d30cc8> FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813> GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky> Hi Susan, Many thanks for the review and comments below. All of the comments below are incorporated into revision 23. Thanks, Neeraj On Thu, Oct 17, 2024 at 8:48 AM Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote: BESS WG, BESS chairs, and authors: This is a requested review from IDR chairs for draft-ietf-bess-evpn-unequal-lb-22.txt I’m not attaching a file because it is short. Cheerily, Sue Hares -------------- Status: Ready with nits (small technical nits and editorial nits) Summary: This is a very useful draft for EVPN. The draft has solid technical content and flow. A few minor edits will fill in the gaps. Caveat: Keyur Patel said he reviewed this draft, but non-of the chairs (IDR and BESS) can find it. I’m sure Keyur review was great. I just can find it. Editorial/technical issue: Section 4.1 - you should clear state that value units outside of 0x00 or 0x01 are invalid. Also, you should clearly state only 0x00 and 0x01 are valid. Section 4.1 - what happens if Extended Community is malformed? See RFC7606. Please provide details. You are missing a clearly delineated section on BGP error handling. Editorial only: 1) spelling check: 5.2 - recevied - paragraph 1, sentence 1 5.2 - badwidth - paragraph 5, stanrding Please note. 6.2 - (VLAN-a % 4) - last paragraph. Section 10.0 - IANA considerastions needs to use a better formatting. _______________________________________________ BESS mailing list -- bess@ietf.org<mailto:bess@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
