Re: [sidr] No BGPSEC intradomain ?

[Robert Raszuk <[e-mail]>]

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 :-)))