Subject: [Idr] New draft - Flowspec Path Redirect

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Wed, 23 Sep 2015 08:18:09 +0000

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/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Sep 2015 10:56:03 +0200

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)
<[email-masked]> wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Liangqiandeng <[email-masked]>
Date: Wed, 23 Sep 2015 09:01:05 +0000

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,

Benefits:

G/

---

From: Liangqiandeng <[email-masked]>
Date: Wed, 23 Sep 2015 12:02:49 +0000

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

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 23 Sep 2015 14:43:32 +0200

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 < [email-masked] [[email-masked]] > wrote:
Hey Gunter,

Cheers,
R.

---

From: Haoweiguo <[email-masked]>
Date: Wed, 23 Sep 2015 15:08:25 +0000

Hi Gunter,

Redirect to tunnel is useful, it is a shortcut method compared with using redirect to VRF or next hop. This problem was proposed in my draft of 'draft-hao-idr-flowspec-nvo3-00', the possible usecase is for service chaining on the classifier and traffic steering. However, i propose another method for the 'redirect to tunnel' action rather than using pathID. I use BGP path attribute to carry the set of tunnels which needs to be redirected.

I also would like to hear the community's opinion for these two solutions, whether directly specify the tunnel attribute in BGP flowspec message or only specify pathid to represent a tunnel indirectly?

Thanks,

weiguo

________________________________
From: Idr [[email-masked]] on behalf of VAN DE VELDE, Gunter (Gunter) [[email-masked]]
Sent: Wednesday, September 23, 2015 16:18
To: [email-masked]
Subject: [Idr] New draft - Flowspec Path Redirect

Hi Folks,

Benefits:

Feedback welcome.

G/

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 19:58:17 +0000

Hi Gunter, et al,

What is the coincident! I recently talked (offline) to an author of draft-ietf-idr-flowspec-redirect-ip about covering the third case stated in Section 3 of your draft. Do we really need two distinct extended communities for the redirect purpose? IMO: it is not, should be done by one extended community.

In addition, the redirect tunnel can be the one specified by the BGP encapsulation attribute (in draft-ietf-idr-tunnel-encap). Thus, the solution should allow BGP encapsulation attribute to work with some flowspec’s SAFIs, e.g. 133 and 134, and specify the procedure at tunnel ingress.

Regards,
Lucy

From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Wednesday, September 23, 2015 3:18 AM
To: [email-masked]
Subject: [Idr] New draft - Flowspec Path Redirect

Hi Folks,

Benefits:

G/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Sep 2015 23:03:31 +0200

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
<[email-masked]> 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.
>
> On Wed, Sep 23, 2015 at 10:56 AM, Robert Raszuk <[email-masked]> wrote:
>
> Hey Gunter,
>
>> We have created a new draft to allow the capability to have Flowspec
>> signal
>> a redirect to tunnel/LSP.
>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Sep 2015 23:08:23 +0200

Hi Lucy,

I agree that having one document vs two similar ones would be better.

However authors of the latest one introduced new term "PATH_ID" which
I do not think we have ever defined before. It is more then tunnel
endpoint and encapsulation.

It is effectively an abstract ID which may indicate number of stiched
tunnels - be it MPLS LSPs, nested GRE or segments.

I do not know where it belongs (maybe RTGWG) but to me a concept of
PATH_ID if at all necessary needs to be defined in a separate document
to be a normative reference across number IETF WGs.

Best,
R.

On Wed, Sep 23, 2015 at 9:58 PM, Lucy yong <[email-masked]> wrote:
> Hi Gunter, et al,
>
>
>
> What is the coincident! I recently talked (offline) to an author of
> draft-ietf-idr-flowspec-redirect-ip about covering the third case stated in
> Section 3 of your draft. Do we really need two distinct extended communities
> for the redirect purpose? IMO: it is not, should be done by one extended
> community.
>
>
>
> In addition, the redirect tunnel can be the one specified by the BGP
> encapsulation attribute (in draft-ietf-idr-tunnel-encap). Thus, the solution
> should allow BGP encapsulation attribute to work with some flowspec’s SAFIs,
> e.g. 133 and 134, and specify the procedure at tunnel ingress.
>
>
>
> Regards,
>
> Lucy
>
>
>
>
>
>
>
>
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 21:37:08 +0000

Hi Robert,

I understand that the new draft adds additional redirect scenario and a new term, but it would be nice to have one draft and one extended community to cover the BGP redirect feature: over IP, a tunnel over IP, or over a path identified by a PATH_ID.  

