On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <[email protected]> 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<[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
