from:"Alexandru Petrescu"

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

2015-09-02 Thread Alexandru Petrescu




Le 01/09/2015 18:06, Ray Hunter a écrit :

inline

Alexandru Petrescu wrote:



Le 12/08/2015 14:20, Eric Vyncke (evyncke) a écrit :




While I pay for it, I never use the millions of WiFi access points I
can
use here in the Netherlands. I tried it once, walking in a small
city. At
the time the handover was completed, the connectivity was gone.


This is a question of use-cases.  In a city yes there are many
hotspots but also yes they're sparsely distributed - you must handover
to something else in between.  In a home network they'd be densely
distributed, could hand-over directly, or not at all.

Actually they're pretty densely distributed around me.

There's one AP per household (via the cable TV provider) which has an
SSID for dedicated use.

These also support the guest/roaming access using a common SSID
identical on all APs.


YEs.


There are 5 apartments within wifi range of my desktop (I can see that
via the dedicated SSID).
And I find 12 on my mobile if I walk to the balcony.


I can agree.   I guess while the beacons are seen strong, once connected 
the strength becomes lower for some reason.


Also, automatic handing-over to such apparently dense hotspots is 
hampered on-purpose by administrative will: security keys, captive 
portals, acceptance conditions, and more.


It's a problem in home networks and also while travelling: airport, 
hotel, restaurant networks.


I am not sure how to relate this precisely to homenet WG...

Alex




You could be moving a lot and never handing over, as much as you could
sit and do many hand-overs per second.

Such use-cases and reqs are described in DMM WG documents.


ACK


Alex

 It might

have to do with IEEE and IETF mismatch. Same SSID shall have same IP
subnet (IEEE) versus each link has its own subnet (some of IETF, no
formal statement...).


Of course, if every SSID has its own 192.168.0.0/24, oups, this is
legacy
IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

___
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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

2015-09-01 Thread Alexandru Petrescu




Le 12/08/2015 15:39, Eric Vyncke (evyncke) a écrit :


On 12/08/15 15:18, "Teco Boot"  wrote:


How works *seamless* WiFi handover with same SSID, with different IPv6
subnets?


The question is tempting, but I'd say the following:
- a deployment with same SSID and different IP subnets is not good.
- keys of these SSIDs is a third parameter that should be considered: 
handovers are easier when keys are different.



Single subnet for a neighborhood, with all the multicast suppression?
Single subnet for a country?


Not sure whether 'community wifi' belongs to this alias but anyway, there
are working solutions with host routes and/or tunnels... Nothing optimum
and probably not really scalable for a whole country.


Mobile IP, Proxy MIP, GTP scale to some sizes.

Alex


I will take your single /64 for the whole country as a joke :-)  OTOH,
there are actually solutions for this kind of deployment, let's wait until
Pascal chimes in ;-)

-éric

___
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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

2015-09-01 Thread Alexandru Petrescu




Le 12/08/2015 14:20, Eric Vyncke (evyncke) a écrit :




While I pay for it, I never use the millions of WiFi access points I can
use here in the Netherlands. I tried it once, walking in a small city. At
the time the handover was completed, the connectivity was gone.


This is a question of use-cases.  In a city yes there are many hotspots 
but also yes they're sparsely distributed - you must handover to 
something else in between.  In a home network they'd be densely 
distributed, could hand-over directly, or not at all.


You could be moving a lot and never handing over, as much as you could 
sit and do many hand-overs per second.


Such use-cases and reqs are described in DMM WG documents.

Alex

 It might

have to do with IEEE and IETF mismatch. Same SSID shall have same IP
subnet (IEEE) versus each link has its own subnet (some of IETF, no
formal statement...).


Of course, if every SSID has its own 192.168.0.0/24, oups, this is legacy
IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

___
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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

2015-09-01 Thread Alexandru Petrescu

Handovers between WiFi and self, or anything else are treated in the 
mobility Working Group (dmm).


Handover is considered solved with protocols like Mobile IP, Fast MIP, 
Proxy-MIP and more.  Nothing stops it from running in a home 
environment, other than maybe a question of where to place a Home Agent. 
 I dont see anything else particular in a home.


The current thought in the dmm WG is to work on a Distributed Mobility 
Management scheme, because that HA has certain inconvenients.


Handover - go to dmm.

Alex

Le 12/08/2015 12:27, Juliusz Chroboczek a écrit :

I still think the Homenet WG should pay far more attention to seamless
WiFi handover,


We're currently working on that with the WLAN-SI guys.  They've got
a nationwide mesh network (it's a small country, granted, and they use the
public Internet infrastructure whenever possible), and while they're not
interested in roaming at a global scale, they insist on seamless roaming
within a small cluster of routers (home or village sized), and they insist
on no host changes and good support for Android hosts.

We'll write to this list when we know what works.

In case it doesn't show, I'm enthusiastic about the energy and competence
of the WLAN-SI core team.  They make a serious effort in translating
everything they do into English, and they've got a nice node database
online (even nicer one ready, but not deployed yet):

   https://wlan-si.net/
   https://nodes.wlan-si.net/

-- Juliusz

___
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

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

2015-09-01 Thread Alexandru Petrescu

There is a WG item in v6ops WG which tells the Access Point should 
unicast RAs to battery-powered Clients rather than multicasting it, 
because the observation is that it consumes power on the smartphone.


That's an observation reflected in more places.

The solution space is the following:
- practice recommendation to turn-off 'multicast' on WiFi.
- L2 multicast mechanisms using filters.
- L2 multicast mechanisms using messages.

There is nothing else in that space.

Alex

Le 10/08/2015 20:48, Alia Atlas a écrit :

Hi Adrian,

I am encouraging those interested to wrote a draft indicating the
observed issues and perhaps exploring the solution space.   I assume
that's what you would need to start having a meaningful discussion on
reasonable options.

Thanks,
Alia

On Aug 10, 2015 5:41 AM, "Stephens, Adrian P"
mailto:adrian.p.steph...@intel.com>> wrote:

Hello Mikael,

Please see my responses embedded below...

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825  (office)
Tel: +1 (971) 330 6025  (mobile)

--
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

-Original Message-
From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org
] On Behalf Of Mikael
Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: ieee-ietf-co...@ietf.org ; Dan
Romascanu (droma...@avaya.com ); Glenn
Parsons; mbo...@ietf.org ; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11


(included mbo...@ietf.org  and also changed
subject to something more
appropriate)

As far as I can tell, so far people have told IETF it's their job to
reduce multicast to make IP based protocol "work" on 802.11 media.
That's at least what I have been seeing. Considering the reactions
from other parties, it seems the "multicast sucks on 802.11" is
something 802.11 hasn't heard of before.

[Adrian P Stephens]
This problem is nothing new.  We know about the relative performance
of multicast vs unicast.
Saying it "sucks" is not very helpful.   Unlicensed spectrum is
free.  You are getting more than you are paying for :0).


The only thing IETF can do is to use less multicast, and the obvious
way of solving it is to just replicate into unicast. This seems like
a suboptimal way to work around the problem if there are a lot of nodes.

[Adrian P Stephens]
The technical solution is surely to add a class of service
specification to multicast packs that indicates their sensitivity to
loss.
The point is that the AP is in possession of a lot of data about
individual nodes that may help it make an informed decision
between unicast and multicast.

Moving the duplication into the IP layer ensures uninformed decisions.


 >From what I read below, one way out of this is the IETF making a clear
statement that multicast is an integral part of IP networking, and
if a medium doesn't support delivering multicast frames in a
similarily reliable fashion to unicast, it's not suited to carrying
IP based protocols (or any other protocol that uses L2
broadcast/multicast).

[Adrian P Stephens]

I'm guessing you will be the first to turn off the 802.11 networking
on your devices when the IETF makes such a statement.




It seems to me that there are a few paths that the IETF could go:

Write an RFC stating requirements on L1/L2 protocols when it comes
to unicast, multicast and broadcast handling of packets. This could
include options for mechanisms that turned multicast/broadcast into
unicast that certain medias could have as requirements. Then IEEE
could create a device profile that would fulfil these requirements,
possibly add a certification, and then try to get market pressure to
require devices to support this profile. The IETF wouldn't change
its mind about how multicast is used in its protocols after this,
but just say "this is the reality, please deal with it when you
create L1/L2 that's supposed to carry IP".

Or the IETF could just say that this seems like a lost cause,
multicast/broadcast doesn't seem to work on some L1/L2, and start
working on techniques that minimizes broadcast/multicast and change
all the protocols to reflect this new reality.

Something in the middle, but anyway changing the requirements on
IETF protocols to avoid using multicast if it can, documenting where
it makes sense and when it doesn't.

Right now what I am seeing is that there are people who are lobbying
to do away with multicast as much as possible because they see that
in reali

Re: [homenet] [ieee-ietf-coord] multicast mechanisms

2015-09-01 Thread Alexandru Petrescu


Donald,

Thanks for the mentioning of 802.11aa, GCR, and transmission rates to
multi-destination.

Other than these delivery mechanisms, is there something at IEEE 802.11
about building paths to be used for delivery?

I am thinking of a potential IEEE 802.11 Management Frame which
expresses interest in joining multicast groups (akin to an IP MLD
REPORT) - does such thing exist?

Alex

Le 06/08/2015 16:01, Donald Eastlake a écrit :

I think there are some problems with slide 5 of the references
presentation. Although I am active in IEEE 802.11 this is not
particularly my area of expertise. I'm sure Dorothy will correct me
if I'm wrong:

- The claim that the AP must retransmit multi-destination frames as
the "lowest possible" rate seems a bit misleading. Beacons (AP
originated station discovery frames) should be sent at the lowest
rate the AP is configured to use and Probes (station originated AP
discovery frames) should be sent with the lowest rate the station is
configured to use. Multi-destination data need only be sent at the
lowest rate needed for the worst of the associated stations,
although an AP could send slower if it wanted to, which still uses
less air time than serially unicasting since you would have to send
it at that slow rate anyway to that worst station. In any case, none
of these is the "lowest possible" rate, which I assume means the
slowest/most-robust modulation defined in the 802.11 standard.

- 802.11 does have a feature called GCR -- Groupcast With Retries,
which was part of the 802.11aa amendment, although it is not widely
implemented. It includes such features as a way for the AP to send
several multi-destination frames and then, using unicast, to poll
associated stations for a bit map of which of those frames they
correctly received (BlockAck) and a feature for the AP to
spontaneously transmit a multi-destination frame more than once
without causing confusion for improved reliability.

Thanks, Donald = Donald E. Eastlake 3rd
+1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com


On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan)
 wrote:

Hi Mikael,

I agree that we need a more focused dialog. I am copying to your
message the IEEE 802 - IETF coordination list. FYI - this is a team
of IETF and IEEE 802 experts that includes but is not limited to
the ADs who work on issues that require coordination between the
IETF and the IEEE on the lines described by RFC 7241. Folks who are
interested to join this activity - please write to me. You should
also know Dorothy Stanley who is the liaison manager of IEEE 802.11
to the IETF. Let us see what other participants in IEEE 802 have to
say about this before we discuss how we can best proceed.

Regards,

Dan




-Original Message- From: Mikael Abrahamsson
[mailto:swm...@swm.pp.se] Sent: Thursday, August 06, 2015 9:45
AM To: Glenn Parsons Cc: Alia Atlas; Acee Lindem (acee); Toerless
Eckert (eckert); Homenet; Eric Gray; Romascanu, Dan (Dan)
Subject: RE: [homenet] Despair

On Thu, 6 Aug 2015, Glenn Parsons wrote:


As I indicated in another thread, the right place to start a
discussion on this

would be in the IETF-IEEE 802 coordination that Dan leads.


While this issue may be solved be current work underway (and
included in

the coordination), perhaps a clearer problem statement would help
us to ensure that is the case.

There are documents that talk about multicast from a power
efficiency standpoint:

https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00

Slide 2 of
http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf



pretty much sums it up, most of IETF protocols are designed around multicast

being as reliable as unicast. IPv6 relies on this. On 802.11 this
isn't the case. Slide 5 describes how this works in 802.11.

The fact that multicast and broadcast is unreliable (not ACKed)
on 802.11 is from what I can see the major cause of the
unreliability problem that the mesh wifi networking protocols are
trying to solve by basically only using multicast for discovery.

The whole question is whether this should be fixed by 802.11 or
if the IETF needs to (basically) abandon multicast/unicast, or if
the IETF should develop a multicast->unicast replication
mechanism for wifi (there is work in this area going on).

Personally, I think 802.11 needs to fix multicast/unicast so it's
reliable, or get back the IETF and say it can't be fixed and then
the IETF can continue the work on multicast reduction (or
workaround) even harder.

I find the current approach of (basically) individuals within the
IETF working on multicast reduction without (as far as I can see)
any dialogue with 802.11 to be a non-optimal way of solving the
problems we're seeing.

-- Mikael Abrahamssonemail: swm...@swm.pp.se


___ ieee-ietf-coord
mailing list ieee-ietf-co...@ietf.org
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

2015-09-01 Thread Alexandru Petrescu




Le 12/08/2015 07:17, Mikael Abrahamsson a écrit :

On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote:


Without guidance on how good the multicast packet loss rate should be,
it is difficult to define the best solution .


I'd say most applications people actually use start behaving very badly
around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really
get affected etc. I'd imagine most people I interact with that design
protocols design protocols have in their mind that the packet loss rate
is around this level, not higher.

So for me, the "contract" that 802.11 needs to fulfil for the IETF not
to start looking into changing IP for 802.11, is for 802.11 networks to
deliver broadcast and multicast packets with around 0.1% packet loss (or
less) as a design goal for normal operations.


In addition to treating 'multicast' in terms of delivery, reading as 
'multi-media', I think we should think of multicast in terms of a 
mechanisms, as well.


The mechanisms to build multicast paths are essential prior to 
delivering multimedia data in an efficient manner.


The mechanisms include multicast tree building protocols, filtering, and 
more.


I believe that IETF has a rich set of multicast mechanisms, whereas IEEE 
only has filters.  I may be wrong though.


Alex




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCPv4 Subnet Allocation, and IPv4 Router Advertisements

2015-07-22 Thread Alexandru Petrescu




Le 22/07/2015 13:52, David Lamparter a écrit :

On Wed, Jul 22, 2015 at 01:44:52PM +0200, Alexandru Petrescu wrote:

Do you need DHCPv4 Subnet Allocation and/or IPv4 Router Advertisements
(RFC6656 and RFC1256)?


hncp-07 section 7.4 says:
[...] The winner is the router (connected to the Common Link)
advertising the greatest L-capability. [...] The elected router MUST
provide DHCPv4 services on the given link.


Sounds as if you actually want a "The elected router MAY provide DHCPv4 
service on the given link, and only until year 2020".?


Or maybe you want to have an RFC today to be able to update it in a few 
years time? (remove the MUST).



hncp-07 section 10 says on the election:
[...] between 1 and 7 included (4 is the default) if the router is
capable of running a legacy DHCPv4 server offering IPv4 addresses to
clients and 0 otherwise. [...]

So, L=0 implies the router can't do a DHCPv4 server.  And if you have a
link where all routers have L=0, there will not be DHCPv4 on that link.
(Which is, I guess, how you would do sunset4?)


You seem to be saying that '0' is somehow a priviledged value.  Maybe 
make _that_ a 'default' (not '4') and make _that_ a MUST?


Not sure if any of this is changing in -08;  I do agree with Alexandru
in that there is a need for a mechanism to ditch IPv4 for individual
v6-only devices or complete v6-only homenets.


YEs, trying to set my mind about this being IPv6-only in a brief time, 
and IPv4 still there, but not in the way.


IPv6 is default, the doc should read mainly IPv6, IPv4 in the appendix, 
or as exceptional additional documents for those who really need it.


Just some comments...


NB: Prefix assignment is a different question.


I agree.

Alex




-David



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] DHCPv4 Subnet Allocation, and IPv4 Router Advertisements

2015-07-22 Thread Alexandru Petrescu


Hi,

With respect to implementation report.

Do you need DHCPv4 Subnet Allocation and/or IPv4 Router Advertisements 
(RFC6656 and RFC1256)?


Alex
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

2015-03-26 Thread Alexandru Petrescu


Le 26/03/2015 16:33, Ray Bellis a écrit :


On 26 Mar 2015, at 16:08, Brian E Carpenter  wrote:


I also suggest that comments in this thread should consist of precise
proposed changes to the draft design team charter, not another run
round the whole discussion loop.


Thank you Brian, that’s very well put.


One comment is the following: instead of selecting, make them interface; 
maybe use a common TLV.  This has been tried in the past in MANET and 
other routing protocols.


Alex



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

Re: [homenet] Mesh networks in the homenet

2015-03-26 Thread Alexandru Petrescu


Le 26/03/2015 02:35, Henning Rogge a écrit :

On Wed, Mar 25, 2015 at 5:15 PM, Alexandru Petrescu
 wrote:

Err, no.  It's an A-B-C situation where each (even B) has 1
interface, and all are in an IBSS.  This is the situation
described in that draft.


Are there 1-interface routers in homenet?



In an 802.11 IBSS, I would assume yes.



Well IBSS is not made to have 1-interface routers on them, so this
 (1-interface routers) is not really good to do, in my personal
oppinion.

IBSS is made to have 1-interface Hosts on it, not routers.


one of the typical use-cases of IBSS mode was to connect larger
amount of routers for a mesh network.


I doubt that.  IEEE specs of IBSS tell 'STA' (station).  They never say
Router.

A mesh network may be a nonsense in itself; it's as if IP networks were
not meshed, or as if there were meshes somewhere which were not networks.

One has to look at the latin origins of the words mesh and network.
They mean practically the same thing, no need to double.


Remark this is my IMHO and a number of other people disagree with
this.

I know.

I just tell that you can build a very good ad-hoc network without
an AP and with 2-interface routers.  At that point there is no
hidden-terminal problem.


Unfortunately this is wrong.

The number of interfaces is totally irrelevant to the hidden station
 problem.


Well no.

In the ABC problem if B had two interfaces each on a different channel,
and it were a real IP router then there were no hidden station problem.

Insisting to deploy 1-interface routers and say there are unsolvable
problems, and that meshes are different than other networks, is leading
to frustration.

Please do not get me wrong: I do support IBSS mode and large wireless
neworks; except that they should be done otherwise than currently
recommended.


The only question is if you have one wireless radio interface (among
many on a router) connecting to two other routers (with maybe many
more interfaces) that cannot hear each other on this interface.


So you should not have only wireless interface on a router.  You should
have at least two distinct wireless interfaces on a router, each on a
different channel.  This is what some deployments do.


It can even happen on AP/client networks if you use them to connect
multiple routers. There is no guarantee that the clients can see each
other.


The guarantee to see each other comes from careful network planning,
careful field analysis.  Once the field is understood the deployment is
very easy.

A guarantee that everything will be unstable stems from lack of analysis
of the field and promotion of technology that is designed on paper by
using a God view.

Alex



Henning Rogge




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] renumbering RFC router renumbering

2015-03-25 Thread Alexandru Petrescu


Le 24/03/2015 21:01, Brian E Carpenter a écrit :

On 25/03/2015 08:47, JF Tremblay wrote:



On Mar 24, 2015, at 2:00 PM, Brian E Carpenter
 wrote:

[...] Make-before-break renumbering (a.k.a. planned renumbering)
is preferable but we can't rely on it. (I also try to never
forget Fred Baker's observation that there is no such thing as
renumbering: there is only numbering.)


Any reference for reading (on Fred’s principle)?


I'm not aware of a written version; it's something I've heard him
say more than once. Of course there is RFC 4192, but it isn't in
that.


Not sure what the question was but there is a stds track RFC in the 
2000s about IPv6 router renumbering, authored at Fermilab IIRC.


That has a notion of difference between numbering and renumbering.

Numbering is the initial assignment of prefixes on links.  Presumably a 
manual operation.


Re-numbering is propagation of tuples [existing prefix, new prefix] with 
RAs messages between routers.


This technique was used by other protocols such as Hierarchical Mobile 
IPv6 which is an RFC as well, although experimental IIRC.


This of course brings the question of what is renumbering.

Alex




Brian



[...] However, Dave Taht told us recently that renumbering *is*
currently broken, and I'd like to see his list of issues. For
now, here are the issues that I see:


I’ll let Dave answer for himself, but my personal experience at
home currently is that it breaks quite often. As soon as the home
network gets renumbered, new RAs are flooded, but no RAs are sent
to de-prefer the current prefix (as specified in RFC7084 L-13).
I’ve seen this happen both with 6RD and in native, with two home
router vendors. I usually flap my link physically to flush old
addresses.

Btw, I didn’t raise this morning, but I believe smooth renumbering
from an ISP is possible, at least for cable ISPs (costly, but
possible). This requires support for multiple concurrent prefix
delegations on home routers, which I haven’t seen yet in the wild.
This requirement isn’t explicitly mentioned in RFC7084, only
indirectly through the support for DHCPv6-PD (WPD-1).

So on the short term, proper implementation of RFC7084 L-13 is
required for smoother unplanned renumbering. For smooth planned
renumbering, support for multiple concurrent PDs is required. It’s
too bad that the homenet architecture doc (RFC7368 section 3.4.1)
does not even mentions this possibility.

JF







___ 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

Re: [homenet] Mesh networks in the homenet

2015-03-25 Thread Alexandru Petrescu


Le 24/03/2015 19:01, Juliusz Chroboczek a écrit :

