Subject: Re: [Idr] New draft - Flowspec Path Redirect

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 14:51:08 -0400

On Mon, Sep 28, 2015 at 05:18:43PM +0000, Lucy yong wrote:
> 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.

This is also one of my two major concerns about this draft.  The path-id is
not only completely arbitrary in the current draft, but also opaque.  This
leads to issues with validation, but it also leads to the question about
synchronization or coordination of path-ids at various routers in the AS.

Are there requirements to synchronize the path-ids?
Are the path-ids intended to have "anycast" type properties?

The second rather large issue is something I'll go into more detail in my
response for draft-eddy-idr-flowspec-exp:  The authors of the redirect-ip
draft ran into issues fairly early on with regard to the coordination of
multiple redirect capabilities for a flowspec route.  You can get a sense of
some of the complexity by examining the rules in that draft.

Any new drafts covering traffic redirection *MUST* document how they operate
with regard to other redirection mechanisms.  This is required not only for
interoperability, but also to be clear about the precedence of forwarding
behaviors when multiple such behaviors are present.

One question I have is whether this behavior is being sought because there
is the impression that arbitrary tunneling is not currently possible.  It's
generally understood in the redirect-ip document that the referenced address
may be at the end of a tunnel.  That tunnel is intended to be discovered by
the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.
If this mechanism isn't seen to be quite sufficient, perhaps utilizing an
additional flag bit in the Reserved field may help with some additional
semantics?

-- Jeff

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Oct 2015 20:33:01 +0000

Let's get a closer look for 'redirect to tunnel'. IMO: two useful use cases: 1) redirect the flow-spec to a tunnel where the remote tunnel endpoint is different from the BGP next hop of the flow-spec update. This is the case similar to RFC5575 and draft of redirect to IP (but they both are not allowed over a tunnel) 2) redirect traffic to the tunnel where the remote tunnel endpoint is the BGP next hop of the flow-spec update; this is the case for TE and allows BGP flow-spec to be carried by a tunnel that is built by other control protocols such as RSVP-TE, LDP, PCEP, GMPLS. 

To me, the first case is too danger to allow flow-spec via a tunnel to be built by other control protocol (very hard to validate such tunnel), but it is OK for the first case to be carried by a tunnel specified by BGP. For the second case, such tunnel can be built by BGP and non-BGP protocols. To do that, it is necessary to have some interworking (API) between BGP and RSVP-TE (as example) components on a router that support both.

If BGP next hop node can confirm the LSPs built by RSVP-TE to the node, it can advertise the flow-spec to be carried by the LSPs to it. If BGP speaker node supports RSVP-TE and has the LSP to the BGP next hop, it can validate the LSP via the API on the node and get the tunnel's encap info from the API; in data plane, the flow-spec packets can be forwarded to the tunnel accordingly. 

Today, BGP configured VPNs are manually configured to the LSP between PEs. If BGP can interwork with other control (signaling) protocols at the node, it can bind the flow-spec or route with a tunnel that is built by other protocols. IMO: this is very useful capability for automation and traffic engineering. 

The question is should we have one solution to cover both tunnel redirect cases, and one solution to cover BGP specified tunnel and non-BGP built tunnel (i.e. other control protocols). It would be awesome if operators help to validate use cases, which will greatly help on the solution development. 

Jeff- "That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.
If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in the Reserved field may help with some additional semantics?"

BGP has not yet to interwork with a signal control protocol although it interworks with IGP protocol. Yes, it is necessary to have a proper protocol to work with control protocols, but avoid a protocol for each control protocol.

Lucy

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Monday, October 05, 2015 1:51 PM
To: Lucy yong
Cc: VAN DE VELDE, Gunter (Gunter); [email-masked]
Subject: Re: [Idr] New draft - Flowspec Path Redirect

On Mon, Sep 28, 2015 at 05:18:43PM +0000, Lucy yong wrote:
> 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.

This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question about synchronization or coordination of path-ids at various routers in the AS.

The second rather large issue is something I'll go into more detail in my response for draft-eddy-idr-flowspec-exp:  The authors of the redirect-ip draft ran into issues fairly early on with regard to the coordination of multiple redirect capabilities for a flowspec route.  You can get a sense of some of the complexity by examining the rules in that draft.

Any new drafts covering traffic redirection *MUST* document how they operate with regard to other redirection mechanisms.  This is required not only for interoperability, but also to be clear about the precedence of forwarding behaviors when multiple such behaviors are present.

One question I have is whether this behavior is being sought because there is the impression that arbitrary tunneling is not currently possible.  It's generally understood in the redirect-ip document that the referenced address may be at the end of a tunnel.  That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.
If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in the Reserved field may help with some additional semantics?

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Oct 2015 07:25:47 -0400

Gunter: 

I am responding to the beginning of this thread to indicate my review of the mail thread from until 10/8. 

General comment: 

·         Extended community is a redirect ‘path-id’ (128bit/32 bit)  which is similar to the draft-hao-idr-flowspec-redirect-tunnel-00.txt. 

·         Your draft assumes as localized path-id indexed table.  Draft-hao-idr-flowspec-redirct-tunnel-00.txt assumes an extensions to the BGP Tunnel Encapsulation Attribute that points to a tunnel.  

·         Your extended community TID + C (Copy) bit.   The draft-hao-idr-flowspec-redirect-tunnel-00.txt contains “C (Copy) bit. 

·         Your TID states – “to provide the router consuming the flowspec rule an indication of how and where to use the path-id when redirectin traffic”.  No further details are provided for this field so it is difficult to understand it. 

As far as I can tell you have not answered the following questions: 

·         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 ? (Robert Razuk)?

o   [Lucy] 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.  

o   [Jeff]: This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question about synchronization or coordination of path-ids at various routers in the AS.

o   pHeff

·         [Jeff/Lucy’s comment]:  How Path-id and redirect ID are totally different aspects? 

o   [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.

o   [Lucy] 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.  

o   [Jeff]: This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question about synchronization or coordination of path-ids at various routers in the AS.

§  Are there requirements to synchronize the path-ids?

§  Are the path-ids intended to have "anycast" type properties?

§  [Jeff] Any new drafts covering traffic redirection *MUST* document how they operate with regard to other redirection mechanisms.  This is required not only for interoperability, but also to be clear about the precedence of forwarding behaviors when multiple such behaviors are present.

o   [Jeff] One question I have is whether this behavior is being sought because there is the impression that arbitrary tunneling is not currently possible.  It's generally understood in the redirect-ip document that the referenced address may be at the end of a tunnel.  That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.  If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in the Reserved field may help with some additional semantics?

·         Set-up of tunnel

o   Gunter: 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.

o   [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.

·         Why you consider this draft to be “simple” [Sue Hares] 

It would be good to plan to cover this information for interim (if you present), and at IETF. We will be scheduling the flowspec and path drafts during the same time period.  

Sue Hares 

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

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: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Mon, 19 Oct 2015 19:15:13 +0000

<>snip<>
<>/snip<>

GV> Yes, many thanks for this opportunity to discuss the redirect-to-Path at both the interim (for people that can not attend IETF94) and the IETF94 IDR meeting.

Brgds,
G/

From:  Susan Hares <[email-masked]>
Date:  Tuesday 13 October 2015 at 13:25
To:  Gunter Van de Velde <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:  "'Keyur Patel (keyupate)'" <[email-masked]>
Subject:  RE: [Idr] New draft - Flowspec Path Redirect

Gunter:

General comment:

·        
Extended community is a redirect ‘path-id’ (128bit/32 bit)  which is similar to the draft-hao-idr-flowspec-redirect-tunnel-00.txt.

·        
Your draft assumes as localized path-id indexed table.  Draft-hao-idr-flowspec-redirct-tunnel-00.txt assumes an extensions to the BGP Tunnel Encapsulation
 Attribute that points to a tunnel.  
·        
Your extended community TID + C (Copy) bit.   The draft-hao-idr-flowspec-redirect-tunnel-00.txt contains “C (Copy) bit.

·        
Your TID states – “to provide the router consuming the flowspec rule an indication of how and where to use the path-id when redirectin traffic”. 
 No further details are provided for this field so it is difficult to understand it.

·        
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 ? (Robert Razuk)?
o  
[Lucy] 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.  
o  
[Jeff]: This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question
 about synchronization or coordination of path-ids at various routers in the AS.
o  
pHeff
·        
[Jeff/Lucy’s comment]:  How Path-id and redirect ID are totally different aspects?

o  
[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.
o  
[Lucy] 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.  
o  
[Jeff]: This is also one of my two major concerns about this draft.  The path-id is not only completely arbitrary in the current draft, but also opaque.  This leads to issues with validation, but it also leads to the question
 about synchronization or coordination of path-ids at various routers in the AS.
§ 
Are there requirements to synchronize the path-ids?
§ 
Are the path-ids intended to have "anycast" type properties?
§ 
[Jeff] Any new drafts covering traffic redirection *MUST* document how they operate with regard to other redirection mechanisms.  This is required not only for interoperability, but also to be clear about the precedence of forwarding
 behaviors when multiple such behaviors are present.
o  
[Jeff] One question I have is whether this behavior is being sought because there is the impression that arbitrary tunneling is not currently possible.  It's generally understood in the redirect-ip document that the referenced
 address may be at the end of a tunnel.  That tunnel is intended to be discovered by the BGP speaker in a fashion similar to resolving L3VPN nexthop addresses.  If this mechanism isn't seen to be quite sufficient, perhaps utilizing an additional flag bit in
 the Reserved field may help with some additional semantics?
 
·        
Set-up of tunnel
o  
Gunter: 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.
o  
[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.
·        
Why you consider this draft to be “simple” [Sue Hares]

It would be good to plan to cover this information for interim (if you present), and at IETF. We will
 be scheduling the flowspec and path drafts during the same time period.  
Sue Hares

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

Hi Folks,

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: 

Feedback welcome.

G/