On May 29, 2012, at 2:24 PM, John G. Scudder wrote: > 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).
In an offline follow-up with Robert Raszuk, he pointed out that when one applies a knob that results in an AS_PATH that can't be represented as a BGPSEC_Path_Signatures [*] there is a third option, that of downgrading from BGPSEC to unsigned BGP. That is to say, you convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to the AS_PATH, and propagate the route with the AS_PATH and not the BGPSEC_Path_Signatures. This is functionally equivalent to "in all such cases, the route fails validation" but is more straightforward and seems to make a lot of sense: everything that can be represented signed, should be. If you insist on doing something that can't be signed, you can fall back to unsigned BGP and hope for the best. This leaves me feeling a little more sanguine about the drop-the-AS_PATH idea, although I still think some more attention to enumerating what knobs will fall by the wayside is advisable. --John [*] The name of this attribute makes for awkward prose since it has no natural singular. How about calling it BGPSEC_Path_Signature instead? Or Signed_Path or Signed_AS_Path sans brand name? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
