Acee:

OK...but deciding on what to do on a specific deployment without manually 
configuring the router is not trivial.

As far as other parameters, the draft seems to specify fixed values which are 
not specific to a deployment.


BTW, the draft reads "OSPFv3 interfaces MUST auto-configure the default 
HelloInterval and RouterDeadInterval as specified in 
[OSPFV3<http://tools.ietf.org/html/draft-acee-ospf-ospfv3-autoconfig-02#ref-OSPFV3>]."..but
 rfc5340 doesn't actually specify a default value, just provides examples:

   HelloInterval
      The length of time, in seconds, between Hello packets that the
      router sends on the interface.  This value is advertised in the
      router's Hello packets.  It MUST be the same for all routers
      attached to a common link.  The smaller the HelloInterval, the
      faster topological changes will be detected.  However, more OSPF
      routing protocol traffic will ensue.  Sample value for a X.25 PDN:
      30 seconds.  Sample value for a local area network (LAN): 10
      seconds.

   RouterDeadInterval
      After ceasing to hear a router's Hello packets, the number of
      seconds before its neighbors declare the router down.  This is
      also advertised in the router's Hello packets in their
      RouterDeadInterval field.  This should be some multiple of the
      HelloInterval (e.g., 4).  This value again MUST be the same for
      all routers attached to a common link.

Alvaro.

From: Acee Lindem [mailto:[email protected]]
Sent: Thursday, May 31, 2012 11:44 AM
To: Retana, Alvaro
Cc: OSPF List; Jari Arkko
Subject: Re: New Version Notification for 
draft-acee-ospf-ospfv3-autoconfig-02.txt


On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote:


Hi!

My reason for the suggestion was that requiring a special instance ID (even if 
well known) takes away from the auto-* properties by requiring other routers to 
behave in a special way.  IOW, the use case of adding an 
auto-configuration-capable router to an existing network would not be possible 
w/out additional configuration and/or hacks.

I obviously like option #2. :)

IMHO, option #3 is not good because it still requires the 
auto-configuration-capable router to be configured beforehand...which is an 
oxymoron!

This was not the intent of #3 - it was meant to allow an implementation to 
decide dependent on the targeted deployments. Even without the reserved 
instance ID, other parameters (area, hello, dead, etc) in the existing network 
would need to use the auto-configured values.

Thanks,
Acee




Thanks!

Alvaro.

From: Acee Lindem [mailto:[email protected]]
Sent: Monday, May 28, 2012 4:19 PM
To: OSPF List
Cc: Jari Arkko; Retana, Alvaro
Subject: Fwd: New Version Notification for 
draft-acee-ospf-ospfv3-autoconfig-02.txt

Speaking as a Draft Author:

This version includes additions based on comments received at IETF 83. Section 
5.1 clarifies the detection of a neighbor with a duplicate Router-ID to exclude 
the case where multiple router interfaces are connected to the same link. 
Section 5.4 was added to mitigate the effects of a duplicate OSPFv3 Router-ID 
in the OSPFv3 routing domain prior to duplicate Router-ID resolution.

Additionally, we received a suggestion from Alvaro Retana to not use an 
reserved OSPFv3 instance ID for auto-configured routers. Rather, allow OSPFv3 
auto-configured routers to use the default OSPFv3 instance ID and automatically 
join an existing non-autoconfigured OSPFv3 routing domain. I see three possible 
alternatives:

    1. Reject the suggestion. The alternate OSPFv3 instance ID was added 
specifically to prevent this.
    2. Adopt the suggestion and remove the reserved instance ID. The security 
considerations now recommend that implementation provide the capability to 
configure a single key.
    3. Add an applicability statement indicating that an implementation MAY use 
the default OSPFv3 instance if the network where the implementation is deployed 
requires incorporation into an existing OSPFv3 network.

Please provide your thoughts on this issue.

Thanks,
Acee




Begin forwarded message:



From: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: May 28, 2012 3:41:15 PM EDT
To: Acee Lindem <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt

A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been 
successfully submitted by Acee Lindem and posted to the IETF repository.

Filename:       draft-acee-ospf-ospfv3-autoconfig
Revision:       02
Title:              OSPFv3 Auto-Configuration
Creation date:            2012-05-28
WG ID:                     Individual Submission
Number of pages: 14

Abstract:
  OSPFv3 is a candidate for deployments in environments where auto-
  configuration is a requirement.  One such environment is the IPv6
  home network where users expect to simply plug in a router and have
  it automatically use OSPFv3 for intra-domain routing.  This document
  describes the necessary mechanisms for OSPFv3 to be self-configuring.




The IETF Secretariat


_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to