+1
On Thu, Sep 26, 2024 at 3:30 PM Jorge Rabadan (Nokia) < [email protected]> wrote: > 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 <[email protected]> > *Date: *Wednesday, September 25, 2024 at 10:45 PM > *To: *[email protected] < > [email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, Jorge Rabadan (Nokia) < > [email protected]>, [email protected] <[email protected]>, gangadhara > reddy chavva <[email protected]> > *Subject: *Re: WG status for draft-ietf-bess-bgp-srv6-args > > You don't often get email from [email protected]. 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 < > [email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
