Subject: [Idr] Flowspec, coexistance of redirect and mirror actions

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Sun, 25 Aug 2013 05:13:52 +0000

Hi authors, 

Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02

If it is desired to perform both "redirect-action" to a nexthop X, and "mirror-action" to a different nexthop Y simultaneously for the same flow, how is it achieved? 

It appears the signaling for such a scenario may not be handled by the mechanisms specified in this draft, unless I am missing something. Could you pls clarify. 

Thanks
Kaliraj

---

From: Dave Mitchell <[email-masked]>
Date: Sat, 24 Aug 2013 23:35:55 -0700

Hello,
  I think the above to options (port mirroring vs NH change) are completely
different and should be used in different terms based on the actions
required within the PFE. Since port-mirroring can sometimes need tunneling
due to an indirect next-hop, using a single community to do both
seems less than ideal, nor something operators would use very often. (just
my $0.02)

I most definitely agree that there needs to be a "then next-hop" option in
flow-spec and a "match community", considering these
exist in normal BGP NLRI policy statement. I'd also like to see the ability
to take multiple prefixes (prefix-list) in a single statement and have them
distributed in the FIB accordingly, as opposed to the single src/dest match
options, per flow-route, that currently exist. I also think the
inflexibility of
differing prefix-length matching between src/dst in flow-spec should be
investigated. I've had to work around this issue for years and it's not
ideal.

Community example for changing next-hop in flow-spec for a particular dest:

route MODIFY_NH_FOO {
    match {
        community $foobar;
    }
    then {
        next-hop NH_SLASH_32;
        accept;
    }
}

Example of prefix list (src and dst) option that I feel would be useful for
flow-spec in general. If for instance you are trying to deal with nasty
source traffic to multiple datacenters on a backbone, the below route
currently has to be $x numbers of datacenters as the dest, potentially
bloating the RIB when in all reality, one statement should be able to be
disseminated into the FIB correctly.

route FS_PREFIX_LIST_FOO {
    match {
        source-prefix-list $foo;
        dest-prefix-list $bar;
        community $foobar;
    }
    then {
        next-hop NH_SLASH_32;
        accept;
    }
}

Thanks!

On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai <[email-masked]
> wrote:

> If it is desired to perform both "redirect-action" to a nexthop X, and
> "mirror-action" to a different nexthop Y simultaneously for the same flow,
> how is it achieved?
>
> It appears the signaling for such a scenario may not be handled by the
> mechanisms specified in this draft, unless I am missing something. Could
> you pls clarify.
>
> Thanks
> Kaliraj
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Dave Mitchell <[email-masked]>
Date: Sat, 24 Aug 2013 23:31:55 -0700

Hello,
seems less than ideal nor something operators would use often. (just my
$0.02)

I most definitely agree there needs to be a "then next-hop" option in
flow-spec and a "match community" to make things easier, considering these
exist in normal BGP NLRI policy statement. I'd also like to see the ability
to take multiple prefixes (prefix-list) in a single statement and have them
distributed in the FIB accordingly, as opposed to the single src/dest match
options, per flow-route, that currently exist. I also think the
inflexibility of
differing prefix-length matching between src/dst in flow-spec should be
investigated. I've had to work around this issue for years and it's not
ideal.

route MODIFY_NH_FOO {
    match {
        community $foobar;
    }
    then {
        next-hop NH_SLASH_32;
        accept;
    }
}

Thanks!

-dave

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Tue, 27 Aug 2013 17:18:30 +0000

Hi Kaliraj,

You are correct; these actions are mutually exclusive according to the
current encoding. What does it mean for you to have a flow both moved
(redirected) and copied (mirrored)? Do you mean the original flow with
destination A is steered/moved to new destination B while at the same time
a copy of this flow is sent to a new destination C? I personally have not
seen a requirement for this type of compound action but I will leave the
other authors to comment as well.

-Adam

On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <[email-masked]> wrote:

>"mirror-action" to a different nexthop Y simultaneously for the same
>flow, how is it achieved?
>

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Tue, 27 Aug 2013 17:55:25 +0000

Yes Adam, the original flow with destination A is steered/moved to new destination B (e.g. scrubber device) while simultaneously copy of this flow sent to a new destination C (e.g. for LI) 

