Re: [ipwave] [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -subnet structure, multicast

[Brian E Carpenter <[e-mail]>]

On 12-Apr-19 20:42, Alexandre Petrescu wrote:
> 
> 
> Le 11/04/2019 à 22:49, Brian E Carpenter a écrit :
>> Hi,
>>
>> If there are multiple interfaces, it seems to me that you
>> automatically have the situation described by Pascal, in which
>> traditional Ethernet-like multicast ND, DAD and RA simply do not
>> work.
> 
> Brian,
> 
> IPv6 ND on multiple OCB interfaces of an IP-OBU Router works ok.  Each 
> interface has its own subnet, with its own ND, DAD and RA.  The router 
> forwards IP packets between these interfaces.  It has a routing table.

So you mean that every car is a router? Sure, that can work. But this
wasn't clear from Section 3 of the draft or the discussion here.
So do you plan to use RPL? And some method of dynamic prefix assignment?
I realise that these questions are out of scope for the present draft,
but they are important context that could be mentioned in Section 3.

   Brian

> 
> I do not understand what do you mean when you say that EThernet-like 
> multicast ND, DAD and RA simply do not work.
> 
>>> a standard that works even if there's a single OCB interface.
>>
>> That's the easy case.
> 
> I agree.
> 
> Alex
> 
>>
>> Regards Brian
>>
>> On 12-Apr-19 03:15, William Whyte wrote:
>>> Hi Alex -- there *can* be multiple OCB interfaces in one car, but
>>> should the standard be written assuming that there are multiple OCB
>>> interfaces? I would have thought that the goal would be to write a
>>> standard that works even if there's a single OCB interface.
>>>
>>> If we're relying on multiple OCB interfaces to make this work, how
>>> many of those interfaces per car are we relying on? We can't
>>> presumably be assuming a distinct interface for each remote car
>>> that the local car is communicating with. If we aren't assuming a
>>> distinct interface for each remote car, then doesn't the problem
>>> that Pascal identifies come up?
>>>
>>> (You also mention that the antenna at the front of car B
>>> communicates with the one at back of car A -- but what if A
>>> overtakes B? And to be clear, I'm not asking for a direct answer to
>>> that question, I'm saying that if there are assumptions about the
>>> physical topology that we're relying on, we need to make those
>>> assumptions very clear and make them clear up front)
>>>
>>> I'd be very concerned if we were writing a standard that didn't
>>> work if there was only one OCB interface in the car. Can you
>>> reassure me on that?
>>>
>>> Cheers,
>>>
>>> William
>>>
>>>
>>>
>>>
>>> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>> Pascal,
>>>
>>> Do you agree there can be multiple IP OCB interfaces in one car?
>>>
>>> Alex
>>>
>>> Le 11/04/2019 à 11:23, Alexandre Petrescu a écrit :
>>>> 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
>>>>>> <[e-mail]> <mailto:[e-mail]> 
>>>>>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019
>>>>>> 09:54 To: NABIL BENAMAR <[e-mail]>
>>>>>> <mailto:[e-mail]>; Pascal Thubert (pthubert) 
>>>>>> <[e-mail]> <mailto:[e-mail]> Cc:
>>>>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>>>>> <mailto:[e-mail]>; [e-mail]
>>>>>> <mailto:[e-mail]>; draft-ietf-ipwave-ipv6-over-
>>>>>> [e-mail] <mailto:[e-mail]>;
>>>>>> Alexandre Petrescu <[e-mail]>
>>>>>> <mailto:[e-mail]>; Ole Troan
>>>>>> <[e-mail]> <mailto:[e-mail]> 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)
>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>> 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
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>>>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu
>>>>>>>> <[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>>
>>>>>>>> Cc: Pascal Thubert (pthubert) <[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>;
>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>;
>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail]>; [e-mail]
>>>>>>>> <mailto:[e-mail]> <mailto:int-
>>>>>> [e-mail] <mailto:[e-mail]>>;
>>>>>> draft-ietf-ipwave-ipv6-over-
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail]>; Brian E
>>>>>> Carpenter <[e-mail]
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>>
>>>>>>>> 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
>>>>>>>> <[e-mail]
>>>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>> 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
>>>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
> |1111111010|         (zeros)       |    Interface Identifier    |
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
> I presume there is support for bridging 802.11p and
>>>>>>>>>>>>>> other 802.3
>>>>>> links?
>>>>>>>>>>>
>>>>>>>>>>> In the IP-OBUs that I know there is IP forwarding
>>>>>>>>>>> between 802.11-
>>>>>> OCB
>>>>>>>> (earlier 802.11p) and 802.3, not bridging.
>>>>>>>>>>>
>>>>>>>>>>> In some IP-OBU (Internet Protocol On-Board Unit)
>>>>>>>>>>> some non-OCB
>>>>>>>> interfaces are indeed bridged.  E.g. the Ethernet
>>>>>>>> interface is bridged to
>>>>>> the
>>>>>>>> WiFi interface; that helps with DHCP, tcpdump and others
>>>>>>>> to see one a
>>>>>> single -
>>>>>>>> bridged - interface.
>>>>>>>>>>>
>>>>>>>>>>> Bridging may be, but it is not a MUST.  There is no
>>>>>>>>>>> necessarily any
>>>>>> bridging
>>>>>>>> between the 802.11-OCB interface and other interface,
>>>>>>>> neither bridging between the multiple 802.11-OCB
>>>>>>>> interfaces that might be present in
>>>>>> the
>>>>>>>> same computer.
>>>>>>>>>>>
>>>>>>>>>>> Do you assume bridging of 802.11-OCB interface to
>>>>>>>>>>> Ethernet
>>>>>> interface is
>>>>>>>> always there?
>>>>>>>>>>>
>>>>>>>>>>> Note: I also heard many comments suggesting that
>>>>>>>>>>> EAL is akin to
>>>>>>>> 'bridging'.  I do not know whether you refer to that
>>>>>>>> perspective.  If yes,
>>>>>> we can
>>>>>>>> discuss it separately.
>>>>>>>>>>>
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>>>> And that the MAC address length of this link
>>>>>>>>>>>>>> type is also 48 bits?
>>>>>>>>>>>>>
>>>>>>>>>>>>> YEs, the length of MAC address on 802.11 mode
>>>>>>>>>>>>> OCB is also 48.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the two assumptions above hold, then I see
>>>>>>>>>>>>>> zero justification
>>>>>> for
>>>>>>>> pushing the 64 bit boundary in this draft.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me try  to understand the first
>>>>>>>>>>>>> assumption.
>>>>>>>>>>>> Ole
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Int-dir mailing list [e-mail]
>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>>>>
>>>>>>>>> _______________________________________________ Int-dir
>>>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ Int-dir
>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>> _______________________________________________ its mailing list 
>>> [e-mail] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>>>
>>> --
>>>
>>> ---
>>>
>>> I may have sent this email out of office hours. I never expect a
>>> response outside yours.
>>
>>
> .
>