Hi Hank,

Your talk points to the agenda slides: http://ripe62.ripe.net/presentations/112-ripe62-rtg-agenda.pdf

Where are your slides?

It should be the final slide of the same pack. That is all there was, if you review the video of the session it was very, very, short. :) Rob

Hi, for starters, i'm not sure if such a recommendation does anything "good", since people tend to ignore "recommendations" if they think they suck for their needs, but it certainly won't harm anything. So i'm all in favor of this one. At least one can point to it to induce some clue. Now for the points mentioned here: Am 27.06.2011 um 14:05 schrieb James_R-ripelist@jump.org.uk:

On Mon, 27 Jun 2011, Rob Evans wrote:

...

...

1 I would now like to start a four week "last call" on the routing recommendations draft so that it can be published as a RIPE document. Please send comments to the list.

Including mention of a /48 general acceptance seems to be without any logic or foundation.

Why?

No one needed 16 bits of deaggregation in IPv4, I can't see any reason why 16 bits of deaggregation is needed, or in any way sensible in IPv6.

"No one" or "you"? Why does it harm if no one needs it anyways?

How about suggesting a /36, rather than turning IPv6 deaggregation into the same mess that IPv4 has become - except several orders of magnitude worse,

A /36? Why not a /40 (i use this for downstream-ISPs-not-being-LIR, so of course it's better for me), why not a /47 (i use this for PA filtering, allowing aggregation but not /48 TE-deaggregation and use of PA /48s as an alternate solution to more expensive PI). This is about some sort of consensus, and a prefix length of /48 is the only thing that most seem to agree on for "this far but certainly not further". And again, it's a recommendation, not more. You can do whatever you want if your peer/upstreams allow it. That's the way the Internet works.

since with v4 the most anyone can expect to deaggregate their /21 is into /24s, growing their slots in the global BGP table 8x, whereas with v6 you're leading a /32 into /48 deaggregation, growing slots in the gobal BGP tables 65536x.

Why should anyone do that? Why do you think other operators would those let them do this? Do you have any evidence here?

Routers won't cope for long with people dumping v6 /48s into the tables in the same way that v4 /24s get dumped into the tables.

Do you have any evidence here? Do you know when the v6 tables will outgrow your routers? Do you know how many v6 table slots your next routers will support? Don't you have a business plan to upgrade your routers in the next 5-10 years or so when you probably run low on RAM/TCAM/etc space and they are outdated anyways?

"The operator community will ultimately decide" - is nonsense, commercial decisions rather than prudent technical decisions take over when it comes to whether to accept silly deaggregation, as a result several high profile content and network providers are no longer running default-free because of the sheer size of the tables no longer fitting on their equipment (which would have fit just fine if it wasn't for general acceptance of excessive deaggregation).

Do you have any evidence here? Do you understand that the internet is run by commercial companies making commercial decisions today and the time where technical decisions were honored are long gone? Or why do we see IPv4 deaggregation for Traffic Engineering nowadays for example? Bottom line: The only thing anyone (as in "the majority") can agree on is a /48 as upper limit. You can only try to mitigate any ill-effect by such a moderate recommendation since you can't rule the internet. If you recommend something too strict, everyone will ignore it and it's completely useless. In the end, that's probably the best _WE_ can do here at this place (routing-wg). We already had this discussion i think :-) Feel free to lobby for your point of view to all companies out there, we will all praise you if you succeed in convincing everyone not to deaggregate for stupid reasons! -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

The last call has come to and end up. A poll of the room was conducted today at the meeting of the routing wg during RIPE63 with no additional comments. There have also not been additional comments on the mailing list and the comments that came up earlier have been addressed without further followup discussion. In view of this, I, as routing wg chair, hereby declare consensus has been reached and request that the RIPE NCC proceed to publish the IPv6 routing recommendations document be published as a RIPE document. Thanks to all who have worked to get this done and in particular to Rob Evans and Philip Smith who edited the document. Joao Damas On 19 Oct 2011, at 15:17, Joao Damas wrote:

Formally, this last call ended a few weeks ago. Comments received, by James and Sascha do not appear to leave open issues at this time. However, since we didn't formally close this when we should have, I am extending this two more weeks, to November 2nd, coinciding with the wg meeting at RIPE 63.

regards, Joao

On 27 Jun 2011, at 12:26, Rob Evans wrote:

...

All,

Just a gentle reminder that we are now three weeks into the last call on the IPv6 routing recommendations document. Latest version attached for your convenience.

...

1 I would now like to start a four week "last call" on the routing recommendations draft so that it can be published as a RIPE document. Please send comments to the list.

All the best, Rob

<v6-aggregation.txt>