Hi, Just few comments:
Ah I just realized that you mention SAFI here, but when writing the draft I > was thinking about an AFI. > To define a new MP_REACH you need both AFI (two octets) + SAFI (1 octet) RFC 4760 section 2. interface, so it does not need to be advertised in band. Now you mentioned > it though, it seems that actually using the proper AFI set (e.g. IPv4 or > IPv6 etc) and then using a new SAFI to carry the looking glass address > would be an elegant design too. > You mean that address of the same LG would be send over AFI=1/SAFI=LG to send IPv4 address and AFI=2/SAFI=LG to send given LG's IPv6 address ? Looks ok if you want to really negotiate two capabilities for that. > For example, I can imagine looking glass reachability can use MP_REACH > and then when the looking glass is no longer reachable it can be withdrawn > with MP_UNREACH, without needing to add that complexity into the looking > glass message itself. > Typically in BGP we try to shield the world from say switch flap given server is connected to. Sending host routes all over the place - while doable - I am not sure will be best for protocol stability. I am still not sure what is wrong using DNS for this type of discovery. If I were to tackle this problem I would start with DNS. Say your draft will define a well known name ASN-LG (example: 6939-lg) . Then each AS willing to play the game will just push the current IP address(es) into such well known DNS record so anyone can get seamlessly to their looking glasses pool. Done. And this does not require any extension to BGP :) Moreover such draft can be worked on and published by GROW WG too. Interesting, I hadn't considered this type of architecture where there is a > centralized looking glass that is fed from the border routers. > Well I am sure there is a lot of such collectors in the wild. Maybe we also have as you say just type of jump hosts where under the hood when you query LG a box get's to production box to get the info live. And even so maybe it would log into POP's RR not ASBR so the requirement of best external still applies. Thx, R.
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
