Tobias,
On 4/5/26 10:31, Tobias Fiebig wrote:
- I have flagged a spot in the diff where I couldn't quite understand
the intention of the English (see XXX JMH)
I now clarified an restricted that, aligned with the cited document:
Routes carried by BGP <bcp14>MUST NOT</bcp14> carry RPKI validation
states in transitive BGP path attributes <xref target="I-D.ietf-
sidrops-avoid-rpki-state-in-bgp" format="default"/>.
https://github.com/ichdasich/draft-ietf-grow-bgpopsecupd/commit/14bc065a43922cd28f4564731bcfd9c6de05a6d9
This addresses my concern.
- There is a claim about treating unknown path attributes as
"immutable". We've hit an inflection point among operators where
this
stance is not universal. For some discussion (kindly ignore the
enforcement mechanism), see
https://datatracker.ietf.org/doc/draft-haas-idr-path-attribute-filtering/
.
The working group should make an active decision whether this remains
a BCP.
Given the objective of the document, I would argue that 'stance is not
universal' requires a more open text, highlighting this.
I picked some things from draft-haas-idr-path-attribute-filtering which
might accomplish this; What are your thoughts on that?
Transitivity of attributes unknown to an operator cannot be
established. Treating such attributes as immutable enables incremental
deployment of new BGP features, while processing unknown attributes may
harm availability if the eBGP speakers used by an operator are unable
to handle the attribute safely. Hence, operators <bcp14>SHOULD</bcp14>
carefully assess the tradeoff between incremental deployment and BGP
security for their network.
I'm clearly fine with this. :-)
-- Jeff
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
