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

Thanks Pavan,

It’s good to have this documented clearly.

Personally, I am amused/confused that *how* packets are intercepted for classification (via a routing entry or via a data plane filter) is important to the specification of this protocol. That is, the protocol says “packets that match this flowspec MUST be placed on this LSP/path”. How an implementation chooses to achieve that is, IMHO, not material to the on-the-wire behaviour. That is, the packets will come in and will be placed on the path, and the protocol instructions to achieve it do not need to tell anyone how to achieve it.

This is probably closest to your option 1. That is, an implementation may choose to implement this however it wants.

It would be wrong, also IMHO, to imply that an implementation must install a data plane filter to handle PCEP flowspecs. That depends (of course) on how you define a data plane filter.

As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep. What was originally a simple association of a binding SID to a PCEP message now also has an element of flowspec built in. I wonder whether that document shouldn’t refer to draft-ietf-pce-flowspec if it wants to describe what traffic to associate with a path.

Like you, I would like to hear more from the working group.

Cheers,

Adrian

From: Vishnu Pavan Beeram <vishnupavan@gmail.com> 
Sent: 10 January 2020 05:45
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: pce@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org
Subject: 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 <mailto: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 <mailto:Pce@ietf.org> 
https://www.ietf.org/mailman/listinfo/pce