Subject: Re: [Idr] FW: WGLC for draft-ietf-idr-bgp-flowspec-oid-06

From: Pradosh Mohapatra <[email-masked]>
Date: Sun, 6 May 2018 00:38:11 +0000 (UTC)

+1. I am not aware of any IPR related to this draft.
- Pradosh 

    On Friday, April 27, 2018, 10:29:23 AM PDT, Juan Alcaide (jalcaide) <[email-masked]> wrote:  
 
   I am unaware of any undisclosed IPR that applies to this draft.
 
 -J
 
 On 4/27/2018 6:42 PM, Clarence Filsfils (cfilsfil) wrote:
  
John, 
 
 I am unaware of any undisclosed IPR that applies to this draft. 
 
 Cheers, 
 Clarence

---

From: John Scudder <[email-masked]>
Date: Thu, 10 May 2018 18:28:20 +0000

Hi All,

On Apr 26, 2018, at 3:58 PM, John Scudder <[email-masked]<mailto:[email-masked]>> wrote:

The authors have requested a working group last call for draft-ietf-idr-bgp-flowspec-oid-06. Please respond with your comments before Friday, May 11.

A quick update on the status of this WGLC:

- All the authors have responded about IPR (thank you!).
- Three people who are not authors (Acee, Shyam, Keyur) have responded supporting publication.
- Nobody has responded with other comments or opposition.

Three respondents is not a very large number; it would be helpful if others would chime in.

The WGLC period is scheduled to end tomorrow.

Thanks,

--John

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 10 May 2018 18:57:38 +0000

This supports some of the bi-lateral, ddos-peering work we want to do, so support.

https://pc.nanog.org/static/published/meetings/NANOG71/1447/20171003_Levy_Operationalizing_Isp_v2.pdf

That is almost always going to be between some set of systems not one hop away, not directly in the forwarding plane, probably not really IBGP peers.

" It thus becomes necessary to modify step (a) of the RFC 5575<https://tools.ietf.org/html/rfc5575>
   validation procedure such that an IBGP peer that is not within the
   data forwarding plane may originate flow specification NLRIs."

While you could have the IBGP peer directly in the forwarding plane, forward it like a route reflector, requiring it to seems counter intuitive as it is more likely to come from some BGP speaking tool in ISP requesting the filter.

Next lots of references to IBGP and a few to EBGP, when I think of IBGP, IBGP is internal to a single AS (yes I know there are exceptions) but that is kind of the meaning, while this is mostly between peers (whom could do IBGP between them but is that required? Can't we validate without IBGP direct connections?)

Metric System < +000 > -000
Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
[email-masked]<mailto:[email-masked]>
________________________________
From: Idr [[email-masked]] on behalf of John Scudder [[email-masked]]
Sent: Thursday, May 10, 2018 12:28 PM
To: idr@ietf. org
Cc: [email-masked]
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Hi All,

Thanks,

--John
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 11 May 2018 05:39:30 +0000

I support the draft.

Donald, are you saying that AS1 should accept a flowspec rule from AS2 for traffic going to AS3?
If AS1 can trust the flowspec from AS2, then I don't see why not.
Maybe we can add text to the effect of:
The rules stated here are for default behavior.
Local policy may allow flow specifications from other EBGP neighbors to be accepted.

Thanks,
Jakob

From: Idr <[email-masked]> On Behalf Of Smith, Donald
Sent: Thursday, May 10, 2018 11:58 AM
To: John Scudder <[email-masked]>; idr@ietf. org <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Cc: [email-masked]<mailto:[email-masked]>

Thanks,

--John

---

From: "Kasavchenko, Kirill" <[email-masked]>
Date: Fri, 11 May 2018 11:30:30 +0000

I support the draft. In all FlowSpec deployments I have worked on validation had to be turned off, so this draft addresses the very real issue.

Thanks,
Kirill

From: Idr <[email-masked]> on behalf of John Scudder <[email-masked]>
Date: Thursday, 10. May 2018 at 13:28
To: "idr@ietf. org" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

[EXTERNAL EMAIL]
Hi All,

Thanks,

--John

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 May 2018 14:50:17 +0000

That would work of course MAY would be caps :) But that should cover the case I was describing.

All the other BGP security issues would still apply.

Cc'ing the two architects that have been working on this concept with me, in case they have anything to add.

Metric System < +000 > -000
Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
[email-masked]<mailto:[email-masked]>
________________________________
From: Jakob Heitz (jheitz) [[email-masked]]
Sent: Thursday, May 10, 2018 11:39 PM
To: Smith, Donald; John Scudder; idr@ietf. org
Cc: [email-masked]
Subject: RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

