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

[Acee Lindem <[e-mail]>]

Hi Madhakar, 

For auto-configured routers, we have previously added that we simply
default to the asymmetric behavior without additional requiring additional
LLS encoding. Here is an excerpt from
draft-ietf-ospf-ospfv3-autoconfig-02.txt:

3.  OSPFv3 HelloInterval/RouterDeadInterval Flexibility

   Auto-configured OSPFv3 routers will not require an identical
   HelloInterval and RouterDeadInterval to form adjacencies.  Rather,
   the received HelloInterval will be ignored and the received
   RouterDeadInterval will be used to determine OSPFv3 liveliness with
   the sending router.  In other words, the Inactivity Timer for each
   neighbor will reflect that neighbor's advertised RouterDeadInterval
   and MAY be different from other OSPFv3 routers on the link without
   impacting adjacency formation.  A similar mechanism requiring
   additional signaling is proposed for all OSPFv2 and OSPFv3 routers
[ASYNC-HELLO]. 

Hence, I believe we disagree on this point. It would be good to get WG
discussion on this point.

Thanks,
Acee 





On 6/16/13 9:14 PM, "Madhukar Anand (anandmkr)" <[e-mail]> wrote:

>
>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, "[e-mail]" <[e-mail]>
>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
>>
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf