Dear Acee and Joel, Yes, I was wrong. Thanks a lot.
The last thing: please 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. I hope OSPF WG would define it clearly for anycast. Thanks a lot for your discussions so far. On 12/23/06, Acee Lindem <[EMAIL PROTECTED]> wrote:
On Dec 22, 2006, at 9:26 PM, Yue Wang wrote: > On 12/22/06, Acee Lindem <[EMAIL PROTECTED]> wrote: >> >> On Dec 22, 2006, at 1:05 AM, Yue Wang wrote: >> >> > On 12/22/06, Acee Lindem <[EMAIL PROTECTED]> wrote: >> >> Hi Yue, >> >> On Dec 21, 2006, at 9:08 PM, Yue Wang wrote: >> >> >> >> > 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. >> >> > >> >> >> >> <pruned> >> >> >> >> > >> >> > >> >> >> > 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. >> >> >> >> Independent of address type (unicast or anycast), you take the >> >> shortest path. What are you proposing for anycast that deviates >> from >> >> this >> >> premise? >> > >> > I simply maintained a route list for each anycast address so >> that the >> > 1-hop route will not be flushed by the 2-hop route in the above >> > example. >> >> Assuming the 1-hop route is lower cost, this shouldn't be necessary. >> Look at section 3.8.1 in RFC 2740. Every router advertising anycast >> addresses simply advertises the closest anycast address. How this is >> accomplished is an implementation specific matter and depends how >> the anycast addresses are discovered - is that what you're >> trying to accomplish with your route lists? >> > > No, my point is: the 2-hop route will update the 1-hop route because > the current OSPF thinks it newer, if we simply treat anycast as > unicast. OSPF takes the shortest path - NOT the newest. I think you are confusing a bug in a specific implementation or a bug in an implementation's linkage to anycast advertisement to how the protocol actually works. > Note that an anycast address can be on multiple locations. > And I use the anycast route list to maintain this information. When you calculate your intra-area SPF, you should consider all applicable intra-area-prefix-LSAs. This way, if an anycast prefix is reachable from multiple vertexes in in your Shortest Path Tree (SPT), you'll still choose the path to the one which is closest. Again, I'll simply point you to RFC 2740. Acee > > > >> Thanks, >> Acee >> >> > >> >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > regards, >> >> > wang yue >> >> > >> >> > _______________________________________________ >> >> > OSPF mailing list >> >> > [email protected] >> >> > https://www1.ietf.org/mailman/listinfo/ospf >> >> >> >> >> > >> > >> > -- >> > regards, >> > wang yue >> >> > > > -- > regards, > wang yue
-- regards, wang yue _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
