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

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 11 Feb 2014 20:38:35 +0000

Hi,

I see 2 cases:

Signaling primary/backup actions

We could control path priority using LP or MED.
Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ...

Of N path RR could select best 2 or 3 or all best path  based on preferred LP (or MED)
BGP Client could select first action, if not possible due to NH not available in RIB, then act on second ... etc...

Signaling multiple parallel actions.

I don't have answer for this one

Bertrand

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: mercredi 28 août 2013 16:52
To: Pradosh Mohapatra
Cc: [email-masked]; [email-masked]; Jeff Haas; David Smith (djsmith); [email-masked]
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

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]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>>
To: "Simpson, Adam (Adam)" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; Henderickx, Wim (Wim); [email-masked]<mailto:[email-masked]>
> Cc: Jeff Haas; [email-masked]<mailto:[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
> (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]<mailto:[email-masked]>> wrote:
>
> >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
> >
>
>

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

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

---

From: <[email-masked]>
Date: Mon, 17 Feb 2014 10:19:09 +0100

Hi,

In order to have both actions applied, why not setting twice time the extcommunity in the BGP update ? (one with C=0 and one with C=1).
Does this cause any issue ?

Applying multiple actions by setting multiple extcts seems to be authorized, so why not using the same thing here by setting twice time the same extct with different C flag. Otherwise need to split it in two different extcts.

Thoughts ?

Best Regards,

Stephane

De : Idr [mailto:[email-masked]] De la part de Bertrand Duvivier (bduvivie)
Envoyé : mardi 11 février 2014 21:39
À : Robert Raszuk; Pradosh Mohapatra
Cc : [email-masked]; [email-masked]; [email-masked]; Jeff Haas; David Smith (djsmith)
Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Hi,

I see 2 cases:

Bertrand

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: mercredi 28 août 2013 16:52
To: Pradosh Mohapatra
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jeff Haas; David Smith (djsmith); [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Hi Pradosh,

Regards,
R.

- Pradosh

Thanks,
Kaliraj

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Mon, 17 Feb 2014 21:33:59 +0000

A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines where to redirect or mirror the packets).

From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra
Cc: [email-masked]; [email-masked]; [email-masked]; David Smith (djsmith); Jeff Haas
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Hi,

Thoughts ?

Best Regards,

Stephane

Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jeff Haas; David Smith (djsmith)

Hi,

I see 2 cases:

Bertrand

Hi Pradosh,

Regards,
R.

- Pradosh

Thanks,
Kaliraj

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Feb 2014 22:45:34 +0100

Saikat,

Flowspec RFC5575 is not using next hop for it's actions. In fact BGP
NEXT_HOP is optional.

   A given flow may be associated with a set of attributes, depending on
   the particular application; such attributes may or may not include
   reachability information (i.e., NEXT_HOP)

Instead we use the RT match to determine which local VRF is used for
redirect or mirror. Stephane's proposal is wise IMO as we could list
different VRFs one for each required action. The forwarding or
encapsulation itself is defined in those redirect/mirror VRFs.

      Redirect:  The redirect extended community allows the traffic to be
      redirected to a VRF routing instance that lists the specified
      route-target in its import policy.  If several local instances
      match this criteria, the choice between them is a local matter
      (for example, the instance with the lowest Route Distinguisher
      value can be elected).  This extended community uses the same
      encoding as the Route Target extended community [RFC4360
<https://tools.ietf.org/html/rfc4360>].

Best,

R.

On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) <[email-masked]>wrote:

>  A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines
> where to redirect or mirror the packets).
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Monday, February 17, 2014 1:19 AM
> *To:* Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra
> *Cc:* [email-masked]; [email-masked]; [email-masked]; David Smith
> (djsmith); Jeff Haas
>
> *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions
>
>
>
> Hi,
>
>
>
> In order to have both actions applied, why not setting twice time the
> extcommunity in the BGP update ? (one with C=0 and one with C=1).
>
> Applying multiple actions by setting multiple extcts seems to be
> authorized, so why not using the same thing here by setting twice time the
> same extct with different C flag. Otherwise need to split it in two
> different extcts.
>
>
>
> Thoughts ?
>
>
>
>
>
> Best Regards,
>
>
>
> Stephane
>
>
>
>
>
> *De :* Idr [mailto:[email-masked] <[email-masked]>] *De la
> part de* Bertrand Duvivier (bduvivie)
> *Envoyé :* mardi 11 février 2014 21:39
> *À :* Robert Raszuk; Pradosh Mohapatra
> *Cc :* [email-masked]; [email-masked]; [email-masked]; Jeff Haas; David
> Smith (djsmith)
> *Objet :* Re: [Idr] Flowspec, coexistance of redirect and mirror actions
>
>
>
> Hi,
>
>
>
> *I see 2 cases: *
>
>
>
> *Signaling primary/backup actions*
>
>
>
> BGP Client could select first action, if not possible due to NH not
> available in RIB, then act on second ... etc...
>
>
>
> *Signaling multiple parallel actions.*
>
>
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Robert Raszuk
> *Sent:* mercredi 28 août 2013 16:52
> *To:* Pradosh Mohapatra
> *Cc:* [email-masked]; [email-masked]; Jeff Haas; David Smith (djsmith);
> [email-masked]
> *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions
>
>
>
> 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:
>
> Hi Kaliraj,
>
>
>
>    ------------------------------
>
> *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
> > From: Simpson, Adam (Adam) [mailto:[email-masked]]
> > To: Kaliraj Vairavakkalai; [email-masked]; [email-masked];
> > [email-masked]; Henderickx, Wim (Wim); [email-masked]
> > Cc: Jeff Haas; [email-masked]
> > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <[email-masked]>
> wrote:
> >
> > >Hi authors,
> > >
> [email-masked]
> [email-masked]

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Mon, 17 Feb 2014 22:02:45 +0000

