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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Jan 2020 22:13:58 -0000

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 9 Jan 2020 23:44:41 -0600

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 <[email-masked]> wrote:

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Jan 2020 16:32:55 -0000

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 <[email-masked]> 
Sent: 10 January 2020 05:45
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi WG,

Thanks,
Adrian

_______________________________________________
Pce mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pce

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 13 Jan 2020 06:22:56 -0600

Adrian, Hi!

Please see inline..

Regards,
-Pavan

On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel <[email-masked]> wrote:

> 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.
>

Existing (network element) implementations have config knobs that
distinguish between adding a filter rule to steer traffic onto the path of
a tunnel and installing a resolver route (LPM based forwarding). And like
with most TE-Tunnel/TE-Policy specific config knobs, there seems to be a
strong desire to let the Controller push/control these knobs. That is where
my options 2 and 3 come in.

>
> 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.
>

I'm not sure about mission creep, but the association of a binding type to
a path does (already) describe the type of traffic steered onto the path.
It results in the installation of a keyed entry in the forwarding plane
with the action of steering the packets matching this entry to the selected
path of the policy. Given the precedent, adding a couple of new binding
types for destination prefixes seems appropriate.

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

Yeah, looking forward to see some opinions come in on this.

>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Vishnu Pavan Beeram <[email-masked]>
> *Sent:* 10 January 2020 05:45
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
>
>
>
> Adrian, Hi!
>
>
>
>    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.