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 <nore...@ietf.org> Sent: Monday, February 17, 2025 3:17 PM To: gen-art@ietf.org Cc: draft-ietf-idr-deprecate-as-set-confed-set....@ietf.org; i...@ietf.org; last-c...@ietf.org 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 (nore...@ietf.org<mailto:nore...@ietf.org>) 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 -- gen-art@ietf.org<mailto:gen-art@ietf.org> To unsubscribe send an email to gen-art-le...@ietf.org<mailto:gen-art-le...@ietf.org>
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
