/* adding GROW WG as what is being discussed is much more operational topic then protocol extension */
Hi Jeff, Minimally, the proposal > covers an extended community that can be used by policy to say: > > Is my BGP Identifier present in this list of extended communities? > If so, I'm interested in it. I would like to comment on this point. Looks very innocent on the surface. *Point #1: * At the target deployment (as per current version of the draft) this means p2p distribution of information with inherently p2mp protocol. I do not think this is efficient. This is trying to use BGP as a policy/config push mechanism only because we do not have a good one yet in IETF. *Point #2: * I do have some sympathy (as noted already earlier) that if my extended community carries a prefix of BGP_ROUTE_IDs this could have potentially some useful applications**. But not a list of 1:1 mapped BGP_IDs. That list can get really long and neither processing it at each node now attaching it to each UPDATE is efficient. *Point #3: * As it has been noted already by Gert you can accomplish what you need today already with just adding a community and applying filtering on it. Of course modulo filtering on IBGP has its own risks, but those I assume are well understood. *Point #4: * As previously discussed, the draft should discuss handling withdrawals in all previously described scenarios. Not only in terms of implementation's ability to do so, but actual protocol correctness (case where UPDATE carries both MP_REACH and MP_UNREACH and node-target-ext-comm applies to the former not the latter. Splitting those into different UPDATE messages may not always be easy. *Point #5: * We are starting to get to the point of ingress inline signalling atomic filtering rules. Nothing wrong with this. But if so I would rather see this generalized. With that, Wide-Communities provide such ability. Why define more in encoding which by design is limited in size ? What if next would be a request to only accept UPDATE by a node which has a client belonging to a fixed IPv6 prefix ? Likewise why not enable sender to advertise routes to only a subset of upstream or peer ASNs ? We are really walking on the line of protocol inline encoding of policies vs mgmt driven policy/cfg push (both modulo current RTC like option). Comments more than welcome (before it's too late :), Robert
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
