Hi MIchael - I agree. Even if we use the reserved IPv4 instance ID, it should be documented. Thanks, Acee On May 31, 2012, at 5:35 PM, Michael Barnes wrote:
> Hi Acee, > > If you do use a reserved instance ID, then there should be one per address > family in accordance with RFC5838. This is needed to allow for the fact that > we use a different instances for each AF. > > Regards, > Michael > > ------ Original Message ------ > Received: Thu, 31 May 2012 02:22:21 PM PDT > From: Acee Lindem <[email protected]> > To: "Retana, Alvaro" <[email protected]>Cc: OSPF List <[email protected]>, Jari > Arkko <[email protected]> > Subject: Re: [OSPF] New Version Notification for > draft-acee-ospf-ospfv3-autoconfig-02.txt > >> >> 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 >>> >>> >> >> > >> --------------------------------------------- >> Attachment: smime.p7s >> MIME Type: application/pkcs7-signature >> --------------------------------------------- >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
