Subject: Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Aug 2020 23:11:24 +0100

Just coming back to you on this one, Alvaro....

> I'm not too keen on the use of treat-as-withdraw, specially because
> the sender doesn't know that something happened.  Knowing that the
> communication is direct between the controller/classifier, I would
> like to propose thinking of multiple communities as interfering with
> the new one (see §7.7/rfc5575bis).  This would result in this document
> specifying something like this:
>
> OLD>
>   ...: the inclusion of the "Flow Specification for SFC Classifiers" action
>   extended community along with any other action MUST be treated by an
>   implementation of this specification as an error which SHOULD result in the
>   Flow Specification UPDATE message being handled as Treat-as-withdraw
>   according to Section 2.
>
> NEW>
>   ....  The "Flow Specification for SFC Classifiers" extended community
>   interferes with all other Traffic Filtering Actions.  Only the SFC
>   Classifiers action MUST be considered and all others ignored.
>
> If you *really* want to treat-as-withdraw, then here's my suggested
> text to be in line with rfc5575bis:
>
> NEW>
>   ...: a "Flow Specification for SFC Classifiers" Traffic Filtering Action
>   Extended Community advertised with any other Traffic Filtering Action
>   Extended Community MUST be treated as malformed.

We settled on the second of these options.

Best,
Adrian

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 20 Aug 2020 13:30:08 -0700

Thanks Adrian!

I looked at the diffs and reviewed our exchange.

I’m clearing my DISCUSS.

Alvaro.

On August 19, 2020 at 6:11:27 PM, Adrian Farrel ([email-masked]) wrote: