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?


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.

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.)

These bugs were also observed in Zebra OSPFv3. I think OSPF WG has the
responsibility to point them out in the standards.

Besides, I noticed that the anycast route calculation can be done
without changing SPF tree. Of course, it is only an efficient
implementation. However, RFCs (e.g. OSPFv3) often provide guidelines
for better implementation so that vendors can implement them easily.
Right?


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.

--

Yue Wang

_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to