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

Mukesh.Gupta@NOKIA.COM Sun, 11 July 2004 18:22 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA05132 for <ospf-archive@LISTS.IETF.ORG>; Sun, 11 Jul 2004 14:22:04 -0400 (EDT)
Received: from ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; 11 Jul 2004 14:22:03 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25431591 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jul 2004 14:21:59 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jul 2004 14:21:59 -0400
Received: from ( []) by (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6BILvb13865 for <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 11 Jul 2004 21:21:57 +0300 (EET DST)
X-Scanned: Sun, 11 Jul 2004 21:21:33 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by (8.12.9/8.12.9) id i6BILXk5015147 for <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 11 Jul 2004 21:21:33 +0300
Received: from ( by 00md9iaF; Sun, 11 Jul 2004 21:21:32 EEST
Received: from ( []) by (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6BILVn27368 for <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 11 Jul 2004 21:21:31 +0300 (EET DST)
Received: from ([]) by with Microsoft SMTPSVC(5.0.2195.6881); Sun, 11 Jul 2004 13:21:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt
Thread-Index: AcRmEbAmi6Fwh/RFQbe1/wT3BG8w0gBYT/1w
X-OriginalArrivalTime: 11 Jul 2004 18:21:30.0322 (UTC) FILETIME=[E328D320:01C46773]
Message-ID: <>
Date: Sun, 11 Jul 2004 13:21:29 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukesh.Gupta@NOKIA.COM
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
Precedence: list
Content-Transfer-Encoding: quoted-printable


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 ?