Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Jeffrey Haas <jhaas@pfrc.org> Mon, 02 December 2019 17:22 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEDD120835 for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 09:22:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXfnRD96RY4q for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 09:22:11 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1E999120834 for <idr@ietf.org>; Mon, 2 Dec 2019 09:22:09 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C9DDD1E2F5; Mon, 2 Dec 2019 12:26:21 -0500 (EST)
Date: Mon, 2 Dec 2019 12:26:21 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Cc: Sue Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20191202172621.GG18175@pfrc.org>
References: <016501d59dd2$e5458850$afd098f0$@ndzh.com> <D0AA5E62-4AE5-43A5-BA23-E66D98AF657B@pfrc.org> <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/EvoiRzrNGlHw4q1ijEpzrq3Hjkw>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 17:22:13 -0000

Gunter,

On Fri, Nov 29, 2019 at 03:51:35AM +0000, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> > Procedure-wise, there needs to be a bit more text covering cases about interactions with other traffic actions.  This was a known headache for similar drafts such as redirect-to-ip.  In particular, interaction with redirect-to-ip and redirect-to-vrf is needed.
> 
> GV> Section "6. Validation Procedures" gives input on this. We discussed this with you long ago and hence this text was added.
> 
> "
>    While it MUST NOT happen, and is seen as invalid combination, it is
>    possible from a semantics perspective to have multiple clashing
>    redirect actions defined within a single flowspec rule.  For best and
>    consistant compatibility with legacy implementations, the redirect
>    functionality as documented by rfc5575bis MUST NOT be broken, and
>    hence when a clash occurs, then rfc5575bis based redirect MUST take
>    priority.
> "
> 
> This means that redirect-to-VRF will take absolute priority to not break rfc5575bis behavior.
> Having also redirect-to-ip will result in an invalid

Redirect-ip isn't even mentioned in the draft.

Part of the reason to raise this is whether intentional interactions could
happen.  As an example, redirect-ip is specced to be permitted in the
context of a VRF redirection.

I suspect in the majority of the cases that path-redirect is intended
involving segment routing that following a segment path from a VRF context
doesn't make much sense.  However, some of the cases are left as much more
abstract and perhaps they could?

My point is that a bit more normative text on the various cases would be
needed for interoperable code.

> > The text "A single flowspec rule MUST NOT have more as one indirection-id per S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST be imposed first for any given flowspec entry."  There's no procedure for what happens in error handling when you do have more than one of the same S-ID.  The text about the case for S-ID of 0 is also a bit ambiguous.  It feels like it's reading "there is no sequence", but what do you do when you then have ones that do?
> 
> GV> What about the following rewrite:
> 
> Original:
>     The 'S-ID' field identifies a 4 bit Sequence ID field.  This field is
>    used to provide a flowspec client an indication how and where to
>    sequence the received indirection-ids.  The Sequence ID value 0
>    indicates that Sequence ID field is NOT set and SHOULD be ignored.  A
>    single flowspec rule MUST NOT have more as one indirection-id per
>    S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST
>    be imposed first for any given flowspec entry.
> 
> New:
>    The 'S-ID' field identifies a 4 bit Sequence ID field.  This field is
>    used to provide a flowspec client an indication how and where to
>    sequence the received indirection-ids.  The Sequence ID value 0
>    indicates that Sequence ID field is NOT set and **all other sequence ID's**
>    SHOULD be ignored.  A
>    single flowspec rule MUST NOT have more as one indirection-id per
>    S-ID.  On a flowspec client the indirection-id with lowest S-ID MUST
>    be imposed first for any given flowspec entry.

Aside comment: Any possibility this could be renamed Seq-Id or something
similar to avoid name confusion to SID?

The text above is clearer, but I'm not sure it really helps your case.  Here
is what I believe the intent to be in pseudo-code:

if Seq-ID == 0 is present:
  apply actions, if possible.
  exit
foreach s in Seq-Id 1..15:
  if s is present:
     if action for s is possible:
        apply it.
        exit
     else:
        continue

Basically, try each sequence in turn.  If you can do something with it,
you're done.  If you can't (the indirection can't be applied for numerous
reasons), try next.  S-ID zero is intended to be a "hard stop".

The 'C' bit also looks like it only changes the stream behavior and doesn't
impact whether the rule is terminating or not.

What's still not covered, since these are extended communities, is cases
like there are two of a given S-ID present.  Perhaps it was added via blind
policy?  What do you do?  

> "
>    While it MUST NOT happen, and is seen as invalid combination, it is
>    possible from a semantics perspective to have multiple clashing
>    redirect actions defined within a single flowspec rule.  For best and
>    consistant compatibility with legacy implementations, the redirect
>    functionality as documented by rfc5575bis MUST NOT be broken, and
>    hence when a clash occurs, then rfc5575bis based redirect MUST take
>    priority.  Additionally, if the "Redirect to indirection-id" does not
>    result in a valid redirection, then the flowspec rule MUST be
>    processed as if the "Redirect to indirection-id" community was not
>    attached to the flowspec route.
> "
> 
> GV> Is there more to add to this? (We could add a line to detail that "redirect-to-ip" is incompatible with "redirect to indirection-id" and result in invalid redirection rule, however to me that is already implied with enough detail in the text above)

redirect-to-ip is not core to 5575bis, so clarity as to precedence would be
helpful, I think.

> > A few IANA issues:
> > I see the type registry is currently registered with IANA (code point 0x09).  However, the sub-type registry is not established for some reason?
> > The ID-Type field likely needs its own IANA registry.  Values 1-5 are defined in this draft.
> 
> GV> Correct. There is a reason for this. When we asked IANA the code-points they informed me that once the document get to RFC the sub-type registry will be established by IANA.

Understood.  They sometimes like to operate this way.  

-- Jeff