Before we lose this, let it be noted that we seemed to have arrived
at "no" for an answer to whether we want to deal with
non-transitive networks, *as part of this particular routing
protocol discussion*.


This is what the protocol comparison draft has to say on the
subject:

We believe that IBSS may be out of scope for Homenet, but we expect
that people will attempt to use the Homenet protocols in IBSS mode,
whether we like it or not.


Well, you can put IBSS out of scope for homenet WG, but nobody can stop
one to set an IBSS mode in a home network.

This is a confusion about the use of the term 'home networking and
homenet WG'.


Without special ND handling, Hidden nodes will fail DAD, and you
can't expect to get a mac address for a node you don't get
multicast to.


I agree.  If we assume unmodified clients, then IBSS is only suitable
for router-to-router links.  However, I think that Homenet needs a
killer feature, and almost-zeroconf router-to-router wireless links
might be it.


There are a few such killer features but they dont seem to be considered
in homenet WG.

To find one it is very easy: express a problem you have encountered.

Buy a modern home device bring it home and tell what was the difficulty
in setting it up.  There are many simple problems immediately exposed:
how is IPv6 running (is it NAT? is it PD? is it ULA?  is it running DHCP?).

Ask your DSL operator what IPv6 and how.  In France there are now two
IPv6-enabled DSL operators for the user lambda (not professional) and
you'll see how they need some feature.  For example Free IPv6 DSL only
allows setting routes manually by filling in forms in a webpage -
automate that.  Orange IPv6 DSL is nascent yesterday - what are the
problems there?


(Now I happen to believe that if Homenet is successful, we will get
modified clients -- think Android -- but I realise that this opinion
does not necessarily reflect the consensus of this group.)


I *don't* think meshes are out of scope for homenet.  I do think
meshes need a mesh routing protocol.


I disagree.  If you accept that a small mesh is a cheap and
convenient way to establish a router-to-router link, then you'll want
to avoid the tricky issues that come with running multiple routing
protocols (bidirectional redistribution at two distinct points within
the network, oh boy).


Multiple routing protocols is inevitable IMHO.  To deal with it is like
dealing with OSPF and BGP - make them talk to each other.


(But then, I'm pretty much bound to disagree.  The desire to have a
single routing protocol that you let loose on a highly heterogeneous
network and it just works is the main driver behind Babel.)


A single routing protocol is a good goal to state at WG meeting decision
time.  But it often leads to actually new protocol which will be the
one.  We've seen that recently with RPL - that's the one.  There is even
a set of requirements for it in the home networks (RFC).

Should we enumerate all routing protocols which are 'the one'?


we would be talking about AP / BSS, not ad-hoc / IBSS [...]
Massively reduced marginal links (because when you start losing
beacons between AP and Client, you'll be deassociated.)


I strongly disagree.  By default, the Linux Intel driver will
perform recalibration after it misses 5 beacons in a row.  You can
have a perfectly functional yet clearly marginal link in AP/STA
mode.


Maybe yes, with that particular driver.

Alex



-- Juliusz

___ 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

Re: [homenet] Mesh networks in the homenet

2015-03-25 Thread Alexandru Petrescu


Le 24/03/2015 17:49, David Lamparter a écrit :

On Tue, Mar 24, 2015 at 05:28:05PM -0500, Alexandru Petrescu wrote:

Le 24/03/2015 17:19, David Lamparter a écrit :

Before we lose this, let it be noted that we seemed to have
arrived at "no" for an answer to whether we want to deal with
non-transitive networks, *as part of this particular routing
protocol discussion*.

If I'm misrepresenting the outcome from today's meeting, someone
please correct me.


That transitiveness issue is from the fact that their routers only
have 1 interface.


I don't follow. If each of the routers in the A-B-C situation has a
wired segment attached to them, it's still A-C intransitive, but
they each have 2 interfaces?


Err, no.  It's an A-B-C situation where each (even B) has 1 interface,
and all are in an IBSS.  This is the situation described in that draft.


Are there 1-interface routers in homenet?


In an 802.11 IBSS, I would assume yes.


Well IBSS is not made to have 1-interface routers on them, so this
(1-interface routers) is not really good to do, in my personal oppinion.

IBSS is made to have 1-interface Hosts on it, not routers.

Remark this is my IMHO and a number of other people disagree with this.

I know.

I just tell that you can build a very good ad-hoc network without an AP
and with 2-interface routers.  At that point there is no hidden-terminal
problem.


I *don't* think meshes are out of scope for homenet.  I do think
meshes need a mesh routing protocol.  But pulling this into the
current discussion seems to generate nothing but waste heat.


We dont have a definition of what a mesh is.  Saying mesh is
inviting people from RoLL and MANET WGs to argue.

However, I'd doubt a homenet is a mesh in their sense.


Sorry - replace "mesh" with "network segment with intransitive
reachability" in my mail.


Ok.  I'd substitute network for mesh altogether.


(And I'm not applying the concept to a homenet as a whole, I see it
as an attribute of a particular set of links / interface types.)


Well, I dont.

A mesh is a network and vice-versa.


As a consequence, when we talk about 802.11, we would be talking
about AP / BSS, not ad-hoc / IBSS.


Yes and no.

Yes, at home most deployments are in AP mode.

But no in that still at home the WiFi landscape has recently
become reacher than the old dichotomy AP-mode vs adhoc-mode.  E.g.
the 802.11ac and ad products feature direct AP to AP communication
for range extension, or streaming from a tablet to a TV set, or a
LED projector switching between being an AP itself or being a
Client to another AP.


I'll have to look at these in detail, but they sound like individual
links that would be treated as P2P in the routing protocol.


I agree, although I dont understand what you mean by P2P.

Peer-to-peer networks is a great term used by DSL boxes and enhanced
Blueray players to download content from P2P platforms.

Peer-to-peer is also a great term used by the RPL protocol to tell a
node talks directly to another RPL node, instead of up-and-down a
Directed Acyclic Graph.

Point-to-point links are those which only have two IP ends on them, like
a cellular link of a smartphone, or the uplink of a DSL box.

A AP to AP wireless link could be a point-to-point link, but I dont
think point-to-point protocols are used on these links.  The netgear
802.11ac AP to AP communication (see its user manual) is not necessarily
a point-to-point link.  I _suppose_ that link is a WiFi link like any
other (i.e. not point-to-point link).



(In the tablet to TV set case, I guess routing wouldn't be involved
at all?  Strays into the "is everything a router?" question,
though.)


Sure it should.

In a typical homenet you have a growing number of these apparently
specialized links.  You have this tablet-to-TV but also 802.15.4 smart
light control, and remotely controlled window shades, alarms, smartbody 
to smartphones, smartgrid control, and more.  Each of these works ok 
isolated in itself.  When you want to link them together only IP works 
for each.  And only a notion of IP routing can find paths through such a 
maze.  Actually it's such complex that I gave up completely considering 
it, it's craziness.



No hidden node problem.  No intransitive reachability.
Massively reduced marginal links (because when you start losing
beacons between AP and Client, you'll be deassociated.)


Tinkering about this.


Tinker loudly, into your keyboard, onto a mail ;)


Overall it may boil down to have IP running on each of these links, a
routing protocol and an address and prefix assignment functionality.

Alex




-David




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Mesh networks in the homenet

2015-03-24 Thread Alexandru Petrescu


Le 24/03/2015 17:19, David Lamparter a écrit :

Hi Homenet chairs & list,


Before we lose this, let it be noted that we seemed to have arrived
at "no" for an answer to whether we want to deal with non-transitive
 networks, *as part of this particular routing protocol discussion*.

If I'm misrepresenting the outcome from today's meeting, someone
please correct me.


That transitiveness issue is from the fact that their routers only have
1 interface.

Are there 1-interface routers in homenet?


(As a nail in the coffin for this:  IPv6 isn't even implemented for
NBMA networks, which a mesh falls under.  Without special ND
handling, Hidden nodes will fail DAD, and you can't expect to get a
mac address for a node you don't get multicast to.  Before anyone
reminds me of RFC 2491, please point to an implementation / a wifi
mesh that runs MARS.)

(The big community meshes usually don't have stupid clients in the
ad-hoc cloud.  If you're in ad-hoc, you speak the mesh protocol.
Stupid clients go to a separate AP/BSS on a mesh router of their
choosing.)


I *don't* think meshes are out of scope for homenet.  I do think
meshes need a mesh routing protocol.  But pulling this into the
current discussion seems to generate nothing but waste heat.


We dont have a definition of what a mesh is.  Saying mesh is inviting
people from RoLL and MANET WGs to argue.

However, I'd doubt a homenet is a mesh in their sense.


As a consequence, when we talk about 802.11, we would be talking
about AP / BSS, not ad-hoc / IBSS.


Yes and no.

Yes, at home most deployments are in AP mode.

But no in that still at home the WiFi landscape has recently become
reacher than the old dichotomy AP-mode vs adhoc-mode.  E.g. the 802.11ac
and ad products feature direct AP to AP communication for range
extension, or streaming from a tablet to a TV set, or a LED projector
switching between being an AP itself or being a Client to another AP.


No hidden node problem.  No intransitive reachability.  Massively
reduced marginal links (because when you start losing beacons
between AP and Client, you'll be deassociated.)


Tinkering about this.

Alex




Cheers,

-David

___ 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

[homenet] rt protocol comparison on criterion 'transitivity' A-B-C draft-baccelli-intarea-adhoc-wireless-com-00.txt

2015-03-24 Thread Alexandru Petrescu


Hello,

During the slide presentation by Margaret we saw a criterion for 
protocol comparison describing 'transitivity', in the sense A sees B 
sees C but A does not sees C - aka a 'hidden terminal problem' in WiFi 
IBSS mode.


In intarea WG there is an actively maintained draft about these issues 
in adhoc networks:

http://www.ietf.org/id/draft-baccelli-intarea-adhoc-wireless-com-00.txt

Babel and IS-IS as well as any future routing protocol should be aware 
of the discussion around this draft.


Alex

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

2015-03-04 Thread Alexandru Petrescu


Le 03/03/2015 19:41, Michael Richardson a écrit :


Ole Troan  wrote:

I was planning on using ISC DHCP 4.3.1 together with an external
script as described in https://github.com/mpalmer/isc-dhcp
contrib, to detect the next hop address of my homenet router and
install the relevant route for the delegated prefix on the
last-hop ISP router (a Linux box).



typically the ISP router snoops DHCPv6 messages and does route
injection based on that, or the DHCPv6 server runs on the ISP
router and does route injection based on binding state.


The IPv6 support in ServPOET's PPPoE BMS (which I wrote last year)
runs a DHCPv6 daemon on the router itself, and simply adds a route
via the PPP link when the DHCPv6-PD occurs.


If you had to do this, and if other implementations dont and break, it's
 because something has to be specified about DHCP-PD Router and Relay.
A spec must tell implementor to do it, otherwise it wont work and break.

(we wrote earlier a draft about this DHCP-PD problem that we'll be glad
to resurrect, or we'll be glad to read other drafts on same topic)

https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00

Alex




The selection of prefix comes from radius during the PPP
negotiation/authentication, and is passed "laterally" from the PPP
process to the DHCPv6 process (which is called rfc6204d, because 7208
wasn't quite out at the time).

The amount of DHCPv6 processing required for a PPP link is remarkably
small, and I worry that I may have done too little.  Of the three
CPEs that I've tested with, one is OpenWRT BB (thanks to Stephen and
Markus and the rest of the crew) and worked great, a second locked up
tight when given an IPv6 PD, a third proclaimed "IPv6 suport" on the
box, but had nothing inside.  I have two more devices to test with:
one of which requires translation from chinese, and the fifth I got
last week, and I haven't powered on yet. (Thanks Hui!)

I've been talking on and off with Tim Winters of the UNH interop lab,
and at this point it seems that they just aren't equipped with IPv6
capable CPEs that do PPP such that visiting there makes sense.  There
are some there that do cable/ethernet-WAN, but not PPPoE WAN.

(also m...@finepoint.com two days/week)



___ 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

Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15

2014-10-31 Thread Alexandru Petrescu


Le 31/10/2014 16:47, Ted Lemon a écrit :

On Oct 31, 2014, at 10:55 AM, Sheng Jiang 
wrote:

The current general mechanism are too general to work for the use
case of hierarchical prefix delegation. But if we add hierarchical
topology and no bypass requests as constraint conditions, we may be
able to make hierarchical prefix delegation work.


No, that is not the point I am making.   The point I am making is
that hierarchical delegation simply won't work, no matter what
mechanism you put in place to do it, because the network has to be
able to grow incrementally.   With that as a base assumption, you
cannot predict where the network will grow, so you don't know how to
construct the hierarchy.   Once the hierarchy is constructed, you
would have to renumber on a regular basis to make hierarchical
delegation work.


At which point one wonders whether Router Renumbering RFC2894 may need 
some updates.


Alex


   I think it is preferable to simply allow for a

complete routing table, and then try as best as possible to make
routing hierarchical, without demanding perfection.

___ 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

Re: [homenet] on prefix comparison

2014-10-29 Thread Alexandru Petrescu


Hi Pierre,

I took some time to understand the code.

But here is what I would like to say.

Your algorithm decides whether or not one prefix collides with another, 
by comparing prefix/plen pairs according to an exact match rule.


On another hand, the forwarding towards these prefixes is realized by 
longest-prefix match rule applied to an address against successive 
entries in a routing table.  By this rule an address/128 matches the 
first one entry whose prefix length is longest, if several; and default 
otherwise.


If one hears two prefix/plen pairs in RAs and decides they 'collide' by 
the exact match rule implemented by the code below then one may decide 
this is a bad configuration situation.  At the same time the forwarding 
may be set up ok, because it uses the longest-prefix match rule, not 
exact match, and has a default to escape to as well.


This is why I am saying that any method to compare prefixes may not be 
agreed on, may not lead to effective results, unless designed according 
to the rules used for forwarding.


Yours,

Alex



Le 08/10/2014 14:25, Pierre Pfister a écrit :

A prefix can only contain another prefix if its prefix length is smaller.

Here is some C-code that provides what you are looking for.

Cheers,

- Pierre


/* Tell whether a prefix contains an address */
uint8_t prefix_contains(const struct in6_addr *p, uint8_t plen, const struct 
in6_addr *addr)
{
int blen = plen >> 3;
if(blen && memcmp(p, addr, blen))
return 0;

int rem = plen & 0x07;
if(rem && ((p->s6_addr[blen] ^ addr->s6_addr[blen]) >> (8 - rem)))
return 0;

return 1;
}

/* Tell whether a prefix contains another prefix */
uint8_t prefix_include(const struct in6_addr *p1, uint8_t plen1, const struct 
in6_addr *p2, uint8_t plen2)
{
if(plen1 > plen2)
return 0;

return prefix_contains(p1, plen1, p2);
}

/* Tell whether two prefixes are colliding */
uint8_t prefix_collision(const struct in6_addr *p1, uint8_t plen1, const struct 
in6_addr *p2, uint8_t plen2)
{
return prefix_include(p1, plen1, p2, plen2) || prefix_include(p2, 
plen2, p1, plen1);
}


Le 8 oct. 2014 à 14:13, Alexandru Petrescu  a 
écrit :


Pierre, just a small doubt, but I agree with you in general.

Le 08/10/2014 13:58, Alexandru Petrescu a écrit :
[...]

Equality is never considered alone. Actually, most of the time, you
will find considerations such as: The prefix is not included or does
not include any other Assigned Prefix with a higher precedence.


It is hard to say whether a prefix is included into another or not.  We do not 
have a published algorithm to say what it means for a prefix to include another.

In general, we have a common understanding (and not published algorithm) about 
what it means 'longest prefix match'.  But that compares an address to a 
prefix, not a prefix to a prefix.

Sure, one could assume that an address is just a /128 prefix and execute 
longest prefix match with it as if it were an address.

But then again which prefix has the role of the address and which is the role 
of the prefix?  In other words, when hearing two prefixes on a link and want to 
compare them, which of them should be compared against the other by using the 
longest-prefix match?  There are two possibilities and two different outputs 
for a particular tuple of prefixes, depending on the order of this longest 
prefix match.

Of course, I do not mention the easy case which compares two prefixes of 
precisely same length.

Just because the length is different may make think that the prefixes are 
different.  Or otherwise one could be aggregated into another.  But there are 
several types of aggregation: matching up to the shortest length, matching up 
to middle, up to longest length, beyond the longest length.

These cases are not documented and people may implement them in many different 
ways with different outputs when trying to tell whether this or that prefix are 
equal or included into one another.

Alex









___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] “Hybrid Access for Broadband Networks” (WT-348)

2014-10-29 Thread Alexandru Petrescu


Le 28/10/2014 05:10, Xueli a écrit :

Hello Alex

Thank you for your nice comment. The scenario here is for the fixed
operators rather than the mobile phone for higher bandwidth. I make
this clarification in the new version architecture draft as： ” Hosts
in the customer site may connect to the Internet through the CPE, the
3G/4G network, or both.  In most cases the majority of the hosts
connects to the Internet through the CPE only and will experience
slow Internet access when the bandwidth provided by the fixed access
network is fully utilized (e.g., the traffic over the fixed access
network reached its maximum capacity or a pre-specified threshold set
by the operator). So we are considering the scenario with CPE
extension with multiple access networks.

I would like to know additional information on the internet drafts
you mentioned, do you mind to provide more information on this?


Sure, it is about these documents;

Flow Binding Support for Mobile IP
draft-ietf-mip4-multiple-tunnel-support-08.txt

Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
RFC 6089

and this post:
https://www.ietf.org/mail-archive/web/mip4/current/msg03728.html



Best Regards Li


-Original Message- From: Alexandru Petrescu
[mailto:alexandru.petre...@gmail.com] Sent: Thursday, October 23,
2014 12:28 AM To: Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET
Working Group; m...@ietf.org Subject: Re: “Hybrid Access for Broadband
Networks” (WT-348)

Hello Xueli,

Several people look at this problem as an IP problem.  Instead of
considering a cellular+dsl combination in a homebox, they considered
cellular+wifi on a smartphone.   But the goal was the same: augment
the bandwidth perceived by the end user.

In implementation it is however quite challenging.  The more tempting
the expectations of augmenting bandwidth by simply adding network
interfaces (as in adding RAM to a busy computer), the higher the
desillusion when facing the challenges of implementation.

Some consider it simply as a local computer policy problem (and hence
no new communicaiton standards needed), but others consider that
there is a need of a server in the infrastructure to which these
interfaces would first connect (a sort of an 'anchor').

If such a technology is developped, it will surely be useful for more
than homenets - it will be useful for multi-interfaced smartphones,
useful for mobile routers installed in vehicles, and more that I can
not think of.

Alex PS: there are a few IETF Internet Drafts about how would
smartphones would use this, with Mobile IPv4 and Mobile IPv6
extensions, but there are no widespread implementations.

Le 22/10/2014 11:48, Xueli a écrit :

Hello

Thanks Barbara to send this liaison out.

Hybrid Access network is that Residential gateway (RG, or CPE) is
extended with more than two access lines

(e.g. DSL + LTE) in order to provide higher bandwidth for the
customers. The scenario and architecture are shown as follows

cid:image002.jpg@01CF9A07.BF8CD480

Right now, we have two individual drafts, one for architecture and
requirements, and the other one is for an optional solution.

The draft
(http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architec



ture-00  ; ) proposes the architecture and gap analysis.


The solution draft proposes one option for the solutions,
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00

We did not combine them as one draft, because we believe there may
be other candidates, and we would like to have further discussions
in the related groups and IETF.

We used to present it in Homenet in Toronto.

Now the authors have invited Orange to join this architecture
work. We will send out the new version of these drafts soon.

We are glad to invite the experts for comments.

Best Regards

Li Xue on the co-authors behalf

-Original Message-

From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Ted
Lemon

Sent: Wednesday, October 22, 2014 3:05 AM

To: STARK, BARBARA H

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband
Forum Work on “Hybrid Access for Broadband Networks”(WT-348)"

On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H 
wrote:


FYI. I made sure they were aware of IETF mif and homenet
activities in this area. I intend to try to prevent having to
track efforts that try to do the same thing in two different
ways. But some of the BBF effort  may be focused on what can be
done around "bonding" of multiple

interfaces that are under the control of a single service provider.
I don't see this in mif or homenet.

Thanks.   I couldn't really tell what was being proposed from the
Liaison statement, so this information is helpful.

___

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet



___ homenet mailing
list homenet@ietf.org
https

Re: [homenet] “Hybrid Access for Broadband Networks” (WT-348)

2014-10-22 Thread Alexandru Petrescu


Hello Xueli,

Several people look at this problem as an IP problem.  Instead of 
considering a cellular+dsl combination in a homebox, they considered 
cellular+wifi on a smartphone.   But the goal was the same: augment the 
bandwidth perceived by the end user.


In implementation it is however quite challenging.  The more tempting 
the expectations of augmenting bandwidth by simply adding network 
interfaces (as in adding RAM to a busy computer), the higher the 
desillusion when facing the challenges of implementation.


Some consider it simply as a local computer policy problem (and hence no 
new communicaiton standards needed), but others consider that there is a 
need of a server in the infrastructure to which these interfaces would 
first connect (a sort of an 'anchor').


If such a technology is developped, it will surely be useful for more 
than homenets - it will be useful for multi-interfaced smartphones, 
useful for mobile routers installed in vehicles, and more that I can not 
think of.


Alex
PS: there are a few IETF Internet Drafts about how would smartphones 
would use this, with Mobile IPv4 and Mobile IPv6 extensions, but there 
are no widespread implementations.


Le 22/10/2014 11:48, Xueli a écrit :

Hello

Thanks Barbara to send this liaison out.

Hybrid Access network is that Residential gateway (RG, or CPE) is
extended with more than two access lines

(e.g. DSL + LTE) in order to provide higher bandwidth for the
customers. The scenario and architecture are shown as follows

cid:image002.jpg@01CF9A07.BF8CD480

Right now, we have two individual drafts, one for architecture and
requirements, and the other one is for an optional solution.

The draft
(http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00
 ; ) proposes the architecture and gap analysis.

The solution draft proposes one option for the solutions,
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00

We did not combine them as one draft, because we believe there may be
 other candidates, and we would like to have further discussions in
the related groups and IETF.

We used to present it in Homenet in Toronto.

Now the authors have invited Orange to join this architecture work.
We will send out the new version of these drafts soon.

We are glad to invite the experts for comments.

Best Regards

Li Xue on the co-authors behalf

-Original Message-

From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Ted
Lemon

Sent: Wednesday, October 22, 2014 3:05 AM

To: STARK, BARBARA H

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum
Work on “Hybrid Access for Broadband Networks”(WT-348)"

On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H 
wrote:


FYI. I made sure they were aware of IETF mif and homenet activities
in this area. I intend to try to prevent having to track efforts
that try to do the same thing in two different ways. But some of
the BBF effort  may be focused on what can be done around "bonding"
of multiple

interfaces that are under the control of a single service provider. I
 don't see this in mif or homenet.

Thanks.   I couldn't really tell what was being proposed from the
Liaison statement, so this information is helpful.

___

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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Let's make in-home ULA presence a MUST !?

2014-10-16 Thread Alexandru Petrescu


Le 16/10/2014 00:57, Michael Thomas a écrit :


On 10/15/14, 3:49 PM, Ted Lemon wrote:

On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:

See, I don't find that ideal at all. If I'm swinging around on my
backyard trapeze watching the flying wallendas instructional
video from my home jukebox, I really don't want to have my
network break connectivity because I happened to switch to my
neighbor's wifi and I was using a ULA when I could have kept
connectivity with a GUA.

This is simply a non-sequitur.   It has nothing to do with homenet.
It has to do with how the stack works on your home, and what the
propagation of radio waves looks like in your back yard. The
assumption that you will be able to access your jukebox over your
neighbor's wifi contains packed in it so much new protocol work we
could fork several working groups to handle it.


If I use a GUA to my jukebox, the routing will just work regardless
of which AP I'm currently connected to. With ULA's, not so much.
That's hardly a non-sequitur.

ULA's with mobility are very problematic IMO.


I think this is right, mobility and ULAs may have some issues.

If by mobility we understand Mobile IP then assigning a GUA to HA (or
some form of protocol forwarding from the Box to the HA) only may allow
to then use ULAs for the mobile devices.  The implications of NATv6 may
vary.


I'm a lot more likely to wander onto my neighbor's home network than
to suffer a flash renumbering from one of my providers.


Yes and no.  WiFi wandering is completely under the enduser's control.


Mobility considerations aren't a distant future, they're now.


I agree.

Alex



Mike

___ 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

Re: [homenet] Let's make in-home ULA presence a MUST !?

2014-10-16 Thread Alexandru Petrescu


Le 16/10/2014 00:49, Ted Lemon a écrit :

On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:

See, I don't find that ideal at all. If I'm swinging around on my
backyard trapeze watching the flying wallendas instructional video
from my home jukebox, I really don't want to have my network break
connectivity because I happened to switch to my neighbor's wifi and
I was using a ULA when I could have kept connectivity with a GUA.


This is simply a non-sequitur.   It has nothing to do with homenet.


I agree it has nothing to do with homenet.

It is a problem at work, at airport, in public garden, in the street, at 
the restaurant - in general in every place where WiFi arrived.


It is an entirely WiFi connection management problem.  In Windows it can 
be avoided by unchecking the "Automatically Connect To" attached to that 
WiFi ESSID, or more brutally by removing that undesired profile completely.


Alex


It has to do with how the stack works on your home, and what the
propagation of radio waves looks like in your back yard.   The
assumption that you will be able to access your jukebox over your
neighbor's wifi contains packed in it so much new protocol work we
could fork several working groups to handle it.


As far as homenet goes, i'd rather it not bake in any assumptions
about ULA's beyond what is already there.


I hear you.   But why should the working group care what you prefer?
I don't say that to be dismissive, but to encourage you to give a
reason that isn't just an opinion.

___ 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

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-10 Thread Alexandru Petrescu


Le 09/10/2014 21:17, Brian E Carpenter a écrit :

On 09/10/2014 22:29, Alexandru Petrescu wrote:

Thanks for updating.

Le 09/10/2014 11:26, Pierre Pfister a écrit :

Hello,

I’m proposing this change then.

1. In case the provided prefix is 64, the default consist in assigning
prefixes of length 64 first.
2. I’m adding a reference to 6man-why64.

When the algorithm decides to make a new assignment, it first needs
 to specify the desired size of the assigned prefix.  Although this
 algorithm intends to remain generic, it was observed in
 [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
 length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.


With this text above, operators will be encouraged to read and give /64
to end user sites.


Huh? This text is discussing internal subnets inside the homenet; it
has nothing to do with the ISP allocation, which is discussed in the
homenet architecture (and RFC 6177).


Yes, I looked at RFC 6177 and I agree in a sense.  It is the ISP 
out-of-ones-homenet that is concerned by RFC6177 to assign more than /64 
to homenet.


But, ISPs may be interested in populating one's homenet with more than 
just 1 or 2 boxes currently.  Theyd will rather use this HNCP document 
to build one's homenets, rather than an architecture document.


At that point that ISP may become an internal-subnet-ISP in one's 
homenet.  And will tend to allocate only /64s for anything one wants to 
do in one's homenet beyond the subnets ISP builds.  And that will forbid 
one again to go beyond what ISP allows.


Which may end up in the same /64 limit.

(I speculate that however many devices ISPs put in a homenet there will 
always be some other devices they forgot but need to be there).


(one recent announcement of many devices in home is from Orange, and one 
deployed practice of always-2 boxes is from Free).


Alex



 Brian






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-09 Thread Alexandru Petrescu


Hello Pierre,

Le 09/10/2014 11:26, Pierre Pfister a écrit :
[...]

The following table MAY be used as default values, where X is the
length of the delegated prefix.

If X <= 64:  Prefix length = 64


I disagree.  In general, for assigning prefixes, and subsequently 
routing to them, I do not understand why should one recommend any prefix 
length at all, and even less to make it default.


This default prefix len above may prohibit one in a homenet to be an ISP 
for other smaller IoT networks.


Look, we have another draft in 6man that calls for adoption, 
draft-boucadair-6man-prefix-routing-reco-00.  That draft recommends the 
following:

   Forwarding and routing protocols MUST NOT restrict by design the
   length of IPv6 prefixes.  In particular, forwarding and routing
   processes MUST be designed to accept prefixes of any length up to
   /128.


What do you think?

Alex




….

Processes proposed in the appendix are optional.
Our implementation supports some part of it, and it works fine in our
test-cases.
I’d rather have a /80 than no connectivity at all (And it just works.).
IMO, why64 is way too pessimistic on the current implementation state
and even more when it comes to the progress implementations will do in
the coming years.

And we either do that or let people do NAT66. ;)


Is it OK for you Ole ?

Cheers,

- Pierre

Le 9 oct. 2014 à 07:25, Mark Townsley mailto:m...@townsley.net>> a écrit :





On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:


On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister mailto:pierre.pfis...@darou.fr>> wrote:
Why should we mandate homenet implementations to *brake* in
situations where they could work fine ? Why should we voluntarily
prevent a link from being configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a ‘ISP MUST
provide a /56 to customers’ than ‘Homenet MUST brake when the
provided prefix is not big enough’.


But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don’t go longer than /64, and ISPs should provide enough prefixes.

The why64 text is very relevant here.


And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).


Informative reference, as we don't want to create a downref over this.



Certainly the mechanisms should support any prefix length,


I agree.

- Mark


but
the reality remains that only /64 subnets work properly in all
circumstances today.

  Brian

___
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





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-09 Thread Alexandru Petrescu


Le 09/10/2014 02:35, Brian E Carpenter a écrit :

On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:

Why should we mandate homenet implementations to *brake* in situations where 
they could work fine ? Why should we voluntarily prevent a link from being 
configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 to 
customers’ than ‘Homenet MUST brake when the provided prefix is not big enough’.


But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don’t go longer than /64, and ISPs should provide enough prefixes.

The why64 text is very relevant here.


And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).

Certainly the mechanisms should support any prefix length, but
the reality remains that only /64 subnets work properly in all
circumstances today.


But this is new work, not work documenting existing practice.

Alex



 Brian






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-09 Thread Alexandru Petrescu


Thanks for updating.

Le 09/10/2014 11:26, Pierre Pfister a écrit :

Hello,

I’m proposing this change then.

1. In case the provided prefix is 64, the default consist in assigning
prefixes of length 64 first.
2. I’m adding a reference to 6man-why64.

When the algorithm decides to make a new assignment, it first needs
to specify the desired size of the assigned prefix.  Although this
algorithm intends to remain generic, it was observed in
[I-D.ietf-6man-why64] that hosts may malfunction when the prefix
length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.


With this text above, operators will be encouraged to read and give /64 
to end user sites.


Alex


The following table MAY be used as default values, where X is the
length of the delegated prefix.

If X <= 64:  Prefix length = 64

….

Processes proposed in the appendix are optional.
Our implementation supports some part of it, and it works fine in our
test-cases.
I’d rather have a /80 than no connectivity at all (And it just works.).
IMO, why64 is way too pessimistic on the current implementation state
and even more when it comes to the progress implementations will do in
the coming years.

And we either do that or let people do NAT66. ;)


Is it OK for you Ole ?

Cheers,

- Pierre

Le 9 oct. 2014 à 07:25, Mark Townsley mailto:m...@townsley.net>> a écrit :





On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:


On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister mailto:pierre.pfis...@darou.fr>> wrote:
Why should we mandate homenet implementations to *brake* in
situations where they could work fine ? Why should we voluntarily
prevent a link from being configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a ‘ISP MUST
provide a /56 to customers’ than ‘Homenet MUST brake when the
provided prefix is not big enough’.


But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don’t go longer than /64, and ISPs should provide enough prefixes.

The why64 text is very relevant here.


And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).


Informative reference, as we don't want to create a downref over this.



Certainly the mechanisms should support any prefix length,


I agree.

- Mark


but
the reality remains that only /64 subnets work properly in all
circumstances today.

  Brian

___
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





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-08 Thread Alexandru Petrescu


Le 08/10/2014 15:14, Pierre Pfister a écrit :
[...]

