Hi all,
AFAICS, no one else has pitched in on this debate (so we can't really call it a
debate).
The easiest approach to keeping everyone (i.e., Pavan) happy is to take the
following approach.
> 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.
The way I propose to handle it is to add a flag to the FLOWSPEC object with
meaning:
- clear: Use the Flow Filter TLV as a "flow specification"
- set: Use the Flow Filter TLV to install a Longest Prefix Match route
Define a new error "FlowSpec Error" : "Unsupported LPM Route" for use when the
receiver does not support installing an LPM route for the Flow Filter TLV.
An introductory sentence is also added saying:
How an
implementation decides how to filter traffic that matches a Flow
Specification does not form
part of this specification, but a flag is provided to indicate that the
sender of a PCEP
message that includes a Flow Specification is intended to be installed as a
Longest Prefix
Match route, or as a Flow Specification policy.
I'll make the changes to the document, but note that we are well past WG last
call. I hope that with the change we will be able to move ahead.
Look out for the new revision.
Best,
Adrian
-----Original Message-----
From: Vishnu Pavan Beeram <vishnupa...@gmail.com>
Sent: 13 January 2020 12:23
To: Adrian Farrel <adr...@olddog.co.uk>
Cc: pce@ietf.org; draft-ietf-pce-pcep-flows...@ietf.org
Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
Adrian, Hi!
Please see inline..
Regards,
-Pavan
On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel <adr...@olddog.co.uk> wrote:
> 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.
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.
> *From:* Vishnu Pavan Beeram <vishnupa...@gmail.com>
> *Sent:* 10 January 2020 05:45
> *To:* Adrian Farrel <adr...@olddog.co.uk>
> *Cc:* pce@ietf.org; draft-ietf-pce-pcep-flows...@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 <adr...@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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
