Re: Interested in wireless ?

[Alexandre Petrescu <[e-mail]>]

Le 07/07/2020 à 17:20, Pascal Thubert (pthubert) a écrit :
> A very broad claim, and I do not see that at all from reading the 
> spec, Fred.
> 
> I read a virtual interface for global mobility. I read something 
> similar to VxLANs, where the AR would play the role of xTR and the 
> capability to have multiple tunnels (as RFC 6089 does) and one end 
> point mobile (LISP can do that too). I'm unclear if you encapsulate 
> the L2 packets like we typically do with VxLANs, or if there may be
> a local CareOf Address, seems the former but I did not get it all. I 
> see the same challenges of getting this deployed as for MIP, NEMO, 
> LISP, etc..., in particular with the reliance of a service in the 
> visited network. Having worked on those, I can understand the risk 
> and the frustration.
> 
> But do you really think that all wireless nodes need this / will 
> behave like that? Don't you think that some mobiles just want an 
> address in the visited network and connect to the Internet? E.g., 
> tell me (in a different thread, offline, whatever) what use a 
> wireless mesh network will have of OMNI, and how that could replace 
> WiND and RPL in deployed smartgrid networks?
> 
> I do not believe the 2 drafts are competition. ...ipv6-over-wireless 
> presents the problems doing IPv6 over a physical wireless link, OMNI 
> deals with overlays but does not address the physical access 
> challenges. ...ipv6-over-wireless is informational, OMNI aims at 
> defining a new standard. They actually could work very well together 
> if/when OMNI terminates the tunnels at L3 with a CoA.
> 
> Bottom line: I understand that you want to advertise OMNI, I do not 
> understand why you create confusion in this thread, starting with my 
> own.
> 
> Take care,
> 
> Pascal

Pascal,
allow me to write here.  To me, this is not confusing even though it
might involve some magic that still needs to be uncovered.

An OMNI interface, as I understand it, is fundamental to mobile nodes
and routers that want to maintain session continuity.  Some sessions
need that.

In a sense, wireless, as opposed to wired, frees one to become more
mobile.  As such, it makes sense to think that an OMNI interface is for
wireless.

Of course, one could have nodes that do not move and use wireless links.
  Or nodes that dont need an address that lasts longer than a few
milliseconds.  These nodes would not need OMNI, I think.  These nodes
would not move much, would use an address that might change and some of
their sessions might not be interrupted; it is because these sessions
simply dont need constant addresses: a click to browse the web is such
an an ephemeral interaction in terms of message exchanges that it is
sufficient to have an address that lasts just a few milliseconds.

That said, I still think there is need for clarification about how a
virtual interface OMNI redirects its traffic on a real interface, such
as to avoid the need for technologies such as route injection and Mobile
IP.  Does that use some statically configured table, or is there dynamic
behaviour in there, and would that scale.  There cant be magic in there,
and I might find that explanation in OMNI drafts.

Alex