Please see inline below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, September 23, 2015 4:08 PM
To: Lucy yong
Cc: VAN DE VELDE, Gunter (Gunter); [email-masked]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

Hi Lucy,

However authors of the latest one introduced new term "PATH_ID" which I do not think we have ever defined before. It is more then tunnel endpoint and encapsulation.

It is effectively an abstract ID which may indicate number of stiched tunnels - be it MPLS LSPs, nested GRE or segments.

I do not know where it belongs (maybe RTGWG) but to me a concept of PATH_ID if at all necessary needs to be defined in a separate document to be a normative reference across number IETF WGs.
[Lucy] You mean that the PATH_ID semantics need to be specified first and it can apply to a route and flow redirect, is that right?

Thanks,
Lucy

Best,
R.

On Wed, Sep 23, 2015 at 9:58 PM, Lucy yong <[email-masked]> wrote:
> draft-ietf-idr-flowspec-redirect-ip about covering the third case 
> stated in Section 3 of your draft. Do we really need two distinct 
> extended communities for the redirect purpose? IMO: it is not, should 
> be done by one extended community.
>
>
>
> encapsulation attribute (in draft-ietf-idr-tunnel-encap). Thus, the 
> solution should allow BGP encapsulation attribute to work with some 
> flowspec’s SAFIs, e.g. 133 and 134, and specify the procedure at tunnel ingress.
>
>
>
> Regards,
>
> Lucy
>
>
>
>
>
>
>
>
>
> From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, 
> Gunter
> (Gunter)
> signal a redirect to tunnel/LSP.
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Sep 2015 23:45:48 +0200

> [Lucy] You mean that the PATH_ID semantics need to be specified first and it can apply to a route and flow redirect, is that right?

Yes precisely right on the spot.

Moreover I do not think this is IDR WG which should define it. The
concept is clearly much broader then related to BGP Flowspec :)

The closest I can think of in the analogy space would be the notion of
forwarding adj where LSP is injected and flooded by link state
protocol as a new type of link.

Here however we are dealing with a new description for concatenated
set of encapsulations, segments or LSPs. I am not clear which WG has
such responsibility in the charter .. as mentioned maybe RTGWG ..
maybe PCE ?

Thx,
r.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 24 Sep 2015 00:57:59 +0000

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

Best regards,
Qiandeng

Hi Folks,

Benefits:

G/

---

From: Haoweiguo <[email-masked]>
Date: Thu, 24 Sep 2015 01:06:33 +0000

Hi Lucy & Gunter,

I also think the redirect tunnel can be the one specified by the BGP encapsulation attribute (in draft-ietf-idr-tunnel-encap), in the draft of 'draft-hao-idr-flowspec-nvo3-00', the solution was proposed.   PATH_ID is a new concept, i am still wondering the advantage using PATH_ID rather than existing BGP encapsulation attribute to identify a tunnel, maybe both methods should be supported .

Thanks,

weiguo

From: Idr [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Thursday, September 24, 2015 3:58
To: VAN DE VELDE, Gunter (Gunter); [email-masked]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

Hi Gunter, et al,

Regards,
Lucy

Hi Folks,

Benefits:

G/

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Sep 2015 14:56:48 +0000

Inline with [lucy1]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, September 23, 2015 4:46 PM
To: Lucy yong
Cc: idr wg
Subject: Re: [Idr] New draft - Flowspec Path Redirect

Moreover I do not think this is IDR WG which should define it. The concept is clearly much broader then related to BGP Flowspec :)
[Lucy1] Agree. The Path_ID associated path may not be implemented by IP or MPLS. The work related to IDR is only how to distribute a flow (or a route) and path binding by BGP.

The closest I can think of in the analogy space would be the notion of forwarding adj where LSP is injected and flooded by link state protocol as a new type of link.

Here however we are dealing with a new description for concatenated set of encapsulations, segments or LSPs. I am not clear which WG has such responsibility in the charter .. as mentioned maybe RTGWG ..
maybe PCE ?
[Lucy1] According RT Area rule, in this case, RTG WG will be the best place to start since the path implementations relate to many WGs unless we are clear that one particular path implementation makes a sense to this usage. 

Thx,
Lucy

---

