i) EID value space variation can result in triggered updates (e.g.permanently remove a contiguous set [j,..,m] of intermediate EID from anaggregate [a,..,z] results into two aggregates [a,..,i] and [n,..,z])
Well EID-prefix assignments will be relatively static. So I don't think we'll nearly have the flapping as the underlying network. And it seems the underlying network holds together fairly well with the issue you state above.
ii) with an overlay + out-of-band EID-to-RLOC resolution: the ETR once receiving a MAP Request does not check forwarding towards the RLOC it sends back to the ITR. the ITR once receiving a MAP Reply can not rely
Right, it doesn't because it is really hard to do that without building a complex system.
on egress RLOC as distributed by BGP to check its actual reachability.thus, resulting in false positive and the system will stabilize once the BGP RLOC will stabilize. As a consequence there is no improvement of theBGP local stability (assuming RLOC are completely aggregatable) or BGP global stability (otherwise).
This is no different than we have today. Are you saying what we have today is not sufficient?
iii) otoh you have the reverse issue, true negative. the BGP ALT is flapping preventing EID reachability while the RLOC are actuallyreachable via the BGP. to solve this BGP ALT must be at least as stableas the underlying BGP.
The ALT will not flap, I don't know why you think that. We have logical tunnels between eBGP peers that are very resilient since there is a robust network underneath it.
And since the EID-prefixes are added and deleted based on subscription based contracts, the flap rate is more like months and years, then what you are thinking.
Hope this clarifies that issue, -dimitri.
Well, not really. Dino _______________________________________________ GROW mailing list GROW at ietf.org https://www.ietf.org/mailman/listinfo/grow