On July 5, 2020 at 1:10:06 PM, Adrian Farrel wrote:
Adrian:
Hi!
> > > DISCUSS:
> >>> -------------------------------------------------------------
> >>>
> >>> (1) Controllers and other nodes.
...
> We can, however, make sure that only nodes that are authorised to be
> controllers are allowed to speak as controllers. An approach here would be
> to configure each SFF with the identities of the controllers that it
> accepts. (This, for example, is what is usually done with NMSes. Note that
> in the PCE world, a PCC can be configured with the identities of he PCEs or
> it can discover them). I think we might add...
>
> "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.
> >>> (2) New Flow Specification Traffic Filtering Action
...
> > You>
> > I think that when you program an SFC classifier, that is a single
> > peer-to-peer communication targeted at an SFC Classifier.
> > A 5575-only node will not be a classifier.
> >
> > Me>
> > That is the type of operational considerations that I would like to see
> > the document include.
> >
> > That's all I'm looking for. By "isolating" the communication from
> > potential rfc5575bis-only nodes you eliminate my concern.
>
> OK, we can work something out.
>
> 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
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!
Alvaro.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
