Lorenzo,
thanks for posting. A few responses and comment.
From: Lorenzo Colitti <lore...@google.com>
>First, some of the draft, particularly the flowing prose in sections 1-3, or
things like "will not only act as an enabler but will also provide >criticality
required transition capabilities to ensure advanced phases can also be deployed
seamlessly to both customers and operators >with minimal disruption" is
unnecessarily verbose and marketing-y for a technical document. Perhaps it could
be shortened.
[VK] Ok, we can review this to address salient points.
>More importantly, I see issues with the message of the draft itself. For a
draft whose main proposal is an "incremental upgrade path", I'm >surprised that
no upgrade path is actually presented.
[VK] The goal of the draft was to describe (as other incrementals in the
past) that path, but not spell out each detail. Details on how to move to a
given technological phase should be part of the work of a given technology.
It would be a very long and tedious task to deal with that on just one
document. Also, given the flux with some of the current work, I am not sure
we know enough to spell that out now anyway.
>A number of phases are described, but no actual upgrade path is provided. I
think >this is a real concern, because I see important ways in >which each the
intermediate phases, instead of being an incremental step, could >actually be a
barrier to further progress.
[VK] It would be good to vet these potential barriers out. I would say
that the first phase is actually today (what we have in networks by virtue
of 6402 or 6402-like code already in the wild). If we suggest the last
phase (Posterus) is much of what many (in this WG) think is the end state,
then it's the second (medius) and third (provectus) phase progressions which
are in question.
To that point, going from 6204 to phase 2 (of which HIPnet is an option)
appears to be very achievable. So the question (in my mind) comes down to
how to progress from that to using routing protocols in the home (with our
without it's prefix assignment capabilities).
I think moving from 6204/6204-bis to homenet is as much a challenge as
moving from hipnet to homenet., I would like to know how we had planned on
moving from 6204 to phase 3/4. And, would still like to know what barriers
phase 2 would have on phase 3/4 (I.e. How would adding a routing protocol as
an overlay [option] to an existing home network be problematic).
>A very basic example is ISPs delegating only a /64 to each home network. This
is a barrier to evolution, because home routers are often >written to the lowest
common denominator. If ISPs hand out /64s, we might see widespread adoption of
routers that only support /64 >and choke when given anything else. At that
point, it becomes impossible for ISPs to hand out prefixes larger than /64s
because of the >fear of breaking customer connectivity. Fortunately this does
not appear to be the case because most ISPs started to provide larger than >/64
prefixes from day one; but it would have been a real problem if most ISPs had
standardized on /64.
[VK]. I note this, not as a design point, but a reality of what is in the
wild. I cannot ignore it. I think many operators had (past) chosen this as
an initial step due to problems with CPE equipment that reacted poorly to
shorter (larger) prefixes. I suspect this will change once the risk is
lower (operators are not allowed to just impact customers willy nilly to
achieve technological advancement). I agree that long term use of a /64 is
problematic.. I don't like this but I again will say I cannot ignore it as
a potential in some networks and/or a condition of error at times. Any
solution needs to know what to do in such a case.
>Another example is the fact that the draft proposes a tree topology ("Medius"
and "Provectus") as intermediate between a flat one-link >topology and a fully
meshed topology. That sounds good in theory, but in practice things aren't that
simple, because as soon as you have >even just one device that doesn't support
meshing, the mesh doesn't work any more.
[VK] Well most home networks we see in our networks are actually flat. Some
use sub-tended equipment to achieve WiFi range extensions and/or port count
increases (I am speaking of people who may have full router/gateway to
extend WiFi and not a proper extender which is not a L3 point in the
topology).
[VK]Of those tandem devices, they are often tree in nature (hanging off the
main gateway). I know we have spoken about meshes to date, and I agree this
can happen, but I have not seen any data suggesting it's a significant
portion of the deployment base. But this is a point of discussion.
Try putting an router that only supports EIGRP into >an OSPF or IS-IS based
network - the whole thing falls over. So in fact, far from being an
intermediate step, these phases actually >constitute barriers that make it
harder to get to the end state.
[VK] For the routing piece, I don't think anyone is suggesting that there is
a mixed mode of routing protocols. I think the draft did present some
options. That said, it is possible to run more then one Routing protocol in
big networks (we do it all the time), but I am not sure that's a good idea
for a home network. EIGRP was not discussed. There was some discussion of
RIP, which is still an option (some may disagree). RiP does have some
advantages due to simplicity and is widely used in circumstances where it
makes sense (not saying home net is one of them).
>As another example, in the "Provectus" phase, it is stated that a routing
protocol is "optional". How is this going to work? What happens >when some but
not all routers speak the routing protocol? Which source of information will be
authoritative? Who is going to turn the >routing protocol on? And so on.
[VK] discussion around this is welcome. If you have gleaned routing (form
prefix assignment and default for north), then you don't need a full
complement of routes running routing protocols (the routing table my be
comprised of routes form different soruces). This may not be the most
efficient mode of operation, but again, we are talking about brown field.
To expect a full home network swap out of like-capable equipment is not
reasonable operationally (so all solutions need to deal with modes of
operation with previous-gen and current-gen functions operating together).
>So saying "we'll get there in phases" is well and good, but to do that the
draft needs to explain how to get from one phase to another, >and explain how
deploying "intermediate" phases makes the end result easier, not more difficult,
to achieve.
[VK] I can only go with experience here. I have had very few opportunities
to build greenfield. Most of the networks we have in general are here based
on progression. Mind you that was managed networks, but I think the
principle still holds. In my mind, to suggest we don't need phases is more
contrary to our experience and how we can get from A-Z in a single step is
questionable. I can tell you today we spend most of our time as operators
trying to get stuff upgraded (mobile and wireline) and making stuff work
(not break) while we do it. It's a difficult reality we deal with every
day.
Regards,
Victor K
On Fri, Jul 5, 2013 at 11:48 AM, Victor Kuarsingh <vic...@jvknet.com> wrote:
> Homenet WG,
>
> A draft has been submitted (below) which outlines a home network
> progression from current state (reference point RFC6204) to future
> advanced states.
>
> The progression is outlined as an incremental approach to achieve the full
> envisioned homenet architecture over a series of phases (additive
> capabilities).
>
> The progression outlined was envisioned such that the home network can be
> evolve in a controlled and feasible manner considering the realities of
> brownfield deployments in environments that must remain operational during
> the transition.
>
> The WGs feedback is desired and requested.
>
> Regards,
>
> Victor K
>
>
> On 2013-07-04 10:34 PM, "internet-dra...@ietf.org"
> <internet-dra...@ietf.org> wrote:
>
>> >
>> >A new version of I-D, draft-jvkjjmb-home-networking-incremental-00.txt
>> >has been successfully submitted by Victor Kuarsingh and posted to the
>> >IETF repository.
>> >
>> >Filename: draft-jvkjjmb-home-networking-incremental
>> >Revision: 00
>> >Title: An incremental solution to advanced home networking
>> >Creation date: 2013-07-04
>> >Group: Individual Submission
>> >Number of pages: 24
>> >URL:
>> >http://www.ietf.org/internet-drafts/draft-jvkjjmb-home-networking-incremen
>> >tal-00.txt
>> >Status:
>> >http://datatracker.ietf.org/doc/draft-jvkjjmb-home-networking-incremental
>> >Htmlized:
>> >http://tools.ietf.org/html/draft-jvkjjmb-home-networking-incremental-00
>> >
>> >
>> >Abstract:
>> > The home network is an environment subject to ongoing evolution and
>> > change. Many home networks today are simplistic in nature, often
>> > comprising of a single router/gateway. The expectation over time is
>> > predicated on the notion that the home network will be more complex
>> > servicing many in-home and Internet functions. The home network will
>> > evolve necessitating the replacement and update to current hardware
>> > and software to more advanced devices and software capable of
>> > operating in more complex environments. This document provides a
>> > view on how the home network can progress from today's foundational
>> > form, to a more advanced environment, using progressive technological
>> > capabilities.
>> >
>> >
>> >
>> >
>> >
>> >
>> >The IETF Secretariat
>> >
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
