[routing-wg] IPv6 Routing Recommendations

the idea here is twofold: 
1) to take routing policy out of addressing policy. That part was done
2) make people aware that while de-aggregation is possible, it has its costs, for everyone, not just the de-aggregator, and therefore one should think a bit before splitting an allocation down into atoms. Because a lot of people find it good to have some recommendation describing this thought process, this document is being written and sent for consideration to the working group.

Joao

On 27 Apr 2010, at 11:25, Sander Steffann wrote:

> Hi Philip,
> 
>> Nick Hilliard said the following on 27/04/10 07:57 :
>>> On 26/04/2010 13:32, Randy Bush wrote:
>>>> we tell people ipv6 allows multi-homing.
>>> 
>>> Do we?   Which particular vapour are you referring to here?
>> 
>> I suppose the question Rob and I are trying to address is, do we want to
>> encourage ISPs to take their /32 and announce all 65536 /48s in an
>> effort to do some kind of amazing traffic engineering act by juggling
>> all 65k prefixes at once?
>> 
>> Or do we want to encourage ISPs to think aggregation, and only leak the
>> subprefixes that they need to leak to support their multihoming
>> customers and traffic engineering requirements?
> 
> I want to emphasize that this came up because of LIRs that had multiple distinct networks that they couldn't announce (ok, nothing is impossible, but it would be awkward)  their PA /32 prefix in one part. Possible solutions were to give them multiple /32 prefixes or to write a recommendation that a bit of de-aggregation should be permitted. At the time the latter was felt to be a better solution :)
> 
> It can of course be abused for traffic engineering...
> 
>> Anyway, the doc would just be recommendations, along the lines of
>> RIPE-399 being no more than recommendations. If folks think we are
>> wasting our time putting together an IPv6 equivalent, let us know, and
>> we can stop here. ;-)
> 
> The routing stuff was taken out of the address policies to be moved to a separate routing recommendations document. I think this is important, so please continue :-)
> 
> Thanks,
> Sander
>