Re: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt

"Madhukar Anand (anandmkr)" <> Mon, 17 June 2013 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94C2821F9990 for <>; Sun, 16 Jun 2013 21:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KNr4fGGYtwRy for <>; Sun, 16 Jun 2013 21:15:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B4E6921F994A for <>; Sun, 16 Jun 2013 21:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3012; q=dns/txt; s=iport; t=1371442502; x=1372652102; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZBU2ht5yWm7i8h+KkRdEE24Epl0J5oN2A5ucmmJ0XOo=; b=TvovmU/EjKubcGBX4tyf2104jWflB6wMzKH93xnJmXe2X631UgmduI1q bM6m7Fx0TIWVRdvVIVAEjgTOnn9v5LLDi5HSV27fLBq+jjYa/u5Ij7zY0 FlU1wh1tiWkC5cnpwt5ivr4t0lasuWXtsd++pJYJfNR/qL8mBiAcnl4iZ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoIHAOKMvlGtJXHA/2dsb2JhbABagwkxQwa+UoEEFm0HgiUBBDo4BQISAQgiFEIlAgQOBQgBiAUHBbdfjg+BBzEHgn9hA5NvhHuQGoMPgWhA
X-IronPort-AV: E=Sophos;i="4.87,878,1363132800"; d="scan'208";a="223538090"
Received: from ([]) by with ESMTP; 17 Jun 2013 04:15:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5H4F1Mk027225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 04:15:01 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Sun, 16 Jun 2013 23:15:01 -0500
From: "Madhukar Anand (anandmkr)" <>
To: "" <>
Thread-Topic: New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt
Thread-Index: AQHOaxB6veIaFt2heUyHZvceKkKAA5k5KtqA
Date: Mon, 17 Jun 2013 04:14:59 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Madhukar Anand <>
Subject: Re: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jun 2013 04:15:07 -0000

Thanks for all the feedback. We have made 3 modifications modifications to
the previous draft:

(1) In the introduction, we have added OSPFv3 Autoconfig as another

Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for
flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of
[OSPFV3-AUTOCONFIG]). These requirements can be easily met by implementing
the proposal here.

(2) In 2.2 Receiving HELLOs with Asymmetric Hold Timer Values.

 Routers that recognize this new extended options will set the
   value of the neighbor dead interval to the value specified in the LLS
   block TLV, but only if BOTH the HELLO and dead interval are set to
   zero in the OSPF HELLO packet.

(3)  We have also summarized the discussion section and the relation of
this proposal w.r.t. BFD.

It is possible to use Bidirectional Forwarding Detection (BFD) [RFC 5880]
to alleviate some of the concerns in the use-cases identified above.
Relying entirely on BFD without OSPF HELLOs is not a
possibility given that OSPF HELLOs are still used for discovery of
neighbors. The BFD approach has its own shortcomings such as limited
cross-vendor and cross-platform support and also performance implications,
especially with increasing scale requirements. In any case, BFD can be
made to work in conjunction with the proposal in this document to achieve
the best possible network performance. It is intended that the proposal
for asymmetric hold timer would work independent of BFD deployment
considerations, and could also help in new applications where it may be
desirable to support asymmetric and possibly dynamic dead interval values
(e.g., OSPFv3 Auto-Configuration, [OSPFV3-AUTOCONFIG]).


On 6/16/13 9:09 PM, "" <>

>A new version of I-D, draft-madhukar-ospf-agr-asymmetric-01.txt
>has been successfully submitted by Madhukar Anand and posted to the
>IETF repository.
>Filename:	 draft-madhukar-ospf-agr-asymmetric
>Revision:	 01
>Title:		 Asymmetric OSPF Hold Timer
>Creation date:	 2013-06-16
>Group:		 Individual Submission
>Number of pages: 10
>   Current OSPF standard requires that the HELLO/Dead interval be
>   symmetric on either side of the link in order to maintain adjacency.
>   There are many scenarios in which this may not be desirable. This
>   memo describes a technique to allow OSPF adjacency to be maintained
>   with asymmetric values of the OSPF Dead interval.
>The IETF Secretariat