Dear Acee and All, The last thing to raise your attention (see below).
Thanks a lot for your advice and discussion. Look forward to the future anycast standard in OSPFv3. On 12/21/06, Acee Lindem <[EMAIL PROTECTED]> wrote:
Hi Yue, Yue Wang wrote: > Hello, dear OSPF WG. I am the main author of this draft. > > > First, I like to talk about the motivation of this draft. IP anycast > is a vision of next generation networks. As IPv6 is not widely used > yet, it is promising for OSPFv3 to provide anycast in future. In my > design, I take the minimalist approach so that vendors will benefit > from anycast immediately. > > > Second, I describe my technical considerations as follows. > > 1) Anycast address > > My draft followed the definition of IPv6 anycast addresses (see RFC > 4291). So there is an address aggregation here. > Besides, it is better to identify anycast addresses from unicast > addresses. For example, we can have new route calculation for anycast > addresses. We can have additional security for anycast addresses as it > is more vulnerable to attackes. This address identification is more > flexible and does not disturb OSPFv3. So, Why not? I'm not saying that it's not possible that there are different things one may want to do with anycast addresses. What I'm saying is that, IMHO, there is nothing in this draft that motivates processing IPv6 anycast addresses differently from IPv6 unicast addresses. One strong reason for not doing this is that we only have 3 prefix bits left. So, until we evolve to a TLV based OSPFv3, we must use these bits wisely. > > > 2) Anycast Route Calculation > > I agree that the anycast route calculation is similar to the unicast > case. But there is a bug noticed in Case 1 in Sec 3.5.1 if we consider > anycast the same as unicast. The last comer (anycast server) will > replace the previous route entries (in the logic of unicast). As a > result, there is ONLY ONE route entry for a given anycast address. > This means all client requests will go to the same anycast server. Not in any of my implementations - if you calculate ECMP (Equal Cost Multipath) routes, most implementations will distribute flows (based on source/dest or some longer tuple including other flow qualifiers) across the equal cost routes.
Note that anycast routes are not necessarily equal cost. Suppose there are 2 anycast routes coming into a OSPF network in sequence: the first is 1 hop, the second is 2 hop. As a result, ONLY the 2-hop route stays in the network, if we treat anycast as unicast. That's why I differentiate anycast from unicast.
> > > And Case 2 in Sec 3.5.1 pointed out the timing problem when the best > anycast server leaves. If anycast is considered the same as unicast, > OSPF will simply remove the(ONLY ONE) route entry for a given anycast > address and find another anycast server until the next refreshment. > (Note that OSPF refreshes every 30 minutes by default.) Your section 3.5.1 has left me confused. When anycast servers join or leave the network a mechanism is needed to determine this has occurred. One mechanism would be for the anycast servers to run OSPFv3 themselves and respectively advertise or withdraw the corresponding IPv6 anycast address. If an anycast server becomes unreachable, the advertised anycast addresses will become unreachable when the server does. > > These bugs were also observed in Zebra OSPFv3. I think OSPF WG has the > responsibility to point them out in the standards. The OSPF WG isn't responsible for Zebra or any other implementation. You might want to try the Zebra mailing list: http://www.zebra.org/mailing.html > > Besides, I noticed that the anycast route calculation can be done > without changing SPF tree. Of course, it is only an efficient > implementation. I can assure you that you are not the first to recognize this. In fact, in the RFC 2740 respin, I added text similar to what is in RFC 2328. From http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-13.txt This specification does not require that the above algorithm be used to calculate the intra-area shortest path tree. However, if another algorithm or optimization is used, an identical shortest path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification. > However, RFCs (e.g. OSPFv3) often provide guidelines > for better implementation so that vendors can implement them easily. > Right? I believe there are many different ways which the SPF can be optimized without impacting compatibility or requiring protocol changes. I don't think we want to start documenting them all in the OSPF WG. Anyway, I don't believe you've demonstrated the technical requirement for special processing of IPv6 Anycast addresses and think possibly we've spent enough time on this. Thanks, Acee > > > 3) Inter-Area and Inter-Domain Anycast Route Selection > > This part is not important. I just give a reasonable option to select > Inter-Area and Inter-domain anycast routes. We can further improve it. > > > In sum, this draft provides one of the most efficient solutions of IP > anycast routing in OSPFv3. Thanks a lot for your advice. >
-- regards, wang yue _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
