Re: [Idr] New draft - Flowspec Path Redirect

[Gunter Van De Velde <[e-mail]>]

Interresting question... I see few options to address this. (And fwiw, i left
this currently intentionally out the text to see if some ideas pop-up to confirm
or deny the ideas the authors had on this topic)

The one which currently to me resonates most is to treat the path-id similar as
a traditional bgp next-hop address... Meaning, that if the receiving router
does't have a "valid" entry in the locallised path-id table it treats flowspec
rule as withdraw.

Decision on what is considered "valid" is at first glance a local router
decision.

If you have another proposal i would be happy to learn and see if it resonates.

Ciao,
G/



Sent using CloudMagic Email
[https://cloudmagic.com/k/d/mailapp?ct=pa&cv=7.3.5&pv=5.1.1&source=email_footer_2] On Wed, Sep 23, 2015 at 10:56 AM, Robert Raszuk < [e-mail] [[e-mail]] > wrote:
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-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/
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>

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