Re: [sidr] [Sidrops] operator inputs -- route leak solution

[Randy Bush]

> With all due respect, your draft fails to acknowledge the earlier work by
> me (from 2012), outside of the recent drafts of which I am a
> co-author.

apologies.  this should be corrected,

> So, perhaps it would be best to avoid claims of plagiarizing, when (a)
> there is clear evidence that the source of the material predates your work,
> and (b) when your work does not credit the original work by me.

word for word

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] operator inputs -- route leak solution

[Brian Dickson]

On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering  wrote:

> Hi,
>
> On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote:
> > Pre-emptive top-post in case anyone mistakes the technique proposed: This
> > will NOT be implemented via communities.
> >
> > The proposal is for a NEW optional transitive attribute.
> >
> > If any operators can answer the original question, this will be very
> > helpful. Thank you in advance to any and all operators.
> >
> > Reminder on optional+transitive logic
> > - If the attribute is not understood/implemented/enabled, the attribute
> is
> > passed unmodified.
> > - If it is understood & implemented & enabled, behavior is subject to the
> > applicable standards.
> > - Thus, optional transitives are "opt-in", by definition.
>
> It does not really matter if this is a well-known community or a new
> transitive attribute.
>
> If ISPs do not turn this *on* on their customer connections, it will not
> do anything - and given that those ISPs that *need* to turn this on are
> the ones that are not caring today, I'm still not seeing why they would
> turn this on tomorrow.
>
>
There is direct benefit to partial (even very sparse) deployment.

The deployment is self-serving; whoever turns this on protects themselves
and their downstream customers.

This becomes a differentiator with direct benefits, and creates market
pressure to deploy.

Here's the simplest example showing how few parties need to implement this,
for benefit.
(Key: O = originator, T = top-tier ISP, L = leaker; number N disambiguates;
subscript y/n means "implements")

On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) -
Tn2 - (arbitrary path) - On2

   - leaks in both directions pass without any tagging/blocking;
   - Path via L is preferred, because T1 and T2 prefer customer routes
   (which include L)
   - All traffic between Tn1 and Tn2 is affected (assuming L leaks the
   entire routing table)
   - In addition to latency caused by extra hops, there will likely be
   queueing-based latency, and significant loss

On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) -
Ty4 - (arbitrary path) - On2

   - leaks in both directions are blocked, at Ty3 and Ty4 respectively
   - The leak is blocked despite neither On1 nor On2 activating the protocol
   - The actual path selected will be something else, possibly/probably:
  - On1 - ... - Ty3 - Ty4 - ... - On2
  - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those
  routes are excluded
  - Assuming Ty3 and Ty4 peer, there will not be a better path
  respectively, modulo other peers with shorter AS paths to On1 or On2.

If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths,
the following will be the case:

   - In all likelihood, there will be massive latency and packet loss, on
   the first path via L
   - The other path will not have that latency/loss
   - On1 and On2 will both be better served by
  - preferentially routing to Ty3 and Ty4 (apply better  local-pref
  inbound to Ty3 and Ty4)
  - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
   - On1 and On2 obtain benefit by being able route around L (the leaker)
   - Ty3 and Ty4 get benefit by having more traffic to/from their customers
  - Potential customers may choose Ty3 and Ty4 for those reasons
  - Networks who deploy on their own infrastructure gain similar
  benefits, even if they

All of the above presumes intermediate ASNs that do not implement (all of
the "arbitrary path" bits), yet there is benefit to all the named parties.

The same would be true for ASNs at Tier-2 who peer at various exchange
points, who implement; they would possibly position themselves better than
Tier-1's until any Tier-1's implement.

NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT
see the benefit, unless they also implement, so there is further reason to
implement for Tier-N, N>1.

FYI - I worked as a senior network engineer, where inbound peering ACLs of
other Tier-1 networks, allowed us to escape the AS7001 incident unscathed.
This scales a lot better, since there is no need for ACL maintenance.
Applying to customers/peers should be easy, assuming the ISP knows which
BGP neighbors are customers...

Brian



> So you're adding implementation complexity which will not help anything.
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr