Hi Les, If someone (not necessarily you) wants to write up any of these proposals > then we (the WG/Routing Area) could have a meaningful discussion about such > alternatives. >
Since you keep asking for a write up on an alternate solution(s) and since you clearly stated that your connectivity restoration goals is in seconds please kindly consider the below solution. Keep in mind that this solution has shipped around 2003-2004 and is used all over the world in properly configured networks. * In an area PEs peer with IBGP sessions to RRs * RRs are (in vast majority of cases) part of IGP hence hear the same flooding as would local area ABRs * RRs deploy next hop tracking hence they can react in an event driven fashion to PE down events * RRs then either trigger withdraw or implicit withdraw of service routes (*1*) * Those are received only to those ingress PEs who care via RTC filtering Without doing anything else you get connectivity restoration in seconds today zero code change, zero protocol extension, zero noise. (*1*) Now if one would like to further optimize this step it is really easy to either withdraw all prefixes describing say all routes on the PEs or simply withdraw previously advertised PE next hop. One message just like PULSE except without trashing IGP and targeted to those who need it. I do not see why the optimization (*1*) would not work out of the box. BGP natively uses recursion so service route can resolve via another BGP route then via IGP summary. Hope this helps to understand my suggestion. I also do not see this needs to be a draft or RFC as this is basic BGP 101. Cheers, R. PS,. I do realize especially after you said that you want to improve the situation where BGP reacts only after 3 x 60 sec keepalives to trigger action that some networks may disable next hop validation on RRs. Some may not even want to run IGP on service RRs. Sure this is ok in some topologies. But in such cases there are other ways to detect state of local area PEs on such RRs.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
