Subject: [OSPF] [AOSPF] Anycast Extension to OSPFv3 (draft-wang-aospf-00) - Authors' Technical Considerations

From: "Yue Wang" <[email-masked]>
Date: Sat, 16 Dec 2006 19:05:08 +0800

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-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "Abhay D.S" <[email-masked]>
Date: Wed, 20 Dec 2006 12:16:56 +0800

hello yue wang,
Personally appreciate your effort and score well with your points.

Suggest you to make this draft as an anycast implementation report rather
as an alternative to existing mechanism.

But, it is also suggested you might do some R&D with valid results as
to how OSPFv3 original extensions might fare with your version of 
anycasting.

Remove, all sections of competition with OSPFv3 existing mechanism :-)

Promote this anycasting as a standard in your current network. Connect
other campus networks if you are aware of with the same technology to 
measure
the way it is received and performs.

Warm Regards,
Abhay

---

From: Acee Lindem <[email-masked]>
Date: Wed, 20 Dec 2006 13:34:27 -0500

Hi Yue,

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

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

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

---

From: "Yue Wang" <[email-masked]>
Date: Fri, 22 Dec 2006 10:08:07 +0800

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.

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

-- 
regards,
wang yue

---

From: Acee Lindem <[email-masked]>
Date: Thu, 21 Dec 2006 21:28:54 -0500

Hi Yue,

> future anycast standard in OSPFv3.

<pruned>

> 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?

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Fri, 22 Dec 2006 08:52:28 -0500

On Dec 22, 2006, at 1:05 AM, Yue Wang wrote:

> On 12/22/06, Acee Lindem <[email-masked]> wrote:
>> Hi Yue,
> 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?

Thanks,
Acee

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Dec 2006 10:13:25 -0500

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

> 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

---

From: "Yue Wang" <[email-masked]>
Date: Sat, 23 Dec 2006 10:26:16 +0800

> 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.  Note that an anycast address can be on multiple locations.
And I use the anycast route list to maintain this information.

-- 
regards,
wang yue

---

From: Acee Lindem <[email-masked]>
Date: Fri, 22 Dec 2006 22:10:30 -0500

On Dec 22, 2006, at 9:26 PM, Yue Wang wrote:

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

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

---

From: "Yue Wang" <[email-masked]>
Date: Sat, 23 Dec 2006 11:24:13 +0800

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.  Note that an anycast address can be on
multiple locations.
And I use the anycast route list to maintain this information.

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 is my key point. I think OSPF would define it clearly for anycast.
Thanks a lot for your discussion.

-- 
regards,
wang yue

---

From: "Yue Wang" <[email-masked]>
Date: Sat, 23 Dec 2006 11:35:21 +0800

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.

-- 
regards,
wang yue

---

From: Paul Wells <[email-masked]>
Date: Fri, 22 Dec 2006 21:56:41 -0600

Hi Yue,

Yue Wang wrote:
> 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
> 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.

> refreshment (Sec 12.4, RFC2328). Note that the default LSRefreshTime

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Dec 2006 23:00:54 -0500

> And I use the anycast route list to maintain this information.

I assume that you are talking about inter-area or ASE routes since OSPF
is LS and exchages topology, not routes within an AS.  It could also
be stubs within an AS.

(Excuse the OSPFv2 centric terminology but I find stub, inter-area,
and ASE simpler than vertex attached LSAs or whatever).

For a stub route, if a the router (vertex) is adjacent to some
non-trivial topology (served by RIP2 <gag> for example) the router
advertises the *best* route it has to any given prefix, not the most
recent.  If a 2 hop stub is advertised by a router then it is because
it is now the best route (for example, the 1 hop route may have gone
away due to a link failure that was learned by RIP2).

For an inter-area route the same applies.  If a two hop (or higher
cost we should say) route is advertised by an ABR then it is because
that is now the best route, not because it is the most recently used.

Save applies to ASE.

If two routers advertise the same stub (same prefix), then in OSPFv3
terms there is one LSA for each of the two vertex in the topology.
>From any router in the topology the closest one is the one who's sum
of cost to reach the vertex plus stub cost is lowest.  This is not
uncommon.

The same applies to the same inter-area or ASE advertised by two or
more ABR.  This happens all the time (to the extent ASE is used at
all) since multiple ABR are used for any given area for redundancy.
Each ABR advertises the *best* not the most recent route.  Within the
area there is one LSA per ABR (vertex) advertising this prefix.

You may be confusing OSPF with some other routing protocol.

Your characterizatin of how OSPF works is incorrect.  If you start out
with an incorrect fundamental premise, you are likely to reach a false
conclusion.  That seems to be the case here.  You've made an incorrect
assumption about how OSPF works and concluded that ODPF needed to be
changed to support what you want to do.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Dec 2006 23:22:26 -0500

> Thanks a lot for your discussions so far.

FYI - OSPF LSRefreshTime is related to the refresh time for a given
LSA ***if nothing changes*** in that LSA.

Propogation of the addition or withdrawl of a route is propogated more
or less immediately.

