On May 31, 2012, at 4:13 PM, Retana, Alvaro wrote: > 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.
That's why interaction between configured and auto-configured routers doesn't seem like a likely deployment and using a reserved instance ID seems reasonable. Acee > > BTW, the draft reads “OSPFv3 interfaces MUST auto-configure the default > HelloInterval and RouterDeadInterval as specified in [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. J > > 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]" <[email protected]> > Date: May 28, 2012 3:41:15 PM EDT > To: Acee Lindem <[email protected]> > Cc: "[email protected]" <[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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