The devices doing the scrubbing and LI may be different (based on devices' capability, load-balancing requirement etc), was the thought behind my question. 

Thanks, 
Kaliraj 
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:[email-masked]]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; [email-masked]; [email-masked];
> [email-masked]; Henderickx, Wim (Wim); [email-masked]
> Cc: Jeff Haas; [email-masked]
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
> 
> Hi Kaliraj,
> 
> You are correct; these actions are mutually exclusive according to the current
> encoding. What does it mean for you to have a flow both moved
> destination A is steered/moved to new destination B while at the same time a
> copy of this flow is sent to a new destination C? I personally have not seen a
> requirement for this type of compound action but I will leave the other
> authors to comment as well.
> 
> -Adam
> 
> 
> >mechanisms specified in this draft, unless I am missing something.
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
> 
>

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 27 Aug 2013 14:37:25 -0700 (PDT)

Hi Kaliraj,

Suggest you use add-path: send two paths for the flow, one with next-hop X 
and redirect action, the other with next-hop Y and mirror action.

- Pradosh

________________________________
 From: Kaliraj Vairavakkalai <[email-masked]>
To: "Simpson, Adam (Adam)" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "Henderickx, Wim (Wim)" <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: Jeff Haas <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, August 27, 2013 10:55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Thanks, 
Kaliraj

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Aug 2013 16:52:14 +0200

Hi Pradosh,

5575 still requires you to run BGP best path selection even if you have
multiple paths. This is both for the onward advertisement as well as for
the local installation.

You are proposing to install more then "best" path locally which may
actually require substantial changes to the BGP operation.

How do you control which paths are to be installed let's say which 2 out of
N ? The multipath checks are not really helpful here.

It's an interesting question if we in general agree to install multiple
paths in flowspec SAFI for the exact same NLRI ?

Regards,
R.

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra <[email-masked]>wrote:

>   ------------------------------
>  *From:* Kaliraj Vairavakkalai <[email-masked]>
> *To:* "Simpson, Adam (Adam)" <[email-masked]>; "
> [email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>;
> "[email-masked]" <[email-masked]>; "Henderickx, Wim (Wim)" <
> [email-masked]>; "[email-masked]" <[email-masked]>
>
> *Cc:* Jeff Haas <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, August 27, 2013 10:55 AM
> *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions
>
> Yes Adam, the original flow with destination A is steered/moved to new
> destination B (e.g. scrubber device) while simultaneously copy of this flow
> sent to a new destination C (e.g. for LI)
>
> The devices doing the scrubbing and LI may be different (based on devices'
> capability, load-balancing requirement etc), was the thought behind my
> question.
>
> Thanks,
> Kaliraj
> current

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Tue, 27 Aug 2013 07:23:22 +0000

Hi Dave, 

Thanks for sharing experience from the field, and confirming that mirroring and redirect to different NHs can be used simultaneously. Let's wait for the authors' input.

Btw, I think as-per this draft both redirect and mirroring options can use a tunneled-nexthop. 

I don't fully understand/agree your flow-route community-matching requirement, are you suggesting this as a new flowspec-NLRI-format or just a local-syntactic-sugar?

The prefix-list suggestion is a good syntactic-sugar, but it may not alter the size of flowspec-RIB/num-filters. Perhaps we can take discussion of these points offline, if you agree that these are implementation matter and not standards-related.

Thanks
Kaliraj 
======================================================
From: Dave Mitchell [mailto:[email-masked]] 
Sent: Saturday, August 24, 2013 11:32 PM
To: Kaliraj Vairavakkalai
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Jeff Haas; [email-masked]; Danny McPherson
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Hello,
  I think the above to options (port mirroring vs NH change) are completely different and should be used in different terms based on the actions 
required within the PFE. Since port-mirroring can sometimes need tunneling due to an indirect next-hop, using a single community to do both 
seems less than ideal nor something operators would use often. (just my $0.02)

I most definitely agree there needs to be a "then next-hop" option in flow-spec and a "match community" to make things easier, considering these 
exist in normal BGP NLRI policy statement. I'd also like to see the ability to take multiple prefixes (prefix-list) in a single statement and have them 
distributed in the FIB accordingly, as opposed to the single src/dest match options, per flow-route, that currently exist. I also think the inflexibility of
differing prefix-length matching between src/dst in flow-spec should be investigated. I've had to work around this issue for years and it's not ideal. 

route MODIFY_NH_FOO {
    match {
        community $foobar;
    }
    then {
        next-hop NH_SLASH_32;
        accept;
    }
}
 
Example of prefix list (src and dst) option that I feel would be useful for flow-spec in general. If for instance you are trying to deal with nasty
source traffic to multiple datacenters on a backbone, the below route currently has to be $x numbers of datacenters as the dest, potentially
bloating the RIB when in all reality, one statement should be able to be disseminated into the FIB correctly. 

-dave

On Sat, Aug 24, 2013 at 10:13 PM, Kaliraj Vairavakkalai <[email-masked]> wrote:
Hi authors,

Thanks
Kaliraj