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.
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. 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.
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
begin:vcard
fn:Abhay Rao
n:Rao;Abhay
email;internet:[EMAIL PROTECTED]
version:2.1
end:vcard
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
