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

["Juan Alcaide (jalcaide)" <[e-mail]>]

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:
>
> Sorry Donald, Can you draw a diagram or reword your scenario?
>
> Thanks,
>
> Jakob
>
> *From:*Smith, Donald <[e-mail]>
> *Sent:* Friday, May 11, 2018 12:30 PM
> *To:* Juan Alcaide (jalcaide) <[e-mail]>; Jakob Heitz 
> (jheitz) <[e-mail]>; John Scudder <[e-mail]>; idr@ietf. 
> org <[e-mail]>
> *Cc:* [e-mail]; Schiel, John <[e-mail]>; 
> [e-mail]
> *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
> 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
>
> [e-mail] <mailto:[e-mail]>
>
> ------------------------------------------------------------------------
>
> *From:*Juan Alcaide (jalcaide) [[e-mail]]
> *Sent:* Friday, May 11, 2018 12:57 PM
> *To:* Smith, Donald; Jakob Heitz (jheitz); John Scudder; idr@ietf. org
> *Cc:* [e-mail] <mailto:[e-mail]>; Schiel, John; 
> [e-mail] 
> <mailto:[e-mail]>
> *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)
>
> 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:
>
>     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
>
>     [e-mail] <mailto:[e-mail]>
>
>     ------------------------------------------------------------------------
>
>     *From:*Jakob Heitz (jheitz) [[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Thursday, May 10, 2018 11:39 PM
>     *To:* Smith, Donald; John Scudder; idr@ietf. org
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     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 <[e-mail]> <mailto:[e-mail]>
>     *On Behalf Of *Smith, Donald
>     *Sent:* Thursday, May 10, 2018 11:58 AM
>     *To:* John Scudder <[e-mail]> <mailto:[e-mail]>;
>     idr@ietf. org <idr@ietf..org> <mailto:idr@ietf..org>
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     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
>
>     [e-mail] <mailto:[e-mail]>
>
>     ------------------------------------------------------------------------
>
>     *From:*Idr [[e-mail] <mailto:[e-mail]>] on
>     behalf of John Scudder [[e-mail] <mailto:[e-mail]>]
>     *Sent:* Thursday, May 10, 2018 12:28 PM
>     *To:* idr@ietf. org
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     Hi All,
>
>         On Apr 26, 2018, at 3:58 PM, John Scudder <[e-mail]
>         <mailto:[e-mail]>> 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
>
>     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
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/idr
>
> 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.
>