# ... # # You are missing the point. # # Currently multihomed sites have multiple path entries in the routing table # for a specific multihomed prefix. # # Instead of having multiple paths, you would have multiple location records # in DNS. (Which are A records and any possible reordering by round robbin is # not part of the actual path selection algorithm and which are associated # with indentifiers though a standard to be designed as part of the new # protocol.) # # The process of how you select which one to use (and what knobs you have for # tuning) is a design decision, the same way it was with BGP and OSPF. yes. we called this the A6/DNAME/SRV approach. # * You throw away real topology information and rely on latency (or # whatever), and using latency doesn't work because it doesn't allow traffic # engineering according to policy. (Who said you have to give everybody the # same set of locators? Paul might say ewwww. ... some applications need best-latency. others, best-isochrony. still others, highest-bandwidth. i don't think the network should have a single policy, but i don't think every application should have to test for latency, isochrony, and bandwidth toward each potential endpoint before it selects one. can't we collect this information as "hint state" and make it available to applications who will then make their decision privately? or failing that, just use SRV? # FWIW, if you want the ability to tell different peers different answers like # with BGP you will need the ability to give different answers with the new # protocol.) that's how i envision that the NSID option would be used from the client side, though i recognize that this will make ed lewis's head explode, that's OK too.