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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
