Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 23:15:58 +0100

On Mon, Jan 31, 2011 at 06:54:01AM +0000, Fred Baker wrote:
> What do people want to see happen in draft-wbeebee-v6ops-ipv6-cpe-router-bis?

Speaking with an operator point of view: get the areas it covers
polished up as quickly as possible and get it out of the door as RFC so
we can start pointing vendors to it. There's always the option to update
the RFC later with more topics covered and operational experience
feedback incorporated.

> Part of the outcome of IETF 79 was a discussion around Tom Herbst's
> draft regarding interactions with the Smart Grid's Home Area Network.
> This is something that is not mandatory in a next generation
> residential router, but I suspect will have utility.

See above. If not really required now, I'd favor not to consider it for
cpe-router-bis in order to avoid further delays.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: james woodyatt <[email-masked]>
Date: Tue, 01 Mar 2011 14:35:40 -0800

On Mar 1, 2011, at 2:15 PM, Daniel Roesen wrote:
> we can start pointing vendors to it. [...]

It's not currently on the agenda for IETF 80.  Do the authors plan to ask the working group to adopt it?  I hope they update it to remove sections 5.4, 5.5 and 5.9 before they do that.  (Amend the figure in section 4, too.)  Otherwise, I predict, the draft will be more contentious than operators probably want it to be.  If you want it published quickly, then get rid of all the talk about routed subscriber networks and prefix delegation on the LAN.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 1 Mar 2011 15:53:55 -0800

Hi James,

Question:  Who then addresses routed subscriber networks and prefix
delegation in the HAN?   

I think these topics need to be addressed someplace before internetworked
CPEs are deployed and the topic becomes a major oversight.  For our
application (Smart Energy) we already have groups like WiFi, HomePlug and
HomeGrid planning exactly such deployments next year.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, March 01, 2011 2:36 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go
from here

> we can start pointing vendors to it. [...]

It's not currently on the agenda for IETF 80.  Do the authors plan to ask
the working group to adopt it?  I hope they update it to remove sections
5.4, 5.5 and 5.9 before they do that.  (Amend the figure in section 4, too.)
Otherwise, I predict, the draft will be more contentious than operators
probably want it to be.  If you want it published quickly, then get rid of
all the talk about routed subscriber networks and prefix delegation on the
LAN.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 1 Mar 2011 18:14:03 -0600

Folks,

At least at the Beijing IETF, I believe there was a some consensus in
the room to adopt this document to work on Advanced IPv6 CE router
features.  James, thanks for your comments - we will look into catering
to your comments in the next version we plan to release by March 4th,
2011.  After the -00 version is submitted, we authors (and our expanded
IPv6 CE router design team) can certainly look into polishing the
document and then see if a -01 copy can be submitted by mid-March, 2011.
I am going by the dates I received in email from v6ops Chair in Fred.
The text in double quotes below is what I received as dates from the
Chair.

"The final date for submission of new (-00) drafts is 7 March. Final
date for updated documents is 14 March. With one exception (a testing
report, for which the proceedings will be the enduring documentation),
any draft that will be discussed in this working group at IETF-80 needs
a draft posted since IETF-79, and should have corresponded with
[email-masked] on the topic."

A bit of news to share with folks.  During the week of February 14th,
there was a week-long IPv6 CE Router Interop held at the UNH Interop
Labs and organized by CableLabs in the U.S.  The summary of this Interop
was that IPv6 CE Routers would be tested behind a cable modem and the
cable modem is connected to a CMTS (Cable Modem Termination System).  A
CMTS is akin to DSLAM and first hop L3 router functionality in DSL.
Since UNH is a short drive from where I work at Cisco in the CMTS router
business unit, I expedited an IPv6 ready CMTS system for this Interop.
The Cisco provisioning server team expedited the Cisco Network Registrar
DHCPv4/DHCPv6 server and provisioning system for the Interop as well.
Thus our totally test-ready system reached the Interop ready to start
testing within the first hour of the Interop to test any IPv6 router
plugged behind a cable modem.  A good number of IPv6 CE router vendors
came to this Interop.  My thanks also go to Cablelabs and Chris Donley
whom I requested during the past IETFs that we should have more that two
IPv6 CE router Interops per year because then we flush IPv6 CE Router
and also IPv6 CMTS issues faster.  Thus Cablelabs organized this event
during February of this year.  

http://www.iol.unh.edu/services/testing/ipv6/grouptest/feb_14_2010_cable
labs/

Two other Interops occur during April and September at CableLabs in
Denver area.  Amongst other tests, this Interop also focused on testing
our IETF Basic IPV6 CE Router document which is in RFC Editor queue in
Edit state.

http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/

Some issues that I have noticed from the Interop will also cause us to
add more text to the Advanced IPv6 CE router document.  Also, it is up
to the Cablelabs (http://cablelabs.com) and the UNH labs to publish any
testing results and complete list of participants to a wide mailer such
as this one.

Thanks,

Hemant

---

From: james woodyatt <[email-masked]>
Date: Tue, 01 Mar 2011 16:45:01 -0800

On Mar 1, 2011, at 3:53 PM, Don Sturek wrote:
> 
> I think these topics need to be addressed someplace before internetworked CPEs are deployed and the topic becomes a major oversight.  For our application (Smart Energy) we already have groups like WiFi, HomePlug and HomeGrid planning exactly such deployments next year.

Understood.  Do any of those organizations have a recommendation for a suitable interior routing protocol for residential IPv6 networks?  I'm pretty sure IETF doesn't have one to recommend right now, and I'm pessimistic that it will have one by next year to satisfy the plans of the Smart Energy community.

Is there are reason that application proxies and neighbor discovery proxies are unsatisfactory solutions?

---

From: Timothy Winters <[email-masked]>
Date: Tue, 1 Mar 2011 20:29:42 -0500

Hello,
	As Hemant pointed out the UNH-IOL held a IPv6 CE Plugfest on Feb. 14, 2011.   A whitepaper will be released about our finds from the event.  We expect this to be out in the next couple of weeks, and we are also planning a second event for May 9th, 2011 at the UNH-IOL.  The IPv6 Forum is looking into creating a IPv6 Ready Logo around the the draft mentioned below.   I will post updated test specifications and the whitepaper to the list.  Please feel free to contact me if you have any questions about the plugfest or IPv6 Ready program.

Regards,
Tim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 1 Mar 2011 19:47:24 -0600

Incidentally,  I must also thank Timothy Winters and all other folks of
the UNH-IOL Lab for their great organization and hospitality during the
February Interop. 

Good to hear from you Timothy.

Hemant

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Mar 2011 19:42:08 -0800

> Understood.  Do any of those organizations have a recommendation for a suitable interior routing protocol for residential IPv6 networks?  I'm pretty sure IETF doesn't have one to recommend right no…

Well, one could discuss ZOSPF, or OSPFv3 with a default configuration, or RIPng, or IS-IS with a default configuration. Why would, picking one at random, RIPng be inappropriate?

---

From: james woodyatt <[email-masked]>
Date: Wed, 02 Mar 2011 07:57:22 -0800

> Well, one could discuss ZOSPF, or OSPFv3 with a default configuration, or RIPng, or IS-IS with a default configuration. Why would, picking one at random, RIPng be inappropriate?

Unacceptable human interface burden, for starters.  Beyond that, I have no technical contributions I can make here.

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Mar 2011 08:14:27 -0800

> Unacceptable human interface burden, for starters.  Beyond that, I have no technical contributions I can make here.

I dunno. On my Linksys router (which I don't use anymore, but there is one here at the house), there is a radio button that says "on" or "off" for RIP. If OSPF comes with a default configuration such as described in the MIB document, it can do the same; at the job I had before coming to Cisco (ACC), our configuration design required that when you turned a feature on it had to be operational, and from there configuration commands would change it, and so "SET OSPF ON" (ACC's equivalent of that radio button) had to result in a usable configuration. It worked quite well, actually. I don't see a radio button as "unacceptable UI burden"; a lot of people seem to be able to handle it.

I would agree if we were asking people to navigate IOS CLI. That's a punishment, not a UI :-)

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 02 Mar 2011 08:27:36 -0800

buffalo aps that I was using a couple of years ago came with rip enabled
by default. That was to support the extension of the network using their
bridges or mesh APs. similarly I've seen OLSR deployed in a similar
fashion in both cases it was meant to be done without user intervention.

When two devices are plugged together today they form an l2 adjacency,
why not an l3 one?

joel

---

From: Thomas Herbst <[email-masked]>
Date: Wed, 2 Mar 2011 11:29:43 -0800

As one of the people pushing for a simple first v6 cpe document in my old
role as 
"cisco guy hanging out at Linksys", I agree this document should go
forward and the 
"herbst/sturek" draft should be in advanced.

tom

---

From: Thomas Herbst <[email-masked]>
Date: Wed, 2 Mar 2011 11:35:43 -0800

In the CPE subgroup discussion in Beijing I'd proposed a default of RIPng
on. 
 
Ole preferred OSPF with all area 0.

If we could pick one, I wouldn't really care which one it was.
Picking at random would be more expedient than our normal process.

tom

On 3/2/11 8:27 AM, "Joel Jaeggli" <[email-masked]> wrote:

>>>>> Understood.  Do any of those organizations have a recommendation for
>>>>>a suitable interior routing protocol for residential IPv6 networks?
>>>>>I'm pretty sure IETF doesn't have one to recommend right now, and I'm
>>>>>pessimistic that it will have one by next year to satisfy the plans
>>>>>of the Smart Energy community.
>>>>
>>>> Well, one could discuss ZOSPF, or OSPFv3 with a default
>>>>configuration, or RIPng, or IS-IS with a default configuration. Why
>>>>would, picking one at random, RIPng be inappropriate?
>>>
>>> Unacceptable human interface burden, for starters.  Beyond that, I
>>>have no technical contributions I can make here.
>> 
>> I dunno. On my Linksys router (which I don't use anymore, but there is
>>one here at the house), there is a radio button that says "on" or "off"
>>for RIP. If OSPF comes with a default configuration such as described in
>>the MIB document, it can do the same; at the job I had before coming to
>>Cisco (ACC), our configuration design required that when you turned a
>>feature on it had to be operational, and from there configuration
>>commands would change it, and so "SET OSPF ON" (ACC's equivalent of that
>>radio button) had to result in a usable configuration. It worked quite
>>well, actually. I don't see a radio button as "unacceptable UI burden";
>>a lot of people seem to be able to handle it.
>>

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Mar 2011 22:19:21 -0800

> Ole preferred OSPF with all area 0.

You might take a look at http://tools.ietf.org/id/draft-dimitri-zospf. You might also take a look at section 2.5 of RFC 1850, which has been superseded by RFC 4750 but describes the default configuration of an OSPF entity as defined in the MIB.

If you do what it says, it configures a valid and interesting OSPF configuration. It also has an interesting sid-effect. On every LAN, a Designated Router is elected. Given that, one can conclude that we know for sure what LANs exist in the house. Add one more bit of information - a bit in a Router LSA or a new LSA - indicating that the router in question is acting as a DHCP server and has been given a prefix by its upstream, and the Designated Router on a LAN can now obtain a subnet prefix for the LAN. As a result, we now have a way to uniquely allocate one more specific prefix per LAN.