Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Sep 2017 15:59:36 +0200

Sri,

Thanks for the review.

Le 27/08/2017 à 16:44, Sri Gundavelli (sgundave) a écrit :
[...]

> 1.) Its not clear, if the document makes any assumption on the
> operating environment/communication profile. There is not much
> discussion on that aspect; For example, Is it always a one-hop
> communication between RSU and OBU where the 802.11-OCB link?  So, is
> the use of IPv6 only in that context of 1-hop communication?

The question is very relevant, but not place in this document to go to
much extent about it in an IP-over-foo document.

To answer now: is that 1 OCB hop is right at this time.

> 2.) There is also no discussion on how these links get formed in 
> vehicular environment and when they are attached/detached.

As above.

> 3.) How do nodes discover each other?  How does ND resolution work?
> Are these messages received by a multiple RSU’s, or a single RSU?
> Whats the implication of that. Note that you don’t have that issue in
> 802.11, given the association to an access point, which in turn maps
> the links to a VLAN/subnet.

I think ND may answer to some of the questions.
> 
> 4.) What happens as a vehicle moves between RSU’s, how does it impact
>  address configuration?

Mobile IP, but not in this document.

> Is DHCPv6 based address configuration relevant here?

YEs, but not to describe the detail use of DHCPv6-over-foo on IP-over-foo.

If you want to just refer to DHCP, that would be at which place in this 
document?

[...]
> We briefly introduce the vehicular communication scenarios where
> IEEE 802.11-OCB links are used.
> 
> 
> [Sri] I have not seen much discussion on the link / communication 
> assumptions.

That's why it says 'briefly'.

[...]

> The IEEE 802.11 OCB Networks are used for vehicular communications, 
> as 'Wireless Access in Vehicular Environments'.  The IP
> communication scenarios for these environments have been described in
> several documents, among which we refer the reader to one recently
> updated [I-D.petrescu-its-scenarios-reqs 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.petrescu-its-scenarios-reqs>],
> about scenarios and requirements for IP in Intelligent Transportation
> Systems.
> 
> 
> [Sri] You can do bit more justice to this section.
> 
> Explain the link model. “STA ----802.11-OCB——STA”. Then talk about
> the applicability in Vehicular networks, with STA's as RSU and OCB.
> 
> You may also want to talk about, how links get formed/terminated; how
>  nodes peer/discover and how mobility works ..etc. While 802.11-OCB
> is clearly specified and the use of IPv6 over such link is also not 
> radically new, but the operating environment which is vehicular
> brings many new things. That description is not present any where.

I mentioned it but the details are out of scope for an IPv6 over foo
document.

[...]

> [Sri] I am really not sure how link throughput (12Mbps) relates to
> "IPv6 support on OCB links".

802.11-OCB max 12mbit/s means one _can_ run a wide range of applications
on it.  Other links are so small and rare that you can not run IPv6 on
them, must change IPv6. (LORA, 15.4, etc).