Why should we mandate homenet implementations to *break* in
situations where they could work fine ? Why should we voluntarily
prevent a link from being configured if we actually can configure it
?


Sorry, there is no intention to tell networks where 64 works that 64
must not work.

There is however an intention to not say 64, and just say 'n'.

Old:

Although that choice is completely implementation specific, prefixes
of size 64 are RECOMMENDED.


New:
> Although that choice is completely implementation specific,
> implementations MUST support prefixes of arbitrary length.

Alex

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP

2014-10-08 Thread Alexandru Petrescu


Le 08/10/2014 14:55, Mikael Abrahamsson a écrit :

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:


Le 08/10/2014 14:34, Mikael Abrahamsson a écrit :

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:


as I could have divided it differently, or I could have announced the
/61 in RA in the first link of the homenet, etc.


Why on earth would you want to do that?


divide differently? or /61 in RA?


Divide at anything else than /64.


I meant a /61 can be divided in 8 /64s, or in 4 /64s plus 2 /63s, right? 
 There are some configuration advantages for the latter.




A=1 in SLAAC doesn't work unless
you're using /64 subnet size.


I didnt know that?  Can you elaborate?  Is it that I can not set radvd 
with A=1 and plen=63?  Or is it that the Host receiving this RA will not 
know what do with this RA?


Alex






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP

2014-10-08 Thread Alexandru Petrescu


Le 08/10/2014 14:34, Mikael Abrahamsson a écrit :

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:


as I could have divided it differently, or I could have announced the
/61 in RA in the first link of the homenet, etc.


Why on earth would you want to do that?


divide differently? or /61 in RA?

Alex


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP

2014-10-08 Thread Alexandru Petrescu


Le 08/10/2014 14:15, Pierre Pfister a écrit :


Le 8 oct. 2014 à 13:58, Alexandru Petrescu
 a écrit :


Hi Pierre,

Le 08/10/2014 13:28, Pierre Pfister a écrit :

Hi Alex,

Reply is inlined,

Le 8 oct. 2014 à 12:09, Alexandru Petrescu
 a écrit :


Hi Pierre,

Thanks for the draft update.  Now I have two questions:


prefixes of size 64 are RECOMMENDED.


Why is this length recommended?  I think it may be because of
Ethernet?


I’m not a big fan of putting 64s everywhere neither. And I
strongly disagree with mandating 64 bit long prefixes. The prefix
algorithm itself is agnostic on this side.

Nevertheless, some parts of this document are home-network
specific. Not even talking about crappy implementations, home
network links should support SLAAC whenever possible. Which is
the reason why using 64bit long prefixes is RECOMMENDED.


Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.


SLAAC relies on ‘interface identifier’. Ethernet uses the EUI-64. I
have no knowledge of other methods of generating an interface
identifier.

The why64 draft is interesting (and sad) on that front.




But smaller prefixes are better than *no prefix at all*. When
there are not enough prefixes available (e.g. the ISP provides a
single 64 while we have multiple links), smaller prefixes can be
used (80 for instance). Which means dhcpv6 must be used. Our
implementation supports it, and it works with my laptop.


Ok.


But again, that should be avoided whenever possible. And ISPs
MUST provided enough prefixes (IMO).


I agree with you.

Last time I checked Free ISP seems to provide 8 /64 prefixes to my
homenet: 2001:db8:0:ce10::/64 2001:db8:0:ce11::/64 ...
2001:db8:0:ce17::/64 I dont think these could be aggregated into a
single shorter prefix, or my math is missing.


That is 2001:db8:0:ce10::/61


Right, sorry, my math was missing.  So I suppose Free ISP delegates a
single /61 to me then, not several /64s.  This is a local prefix
division performed in that router.  I do not necessarily agree with it,
as I could have divided it differently, or I could have announced the 
/61 in RA in the first link of the homenet, etc.






Second, their (Free's) web interface asks me to put a next hop for
each of these prefixes.


I’m not sure what that means. Is that in the freebox ?


YEs, it is in the Freebox Server (not Player), the freebox OS 3.0, sorry 
no advertisement.



I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?


It does not support DHCPv6-PD Server on the ingress side, or otherwise 
these fields containing 'next-hop' would have not been there.


As DHCPv6-PD Client on the egress side - I dont know, no means to check 
unless I loose it.



If you put a homenet router below your freebox, you will have to
provide a prefix to the homenet router manually (which is supposed to
be done by DHCPv6-PD).


Yes, I agree with  you.  No DHCP-PD at this time.

But if the freebox had a daemon listening to commands to fill in these 
next-hop fields then it would work.


I am saying this because I speculate the way in which this particular 
operator may work, but I have no affiliation with it.


Alex


Do you think HNCP implementation may help fill in these fields
automatically somehow?



Maybe it would be advantageous to not make any recommendation
on the prefix length.  Some times this may develop into a
barrier beyond which it will be hard to go.

The other question is about the assumed capability to decide
non between prefixes, such as to detect collisions.  Do you
think it is possible to decide equality between prefixes?  I
rather think prefixes have a more refined relationship than
just equal/not-equal - e.g. they are also aggregated.

If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1
do you think a 'collision' could be detected?  I doubt we have
such an algorithm somewhere.



Equality is never considered alone. Actually, most of the time,
you will find considerations such as: The prefix is not included
or does not include any other Assigned Prefix with a higher
precedence.


I wonder about the implementability of this statement, but yes it
may be possible to write one.


I’ll reply to your other mail concerning that.




This is how collisions are detected.


Ok.

Alex



Cheers,

- Pierre



Alex



Le 30/06/2014 17:18, Pierre Pfister a écrit :

Hello group,

I’d like to inform you about the changes made in the two
last homenet-prefix-assignment updates.

http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02







The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).



— Changes between 00 and 01

- If a Delegated Prefix is included in another Delegated
Prefix, it is ignored. This is intended to improve support
for non-homenet routers that provide prefix sub-delegation.
That way, sub-delegated prefixes are i

Re: [homenet] on prefix comparison

2014-10-08 Thread Alexandru Petrescu


Pierre, just a small doubt, but I agree with you in general.

Le 08/10/2014 13:58, Alexandru Petrescu a écrit :
[...]

Equality is never considered alone. Actually, most of the time, you
will find considerations such as: The prefix is not included or does
not include any other Assigned Prefix with a higher precedence.


It is hard to say whether a prefix is included into another or not.  We 
do not have a published algorithm to say what it means for a prefix to 
include another.


In general, we have a common understanding (and not published algorithm) 
about what it means 'longest prefix match'.  But that compares an 
address to a prefix, not a prefix to a prefix.


Sure, one could assume that an address is just a /128 prefix and execute 
longest prefix match with it as if it were an address.


But then again which prefix has the role of the address and which is the 
role of the prefix?  In other words, when hearing two prefixes on a link 
and want to compare them, which of them should be compared against the 
other by using the longest-prefix match?  There are two possibilities 
and two different outputs for a particular tuple of prefixes, depending 
on the order of this longest prefix match.


Of course, I do not mention the easy case which compares two prefixes of 
precisely same length.


Just because the length is different may make think that the prefixes 
are different.  Or otherwise one could be aggregated into another.  But 
there are several types of aggregation: matching up to the shortest 
length, matching up to middle, up to longest length, beyond the longest 
length.


These cases are not documented and people may implement them in many 
different ways with different outputs when trying to tell whether this 
or that prefix are equal or included into one another.


Alex


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-08 Thread Alexandru Petrescu


Hi Pierre,

Le 08/10/2014 13:28, Pierre Pfister a écrit :

Hi Alex,

Reply is inlined,

Le 8 oct. 2014 à 12:09, Alexandru Petrescu
 a écrit :


Hi Pierre,

Thanks for the draft update.  Now I have two questions:


prefixes of size 64 are RECOMMENDED.


Why is this length recommended?  I think it may be because of
Ethernet?


I’m not a big fan of putting 64s everywhere neither. And I strongly
disagree with mandating 64 bit long prefixes. The prefix algorithm
itself is agnostic on this side.

Nevertheless, some parts of this document are home-network specific.
Not even talking about crappy implementations, home network links
should support SLAAC whenever possible. Which is the reason why using
64bit long prefixes is RECOMMENDED.


Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.


But smaller prefixes are better than *no prefix at all*. When there
are not enough prefixes available (e.g. the ISP provides a single 64
while we have multiple links), smaller prefixes can be used (80 for
instance). Which means dhcpv6 must be used. Our implementation
supports it, and it works with my laptop.


Ok.


But again, that should be avoided whenever possible. And ISPs MUST
provided enough prefixes (IMO).


I agree with you.

Last time I checked Free ISP seems to provide 8 /64 prefixes to my homenet:
2001:db8:0:ce10::/64
2001:db8:0:ce11::/64
...
2001:db8:0:ce17::/64
I dont think these could be aggregated into a single shorter prefix, or 
my math is missing.


Second, their (Free's) web interface asks me to put a next hop for each 
of these prefixes.


Do you think HNCP implementation may help fill in these fields 
automatically somehow?




Maybe it would be advantageous to not make any recommendation on
the prefix length.  Some times this may develop into a barrier
beyond which it will be hard to go.

The other question is about the assumed capability to decide non
between prefixes, such as to detect collisions.  Do you think it is
possible to decide equality between prefixes?  I rather think
prefixes have a more refined relationship than just equal/not-equal
- e.g. they are also aggregated.

If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do
you think a 'collision' could be detected?  I doubt we have such an
algorithm somewhere.



Equality is never considered alone. Actually, most of the time, you
will find considerations such as: The prefix is not included or does
not include any other Assigned Prefix with a higher precedence.


I wonder about the implementability of this statement, but yes it may be 
possible to write one.



This is how collisions are detected.


Ok.

Alex



Cheers,

- Pierre



Alex



Le 30/06/2014 17:18, Pierre Pfister a écrit :

Hello group,

I’d like to inform you about the changes made in the two last
homenet-prefix-assignment updates.

http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02



The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).



— Changes between 00 and 01

- If a Delegated Prefix is included in another Delegated Prefix,
it is ignored. This is intended to improve support for
non-homenet routers that provide prefix sub-delegation. That way,
sub-delegated prefixes are ignored.

- Adding network leader definition (The router with the highest
identifier).

- Add a section about DHCPv6 downstream prefix delegation. For
downstream RFC7084 routers support.

- Adding Delegated Prefix deprecation procedure in order to
differentiate prefix deprecation and node disconnection. When a
node disconnect, the DPs advertised by this node may be kept some
time (depending on the DP's lifetimes). But if a DP is actively
deprecated, nodes must stop using it immediately.


— Changes between 01 and 02

- Designated router election can make use of the information
provided by the flooding protocol (i.e. when no router is
designated yet, only the highest router id present on the link
can become designated).

- New implementation guideline in appendix concerning "prefix
waste avoidance". It proposes an algorithm that provides a good
trade-of between randomness, pseudo-randomness and prefix
selection efficiency.



Comments are welcome,

Pierre Pfister ___
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







___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-08 Thread Alexandru Petrescu


Hi Pierre,

Thanks for the draft update.  Now I have two questions:


prefixes of size 64 are RECOMMENDED.


Why is this length recommended?  I think it may be because of Ethernet?

Maybe it would be advantageous to not make any recommendation on the 
prefix length.  Some times this may develop into a barrier beyond which 
it will be hard to go.


The other question is about the assumed capability to decide non between 
prefixes, such as to detect collisions.  Do you think it is possible to 
decide equality between prefixes?  I rather think prefixes have a more 
refined relationship than just equal/not-equal - e.g. they are also 
aggregated.


If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you 
think a 'collision' could be detected?  I doubt we have such an 
algorithm somewhere.


Alex



Le 30/06/2014 17:18, Pierre Pfister a écrit :

Hello group,

I’d like to inform you about the changes made in the two last 
homenet-prefix-assignment updates.

http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02

The changes are mostly about fixing typos, but a few technical changes have 
been made as well (based on the experience gained from the implementation of 
the Prefix Assignment Algorithm over HNCP).


  — Changes between 00 and 01

- If a Delegated Prefix is included in another Delegated Prefix, it is ignored. 
This is intended to improve support for non-homenet routers that provide prefix 
sub-delegation. That way, sub-delegated prefixes are ignored.

- Adding network leader definition (The router with the highest identifier).

- Add a section about DHCPv6 downstream prefix delegation. For downstream 
RFC7084 routers support.

- Adding Delegated Prefix deprecation procedure in order to differentiate 
prefix deprecation and node disconnection. When a node disconnect, the DPs 
advertised by this node may be kept some time (depending on the DP's 
lifetimes). But if a DP is actively deprecated, nodes must stop using it 
immediately.


  — Changes between 01 and 02

- Designated router election can make use of the information provided by the 
flooding protocol (i.e. when no router is designated yet, only the highest 
router id present on the link can become designated).

- New implementation guideline in appendix concerning "prefix waste avoidance". 
It proposes an algorithm that provides a good trade-of between randomness, 
pseudo-randomness and prefix selection efficiency.



Comments are welcome,

Pierre Pfister
___
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

Re: [homenet] Clarification on Routing Thoughts

2014-08-01 Thread Alexandru Petrescu


Le 01/08/2014 12:44, Ole Troan a écrit :

It seems to me that you are grasping for a use case to justify a split
where none is needed.  Protocols like OSPF, IS-IS and Babel would all
work in both environments. RIP won't.  So this seems more like an
argument not to use RIP than an argument to have two different homenet
router profiles.


For the record, can you expound on the technical reason why RIP(v2) won't
work?  (I'm not a fan of it, but last time I used it was on SunOS 3 or
something)


hop count isn't a great tool for expressing that  your gig-e port is a
more desireable path if up  then the wifi interface.



the cost/metric is perfectly fine for that.
assuming a relatively small network diameter.


I think Joël's reluctance about hopcount qualifying the gig-e/wifi
choice may change if considering wifi-ac instead. I.e. hopcount may be
good to qualify a choice between Gigabit Ethernet and Gigabit wifi.

Alex



cheers,
Ole



___
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

Re: [homenet] list of questions on routing section

2014-06-20 Thread Alexandru Petrescu


Le 20/06/2014 15:44, Gert Doering a écrit :

Hi,

On Fri, Jun 20, 2014 at 03:33:15PM +0200, Alexandru Petrescu wrote:

I would see a requirement about DHCP Relay-Server discovery and
configuration but I am not sure how to formulate it at architectural level.


I see a very strong need for you to read up on the homenet drafts *before*
trying to add your valuable input.

Really.  90% of what you have written is either covered by the drafts already,
or fully out of scope.  You are wasting people's time.

Gert Doering
 -- NetMaster



Sorry about that - please ignore that email.

Alex


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] list of questions on routing section (was: Updates to Homenet Architecture Principles doc)

2014-06-20 Thread Alexandru Petrescu


Le 14/06/2014 15:44, Ray Hunter a écrit :
[...]

Does the Homenet Architecture require the routing protocol to carry
arbitrary configuration information?
[my view] No. Assuming the existence of a separate Homenet configuration
protocol, the routing protocol must facilitate auto-configuration, but
does not necessarily have to supply configuration to other processes.
[this is not currently explicitly defined the architecture document AFAICS]


I agree a routing protocol in-house would not need to carry parameters 
such as printer's name.



Does the Homenet Architecture require the routing protocol to support
multiple address families?
[my view] No. The Homenet architecture is IPv6 only. Although support
for IPv4 and other address families may be beneficial, it is not an
explicit requirement to carry the routing information in the same
routing protocol.
[this is not currently in the architecture document AFAICS]


I think the routing protocol must unconditionally support IPv6 natively 
and, if needed in some cases, IPv4.



Does the Homenet Architecture require the routing protocol to support SADR?
[my view] Yes.
[this is in the current architecture document]


I think the routing protocol specs should include fields for source 
addresses (in addition to the traditional next-hop addresses), in order 
to facilitate source-and-destination rule matching in the routing 
tables.  But I dont think the routing protocol would implement anything 
more than carrying fields specific to sources.



"A routing protocol that can make routing
decisions based on source and destination addresses is thus
desirable, to avoid upstream ISP BCP 38 ingress filtering problems."


I doubt the routing _protocol_ makes decisions about that.


Does the Homenet Architecture require the routing protocol to be
tolerant of lossy unstable links?
[my view] Yes.
[this is in the current architecture document]
"Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the
homenet."


Certainly yes.

But this mentioning of MoCA makes wonder about a document IP-over-MoCA, 
which wouldn't be developped here, but would be necessary.


If IP does not run over MoCA then the coexistence statement above would 
make little sense.


Then, for the metric parameters, in addition to bandwidth, loss and 
latency, some parameters such as link energy consumption, or radiated 
energy, would make sense.



Does the Homenet Architecture explicitly require use of a distance
vector or link state algorithms?
[my view] No. The Homenet architecture should be agnostic on this point.
[this is not currently in the architecture document AFAICS]


Yes, I agree.

Any one of distance-vector, link-state, path-vector or any combination, 
should be selectable.  A particular existing routing protocol should not 
be discarded solely on grounds of its link-state or distance-vector 
characteristic.  It's invalid to say "in-house routing can not be 
satisfied by a link-state protocol".


And there are other such characteristics: on-demand vs triggered, 
proactive vs reactive.



Does the Homenet Architecture need an EGP or an IGP?
[my view] An IGP.
[this is in the current architecture document]
This implies that internal routing
functionality is required, and that the homenet's ISP both provides a
large enough prefix to allocate a prefix to each subnet, and that a
method is supported for such prefixes to be delegated efficiently to
those subnets.


I agree.


Is there a minimum hop count limit that must be supported?
[my view] No. The Homenet architecture is agnostic on this point,
although use of Homenet in small offices and small enterprise site may
require higher hop counts.
[this is not currently in the architecture document AFAICS]


I agree, and I'd go as far as citing numbers.

A typical in-house network would use 1, 3 to maximum 5 hops between any 
two most distanced nodes (hop limit decremented 5 times max).  It would 
link typical maximum of 255 uniquely IP-addressable interfaces.


A SOHO and small enterprise would require higher hop counts.


Is there a penalty for the protocol being chatty?
[my view] No. LLN is not envisaged to be used as a transit network, and
as such would be connected by a gateway router.
It is not envisaged that there will be significant limits on bandwidth
consumption or Homenet routers having to sleep for power efficiency.
[this is not currently in the architecture document AFAICS]


Yes, but chattiness in-house may translate into higher electricity bill.

Some people go as far as switching off the entire electricity when 
leaving home.  Adding a new protocol reads maybe as adding something new 
to switch off.

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-17 Thread Alexandru Petrescu


Le 16/06/2014 22:18, Gert Doering a écrit :

Hi,

On Mon, Jun 16, 2014 at 10:09:34PM +0200, Alexandru Petrescu wrote:

Some deployments of IPv6 homenets with multiple IP subnets dont run
routing protocols, but static routing.  I've discovered that recently
with much enthusiasm.  Maybe it's just a first step, but I havent seen
documented this simple and numerous existing deployments.


This is not a "homenet" as per this architecture document.  The key is
"it needs to work for your parents, without you driving over and
setting it up for them".


I suppose parents will likely ask the IPv6 specialists something like this:
- should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'?
- should I click on ULA or not?
- should I click on private addresses or not?
- should I click on Delegate inside when using Delegate from outside,
  or not?
- what should I fill in as next-hop address?
- what does "dotted-decimal notation" mean with IPv6 addresses?
(these are examples from existing consumer equipment for in-house)

Little chances are there that parents will ask whether to use BGP or 
OSPF or please design a protocol for me. (haven't seen these options on 
consumer equipment GUIs).



I know people that have BGP routing with PI space at home, but the fact
that it's "at home" does not make it a *homenet*.


I agree.

Alex



Gert Doering
 -- NetMaster




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-16 Thread Alexandru Petrescu


Le 15/06/2014 18:03, Juliusz Chroboczek a écrit :

"The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet."



Should the text then rather say "Path selection in Homenet needs to be
more sophisticated than measuring pure hop count due to the use of
heterogeneous link technologies, and therefore the routing protocol should
be capable of utilising multiple link-dependent metrics, such as
bandwidth, delay, and link reliability", rather than mentioning
"optimised"?


I'm happy with either.  The current text leaves it to the protocol people
to decide what "optimising" means, but I also like the way you spell out
the requirement.  If you'll allow me to indulge in some minor nit picking
wrt. your suggested wording:

  - you require "multiple [...] metrics", which is what we do in Babel, but
we certainly don't wish to prevent somebody from being smart enough to
design a single metric that works satisfactorily on all link layers;
  - you use "bandwdith" where you mean "throughput" (yeah, I know, I'm
a pedant);
  - I'm on a personal crusade against the utilisation of the verb "to utilise".

So perhaps something like:

   Due to the use of heterogeneous link technologies, path selection in
   a homenet needs to be more refined than minimising hop count.  The
   homenet routing protocol should be able to select paths according to
   criteria such as latency, throughput, link reliability (e.g. measured
   packet loss) or other performance metrics.


I agree.  Some of the new performance metrics which are unaccounted for, 
but present in deployments, is the quantity of radio energy in the air. 
 This is a real customer issue for which current deployed solutions are 
on/off knobs (I want a knob to turn off all WiFi in my home, turn off 
all cellular in my home, turn off all Bluetooth in my home, etc).  More 
sophisticated solutions would involve metrics which quantify this and 
compare meaningfully.  An example is the DAS parameter for mobile phones.


Alex



-- Juliusz

___
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

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-16 Thread Alexandru Petrescu


Le 14/06/2014 17:49, Juliusz Chroboczek a écrit :

So even though link-local multicast may be part of the IPv6 base spec,
it may be desirable to avoid use of multicast traffic where
possible. e.g. a routing protocol could perform initial neighbor
discovery using multicast, but then switch to unicast when maintaining
individual neighbor associations on the longer term, or for exchanging
information with specific neighbors.


Ah, I see.  Yes, that makes sense.


Then I think I don't understand what is meant by "multi-path support".  Is
that merely the ability to switch to a better route if one becomes
available?  Or is there something more to it?  Could you please clarify?



"The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet."



I interpret the above text as requesting an ability to perform load
balancing over equal cost paths, potentially taking into account packet
loss and link quality when selecting which stream to send over which link.


I don't.  I interpret that as meaning that the routing protocol should be
able to pick a path using more refined criteria than just hop count.
E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops
to a single wireless one.  Doing that is not too difficult, and yields
dramatic performance improvements in some fairly simple, realistic
topologies.


I agree.  We did that in a lab experiment with OSPF on 
Ethernet/Bluetooth/WiFi and by defining new metrics.


Alex




Load sharing is a completely different headache.  Done carelessly, load
sharing causes issues with increased latency and jitter, and causes
intermittent connectivity problems that are very difficult to troubleshoot
if one of the links is unreliable.  It also has ghastly performance if you
balance across wireless links without taking radio interference into account.

While it's certainly an area worth experimenting with, I'd be cautious
about requiring load sharing in Homenet unless somebody knows how to do it
right in the general unadministered case.

-- Juliusz

___
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

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-16 Thread Alexandru Petrescu


Hi Mark, participants to homenet WG,

I have some comments, FWIW.

Le 14/06/2014 10:04, Mark Townsley a écrit :


On Jun 13, 2014, at 10:44 PM, Ted Lemon mailto:mel...@fugue.com>> wrote:



On Jun 13, 2014, at 4:27 PM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>>
wrote:

It's prototype implementations and early deployments that will
tell us the right answer, not further debate.


Again, I didn't ask for "the answer."   I asked for a description
of what we want in a routing protocol that isn't so prescriptive.
There's a lot of prescriptive stuff in there, and the reason that
the particular paragraph you are proposing we remove got added was
to counterbalance it.   E.g., why is there a paragraph about all
the routers knowing the whole topology of the network?   Maybe they
will, maybe they won't, but why is it specified?   If we don't know
what we want, this bit seems awfully specific.   If we do know what
we want, why not say what we want?

I think the right answer is to take out more text, but I'm not okay
 with just taking out the particular paragraph you mentioned, or I
 would not have asked for the working group's help on this.



While I agree with Brian here, if you want more text out, so be it.
Here's a proposal which

does that, stopping short of trying to continue word-smithing the
document at this stage.


I simply took section 3.5 from -16, and removed sentences that seemed
to me to be overlyprescriptive,

including the paragraph from Adrian.


Ted, Is that good enough for you?



Removed:




Using information distributed through the routing protocol, each node
in the homenet should be able to build a graph of the topology of the
whole homenet including attributes such as links, nodes,
connectivity, and (if supported by the protocol in use) link
metrics.


Routing within the homenet will determine the least cost path across
the homenet towards the destination address given the source
address. The path cost will be computed as a linear sum of the metric
assigned to each link.  The metric may be configured or automatically
derived per link based on consideration of factors such as worst-case
queue depth and router processing capabilities.


The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet.


Homenets may use a variety of underlying link layer technologies,
and may therefore benefit from being able to use link metrics if
available.  It may be beneficial for traffic to use multiple paths
to a given destination within the homenet where available, rather
than a single best path.



Result:










3.5
.
Routing functionality



Routing functionality is required when there are multiple routers
deployed within the internal home network.  This functionality could
be as simple as the current 'default route is up' model of IPv4 NAT,
or, more likely, it would involve running an appropriate routing
protocol.  Regardless of the solution method, the functionality
discussed below should be met.

The homenet unicast routing protocol should be based on a previously
deployed protocol that has been shown to be reliable and robust, and
that allows lightweight implementations, but that does not preclude
the selection of a newer protocol for which a high quality open
source implementation becomes available.


Sounds as if there is no lightweight implementations high quality
open source of existing routing protocols?


The routing protocol should support the generic use of multiple
customer Internet connections, and the concurrent use of multiple
delegated prefixes.  A routing protocol that can make routing
decisions based on source and destination addresses


Sounds as if current implementations dont do that?


is thus desirable, to avoid upstream ISPBCP 38
  ingress filtering problems.
Multihoming support should also include load-balancing to multiple
providers, and failover from a primary to a backup link when
available.  The protocol however should not require upstream ISP
connectivity to be established to continue routing within the
homenet.

Multiple types of physical interfaces must be accounted for in the
homenet routed topology.  Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment.

The routing environment should be self-configuring, as discussed
previously.  Minimising convergence time should be a goal in any
routed environment, but as a guideline a maximum convergence time at
most 30 seconds should be the target (this target is somewhat
arbitrary, and was chosen based on how long a typical home user
might wait before attempting another reset; ideally the routers might
have some status light indicating they are converging, similar to an
ADSL r

Re: [homenet] DHCP PD

2014-02-05 Thread Alexandru Petrescu


Le 05/02/2014 15:01, Ole Troan a écrit :

Ted,


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.


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


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


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


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



cheers, Ole




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

2014-02-05 Thread Alexandru Petrescu


Le 05/02/2014 09:06, Mikael Abrahamsson a écrit :

On Wed, 5 Feb 2014, Brian E Carpenter wrote:


On 05/02/2014 12:13, Michael Richardson wrote:

Pierre Pfister  wrote:

...

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.


Yes, that's one of many reasons why using prefixes to distinguish
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.


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

Alex






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

2014-02-05 Thread Alexandru Petrescu


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.


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


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



cheers, Ole




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-02-04 Thread Alexandru Petrescu


Le 04/02/2014 17:35, Juliusz Chroboczek a écrit :

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)


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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

2014-02-03 Thread Alexandru Petrescu


Le 03/02/2014 15:11, Ray Bellis a écrit :


On 3 Feb 2014, at 12:51, Alexandru Petrescu
 wrote:


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


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


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



Ray (no hat)




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

2014-02-03 Thread Alexandru Petrescu


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


Pierre,

Thanks for the reply.

Le 30/01/2014 13:46, Pierre Pfister a écrit :


Le 30 janv. 2014 à 13:38, Alexandru Petrescu
 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 homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-02-03 Thread Alexandru Petrescu


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.


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


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

Alex


Acee

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


On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek
mailto:j...@pps.univ-paris-diderot.fr>> 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 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
 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-01-31 Thread Alexandru Petrescu


Le 31/01/2014 09:56, Ole Troan a écrit :

Teco,


I can see reasons for having shared sub-layer for routing protocol and prefix 
distribution protocol. As example, in MANET we have such already: RFC 5444 and 
5498. If we define a set of TLVs for border router information and prefix 
distribution, it can run on whatever routing protocol. Don't forget BGP.

For Homenet plug&play, I don't suggest to let configure grandma her favorite 
IGP ;)


doesn't that mean we have to pick one?


Yes, and here's my preferred: pick DHCP, it satisfies all requirements; 
where it doesnt update it.  Then plug it into OSPF, then onto BGP.


Alex



cheers,
Ole



___
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

Re: [homenet] Homenet protocol decisions

2014-01-31 Thread Alexandru Petrescu


Le 30/01/2014 22:13, Lorenzo Colitti a écrit :

On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan mailto:otr...@employees.org>> 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.


(just a little point here, because I am encouraged by the beginning of 
the paragraph; yes, you can use a topologically incorrect address as src 
in outgoing packets, there are video stream applications for that; they 
 work especially in the small setting of home, where there's no ingress 
filtering).



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.


I tend to agree, modulo exception above.  And provided I udnerstand the 
word 'blackholing'...


Alex




___
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

Re: [homenet] Homenet protocol decisions

2014-01-30 Thread Alexandru Petrescu


Pierre,

Thanks for the reply.

Le 30/01/2014 13:46, Pierre Pfister a écrit :


Le 30 janv. 2014 à 13:38, Alexandru Petrescu
 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)
 ++



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 homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet







___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-01-30 Thread Alexandru Petrescu


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?

Alex



cheers,
Ole




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-01-30 Thread Alexandru Petrescu


Le 30/01/2014 12:35, Ole Troan a écrit :

Alex,


In my understanding, there is a need to couple the prefix assignment to the 
routing protocol.  Although I am not sure how much tight, or what tight and 
loose might mean.


to clarify what I meant:
tight coupling  --- integrated in a routing protocol, e.g. in 
draft-arkko-homenet-prefix-assignment
loosely coupled --- separate (new) protocol


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.

Alex



cheers,
Ole




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-01-30 Thread Alexandru Petrescu


Le 30/01/2014 12:04, Ole Troan a écrit :

In my understanding, there is a need to couple the prefix assignment to the 
routing protocol.  Although I am not sure how much tight, or what tight and 
loose might mean.


to clarify what I meant:
tight coupling  --- integrated in a routing protocol, e.g. in 
draft-arkko-homenet-prefix-assignment
loosely coupled --- separate (new) protocol


Could it be separate (existing) protocol?

Alex



cheers,
Ole




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

2014-01-30 Thread Alexandru Petrescu


Hi,

I am also interested in this direction.

Thanks for the diagram, it illustrates well.

'Tightly couple routing protocol and prefix assignment, as well as
 distribution of other configuration information'?  (yes/no)

Yes.

But,

In my understanding, there is a need to couple the prefix assignment to 
the routing protocol.  Although I am not sure how much tight, or what 
tight and loose might mean.


For example, would coupling the DHCP-PD assignment operations triggering 
routing protocol updates mean tight or loose coupling.  Or would this be 
a 100% alternative to a routing protocol-only prefix assignment solution?


I am asking because I author an inidividual draft
draft-petrescu-relay-route-pd-problem-00.txt
"Route Problem at Relay during DHCPv6 Prefix Delegation" in this space.

Alex

Le 30/01/2014 11:48, Ole Troan a écrit :

All,

Updating the ospf prefix-assingment draft has been on my todo list for a
long time.
Before doing so I wanted to ask the working group if there was any clear
direction evolving.
Any views on the decisions in the flow chart attached? Anything I missed?

To summarize:
We need to decide, if we want prefix assignment and distribution of
other configuration information integrated in a routing protocol.
Depending on that decision we either need to design a separate protocol
to do that, or we need to add support for that in a routing protocol.
Prefix assignment is simpler with a link-state protocol, so that's why I
have limited the choice of routing protocols for that branch. I have
assumed there is agreement to have a single routing protocol in the
home, and not support multiple.

cheers,
Ole




___
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

55 matches

Mail list logo