IDR folks, BGPSEC (in the SIDR WG) includes a path attribute, BGPSEC_Path_Signatures, that substantially overlaps the semantics of AS_PATH. For reasons discussed in the forwarded note below, it proposes that updates carrying BGPSEC_Path_Signatures should NOT carry AS_PATH.
Since this would represent a fairly major change to the protocol, I wanted to make sure those not following SIDR were aware of it. Please cross-post any comments to [email protected]. (See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.) --John Begin forwarded message: > From: "John G. Scudder" <[email protected]> > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun > Date: May 29, 2012 2:21:33 PM EDT > To: Matt Lepinski <[email protected]> > Cc: "[email protected] list" <[email protected]> > > On May 22, 2012, at 5:46 PM, Matt Lepinski wrote: > >> Other than confeds are there any other potentially open issues related to >> the removal of AS_Path? > > (I think this just recapitulates what I said at the interim, but maybe it's > worth saying again for the list.) > > Philosophically, the thing that makes me worry the most is that we're cutting > out one of BGP's fundamental elements and replacing it with one which > provides only a subset of its semantics. Specific things missing include: > > - Confederations. But we are discussing ways to fix this. > - Extensibility to include new segment types. In principle this is a fairly > serious omission, but one can argue that new segment types can't be > introduced in practice, since existing implementations will treat them as > fatal errors. > > And actually, that's it for my list of specifics. I think we can check off > the "done, in principle" box for confeds. So the remaining issue is > extensibility. One may or may not find the "extensibility doesn't work > anyway" argument compelling, I'm not entirely sure *I* do. In any case, I > think this deserves a good airing before we commit. > > The other issue is one Shane already brought up on this thread -- the fact > that some of the more egregious AS_PATH editing hacks that exist in the wild > may not be supportable in the AS_PATH-less new world order. (Many of the less > egregious ones seem to be OK with appropriate pcount gyrations.) The pros and > cons are a bit slippery here since even if we continue to carry AS_PATH, if > the BGPSEC_Path_Signatures attribute can't represent the semantics of what's > in that AS_PATH, then validation will fail. But at least there's scope for a > network operator on the receiving end to tolerate the validation failure and > use the route anyway, if desired. In the case where there's no AS_PATH, the > data are just gone with no chance for appeal. > > It's also worth noting that leaving AS_PATH in would not be without cost. In > the cases where the content of AS_PATH is isomorphic to that of > BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH > clearly could have been left out. In the remaining cases, what is the > implementation supposed to do? It would be necessary to carefully specify. > The easiest cop-out would be to say that in all such cases, the route fails > validation. But I have a feeling that it's not that easy. Leaving AS_PATH out > reduces that particular maze of twisty passages, although it replaces it with > another: making sure it was really OK to axe AS_PATH to begin with (i.e., the > discussion above). > > I'm going to forward this to IDR to ensure that those who aren't following > SIDR are aware there's a proposal to phase out AS_PATH in favor of a > simplified replacement in BGPSEC. > > --John > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
