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

[TULASI RAM REDDY <[e-mail]>]

Thanks Jorge for the update.

Thanks,
Tulasi.
On Thu, Sep 26, 2024 at 3:30 PM Jorge Rabadan (Nokia) <
[e-mail]> 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 <[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]> 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]>
> 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]> 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
>


-- 
TULASI RAMI REDDY N