In the case of a network disconnect affecting a stub or link, a router
adjacent to the disconnect would propogate an LSA change immediately.

In the case of a router going down, the routers adjacent to it would
immediately propogate LSA changes withdrawing links to it.  The down
router would be isolated (disconnected, partitioned) from the
topology.  Once isolated anything in the way of stubs, inter-area or
ASE would be irrelevant even if not immediately removed by aging.

By "more or less immediately" I mean the following.  In a quiescent
network, origination of a new LSA will occur within link failure
detection time with for framings such as SONET is typically on the
order of 10msec.  In a hypothetical case where the network is unstable
and already propogating lots of LSA changes, origination and
propogation could be delayed but only to the extent needed to limit
transfer on information between neighbors.

Maybe you should learn more about how OSPF works or check with someone
who thoroughly understands OSPF before further lecturing the work
group on what is wrong with it.

There is no need draft-wang-aospf-00 and it should not be a WG item.

Curtis

---

From: Acee Lindem <[email-masked]>
Date: Sun, 24 Dec 2006 06:49:17 -0500

Hi Yue,

I can't explain any better than Paul and Curtis already have in their  
postings.
The problem you're seeing is either in you're OSPFv3 implementation or
in the anycast address discovery and advertisement in the OSPFv3 router
originating the intra-area-prefix-LSA. Note that the latter is  
outside the
scope of the OSPFv3 protocol.

Thanks,
Acee

On Dec 22, 2006, at 10:35 PM, Yue Wang wrote:

>> >> >> >> > 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
>> >> >> > sequence: the first is 1 hop, the second is 2 hop.  As a  
>> result,
>> >> >> ONLY

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 24 Dec 2006 10:23:20 -0500

In message <[email-masked]>
Acee Lindem writes:
> postings.  The problem you're seeing is either in you're OSPFv3
> implementation or in the anycast address discovery and advertisement
> in the OSPFv3 router originating the intra-area-prefix-LSA. Note that
> the latter is outside the scope of the OSPFv3 protocol.
>  
> Thanks,
> Acee

Hi Acee,

Yue has shown remarkable good character in readily accepting that
OSPFv3 may already accomodate the needs that he was addressing in his
draft.  I look forward to future contributions from him.

It does sound like he has tried to make use of anycast and run into a
problem of some sort.  Having myself only worked with IPv4 and OSPFv2
I hope that I have not missed any of the details of IPv6 address
discovery that may be at issue or some other IPv6 specific detail.

I've used a form of anycast with IPv4 and it was not without problems.
One problem we ran into was with the use of TCP and ECMP.  Routers
outside of our control did per packet BGP ECMP (rare) or periodically
reseeded the BGP ECMP hash used for src/dst split (common).  Using an
unmodified TCP application didn't work well.  Some means of
redirecting to another address on the box was needed when the initial
request was processed to allow state to be retained and "latch in" to
the same server for the duration of a session requiring state.  For
example, for HTTP today a simple redirect to another address on the
server was adequate.  Redirecting other applications would not be as
simple.  This was at a time when DNS servers did not round robin the
A-records in responses and hosts always went to the first listed.  As
I remember, it also predated widespread browser support for a fully
transparent HTTP redirect.  Eventually other techniques were used
rather than this form of anycast.  This was for a major web site (not
AOL) on a major provider (yes, it was ANS), so it was a rather large
scale early real world use, or attempted use, of anycast.

My instinct is that the same should work for IPv6 just as well (or
poorly) but I don't have any experience to back that up.

Curtis

---

From: "Abhay D.S" <[email-masked]>
Date: Mon, 25 Dec 2006 10:35:37 +0800

hi yue wang,
Who has written the perfect first draft ?

When a draft is dropped at the interface, you just need to re-transmit
it a newer and better version.

Just reflecting on Curtis's suggestions.....

It seems reasonable to "not" write off your implementation experience in 
your draft as "dead".

As I suggested earlier, you might cut out the bug reports of your 
implementation and make your
draft as an implementation report as against the standards.

Here is a list of suggestions again: What might be the frame work of 
your draft.

1) Treatment of anycast addresses separately, without any generalization.

2) An option to aggregate anycast only addresses.

3) De-aggregation of anycasting made simpler.(When there are no anycast 
routes, you might simply remove
    the aggregation.)

4) The universal truth of route calculation and its bugs about the next 
hop MAY not be mentioned( leave no
     room for reviewers to single out your draft based on this universal 
truth, (however you have gone a little wrong here)
     but who has written the perfect first draft ?).)

5) Make this draft as an "IMPLEMENTATION REPORT"

6) I would suggest you might think about inter-operating  with existing 
OSPFv3 mechanisms.

7) Single out the best practices that can be observed when using this 
extension of yours in anycasting.

Thanks and Regards,
Abhay D.S.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 28 Dec 2006 16:31:33 -0500

Hi Curtis,

Thanks much for participating in this discussion. Some comments
inline.

> draft.  I look forward to future contributions from him.

I wholeheartedly agree.

> poorly) but I don't have any experience to back that up.