From: Lizhenbin <[email-masked]>
Date: Mon, 28 Sep 2015 11:16:48 +0000

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:[email-masked]] 代表 Gunter Van De Velde
发送时间: 2015年9月23日 20:44
收件人: Robert Raszuk
抄送: [email-masked]; 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.

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hey Gunter,

Cheers,
R.

On Wed, Sep 23, 2015 at 10:18 AM, VAN DE VELDE, Gunter (Gunter)
<[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

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

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Mon, 28 Sep 2015 15:54:59 +0000

Hi Lucy,

There are active/existing/working vendor implementations of draft-ietf-idr-flowspec-redirect-ip and some SP’s are already using this.
At the same time the a redirect-ip and a PATH_ID are totally different aspects, even though both are communities…

A tunnel is setup between head-end and tail-end… so to direct a recipient router to send interesting traffic into an engineered tunnel and at the same time
exchange the tunnel setup parameters is non-trivial. Hence the abstraction as mentioned in draft-vandevelde-idr-flowspec-path-redirect-00<https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> draft is a simple solution while still using existing and unchanged traditional technologies.

G/

From: Lucy yong
Date: Wednesday 23 September 2015 21:58
To: Gunter Van de Velde, "[email-masked]<mailto:[email-masked]>"
Subject: RE: New draft - Flowspec Path Redirect

Hi Gunter, et al,

Regards,
Lucy

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

Hi Folks,

Benefits:

G/

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 28 Sep 2015 12:30:56 -0400

Gunter: 

I’d like a bit more details on why you consider in  <https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> draft-vandevelde-idr-flowspec-path-redirect-00 a simple solution.  

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Monday, September 28, 2015 11:55 AM
To: Lucy yong; [email-masked]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

Hi Lucy,

exchange the tunnel setup parameters is non-trivial. Hence the abstraction as mentioned in  <https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> draft-vandevelde-idr-flowspec-path-redirect-00 draft is a simple solution while still using existing and unchanged traditional technologies.

G/

From: Lucy yong
Date: Wednesday 23 September 2015 21:58
To: Gunter Van de Velde, "[email-masked]"
Subject: RE: New draft - Flowspec Path Redirect

Hi Gunter, et al,

Regards,

Lucy

 

Hi Folks,

Benefits: 

Feedback welcome.

G/

---

From: Lucy yong <[email-masked]>
Date: Mon, 28 Sep 2015 17:18:43 +0000

Hi Gunter,

There are active/existing/working vendor implementations of draft-ietf-idr-flowspec-redirect-ip and some SP’s are already using this.
At the same time the a redirect-ip and a PATH_ID are totally different aspects, even though both are communities…
[Lucy] if redirect via an IP tunnel, I don’t see much difference for redirect action. BGP can validate the tunnel reachability. If the path identified by PATH_ID is implemented by different technologies and/or protocols, you are right, the aspect can be very different. However, the difference is not at redirect action itself; it is how BGP control plane can validate the path existence on the data plane and control them. If BGP can do that properly, we can apply such path for a router or a flow spec.

A tunnel is setup between head-end and tail-end… so to direct a recipient router to send interesting traffic into an engineered tunnel and at the same time
exchange the tunnel setup parameters is non-trivial.
[Lucy] This is what draft-ietf-idr-redirect-ip specified. To redirect a flow over an IP tunnel brings the benefit to keep the flow packet IP dest on the tunneled packet and carries the redirect point IP address as outer src IP, which is useful for other applications. For example, which location the flow packet is sent to and which location the flow packet is redirected at. To redirect over an IP tunnel, this draft can easily be extended to cover that.
Hence the abstraction as mentioned in draft-vandevelde-idr-flowspec-path-redirect-00<https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> draft is a simple solution while still using existing and unchanged traditional technologies.
[Lucy] As Sue pointed out, why you think that is a simple solution? Sometime, simple for one thing but complicate to another/others. Since the path may be constructed by different technology and protocols, we should first think how BGP can integrate its flow spec or a route with a path that is or will be established by other protocols. We need use case integrity inspection. For this reason, I agree with Robert, we need first specifying PATH ID semantics that is relevant to BGP.  Don’t take me wrong, IMO: this is a good idea, but we need to work out the semantics first. In term of documenting, I would prefer flow over IP tunnel to be covered by the redirect-ip draft; sure once we figure out PATH IP semantics, IP tunnel should be naturally supported by the PATH ID approach.

Thanks,
Lucy

G/

From: Lucy yong

Hi Gunter, et al,

Regards,
Lucy

Hi Folks,

Benefits:

G/