I was referring to draft-simpson-idr-flowspec-redirect.

"The filter entry matches the IP packets described in
   the NLRI field and redirects them (C=0) or copies them (C=1) towards
   the IPv4 or IPv6 address specified in the 'Network Address of Next-
   Hop' field of the associated MP_REACH_NLRI."

I assumed this thread is for draft-simpson-idr-flowspec-redirect since that is what the first email in the thread refers to.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, February 17, 2014 1:46 PM
To: Saikat Ray (sairay)
Cc: [email-masked]; Bertrand Duvivier (bduvivie); Pradosh Mohapatra; [email-masked]; [email-masked]; [email-masked]; David Smith (djsmith); Jeff Haas
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Saikat,

Flowspec RFC5575 is not using next hop for it's actions. In fact BGP NEXT_HOP is optional.

Instead we use the RT match to determine which local VRF is used for redirect or mirror. Stephane's proposal is wise IMO as we could list different VRFs one for each required action. The forwarding or encapsulation itself is defined in those redirect/mirror VRFs.

      encoding as the Route Target extended community [RFC4360<https://tools.ietf.org/html/rfc4360>].

Best,

R.

On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) <[email-masked]<mailto:[email-masked]>> wrote:
A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines where to redirect or mirror the packets).

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; David Smith (djsmith); Jeff Haas

Hi,

Thoughts ?

Best Regards,

Stephane

Hi,

I see 2 cases:

Bertrand

Hi Pradosh,

Regards,
R.

- Pradosh

Thanks,
Kaliraj

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Feb 2014 18:02:14 -0500

> I assumed this thread is for draft-simpson-idr-flowspec-redirect since that is what the first email in the thread refers to.

There is a side discussion in progress toward both updating the marking
mechanism and also clarifying the case where more than one copy of the
community is present.  Based on the pace of the discussion, I suspect all
involved are having busy work months. :-)

-- Jeff

---

From: <[email-masked]>
Date: Tue, 18 Feb 2014 10:41:21 +0100

This may not be a good solution to rely on nexthop field . Something similar to VRF Redirect may be better (encode redirect IP in the community) and may permit to use multiple instance of the community.
It's important to keep FIB check to ensure reachability to the encoded IP.

De : Saikat Ray (sairay) [mailto:[email-masked]]
Envoyé : lundi 17 février 2014 23:03
À : Robert Raszuk
Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh Mohapatra; [email-masked]; [email-masked]; [email-masked]; David Smith (djsmith); Jeff Haas
Objet : RE: [Idr] Flowspec, coexistance of redirect and mirror actions

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, February 17, 2014 1:46 PM
To: Saikat Ray (sairay)
Cc: [email-masked]<mailto:[email-masked]>; Bertrand Duvivier (bduvivie); Pradosh Mohapatra; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; David Smith (djsmith); Jeff Haas
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

Saikat,

Best,

R.

Hi,

Thoughts ?

Best Regards,

Stephane

Hi,

I see 2 cases:

Bertrand

Hi Pradosh,

