Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.txt

From: Acee Lindem <[email-masked]>
Date: Fri, 1 Jun 2012 16:56:42 -0400

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-masked]>
> To: "Retana, Alvaro" <[email-masked]>Cc: OSPF List <[email-masked]>, Jari
> Arkko <[email-masked]>
> 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-masked]] 
>>> 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-masked]] 
>>> 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-masked]" <[email-masked]>
>>> Date: May 28, 2012 3:41:15 PM EDT
>>> To: Acee Lindem <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> 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
>> ---------------------------------------------
>