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

Robert Raszuk <> Thu, 13 June 2019 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C93211204EB for <>; Thu, 13 Jun 2019 14:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EBZTEslBzsdP for <>; Thu, 13 Jun 2019 14:06:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8569C12029C for <>; Thu, 13 Jun 2019 14:06:49 -0700 (PDT)
Received: by with SMTP id z24so48097qtj.10 for <>; Thu, 13 Jun 2019 14:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AZkVq1ptqLgNe5Vm+DoWWAKC9iHXOm9Js6XdWwBrEjY=; b=G8c4kJqlKZJHTEVHw7XyOiT4qma67onxlzca7jGCCiBGt/8J5UC0NkQw/wxobz2z8a TWGG6/P/P2pgvlPDa9G4sW9aM+fH8Ku1E5/20lQhE8rBOYOgGlpXeaxfUw3GADV6PIyq Osb1sXKYTB2lFY0eWs+bLtBCXOkOFmuUi8UD7tN6bW1MTfJ63FZogeTAtWIaJXswOwR+ djyguYesHuOEW+m06VndxVhhPKcib3HQAZknWFkoGQeQ8okBB/v7f6gQttBvKQP8PgTf y+J2aN+ptmS11gh+bHGkC+F9V6agUg5h8Bo+abgpKnnXjz0P8NkhBzjziv1ypkmYf5A3 I+bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AZkVq1ptqLgNe5Vm+DoWWAKC9iHXOm9Js6XdWwBrEjY=; b=pJm2IQQ1Rvcd1PlHqEZOIK5pgX4HmEiTUx6IK5Ck048soEoPKuOhDmVbwUHGZD1AZ7 KFpY48Pte+wrgffFOEuVJVX68iKm4HDyB26BLCKRQXW6/MqkII5mM4065oefl0z8lGk4 U2HvSBlzgaxjuyb8JeeNEY2dCxaTfcIAQIUURti/iWr6K9seurl6vt+bRmQ5daHoTLln tZMr9hdUHtQZ8jQvMe1edPrJRyqnL5dMKOjrOZlpLzBKrhmhrvgTLPmbHm7PPOryI10R 4uM3soFsQPWOXI6fEPJRrQ0HYTKVbH02JshNIjUGEfDb8VKJbV6JMcrSRwtlUgYMZURA 7mRA==
X-Gm-Message-State: APjAAAXnSm8I3GCUdtqABFCvUYD0aQ5DT0k19TpXNhs9z/fBG2vVDMW0 nuyOBM3/+nAu+crNf+jjRiuLcdAXrpu94m0YU+6JVg==
X-Google-Smtp-Source: APXvYqwCsgOvIrEhgnn3w22Q4Rmkz2TdXYhYZqM9daoKkyJ8wG7y2lr5Plk0375+gPTS+q0+c+umVE/EfEQnhESwXfw=
X-Received: by 2002:aed:382a:: with SMTP id j39mr75137040qte.94.1560460008385; Thu, 13 Jun 2019 14:06:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 13 Jun 2019 23:06:39 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: John Scudder <>, "" <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000007c860e058b3ae8a1"
Archived-At: <>
Subject: Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2019 21:06:52 -0000


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

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

Thx a lot,

On Thu, Jun 13, 2019 at 10:47 PM Jeffrey Haas <> 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:
> 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