On Nov 15, 2011, at 6:39 PM, Pradosh Mohapatra wrote: > Can you describe specific concerns you have with using extended community? > It does work with confederations.
Confederation in this context was referring to the _current inability of BGPSEC to natively accommodate AS confederations, or IBGP in general, for that matter, where Member-ASes commonly apply 'policy' at Member-ASBRs and no implicit transitive trust relationship would exist. While I don't want to overly conflate this function with that issue, it does intersect in that Opaque Extended Communities already assume a transitive trust relationship and in a world where the value of an Opaque Extended Community would be used to convey the validation state of a prefix an IBGP speaker has no way to validate the semantic integrity of the string. Its essentially what I have today, and into the future secure routing should enable me to verify this. > Do you have alternatives in mind for incremental deployment case? I'm not sure what you mean by "incremental deployment" here, are you referring to the case where it gets enabled and deployed but no IBGP speaker applies policy based on the validation state until all IBGP speakers support prefix origin validation capability as defined in the document? I suspect this is what S3.1 is implicitly conveying. I'm not convinced incremental deployment of the validation state processing capability within IBGP should be supported. The current Deployment Considerations section makes me uneasy in that it's essentially saying "if you don't support this Opaque value and decision algorithm modification as prescribed in S.3 then you should develop static policy maps that influences the best path selection *the same way* as what would have been enabled by an implementation of this extension." -- i.e., that may not even be feasible in some operating environments and the complexity it presents is likely conducive to misconfiguration that introduce forwarding loops in the network. Does that make sense? -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
