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

[Ines Robles <[e-mail]>]

Ok, thank you, Jeffrey, for addressing my comments.

Best regards,

Ines

On Tue, Feb 18, 2025 at 4:02 PM Jeffrey Haas <[e-mail]> wrote:

> 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
>
>
>