I support the draft.

Thanks,
Jakob

Thanks,

--John

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 11 May 2018 20:57:48 +0200

Don,

(just to be clear, this has nothing to directly with the redirect 
extended-community draft)

We already thought about it and added a 'clause' in the last revision.

"Optionally, an implementation
    could be configured to allow only flow specification NLRIs containing
    only a subset of ASes.  This could be useful, for example, with
    networks that consist of multiple ASes that operate under the same
    administrative domain."

This is not what you want?

-J

On 5/11/2018 4:50 PM, Smith, Donald wrote:
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> *From:* Jakob Heitz (jheitz) [[email-masked]]
> *Sent:* Thursday, May 10, 2018 11:39 PM
> *To:* Smith, Donald; John Scudder; idr@ietf. org
> *Cc:* [email-masked]
> *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
> I support the draft.
>
> *From:*Idr <[email-masked]> *On Behalf Of *Smith, Donald
> *Sent:* Thursday, May 10, 2018 11:58 AM
> *To:* John Scudder <[email-masked]>; idr@ietf. org <idr@ietf..org>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
> That is almost always going to be between some set of systems not one 
> hop away, not directly in the forwarding plane, probably not really 
> IBGP peers.
>
> While you could have the IBGP peer directly in the forwarding plane, 
> forward it like a route reflector, requiring it to seems counter 
> intuitive as it is more likely to come from some BGP speaking tool in 
> ISP requesting the filter.
>
> Next lots of references to IBGP and a few to EBGP, when I think of 
> IBGP, IBGP is internal to a single AS (yes I know there are 
> exceptions) but that is kind of the meaning, while this is mostly 
> between peers (whom could do IBGP between them but is that required? 
> Can't we validate without IBGP direct connections?)
>
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>
> *From:*Idr [[email-masked]] on behalf of John Scudder 
> [[email-masked]]
> *Sent:* Thursday, May 10, 2018 12:28 PM
> *To:* idr@ietf. org
> *Cc:* [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
> Hi All,
>
>     The authors have requested a working group last call for
>     draft-ietf-idr-bgp-flowspec-oid-06. Please respond with your
>     comments before Friday, May 11.
>
> This communication is the property of CenturyLink and may contain 
> confidential or privileged information. Unauthorized use of this 
> communication is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please immediately notify the 
> sender by reply e-mail and destroy all copies of the communication and 
> any attachments.
>
> This communication is the property of CenturyLink and may contain 
> confidential or privileged information. Unauthorized use of this 
> communication is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please immediately notify the 
> sender by reply e-mail and destroy all copies of the communication and 
> any attachments.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 May 2018 19:30:09 +0000

I am not entirely sure if that works here or not.

But I think with that you could show some AS as the last AS in the past (far left) and maybe not show the original customer AS?

As long as your advertising that space to me, and I don't have a better path it should work.

Now what happens when a customer is a customer of ISP A and ISP B both have routes to it, if A advertises flowspec to B for that network wouldn't it be blocked as the best path to the customer inside of B is B's path.

This is actually a different problem, or subset of the original issue.

What should happen in that case? I might want to take action, I might not be seeing a huge flood, while the original announcer (A) is and wants us to take action as they expect we will be seeing that traffic soon?

Metric System < +000 > -000
Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
[email-masked]<mailto:[email-masked]>
________________________________
From: Juan Alcaide (jalcaide) [[email-masked]]
Sent: Friday, May 11, 2018 12:57 PM
To: Smith, Donald; Jakob Heitz (jheitz); John Scudder; idr@ietf. org
Cc: [email-masked]; Schiel, John; [email-masked]
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Don,

(just to be clear, this has nothing to directly with the redirect extended-community draft)

-J

From: Jakob Heitz (jheitz) [[email-masked]<mailto:[email-masked]>]

I support the draft.

Thanks,
Jakob

From: Idr <[email-masked]><mailto:[email-masked]> On Behalf Of Smith, Donald
Sent: Thursday, May 10, 2018 11:58 AM
To: John Scudder <[email-masked]><mailto:[email-masked]>; idr@ietf. org <idr@ietf..org><mailto:idr@ietf..org>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

From: Idr [[email-masked]<mailto:[email-masked]>] on behalf of John Scudder [[email-masked]<mailto:[email-masked]>]

Thanks,

--John

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 11 May 2018 19:39:19 +0000

Sorry Donald, Can you draw a diagram or reword your scenario?

Thanks,
Jakob

From: Smith, Donald <[email-masked]>
Sent: Friday, May 11, 2018 12:30 PM
To: Juan Alcaide (jalcaide) <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; John Scudder <[email-masked]>; idr@ietf. org <[email-masked]>
Cc: [email-masked]; Schiel, John <[email-masked]>; [email-masked]
Subject: RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Cc: [email-masked]<mailto:[email-masked]>; Schiel, John; [email-masked]<mailto:[email-masked]>

-J

Thanks,
Jakob

Thanks,

--John

Idr mailing list

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 11 May 2018 21:52:35 +0200

Yes.. also, I'd say we can keep the wording simple and open. So 
implementation/configuration can decide

-J

On 5/11/2018 9:39 PM, Jakob Heitz (jheitz) wrote:
> *From:*Smith, Donald <[email-masked]>
> *Sent:* Friday, May 11, 2018 12:30 PM
> *To:* Juan Alcaide (jalcaide) <[email-masked]>; Jakob Heitz 
> (jheitz) <[email-masked]>; John Scudder <[email-masked]>; idr@ietf. 
> org <[email-masked]>
> *Cc:* [email-masked]; Schiel, John <[email-masked]>; 
> [email-masked]
> But I think with that you could show some AS as the last AS in the 
> past (far left) and maybe not show the original customer AS?
>
> Now what happens when a customer is a customer of ISP A and ISP B both 
> have routes to it, if A advertises flowspec to B for that network 
> wouldn't it be blocked as the best path to the customer inside of B is 
> B's path.
>
> What should happen in that case? I might want to take action, I might 
> not be seeing a huge flood, while the original announcer (A) is and 
> wants us to take action as they expect we will be seeing that traffic 
> soon?
>
> *From:*Juan Alcaide (jalcaide) [[email-masked]]
> *Sent:* Friday, May 11, 2018 12:57 PM
> *To:* Smith, Donald; Jakob Heitz (jheitz); John Scudder; idr@ietf. org
> *Cc:* [email-masked] <mailto:[email-masked]>; Schiel, John; 
> [email-masked] 
>     Cc'ing the two architects that have been working on this concept
>     with me, in case they have anything to add.
>
>     *From:*Jakob Heitz (jheitz) [[email-masked]
>     <mailto:[email-masked]>]
>     *From:*Idr <[email-masked]> <mailto:[email-masked]>
>     *On Behalf Of *Smith, Donald
>     *To:* John Scudder <[email-masked]> <mailto:[email-masked]>;
>     idr@ietf. org <idr@ietf..org> <mailto:idr@ietf..org>
>     That is almost always going to be between some set of systems not
>     one hop away, not directly in the forwarding plane, probably not
>     really IBGP peers.
>
>     While you could have the IBGP peer directly in the forwarding
>     plane, forward it like a route reflector, requiring it to seems
>     counter intuitive as it is more likely to come from some BGP
>     speaking tool in ISP requesting the filter.
>
>     between peers (whom could do IBGP between them but is that
>     required? Can't we validate without IBGP direct connections?)
>
>     *From:*Idr [[email-masked] <mailto:[email-masked]>] on
>     behalf of John Scudder [[email-masked] <mailto:[email-masked]>]
>     communication is strictly prohibited and may be unlawful. If you
>     have received this communication in error, please immediately
>     notify the sender by reply e-mail and destroy all copies of the
>     communication and any attachments.
>
>     communication is strictly prohibited and may be unlawful. If you
>     have received this communication in error, please immediately
>     notify the sender by reply e-mail and destroy all copies of the
>     communication and any attachments.
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 May 2018 20:36:13 +0000

Customer M

|              |

|              |

|              |

ISPA------ISPB

ISPA sees a large DDoS attack against customer M and triggers a flowspec rule internally and to ISPB.

But ISPB has customer M connections too (one or more) and receives BGP announcements from them (or has a static or ... but has routes that would be preferred internally), thus the flowspec check would fail right?

Sent: Friday, May 11, 2018 1:39 PM
To: Smith, Donald; Juan Alcaide (jalcaide); John Scudder; idr@ietf. org

Thanks,
Jakob

-J

Thanks,
Jakob

Thanks,

--John

Idr mailing list

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 11 May 2018 20:42:58 +0000

This is the case that we all intend to work (I think), but only if ISPB explicitly
allows that flowspec rule from ISPA. It would not happen by default.
Now to find the words...

Thanks,
Jakob

From: Smith, Donald <[email-masked]>
Sent: Friday, May 11, 2018 1:36 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Juan Alcaide (jalcaide) <[email-masked]>; John Scudder <[email-masked]>; idr@ietf. org <[email-masked]>
Cc: [email-masked]; Schiel, John <[email-masked]>; [email-masked]
Subject: RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Customer M

|              |

|              |

|              |

ISPA------ISPB

Thanks,
Jakob

From: Smith, Donald <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 11, 2018 12:30 PM
To: Juan Alcaide (jalcaide) <[email-masked]<mailto:[email-masked]>>; Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; John Scudder <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Schiel, John <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

-J

Thanks,
Jakob

Thanks,

--John

Idr mailing list

---

From: John Schiel <[email-masked]>
Date: Fri, 11 May 2018 15:44:01 -0600

Don's example makes sense to me. Ideally CustM is getting traffic both from
ISPA and ISPB. If ISPA identifies and stops the traffic from going to
CustM, then sends a rule to B, ISPB may or may not accept the rule and the
attack would still go over the connection from ISPB to CustM based on
preferred path regardless of rule acceptance. If the metrics are different
and the preferred path is now from ISPB to ISPA and then to CustM, then the
importance of accepting the rule becomes more important.

I don't see any current issues with this WG.

--John

On Fri, May 11, 2018 at 2:42 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Smith, Donald <[email-masked]>
> *Sent:* Friday, May 11, 2018 1:36 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Juan Alcaide (jalcaide) <
> [email-masked]>; John Scudder <[email-masked]>; idr@ietf. org <
> [email-masked]>
>
> But ISPB has customer M connections too (one or more) and receives BGP
> announcements from them (or has a static or ... but has routes that would
> be preferred internally), thus the flowspec check would fail right?
>
>
>
>
>
>
>
>
>
> [email-masked]
> ------------------------------
>
> *Sent:* Friday, May 11, 2018 1:39 PM
> *To:* Smith, Donald; Juan Alcaide (jalcaide); John Scudder; idr@ietf. org
> *Cc:* [email-masked]; Schiel, John; draft-ietf-idr-bgp-flowspec-
> [email-masked]
> *From:* Smith, Donald <[email-masked]>
> *To:* Juan Alcaide (jalcaide) <[email-masked]>; Jakob Heitz (jheitz) <
> [email-masked]>; John Scudder <[email-masked]>; idr@ietf. org <
> [email-masked]>
> But I think with that you could show some AS as the last AS in the past
> (far left) and maybe not show the original customer AS?
>
> have routes to it, if A advertises flowspec to B for that network wouldn't
> it be blocked as the best path to the customer inside of B is B's path.
>
> What should happen in that case? I might want to take action, I might not
> be seeing a huge flood, while the original announcer (A) is and wants us to
> take action as they expect we will be seeing that traffic soon?
>
>
>
>
>
>
>
>
>
> [email-masked]
> ------------------------------
>
> *From:* Juan Alcaide (jalcaide) [[email-masked]]
> *Cc:* [email-masked]; Schiel, John; draft-ietf-idr-bgp-flowspec-
> [email-masked]
> [email-masked]
> ------------------------------
>
> *From:* Jakob Heitz (jheitz) [[email-masked] <jheitz@cisco..com>]
> *From:* Idr <[email-masked]> <[email-masked]> * On Behalf Of *Smith,
> Donald
> *To:* John Scudder <[email-masked]> <[email-masked]>; idr@ietf. org
> <idr@ietf..org> <idr@ietf..org>
> That is almost always going to be between some set of systems not one hop
> away, not directly in the forwarding plane, probably not really IBGP peers.
>
>
>
> forward it like a route reflector, requiring it to seems counter intuitive
> as it is more likely to come from some BGP speaking tool in ISP requesting
> the filter.
>
>
>
> IBGP, IBGP is internal to a single AS (yes I know there are exceptions) but
> that is kind of the meaning, while this is mostly between peers (whom could
> do IBGP between them but is that required? Can't we validate without IBGP
> direct connections?)
>
>
>
>
>
> [email-masked]
> ------------------------------
>
> *From:* Idr [[email-masked]] on behalf of John Scudder [
> [email-masked]]
> On Apr 26, 2018, at 3:58 PM, John Scudder <[email-masked]> wrote:
>
>
>
> draft-ietf-idr-bgp-flowspec-oid-06. Please respond with your comments
> before Friday, May 11.
>
>
>
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>
>
>
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Sat, 12 May 2018 01:14:07 +0200

If trafic goes ISPB->ISPA->Customer M, then ISPB will accept the FS rule 
from ISPA (this is just RFC5575)
If traffic goes ISPB->Customer M, then ISPB needs to trust the FS rule 
from ISPA. This is what ISPB needs to configure and this is the wording 
we are discussing

-J

On 5/11/2018 11:44 PM, John Schiel wrote:
> Don's example makes sense to me. Ideally CustM is getting traffic both 
> from ISPA and ISPB. If ISPA identifies and stops the traffic from 
> going to CustM, then sends a rule to B, ISPB may or may not accept the 
> rule and the attack would still go over the connection from ISPB to 
> CustM based on preferred path regardless of rule acceptance. If the 
> metrics are different and the preferred path is now from ISPB to ISPA 
> and then to CustM, then the importance of accepting the rule becomes 
> more important.
>
> On Fri, May 11, 2018 at 2:42 PM, Jakob Heitz (jheitz) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     *To:* Jakob Heitz (jheitz) <[email-masked]
>     <mailto:[email-masked]>>; Juan Alcaide (jalcaide)
>     <[email-masked] <mailto:[email-masked]>>; John Scudder
>     <[email-masked] <mailto:[email-masked]>>; idr@ietf. org
>     <[email-masked] <mailto:[email-masked]>>
>
>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Schiel, John
>     <[email-masked]
>     <mailto:[email-masked]>>;
>     But ISPB has customer M connections too (one or more) and receives
>     BGP announcements from them (or has a static or ... but has routes
>     that would be preferred internally), thus the flowspec check would
>     fail right?
>
>     *From:*Smith, Donald <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Juan Alcaide (jalcaide) <[email-masked]
>     <mailto:[email-masked]>>; Jakob Heitz (jheitz)
>     <[email-masked] <mailto:[email-masked]>>; John Scudder
>     <[email-masked] <mailto:[email-masked]>>; idr@ietf. org
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Schiel, John
>     <[email-masked]
>     <mailto:[email-masked]>>;
>     Now what happens when a customer is a customer of ISP A and ISP B
>     both have routes to it, if A advertises flowspec to B for that
>     network wouldn't it be blocked as the best path to the customer
>     inside of B is B's path.
>
>     What should happen in that case? I might want to take action, I
>     might not be seeing a huge flood, while the original announcer (A)
>     is and wants us to take action as they expect we will be seeing
>     that traffic soon?
>
>     *From:*Juan Alcaide (jalcaide) [[email-masked]
>     <mailto:[email-masked]>]
>         Cc'ing the two architects that have been working on this
>         concept with me, in case they have anything to add.
>
>         <mailto:jheitz@cisco..com>]
>         *From:*Idr <[email-masked]>
>         <mailto:[email-masked]> *On Behalf Of *Smith, Donald
>         <https://pc.nanog.org/static/published/meetings/NANOG71/1447/20171003_Levy_Operationalizing_Isp_v2.pdf>
>
>         That is almost always going to be between some set of systems
>         not one hop away, not directly in the forwarding plane,
>         probably not really IBGP peers.
>
>         plane, forward it like a route reflector, requiring it to
>         seems counter intuitive as it is more likely to come from some
>         BGP speaking tool in ISP requesting the filter.
>
>         Next lots of references to IBGP and a few to EBGP, when I
>         think of IBGP, IBGP is internal to a single AS (yes I know
>         there are exceptions) but that is kind of the meaning, while
>         this is mostly between peers (whom could do IBGP between them
>         but is that required? Can't we validate without IBGP direct
>         connections?)
>
>         *From:*Idr [[email-masked]
>         <mailto:[email-masked]>] on behalf of John Scudder
>         [[email-masked] <mailto:[email-masked]>]
>             draft-ietf-idr-bgp-flowspec-oid-06. Please respond with
>             your comments before Friday, May 11.
>
>         This communication is the property of CenturyLink and may
>         contain confidential or privileged information. Unauthorized
>         use of this communication is strictly prohibited and may be
>         unlawful. If you have received this communication in error,
>         please immediately notify the sender by reply e-mail and
>         destroy all copies of the communication and any attachments.
>
>         This communication is the property of CenturyLink and may
>         contain confidential or privileged information. Unauthorized
>         use of this communication is strictly prohibited and may be
>         unlawful. If you have received this communication in error,
>         please immediately notify the sender by reply e-mail and
>         destroy all copies of the communication and any attachments.
>
>         <https://www.ietf.org/mailman/listinfo/idr>
>
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>

---

From: "LINGALA, AVINASH" <[email-masked]>
Date: Fri, 18 May 2018 16:38:00 +0000

Support.

-Avinash

From: Idr <[email-masked]> On Behalf Of John Scudder
Sent: Thursday, May 10, 2018 2:28 PM
To: idr@ietf. org <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

Hi All,

Thanks,

--John