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

[Jeffrey Haas <[e-mail]>]

Gunter,

On Tue, Dec 03, 2019 at 10:09:19AM +0000, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> > 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.
> 
> ***
> GV2> The original concept was to have an abstract steering correlation towards a 32bit tunnel-ID (This is an action, opaque to VRF, or any other associated contexts). If indeed a matter of context is added to the redirection id (for example the 32 bits represent a Segment path) then that few more normative text could be added on the cases.

It makes sense to do that then.  The redirect-ip case does specifically call
out that you can do the redirect in the VRF table context.  What you'll be
doing is effectively highlighting whether the abstract indirection table is
box-wide or scoped to specific tables.

Ideally, this will let you think through the yang implications of the
feature as well.

> > 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".
> 
> ***
> GV2> Thanks. let me think on how to integrate this best

Thanks.  I think that will add needed clarity.

> > 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?  
> 
> ***
> GV2> ok, my personal understanding is that rule is invalid, and then the flowspec rule MUST be
> processed as if the "Redirect to indirection-id" community was not attached to the flowspec route.

That's one option.  A similar one includes testing the usability of the
rule, as I noted in the pseudocode.  Let me drawn an analogy (perhaps a poor
one) from redirect-ip:

Consider a flowspec route with redirect-IP:A and redirect-ip:B.

If A is resolvable (per BGP route resolution rules) and B is not, it's
clearer that you want to use what can actually work.  If both are
resolvable, then an implementation may choose to use both for load
balancing.

Going back to indirection-id, if you have conflicting rules, but similar
"can this work" tests, do you really want to reject it solely because the
rules may appear conflicting?  Perhaps.

Unlike redirect-to-ip, I have no strong opinions about whether to permit
load balancing or other similar behaviors rather than consider it invalid.
What I will absolutely note is that troubleshooting this from extended
community output on a BGP route is likely to be more than a little awkward
at best.  Consider that most implementations tend to simply display extended
communities in their internal sort order (often effectively memcmp()) rather
than something that's more lexicographically ordered for troubleshooting
this feature.

-- Jeff