Subject: Re: [OSPF] Anycast Extension to OSPFv3 draft-wang-aospf-00

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Dec 2006 23:27:41 -0500

I don't feel that there is any need for this draft.  IMO it should not
be adopted as a WG item.

Curtis

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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 14 Dec 2006 14:20:33 -0500

We've had a lot of discussion on the openness of the WG to new
proposals. I'd like to now focus specifically on the technical
aspects of this draft and as to why I don't think it necessary or
should become a WG document.

   Section 3.2 - I see this prefix checking not only as unnecessary but
   also contrary to the OSPFv3 design point that it runs a link as opposed
   to a subnet. Furthermore, I'd expect anycast services to be accessible
   via  /128 loopbacks on servers rather than an address bounded by
   a specific IPv6 prefix.

   Section 3.3 - This can be done for /128 unicast addresses with 
overlapping
   ranges (which is part of the base OSPFv3).

   Section 3.4 - An implementation can advertise or withdraw a /128 unicast
   prefix when the anycast addresss is learned or found to be unreachable.
  
   Section 3.5 - One can use the shortest path to a /128 unicast prefix just
   as well without any changes to OSPFv3.

     - The backup route handling in 3.5.1 is only needed if one can't do
        an SPF (or incremental SPF) fast enough. In any case, this 
requirement
        isn't specific to anycast addresses and we should not come up 
with a
        partial solution just for anycast addresses  This section 
certainly doesn't
        cover all the cases but rather than go there I'd direct you to 
the work
        on IPFRR being done in the RTG WG.

     - If I read Section 3.5 correctly, it implies that the OSPF 
precedence should
       be ignored and the closest route should be preferred for anycast 
irrespective
       of type. I find changing this age-old OSPF design point for a 
particular type
       of prefix egregious.. If you want this behavior within an OSPF 
domain, simply
       advertise all your anycast addresses as  Type 1 AS external /128 
prefixes and
       you're done.

Thanks,
Acee

---

From: Russ White <[email-masked]>
Date: Thu, 14 Dec 2006 15:30:54 -0500

>        isn't specific to anycast addresses and we should not come up with a

Or if you can't hold two leaves, with the second being a backup for
immediate install in the routing table. In short there are a ton of
options here, we don't need to prescribe one in a draft.

>       advertise all your anycast addresses as  Type 1 AS external /128

In fact, this is worse than "why should we change this." Changing this
can actually result in routing loops, if not all the routers in the area
are preferring routes based in this way. You'd have to present some
fairly strong advantages to be convincing about changes in route preference.

:-)

Russ

---

From: "Abhay D.S" <[email-masked]>
Date: Fri, 15 Dec 2006 11:11:17 +0800

hi acee,

>   via  /128 loopbacks on servers rather than an address bounded by
I would read it as a hierarchy within OSPFv3 for anycasting.
>   ranges (which is part of the base OSPFv3).
How about  only anycast aggregation option ?.
>   prefix when the anycast addresss is learned or found to be unreachable.
If it were aggregated then the aggegrate still might exist !.

>        on IPFRR being done in the RTG WG.
They want to do it in a different way, since look at SPF tree from far. 
Actually the SPF
tree has not changed here. Only the address has been changed. It means 
holding a route
cache for upto 5 next hops and immediately choose another instead of 
re-doing calculation.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 14 Dec 2006 22:46:50 -0500

Hi Abhay,
> I would read it as a hierarchy within OSPFv3 for anycasting.
I'd like to hear from the authors what value this adds.
> How about  only anycast aggregation option ?.
If you treat anycast prefixes the same as unicast this is not needed.

> If it were aggregated then the aggegrate still might exist !.
Only if there are other prefixes in the range (or a bug :^).

> They want to do it in a different way, since look at SPF tree from 
> far. Actually the SPF
Aside from not seeing the reason for a limited scope solution, I don't see
the need to document the precise implementation.

Thanks,
Acee

>>       be ignored and the closest route should be preferred for 
>> anycast irrespective
>>       advertise all your anycast addresses as  Type 1 AS external 
>> /128 prefixes and
>>       you're done.
>>
>> Thanks,
>> Acee
>>
>>>   
>>