Hi Tulasi, Yes, there are implementations that follow that text you are highlighting (the one I’m aware of).
Thanks. Jorge From: TULASI RAM REDDY <tulasiramire...@gmail.com> Date: Wednesday, September 25, 2024 at 10:45 PM To: draft-ietf-bess-bgp-srv6-a...@ietf.org <draft-ietf-bess-bgp-srv6-a...@ietf.org>, bess@ietf.org <bess@ietf.org>, skr...@cisco.com <skr...@cisco.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, w...@juniper.net <w...@juniper.net>, gangadhara reddy chavva <meetgangadh...@gmail.com> Subject: Re: WG status for draft-ietf-bess-bgp-srv6-args You don't often get email from tulasiramire...@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Resending with reply-all. Thanks, Tulasi. On Wed, Sep 25, 2024 at 10:46 PM TULASI RAM REDDY <tulasiramire...@gmail.com<mailto:tulasiramire...@gmail.com>> wrote: Hi Ketan, Thanks for your confirmation. I agree with the proposal in the document, in case of mismatch we can't really use the SHL in Type 1 as it doesn't conform with Type3 AL but implementation of this to exclude *only* advertising PE for BUM to avoid loop would be little involved in actual forwarding. Just want to know if any vendor has the configurable option and see the mismatch as highlighted in B and solved by actually blocking specific PE in BUM. Thanks, Tulasi. On Wed, Sep 25, 2024 at 9:12 PM Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> wrote: Hi Tulasi, The document is in the WGLC queue. We (authors) will refresh it shortly. RFC8986 does not mandate a fixed size for ARG nor call for making it configurable. The text that you highlight is simply bringing to notice such a possibility and how to handle it. Perhaps I am missing your question/concern with the text and if so, please clarify. Thanks, Ketan On Wed, Sep 25, 2024 at 4:59 PM TULASI RAM REDDY <tulasiramire...@gmail.com<mailto:tulasiramire...@gmail.com>> wrote: Hi All, I see the draft-ietf-bess-bgp-srv6-args-01 is in expired state, do we have any plans to revive with the new version. I don't see much traction in the WG for adoption. Do we have AL configuration options provided by any vendor for uSID or Full SID. Curious to know, if any vendor has implemented below mismatch AL case as highlighted in red in Sec3.3: Processing at Ingress PE 2. When a non-zero AL is signaled via Route Type 3, then the matching Route Type 1 for the Ethernet Segment is found and checked for the presence of an SRv6 SID advertisement with the End.DT2M behavior. b. If the AL values in Route Type 1 and 3 are both non-zero and not equal, then there is no usable ARG value. It also indicates an inconsistency in signaling from the egress PE. To avoid looping, the BUM traffic MUST NOT be forwarded for such routes from the specific Ethernet Segment and implementations SHOULD log an error message. Thanks, TULASI RAMI REDDY N -- TULASI RAMI REDDY N -- TULASI RAMI REDDY N
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
