Re: [sidr] [Idr] No BGPSEC intradomain ?

[Robert Raszuk <[e-mail]>]

 > So... we can send the data along, but in the case of BGPSEC speakers
 > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

So far I have always heard that BGPSEC is just providing the hint to the 
operator and does not change how BGP works.

Here you are saying that now AS_PATH length should be calculated from 
completely different (and optional) attribute.

You are also saying that now multipath code which computes which path 
are eligible to be multipath needs to look/parse/decrypt totally 
different attribute.

All BGP monitoring tools need to be upgraded to now understand BGPSEC 
attribute too. And surprise .. here BMP will not convert it like it will 
to "legacy" speakers.

You may think that if we stuff all "data" in the new attribute and drop 
the other one everything else will work. This may be so in theory, but 
it is clearly not a case in practice.

Regards,
R.


> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<[e-mail]>  wrote:
>> Anyhow my doubt has been answered and I stay by my opinion that not sending
>> AS_PATH and AS4_PATH is a terrible idea.
>
> So... we can send the data along, but in the case of BGPSEC speakers
> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> Carrying extra bits isn't actually helpful is it? (the implementers
> drove the design decision here I believe)
>
>> 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.
>
> is it helpful for the folks that write bgp code though? "Hey, you will
> need to re-synthesize the as-path at sec->non-sec boundaries. you need
> to also create sec-path at none->sec boundaries."
>
> -chris
>
>