In message <c67b6f74.15f%terry.mander...@icann.org>
Terry Manderson writes:
>
> Hi Curtis,
>
> Thanks for reading and providing feedback on the document.
>
>
> On 5/07/09 7:27 AM, "Curtis Villamizar" <cur...@occnc.com> wrote:
>
>
> >
> >
> > There seem to be a few classes of requirements missing.
> >
> > 1. Third party aggregation.
> >
> > AS X wants to form and aggregate based on components originated by
> > another set of AS.
> >
>
> By this do you mean that AS X wants to additionally originate the prefixes
> from AS Y, or perhaps simply aggregate two contiguous prefixes into one
> announcement?
AS-{A,B,C..} are connected to AS-X and maybe one other (AS-Y). If
both AS-X and AS-Y aggregate, things are OK. If AS-X and AS-Y
exchange more specifics only among themselves all is fine.
Example: After CANET fragmented (mid-1990s) most of the 1,500 or so
component routes were announced to ANS or InternetMCI with ANS and MCI
forming aggregates. This took some coordination but wasn't bad. It
predated BGP communities and was mostly coordinated through the IRR.
Other example: Most of OZ used to be homed into two US providers both
with beachheads in OZ. They could have done the same but AFAIK they
did not. They may have at one time used BGP communities to deal with
this but a lot has changed since and I don't know how that evolved.
> > 2. Hostile aggregation avoidance.
> >
> > AS Y does not want their component included in the aggregate
> > formed by AS X. [Note: This can currently be communicated in BGP
> > communities to an immediate peer or through RPSL. For any method,
> > there is no way to enforce the requrest to AS X.]
>
> Right, so where AS X is doing aggregation as in "1." above, AS Y wishes to
> say "thou shalt not aggregate my routes". Yeah?
Example: Sprintlink advertising /8 routes. They didn't do that for
very long due to a bit of an uproar.
> > 3. Peer preference.
> >
> > AS Y would like to indicate a preference for a given peer or AS
> > path. [This can be done through RPSL, and to an extent using AS
> > Path padding. AS Path padding is by far more commonly used,
> > though it only affects choice of among immediate peers.]
> >
> > If this is a requirements document it doesn't make sense to list only
> > the requirements covered by a predetermined solution.
>
> Sure. I'm more than happy to accept and list all possible or potential
> needs.
>
> [...]
>
> >
> > Another note: Is there any plan to fill in the "how" in the examples
> > provided or is that going to be left as an exercise to the reader?
> >
>
> Yes.. I intentionally left out 'how' as it would have wrongly drawn the
> discussion to interpretation of RPKI objects instead of listing the
> use-cases. Once the use cases are solid, effort can then be given to
> documenting suggested ways to achieve the outcomes using RPKI objects.
OK. Thanks.
> Cheers
> Terry
Curtis
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
