Subject: Re: [homenet] Homenet protocol decisions

From: Teco Boot <[email-masked]>
Date: Sat, 1 Feb 2014 11:36:30 +0100

Op 31 jan. 2014, om 20:25 heeft Ole Troan <[email-masked]> het volgende geschreven:
>> 
>> My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed.
> 
> what are the arguments for involving hosts in the prefix assignment protocol?
> as opposed the existing router to hosts protocols (ND/DHCP).
> 

With multiple prefixes, hosts have to select.

Hosts get smarter and know how to handle multiple paths (MPTCP and the like). It isn't enough just to provide a prefix with lifetime. If the router knows more, for example data rate and delay (fixed line, 3G/4G, whatever), it shall pass it to the host.

Teco

---

From: Teco Boot <[email-masked]>
Date: Sat, 1 Feb 2014 11:45:17 +0100

Op 31 jan. 2014, om 19:56 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

>> On Fri, Jan 31, 2014 at 10:54 AM, Teco Boot <[email-masked]> wrote:
>> > And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case?
>> 
>> I don't see a problem. If the two partitions have border router(s), addresses for the prefixes for the connected border router keeps functioning. Prefixes for the disconnected border router(s) should be deprecated. Is is an internal function on the router, based on topology information and configured prefixes, provided by routing protocol and prefix distribution protocol.
>> 
>> > How do you tell the prefix assignment protocol that it needs to resolve addressing conflicts when you merge two networks that have the same prefixes?
>> 
>> First we have to verify if this can happen. My favorite is using DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box should circumvent your scenario.
>> 
> Er, *what*? You are aware that if you have a partition, one of the two partitions will not be able to reach the DHCP server?

Does it matter? Prefixes for unreachable DHCP servers should be deprecated. Leases wil expire. A mobility tool is needed for connection survival (MPTCP, whatever).

Yes, here is a need for coupled routing and prefix management. The routing table has state on connectivity to border routers. Prefix management makes use of that. Where is the need for coupled protocols?

Teco

---

From: Ole Troan <[email-masked]>
Date: Sat, 1 Feb 2014 13:51:48 +0100

Teco,

> With multiple prefixes, hosts have to select.

yes. there isn't that much information the network has that it can tell hosts though.
as long as the network routes the packets the right way, I'm going to be happy.

in more convoluted networks with walled gardens and VPNs, the network may pass the host more policy information, e.g. DNS server selection, SAS/DAS policy and so on.

> Hosts get smarter and know how to handle multiple paths (MPTCP and the like). It isn't enough just to provide a prefix with lifetime. If the router knows more, for example data rate and delay (fixe…

as the hosts gets smarter they'll be able to figure out the best end to end path themselves.
the network may pass meta data associated with prefixes to the hosts. e.g. "usage of this prefix is horribly expensive".

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 02:29:51 +0100

Hi Ole,

> We need to decide, if we want prefix assignment and distribution of other
> configuration information integrated in a routing protocol.

There's two orthogonal decisions.

One is whether to make the configuration protocol a subprotocol of the
routing protocol.  (I have mentioned earlier that I very strongly favour
a separate configuration protocol, I won't repeat my arguments here.)

The other is to what extent "other configuration information" should
be carried by the Homenet Configuration Protocol.  The principled
solution would be to mandate site-local multicast, and have
application-layer protocols design their own discovery mechanisms (the
end-to-end argument and all that).  The pragmatic solution would be to
include the kitchen sink in the configuration protocol.

(My gut feeling is for an extensible configuration protocol that can
carry arbitrary extra information, but that's simply because I don't
have any experience with site-local multicast.  I hope somebody can
convince me that we can take site-local multicast for granted.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 03:11:44 +0100

> And what happens when the routing protocol finds out that, even though the
> delegation protocol thinks everything is OK and addresses were delegated just
> fine, the network is now partitioned? How do you reassign addresses in that
> case?

I fail to see how this particular functionality requires merging the
two protocols.  If a link is partitioned, you need to time-out the
address assignments made by the now unreachable router.  Whether they
are timed out by the routing protocol or by a separate configuration
protocol is pretty much an implementation detail, isn't it?

> How do you tell the prefix assignment protocol that it needs to resolve
> addressing conflicts when you merge two networks that have the same prefixes?
> You have to tightly couple prefix assignment and routing again.

If I were to implement this, I'd probably listen for changes to the
kernel's routing table and defend my address whenever in doubt.
(Being the paranoid type, I'd also flood periodic defense packets
every few minutes, just in case.)

> In which case it's just better to have the same protocol

There are other disadvantages to having a single protocol.  It's
a tradeoff, as usual.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Feb 2014 16:43:22 +1300

Juliusz,

You (and others) who speak of a "Homenet Configuration
Protocol" seem to be making an assumption which is far from
clear to me. That assumption is that config parameters in a homenet
will come in some sense top-down from a higher level source of
authority.

I think that's a false assumption. It's derived from the old-style
management of campus and enterprise networks, where there *is* a
source of authority that also understands how to configure a network.
That simply doesn't exist in a homenet, especially when we move
away from the single-CPE flat network to the much more complex
networks we expect in the future.

I think we need a completely different approach. Just by chance,
I happen to have one in mind. It's discussed for the case of
carrier networks in
http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02

I believe that exactly the same approach is needed for homenets.

Regards
   Brian

On 02/02/2014 14:29, Juliusz Chroboczek wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
> .
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Feb 2014 21:41:55 -0800

On Sat, Feb 1, 2014 at 2:45 AM, Teco Boot <[email-masked]> wrote:

> >> First we have to verify if this can happen. My favorite is using
> DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box
> should circumvent your scenario.
> >>
> > Er, *what*? You are aware that if you have a partition, one of the two
> partitions will not be able to reach the DHCP server?
>
> Does it matter? Prefixes for unreachable DHCP servers should be
> deprecated. Leases wil expire. A mobility tool is needed for connection
> survival (MPTCP, whatever).
>

You can't reliably deprecate information in DHCP. Even if the client
supports the reconfigure option, deprecating something in DHCP requires
that the server that has the original nonce still be up and around.

This is why DHCP is not a good protocol to use in a distributed, unreliable
network like a homenet.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Feb 2014 21:45:53 -0800

> protocol is pretty much an implementation detail, isn't it?

The routing protocol knows that the network is partitioned because that's
what it does. How is the configuration distribution protocol going to know
that? Either you couple it to the routing protocol, or you have it poll to
see if things have changed (inefficient and/or slow to notice changes). Why
would you do the latter?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 2 Feb 2014 08:07:08 +0100 (CET)

> will come in some sense top-down from a higher level source of

No, I don't think that's what's assumed. All the discussions I've heard 
have been to have configuration sent around the home using a routing 
protocol, or another protocol that disseminates information around the 
home in a similar fashion.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Sun, 2 Feb 2014 10:49:17 +0100

> No, I don't think that's what's assumed. All the discussions I've heard have been to have configuration sent around the home using a routing protocol, or another protocol that disseminates information around the home in a similar fashion.

absolutely. any protocol here must support multiple sources of information.

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 16:08:28 +0100

> You (and others) who speak of a "Homenet Configuration Protocol"
> seem to be making an assumption [...] that config parameters in
> a homenet will come in some sense top-down

I don't think we are.  (But you're right, this deserves stating explicitly.)

I think that most of us have in mind a peer-to-peer protocol in which
authoritative configuration information (notably prefix information)
is flooded by the edge routers (CPEs), and dynamic information is
negotiated dynamically both on a link-local basis (agreeing on a single
prefix) and globally to the homenet (ensuring unicity).  (I'm assuming
just site-local unicast and multicast, hence the need for an application-
layer flooding algorithm, I'm not sure if others are assuming site-local
multicast.)

As far as I am aware, this is the same model as the one in Acees' draft,
except for the use of a flooding mechanism separate from OSPF's, and
is in full agreement with the Arch document.

-- Juliusz

---

From: Acee Lindem <[email-masked]>
Date: Sun, 2 Feb 2014 16:47:07 +0000

I agree. Also, since we already have to bootstrap an auto-configuring routing protocol, why not leverage this work to distribute other information?
Acee

On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote:

The routing protocol knows that the network is partitioned because that's what it does. How is the configuration distribution protocol going to know that? Either you couple it to the routing protocol, or you have it poll to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 18:03:28 +0100

> Also, since we already have to bootstrap an auto-configuring routing
> protocol, why not leverage this work to distribute other information? 

As usual, it's a tradeoff, and the choice of tradeoff is dependent on
one's background.

Those of us who come from the Free Software chaos will prefer small,
self-contained protocols that can be implemented by small, loosely
coupled groups of developers, and that communicate through well-
defined, stable APIs.

Those who come from large, well-managed, centralised organisations
will prefer large protocols, and won't want to bother with the tricky
job of defining stable interfaces between loosely coupled software
components.

To put it differently -- with Dave's help, we should have no trouble
pushing a self-contained configuration daemon into OpenWRT and from
there to other Linux and BSD systems.  We will find it somewhat more
challenging to add the proposed sub-protocol to all of the Open Source
implementations of OSPF and ensure that it's compiled-in by default.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sun, 2 Feb 2014 09:15:58 -0800

On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem <[email-masked]> wrote:
> I agree. Also, since we already have to bootstrap an auto-configuring
> routing protocol, why not leverage this work to distribute other
> information?

Because routing protocol authors are generally hostile to adding
what is effectively dhcp-like support to their protocols and daemons?

> On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek
> <[email-masked]> wrote:
>>

Several comments:

1) The synchonicity problem exists for multiple layers of the stack.
Take DNS for example, when addresses change, dns needs to change also.
It's very hard with any form of centralized server for dns to make
that fast or atomic.

2) All the interdependencies on config and routing and dns for a
highly dynamic ipv6 world are forcing daemon writers to adopt a
software bus structure to broadcast and respond to changes to various
subsystems controlled by various daemons.

In the linux world at least, system configuration information is
propigated between daemons mostly along the dbus, and the openwrt folk
have implemented a ubus that is lighter weight, that communicates
between dhcpv6, dns, dhcpv4 and other daemons.

So what's needed is a clear delination of responsibilties for
acquiring and pushing out changes to the underlying network
architecture, and it doesn't matter what protocol on the wire those
run over.

3) So far in dealing with highly dynamic ipv6, and poor interfaces to
DNS in particular in the real world, I despise it and go back to
wanting a /48 distributed with my house, or at least, some way to buy
one from my ISP.

4) In my case at least the prefix distribution problem aint'  problem
'cause I just ship /128s everywhere I need 'em with AHCP.

/me ducks

Yes, distributing prefixes is needed.

5) To finally get to your own point, there is no need to poll at the
protocol level, the daemons on the responsible routers need be aware
of changes and push them. Ideally there is some level of
authentication involved,
particularly in changes pushed like "forcibly retract this ipv6 prefix
and use this one instead because my provider just changed me for no
f-ing good reason")

We've demonstrated that a protocol like AHCP can do that, (and nobody
is suggesting that AHCP as currently defined is sufficient, it merely
serves as a convenient counter-example to the
embed-everything-in-the-routing protocol thread, that anybody can
install and run, as it's been available in linux for 6+ years....)

6) A well defined set of TLVs and actions for border discovery, nat
detection in ipv4, and carrying dns, ntp, and other core services is
needed no matter how they are distributed.

7) I generally despair of this entire debate, and wish more people
were writing code, doing experiments, and working inside the real
world. I hate that this discussion has ratholed on the method of
distribution, rather on than on "what configuration information needs
to be propagated inside the home on zigbee, wifi, lte, moca, homeplug,
in order to have grandma be able to get her pr0n and meds from her
high-tech wheelchair. "

me, for example, am observing how src/dst routing works in the real
world, and am trying to improve it, deal with bcp38 and vpn
technolgies, etc. There is a lot of work to be done to defeat in
detail all the existing problems, and I argue strongly for trying
stuff, iterating, and trying more stuff, until a viable
standard for these problem emerges...

... and that, is probably the basic beef I have in modifying an
existing routing protocol. Solving configuration distribution and
border discovery, and nat detection, and core service distribution -
needs a design small, flexible, and rapidly iterate-able, and
*separate*, for these problems.

I certainly wish we could foresee all problems in advance; we
obviously can't (two years on this thread running), something flexible
and iterate-able is needed.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 13:01:11 -0500

On Feb 2, 2014, at 12:15 PM, Dave Taht <[email-masked]> wrote:
> I hate that this discussion has ratholed on the method of

This is a really good point.   The architecture document is supposed to have tried to address this, but I take it from your complaint that you don't think it does.   Could you provide some suggestions for what the next steps to address this problem should be?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Feb 2014 07:58:33 +1300

> what is effectively dhcp-like support to their protocols and daemons?

I think there's a reason for that "hostility", which is that in some
sense everything other than routing is less fundamental, and we need
to protect routing from the rest by isolating it. If routing fails,
nothing else can work, after all. So there's a tendency to keep
the routing protocols "pure".

However, the great thing about routing protocols is that they really
are very close to autonomic, and we need that instead of traditional
top-down configuration. Despite the protests, I detect hints of
top-downness in many of the messages on this thread. Apart from
external routes and available global prefixes, what else *needs*
to be top-down in a homenet?

   Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 20:17:59 +0100

> Despite the protests, I detect hints of top-downness in many of the
> messages on this thread.

Yes, it's an easy mistake to make.  You're right, we should be very
vigilant about that.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sun, 2 Feb 2014 11:20:39 -0800

> the routing protocols "pure".

I will definately argue that a more extensible protocol than a routing
protocol or dhcp as currently defined is needed for configuration.

given the ubiquity of http servers, additional configuration could be
carried by propagating a configuration server url around (and or leveraging
sddp/upnp/pcp/dns-sd).

> to be top-down in a homenet?

1) What time is it?

I would personally like it if ntp over ipv6 was encrypted and
multicast within your own borders. I'd settle for all boxes within a
homenet agreeing on the same set of what local time servers are
definitive.

2) Where are my dns server(s)? What do they serve addresses for? The
dns scoping problem has not been addressed here, and it gets horribly
complex rapidly in the presence of multiple isps, vpns, and other
services like the nest stuff. Your vpn is probably going into split
dns in particular...

3) As a couple straw men...

my opposition to iw10 universally is probably pretty well known. The
relevant rfc and research in favor of it was skewed in favor of stuff
coming from high speed/high bandwidth servers...

http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00

...instead of the behavior of apps sending stuff from your local (much
slower) network to the internet.

http://tools.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt

The observable spike from iw10 is quite large on egress from slower
networks, and especially damaging on single queue aqm systems like
codel and pie.

now it turns out iw10 (initcwnd), mtu, and can be set on a per route
basis (at least in linux), and I would not mind at all if my route to
the each source specific gw to the internet from my slower net
advertised a saner iw, and correct pmtu.

That is pretty top-down, and it would be probably best to carry that
info in the routing protocol. (/me ducks)

4) There is a long list of things supplied currently by dhcp, many of
which are obsolete (impress server anyone?), that would be worth going
through in detail. I imagine that there are multiple rfc's following
this one:

http://tools.ietf.org/search/rfc2132

there are many lessons to be learned from dhcp.

-- 
Dave Täht

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Feb 2014 20:53:40 +0100

> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02

I've now read this draft.  Section 2.4 says things that I never even
considered, and I need to think it over.  (In particular, functionality
such as what you describe there would be marvelous for monitoring tools.)

There's only one point that I disagree with.  In Section 4 you say:

    Multi-party negotiations are too complicated to be modeled and
    there may be too many dependencies among the parties to converge
    efficiently.

If I read you right, you're disallowing the familiar claim/defend
scheme, where a node claims an address over multicast, and waits for
other nodes to disagree.  (The best-known case is probably that of
DHCPv4, where implementations commonly make an ARP query before
assigning an address, but there's no reason why this shouldn't be an
intrinsic part of the configuration protocol.)

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Feb 2014 11:58:05 -0800

> to be top-down in a homenet?

If you're worried about isolation, you could always run the same routing
protocol -- modified to carry your payloads --  on, say, a different 
port and
modify the daemon to not touch the fib.

Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 03 Feb 2014 10:04:45 +0100

Le 02/02/2014 17:47, Acee Lindem a écrit :
> I agree.

I disagree questioning what happens when the routing protocol finds out
that even though the delegation protocol things everything is ok and
addresses were delegated justfine the network becomes partitioned.

First, I would try to understand what is meant by partitioned network.
I have heard this term in the MANET/AUTOCONF discussion as well; there
it was high level just to give a feeling about how a network would
become disconnected.  But less of a real experience.

Then, a delegation protocol (DHCP-PD, see the other threat), is guided
by a pre-configured database.  That database should be in sync with the
routing protocol pre-configured database.  If these two files are not
sync'ed then it's the planners fault.  Or otherwise automatic means
exist to make them be in sync.

Also, plugging the DHCP prefix delegation protocol into the routing
protocol would be a two-way process, not just one=way: DHCP-PD would
inform the routing protocol daemon about the allocation, subsequently
this latter would update some local routes; but also - if the routing
protocol finds there are some loops then it reports an error to the DHCP
PD daemon.

One should also take into account that a routing protocol doing prefix
delegation at the same time as DHCP-PD (without knowledge one of the
other) is probably goign to become a source of contention.

> protocol, why not leverage this work to distribute other

I do not disagree with this.  I think it is meaningful direction as well.

Alex

>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> I fail to see how this particular functionality requires merging
>> the two protocols.  If a link is partitioned, you need to time-out
>> the address assignments made by the now unreachable router. Whether
>> they are timed out by the routing protocol or by a separate
>> configuration protocol is pretty much an implementation detail,
>> isn't it?
>>
>>
>> The routing protocol knows that the network is partitioned because
>> that's what it does. How is the configuration distribution protocol
>> going to know that? Either you couple it to the routing protocol,
>> or you have it poll to see if things have changed (inefficient
>> and/or slow to notice changes). Why would you do the latter?
>
>
>
> _______________________________________________ homenet mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Feb 2014 10:05:49 +0100

> in order to have grandma be able to get her pr0n and meds from her

apart from the sentence making it appear that "configuration information" hinges on data-link type, I think you make an important point.

what information needs to be propagated in the home?
since this is the homenet working group, we limit ourselves to getting the network layer functional.
that in my mind is: addressing, unicast routing, service discovery, external naming, other host configuration, and time.

unicast routing:
 - internal routes (assigned /64s and ULA)
 - SADR routes for PD prefixes
   (either explicit SADR or implied as part of prefix assignment)
 - More specific external routes (learnt via RFC4191 or other configuration)
   requires explicit SADR

addressing:
 - PD prefixes
 - ULA prefixes
 - whatever assigned prefixes required for the prefix assignment algorithm to function
 - meta data associated with prefixes (SAS/DAS policy, colour)

service discovery:
 - DNS zones for the bootstrapping the mDNS scheme

external naming:
 - I don't see how we can make this zero-conf. each border router could run hidden primaries for the reverse zone.
   if you get forward zones from the ISPs, then applications could update each of those primaries using DNS update.
   assuming we can bootstrap security. if the home has a vanity name, then the hidden primaries must run on
   some well known address in the home, and there has to be some agreement with either ISP or someone else
   to run secondaries.

other host configuration:
 - this is information learnt from external connections, homenet defaults and configuration provided by the user.
   basically externally learn from RA/DHCP, and passed transparently through the homenet, for homenet routers
   to propagate to hosts using DHCP/RA
 - DNS recursive resolvers
 - DNS server selection policy
 - SAS/DAS policy
 - NTP servers
 - whatever else is required for configuration of the network layer

we could put these into three different classes:
1) addressing / routing
2) configuration information for the homenet routers
3) configuration information for hosts
    (that the homenet passes transparently from some source to hosts)

addressing and routing are inherently tided together. the home network is quite useless without either of them functioning.
if we look at a routing protocol as just a distributed database, it might not matter what we put into it, although it makes my tummy churn to think about embedding DHCP options into OSPF. ;-)

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 03 Feb 2014 13:51:09 +0100

Le 30/01/2014 14:03, Ole Troan a écrit :
> Alex,
>
> changing the thread since this seems to diverge from getting answers to the questions I asked.
>
> cheers,
> Ole
>
>
> On 30 Jan 2014, at 13:55 , Alexandru Petrescu <[email-masked]> wrote:
>
>> Pierre,
>>
>> Thanks for the reply.
>>
>> Le 30/01/2014 13:46, Pierre Pfister a écrit :
>>>
>>> Le 30 janv. 2014 à 13:38, Alexandru Petrescu
>>> <[email-masked]> a écrit :
>>>
>>>> Le 30/01/2014 13:28, Ole Troan a écrit :
>>>>>>>> Could it be separate (existing) protocol?
>>>>>>>
>>>>>>> if one had existed, sure. requirements from homenet-arch (I
>>>>>>> might have missed some): - must support multi-homing - each
>>>>>>> link should be assigned a stable prefix - efficient
>>>>>>> allocation of prefixes - should support both IPv4 and IPv6
>>>>>>
>>>>>> I meant this:
>>>>>>
>>>>>> loosely coupled ---- separate (existing DHCPv6-PD) protocol
>>>>>> triggering route updates to the routing protocol.
>>>>>
>>>>> yes, DHCP PD comes up as a proposed solution quite frequently. I
>>>>> just don't see how you can make DHCP PD fulfill the
>>>>> requirements.
>>>>
>>>> Well it does support multi-homing (Server allocates things to as
>>>> many interfaces as needed), each link can be assigned a stable
>>>> prefix (provided it triggers updates to the Routing protocol), the
>>>> allocation is efficient (Server maintains dynamic databases,
>>>> leases) and it supports both IPv4 ('IPv4 subnet allocation'
>>>> RFC6656, DHCP transition et alia), and IPv6.
>>>>
>>>> I miss something?
>>>
>>> Well, in some cases DHCP seems to work, but not when you start
>>> imagining multi-homed networks with multiple routers. Or maybe you
>>> can tell me how to solve this situation with DHCP:
>>>
>>> You have ISP1 connected with Router 1. ISP2 connected with Router 2.
>>> Router 1, Router 2, and a third Router (Router 3), are connected on
>>> the same link. ISP1 is delegated the prefix A/56 to Router 1. ISP2
>>> is delegating the prefix B/56 to Router 2.
>>>
>>> A host is connected behind Router 3.
>>
>> Bear with me for a moment... is this topology what you meant?
>>
>>
>>       ISP1               ISP2
>>        |                  |
>>     +-------+          +-------+
>>     |Router1|A/56      |Router2|B/56
>>     +-------+          +-------+
>>        |                  |
>>      --+-------+----------+--
>>                |
>>                |
>>            +-------+
>>            |Router3|
>>            +-------+
>>                |
>>              +----+
>>              |Host|(how can it get an address from A, and from B)
>>              +----+

In this setting the Router3 could run two DHCPRelay processes, and 
Router1 and 2 would be Servers.

This would allow Host to obtain an address from each (==multi-homed).

Alex

>>
>>
>>> How can it get addresses from both prefixes ?
>>
>> Before I try to figure it out - is the above topology what is meant? Something I misplaced?
>>
>> Alex
>>
>>>
>>> Cheers,
>>>
>>> Pierre
>>>
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> cheers, Ole
>>>>>
>>>>
>>>>
>>>> _______________________________________________ homenet mailing
>>>> list [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Mon, 3 Feb 2014 14:11:11 +0000

On 3 Feb 2014, at 12:51, Alexandru Petrescu <[email-masked]> wrote:

> In this setting the Router3 could run two DHCPRelay processes, and Router1 and 2 would be Servers.
> 

It could, but assume that Router3 doesn't yet know anything about the upstream topology.

Ray (no hat)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2014 09:19:04 -0500

> will come in some sense top-down from a higher level source of

I'm not sure that he is making this assumption.
There are clearly sources of authority for various things: the border router(s)
know about the services from the ISP(s) they are connected to.
I might also say, "the printer knows that it is a printer", but that already a
solved problem.  The key thing is that some component knows that the local
zone is carpenterhouse.example.com, and may let the printer know that, so
that it can advertise that name into the right places.

    > I believe that exactly the same approach is needed for homenets.

I read the beginnging of the document, and it seems in sync with with Juliuz
is actually talking about.   I did not find enough motivation in the document
for what is desired.

I am also skeptical that there are significant configuration things in the
homenet which ultimately need to share fate with connectivity.

I am most worried that we really have no process here to make a decision.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 03 Feb 2014 15:24:02 +0100

> It could, but assume that Router3 doesn't yet know anything about

Right, so it would need to discover it - a DHCP Server discovery
mechanism performed by Relay.

I doubt the multi-homing requirement as such would be a criterion to
simply discard DHCP-PD.

(w/o comparing alternatives, I would say that routing protocols also
need something like a discovery procedure when they dont know yet their
upstream).

Alex

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2014 09:27:30 -0500

> coupled groups of developers, and that communicate through well-

Yes, I've lived in this space for 20+ years.

In that space, we still don't have a DHCP client which can sensibly interact
with an 1X supplicant in order to get me on a network which has a working
layer-3 uplink, even though the layer-2 signal strength is not the strongest.
(I call then "NOTworks", an AP sitting somewhere with a broken DSL link)

NetworkManager and its equivalent in Android is closest we have gotten, and
there are still significant issues: they are getting better, but it hasn't
been fun.

And it's not the size of the protocol that really matters.
One problem that the free software chaos suffers from is that much of the
tools that we have (quagga, ISC DHCP, for instance) are designed by
"big organizations" for "big organizations".

    > job of defining stable interfaces between loosely coupled software

I think that are significantly overstating this situation.
Big organizations are seldom well organized or well managed, and they hate
forklift upgrades, so they actually prefer small incremental additions as
well.

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 3 Feb 2014 07:39:10 -0700

>> This would allow Host to obtain an address from each (==multi-homed).

I’m not sure DHCP Relaying was intended to work with different DHCP servers. In any case, DHCP client was not.

We can’t ask routers to relay DHCP from whatever DHCP server they obtain something from. In the case Router 2 has the same problem as router 3, we would have two relays ? And so on ? It would require a discovery mechanism and only the very first owner of a prefix would provide the addresses. In which case it would probably need knowledge of the network. And suddenly it starts looking like a different configuration protocol. At least it doesn’t look like how DHCP was designed first.

Over more, if you put a host instead of Router 3, we would need the host to have multiple DHCP server. So it not only is inefficient in terms of addressing, but requires changes to the hosts… And assuming multiple DHCP server is not, in my mind, a small change.

Pierre

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 09:51:35 -0500

> I’m not sure DHCP Relaying was intended to work with different DHCP servers. In any case, DHCP client was not.

This is not actually true.   RFC 3315 was written with the clear anticipation of the possibility that a DHCP client might talk to multiple DHCP servers.   It doesn't specifically require this behavior, and it doesn't always make sense, but if you have two managed prefixes on a wire, I would expect a DHCP client to try to configure both of them, and if two DHCP servers each manage one of the prefixes, I would expect the DHCP client to wind up getting configurations from two servers.

It may be that we weren't clear enough on this point, but that was definitely an anticipated use case.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Feb 2014 10:00:10 -0500

> homenet which ultimately need to share fate with connectivity.

Let me try again:
I am also skeptical that there are significant configuration things in the
homenet which *do not* ultimately need to share fate with connectivity.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 10:29:52 -0500

> homenet which *do not* ultimately need to share fate with connectivity.

ULA seems like an obvious example.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Feb 2014 11:06:18 -0800

> definitely an anticipated use case.

Perhaps, but if implementations don't actually do this (and I don't think
they do), then it doesn't really matter what the intent was.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 14:51:52 -0500

On Feb 3, 2014, at 2:06 PM, Lorenzo Colitti <[email-masked]> wrote:
> Perhaps, but if implementations don't actually do this (and I don't think they do), then it doesn't really matter what the intent was.

There are no homenet router implementations.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 10:32:34 +1300

Juliusz,

> intrinsic part of the configuration protocol.)

I don't think we intended to exclude that, but there may well
be scenarios where suitably scoped multicast isn't available.

We were concerned about guaranteed convergence in a multi-party
scenario, which seems tractable with (reasonably reliable)
multicast. Anyway, this aspect needs more thought, thanks!

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2014 10:36:45 +1300

> ULA seems like an obvious example.

If the network gets split, ULA connectivity breaks too.

    Brian

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Feb 2014 13:40:45 +0200

> There are no homenet router implementations.

Given N*10^8+ (conservative estimate, N some single digit probably) potential homenet hosts already out there and 0 homenet routers, designing with the assumption that ‘yeah, hosts can change’ doesn’t sound too reasonable to me.

Then again, what’s wrong with fighting windmills?

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 08:46:08 -0500

> Then again, what’s wrong with fighting windmills?

We're talking about prefix delegation.   Prefix delegation runs on routers, not hosts.

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Feb 2014 15:09:21 +0100

> We're talking about prefix delegation.   Prefix delegation runs on routers, not hosts.

actually, we're talking about prefix assignment. which may be splitting hairs, but isn't quite the same as prefix delegation.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 09:16:37 -0500

> actually, we're talking about prefix assignment. which may be splitting hairs, but isn't quite the same as prefix delegation.

Splain?   You mean we're talking about the general problem, rather than the DHCP-PD solution?   If so, that's fine, but the specific comment that Markus made was about DHCP PD, and that's what I was responding to.   I am not specifically advocating the use of DHCP PD to solve this problem, but I do want to see it evaluated realistically, and not on the basis of a misunderstanding of what it does and how it's used.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Feb 2014 09:58:41 -0500

To quote from the charter:

  Prefix configuration, routing, and security 
  related work shall not cause any changes that are not backwards 
  compatible to existing IPv6 hosts. There may be host visible changes 
  in the work on naming and discovery protocols, however. 

"backwards compatible" doesn't mean that we can't write down things where a
smarter newer host can get better service.  It means that existing hosts must
get some kind of service, regardless.

---

From: Teco Boot <[email-masked]>
Date: Tue, 4 Feb 2014 16:35:57 +0100

Op 2 feb. 2014, om 06:41 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> You can't reliably deprecate information in DHCP. Even if the client supports the reconfigure option, deprecating something in DHCP requires that the server that has the original nonce still be up and around.
> 
> This is why DHCP is not a good protocol to use in a distributed, unreliable network like a homenet.

Enterprise networks transform to distributed, unreliable networks (wireless access, BYOD with cellular access, sensors). At least some of them. Replace DHCP?

I do not suggest full end-to-end DHCP connections from hosts to single DHCP server. I suggest structuring the Homenet somewhat, with clearly defined services for different tasks. I don’t see a problem using DHCP server on CPE box managing info for ISP connected via that box. And a DHCP server on leaf routers managing info provided to attached clients. Why not using DHCP between?

Your reachability dependency argument is solved easily, let’s mandate the Homenet DHCP server advertises its DHCP server address (/128) in the routing protocol. Homenet routers watch these entries.

Why not let Homenet routers MUST implement DHCP reconfigure extension, at least for their DHCP Client function?

Of course I suggest DHCP as just one of the Homenet components.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 4 Feb 2014 16:51:24 +0100

> It could, but assume that Router3 doesn't yet know anything about the upstream topology.

We have to come up with border router discovery. Are you interested in details on transient state right now?

Teco

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Feb 2014 17:35:14 +0100

> First, I would try to understand what is meant by partitioned network.

  http://www.ietf.org/rfc/ien/ien110.txt
  http://www.ietf.org/rfc/ien/ien146.txt

-- Juliusz (who sometimes enjoys reading old papers)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Feb 2014 18:02:37 +0100

> -- Juliusz (who sometimes enjoys reading old papers)

Thanks.  It is indeed enjoying to see how far this term comes from.

Ok, a homenet may become partitioned if grandma's IPv6 Access Point only
links a smartphone to a scale, but not to the Internet.

To avoid the homenet partitioning, one would need a means for the Access
Point to connect to the Internet, get prefixes, advertise prefixes,
self-configure prefixes, deliver addresses, establish routes, forward
end-to-end traffic (w/o touching other fields than the Hop Limit)
seamlessly, with zero pre-configuration.

Alex

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Feb 2014 19:10:29 +0200

> We're talking about prefix delegation.   Prefix delegation runs on routers, not hosts.

Quoting you:

This is not actually true.   RFC 3315 was written with the clear anticipation of the possibility that a DHCP client might talk to multiple DHCP servers.   It doesn’t specifically require this behavior, and it doesn't always make sense, but if you have two managed prefixes on a wire, I would expect a DHCP client to try to configure both of them, and if two DHCP servers each manage one of the prefixes, I would expect the DHCP client to wind up getting configurations from two servers.

I thought you were asking for host changes to support multiple servers (even if RFC says they should, and I’m not sure it does, I have yet to find one that does).

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 12:23:01 -0500

> I thought you were asking for host changes to support multiple servers (even if RFC says they should, and I’m not sure it does, I have yet to find one that does).

I think host changes to make this work will be crucial to having hosts that can operate on multiple prefixes managed by different organizations on the same wire, but I don't think that homenet clients need this, because most likely they'll be doing SLAAC, and maybe getting some local configuration parameters with stateless DHCP, which themselves would have to be derived automatically by the homenet, either through internal communication or from externally-received information.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Feb 2014 18:13:55 -0500

Pierre Pfister <[email-masked]> wrote:
    >> Prefix configuration, routing, and security related work shall not
    >> cause any changes that are not backwards compatible to existing IPv6
    >> hosts. There may be host visible changes in the work on naming and
    >> discovery protocols, however.
    >> 
    >> "backwards compatible" doesn't mean that we can't write down things
    >> where a smarter newer host can get better service.  It means that
    >> existing hosts must get some kind of service, regardless.

    > In a multi-homing case, multiple ISP would provide multiple
    > prefixes. It is expected that, with colored prefixes, each prefixes
    > will be attached dedicated services. When there is a single ISP,
    > DHCP-PD can serve the prefixes correctly to the host. But in a

There are a number of possibilities where "backwards compatible" might mean
different things. Let's take your voice application example:

> For instance, if a prefix is for general purpose, and another is for voice
> applications, then hosts may only get addresses for voice application, and
> would therefore not being able to access the internet.  

So, prior to homenet, what happens? (If the answer is no v6, then stop.)

If it that the phones get plugged into the voip router, and the computers
get plugged into the internet router, and the two are not connected, then
that is in fact still an option.

If the routers are upgraded with homenet, and now interconnected then to
remain backwards compatible I would expect:
  1) the phones without required upgrades to remain plugged into the voice
     router.
  2) hosts that can accept two prefixes and pick the right prefix can
     run the soft voice application.
  3) hosts that can not accept two prefixes (really? that's in the spec
     for a long time), would have a problem. They weren't to spec.
  4) hosts that can accept two prefixes would attempt to use the voice
     prefix for internet access, get a no-route-to-host, and happy
     eyeballs would do the right thing.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Feb 2014 15:49:58 +1300

> Pierre Pfister <[email-masked]> wrote:
...
>> would therefore not being able to access the internet.  

Yes, that's one of many reasons why using prefixes to distinguish
types of traffic is a really bad idea.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Feb 2014 08:15:10 +0100

Ted,

> I think host changes to make this work will be crucial to having hosts that can operate on multiple prefixes managed by different organizations on the same wire, but I don't think that homenet clie…

yes, and with the "derived automatically" mechanism you could also use DHCP for address assignment.
the homenet side of the routers "managed by different organisations" would of course have to be managed (or non-managed) by the homenet itself.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Feb 2014 09:04:50 +0100

Ted,

> Splain?   You mean we're talking about the general problem, rather than the DHCP-PD solution?   If so, that's fine, but the specific comment that Markus made was about DHCP PD, and that's what I wa…

as one of the authors of RFC3633, DHCP PD was not designed to do assignment of prefixes inside a network.
DHCP PD was designed to be a "fax replacement".

there has been a number of proposals for how DHCP PD could be adapted for this purpose:

they generally fall into one of flat assignment with central DHCP server or hierarchical PD with a spanning tree of DHCP relays.

http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01
http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-01
http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf-01
http://tools.ietf.org/html/draft-grundemann-hipnet-00

please take a look at those drafts, and let us know what we've missed in the DHCP PD "solution space".

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Feb 2014 09:06:54 +0100 (CET)

> types of traffic is a really bad idea.

The idea is that "non color-aware" devices will only use the "Internet" 
prefix, by means of the colored prefixes will use a different ND PIO type 
for prefix announcement (thus invisible to these non color-aware hosts), 
plus DHCPv6 server would only hand out prefixes/addresses to hosts that 
request them.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Feb 2014 13:04:14 +0100

Le 05/02/2014 09:04, Ole Troan a écrit :
> Ted,
>
>>> actually, we're talking about prefix assignment. which may be
>>> splitting hairs, but isn't quite the same as prefix delegation.
>>
>> Splain?   You mean we're talking about the general problem, rather
>> than the DHCP-PD solution?   If so, that's fine, but the specific
>> comment that Markus made was about DHCP PD, and that's what I was
>> responding to.   I am not specifically advocating the use of DHCP
>> PD to solve this problem, but I do want to see it evaluated
>> realistically, and not on the basis of a misunderstanding of what
>> it does and how it's used.
>
> as one of the authors of RFC3633, DHCP PD was not designed to do
> assignment of prefixes inside a network. DHCP PD was designed to be a
> "fax replacement".

That may be one of the original intents, I dont doubt it, and I am happy
to see it that way (although I wonder what in a fax uses prefixes).  And
I disagree with the statement that DHCP PD to be just a quote fax
replacement.

It's been also used for moving networks, like in RFC6276 and in the
upcoming to some extent it a 'proxy' form.

> they generally fall into one of flat assignment with central DHCP
> server or hierarchical PD with a spanning tree of DHCP relays.
>

The picture is interesting and one would have to look at them.  I would
specifically look for whether they suggest means to dynamically
configure the relationship between the Relay and the Server.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Feb 2014 13:13:37 +0100

Le 05/02/2014 09:06, Mikael Abrahamsson a écrit :
> prefix, by means of the colored prefixes will use a different ND PIO
> type for prefix announcement (thus invisible to these non color-aware
> hosts), plus DHCPv6 server would only hand out prefixes/addresses to
> hosts that request them.

A color could also be a particular value for the flow label field.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 08:08:34 -0500

> please take a look at those drafts, and let us know what we've missed in the DHCP PD "solution space".

I've read all those drafts at one time or another.   I just checked the latest version of http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it appears to do pretty much the right thing.

One thing that isn't mentioned in that draft that I don't think is intuitive to all readers is that if you have two CERs, this technique still works; the only difference is that the technique has to be done independently by each internal router with respect to each CER.

This draft also does not appear to talk about how to get rid of prefixes to CERs that have failed.   Ideally the homenet routing protocol server could signal the DHCPv6 PD requesting router server when a CER has gone away, or else the PD requesting router server could poll for that information from time to time (you want a little hysteresis to avoid needlessly dropping prefixes in the event of a router reboot, of course).

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Feb 2014 15:01:01 +0100

Ted,

> One thing that isn't mentioned in that draft that I don't think is intuitive to all readers is that if you have two CERs, this technique still works; the only difference is that the technique has t…

you make it sound like that's a part and parcel of DHCP. I can't see how you can implement that today.
are there any implementations doing this? I have never seen any.
as an example of the problems you'll encounter. how does the RR detect the difference between a backup DR and a separate DR? first case it should pick the best server, second case it should set up sessions to both.

> This draft also does not appear to talk about how to get rid of prefixes to CERs that have failed.   Ideally the homenet routing protocol server could signal the DHCPv6 PD requesting router server…

"homenet routing protocol server"? this proposal makes do with static routing.

given an arbitrary topology.
how do you build the relay topology and discover DHCP servers?
   use site-local multicast -> we don’t quite know how to bootstrap that?
   hop-by-hop relaying? how do you deal with loops?
   you're essentially building a spanning tree of relays.
how do you deal with multiple routers on the link? just keep adding /64s out of the same site-prefix to it?

how does the network react to network events? given you rely on DHCP snooping then network convergence time
is rather glacial.

while DHCP PD may look like a candidate at first glance, to make it work in all corner cases, you essentially build something quite different than current DHCP. then you might as well use a real routing protocol and a prefix assignment protocol designed for the purpose.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 09:13:01 -0500

> you make it sound like that's a part and parcel of DHCP. I can't see how you can implement that today.

Eh?   It's dead trivial.   The draft already sets up relay agents—the only difference is that all relays now relay to both CERs, not just one.   The requesting routers get delegations from both CERs and use both delegations.

You are right that no existing implementation does this, but no existing implementation does homenet, so that seems like a pretty mild criticism!   :)

> "homenet routing protocol server"? this proposal makes do with static routing.

When I said the proposal looked mostly right, I was referring to the DHCP PD aspect, not the static routing aspect.   Static routing might work, but I suspect it would be brittle.

> how do you deal with multiple routers on the link? just keep adding /64s out of the same site-prefix to it?

Only the CERs delegate prefixes.  If you have multiple paths to the same CER, you will still only get one prefix per identity association.

> how does the network react to network events? given you rely on DHCP snooping then network convergence time

Right, I'm not arguing that we don't need a routing protocol.   I'm not even particularly arguing that PD is the right way to delegate prefixes.   But it would work, and with no protocol changes—it would just require an operations document to explain how to do it.

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Feb 2014 15:33:24 +0100

Ted,

> Eh?   It's dead trivial.   The draft already sets up relay agents—the only difference is that all relays now relay to both CERs, not just one.   The requesting routers get delegations from both CER…

you cut out my question about how to build the relay topology.
e.g. relays would have to replicate client messages to multiple CERs.

> You are right that no existing implementation does this, but no existing implementation does homenet, so that seems like a pretty mild criticism!   :)

a goal for homenet is to reuse existing implementations.

> Only the CERs delegate prefixes.  If you have multiple paths to the same CER, you will still only get one prefix per identity association.

a link with multiple routers on it will get multiple prefixes from the same site prefix.

> Right, I'm not arguing that we don't need a routing protocol.   I'm not even particularly arguing that PD is the right way to delegate prefixes.   But it would work, and with no protocol changes—it…

I see you are making that assertion. I don't believe you.
please write a draft how this would work.

cheers,
Ole

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Feb 2014 16:57:11 +0100

> please write a draft how this would work.

http://tools.ietf.org/html/draft-boot-homenet-brdp-00

Older „autoconf” version was implemented in opnet, the protocol itself worked, routers (and hosts) were aware of Border Routers (the CPE boxes with DHCP PD server) and exit links to ISPs with corresponding prefixes. The autoconfig part was not implemented. It was tailored for MANET / Autoconf space, not for more static Homenets.

Now I work on multi smart-gateway for IPv4 (hmm), build on top of olsrd (v1). It uses tunnels (instead of SADR). Tunnel management, exit link detection and route policy management is in separate daemon. We learned before we should not overload the routing daemon.

Multi smart-gateway is prepared for IPv6. Future work is port_on_top_of or line_up_with OLSRv2 (RFC to be) and adding full IPv6 support based on SADR, not on tunnels. Using same mechanism in MANET as in Homenet has our preference. I cannot see much difference.

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Feb 2014 19:54:10 +0100

Le 05/02/2014 15:01, Ole Troan a écrit :
>> I've read all those drafts at one time or another.   I just
>> checked the latest version of
>> http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and
>> it appears to do pretty much the right thing.
>>
>> One thing that isn't mentioned in that draft that I don't think is
>> intuitive to all readers is that if you have two CERs, this
>> technique still works; the only difference is that the technique
>> has to be done independently by each internal router with respect
>> to each CER.
>
> you make it sound like that's a part and parcel of DHCP. I can't see
> how you can implement that today. are there any implementations doing
> this? I have never seen any. as an example of the problems you'll
> encounter. how does the RR detect the difference between a backup DR
> and a separate DR? first case it should pick the best server, second
> case it should set up sessions to both.

Ole,

I think the RR would not need to detect a full difference, but maybe to
obtain prefixes from both, and subsequently distinguish between them
maybe based on some preference values.

If I am not wrong the same scheme of preferences based on lifetime as ND
uses, is also used in PD (valid  lifetime and preferred lifetime).

I guess the RR could also indicate some preference value when requesting
prefixes.

It would then come down to a more intelligent decision making at the RR.

Obtaining two prefixes from two different servers is not that huge of a
problem, I think.

>> This draft also does not appear to talk about how to get rid of
>> prefixes to CERs that have failed.   Ideally the homenet routing
>> protocol server could signal the DHCPv6 PD requesting router
>> server when a CER has gone away, or else the PD requesting router
>> server could poll for that information from time to time (you want
>> a little hysteresis to avoid needlessly dropping prefixes in the
>> event of a router reboot, of course).
>
> given an arbitrary topology. how do you build the relay topology and
> discover DHCP servers?

I think it is good to question how would Relays discover servers.

But that does not mean that OSPF-or-other-routing-protocol doesn't need
same thing.

Where one questions the use of multicast - OSPF also relies on it.

> use site-local multicast -> we don’t quite know how to bootstrap

OSPF also relies on same multicast paradigm.  If we know how to do it
for OSPF then we'd know for DHCP as well.

> hop-by-hop relaying?

?

> how do you deal with loops?

Loops in a small setting like a homenet may be primarily a matter of
where does the default route point to.  In the immediate, one wants to
make sure these default routes don't lead to loops.  This is a reason
why one may question how is the default route delivered.

A routing protocol which maintains routes will indeed detect loops, but
will do little in itself to inform a Host that what it believes to be a
default route should not be used.  A routing protocol needs to rather
inform a Router to modify its radvd.conf towards that Host.  That isn't
implemented either in widespread implementations, as far as I know.

Or, one wouldn't want a routing protocol to replace RA for the default
route, right?

> you're essentially building a spanning tree of relays. how do you
> deal with multiple routers on the link? just keep adding /64s out of
> the same site-prefix to it?
>
> how does the network react to network events? given you rely on DHCP
> snooping then network convergence time is rather glacial.
>
> while DHCP PD may look like a candidate at first glance, to make it
> work in all corner cases, you essentially build something quite
> different than current DHCP. then you might as well use a real
> routing protocol and a prefix assignment protocol designed for the
> purpose.

Hm.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Feb 2014 08:15:32 +1300

> A color could also be a particular value for the flow label field.

No, a DSCP. The flow label value is supposed to be opaque with
no semantics.

We designed diffserv for this purpose and it works well and is quite
widely used in corporate networks. Wasting prefixes to distinguish
traffic types is an incredibly bad idea.

     brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 6 Feb 2014 08:46:14 +0100 (CET)

> traffic types is an incredibly bad idea.

Problem with DSCP is that you have to reset them for a non-qos service in 
your network (unless you're running some kind of encapsulation scheme such 
as tunnels or MPLS).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Feb 2014 08:39:11 +1300

On 06/02/2014 20:46, Mikael Abrahamsson wrote:
> Problem with DSCP is that you have to reset them for a non-qos service
> in your network (unless you're running some kind of encapsulation scheme
> such as tunnels or MPLS).

Sorry, what, why? DSCP is a no-op for a router that doesn't
implement diffserv, so why would you ever need to reset them?
(It's normal for border routers to clear the DSCP if they want to,
of course; no harm, no foul.)

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Feb 2014 16:54:12 -0800

On Wed, Feb 5, 2014 at 11:46 PM, Mikael Abrahamsson <[email-masked]>wrote:

>> widely used in corporate networks. Wasting prefixes to distinguish traffic
>> types is an incredibly bad idea.
>>
>

This is no different from what you need to do with prefixes, due to BCP 38.

DSCP: When a packet comes in, you check DSCP, and possibly rewrite it.
Prefix: When a packet comes in, you check the source / dst prefix, check
DSCP, possibly drop the packet, and possibly rewrite DSCP.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Feb 2014 04:10:14 +0100 (CET)

On Fri, 7 Feb 2014, Brian E Carpenter wrote:

> Sorry, what, why? DSCP is a no-op for a router that doesn't implement 
> diffserv, so why would you ever need to reset them? (It's normal for 
> border routers to clear the DSCP if they want to, of course; no harm, no 
> foul.)

If my core understands DSCP and acts on it, I don't want non-QoS customers 
to send EF traffic, overloading my priority queue with their DDOS traffic.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Feb 2014 17:35:20 +1300

On 07/02/2014 16:10, Mikael Abrahamsson wrote:
>> border routers to clear the DSCP if they want to, of course; no harm,
>> no foul.)
> 
> If my core understands DSCP and acts on it, I don't want non-QoS
> customers to send EF traffic, overloading my priority queue with their
> DDOS traffic.

Of course; that's Diffserv 101. If you don't have a Diffserv SLA
with a customer, I'd expect you to clear the DSCP, or if you were
feeling charitable, run the traffic through a diffserv classifier.

I don't see any single respect in which homenets are different,
and I don't see that a device asserting "I am a telephone, not
a DOS vector" is helped by it using a special prefix. Source
addresses can be forged just as easily as DSCPs.

    Brian

---

From: Teco Boot <[email-masked]>
Date: Fri, 7 Feb 2014 07:50:39 +0100

> of course; no harm, no foul.)

No harm? Hmm. Two edge networks are connected via backbone and try to use end to end QoS. It is not unusual to add a tunnel, just to protect against DSCP rewrites.

Teco

---

From: joel jaeggli <[email-masked]>
Date: Thu, 06 Feb 2014 23:20:47 -0800

> No harm? Hmm. Two edge networks are connected via backbone and try to use end to end QoS. It is not unusual to add a tunnel, just to protect against DSCP rewrites.

if you include the DSCP in your hash algorithm really funny things
happen when providers that set them differently on different parts of
the same flows (e.g. prioritizing syn/ack) fail to sanitize them at
their border. there's a lot of pollution in DSCP which means you really
should sanitize them before you employ those bits.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Feb 2014 11:26:06 +0100

Brian,

As you point out, DSCP does of course work between endpoints within an enterprise network just as it was designed to do. It's reasonable to think that the same technology could be used in other environments, but the track record of it doing so outside of a tightly controlled domain is rather poor. Reclassifying at boundaries is expensive, often inaccurate, and ultimately doomed as we encrypt more and more end to end. It would be great if diffserv worked across the Internet, multicast would be nice as well. But, heck, we can't even get PMTUD working well enough to truly depend on. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Feb 2014 11:31:44 +0100

> I am most worried that we really have no process here to make a decision.

How about rough consensus and running code?

- Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Feb 2014 19:35:09 +0900

Mark,

It is a controlled domain.
ISPs do filter packets from their users, because of BCP 38.
DSCP is no harder than source address filtering.

Please let's stop bringing to the table technical arguments that don't hold
water, ok? I'd much rather hear "we want this to be standardized because DT
has implemented it" - at least that's the truth. :-)

Cheers,
Lorenzo

On Fri, Feb 7, 2014 at 7:26 PM, Mark Townsley <[email-masked]> wrote:

>
> Brian,
>
> As you point out, DSCP does of course work between endpoints within an
> enterprise network just as it was designed to do. It's reasonable to think
> that the same technology could be used in other environments, but the track
> record of it doing so outside of a tightly controlled domain is rather
> poor. Reclassifying at boundaries is expensive, often inaccurate, and
> ultimately doomed as we encrypt more and more end to end. It would be great
> if diffserv worked across the Internet, multicast would be nice as well.
> But, heck, we can't even get PMTUD working well enough to truly depend on.
>
> - Mark
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Feb 2014 20:02:20 +0900

On Fri, Feb 7, 2014 at 7:57 PM, Mikael Abrahamsson <[email-masked]> wrote:

> Absolutely, but it means resetting DSCP, thus breaking QoS in other parts
> of the packet path.

Well to be more precise, it means making sure DSCP is a value that the
customer is allowed to use (or rewriting it). Just like you have to make
sure that the packet's source address is a value that the customer is
allowed to use (or dropping the packet). No?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Feb 2014 11:57:38 +0100 (CET)

> has implemented it" - at least that's the truth. :-)

Let's agree that there are many ways to skin a cat and different ways have 
different pro:s and con:s.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Feb 2014 12:20:03 +0100 (CET)

> allowed to use (or dropping the packet). No?

Correct.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Feb 2014 12:44:45 +0100

Lorenzo,

> DSCP is no harder than source address filtering.

It's not about whether treating the packet is hard technically on the forwarding engine, it's about whether you can trust whether the bits are set correctly and persevered where the operator expects them to. For DSCP, we even have difficulties with that across vendors in enterprise deployments. As trust is something that is built up over time, and DSCP has indeed been around quite a while, there's a lot of baggage to get past here. 

Operationally, I don't think BCP38 filtering and QoS treatment based on DSCP is a fair comparison at all. If your NAT sets the wrong source IP address bits and your packets get dropped by your ISP, you lose service entirely. Bad DSCP bits, unless being monitored closely by someone or some tool, likely results in intermittent service issues based on what mix of traffic is present at any given time. Rather than the problem getting resolved, the user just hangs up and calls on his mobile phone (or whatever), and then the problem just "goes away" later, until it comes back again.. Rinse. Repeat.

> Please let's stop bringing to the table technical arguments that don't hold water, ok? I'd much rather hear "we want this to be
> standardized because DT has implemented it" - at least that's the truth. :-)

I tried to stay out of the "semantic" discussion, but you're going to put me in it anyway. Here's my thought on that.

We most often think about reducing the NAPT complexity above IPv4 by moving to IPv6, but there is a plethora of complexity below  that IPv6 has the chance to collapse. In a greenfield IPv6 design, once you wipe away all the VLANs, overlays, etc... the inertia from that exercise alone can lead to looking at addresses for more than numbering exposed physical network interfaces alone. I've seen this again and again, and it is just this point where one person's convenient use of IP addressing becomes another's evil semantic horror. That makes sense, because once you pass the least common denominator of a physical network interface, you are necessarily more and more domain-specific, which is where most misunderstandings and arguments tend to occur. 

This seems like a "Tussle", quoting [Clark], et. al... 

"Design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive." 

You asked for Truth. Truth is that homes need multiple prefixes for multihoming to different ISPs. Reality is, if DT wants to use that to expose 3 VLANs or 3 networks making it look like 3 ISPs to the homenet, so be it. In fact, it's a good test case to ensure the multiprefix design is implemented and flexible enough to handle cases we don't immediately envision. 

- Mark

[Clark] http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Feb 2014 08:48:52 +1300

>> allowed to use (or dropping the packet). No?

Yes. There's nothing we've discussed in this thread that is different
from the diffserv architecture (RFC 2475). Diffserv works within
a single administrative domain (possibly split up using tunnels).
There are some efforts towards inter-provider diffserv in TSVWG
(RFC 4594, RFC 5127, draft-geib-tsvwg-diffserv-intercon).

   Brian

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Feb 2014 22:51:14 +0100

> (RFC 4594, RFC 5127, draft-geib-tsvwg-diffserv-intercon).

Great, happy to see everyone finally at some level of violent agreement then!

- Mark

---

From: Ray Hunter <[email-masked]>
Date: Mon, 10 Feb 2014 17:52:59 +0100

Lorenzo Colitti wrote:
> On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We need to decide, if we want prefix assignment and distribution
>     of other configuration information integrated in a routing protocol.
>
>
> I think the two should be in the same protocol, because routing and 
> addressing are tightly coupled. Fundamentally, there is no point in 
> configuring an address on a host if the homenet doesn't have 
> reachability to it - because you can't use that address to talk to 
> anyone else in the homenet.
>
> If the routing protocol and the prefix distribution protocol are 
> separate, then they can end up with different ideas on what prefix is 
> on a given link. That will lead to blackholing.
+1

I don't see how you're going to avoid tight coupling and still keep 
things stable when/if provider links and internal links flap.

IMHO there's got to be some form of fate sharing to avoid every single 
app having to implement a version of happy eyeballs.

-- 
Regards,
RayH