Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec

Adrian, Hi!

Much Thanks for starting this thread! There are multiple implementations
that support user-triggered installation/uninstallation of
destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes
subject to longest prefix match based forwarding) and it is important to
have this behavior covered in PCEP.

I’m listing 3 options that were considered for addressing this item:

   1. Add a new sub-section to Section 8 of <draft-ietf-pce-pcep-flowspec>
   stating that an implementation receiving a FLOWSPEC object that carries
   only destination IPv4/IPv6 TLVs may choose to not install any data-plane
   filters and instead install routes that are subject to longest prefix match
   (LPM) based forwarding. With this option, the controller has no say in how
   the network element processes these destination IPV4/IPv6 TLVs.
   2. Introduce a new flag in the FLOWSPEC object to explicitly indicate
   that routes subject to LPM based forwarding MUST be installed. When this
   flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs.
   3. Do not use the FLOWSPEC object at all for this; Use the
   TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid)
   instead. This requires the addition of a couple of new Binding Types (BT)
   to indicate destination-IPV4 and destination-IPv6 bindings. This also
   requires us to add the ability to encode multiple Path Bindings (list)
   in the same message and the ability to remove specific Path Bindings in a
   given message.

Based on some offline conversations with interested parties, there is a
strong need to have an explicit indication for this type of behavior (avoid
ambiguity with respect to filtering) -- so that makes Option 1 undesirable.
There is also a requirement to carry a mix of install and uninstall
destination prefixes associated with a path in the same message. The way
the FLOWSPEC object is currently defined (the R flag is specified per
FLOWSPEC object and not per TLV; parity with BGP), you would need one
object to carry the install prefixes and one more to carry the uninstall
prefixes. Given all this, there is some consensus among interested parties
to implement this behavior using the TE-PATH-BINDING TLV. Note that this
also means that draft-ietf-pce-pcep-flowspec can proceed as is.

@WG -- Any thoughts?

Regards,

-Pavan

On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi WG,
>
> I received a couple of private emails about draft-ietf-pce-pcep-flowspec.
>
> Since they were private, I will try to be circumspect about who they were
> from.
>
> The sender asked to have a flag attached to a flow specification that
> indicates that it can be installed as a static route and thus not subject
> to
> a firewall rule so the longest prefix matching can be performed to
> manipulate route resolution for an LSP.
>
> The request also said that traditionally flow-specifications result in
> firewall rules and those rules operate on packets before longest prefix
> match. We want to install static routes, the equivalent of installing a
> prefix for an LSP and if we treat a flowspec as a static route we can mess
> things up like rule ordering and so on.
>
> The sender suggested that there are currently some draft(s) regarding this
> behavior for BGP flowspec as well, but was not able to point me at them.
>
> I asked for some clarifications and got back:
>
> "What BGP-FS does is install data-plane filters.  We handle that by
> installing RIB entries (that's what BGP carries) into a RIB. Those entries
> are transformed into firewall filters.  What I am asking for is not
> currently supported by BGP-flowspec.
>
> "What I am asking for is an indication that a flow-specification NOT be
> transformed into a data-plane filter.  In other words, installed as a
> normal
> route where the route is subject to longest prefix match based forwarding.
> If you consider how we had to implement the multicast support for PCEP
> flowspec, it is quite similar.  So, in my mind, the 'flag' is an indicator
> to do LPM for a destination.  Presence of the flag also means that no other
> fields can be present in the flowspec, e.g. source address or dest/src L4
> ports, etc."
>
> In my view, it should not be too hard to add a flag to the PCEP flow
> specification.
>
> But a couple of questions for the working group and my co-authors:
> - Does anyone else have interest in this work?
> - Can anyone else identify the related BGP work?
> - Does anyone want to suggest text for this?
> - Is this something we should leave as a future extension that can be
> proposed if/when someone cares about it?
>
> I suspect that the default position is "do nothing" and ask Julien to move
> the draft forward, so if you care please speak up.
>
> Thanks,
> Adrian
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>