Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period

[Robert Raszuk <[e-mail]>]

Jeff,

Let me explain the full picture - was just staying focused on John's mail.

When I suggested that destination type should be mandatory I did mean the
base use case of DDoS mitigation.

For other use cases validation will be disabled anyway in all cases hence
we do not have an issue to start with. Nowhere I stated that validation
must be mandatory.

Now that fact that some use cases of flow spec go beyond DDoS mitigation
today my understanding is that future documents will describe it well as
they already go beyond base spec. I would actually recommend to use
different SAFI for those additional use cases clearly separating both - if
for nothing else then for concurrent ability to validate filters for DDoS
while filling much more free to use same mechanism for intradomain use
cases.

And to the point of treating missing destination as 0/0 I think it is not a
good idea. It may break even more things especially in other then DFZ
environments.

Thx a lot,
R.


On Thu, Jun 13, 2019 at 10:47 PM Jeffrey Haas <[e-mail]> wrote:

> Robert (and 5575bis authors),
>
> On Thu, Jun 13, 2019 at 08:26:28PM +0200, Robert Raszuk wrote:
> > RFC5575 has been written as DDoS mitigation tool and 5575bis attempts to
> > clarify various ambiguities of the base spec.
> >
> > We as the WG have decided that numerous 5575 extensions (for example
> those
> > injected by controllers or NMS) will be specified in different documents
> > and not be embedded into base Flow Specification one.
> >
> > With that if we agree that DDoS mitigation is still our target for the
> base
> > spec I would tent to suggest that destination field to be made mandatory
> > for real DDoS mitigation use case. Relaxing that could be done for other
> > Flow Spec use cases in their separate documents, but outside of the base
> > spec.
> >
> > So the only change which may be needed would be add:
> >
> > 4.2.  NLRI Value Encoding
> >
> >    The Flow Specification NLRI-type consists of several optional
> >    subcomponents (except Type 1 which is mandatory).
>
> While I agree that DDoS mitigation is the core use case for flowspec in its
> current form, your suggested change will likely have negative impacts on
> implementations.  Destination-less filters exist and get deployed, and the
> text you're suggesting makes them not-only non-compliant but arguably
> mal-formed.
>
> I think where we have some room for discussion is where we draw the line
> for
> validation in the default case vs. the clarification:
>
> https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08
>
> I believe the reason the discussion is needed in a 5575-bis context is that
> we have an obvious hole in the core spec as to what we should do for what
> is
> intended to be a compliant case.
>
> Whether the text we converge on obviates the need for the -oid draft is an
> open question.
>
> -- Jeff
>