> 
>> -----Original Message----- From: Templin (US), Fred L 
>> <[e-mail]> Sent: mardi 7 juillet 2020 16:03 To: 
>> Pascal Thubert (pthubert) <[e-mail]>; 6man Chairs <6man-
>>  [e-mail]> Cc: 6man WG <[e-mail]> Subject: RE: 
>> Interested in wireless ?
>> 
>> Pascal, when using the OMNI interface for wireless there is no
>> need for changes to ND and no need for multilink subnets:
>> 
>> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
>>
>>
>>
>> 
There is an adoption call in the queue for OMNI.
>> 
>> Thanks - Fred
>> 
>>> Dear chairs;
>>> 
>>> We have had a long thread on the adoption of
>> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless.
>>> I have seen only supporting comments, and even a path for a 
>>> proper RFC type
>> indicated by Brian below.
>>> But I have not seen the action on your part.
>>> 
>>> It would be nice to make the call for adoption now so we could 
>>> discuss the
>> result at one of the IETF virtual meetings.
>>> What do you think?
>>> 
>>> Pascal
>>> 
>>>> -----Original Message----- From: Brian E Carpenter 
>>>> <[e-mail]> Sent: lundi 1 juin 2020 01:21
>>>> To: Pascal Thubert (pthubert) <[e-mail]> Cc: 6man WG 
>>>> <[e-mail]> Subject: Re: Interested in wireless ?
>>>> 
>>>> Pascal,
>>>> 
>>>> There is a category of standards track documents foreseen in 
>>>> RFC2026 called "applicability statements", described at 
>>>> https://tools.ietf.org/html/rfc2026#section-3.2
>>>> 
>>>> I think that is perhaps where your draft could fit. A little 
>>>> bit stronger than Informational and little bit different than 
>>>> Best *Current*
>> Practice.
>>>> 
>>>> Regards Brian
>>>> 
>>>> On 01-Jun-20 04:40, Pascal Thubert (pthubert) wrote:
>>>>> Hello Brian
>>>>> 
>>>>> We may have to split the doc but for the most part I agree
>>>>> it is an
>>>> informational.
>>>>> 
>>>>> For now I suggest to just change the intended status 
>>>>> accordingly and aim at
>>>> BCP or something.
>>>>> 
>>>>> Let’s discuss in parallel the coexistence and if there’s a 
>>>>> need for an std track
>>>> somewhere. There’s at least the use of a 6LBR for address 
>>>> looking up in unicast.
>>>>> 
>>>>> Take care, Pascal
>>>>> 
>>>>>> Le 30 mai 2020 à 22:47, Brian E Carpenter 
>>>>>> <[e-mail]>
>>>> a écrit :
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I believe that this is an important topic that 6MAN should 
>>>>>> take up. The draft
>>>> is a good basis.
>>>>>> 
>>>>>> At the moment I find the draft a bit confusing in one way. 
>>>>>> It's aimed at
>>>> standards track, but it mainly doesn't read like a standard. 
>>>> There's a lot of discussion but not much specification. If I 
>>>> was a coder, I wouldn't really know where to start. For 
>>>> example, the end of the
>> Introduction says:
>>>>>> 
>>>>>> "This document discusses the applicability of IPv6 ND over
>>>>>>  wireless links, as compared with routing-based
>>>>>> alternatives such as prefix-per node and multi-link subnets
>>>>>> (MLSN), and with Wireless ND (WiND), that is similar to the
>>>>>> Wi-Fi association and reduces the need for Network-Layer 
>>>>>> multicast."
>>>>>> 
>>>>>> If it's a standard, IMHO it shouldn't do that. It should 
>>>>>> specify what WiND is,
>>>> with normative references as needed. Section 5 is the important
>>>> part. It's fine to have a descriptive section about why WiND is
>>>> needed, but that is almost better as an appendix. The main text
>>>> should be essentially the instructions for a kernel
>>>> programmer.
>>>>>> 
>>>>>> Regards Brian Carpenter
>>>>>> 
>>>>>>> On 30-May-20 23:46, Pascal Thubert (pthubert) wrote:
>>>>>>> Dear all
>>>>>>> 
>>>>>>> Since there’s so much energy on the list these days, 
>>>>>>> could we consider the adoption of 
>>>>>>> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireles
>>>>>>>
>>>>>>>
>>>>>>> 
s-05
>>>>>>> ?
>>>>>>> 
>>>>>>> I got only positive feedback, there’s no politics, there 
>>>>>>> no label, it’s all about
>>>> IPv6 models for wireless. This may appear useful in a world 
>>>> where the vast majority of devices are connected that way.
>>>>>>> 
>>>>>>> Keep safe,
>>>>>>> 
>>>>>>> Pascal
>>>>>>> 
>>>>>>> ----------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> 
---- IETF IPv6 working group mailing list [e-mail]
>>>>>>> Administrative Requests: 
>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>>>>>> ----------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> 
----
>>>>>>> 
>>>>>> 
>>> 
>>> --------------------------------------------------------------------
>>>
>>>
>>> 
IETF IPv6 working group mailing list
>>> [e-mail] Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>> --------------------------------------------------------------------
>
>>>
>>> 
--------------------------------------------------------------------
> IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>