[Idr] Re: Genart last call review of draft-ietf-idr-deprecate-as-set-confed-set-17

[Jeffrey Haas <[e-mail]>]

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 <[e-mail]> 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
> 
>