Subject: [Idr] Request for 2 drafts

From: "Susan Hares" <[email-masked]>
Date: Mon, 13 Mar 2017 17:11:45 -0400

Jie, John and y'all IDR folks: 

<individual contributor hat on> 

I'd like to follow-up on our "clean up" the attribute area discussion. 

I've published: 

draft-hares-deprecate-atomic-aggregate-00  

draft-hares-idr-bgp-registries-00.txt

I'd like a presentation slot to continue our discussion.  It might be good
near Jeff's document on the same topic (if he's asking for a slot). 

<individual contributor hat off> 

Sue 

PS - I know the first one does not have a BGP or idr title.  It's on
purpose.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 14 Mar 2017 03:15:48 +0000

Hi Sue,

I've added your presentation to the tentative agenda, could you also let me know the desired duration of your presentation? Thanks.

Best regards,
Jie

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, March 14, 2017 5:12 AM
To: Dongjie (Jimmy) <[email-masked]>; 'John G. Scudder' <[email-masked]>; 'idr wg' <[email-masked]>
Subject: Request for 2 drafts

I've published:

I'd like a presentation slot to continue our discussion.  It might be good near Jeff's document on the same topic (if he's asking for a slot).

Sue

PS - I know the first one does not have a BGP or idr title.  It's on purpose.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 14 Mar 2017 07:22:15 -0400

Jie:

Thank  you.

Sue 

From: Dongjie (Jimmy) [mailto:[email-masked]] 
Sent: Monday, March 13, 2017 11:16 PM
To: Susan Hares; 'John G. Scudder'; 'idr wg'
Subject: RE: Request for 2 drafts 

Hi Sue, 

I've added your presentation to the tentative agenda, could you also let me
know the desired duration of your presentation? Thanks.

Best regards,

Jie

From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 5:12 AM
To: Dongjie (Jimmy) <[email-masked]>; 'John G. Scudder'
<[email-masked]>; 'idr wg' <[email-masked]>
Subject: Request for 2 drafts 

I've published: 

 

Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Mar 2017 15:30:36 -0400

Sue,

> I'd like to follow-up on our "clean up" the attribute area discussion. 
[...]
> draft-hares-deprecate-atomic-aggregate-00  

I'd actually recommend against outright deprecating AA.  Mostly it'll lead
to confusion of compliant implementations of 1771/4271 without a lot of
benefit.

A significant amount of the controversy around the feature while
standardizing 4271 had to do with the rules by which AA was attached to
routes.  I suspect very few people besides Tony Li ever had a strong opinion
about the behavior, especially once we got beyond the BGP-3 transition.  
(And I wasn't there at the time.  The Tony observation is driven mostly by
him popping up a few years ago with a proposal that included AA behavior.)

The current behavior of 4271 with regard to AA is pretty mild: If you're
dropping out ASes from the path as part of aggregation, you SHOULD add this
thing.  If you see it, don't de-aggregate.

People generally don't de-aggregate magically these days and those who do
generally expect to have to be very careful.

The document that I thought was worth writing at some point, even if it only
was a draft and never got published, was a short discussion about the origin
of the feature, what its original intent was, what was broken about its
original rules to be attached and why we ended up where we did.  This is
arguably a history document intending to document a rather ugly bit of
living history that confuses newcomers to the protocol.

I'm happy to contribute to such a document.  But I don't recommend we
proceed down the path to deprecation.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Tue, 14 Mar 2017 23:07:54 +0100

> proceed down the path to deprecation.

Hi Jeff,

Isn't the path to deprecate a poorly understood feature ("poorly" as in
ugly, that there is a disconnect between expectations), to just.. deprecate
it? I'd welcome historic perspective in such a deprecation document for
newcomers, it would be helpful for my edification to learn of the rise and
fall of a protocol complications.

However I don't see a compelling reason in itself to not touch 4271, for
the purpose of touching 4271. There have been a number of updates to 4271
over the years, and compliant implementations need to continue to monitor
IETF documents to remain complaint, right?

In context of internet-wide EBGP operations I'd view both aggregation
(aggregation through snipping globally unique ASNs from the as_path) as
well as de-aggregation as most unwelcome. At this point especially
de-aggregation is real threat to the DFZ, stuff like
http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to
mind.

Is there a legitimate use case for keeping atomic aggregate around? if not,
we should clean up.

