Neeraj: Your text in -24 does not address the correct RFC 7606 work.. Please see section 7.14
7.14<https://www.rfc-editor.org/rfc/rfc7606.html#section-7.14>. Extended Community The error handling of [RFC4360<https://www.rfc-editor.org/rfc/rfc4360>] is revised as follows: o The Extended Community attribute SHALL be considered malformed if its length is not a non-zero multiple of 8. o An UPDATE message with a malformed Extended Community attribute SHALL be handled using the approach of "treat-as-withdraw". Note that a BGP speaker MUST NOT treat an unrecognized Extended Community Type or Sub-Type as an error. Section 2.: o Treat-as-withdraw: In this approach, the UPDATE message containing the path attribute in question MUST be treated as though all contained routes had been withdrawn just as if they had been listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI attribute if appropriate) of the UPDATE message, thus causing them to be removed from the Adj-RIB-In according to the procedures of [RFC4271<https://www.rfc-editor.org/rfc/rfc4271>]. o Attribute discard: In this approach, the malformed attribute MUST be discarded and the UPDATE message continues to be processed. This approach MUST NOT be used except in the case of an attribute that has no effect on route selection or installation. However, your text (draft-ietf-bess-evpn-unequal-lb-24.txt) * 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 discard the extended community as specified in [RFC7606] and handle the BGP route as it would if it was received without this extended community. ============== To follow the malformed text, you must discard the UPDATE. Instead, you are treating this as a attribute discard. Can you revise -24 to use the “treat-as-withdraw”? If you really want “attribute-discard”, you must provide justification why are you are breaking [RFC7606] guidelines. Please let me know if this guidance is clear. Cheerily, Sue Hares From: Neeraj Malhotra <neeraj.i...@gmail.com> Sent: Tuesday, November 12, 2024 2:49 PM To: Susan Hares <sha...@ndzh.com> Cc: BESS <bess@ietf.org>; bess-cha...@ietf.org Subject: Re: [bess] draft-ietf-idr-bess-evpn-unequal-lb-23 - needs to use RFC7606 Hi Susan, Thanks for the reminder. Changes to reference RFC7606 were sitting in my local as the tool was locked at the time. Could you please check rev24? Thanks, Neeraj External (neeraj.i...@gmail.com<mailto:neeraj.i...@gmail.com>) Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzAyYzhkMWE1MTg5YzExZjk1NDA5MzFiNTUzZGI4Yzk2LzE3MzE0NDA5NTkuMzcwNjA1Mg==#key=287a44379ee06354977c8d0b406e49a3> 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, Thanks for the reminder. Changes to reference RFC7606 were sitting in my local as the tool was locked at the time. Could you please check rev24? Thanks, Neeraj On Fri, Nov 8, 2024 at 2:06 AM Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>> wrote: Greetings: As I mentioned in the BESS meeting chat at IETF-121, the authors have adjusted the Error Handling section from -22 to -23. However, this section should reference the RFC7606 language. If the authors want specific text, please let me know. Cheers, Sue _______________________________________________ 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
