Hi Warren, Many thx for your comment. It clarifies my question very well.
So you are effectively confirming that as long as there is one ASBR, one RR or one confederation edge which does not yet speak BGPSEC anywhere in the UPDATE path the peer sending to him over ebgp or ibgp will convert BGP_SIGNED_PATH to AS_PATH/AS4_PATH attributes and from now on that path will remain unsigned.
Likewise each RR/confed peer will need to convert BGP_SIGNED_PATH to set of AS_PATH/AS4_PATH attributes when sending to "legacy" BGP speakers.
I do not know what is the rationale for recommendation of not sending mandatory BGP attributes any longer even if their content could be already contained with new BGP_SIGNED_PATH attribute.
Anyhow my doubt has been answered and I stay by my opinion that not sending AS_PATH and AS4_PATH is a terrible idea.
Perhaps one could depreciate it in 20 years when world is upgraded to BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not helpful for any even potential BGPSEC deployment model.
Best regards, R.
Nope, not assuming that at all. The devices on the edge of the AS (those that do eBGP) need to speak BGPSEC, and if the AS is small, they will probably be in a full mesh. If the AS is not small (or has planned ahead :-)) they will talk to a RR or be part of a confed. If they talk through a RR (or set of RRs), these should also speak BGPSEC. If you prefer the confed flavor of scaling, well, the devices on the edge of the confed are kinda like eBGP speakers, and inside the confed they all mesh (or talk through a RR (see previous :-)))
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
