[Idr] 答复: New draft - Flowspec Path Redirect

[Liangqiandeng <[e-mail]>]

Hi Gunter and Robert,

I'm also interested to this question. If you have any deep discuss, please let me know.

After that , I want to discuss a general question for "redirect to Path-id" action.  Can the Path destination be not the terminator of the redirected traffic?  
If it can, maybe we should think about how to avoid traffic-looping.  Do you have any advice in more detail for that?

Best regards,
Qiandeng

-----邮件原件-----
发件人: Idr [mailto:[e-mail]] 代表 Robert Raszuk
发送时间: 2015年9月23日 16:56
收件人: VAN DE VELDE, Gunter (Gunter)
抄送: [e-mail]
主题: Re: [Idr] New draft - Flowspec Path Redirect

Hey Gunter,

Let me ask you a question (which in fact also applies to redirect to next hop draft).

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 ?

I read your draft but other then definition of the encoding I was not able to find answers for this.

The original RFC5575 recommended redirect to local VRF which is just as loopback normally up and within that VRF your orchestration can redirect to next hop or path with whatever encapsulation you like.

Here you (and redirect to next hop folks) are making a shortcut however in both works I have not seen a proper discussion nor definition of set of procedures which need to be executed upon your redirect entity failure.

I suggest both documents are updated with that before we proceed further with both proposals.

Cheers,
R.






On Wed, Sep 23, 2015 at 10:18 AM, VAN DE VELDE, Gunter (Gunter) <[e-mail]> wrote:
> 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-redirec
> t-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/
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr