Subject: [OSPF] OSPFv3 Autoconfiguration as WG Document

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Sep 2012 14:58:06 -0400

We had some support of making http://www.ietf.org/id/draft-acee-ospf-ospfv3-autoconfig-03.txt an OSPFv3 WG document at IETF 84. The impetus is:

   1. OSPFv3 being considered as homenet routing protocol and autoconfiguration is a requirement. 
   2. Work on OSPFv3 configuration has started in the past in other WGs but not finished. 
   3. Current proposal has gone through a couple revision cycles with incremental comments addressed. 

Is anyone opposed? 

Thanks,
Acee

---

From: "Faraz Shamim (sshamim)" <[email-masked]>
Date: Fri, 21 Sep 2012 17:43:34 +0000

Hi Acee,

Not opposing this idea but have 4 comments here:

1)

In section 5.2.1:

 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and
   the S1/S2 bits set to B'01' indicating Area Flooding Scope.

I think it should say S2/S1 as mentioned in RFC 5340. Since S2 comes
before S1 in packet format so it make sense to use the same sequence in
your text.

Also, not sure what you meant by letter 'B' next to '01'.

2)

In section 2.2:

For example, if manual
       configuration or an other condition indicates that an interface
       is connected to an Internet Service Provider (ISP), there is
       typically no need to employ OSPFv3.  However, note that in many
       environments it can be useful to test whether an OSPFv3 adjacency
       can be established.  In home networking environments, an
       interface where no OSPFv3 neighbors are found but a DHCP prefix
       can be acquired may be considered as an ISP interface.

In a situation when you are running eBGP with an ISP and iBGP internally,
it is required to enable OSPFv3 on the ISP link unless you are using
next-hop-self in BGP. So in that case excluding ISP link is a bad idea.
Also in this case enabling OSPFv3 with passive-interface would make sense.

3)

In section 2.4:

OSPFv3 interfaces MUST auto-configure the default HelloInterval
       and RouterDeadInterval as specified in [OSPFV3].

I think the "auto-configure" part is confusing here. We do not "configure"
the default values when we enable OSPFv3 on an interface. A better
sentence in my opinion would be:

OSPFv3 interfaces MUST use the default HelloInterval
       and RouterDeadInterval as specified in [OSPFV3].

4) In section 5.2.1, wouldn't it be better to use the field name/letter
instead of the actual value? For example instead of mentioning 1 0 1 it
should say U S2 S1 and in the explanation section it should mention the
default value for AC LSA. Same logic goes for using TBD instead of "LSA
Function Code"

Thanks,

Faraz

On 9/17/12 1:58 PM, "Acee Lindem" <[email-masked]> wrote:

>We had some support of making
>http://www.ietf.org/id/draft-acee-ospf-ospfv3-autoconfig-03.txt an OSPFv3
>WG document at IETF 84. The impetus is:
>
>Acee _______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Sep 2012 11:47:33 -0400

Hi Faraz, 
Thanks for review.

> before S1 in packet format so it make sense to use the same sequence in

Yes - will update. 

> Also, not sure what you meant by letter 'B' next to '01'.

I mean these are bits. I will see whether or not this is used elsewhere. 

> Also in this case enabling OSPFv3 with passive-interface would make sense.

You certainly wouldn't run OSPFv3 in the same routing domain with the ISP box. 
This is really only an example but I could qualify OSPFv3 as "autoconfigured OSPFv3". 

>       and RouterDeadInterval as specified in [OSPFV3].

Ok. 

> instead of the actual value?

These fields are referred to by the bit names in RFC 5340.  

> For example instead of mentioning 1 0 1 it

This is pretty much standard text for adding an OSPFv3 LSA. The text excerpted below
includes the name of the bits, value, and the designation. 

   The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and
   the S1/S2 bits set to B'01' indicating Area Flooding Scope.  The U
   bit will be set indicating that the OSPFv3 AC LSA should be flooded
   even if it is not understood. 

Note that we want to specify these bits precisely rather than the defaults. 

Thanks,
Acee

---

From: "Faraz Shamim (sshamim)" <[email-masked]>
Date: Mon, 24 Sep 2012 16:11:52 +0000

Hi Acee,

In my point 2) below, I am not saying to enable OSPFv3 towards ISP for the
purpose of forming OSPFv3 neighbor relationship with ISP. I am saying that
in eBGP case, you do need to enable OSPFv3 on the link towards the service
provider(in passive mode) because this ISP link is needed to be known as
an IGP because BGP will cary this next-hop "as is" in its iBGP updates
unless we do next-hop-self. This is one aspect of interaction between BGP
and IGP where you need to carry the eBGP next-hop in your IGP.

Thanks,

Faraz

---

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Sep 2012 12:42:30 -0400

Hi Faraz,

> and IGP where you need to carry the eBGP next-hop in your IGP.

I understood. What I meant was that this would not be an autoconfigured instance of OSPFv3 and it would most likely not be the same instance as is running on non-ISP facing interfaces. 

Thanks,
Acee

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Sep 2012 14:45:28 +0300

It is not a surprise, obviously, that I support this work. I just wanted to say that the applicability goes actually beyond just the homenet work. I think that the mechanism would also be useful in other types of OSPFv3 networks.

I'd be happy to work with Acee to make any changes or other updates, as needed per WG guidance.

Jari

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 25 Sep 2012 18:09:05 -0400

Yes/support

From: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: September 17, 2012 2:58:06 PM EDT
To: OSPF List <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] OSPFv3 Autoconfiguration as WG Document

Is anyone opposed?

Thanks,
Acee

---

From: "Faraz Shamim (sshamim)" <[email-masked]>
Date: Thu, 27 Sep 2012 14:04:29 +0000

Acee,

I am not sure why you think that the same instance can not be used for the
ISP link. The fact that you will enable OSPFv3 in a passive mode, instance
ID really won't matter here.

Faraz

On 9/24/12 11:42 AM, "Acee Lindem" <[email-masked]> wrote:

>I understood. What I meant was that this would not be an autoconfigured
>instance of OSPFv3 and it would most likely not be the same instance as
>is running on non-ISP facing interfaces.
>
>Thanks,
>Acee 
>
>
>> 
>> Thanks,
>> 
>> Faraz
>> 
>>> You certainly wouldn't run OSPFv3 in the same routing domain with the
>>>ISP
>>> box.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Sep 2012 10:26:15 -0400

Hi Faraz,
I agree that this is a viable use case for OSPFv3. However, I don't see it as one that can be handled with autoconfiguration. I will try and clarify this in example in the next revision. 
Thanks,
Acee