[Idr] BGPSEC proposal to drop AS_PATH [was: Fwd: [sidr] request for agenda items for interim meeting 6 Jun]

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 sidr@ietf.org.

(See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.)

--John

Begin forwarded message:

> From: "John G. Scudder" <jgs@juniper.net>
> Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
> Date: May 29, 2012 2:21:33 PM EDT
> To: Matt Lepinski <mlepinski@bbn.com>
> Cc: "sidr@ietf.org list" <sidr@ietf.org>
> 
> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr