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

From: Acee Lindem <[email-masked]>
Date: Mon, 28 May 2012 16:19:08 -0400

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 28 May 2012 16:24:21 -0400

Speaking as OSPF WG Co-chair,

This draft was presented at the Homenet WG in Tai Pei and the OSPF WG in Paris. If OSPFv3 is adopted as the Homenet routing protocol, auto-configuration is required. 
Please state whether or not you support its adoption as an OSPF WG Document.

Thanks,
Acee

---

From: "Retana, Alvaro" <[email-masked]>
Date: Thu, 31 May 2012 15:34:01 +0000

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!

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

Thanks,
Acee

Begin forwarded message:

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

Abstract:

The IETF Secretariat

---

From: Acee Lindem <[email-masked]>
Date: Thu, 31 May 2012 11:43:44 -0400

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

Hi!

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.

Thanks,
Acee

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: "Retana, Alvaro" <[email-masked]>
Date: Thu, 31 May 2012 20:13:47 +0000

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-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

Hi!

Thanks,
Acee

Thanks!

Alvaro.

Thanks,
Acee

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Acee Lindem <[email-masked]>
Date: Thu, 31 May 2012 17:21:51 -0400

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.
>  

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
> I obviously like option #2. J
>

---

From: Russ White <[email-masked]>
Date: Thu, 31 May 2012 19:23:49 -0400

>     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. 

I think this is the best option --the default should be to join an
existing domain, so the default behavior "just works," but the option
should be there to do otherwise if the network administrator has a
specific reason to provide an alternate or reserved instance ID.

Russ

-- 
<><
[email-masked]
[email-masked]