> 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<[email protected]> 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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
