My reply only had gone out to IDR, copying everyone else and catching some missing text:
> On Feb 17, 2025, at 4:26 PM, Jeffrey Haas <jh...@pfrc.org> wrote: > > Ines, > > Thanks for your review. > > On 2/17/25 15:16, Ines Robles via Datatracker wrote: >> The document is well written, and I have some questions: >> >> 1- Consistent Brief Aggregation: What operational considerations or >> guidelines >> do you suggest for selecting the designated origin AS in environments where >> multiple candidate origins exist, such as in multi-homed or proxy aggregation >> scenarios? > It's difficult to offer strong advice here, because "that depends". > Fundamentally what we're interested in is that the operator chooses something > that will make sense for their environment. The most likely scenario will be > that the aggregating party is also the holder of the address space for the > aggregate. In such cases their own AS will likely be the origin AS and they > will discard the contributing AS_PATHs and originate the aggregate using > their own AS. > > For the other cases? It'll depend. The most likely case for including a > contributing downstream AS will be when the address space has been > partitioned and the proxy aggregation will be for a more specific network. > > An example could be provided, but the worry is that suggestions are read > overly strong as normative implementation advice. > > > > >> 2- In cases where consistent brief aggregation results in an empty AS_PATH, >> is >> attaching the ATOMIC_AGGREGATE attribute sufficient to handle the resulting >> loss of AS_PATH information? Or should operators implement additional >> measures >> to ensure proper route validation and loop prevention? ATOMIC_AGGREGATE is effectively vestigial. No one automatically deaggregates. -- Jeff > Jeff > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
