Resending with reply-all. Thanks, Tulasi.
On Wed, Sep 25, 2024 at 10:46 PM TULASI RAM REDDY <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> > 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> 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
