Re: draft-ietf-ospf-ospfv3-auth-04.txt

[[e-mail]]

Mitchell,

Comments inline..

>         Is it really helpful? Ask any customer whether having
>         his system that takes minutes to respond to a router CLI
>         change and I think you will loose that customer!

Little correction.. It is not taking minutes to respond to a
router CLI change.  The router where you changed the authentication
type will immediately start using the new authentication type.

What about when the customer turns on OSPF on an interface.  Doesn't
that take minutes to be fully functional.  That doesn't mean that
the router took minutes to respond.

>         During this latency period that can be 1 hr,
>         no hellos are being responded to, no LSAs are being
>         sent or responded to, the DR doesn't acknowledge new
>         nbrs, etc,... All due to a CLI timebomb. If it happens
>         immediately, the admin should know that he just ran
>         a CLI change and this was the cause.

How can it be 1 hour ?  I remember you talking about no-hellos
on the demand circuits.  What happens when a neighbor crashes
in these situation.  How do we detect that the neighbor is
dead and remove that from our neighbors' list ?

>         The latency time for the system to normally ack the
>         change results in longer than necessary LSDB
>         synchronization and failure detection.
> 
>         If you listed your nbrs, the list would not actually
>         be correct, since you are no longer communicating
>         with your nbrs. Lets see. If I am a router and I
>         have my hello interval set to X secs, I can set up
>         adjs with one set of routers. Then I change it to
>         another value and get adjs with another set of routers.
>         Then if I just toggle the value back and forth within
>         router dead interval time frame, I will have adjs
>         with routers with different hello intervals.. Is
>         this proper operation????
> 
>         If a change is done that is going to eventually drop
>         the adj, then why wait? If the change is a two step
>         process on a single router, then impliment a commit
>         type functionality.
> 
>         I just think that this is an area that really needs
>         a standardized RFC that allows the customer to get
>         immediate changes to changed configurations.

Ok.  Even if we agree with what you are saying, what exactly
are you suggesting for the OSPFv3 security draft ?  Would you
be a little specific and tell me what you want to add/change
in the draft ?

Regards
Mukesh