Re: [ipwave] Expertise on ND problems on OCB

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Charlie,

Keeping some centralized ND cache is a very minor semantic. I don’t think that is everything.

We need to identify what all scenarios to cover. From my point of view, I am interested in brining IPv6 to OCB, so the applications in the CV can connect to infra. I am not too excited about this Star Trek type use-cases, with 2 vehicles come in proximity and have a date to exchange some prefixes, and start some live video __. The goal here is to use the radio for non-priority traffic. 

> Moreover, it seems to me that unicast might be preferable to multicast in vehicular ND protocols

We have this covered in:  https://tools.ietf.org/html/rfc6085
But, I did not say till now this is the solution. It’s one of the many semantics useful in this context.


Sri


On 4/26/19, 10:31 AM, "Charlie Perkins" <[e-mail]> wrote:

    Hello Sri,
    
    Forget about RFC 8505.
    
    What about a solution resident on relatively fixed infrastructure that 
    performs proxy ND services for vehicles in the neighborhood?
    
    To me that sounds like an attractive sort of solution.  It could relieve 
    the vehicles of their requirement to carry out RFC 4861 on-link ND 
    protocol operations.   Moreover, it seems to me that unicast might be 
    preferable to multicast in vehicular ND protocols, because of the issues 
    outlined in previous emails and drafts.  Do you disagree?
    
    We shouldn't get stuck talking about low power when that issue isn't 
    germane to the discussion.
    
    Regards,
    Charlie P.
    
    PS. I hope it's O.K. if I trimmed the long list of respondents. Does 
    every message need to go to [e-mail] too??
    
    
    On 4/26/2019 9:31 AM, Sri Gundavelli (sgundave) wrote:
    > I am sure you are convinced, but myself and many others in the WG have a
    > hard time seeing  RFC 8505 applicability to vehicular environments.  There
    > may be elements from RFC 8505, and many other specs, may be leveraged, but
    > this characterization of RFC 8505 as the ND solution is not convincing to
    > me, or to most people in the group (IMO); specially for a spec designed in
    > 6lo for low-power devices, and with the problem statement documented in
    > RFC 4919 not identifying a single vehicular property. You may have to
    > start revising RFC 4919 to change the scope of 6lo work.
    >
    >
    > Sri
    >
    >
    >
    >
    > On 4/25/19, 12:42 PM, "its on behalf of Carsten Bormann"
    > <[e-mail] on behalf of [e-mail]> wrote:
    >
    >>>> 	€ RFC 8505 isn't just about low power.
    >>> The titles says that, so the authors said that and including the IETF
    >>> WG that published and examined it under such use cases
    >> Actually, it doesn¹t.
    >>
    >> The title is
    >>
    >> Registration Extensions for IPv6 over
    >> 6LoWPAN Neighbor Discovery
    >>
    >> because 6LoWPAN Neighbor Discovery was invented for 6LoWPAN before we
    >> started applying it to the entirety of 6Lo.
    >>
    >> The RFC editor guidelines caused this title to be expanded to:
    >>
    >> Registration Extensions for IPv6 over
    >> Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
    >>
    >> which is indeed the expansion of ³6LoWPAN², but does not help at all ‹ it
    >> just muddies the waters by polluting the title with terms that are no
    >> longer relevant to the document at hand.
    >>
    >> (I¹m not going to go into the other parts of the current discussion; I
    >> have no idea how something like OCB can be discussed without
    >> acknowledging the hidden terminal problem, a.k.a. non-transitive
    >> connectivity, so it seems to me I won't have much to contribute.)
    >>
    >> Grüße, Carsten
    >>
    >> _______________________________________________
    >> its mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/its
    >