I don't think the problems above warrant allocating an OSPFv3 prefix  
option
bit since most of them should be solved outside of OSPFv3.  For example,
I'd hope modern routers wouldn't default to per-packet ECMP forwarding.

I would hypothesize that the problems Yue, et al, encountered might
be in the OSPFv3 router injecting the anycast server prefix into the  
OSPFv3
routing domain. In this case, an OSPFv3 router in this capacity must
always advertise the lowest cost path to all reachable anycast servers
and only withdraw an anycast prefix when all servers are unreachable.

Thanks,
Acee

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Dec 2006 18:03:06 -0500

In message <[email-masked]>
Acee Lindem writes:
> option bit since most of them should be solved outside of OSPFv3.  For
> example, I'd hope modern routers wouldn't default to per-packet ECMP
> forwarding.

I don't think any router in use in a provider has done per-packet ECMP
in a long time but there is no telling what an off brand enterprise
sized router will do.  I recently encountered a DSL router that had to
be reboot to make any configuration change effective so bad design
even today is clearly possible.

Curtis

---

From: Naiming Shen <[email-masked]>
Date: Thu, 28 Dec 2006 16:50:47 -0800

> sized router will do.  I recently encountered a DSL router that had to

But this is not a problem with OSPF specifically. For dynamic routing
information on prefixes(including anycast route), one can otionally
add a sub-tlv/attribute/option-bit/opaque-option to signal a
"Do-Not-Per-Packet-ECMP" status of the route for BGP/ISIS/OSPF/etc,
and it's up to the implememtation to automatically disable the
per-packet loadsharing even it's explicitly configured on outbound
interfaces. Anycast route maybe only one of the applications
which can benefit with this trick.

- Naiming

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Dec 2006 20:58:18 -0500

> which can benefit with this trick.

Naiming,

Just about everything benefits from this trick.  If you do per packet
ECMP and the two legs have unequal delay you get out of order
delivery.  Real time applications are not at all fond of getting out
of order delivery.  TCP can have false triggers of the "fast restart"
mechanism which dramatically slow down TCP transfers.  Per-packet ECMP
has been proven in the field to be a very bad idea and the reasons it
causes problems are very well understood.

Per-packet ECMP should not be done under any circumstances.  Hash
based load split is circa 1986/1987 technology and works.  Use it.
See RFC2991 and RFC2992 for more detailed explanation.

It is unfortunate that routers still allow per-packet ECMP to be
configured.  At least providers know not to use this feature.  But we
can all be sure that somewhere out there someone ignorant of the
problems has enabled it.

Curtis

ps - Maybe the attribute semantics should be an "OK to per packet load
split traffic to this route" and all we have to do is never use it.  :-)

---

From: Naiming Shen <[email-masked]>
Date: Thu, 28 Dec 2006 21:32:44 -0800

Curtis,

> can all be sure that somewhere out there someone ignorant of the

I completely agree. Per-packet ECMP should not be used normally,
especially in provider's networks. But I did experience some cases
( a while ago ) on international links, there were some dominant
prefixes which led to very uneven link bandwidth usages due to flow
based algorithm. I think if folks in the routing area still think
things like anycast having this issue, then to signal this attribute is
useful and can be easily done; otherwise, there is absolutely no issue
in terms of anycast prefiexes(ipv4 or ipv6).

> split traffic to this route" and all we have to do is never use it.  :-)

Well, I don't think any one wants to set this flag in the first place;-)

- Naiming

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 29 Dec 2006 16:34:12 -0500

> in terms of anycast prefiexes(ipv4 or ipv6).

Maybe you missed the point.  The alternative to per-packet ECMP is not
per-prefix ECMP.  The hash based ECMP is only uneven if one or a small
number of host pairs dominate the traffic flow.

The only time that it mattered was when one dominante vendor didn't
offer hash based ECMP.  Per-prefix ECMP could be very uneven.  That
was a decade ago.

As far as anycast goes even with per-packet ECMP, everything is fine
if the application can send one packet that is returned with the
unicast address of an anycast server and use the unicast address from
then on.  This sort of probe can be repeated periodically if
necessary.  A load influenced anycast could be done within an IGP by
changing a cost but load might tend to slosh (all to one server, then
another).  What might work better for that would be an underlying
multicast with limited TTL (reaches multiple close servers, all of
which respond with their loadings).  Limited deployment of multicast
might be an issue and non-optimality of a multicast tree with fixed RP
might also be an issue.  There are plenty of tools in the tool box to
implement an anycast end user service without resorting to a new
address type and any change to routing.

The WG is OSPF and we're off topic at this point.

Curtis

---

From: Naiming Shen <[email-masked]>
Date: Fri, 29 Dec 2006 15:35:32 -0800

> offer hash based ECMP.  Per-prefix ECMP could be very uneven.  That

The majority of the router software now is certainly 4-tuple based hash,
but it does not mean in all the cases even load distribution can be
achieved.

> then on.  This sort of probe can be repeated periodically if

Sure, then this involves application awareness of anycast knowledge
and explicit configuration, it's error-prone to say the least.
That would certainly be a big restriction.

> The WG is OSPF and we're off topic at this point.

Agreed.

- Naiming