Regards,
R.

- Pradosh

Thanks,
Kaliraj

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Feb 2014 10:48:28 +0100

It is more then that ...

The reason Pedro and I originally chosen to go via VRF was precisely
to avoid distributing encapsulation destination(s) as well as
encapsulation types within the flow spec routes leaving it to local
(special) VRF.

Moreover some PEs may have locally attached inspection devices so it
would be impossible to universally send such redirect destination
action via p2mp protocol.

If authors of the new draft insist on the embedded redirect/mirror
destination I would highly recommend not to use the "global" next hop
from MP-REACH but to allow space to carry one within the action
instructions. That way one could use different address for different
actions.

Regards,
R.

On Tue, Feb 18, 2014 at 10:41 AM,  <[email-masked]> wrote:
> This may not be a good solution to rely on nexthop field . Something similar
> to VRF Redirect may be better (encode redirect IP in the community) and may
> permit to use multiple instance of the community.
>
> Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh
> Mohapatra; [email-masked]; [email-masked]; [email-masked]; David Smith
> (djsmith); Jeff Haas
> I assumed this thread is for draft-simpson-idr-flowspec-redirect since that
> is what the first email in the thread refers to.
>
>
>
> Cc: [email-masked]; Bertrand Duvivier (bduvivie); Pradosh
> Mohapatra; [email-masked]; [email-masked]; [email-masked]; David Smith
> (djsmith); Jeff Haas
> different VRFs one for each required action. The forwarding or encapsulation
> itself is defined in those redirect/mirror VRFs.
>
>
>
>
>       encoding as the Route Target extended community [RFC4360].
>
>
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> Applying multiple actions by setting multiple extcts seems to be authorized,
> so why not using the same thing here by setting twice time the same extct
> with different C flag. Otherwise need to split it in two different extcts.
>
>
>
> Thoughts ?
>
>
>
>
>
> Best Regards,
>
>
>
> Stephane
>
>
>
>
>
> multiple paths. This is both for the onward advertisement as well as for the
> local installation.
>
>
>
> 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.
>
>
>
> 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]>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Tue, 18 Feb 2014 21:29:51 +0000

Just to avoid any further confusion:

draft-simpson-idr-flowspec-redirect has been replaced by
draft-ietf-idr-flowspec-redirect-ip-00.

As Jeff suggested, a new version of draft-ietf-idr-flowspec-redirect-ip
will be posted imminently and in the new version the encoding of the IP
address that is the redirection target is completely contained within the
extended community of the flow-spec action. We agree that overloading the
NEXT_HOP field to carry the redirect IP address, as proposed in the 00
draft, was in retrospect not the best choice. With this change there is no
technical issue having multiple redirect extended communities in one
UPDATE, each pointing to a potentially different target address.

-Adam

On 2/18/2014, 4:48 AM, "Robert Raszuk" <[email-masked]> wrote:

>>encapsulation
>> Cc: [email-masked]; [email-masked]; [email-masked]; David Smith
>>(djsmith);
>> Jeff Haas
>>
>>
>>authorized,
>> Cc : [email-masked]; [email-masked]; [email-masked]; Jeff Haas; David
>>Smith
>> (djsmith)
>> Of N path RR could select best 2 or 3 or all best path  based on
>>preferred
>> LP (or MED)
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Robert
>> Raszuk
>>> destination A is steered/moved to new destination B while at the same
>>>time
>>> a
>>_________________________________________________________________________
>>________________________________________________
>>
>>
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou
>> falsifie. Merci.
>>
>>
>>
>> As emails may be altered, Orange is not liable for messages that have
>>been
>> modified, changed or falsified.
>>
>> Thank you.
>>
>>
>>
>> 
>>_________________________________________________________________________
>>________________________________________________
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou
>> falsifie. Merci.
>>
>> As emails may be altered, Orange is not liable for messages that have
>>been
>> modified, changed or falsified.
>> Thank you.
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Feb 2014 22:31:44 +0100

Thx Adam for this summary. Very helpful ! Also glad to see the proper
encoding shift.

Best,
R.

---

From: <[email-masked]>
Date: Thu, 20 Feb 2014 10:37:19 +0100

Great improvment ! Thanks

-----Message d'origine-----
De : Simpson, Adam (Adam) [mailto:[email-masked]] 
Envoyé : mardi 18 février 2014 22:30
À : Robert Raszuk; LITKOWSKI Stephane DTF/DERX; Saikat Ray (sairay)
Cc : [email-masked]; [email-masked]; Jeff Haas; David Smith (djsmith); [email-masked]
Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions

draft-simpson-idr-flowspec-redirect has been replaced by draft-ietf-idr-flowspec-redirect-ip-00.

As Jeff suggested, a new version of draft-ietf-idr-flowspec-redirect-ip
will be posted imminently and in the new version the encoding of the IP address that is the redirection target is completely contained within the extended community of the flow-spec action. We agree that overloading the NEXT_HOP field to carry the redirect IP address, as proposed in the 00 draft, was in retrospect not the best choice. With this change there is no technical issue having multiple redirect extended communities in one UPDATE, each pointing to a potentially different target address.

-Adam

On 2/18/2014, 4:48 AM, "Robert Raszuk" <[email-masked]> wrote:

>It is more then that ...
>
>The reason Pedro and I originally chosen to go via VRF was precisely to 
>avoid distributing encapsulation destination(s) as well as 
>> This may not be a good solution to rely on nexthop field . Something 
>>similar  to VRF Redirect may be better (encode redirect IP in the 
>>community) and may  permit to use multiple instance of the community.
>>
>> De : Saikat Ray (sairay) [mailto:[email-masked]] Envoyé : lundi 17 
>> février 2014 23:03 À : Robert Raszuk Cc : LITKOWSKI Stephane 
>> DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh Mohapatra; 
>> [email-masked]; [email-masked]; [email-masked]; David Smith 
>> (djsmith); Jeff Haas Objet : RE: [Idr] Flowspec, coexistance of 
>> redirect and mirror actions
>>
>>
>>
>> I assumed this thread is for draft-simpson-idr-flowspec-redirect 
>>since that  is what the first email in the thread refers to.
>>
>>
>>
>> Cc: [email-masked]; Bertrand Duvivier (bduvivie); 
>> Pradosh Mohapatra; [email-masked]; [email-masked]; [email-masked]; 
>> David Smith (djsmith); Jeff Haas
>> On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) 
>> <[email-masked]>
>> wrote:
>>
>> A given update (a BGP path) has only one NEXTHOP (the NEXTHOP 
>> determines where to redirect or mirror the packets).
>>
>>
>>
>>authorized,  so why not using the same thing here by setting twice 
>>time the same extct  with different C flag. Otherwise need to split it 
>>in two different extcts.
>>
>>
>>
>> Thoughts ?
>>
>>
>>
>>
>>
>> Best Regards,
>>
>>
>>
>> Stephane
>>
>>
>>
>>
>>
>> De : Idr [mailto:[email-masked]] De la part de Bertrand 
>>Duvivier
>> (bduvivie)
>> Cc : [email-masked]; [email-masked]; [email-masked]; Jeff Haas; 
>>David Smith
>> (djsmith)
>>preferred  LP (or MED)
>>Robert  Raszuk
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <[email-masked]>; "[email-masked]" <[email-masked]>; 
>>"Henderickx,  Wim (Wim)" <[email-masked]>; 
>>"[email-masked]"
>> <[email-masked]>
>> 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)
>>
>> capability, load-balancing requirement etc), was the thought behind 
>>my  question.
>>
>> Thanks,
>> 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
>>>
>>>
>>> >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
>>> >
>>>
>>>
>>
>>
>>______________________________________________________________________
>>___ ________________________________________________
>>
>>
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>avez recu  ce message par erreur, veuillez le signaler
>>
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
>> messages electroniques etant susceptibles d'alteration,
>>
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law;
>>
>> If you have received this email in error, please notify the sender 
>> and delete this message and its attachments.
>>
>>been  modified, changed or falsified.
>>
>> Thank you.
>>
>>
>>
>> 
>>______________________________________________________________________
>>___ ________________________________________________
>>
>>confidentielles ou privilegiees et ne doivent donc  pas etre diffuses, 
>>exploites ou copies sans autorisation. Si vous avez recu  ce message 
>>par erreur, veuillez le signaler  a l'expediteur et le detruire ainsi 
>>que les pieces jointes. Les messages  electroniques etant susceptibles 
>>d'alteration,  Orange decline toute responsabilite si ce message a ete 
>>altere, deforme ou  falsifie. Merci.
>>
>> This message and its attachments may contain confidential or 
>>privileged  information that may be protected by law;  they should not 
>>be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender 
>>and  delete this message and its attachments.
>>been  modified, changed or falsified.
>> Thank you.
>