North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Customer AS
- From: Curtis Villamizar
- Date: Wed Aug 21 21:06:53 1996
In message <199608191828.TAA07038@diamond.xara.net>, "Alex.Bligh" writes:
> > I agree that the majority of more specifics are mistakes. We use the
> > IRR to separate out the inintentional mistakes (the redundancy in that
> > statement was intentional:). This does protect us against the all too
> > common case of too ignorant of CIDR to know better and registering the
> > more specific in the IRR anyway (the intentional mistakes).
> Really? I would agree that the majority of more specifics are not in
> the IRR. This doesn't necessarilly mean they are mistakes. For instance
> we announce a pile of more specifics from other provider aggregates
> (intentionally, and with permission) where a customer is renumbering.
> These get filtered by Sprint (because they are too long prefixes),
> and by ANS (as they aren't in the IRR), but the idea is we propogate
> these more specifics as close as possible to the major networks
> as possible, so that as far as possible we aren't using the
> old providers transit to transit these routes (for several
> obvious reasons). We don't put advisories or more specifics in the
> IRR for several reasons, not least of which because this is a temporary
> arrangement, and sorting out changing guardianship of the RIPE
> objects etc. etc. with the old provider who is often slow to
> cooperate is simply not worth the hassle.
The mistakes that I was referring to is the more specifics that *are*
in the IRR and are announced even though there is no good reason to
announce them. If I look throught the routes we accept, there are
quite a few long lists of contiguous /24s with identical ASpaths.
Some of them have aggregates but perhaps the aggregator hasn't
BTW- wrt you second point. It's OK to keep the /24s in the IRR if you
want a record for contact reference, but they should be marked
withdrawn. Advisories are no longer used by ANS as of October 1995.
> So I have no problem with either ANS or Sprint's filters, just
> don't think *all* non-IRR entered more specifics are mistakes.
Entering the aggregate an not the more specifics is OK. Sorry for not
being clear. If you announce the more specifics we'll just accept the
aggregate, which is also OK with us if the more specifics would not
improve our connectivity at all.
> Alex Bligh
> Xara Networks
- - - - - - - - - - - - - - - - -