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

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

From: "Madhukar Anand (anandmkr)" <anandmkr@cisco.com>
To: "ospf@ietf.org" <ospf@ietf.org>
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: <60816F26681B6440A1552440352BAE941DD5E294@xmb-aln-x05.cisco.com>
In-Reply-To: <20130617040919.17495.50463.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.2.120421
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1F5C9B6A32F8E246A29F703BF61174CC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Madhukar Anand <None@ietfa.amsl.com>
Subject: Re: [OSPF] New Version Notification for draft-madhukar-ospf-agr-asymmetric-01.txt
Precedence: list

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
use-case:

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]).

Thanks,
Madhukar

On 6/16/13 9:09 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>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
>URL:             
>http://www.ietf.org/internet-drafts/draft-madhukar-ospf-agr-asymmetric-01.
>txt
>Status:          
>http://datatracker.ietf.org/doc/draft-madhukar-ospf-agr-asymmetric
>Htmlized:        
>http://tools.ietf.org/html/draft-madhukar-ospf-agr-asymmetric-01
>Diff:            
>http://www.ietf.org/rfcdiff?url2=draft-madhukar-ospf-agr-asymmetric-01
>
>Abstract:
>   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
>

Re: [OSPF] New Version Notification for draft-mad… Madhukar Anand (anandmkr)
Re: [OSPF] New Version Notification for draft-mad… Acee Lindem