Simpson, Adam (Adam | 26 Jul 2012 18:19
Favicon

FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

This individual submission was posted last week and will be presented at the IDR meeting next week. Any
feedback you have before or after the meeting would be welcome.

Thanks,
Adam

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, July 16, 2012 10:33 AM
To: Simpson, Adam (Adam)
Cc: mtexier <at> arbor.net; pmohapat <at> cisco.com; djsmith <at> cisco.com; Henderickx, Wim (Wim)
Subject: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

A new version of I-D, draft-simpson-idr-flowspec-redirect-01.txt
has been successfully submitted by Adam Simpson and posted to the
IETF repository.

Filename:	 draft-simpson-idr-flowspec-redirect
Revision:	 01
Title:		 BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-simpson-idr-flowspec-redirect-01.txt
Status:          http://datatracker.ietf.org/doc/draft-simpson-idr-flowspec-redirect
Htmlized:        http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-simpson-idr-flowspec-redirect-01

Abstract:
   Flow-spec is an extension to BGP that allows for the dissemination of
(Continue reading)

Robert Raszuk | 26 Jul 2012 18:40

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Hi Adam,

While we are at such extension how about we would also define in this 
document one more extended community value which would allow in addition 
to "redirect-to-ip", also "mirror-to-ip" action ?

Of course both would be mutually exclusive.

Thx,
R.

> This individual submission was posted last week and will be presented at the IDR meeting next week. Any
feedback you have before or after the meeting would be welcome.
>
> Thanks,
> Adam

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Robert Raszuk | 26 Jul 2012 19:15

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Let me expand a bit ....

Actually the original "redirect-to-vrf" flowspec action also addressed 
the issue of forwarding via flow-spec unaware core via any form of 
tunneling enabled under given vrf instance.

Since here the default would be to relay on global forwarding table of 
the router the same flow spec rules must be understood and executed hop 
by hop.

In order to simplify deployment aspect it seems recommended to also 
within each of the community define few bits to indicate optional 
encapsulation of redirected or mirror flows.

0000 - native
0001 - NH is GRE tunnel destination
0002 - NH is L2TPv3 tunnel destination
etc ...

Best regards,
R.

> Hi Adam,
>
> While we are at such extension how about we would also define in this
> document one more extended community value which would allow in addition
> to "redirect-to-ip", also "mirror-to-ip" action ?
>
> Of course both would be mutually exclusive.
>
(Continue reading)

Henderickx, Wim (Wim | 26 Jul 2012 19:39
Favicon

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Robert, why do you want to do this explicitly and not implicitly? We are assuming the tunnels can be of any
kind and the NH resolves to whatever the routing protocols have given us. Meaning if the NH is resolved to
native or GRE or L2TPv3 we don't care.
Do you see a reason to constraint this?

-----Original Message-----
From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of Robert Raszuk
Sent: donderdag 26 juli 2012 19:16
To: Simpson, Adam (Adam)
Cc: idr <at> ietf.org
Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Let me expand a bit ....

Actually the original "redirect-to-vrf" flowspec action also addressed 
the issue of forwarding via flow-spec unaware core via any form of 
tunneling enabled under given vrf instance.

Since here the default would be to relay on global forwarding table of 
the router the same flow spec rules must be understood and executed hop 
by hop.

In order to simplify deployment aspect it seems recommended to also 
within each of the community define few bits to indicate optional 
encapsulation of redirected or mirror flows.

0000 - native
0001 - NH is GRE tunnel destination
0002 - NH is L2TPv3 tunnel destination
etc ...
(Continue reading)

Robert Raszuk | 26 Jul 2012 20:01

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Hi Wim,

Actually I do. Routing protocols do not provide the encapsulation
destination today. So you would need to configure it as recursive static
route on each ingress router. Today you are always (for example in BGP) 
signalling your encap endpoint explicitly.

If we signal it within the flow-spec SAFI there is much less overhead 
and much less room for operational mistakes.

Also when we use the NH as tunnel-to address there should be no next hop
self on the flowspec route at the EBGP boundary.

Regards,
R.

> Robert, why do you want to do this explicitly and not implicitly? We
> are assuming the tunnels can be of any kind and the NH resolves to
> whatever the routing protocols have given us. Meaning if the NH is
> resolved to native or GRE or L2TPv3 we don't care. Do you see a
> reason to constraint this?
>
> -----Original Message----- From: idr-bounces <at> ietf.org
> [mailto:idr-bounces <at> ietf.org] On Behalf Of Robert Raszuk Sent:
> donderdag 26 juli 2012 19:16 To: Simpson, Adam (Adam) Cc:
> idr <at> ietf.org Subject: Re: [Idr] FW: New Version Notification for
> draft-simpson-idr-flowspec-redirect-01.txt
>
> Let me expand a bit ....
>
(Continue reading)

Henderickx, Wim (Wim | 26 Jul 2012 20:39
Favicon

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Clear, you want a 1 step process rather than an additional indirection with additional config/routing exchange.

-----Original Message-----
From: Robert Raszuk [mailto:robert <at> raszuk.net] 
Sent: donderdag 26 juli 2012 20:02
To: Henderickx, Wim (Wim)
Cc: Simpson, Adam (Adam); idr <at> ietf.org
Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Hi Wim,

Actually I do. Routing protocols do not provide the encapsulation
destination today. So you would need to configure it as recursive static
route on each ingress router. Today you are always (for example in BGP) 
signalling your encap endpoint explicitly.

If we signal it within the flow-spec SAFI there is much less overhead 
and much less room for operational mistakes.

Also when we use the NH as tunnel-to address there should be no next hop
self on the flowspec route at the EBGP boundary.

Regards,
R.

> Robert, why do you want to do this explicitly and not implicitly? We
> are assuming the tunnels can be of any kind and the NH resolves to
> whatever the routing protocols have given us. Meaning if the NH is
> resolved to native or GRE or L2TPv3 we don't care. Do you see a
> reason to constraint this?
(Continue reading)

Shyam Sethuram (shsethur | 16 Aug 2012 08:51
Picon
Favicon

Re: FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Adam,
One clarification - I guess, a nit:

Towards the end of Sec 3, you mention:
  "This means that a flow-spec route with a
   destination prefix subcomponent SHOULD NOT be accepted from an EBGP
   peer unless that peer also advertised the best path for the matching
   unicast route."

It should instead say something to the effect of "... such a flow-spec
route should not be selected as best-path / installed as a filtering rule".
We can certainly accept those flow-spec routes from peer ?

thanks--shyam

>-----Original Message-----
>From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of Simpson, Adam
>(Adam)
>Sent: Thursday, July 26, 2012 9:20 AM
>To: idr <at> ietf.org
>Subject: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt
>
>This individual submission was posted last week and will be presented at the IDR meeting
>next week. Any feedback you have before or after the meeting would be welcome.
>
>Thanks,
>Adam
>
>
>-----Original Message-----
(Continue reading)


Gmane