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

[Acee Lindem <[e-mail]>]

Hi Abhay,
Abhay D.S wrote:
> hi acee,
>
> Acee Lindem wrote:
>> 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.
> I would read it as a hierarchy within OSPFv3 for anycasting.
I'd like to hear from the authors what value this adds.
>>
>>   Section 3.3 - This can be done for /128 unicast addresses with 
>> overlapping
>>   ranges (which is part of the base OSPFv3).
>>
> How about  only anycast aggregation option ?.
If you treat anycast prefixes the same as unicast this is not needed.

>>   Section 3.4 - An implementation can advertise or withdraw a /128 
>> unicast
>>   prefix when the anycast addresss is learned or found to be 
>> unreachable.
>>  
> If it were aggregated then the aggegrate still might exist !.
Only if there are other prefixes in the range (or a bug :^).

>
>>   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.
>>
> 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.
Aside from not seeing the reason for a limited scope solution, I don't see
the need to document the precise implementation.

Thanks,
Acee


>>     - 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
>>
>>>   
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ospf
>>
>>

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