Subject: Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Thu, 17 Feb 2022 14:44:51 +0800 (CST)

Hi,

Ron and John both mentioned that leveraging the existing AFI/SAFI may cause misunderstanding of the SRv6 service routes.

We encountered this problem during implementation and submitted a draft talking about this.

https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02

One solution(if new AFI/SAFI is not defined) we proposed in the draft is to define a new BGP capability code for for SRv6-based BGP service capability, and then SRv6 service routes would only be exchanged between devices that support it based on this capability.

Do you think this is a possible solution?

Regards,

Yao

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 13:50:11 +0530

Hi Yao,

Thanks to you and your co-authors for this work.

While the implementations and deployments today use configuration knobs for
this purpose, the use of capabilities exchange is certainly another option
to consider. However, the capability exchange takes care of peering between
implementations that are enabled for and support SRv6. We will still need
the policy configuration knobs for more granular control and filtering
mechanisms. So, IMHO, these mechanisms are complementary.

That said, let us go through the normal WG review process and I see no
issue in extending with capability exchange in a future document such as
yours.

Thanks,
Ketan

On Thu, Feb 17, 2022 at 12:15 PM <[email-masked]> wrote:

> Hi,
>
> Ron and John both mentioned that leveraging the existing AFI/SAFI may
> cause misunderstanding of the SRv6 service routes.
>
> One solution(if new AFI/SAFI is not defined) we proposed in the draft is
> to define a new BGP capability code for for SRv6-based BGP service
> capability, and then SRv6 service routes would only be exchanged between
> devices that support it based on this capability.
>

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Feb 2022 01:05:20 +0000

Hi Yao,

Thanks for bringing this up. I’ve followed up further in the main thread.

Regards,

—John

> On Feb 17, 2022, at 1:44 AM, [email-masked] wrote:
> 
> 
> 
> Hi,
>