Re: [Idr] New draft - Flowspec Path Redirect

[Lucy yong <[e-mail]>]

Let's get a closer look for 'redirect to tunnel'. IMO: two useful use cases: 1) redirect the flow-spec to a tunnel where the remote tunnel endpoint is different from the BGP next hop of the flow-spec update. This is the case similar to RFC5575 and draft of redirect to IP (but they both are not allowed over a tunnel) 2) redirect traffic to the tunnel where the remote tunnel endpoint is the BGP next hop of the flow-spec update; this is the case for TE and allows BGP flow-spec to be carried by a tunnel that is built by other control protocols such as RSVP-TE, LDP, PCEP, GMPLS. 

To me, the first case is too danger to allow flow-spec via a tunnel to be built by other control protocol (very hard to validate such tunnel), but it is OK for the first case to be carried by a tunnel specified by BGP. For the second case, such tunnel can be built by BGP and non-BGP protocols. To do that, it is necessary to have some interworking (API) between BGP and RSVP-TE (as example) components on a router that support both.

If BGP next hop node can confirm the LSPs built by RSVP-TE to the node, it can advertise the flow-spec to be carried by the LSPs to it. If BGP speaker node supports RSVP-TE and has the LSP to the BGP next hop, it can validate the LSP via the API on the node and get the tunnel's encap info from the API; in data plane, the flow-spec packets can be forwarded to the tunnel accordingly. 

Today, BGP configured VPNs are manually configured to the LSP between PEs. If BGP can interwork with other control (signaling) protocols at the node, it can bind the flow-spec or route with a tunnel that is built by other protocols. IMO: this is very useful capability for automation and traffic engineering. 

The question is should we have one solution to cover both tunnel redirect cases, and one solution to cover BGP specified tunnel and non-BGP built tunnel (i.e. other control protocols). It would be awesome if operators help to validate use cases, which will greatly help on the solution development. 

Jeff- "That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.
If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in the Reserved field may help with some additional semantics?"

BGP has not yet to interwork with a signal control protocol although it interworks with IGP protocol. Yes, it is necessary to have a proper protocol to work with control protocols, but avoid a protocol for each control protocol.

Lucy



     

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Monday, October 05, 2015 1:51 PM
To: Lucy yong
Cc: VAN DE VELDE, Gunter (Gunter); [e-mail]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

On Mon, Sep 28, 2015 at 05:18:43PM +0000, Lucy yong wrote:
> There are active/existing/working vendor implementations of draft-ietf-idr-flowspec-redirect-ip and some SP’s are already using this.
> At the same time the a redirect-ip and a PATH_ID are totally different 
> aspects, even though both are communities… [Lucy] if redirect via an IP tunnel, I don’t see much difference for redirect action. BGP can validate the tunnel reachability. If the path identified by PATH_ID is implemented by different technologies and/or protocols, you are right, the aspect can be very different. However, the difference is not at redirect action itself; it is how BGP control plane can validate the path existence on the data plane and control them. If BGP can do that properly, we can apply such path for a router or a flow spec.

This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question about synchronization or coordination of path-ids at various routers in the AS.

Are there requirements to synchronize the path-ids?
Are the path-ids intended to have "anycast" type properties?

The second rather large issue is something I'll go into more detail in my response for draft-eddy-idr-flowspec-exp:  The authors of the redirect-ip draft ran into issues fairly early on with regard to the coordination of multiple redirect capabilities for a flowspec route.  You can get a sense of some of the complexity by examining the rules in that draft.

Any new drafts covering traffic redirection *MUST* document how they operate with regard to other redirection mechanisms.  This is required not only for interoperability, but also to be clear about the precedence of forwarding behaviors when multiple such behaviors are present.

One question I have is whether this behavior is being sought because there is the impression that arbitrary tunneling is not currently possible.  It's generally understood in the redirect-ip document that the referenced address may be at the end of a tunnel.  That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.
If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in the Reserved field may help with some additional semantics?

-- Jeff