> o  Operation Outside the Context of a BSS (OCB): the (earlier 
> 802.11p) 802.11-OCB links are operated without a Basic Service Set 
> (BSS).  This means that the frames IEEE 802.11 Beacon, Association 
> Request/Response, Authentication Request/Response, and similar, are
> not used.  The used identifier of BSS (BSSID) has a hexadecimal value
> always 0xffffffffffff (48 '1' bits, represented as MAC address
> ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to
> an arbitrary BSSID value set by administrator (e.g.
> 'My-Home-AccessPoint').  The OCB operation - namely the lack of
> beacon-based scanning and lack of authentication - has a potentially
> strong impact on the use of the Mobile IPv6 protocol [RFC6275
> <https://tools.ietf.org/html/rfc6275>] and on the protocols for IP
> layer security [RFC4301 <https://tools.ietf.org/html/rfc4301>].
> 
> 
> [Sri] The document till now has been arguing heavily on how IPv6 
> operates so naturally on these links and now I see discussion on
> “Impact to a high-level protocol such as MIPv6”. You may want to fix
> the earlier text.
I removed 'impact' word.   But also, the way MIP adapts to OCB is
outside the scope of this document.

> In any case, the absence of link-layer security practically impacts
> every application, not just MIPv6. Also, MIPv6 does not make any 
> assumptions on the link-layer security. Also, the the 
> 0xFF-FF-FF-FF-FF-FF as the BSSID, makes the messages readable by all
>  other RSU’s in proximity. I think the discussion on the nature of
> the link, who all see’s the messages.. how L2 addresses are resolved
> is not explained clearly.

I added some text about ND and some in the security section about how
this is open.

[...]

> Other aspects particular to 802.11-OCB which are also particular to 
> 802.11 (e.g. the 'hidden node' operation) may have an influence on 
> the use of transmission of IPv6 packets on 802.11-OCB networks.*The
> subnet structure which may be assumed in 802.11-OCB networks is 
> strongly influenced by the mobility of vehicles.*
> 
> 
> [Sri] Per my earlier comment, the link model, addressing ..etc needs
> to be explained in more detail. It is not clear what exactly the
> “subnet structure” that is assumed in 802.11-OCB.

Improved the subnet structure section.

[...]>     The Equivalent Transmit Time on Channel is a concept that may
be used
> as an alternative to the MTU concept.  A rate of transmission may be 
> specified as well.  The ETTC, rate and MTU may be in direct 
> relationship.
> 
> [Sri] The last paragraph needs some additional context. Did
> 802.11-OCB introduce ETTC concept?

We heard this term at mic in Berlin BoF.  Sounded like a more universal
term.  Should we remove it?

[...]
> The mapping between qos-related fields in the IPv6 header (e.g. 
> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data 
> Header" (e.g.  "QoS Control") are not specified in this document. 
> Guidance for a potential mapping is provided in 
> [I-D.ietf-tsvwg-ieee-802-11 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref-I-D.ietf-tsvwg-ieee-802-11>],
> although it is not specific to OCB mode.
> 
> 
> 
> [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs
>  further investigation, IMO.

YEs, it is out of scope in this document.

> 5.3 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.3>.
>
> 
Link-Local Addresses
> 
> 
> 
> The link-local address of an 802.11-OCB interface is formed in the 
> same manner as on an Ethernet interface.  This manner is described
> in section 5 of [RFC2464]
> <https://tools.ietf.org/html/rfc2464#section-5>.
> 
> 
> 
> [Sri] Does this go against the 8064 recommendation on Interface 
> identifier generation?

YEs.

> May be RFC7217 for interface identifier generation in conjunction
> with the link-local address generation per RFC2464

YEs.  But I think it's up to rfc2464-bis to say that, and this
IPv6-over-OCB to just refer to rfc2464-bis.

[...]
> For unicast as for multicast, there is no change from the unicast
> and multicast address mapping format of Ethernet interfaces, as
> defined by sections6 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-6>
> and7 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-7>
> of [RFC2464 <https://tools.ietf.org/html/rfc2464>].
> 
> 
> 
> [Sri] RFC6085 specified mapping is also relevant; If the
> communication peers are aware that there is only one peer, it should
> apply 6085 specified mapping. That mode is relevant for 802.11-OCB
> types links as well.

Same here, would be great to get 6085 into 2464-bis, at which point this
ip-over-ocb inherits from 2464-bis.

I added a reference to 2464-bis.

> 5.4.1 
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-5.4.1>.
>
> 
Address Mapping -- Unicast
> 
> 
> 
> The procedure for mapping IPv6 unicast addresses into Ethernet link- 
> layer addresses is described in [RFC4861
> <https://tools.ietf.org/html/rfc4861>].  The Source/Target Link- 
> layer Address option has the following form when the link-layer is 
> Ethernet.
> 
> [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet 
> link-layer addresses is specified in section 6, of RFC2464 and not in
>  RFC4861.

Either we have a brief paragraph that just refers to 2464 section 6, or
copy paste that section from 2464 and update its [DISC] reference to
4861.  That I did, in order to have the text a bit longer.

At this time I keep it that way, unless someone opposes.

A key question here is how is 2464bis advancing, and how we coordinate
with it.
[...]
> An IPv6 packet with a multicast destination address DST, consisting 
> of the sixteen octets DST[1] through DST[16], is transmitted to the 
> IEEE 802.11-OCB MAC multicast address whose first two octets are the 
> value 0x3333 and whose last four octets are the last four octets of 
> DST.
> 
> [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085.
> In general, for both unicast and multicast, you may want to clearly
> say that this is per the existing specs and duplicated here for
> convenience.

Should _this_ document do it, or should the 2464bis do it?  At this time
I keep it that way.
[...]

> The Interface Identifier for an 802.11-OCB interface is formed using 
> the same rules as the Interface Identifier for an Ethernet
> interface; this is described insection 4 of [RFC2464]
> <https://tools.ietf.org/html/rfc2464#section-4>.  No changes are
> needed, but some care must be taken when considering the use of the
> SLAAC procedure.
> 
> 
> 
> [Sri] Per my earlier comment, please refer to the current
> recommendation on interface-identifier generation and its use in
> link-local, global or other addresses.

Per my comments above - what do you think about 2464bis doing your
recommendations, rather than this one.

Depending on that, we can see further with this document.

[...]

> The 802.11 networks in OCB mode may be considered as 'ad-hoc' 
> networks.  The addressing model for such networks is described in 
> [RFC5889 <https://tools.ietf.org/html/rfc5889>].o
> 
> 
> [Sri] Per my earlier comment, there is no system level view of the 
> network where 802.11-OCB links are used. So, in the absence of such 
> discussion So, I am not sure what part of RFC5889 is applicable here.
> 
That's the only RFC the IETF has about the subnet structure in 'ad-hoc'
networks, and the 'ad-hoc' is what OCB is like.

> For example, link-local addresses may just work fine.

Yes, added.

[...]

> Overall, the captured message is identical with a capture of an IPv6 
> packet emitted on a 802.11b interface.  The contents are precisely 
> similar.
> 
> 
> [Sri] I suggest moving this discussion under the section
> “Implementation Status”,

Agreed.

> which will eventually be removed from the RFC.

But at the same time it depicts this topology of
Router-connected-to-Host, using 802.11-OCB.  This is something that you
requested earlier with STA1----STA2 with OCB in the middle.

So I suggest to keep this section in Appendix.

> There is nothing new here. This are details on experimentation. But,
> if you think there is some useful information such as discussion on
> Capture mode ..etc, you may want to move this entire section to
> Appendix. Implementors may use these tools for verification.

Yes.

[...] >
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#section-8>.
> IANA Considerations
> 
> 
> 
> [Sri] I though there was one IANA request on some multicast related?

added

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Sep 2017 03:58:32 +0000

Hi Alex,

Thanks for posting the new version addressing some of my comments. My main
issue is still about the nature of the link based on 802.11-OCB and the
big change that this operating environment (Vehicular) brings to the
table. We can certainly insist that the scope of this work is about
IPv6-over-foo and so any discussions around address configuration modes,
ND, link models, link prefixes ..etc is out of scope. But, note that the
IEEE definition of WAVE, 802.11-OCB, or the DSRC spectrum band is strictly
for vehicular environments and so I tend to this document has to make sure
we explain how one can make IPv6 and the dependent protocols work on
802.11-OCB based links.  We cannot ignore the operating environment.

For a node to send an IPv6 packet, it surely needs to be able to do the
L2/L3 mapping to the respective access technology and transmit the packet.
But, it also needs to generate an IPv6 address (link-local / global),
perform DAD on the link, perform ND resolutions for the destination
address, do the route lookups and send the packet out. So, what is not
clear to me from reading the spec is how all of that works on 802.11-OCB.

1.) Lets take a high-way scenario where 3 vehicles (A, B, C) come in close
proximity and can communicate among themselves.

At T=0, 
C-—A-—B

At T=1, one of the vehicle moves on (with signal level < 33 dbm) from the
previous neighbors. But there is a new node D in the vicinity. Also, node
C is now in another group ( C, E and F)
D-—A—-B

C-—E-—F

From the classic link sense, the node configurations have changed.

2.) How do the nodes communicate among themselves in the base scenario. Do
they use link-local or global address? How do they generate the addresses?

3.) If its global, how do they discover the on-link prefix?

3.) If its link-local (or global) How does DAD work in the above scenario?
With the link topology changing so dynamically, how can ND work here?

4.) Will the nodes support all standard multicast groups. For example,
will they participate in ALL_NODES_MULTICAST GROUP (FF02::1). IF yes, why
is the spec defining a new group for OCB nodes? Why is that needed?

Please see inline for other comments

On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" <[email-masked]>
wrote:

>
>
>On 9/10/17, 6:59 AM, "Alexandre Petrescu" <[email-masked]>
>wrote:
>
>>Sri,
>>
>>Thanks for the review.
>>

I would have agreed with the “IP-over-foo” analogy and stay away from
answering many question, but lets look at the WAVE, 802-11-OCB and DSRC
definitions. It clearly for vehicular environments. That the baseline
assumption. So, when we say IPv6 for 802-11-OCB, the operating environment
cannot be ignored.

>>> Are these messages received by a multiple RSU¹s, or a single RSU?
>>> Whats the implication of that. Note that you don¹t have that issue in
>>> 4.) What happens as a vehicle moves between RSU¹s, how does it impact
>>>  address configuration?
>>

Sure, but this is a special type of link and so its not clear how this
works.

DHCP server can be outside the link; in the current spec, its not clear
how the node even discovers the on-link prefix, or the default router.

>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref
>>>-
>>>I-D.petrescu-its-scenarios-reqs>],
>>> Explain the link model. ³STA ----802.11-OCB‹‹STA². Then talk about

Per my comments in the beginning ...

>>> ³Impact to a high-level protocol such as MIPv6². You may want to fix
>>> the earlier text.
>>>  other RSU¹s in proximity. I think the discussion on the nature of
>>> the link, who all see¹s the messages.. how L2 addresses are resolved
>>> ³subnet structure² that is assumed in 802.11-OCB.
>>

May require few more details

>>term.  Should we remove it?

I understand the relation between MTU and the ETTC. But, if we talk about
it, we have to explain which parameter drives the other. How do you
exactly set the MTU based on the ETTC rate. More details on needed.

>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref
>>>-
>>>I-D.ietf-tsvwg-ieee-802-11>],
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-5.3>.
>>>
>>> 
>>Link-Local Addresses
>>> 
>>> 
>>> 

We should state that.

>>IPv6-over-OCB to just refer to rfc2464-bis.

As with any bis document, its not going merge newer specs into it. We
still need to refer to the other documents, IMO.

>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-6>
>>> and7 
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-7>

I do not think 2464-bis will add new references. Its up to you, but 6085
may be relevant here.

>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-5.4.1>.
>>>
>>> 

May be I am missing some thing. The mapping is defined in 2464 and so the
4861 reference may be incorrect.

>>Should _this_ document do it, or should the 2464bis do it?  At this time

I am not tracking the bis and so not sure if it will include all these
documents. Any ways …your call

>>> ³Implementation Status²,
>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect
>>i
>>on-8>.
>>> IANA Considerations
>>> 
>>> 
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Sep 2017 21:50:43 +0200

> 802.11-OCB based links.  We cannot ignore the operating environment.

I agree, and in that operating environment there are many possible 
use-cases.  Some of them may have more problems than others, in making 
ND work.

> proximity and can communicate among themselves.

In this case, we need a mechanism in ND such that A routes packets from 
C to B, and vice-versa.  The 'A' is a car with two OCB interfaces: one 
to C and one to B.  It uses a different channel on each of these 
interfaces, and runs IP on each.

Such mechanism is like in the drafts of routing advertisement between 
moving networks, or like in the INPD protocol.

Do you think there can be another?

> C is now in another group ( C, E and F)

There will be multiple ND exchanges here to make it work.  But I would 
like to ask you which is the particular use-case?  Is this something 
planned, or something we are afraid it may arrive?

> With the link topology changing so dynamically, how can ND work here?

We can answer these questions.  We can unfold the ND messaging and the 
SLAAC (if necessary), provided you think that use-case is important.

Do you think we need to describe that use-case D-A-B/C-E-F as an example 
and then tell how ND would work?

Would you be interested in participating in that description?

> is the spec defining a new group for OCB nodes? Why is that needed?

That's a good question.

It is good to have a separated group ID for OCB because it will help 
distinguish between all-nodes adresses on WiFi.

Since the OCB nodes are special (they are not WiFi nodes) it makes sense 
to have special OCB IP multicast groups.

Just like it's useful to have a distinguishing EtherType to distinguish 
between WAVE messages and IPv6 being carried in 802.11.

[...]

> how the node even discovers the on-link prefix, or the default router.

Because in IP-over-foo we dont talk about topologies like star topology, 
or shared topology, or point-to-point topology.

In a separate document (I invite you to get involved) we can describe a 
topology of RSU and many cars around it.  There we can talk how cars 
discover the RSU.  And we can talk about topology of intelligent 
junction where cars see each other through an RSU mirror at angles where 
drivers cant see.  And there again we can talk how cars form addresses, 
discover each other, etc.
[...]

> exactly set the MTU based on the ETTC rate. More details on needed.

Maybe we get rid of ETTC altogether?

Alex
(see separate for 2464bis)

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Sep 2017 22:04:26 +0200

> May require few more details

What kind of details would you see?  Would you like to propose?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Sep 2017 22:11:26 +0200

>>>> [Sri] Does this go against the 8064 recommendation on Interface

Can we tell 2464bis to state it?

> still need to refer to the other documents, IMO.

I think 2464bis should include 8064 recommendation, otherwise it's still 
obsolete.

> I do not think 2464-bis will add new references. Its up to you, but 6085

I think it must.

If I learn it will not, then I will add 7217 to IP-over-OCB.

Do you think it is a good way forward?

> 4861 reference may be incorrect.

2464 has an old reference to 2461 (instead of the new 4861).  So we want 
2464bis to add reference to 4861.  That would be the ideal.

(when 2464 talks about 'mapping' it means both a static mapping between 
addresses, _and_ a dynamic resolution like ND).

> documents. Any ways …your call

The 2464bis is in an individual submission stage.  It is not yet a WG item.

I do not know how the ADs see the situation of this IP-over-OCB document 
vs the advancement of 2464bis.

Do you think we should pursue IP-over-OCB separate from 2464bis?

I can also go that way, but I would like confirmation.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Sep 2017 20:21:39 +0000

Hi Alex,

> What kind of details would you see?  Would you like to propose?

Our starting point is still the link. Is there even possibility of
realizing a “link” in this environment. For hosting a prefix, you need a
link and when that link is based on dynamic grouping of random set of
802-11-OCB nodes, where the nodes are always changing groups, where is the
link. What defines a link?

There is node mobility even in other types of wired/wireless links, but
the presence of a router on the link made a link a stable link where the
prefix stay with the link. But, in WAVE, we don’t have that router and so
the question is what defines a link? Now, the second part is about the
prefixes?  If the hosted prefix is a link-local prefix FE80://, or a
global prefix? A node is always moving between links/subnets, without ever
noticing that it changed the link.

Unless we throw some light on the above, any discussion on subnet
structure is incomplete IMO. The below text does not seem to be addressing
these points.

Sri

-------------------------

5.6.  Subnet Structure

   A subnet is formed by the external 802.11-OCB interfaces of vehicles
   that are in close range (not their on-board interfaces).  This
   ephemeral subnet structure is strongly influenced by the mobility of
   vehicles: the 802.11 hidden node effects appear.  On another hand,
   the structure of the internal subnets in each car is relatively
   stable.

   For routing purposes, a prefix exchange mechanism could be needed
   between neighboring vehicles.

   [RFC5889].

   An addressing model involves several types of addresses, like
   Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique
   Local Addresses (ULA).  The subnet structure in 'ad-hoc' networks may
   have characteristics that lead to difficulty of using GUAs derived
   from a received prefix, but the LL addresses may be easier to use
   since the prefix is constant.

-----------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Sep 2017 08:06:33 +0200

Le 11/09/2017 à 22:21, Sri Gundavelli (sgundave) a écrit :
> realizing a “link” in this environment.

YEs, as pictured, two STAs next to each ohter have a link good enough
for IPv6 ND to work on it.

Move them a little bit further from each other and there is no more link.

I do not understand what do you mean by 'link'?

> For hosting a prefix, you need a link and when that link is based on
> dynamic grouping of random set of 802-11-OCB nodes, where the nodes
> are always changing groups, where is the link. What defines a link?

That's a good point, but do you think we can define a link in this document?

In OCB a 'link' is ephemeral: I see it created when a STA receives an NA 
as response to its NS.  Even then, after that reception we're not sure 
the link is still there.  Or it can.

TCP will make sure that data gets across.

In an RSU-to-OBUs communication there is a very stable link, as link as 
these OBUs stay within the limits of coverage of that OBU.

All this is also valid with WiFi links: ICB (_Inside_ the Context of a BSS).

> There is node mobility even in other types of wired/wireless links,
> but the presence of a router on the link made a link a stable link

I dont think it's the router's presence that makes that link stable(?) 
What makes a link stable is that nodes stay within radio range.

> where the prefix stay with the link. But, in WAVE, we don’t have that
> router and so the question is what defines a link? Now, the second
> part is about the prefixes?  If the hosted prefix is a link-local
> prefix FE80://, or a global prefix? A node is always moving between
> links/subnets, without ever noticing that it changed the link.

On another hand, I think a prefix is attached to an interface, not 
necessarily on a link.

> structure is incomplete IMO. The below text does not seem to be
> addressing these points.

Care to through some light with text you'd like to see in draft.

Or maybe we learn to just live with the question.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 Sep 2017 14:10:54 +0000

Hi Dick,

Yes. The IETF version, or more precisely the concept of a “link” that is
implicitly present in IPv6 ND and other protocols.

Regards
Sri
PS: It appears not all mails are showing up in the ITS archive, including
this one.

On 9/11/17, 6:22 PM, "Dick Roy" <[email-masked]> wrote:

>H all,
>
>The real issue you do have to face is the one outlined by Sri below, that
>being how to set up a local "link" with multiple mobile devices (e.g.
>OBUs)
>that are potentially in motion.  This is what I was trying to explain
>years
>ago when I stressed the need for an ND-equivalent in very rapidly varying
>network topologies.
>
>Note that while 1609 and friends have various definitions of "link", I
>believe the one Sri is referring to is the IETF version which is that of a
>collection of nodes (hosts and routers) that can communicate at layer 2
>and
>below.  
>
>That said, the IETF link concept can still be found in ITS communications.
>In ISO, the concept of an ITS-SU composed of many nodes (host and routers)
>is alive and well.  You will find pretty pictures of them in the annexes
>of
>ISO 21217!  You can imagine use cases where nodes on these local networks
>would like to communicate with similar nodes on other nearby networks
>(e.g.
>a back-seat host has a chat app and the kids want to video-chat with their
>friends in the cars in our caravan to summer camp!).  Here you have
>several
>static LANs (in the cars) that want to form a quasi-static (while we are
>all
>caravanning on the four hour trip to heaven (mom) / hell (dad):^) LAN (or
>possibly a VLAN assuming we also have wide-area connectivity such as a 4G
>interface or two), and the issues surrounding rapidly varying network
>topology are not present while the ND issues are still present.
>
>Perhaps such use cases are useful...
>
>Cheers,
>
>RR   
>
>
>-----Original Message-----
>From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Monday, September 11, 2017 1:22 PM
>To: Alexandre Petrescu
>Cc: [email-masked]
>Subject: Re: [ipwave] Review comments on
>draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section
>
>Hi Alex,
>
>_______________________________________________
>its mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/its
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 Sep 2017 14:17:38 +0000

Hi Alex,

Stepping away from the debates on the wordings or on semantics Š the issue
that I am raising is around ND. Before we can claim that IPv6 works on
802-11-OCB access, we need to make sure one can make ND work. That is the
larger discussion point. I do realize there is text on the experimentation
and packet captures of IPv6 packets on the 802.11-OCB medium, but I
suspect that was in a contained environment, where two RSU¹s with
802.11-OCB interfaces are sitting next to each other. I encourage
repeating the same test with multiple RSU nodes and in a vehicular
environment and see how the results compare. Its possible every thing
works great and I may be missing something, but that is worth verifying
it, IMO.

Regards
Sri

On 9/11/17, 11:06 PM, "Alexandre Petrescu" <[email-masked]>
wrote:

>> realizing a ³link² in this environment.
>
>> where the prefix stay with the link. But, in WAVE, we don¹t have that

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Sep 2017 17:59:55 +0200

Le 12/09/2017 à 16:17, Sri Gundavelli (sgundave) a écrit :
> Hi Alex,
> 
> Stepping away from the debates on the wordings or on semantics Š the
>  issue that I am raising is around ND. Before we can claim that IPv6
>  works on 802-11-OCB access, we need to make sure one can make ND 
> work. That is the larger discussion point.

Agree, but can we go with the IP-over-OCB as it stands now or should we
add/modify something in it?

> I do realize there is text on the experimentation and packet captures
> of IPv6 packets on the 802.11-OCB medium, but I suspect that was in a
> contained environment, where two RSU¹s with 802.11-OCB interfaces are
> sitting next to each other.

It's not only packet captures and contained environments - we used IPv6,
ND, and Mobile IPv6 on cars connecting to Road-Side Unit deployed at a
particular parking and road that I could point.

The issue was how OBU could measure the signal level of an RSU on OCB
(to decide to hand over to it from 4G), because OCB has no Beacons.  So
we used Router Advertisements instead.  And in the IP-over-OCB draft we
do talk about what could be the handover indicators: RA, TSA, WRA.
  For Mobile IPv4 we used IPv4 Router Advertisements on OCB links - they
work.

We also performed a 'see-through' video-streaming on IPv6 on OCB
between two vehicles following each other on road.   The issue was how
the IPv6 Ethernet camera from one vehicle could send UDPv6 packets to
the Ethernet laptop inside the other car, through two IPv6 OBUs on OCB,
w/o RSU.  TO address that, we developped this prefix exchange mechanism
with ND extensions on IPv6 over OCB.  It worked fine.  The issue was not
the link, because the link is stable between two cars following each other.

Others than what I claim, others used IP on OCB at other trials, on road
(not on table).

The distances are in the ranges of 10s of meters, 100s of meters.
Measures were peformed.

> I encourage repeating the same test with multiple RSU nodes and in a
>  vehicular environment and see how the results compare.

YEs, thanks for encouragement.  We and others have plans for that too.

The issues that arise have to do with placement with RSUs, setting power
levels, and deciding channel numbers.

> Its possible every thing works great and I may be missing something, 
> but that is worth verifying it, IMO.

Certainly yes worth verifying.

What ND do you think will not work when two cars follow each other and
stream one another's video?

What ND do you think will not work when one car is handed over between
rightly placed RSUs?

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 Sep 2017 16:22:36 +0000

It is your call and up to the chairs. I am not in the blocking path. But,
I do not believe IESG will approve this in the current form.

Regards
Sri

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Sep 2017 09:27:16 -0700

> On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 

I think you overestimate the IESG. They will pretty much approve anything that is reasonably clean and has WG consensus.

They do not spend a lot of time worrying about wording details, especially on concepts that are well grounded already.

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 Sep 2017 16:32:46 +0000

> They will pretty much approve anything that is reasonably clean and has WG consensus.

Ok! You can give it a try.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of Tony Li <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 12, 2017 at 9:27 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt - subnet structure section

On Sep 12, 2017, at 9:22 AM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Sep 2017 19:03:10 +0200

Sri,

Dick's emails dont appear in archive.

Yours do.

The issue with emails from Dick have to do about masquerading somewhere, 
and security.

IETF ticketing tried looked at it a few months back.  There is still 
internal debate about whose fault is it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Sep 2017 19:21:31 +0200

> [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085. In 
> general, for both unicast and multicast, you may want to clearly say 
> that this is per the existing specs and duplicated here for convenience.

RFC6085 tells there are some circumstances where a mcast IP address maps
into a link-layer unicast address (instead of multicast link-layer address).

Was that test on wired Ethernet 802.3 or on WiFi 802.11?

Does that apply to 802.11-OCB.

Depending on that I can add a reference to 6085.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 13 Sep 2017 00:33:30 +0000

Hi Alex,

>Depending on that I can add a reference to 6085.

This will be relevant in the V2I context where there is a router sending
IPv6 RA¹s. But, we have not had any discussions on that entire topic and
so many things are not clear for me. So, I am OK to leave the reference
out for now.

Sri