[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

some 6bone backbone cleanup recommendations

Hi Bob,

you wrote:

> 6bone Folk,
> Per the 6bone backbone cleanup discussions at the LA IETF I have
> generated
> a first pass set of recommendations on how to proceed.
> The first basic rule to note is that there was almost complete
> consensus to
> avoid hard rule enforcement that forced a pTLA site off the 6bone
> backbone
> with no discourse or allowance for a site to try to clean up their
> act.  In
> fact, it was recommended that we be driven to the greatest extent
> possible,
> by reports that point out the problems (a bit of public exposure and
> humiliation so to speak).  Then arbitrate.
> Various ideas:
> Setup a 6bone-ops list consisting of only mail handles registered in
> the
> 6bone registry:
>   should include email handles from: (David Kessens has volunteered to
> do
> this list)
>     the person: object, e-mail: field
>     the mntner: object, mnt-nfy: field
>     remove duplicates
>     all 6bone sites, not just backbone pTLAs
> Use the current version of Buclin/Durand I-D on "IPv6 routing issues"
> as
> policy:
>   should rename this draft "6bone routing practices" (Bertrand is
> doing this)
>   publish reports of variance with them, per pTLA
> Require a minimum amount of peering for robustness sake:
>   say 3-5 other pTLAs, but not too many
> Publish daily lists of following information:
>   as above, publish reports of variance with the I-D rules, per pTLA
>   pTLA routes longer than /24
>   those pTLAs not carrying all routes (not so easy without special
> effort/tools)
>   those pTLA tunnels not using BGP4+ (already covered above)
>   those pTLAs having too many flaps (publish the Merit 6bone routing
> report)
>   the CSELT ASpath-tree results
>   ping tests across all tunnels
> Directed email to offending sites, especially those significantly
> affecting
> much of the 6bone
> So... comments and volunteers for bits of the work appreciated.
Now I am making available over the Internet a new html page showing the
anomalous BGP4+ prefixes (according to current version of Buclin/Durand
I-D on "IPv6 routing issues") advertised inside the 6Bone backbone. In
particular two kind of anomalous prefixes are displayed:
- Invalid prefixes: prefixes outside of the 6Bone range (e.g. the old
RFC1897 test addresses)
- Unaggregated prefixes: prefixes belonging to the 6Bone range but
longer than /24

This html page is available at
http://carmen.cselt.it/ipv6/bgp/odd-routes.html and is automatically
updated every 5 mim. I have added a link to this new page also inside
the main CSELT's BGP4+ routing info page
(http://carmen.cselt.it/ipv6/bgp/index.html) which is accessible from
the official 6Bone home page.

I hope this will be of help in cleaning up the 6bone backbone.



> Thanks,
> Bob