Re: [Idr] New draft - Flowspec Path Redirect

["Susan Hares" <[e-mail]>]

Gunter: 

 

I am responding to the beginning of this thread to indicate my review of the mail thread from until 10/8. 

 

General comment: 

·         Extended community is a redirect ‘path-id’ (128bit/32 bit)  which is similar to the draft-hao-idr-flowspec-redirect-tunnel-00.txt. 

·         Your draft assumes as localized path-id indexed table.  Draft-hao-idr-flowspec-redirct-tunnel-00.txt assumes an extensions to the BGP Tunnel Encapsulation Attribute that points to a tunnel.  

·         Your extended community TID + C (Copy) bit.   The draft-hao-idr-flowspec-redirect-tunnel-00.txt contains “C (Copy) bit. 

·         Your TID states – “to provide the router consuming the flowspec rule an indication of how and where to use the path-id when redirectin traffic”.  No further details are provided for this field so it is difficult to understand it. 

 

As far as I can tell you have not answered the following questions: 

·         What is the expected system action when the redirect path is down (assuming you have tools to detect it) or next hop you are redirecting it to is unreachable ? (Robert Razuk)?

o   [Lucy] We need use case integrity inspection. For this reason, I agree with Robert, we need first specifying PATH ID semantics that is relevant to BGP.  

o   [Jeff]: 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.

o   pHeff

·         [Jeff/Lucy’s comment]:  How Path-id and redirect ID are totally different aspects? 

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

o   [Lucy] We need use case integrity inspection. For this reason, I agree with Robert, we need first specifying PATH ID semantics that is relevant to BGP.  

o   [Jeff]: 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?

§  [Jeff] 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.

o   [Jeff] 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?

 

·         Set-up of tunnel

o   Gunter: A tunnel is setup between head-end and tail-end… so to direct a recipient router to send interesting traffic into an engineered tunnel and at the same time  exchange the tunnel setup parameters is non-trivial.

o   [Lucy] This is what draft-ietf-idr-redirect-ip specified. To redirect a flow over an IP tunnel brings the benefit to keep the flow packet IP dest on the tunneled packet and carries the redirect point IP address as outer src IP, which is useful for other applications. For example, which location the flow packet is sent to and which location the flow packet is redirected at. To redirect over an IP tunnel, this draft can easily be extended to cover that.

·         Why you consider this draft to be “simple” [Sue Hares] 

It would be good to plan to cover this information for interim (if you present), and at IETF. We will be scheduling the flowspec and path drafts during the same time period.  

Sue Hares 

 

From: Idr [mailto:[e-mail]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Wednesday, September 23, 2015 4:18 AM
To: [e-mail]
Subject: [Idr] New draft - Flowspec Path Redirect

 

Hi Folks,

 

We have created a new draft to allow the capability to have Flowspec signal a redirect to tunnel/LSP.

 

https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00

 

The base principle is to use the indirection capability of BGP for path redirection.

 

This proposal defines a new flowspec community to signal a redirect ‘path-id’. This path-id is is either a 128bit or 32bit value 

Assumed is that recipient router supporting path-id redirect have a localised path-id indexed table containing LSP/tunnel encapsulation information.

Existing technology can be used to construct/create this table (LDP, SR, RSVP, manual-config, etc…) on a recipient router. The LSP/tunnel encap table is indexed using 32 or 128 bit values.

   

Flowspec path-id community is used to activate a redirect LSP/tunnel and provide by indirection the LSP/tunnel information for the flowspec identified traffic towards the LSP/tunnel. 

 

Benefits: 

*	no need for signalling labels or extra encap in BGP
*	Each path-id indexed LSP/tunnel table is a localised construct
*	existing technology is used to construct the path-id indexed localised table
*	Compatibility with technologies already using 32 or 128 bit identifiers for paths and sessions
*	Easy for flow spec to signal as it introduces no need to signal labels etc… no conflicts with existing label exchange technologies

Feedback welcome.

 

G/