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

From: "Michael Barnes" <[email-masked]>
Date: Thu, 31 May 2012 14:35:46 -0700

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