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

[Susan Hares <[e-mail]>]

Ines:

Thank you for your careful review of draft-ietf-idr-deprecate-as-set.

The authors will respond to your specific points.

Cheerily, Sue Hares
Shepherd

From: Ines Robles via Datatracker <[e-mail]>
Sent: Monday, February 17, 2025 3:17 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Gen-art] Genart last call review of draft-ietf-idr-deprecate-as-set-confed-set-17

Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for t
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2E2ZDA4YTI5ZjI4NzQ2NjQxMGNhYmQ1OTA5Y2U5N2ZiLzE3Mzk4MjM0MjkuODYxNjM0Mw==#key=4db20780b71933e6b7212228ba96ad59>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


Reviewer: Ines Robles

Review result: Almost Ready



I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at



<https://wiki.ietf.org/en/group/gen/GenArtFAQ<https://shared.outlook.inky.com/link?domain=wiki.ietf.org&t=h.eJw9jkkOgjAYha9Cujb9O1FaVrDRtUcotAwBKSklRo13l5ro7uUNX94L7WFGZYaGGNetBLiP04hHFzvsQw9ugT74fYX-UBe31CGe6ys6ZWhKo8XFo0VJrqSmDLbBBLdVi30OuPU3MNISZZjumCqElIKS1jQ210S3ThddA7TgWjEumMZKUskFT2j3Rfvg1vlR_a6kwKbgb7w_nEw4Zw.MEUCIEvgOpcSxdOybtYMTr0KdoJtxy6oktjqeL5z4NjNzOapAiEAu0Z5PK6s5HxmxAM-mO316fStIa-nz9cQmdQXdT6Revc>>.



Document: draft-ietf-idr-deprecate-as-set-confed-set-17

Reviewer: Ines Robles

Review Date: 2025-02-17

IETF LC End Date: 2025-02-17

IESG Telechat date: 2025-03-06



Summary:



The draft prohibits the use of the AS_SET and AS_CONFED_SET path segment types

in the AS_PATH. It distinguishes between two aggregation methods:



• Traditional brief aggregation (as defined in RFC 4271) aggregates routes by

combining differences in the AS_PATH into an unordered AS_SET (or

AS_CONFED_SET). This approach can leave the route’s origin ambiguous.



• Consistent brief aggregation avoids this ambiguity by deliberately truncating

the AS_PATH at a designated origin AS. By doing so, it does not use AS_SET or

AS_CONFED_SET, resulting in an unambiguous route origin.



This document updates RFC 4271 by deprecating the origination of BGP routes

with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the

origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). It also

obsoletes RFC 6472.



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?



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?



Thanks for this document.



Ines





_______________________________________________

Gen-art mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>