Pascal,
Please allow me to change the subject of this, to reflect the
content. It helps tracking the discussion.
Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit :
Hello Brian
I meant broadcast at layer 2 not layer 3. L3 uses multicast but
it requires a service at the lower layer to implement it. This
is rarely if ever a real L2 multicast service.
I can agree.
IOW the IETF has thrown the problem over the fence to the IEEE
but it is not really solved to this day.
I think indeed there is redirection of responsability to IEEE.
Maybe IEEE does not like to do it, because of some reasons.
With respect to link-layer multicast: there is indeed no IEEE
messaging for creation or removal of link-layer multicast groups
(like in IP there is MLDv2). But there is concept of link-layer
multicast groups at IEEE. This is used extensively by mapping IP
groups into link-layer groups, and it helps IP.
Should IEEE develop a mechanism using messages (not just local
filters) for creating these link-layer groups?
In practice, the service that is performed on IEEE std 802.3 is
a broadcast over a broadcast domain, and the subnet has to be
contained within that domain.
Well yes and no.
Yes it is a broadcast on 802.3 if we talk IPv4, but it is still
link-layer multicast on 802.3 if we talk IPv6: the link-layer
addresses ofIPv6 on Ethernet are link-layer multicast addresses.
The broadcast operation is emulated on IEEE std 802.11 by the
BSS operation whereby the AP reflects the message to be
broadcasted, so the broadcast domain is that of the AP as
opposed to that of the source STA.
I agree.
By the proposed definition, if car A sees car B they are in the
same subnet. If car B sees car C they are in the same subnet.
Transitively Car A is in the same subnet as car C.
PAscal, again, this depends on how you set up the OCB interfaces
on cars A, B and C.
There are two options: - use a single OCB interface with antenna
sitting on top of each automobile. Make them all in the same
channel frequency (e.g. CCH - Control Channel). That indeed has
that A-B-C transitivity aspect. Worse, it has scalability issues:
one cant grow a convoy beyond a few tens of meters and be sure
the frontmost talks directly to the rearmost. One never knows
whether somebody in the middle repeats, or not. Or one needs to
rely on MANET protocols that may forward on a single interface.
It has some PHY issues as well, that I can describe. The
powerpoint is readily filled with my last PHY experiments of
propagation. - use multiple OCB antennas situated at some
strategic places in a car. This is in the same way as when
placing the other ultra sound, radar and lidar sensors in the
automobile.
An OCB interface in the front bumper of one car forms a subnet
with another OCB interface in the rear bumper of another car, on
a particular channel (SCHx - service channel number x). The
front and rear subnets of a car are in distinct channels. There
is no A-B-C transitivity. There is IP forwarding between front
and rear interfaces of a car.
This can be described. But I dont think it should be described
in the IP-over-OCB document. It is a PHY MAC setting for OCB.
But car C may not be in the radio broadcast domain of car A,
and there is no BSS by definition of OCB to emulate a broadcast
domain between them via an AP. End result is that a DAD or a
lookup by car A will not reach car C.
That may be true, but it is true mostly in a setting where each
car uses a single OCB interface whose antenna is placed on the
roof of the car (placed at same place as the the GPS, LTE, FM or
DVB-T antennas are placed).
In settings where each car has multiple OCB interfaces and
multiple antennas placed at strategic places (strategic: places
that are relevant to PHY propagation conditions), rather than
simply on the roof, the issue you describe in the above
paragraph.
Now, if you read up to here, I would like to ask you (without
claiming to be all-knowing), whether you think a car could have
several OCB interfaces?
By traditional MANET and 6lo definition, the radio broadcast
domain of a node is his link.
It is good, and I agree with it.
For my part, I do not use the traditional MANET and 6lo
definitions because I believe they are not sufficient for
vehicular environments.
In you lab you can arrange that the broadcast domains of 3 cars
fully overlap.
I agree, people do that. It is in small lab, with size in the
range of a few meters; there is much reflexion from the walls.
It is not outdoors.
In that case, the link appears to match the common sense of a
link in wires and the classical IPv6 operations will work
pretty much the same as in a BSS over that Link. It is for
example easy to place a subnet that matches that Link. It is
also easy to confuse a Link with a Subnet, which is what the
definition does. As soon as the broadcast domains start
diverging, things get hairy, see all the work by Erik about
split subnet etc...
I fully agree with this paragraph.
I think if one puts several interfaces and antennas in a car,
and carefully design the use of the propagation models (e.g.
avoid 'omni', consider 'directional', etc) then one can avoid
many problems forbidding IP from running on wireless.
The IETF has studied this situations for 10+ years at MANET,
6TiSCH and 6lo. We have an architecture that cover single link
and multilink subnets.
Yes, there is.
In the former case, the link is defined by one node that owns
the prefix. In the latter case, routing is required inside the
subnet and we created RPL to cover the situation.
YEs, but these are departures from what might be called
traditional IP forwarding. That forwarding happens between two
distinct interfaces.
In practice it means little software for MANET-6lo-multilink is
publicly available, and the engineer skill about them is hard to
find. This translates to equipment being very expensive.
I want to tell you that communication equipment for cars is
already very high compared to an off-the-shelf WiFi router. That
high price tag is due also to specification of things that are
too intelligent and that require high skills from few people.
This is the case of V2X stacks doing ETSI CAM with GeoNetworking
and similar. You end up with a 3000Eur IP-OBU when its
underlying hardware with linux and traditional IP forwarding
costs around 700Eur.
To that 3000Eur one may need to add costs of complexity of MANET
protocols and 6lo multilink subnet moels you arrive at a cost
per communication box that is the equivalent of a small car.
This high cost is less and less acceptable.
Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in
some cars.
We created RFC 8505 for an host to connect to the network in
either situation, without the requirement that the L2 broadcast
domain of the host (its Link) overlaps with that of other nodes
in the subnet (because they don't). We have made RFC 8505
abstract to the routing protocol if any, IOW without the
requirement that the host knows there is a MLSN, understands
RPL or whatever other routing is used
MLSN?
to put together the MLSN. To get there we had to abandon the
dependency that a L2 broadcast from the host reaches all nodes
in the subnet, IOW that the subnet is contained within the Link
of all of
IOW?
its members, IOW that the Links of all the nodes in the subnet
fully overlap. This meant we had to abandon the idea of using
multicast in ND for DAD and AR.
Maybe someone can explain that better than I did. I so please
be my guest. I really tried but I'm not convinced I did not
waste my time with the authors of the draft.
You did not waste your time, no more than I did.
Alex
All the best,
Pascal
-----Original Message----- From: Int-dir
<int-dir-bounces@xxxxxxxx> <mailto:int-dir-bounces@xxxxxxxx>
On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019
09:54 To: NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx>
<mailto:n.benamar@xxxxxxxxxxxxx>; Pascal Thubert (pthubert)
<pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx> Cc:
ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; its@xxxxxxxx
<mailto:its@xxxxxxxx>; int-dir@xxxxxxxx
<mailto:int-dir@xxxxxxxx>; draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>;
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>; Ole Troan
<otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx> Subject:
Re: [Int-dir] Intdir early review of
draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6'
- fe80::/10 vs fe80::/64
Hi Nabil,
On 11-Apr-19 03:40, NABIL BENAMAR wrote:
Do we still talk about broadcast in IPv6 ?
No, we talk about multicast. Pascal was using shorthand. But
if multicast fails with high probability, several aspects of
IPv6 will fail too, unless the LAN provides an NBMA
(non-broadcast multiple access) emulation of multicast, or
suitable alternatives to SLAAC, ND, NUD, and RA.
An earlier draft of this spec mentioned this problem:
The operation of the Neighbor Discovery protocol (ND)
over 802.11-OCB links is different than over 802.11
links. In OCB, the link layer does not ensure that all
associated members receive all messages, because there
is no association operation. Neighbor Discovery (ND)
is used over 802.11-OCB.
but it was inconsistent and was removed. If Ole is correct
below about real-life conditions, the *problem* was not
removed and the draft is not going to work in the real
world.
Brian
On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
<pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>
<mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>>
wrote:
Hello Ole:
Better remove, it is wrong anyway.
Because it is transitive, the description extends the
so-called subnet step
by step to a potentially large number of cars such that there
is no broadcast domain that covers them all. If there is no
broadcast domain and no multicast emulation like a BSS does,
how can we run ND? Yes, it works with 3 cars in a lab.
The description looks like it is confused with the MANET /
6LoWPAN
concept of link, whereby my link joins the collection of
nodes that my radio can reach.
All the best,
Pascal
-----Original Message----- From: Ole Troan
<otroan@xxxxxxxxxxxxx <mailto:otroan@xxxxxxxxxxxxx>
<mailto:otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx>>
Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>>
Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx
<mailto:pthubert@xxxxxxxxx>
<mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>>;
ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <mailto:ietf@xxxxxxxx>
<mailto:ietf@xxxxxxxx>;
its@xxxxxxxx <mailto:its@xxxxxxxx> <mailto:its@xxxxxxxx>
<mailto:its@xxxxxxxx>; int-dir@xxxxxxxx
<mailto:int-dir@xxxxxxxx> <mailto:int-
dir@xxxxxxxx <mailto:dir@xxxxxxxx>>;
draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>
<mailto:80211ocb.all@xxxxxxxx>
<mailto:80211ocb.all@xxxxxxxx>; Brian E
Carpenter <brian.e.carpenter@xxxxxxxxx
<mailto:brian.e.carpenter@xxxxxxxxx>
<mailto:brian.e.carpenter@xxxxxxxxx>
<mailto:brian.e.carpenter@xxxxxxxxx>>
Subject: Re: [Int-dir] Intdir early review of
draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming
IPv6' - fe80::/10 vs fe80::/64
You said: if OCB is still 48bit, and if there is
bridging OCB-Ethernet, then
no
reason to be different than rfc2464.
I said: OCB is still 48bit, but there is no bridging
OCB-Ethernet.
The conclusion is: there is reason to be different from
RFC 2464.
Why?
Now, you give a different conclusion.
Excuse me, I would like to clarify this please?
Clarify what? That a link-layer that looks an awfully lot
like Ethernet should not follow
the
64-bit boundary and the definition of the link-local
address mapping of rfc2464? Section 4.5.1 is already
clear on that.
I think the only thing we are asking you is to change the
following
paragraph:
OLD: A subnet is formed by the external 802.11-OCB
interfaces of vehicles that are in close range (not by
their in-vehicle interfaces). This subnet MUST use at
least the link-local prefix fe80::/10 and the interfaces
MUST be assigned IPv6 addresses of type link-local.
NEW: A subnet is formed by the external 802.11-OCB
interfaces of vehicles that are in close range (not by
their in-vehicle interfaces). A node MUST form a
link-local address on this link.
Not quite sure what value that paragraph adds in the
first place. You
could
probable remove it.
Cheers, Ole
Alex
Le 10/04/2019 à 12:28, Ole Troan a écrit :
Alexandre, Right, so it doesn’t sound like you have
any reason to be different
from
RFC2464.
Just reference or copy that text (section 5,
rfc2464). Ole
On 10 Apr 2019, at 11:22, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>> wrote:
Le 10/04/2019 à 11:04, Ole Troan a écrit :
"At least" does not mean "the value
should be at least 10" in
that
phrase.
Do you think we should say otherwise?
To me there is nothing in the actual text
to tell me that "at
least"
qualifies the "/10". I think you could
rephrase as "This subnet's prefix MUST lie
within the link-local prefix fe80::/10
..."
However, see Jinmei's messages about
conformance with RFC
4291.
I think there might be unexpected side
effects from using an address like
fe80:1::1. What if some code uses matching
with fe80::/64 to test if an address is
link-local? I agree that would be faulty
code, but you would be the first to
discover it.
Indeed. If you absoultely must cut and paste
text from 2464:
YEs, that is how we started. We cut and paste
from 2464.
5. Link-Local Addresses The IPv6 link-local
address [AARCH] for an Ethernet interface is
formed by appending the Interface Identifier,
as defined above,
to
the prefix FE80::/64. 10 bits 54
bits 64 bits
+----------+-----------------------+----------------------------+
