Thanks Alvaro!
>> "In an environment where there is concern that rogue Controllers might be
>> introduced to the network and inject false SFPRs or take over and change
>> existing SFPRs, it is RECOMMENDED that each SFF and Classifier be
>> configured with the identities of authorised Controllers. Thus, the
>> announcement of an SFPR by any other BGP peer would be rejected."
>>
>> Would that be good?
>
> I don't think that the initial qualification ("in an environment...")
> is needed; the action is RECOMMENDED, so the operator can decide
> when/if they want to follow it. Otherwise it looks good to me.
OK
"Where there is concern..."
>> How about:
>>
>> Note that implementation of this section of this specification will be
>> Controllers or Classifiers communicating with each other directly for the
>> purpose of instructing the Classifier how to place packets onto an SFP. In
>> order that the implementation of Classifiers can be kept simple and to
>> avoid the confusion between the purpose of different extended communities,
>> a Controller MUST NOT include other action extended communities at the same
>> time as a "Flow Specification for SFC Classifiers" extended community: 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.
>
> s/action extended communities/Traffic Filtering Action Extended Communities
Ack
> 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.
Thanks. I can accept either of your suggestions. I'm going to do some
archaeology to remind myself where the treat-as-withdraw came from. I have some
memory that it was IDR that pushed us to have this (and other) error actions,
but I may well be misremembering. Depending on what I discover, I will pick one
or the other of the suggestions and re-post.
Cheers,
Adrian
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