I'm usually in favour of deleting things that are not used.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Mar 2017 18:39:16 -0400

> fall of a protocol complications.

This is one of those things I'd love to say "it's nice on principle" but
usually get followed by "but the consequences are a bit ugly".

Deprecating means largely "don't do that".  You now have to deal with all of
the consequences of those things that still do that or expect such to be
done.  BGP changes are all about incremental rollout headache after all.

Implementations will still be required to understand the attribute and
minimally to ignore it.  This means you don't really get rid of much code
there.

Conformance tools will still probe for what we do for things and have to be
revised to not flag as non-conformant an implementation that doesn't pass
the attribute along if it's been set.  Or that it's added if the as-path is
truncated or otherwise incomplete.

And while deaggregation isn't typically done automatically by routers, it's
still good to signal that doing so may be a bad idea.  I'll let you dig out
your favorite deaggregation traffic shaping tool presentation from the *NOG
of your choice.

So, the benefits don't really outweigh the consequence of leaving it in.

If we'd been having this conversation as part of trying to get 1771 style AA
semantics working right[1], I might have had a somewhat different opinion.

> IETF documents to remain complaint, right?

See above.

> http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to

See above. (I generally agree.)  It's also likely to get worse.

> I'm usually in favour of deleting things that are not used.

You're also not the one that gets the bug reports from this sort of thing.
:-)  

At best, I'll acknowledge your network won't fall over from it not showing
up the few times it actually does in the DFZ these days.

-- Jeff

[1] As part of Sue's crash course to how to participate in the IETF process,
I was encouraged to try to work out issues we'd found in our implementation
of the specification (draft-ietf-idr-bgp4-XX) on the mailing list.  As part
of working through inconsistencies in the text regarding how AA was set, I
tried to contact our venerable authors on BGP to get them to work through
those inconsistencies with me.  Being busy at startups, most didn't respond.
This left a rather inexperienced protocols implementor trying to intuit
"what is this thing for?" and supplying various bits of text toward the
draft to try to rectify the discrepancies.

It turns out that if done using the intent of 1771 and earlier, AA would be
set on *most* things, especially when policy was involved.  However,
discovering this set of things resulted in at least 3 churns of the draft.
Eventually that was overcome by the realization that this is an appendix, in
the anatomy sense; a vestigial organ.  It's mostly useful to prevent
auto-deaggregation in implementations that were transitioning from the
classful BGP-3 to CIDR BGP-4.  Such things didn't seem to be common even
back in the day, and the transition from -3 to -4 seemed to take very little
time across the backbones.

What eventually remained was "this is a good idea to signal truncation or
loss of information from the as-path" in the event that deaggregation would
happen. While gross, people did and still do it.  And even otherwise, having
it as a handy note that "information was lost" during aggregation is still
handy.[2]  Having lost most of the crazy text about the rules with which you
set AA based on what you learned, we now have a relatively quiet feature
that's easy to implement with some minor operational benefit.

This exercise in archaeology was my first, and a lingering introduction to
Internet standards.  I've almost foriven my second introduction, which
involved SNMP.

[2] An interesting side effect of extened UPDATES in our other thread will
be that aggregation that results in sets from gateD family software will
mean we have even LONGER AS_SETs today than before.  While such
implementations support "brief" aggregation, the transitional behavior of a
long AS_SET on a extended message speaker to a 4k speaker will make for an
interesting edge and conformance case.

---

From: Job Snijders <[email-masked]>
Date: Tue, 14 Mar 2017 23:45:25 +0100

> interesting edge and conformance case.

Thank you for sharing this Jeff. I treasure emails like these :)

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Mar 2017 11:54:39 -0400

Jeff:

+1 to your problems on changing.  Conformance tools can be changed, but
operators (Data Center, IXP, Enterprise, Carrier) need to buy into upgrades
to tools and re-testing all BGPs.  

Thank you for revealing your tortured past below.    I'm sure you should be
a co-author on any history for Atomic Aggregation (sounds radioactive). 

(Smile. )

Sue
-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, March 14, 2017 6:39 PM
To: Job Snijders
Cc: idr wg
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request
for 2 drafts)

