nested prefixes in Internet

Mon Nov 21 15:41:21 UTC 2016

Hopefully they would be flexible with this sort of policy under certain
circumstances.

I could see this as being somewhat problematic for mitigation providers,
since longer mask preemption is a commonly used method to take on traffic
for scrubbing, as well as customers potentially using a more specific for
migration activity. Or heck, even a less corner case scenario of traffic
engineering to a particular location via more specific route.

To me, it just sounds like more headache than it may be worth to have to
deal with that sort of thing.

On Mon, Nov 21, 2016 at 9:08 AM, Victor Sudakov <vas at mpeks.tomsk.su> wrote:

> Niels Bakker wrote:
> > >I have reports that in case (2), some operators (e.g. Rostelecom)
> > >don't accept the /24 or even /23 prefix on the grounds that it is
> > >part of a larger /19 route already present in the routing table.
> > >
> > >Could they have a reason not to accept these more specific prefixes
> > >other than a whim?
> >
> > If you announce a prefix you must deliver traffic sent to addresses
> > covered by it.  You don't go announcing 0.0.0.0/0 to your peers either.
> >
> > If a customer takes a /24 and announces it elsewhere, a transit
> > provider runs the risk of accepting inbound traffic without having
> > the possibility to bill their customer for it if it accepts more
> > specifics from e.g. a peer.
>
> That's all correct from the point of view of the provider annoncing
> the /19 route, and should be their risk.
>
> My question was however from a different perspective. If AS333
> receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is
> nested within AS111's /19), what reason might AS333 have to ignore the /24?
> AS333 is not concerned with possible monetary relations between AS111
> and AS222.
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:sudakov at sibptus.tomsk.ru
>