[bess] Re: WG status for draft-ietf-bess-bgp-srv6-args

["Jorge Rabadan (Nokia)" <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, September 25, 2024 at 10:45 PM
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Jorge Rabadan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, gangadhara reddy chavva <[e-mail]>
Subject: Re: WG status for draft-ietf-bess-bgp-srv6-args
You don't often get email from [e-mail]. 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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