Re: [Idr] New draft - Flowspec Path Redirect

[Robert Raszuk <[e-mail]>]

Gunter,

> Meaning, that if the receiving router does't have a "valid" entry
> in the locallised path-id table it treats flowspec rule as withdraw.

I don't think "treat-as-withdraw" action is applicable or correct here.

Note that your redirect next hop or redirect path may be down on one
router but up on another.

IMHO there are better options to consider, but since as you indicate
authors already had ideas on that topic I will let authors to present
them in the update draft or by email :)

Cheers,
R.


On Wed, Sep 23, 2015 at 2:43 PM, Gunter Van De Velde
<[e-mail]> wrote:
> 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
> On Wed, Sep 23, 2015 at 10:56 AM, Robert Raszuk <[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