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

[Christopher Morrow <[e-mail]>]

On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <[e-mail]> wrote:
>
>> 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.

ok.

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

to the operator (and the implementation) there's not a difference....

> 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.

I didn't say anything about multipath. I presume it'd do the right
thing with the meta-attribute it knows about way deep inside bgp
processing on platforms that do bgp processing.

> 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.

sure, they'd have to do that anyway, or they just are
'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
other words, tomorrow for them is the same as today, the world keeps
on going round.

> 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.

maybe? so far you've not convinced me... you can feel free to keep
trying though? email is cheap.

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