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. > > > Cheers, > > Adrian > > > > *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.. > 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 > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
