Re: [Idr] New draft - Flowspec Path Redirect

[Haoweiguo <[e-mail]>]

Hi Lucy & Gunter,

I also think the redirect tunnel can be the one specified by the BGP encapsulation attribute (in draft-ietf-idr-tunnel-encap), in the draft of 'draft-hao-idr-flowspec-nvo3-00', the solution was proposed.   PATH_ID is a new concept, i am still wondering the advantage using PATH_ID rather than existing BGP encapsulation attribute to identify a tunnel, maybe both methods should be supported .



Thanks,

weiguo

________________________________

From: Idr [[e-mail]] on behalf of Lucy yong [[e-mail]]
Sent: Thursday, September 24, 2015 3:58
To: VAN DE VELDE, Gunter (Gunter); [e-mail]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

Hi Gunter, et al,

What is the coincident! I recently talked (offline) to an author of draft-ietf-idr-flowspec-redirect-ip about covering the third case stated in Section 3 of your draft. Do we really need two distinct extended communities for the redirect purpose? IMO: it is not, should be done by one extended community.

In addition, the redirect tunnel can be the one specified by the BGP encapsulation attribute (in draft-ietf-idr-tunnel-encap). Thus, the solution should allow BGP encapsulation attribute to work with some flowspec’s SAFIs, e.g. 133 and 134, and specify the procedure at tunnel ingress.

Regards,
Lucy




From: Idr [mailto:[e-mail]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Wednesday, September 23, 2015 3: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/