On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow <> wrote: > On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz > <jakob.he...@ericsson.com> wrote: >> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote: >> >>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <rob...@raszuk.net> >>> 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) >> >> I think it was along the lines of: >> 2 AS paths will create the opportunity for an error if they differ >> and we don't want to go around the error-handling block again. >> >> I agree with Robert. Today, there are many tools that interact >> with BGP messages. If the AS_PATH disappears, they will all break. > > aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker. > If the tools in question are updated to understand BGPSEC (and > negotiate that capability with the bgp speaker) then ... they'd > obviously have to know how to deal with this situation, right? > > -chris
This will be a hurdle on the way to adoption. I can see the network operator now: "My tools won't run. Let's not turn BGPSEC on today". The error-checking excuse looks real lame to me. -- Jakob Heitz. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
