On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote: > 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)
I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same? There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this... For example, I'm a BGPSEC speaker. In the BGPSEC bits I see: AS1 AS2 AS3 AS4 AS5 All this checks out, the magic crypto says all is happy, etc. but, in the AS_PATH I see: AS1 AS 100 AS17 AS6 What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons? Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle. This idea extends this by simply not allowing the error condition to occur. You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases... W > >> 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 > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
