Subject: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Thu, 26 Jul 2012 11:19:33 -0500

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 16, 2012 10:33 AM
To: Simpson, Adam (Adam)
Cc: [email-masked]; [email-masked]; [email-masked]; 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
   traffic flow specification rules. This has many possible applications
   but the primary one for many network operators is the distribution of
   traffic filtering actions for DDoS mitigation. The flow-spec standard
   [RFC 5575] defines a redirect-to-VRF action for policy-based
   forwarding but this mechanism can be difficult to use, particularly
   in networks without L3 VPNs.

   This draft proposes a new redirect-to-IP flow-spec action that
   provides a simpler method of policy-based forwarding. This action is
   indicated by the presence of a new BGP extended community in the
   flow-spec route. Many routers already support a redirect-to-IP filter
   action and, in this case, the only new functionality implied by this
   draft is the ability to signal the action using flow-spec.

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Jul 2012 18:40:19 +0200

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.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Jul 2012 19:15:33 +0200

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.

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

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 26 Jul 2012 19:39:01 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: donderdag 26 juli 2012 19:16
To: Simpson, Adam (Adam)
Cc: [email-masked]
Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt

Let me expand a bit ....

0000 - native

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Jul 2012 20:01:31 +0200

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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Robert Raszuk Sent:
> donderdag 26 juli 2012 19:16 To: Simpson, Adam (Adam) Cc:
> [email-masked] 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.
>
> 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 ?
>>
>> 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
>> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>>
>>
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 26 Jul 2012 20:39:11 +0200

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

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

Hi Wim,

Regards,
R.