[Idr] Re: Fwd: I-D Action: draft-haas-idr-path-attribute-filtering-02.txt

[[e-mail]]

Jeff, John,

Thanks for the updated draft and the significant improvements.

Please find below some additional feedbacks.

1) editorial
The document defines two roles (a speaker sending the routes and a speaker receiving the routes), with filtering action specified for those two roles. Sometimes I feel that its not always clear which role/speaker is referred to. I would have a preference for defining and using two different terms (e.g., in the model of RFC 4724: " Restarting Speaker", " Receiving Speaker"). This is partly done (e.g. " receiving BGP") but IMHO not consistently.

e.g., " For some unwanted Path Attributes, an implementation may choose to use attribute discard for the unwanted Path Attributes rather than using treat-as-withdraw for the entire route. Implementations SHOULD provide operational visibility when attribute discard is done, via logging or aggregate statistics, on a per-BGP neighbor basis."
Is this for the receiving speaker, the sending speaker, or both? (also relates to be below point)



2) unclear semantic/behavior from the perspective of the receiving speaker/AS

My understanding is that the sending speaker is free to either perform "Attribute discard" or "Treat-as-withdraw".
To me this is a concern:
- the receiving AS/speaker does not seem to be able to know (' Operational Visibility" does not seem to cover this).
- the semantic of the Capability Flags are unclear IMHO as a single signal have two different meaning.

Especially as the result are very different in term of routing (route is there, or not).
I'm assuming that you may want one or the other depending on the attribute type. E.g. TAW for Prefix SID, Attribute Discard for ELCv2. If not, may be this is my preference that I'm projecting onto you 😉

Some possible suggestion:
-a- specify the behavior in the IANA 'Filtering Profile", which could have 3 values: "none", "Attribute Discard", Treat-as-withdraw". That would address my concern, and presumably address your preference to have different filtering depending on the attribute.
-b- only apply the filtering on the receiving side (where one can chose, have ops visibility and ability to debug). This is slightly less efficient, but assuming that's a safety net for a very small fraction of the routes, this is not a concern.

Thanks,
Best regards,
--Bruno

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
Sent: Thursday, August 21, 2025 1:51 AM
To: idr <[e-mail]>
Subject: [Idr] Fwd: I-D Action: draft-haas-idr-path-attribute-filtering-02.txt

--------------------------------------------------------------------------------------------------------------
CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.
--------------------------------------------------------------------------------------------------------------

Working Group,

John Scudder and I have published an update for the path attribute filtering capability proposal.

Notable changes:

- Operational considerations

- Recommended default filtering behaviors, including establishing new entries in the IANA managed path attribute registry.

We look forward to your comments.

-- Jeff (speaking as an individual contributor)



-------- Forwarded Message --------

Internet-Draft draft-haas-idr-path-attribute-filtering-02.txt is now available.

Title: BGP-4 Path Attribute Filtering Capability
Authors: Jeffrey Haas
John Scudder
Name: draft-haas-idr-path-attribute-filtering-02.txt
Pages: 15
Dates: 2025-08-20

Abstract:

Path Attributes in the BGP-4 protocol (RFC 4271) carry data associated with BGP routes. Many of the Path Attributes carried in BGP are intended for limited scope deployment. However, the extension mechanism defined by BGP that carries these attributes often carries them farther than necessary, sometimes with unfortunate results.

This document defines a mechanism using BGP Capabilities (RFC 5492) that permits eBGP speakers to determine what Path Attributes should be permitted to cross external BGP routing boundaries.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-haas-idr-path-attribute-filtering/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-haas-idr-path-attribute-filtering-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-haas-idr-path-attribute-filtering-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list -- [e-mail] To unsubscribe send an email to [e-mail]

_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.