> > Troll Bot <[EMAIL PROTECTED]> keeps mentioning PPLB. May be some people > > more knowledgeable about BGP than I am will explain to me why PPLB is > > such a new issue for anycasting? > > I have no idea how new this is, but I have to admit I'm slightly > worried. Not to the degree Dean seems to be, though. > > It is true that if you turn on load balancing over multiple paths in > BGP and then per packet load balancing between several links, packets > belonging to one session can end up on different anycast instances.
Actually, no. That would be a disaster. Noone would ever be able to turn PPLB on under those conditions, since anycast and multihoming both produce multiple candidate paths. BGP's default (as I said in my earlier reply) is to only install the best path, not all of them. (At least on C and J gear.) Doing multipath BGP "safely" would require end to end metrics beyond just aspath-length. That's why multipath BGP is not the default. Given the state of the BGP technical community, I think the next likely evolution will be some kind of flow setup/teardown negotiation and a lot more state in routers, rather than research into the kind of end-to-end metrics that multipath BGP would require. > ... > Now the part that worries me is what's happening in .org. They only use > two addresses in the delegation from the root, and both are heavily > anycasted. This makes no sense at all as it effectively hides all but > two of the .org TLD servers while there are no reasons at all for not > making at least have a dozen others visible. End-user impacting issues > with this have been reported (but have predictably been almost > impossible to reproduce) but the situation persists. If you can make a strong and cohesive argument about this, ICANN would listen. (I know that UltraDNS would be happy implementing whatever the DNS community felt was the strongest configuration, and I think ICANN would say the same.) > Fortunately, the root operators have more sense (or inherited a better > situation). Still, I'm not entirely comfortable with the fact that each > of them seems to make anycasting decisions on their own. Then you can rest easier, because I'm here to tell you, we didn't. > Anycast has many things going for it as it allows root servers to be > installed in many more places than could be done otherwise, but it's also > risky as more and more root servers seem to be in the same place from any > given viewpoint, and especially from not so well connected viewpoints. The rootops don't have a motto, and that's too bad. If it were allowed, the motto I would urge to be taken up is "strength through diversity." The fact that each rootop goes only where they're invited (as in F-root's case) or they can afford to go (as in I-root, J-root, M-root, and K-root's cases) is *wonderful* in terms of root server system survivability. In the cases where this means a bunch of root servers all anycast in the same metro, two *great* things happen: (1) attacks and failures against a single root "letter" don't affect all root servers anycasting in a metro; and (2) attacks against the entire root server system (all letters) have to be much stronger in order to upstream-congest every root server instance in any given metro. In the cases where this means only one root server anycasts from a given metro, it's still a lot better than no anycast in that metro at all, and it may reflect the best use of available resources at a particular point in time. > Problems such as congestion and BGP blackholes or (temporary) BGP > instability can then impact most or even all of the root servers. (Only > for some places connected to the net, though.) So I feel it's very > important to have a reasonable number of root servers that are NOT > anycast. Preferably, those should be in locations that are far apart. Without speaking for any of them, and without telling you who they are, I will say that several rootops feel as you describe, and the likelihood is very high that your preferences will be followed in this matter. -- Paul Vixie . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
