> One minor issue that arose in making these revisions:
>
> Consider the case where you are creating a new update message somewhere
> within your AS (to originate a route to one of your own prefixes) and you
> are sending this new update message via iBGP to an internal peer. The
> document currently says that you omit the Secure_Path attribute (that is,
> the BGPsec_Path attribute is added by your edge router ... since the
> signature depends on the eBGP peer to whom an update is being sent).
>
> An alternative would be to include an 'empty' BGPsec_Path attribute ...
> that is, one with zero Secure_Path segments and zero Signature segments.
>
> If you think sending an empty BGPsec_Path is better than omitting the
> BGPsec_Path, please speak up now. (Both approaches seem perfectly fine to
> me.)
the iBGPsec originator creates an empty BGPsec_Path and sends the update
to
o whether the iBGPsec speaker might send a BGPsec_Path to a iBGP peer
is a per-peer decision determined at BGP_OPEN.
o an eBGP edge which has >0 peers who do not speak BGPsec has to strip
to non-speakers, which may be pretty common in early daze.
o iBGP originators which are not BGPsec enabled will need the eBGPsec
edge to create the BGPsec_Path anyway.
where's the win?
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
