Hi Yue,
Yue Wang wrote:
Dear Curtis,
In the above example, the 2-hop route can update the 1-hop route because
the current OSPF thinks it newer (Sec 3.4.2, RFC 2740), if we simply
treat anycast as unicast.
Section 3.4.2 is talking about the link state database, not routes per
se. As Acee mentioned, it's the cost of a route that matters, not the
age of any particular lsa.
Note that an anycast address can be on
multiple locations.
And I use the anycast route list to maintain this information.
A unicast prefix can also be reachable from multiple points on the
shortest path tree. In fact, I fail to see why you think that anycast
routes need special treatment in this regard. The only difference is
that when a unicast prefix is reachable from multiple locations they all
(presumably) reach the same network segment, whereas multiple anycast
addresses can be used to reach different hosts offering a common service.
A correct implementation of the existing ospfv2 or ospfv3 protocols
should handle this just fine.
Besides, you can look at Case 2 section 3.5.1 in my draft. There is
only one route (e.g. the 1-hop route) for a anycast address maintained
by the current OSPF. If the route is withdrawn due to some reason
(e.g. server power off or network disconnection), the alternative
route (e.g. the 2-hop one) will be rediscovered until the next LSA
refreshment (Sec 12.4, RFC2328). Note that the default LSRefreshTime
is 30 minutes.
This sounds like a bug in a particular implementation, or a
misunderstanding of how ospf works. In ospf routes are not advertised
or withdrawn, lsas are. Routes are computed from the link state
database, which should have a complete description of the topology at
any given point in time. If an lsa is removed, but a (higher cost) path
exists in the topology, it will be installed as soon as spf is run. LSA
refresh has nothing to do with this.
Regards,
Paul
This is my key point. I think OSPF would define it clearly for anycast.
Thanks a lot for your discussion.
On 12/22/06, Curtis Villamizar <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>
"Yue Wang" writes:
>
> 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.
The point of this exercise was initially to determine whether there
was work group support form making draft-wang-aospf-00 a WG document.
There does not seem to be support for this.
<big snip>
> 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.
You seem to have repeated this characterization of how unicast works a
few times now. Second route does not replace the first if the first
is lower costs.
IMHO You have not demonstrated and need to change OSPF to support
anycast. Acee had pointed out how it is done today (in rare instances
where it is done at all) and you have not convinced anyone in the WG
that there is an advantage to you approach.
More important you have not convinced anyone to support this draft as
a WG item. Perhaps Acee has a tally.
No amount of vigorous assertion on your part is going to change that.
Since there are few people speaking out, none for, only a few against,
maybe the question can be posed at the next WG meeting. OTOH If more
people speak out against this as a WG item between now and then, the
draft should be considered a dead item.
Curtis
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
