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

[Lizhenbin <[e-mail]>]

Hi Gunter and Robert,
We are also doing similar work. Regarding the draft, the major concern is as follows:
1. What does the PATH_ID represent? Does it mean only tunnel/LSP or all possible forwarding path including tunnel/LSP, interface, VRF, nexthop, etc?
2. How to allocate the PATH_ID for the forwarding path?
We think the forwarding behavior for Flowspec is always actual forwarding concepts including VRF, nexthop, etc. So we proposed ‘redirect to tunnel’ in similar way. But for PATH_ID you proposed is another way to generalize all possible forwarding path. It may be a new way to define forwarding behavior for BGP Flowspec.

Regarding redirecting tunnel, we proposed several drafts for your reference:
-- draft-hao-idr-flowspec-nvo3-00
-- draft-li-idr-mpls-path-programming-01
-- draft-li-spring-tunnel-segment-00
-- draft-chen-pce-pce-initiated-ip-tunnel-00
-- draft-li-pce-tunnel-segment-00

As Weiguo mentioned, the "redirect to Tunnel" for BGP Flowspec has been described briefly in draft-hao-idr-flowspec-nvo3-00. We will split it into two drafts: 1. draft-hao-idr-flowspec-nvo3-01; 2. one independent draft to define the "redirect to tunnel" for BGP Flowspec.

For "redirect to tunnel" for BGP flowspec, in fact there can be two types of such behaviors:
1. Specify the tunnel type:
For this behavior, we will reuse the IP tunnel types defined in [draft-rosen-idr-tunnel-encaps-00] and the MPLS tunnel types defined in [draft-li-idr-mpls-path-programming-01].
2. Specify the specific tunnel:
For MPLS TE tunnel, there can be multiple MPLS TE tunnels for a specific destination. The tunnel type may be not enough. Then it is necessary to specify the specific MPLS TE tunnel through Tunnel Identifier. [RFC3209] defined the Tunnel Identifier for MPLS TE tunnel. PCE-initiated LSP adopted the Tunnel Identifier for which tunnel ID can be allocated by PCE. [draft-li-idr-mpls-path-programming-01] will try to reuse the tunnel identifier and define it in the tunnel attribute which can be used for "redirect to tunnel" in [draft-hao-idr-flowspec-nvo3-00].
For IP tunnel, there is always only one IP forwarding path for a specific destination. So When define "redirect to specific IP tunnel" the nexthop plus the tunnel type may be enough in the existing deployment. As the development of IP tunnels, it may be popular to configure multiple IP tunnels for the specific destination. For examples we can define multiple MPLS-in-UDP tunnels for which the destination is same and the port number can be different for the purpose of ECMP. In order to cope with such development, [draft-chen-pce-pce-initiated-ip-tunnel-00] is proposed to introduce the tunnel identifier for IP tunnels for which tunnel ID can also be allocated by PCE as the MPLS TE tunnel. It may be also reused in the tunnel attributes for the "redirect to tunnel".

We think if it is only to think about "redirect to tunnel" for the BGP Flowspec there has already been much existing work and it is better to reuse them.

In fact the existing work to specify a specific tunnel the tunnel identifier is a combination with the ingress address/egress address and tunnel ID. But for the draft draft-vandevelde-idr-flowspec-path-redirect-00, PATH_ID can be only one value to represent one tunnel. Recently we proposed the drafts draft-li-spring-tunnel-segment-00/ draft-li-pce-tunnel-segment-00 in which the segment ID/label can be allocated for a tunnel. This is also to use one value to represent a tunnel. Now Segment Routing has defined many types segments which can map to different forwarding path such as interface, node, tunnel, etc. From my point of view, the work to define Segment-ID/Label and PATH-ID for the forwarding path can be consolidated and incorporated in the SRPING work. If we hope to define the generalized concept, maybe we can define “Redirect to Segment” for the BGP Flowspec. In [draft-li-idr-mpls-path-programming-01], we define the label combination attributes to map the service to the MPLS forwarding path. Maybe it can be enhanced to SID stack attribute to map to general forwarding path which can be used for multiple BGP address family including BGP Flowspec.

This is about our thinking on the "redirect to tunnel/path" work. Hope to get your opinion on it.


Best Regards,
Zhenbin(Robin)






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


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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr
>

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