On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote:
> Isn't the path to deprecate a poorly understood feature ("poorly" as 
> in ugly, that there is a disconnect between expectations), to just.. 
> deprecate it? I'd welcome historic perspective in such a deprecation 
> document for newcomers, it would be helpful for my edification to 
> learn of the rise and fall of a protocol complications.

> However I don't see a compelling reason in itself to not touch 4271, 
> for the purpose of touching 4271. There have been a number of updates 
> to 4271 over the years, and compliant implementations need to continue 
> to monitor IETF documents to remain complaint, right?

See above.

> (aggregation through snipping globally unique ASNs from the as_path) 
> as well as de-aggregation as most unwelcome. At this point especially 
> http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes 
> to mind.

> Is there a legitimate use case for keeping atomic aggregate around? if 
> not, we should clean up.
> 

-- Jeff

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Mar 2017 11:47:59 -0400

Job and Jeff: 

Thank you for the feedback.  You are having the same conversation I had with myself about deprecate.  After IETF97, I came down on the side of “getting rid of features that do not exist”.   If we are going to a BGP version 5, this would be one of the things we would get rid of.   I’d like to hear more from other people.  

Job - I’m happy to work with you on such a document that provides history for atomic-aggregate since I was in the original discussions.   I will start a document and we can discuss it at IETF 98 prior to publishing.  

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Tuesday, March 14, 2017 6:08 PM
To: Jeffrey Haas; idr wg
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)

Sue,

[...]

Hi Jeff,

Isn't the path to deprecate a poorly understood feature ("poorly" as in ugly, that there is a disconnect between expectations), to just.. deprecate it? I'd welcome historic perspective in such a deprecation document for newcomers, it would be helpful for my edification to learn of the rise and fall of a protocol complications.

However I don't see a compelling reason in itself to not touch 4271, for the purpose of touching 4271. There have been a number of updates to 4271 over the years, and compliant implementations need to continue to monitor IETF documents to remain complaint, right? 

In context of internet-wide EBGP operations I'd view both aggregation (aggregation through snipping globally unique ASNs from the as_path) as well as de-aggregation as most unwelcome. At this point especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to mind.

Is there a legitimate use case for keeping atomic aggregate around? if not, we should clean up.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Mar 2017 14:22:59 -0400

> a co-author on any history for Atomic Aggregation (sounds radioactive). 

I've had challenging work and good teachers.

We could discuss whether you'd rather repurpose the deprecate draft for
history in Chicago. :-)

-- Jeff

---

From: Theodore Baschak <[email-masked]>
Date: Wed, 15 Mar 2017 15:15:54 -0500

The big incumbent Telco in my area, AS7122, went from overboard on de-aggregation (several /16's advertised as /16+/19's + /24's +/32's) to overboard on aggregation, using the atomic aggregate attribute. 

Overnight on 2015-09-13 AS7122 enabled atomic aggregate for all blocks, despite having 6 downstreams advertising /24's and whatnot from those blocks. Just coincidentally, none of those downstreams were multi-homed at the time so no one noticed anything and there was no pushback. However, now some of these ASNs have been wanting to multi-home and will have trouble doing so because their one path will now be squashed in a atomic aggregate.

Theodore Baschak - AS395089 - Hextet Systems
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/

> On Mar 15, 2017, at 10:47 AM, Susan Hares <[email-masked]> wrote:
> 
> Job and Jeff: 
>  
> On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> Sue,
>> 
> In context of internet-wide EBGP operations I'd view both aggregation (aggregation through snipping globally unique ASNs from the as_path) as well as de-aggregation as most unwelcome. At this point especially de-aggregation is real threat to the DFZ, stuff like http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ <http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/> comes to mind.
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Mar 2017 17:06:15 -0400

Thanks for the report.   This is useful information – sounds like the atomic aggregate caused some real problems.   

Do you know what the telco will do if we pull atomic aggregate? 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Theodore Baschak
Sent: Wednesday, March 15, 2017 4:16 PM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)

Job and Jeff: 

Sue 

 

On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas < <mailto:[email-masked]> [email-masked]> wrote:

Sue,

[...]

Hi Jeff,

In context of internet-wide EBGP operations I'd view both aggregation (aggregation through snipping globally unique ASNs from the as_path) as well as de-aggregation as most unwelcome. At this point especially de-aggregation is real threat to the DFZ, stuff like  <http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/> http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to mind.

Kind regards,

Job