Subject: Re: [Idr] New draft - Flowspec Path Redirect
From: "Jakob Heitz (jheitz)" <[email-masked]>
To: Liangqiandeng <[email-masked]>, "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Sep 2015 00:57:59 +0000
List-Id: Inter-Domain Routing <idr.ietf.org>

When using extended communities, you can list more than one.
You can only put one copy of an attribute.

--Jakob

From: Idr [mailto:[email-masked]] On Behalf Of Liangqiandeng
Sent: Wednesday, September 23, 2015 2:01 AM
To: VAN DE VELDE, Gunter (Gunter) <[email-masked]>; [email-masked]
Subject: [Idr] 答复: New draft - Flowspec Path Redirect

Hi G. Van de Velde and co-authors,

It may be a good idea to define a new redirect-to-Path-id flow-spec action. A Path-id as an abstract concept can cover the scenarios of redirecting to VPN instance, RT, target IP, output interface or output tunnel.

So it can be more general. But as you has found, The key of this solution is that the BGP Peers should comprehend the locally available redirection information referenced by the Path-id conformably. what do you think to resolve this issue?

In other hand, a flowspec rule bound a tunnel-encap attribute can satisfy the same requirement in some scenarios as the flowspec rule carried with a "redirect to path-id" action. Could you give me some advice how to use them individually?

Best regards,
Qiandeng

发件人: Idr [mailto:[email-masked]] 代表 VAN DE VELDE, Gunter (Gunter)
发送时间: 2015年9月23日 16:18
收件人: [email-masked]
主题: [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/