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

[John Scudder <[e-mail]>]

Hi Authors and WG,

I just had it brought to my attention that RFC 5575 and draft-ietf-idr-rfc5575bis both are underspecified with regard to the validation procedures. The problem is what to do if a flow-spec NLRI doesn't contain a destination prefix component. Section 4.2 makes it clear that destination prefix is optional, so it's valid for it not to be present. But the first set of validation steps in section 6 are written in terms of the destination prefix, without acknowledging it might not be there.

This leaves a gap for an interoperability problem, where some implementations might choose to consider validation to have succeeded if the destination prefix component isn't present, and others might consider it to have failed.

To fix this ambiguity I'd like to suggest the following change. The summary is we add a new rule (a), renumber the old (a) and (b), and add a note following.

OLD:
   A Flow Specification NLRI must be validated such that it is
   considered feasible if and only if:

      a) The originator of the Flow Specification matches the originator
      of the best-match unicast route for the destination prefix
      embedded in the Flow Specification.

      b) There are no more specific unicast routes, when compared with
      the flow destination prefix, that has been received from a
      different neighboring AS than the best-match unicast route, which
      has been determined in step a).

NEW:
   A Flow Specification NLRI must be validated such that it is
   considered feasible if and only if:

      a) A destination prefix component is embedded in the Flow 
      Specification.

      b) The originator of the Flow Specification matches the originator
      of the best-match unicast route for the destination prefix
      embedded in the Flow Specification.

      c) There are no more specific unicast routes, when compared with
      the flow destination prefix, that has been received from a
      different neighboring AS than the best-match unicast route, which
      has been determined in step b).
      
   Rule a) MAY be relaxed by configuration, permitting Flow
   Specifications that include no destination prefix component. If such
   is the case, rules b) and c) are moot and MUST be disregarded.

We need the MAY clause since 4.2 does say destination prefix is optional, and also because an operator might actually want to permit this under some circumstances, particularly if the route is internally sourced. I'll also point out that another way according to the proposed rule set to have a flow-spec that matches every packet is to actually put /0 in the destination prefix, then you don't need the optional configuration mentioned in the MAY clause (you do need to accept default for validation to succeed, but that's inherent in flow-spec's design).

The draft has already passed WGLC and been sent to the IESG. But given that it's always easier to correct problems sooner rather than later, I've just pulled it back to the WG. I'm hoping we can have quick consensus on what to do --

- Adopt the fix I've suggested,
- Adopt a different fix,
- Determine that no fix is needed.

We could also let the IESG resolve this but it doesn't seem like good WG hygiene.

I'd like to keep the discussion tightly scoped to just the minimum necessary to clarify section 6.

Let's have the traditional two week window for discussion, to end by June 28.

Thanks,

--John