Subject: RE: Interested in wireless ?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jul 2020 08:12:19 +0000

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 <[email-masked]>
> Sent: lundi 1 juin 2020 01:21
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: 6man WG <[email-masked]>
> 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 <[email-masked]>
> 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-wireless-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 [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 7 Jul 2020 10:10:50 +0100

I definitely support the adoption of this draft.

The content is needed and add more detailed information on ND and wireless.

On Tue, Jul 7, 2020, 09:13 Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Dear chairs;
>
> We have had a long thread on the adoption of
> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless.
> 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
>
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 7 Jul 2020 14:03:17 +0000

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jul 2020 15:20:50 +0000

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

> From: Templin (US), Fred L <[email-masked]>
> Sent: mardi 7 juillet 2020 16:03
> To: Pascal Thubert (pthubert) <[email-masked]>; 6man Chairs <6man-
> [email-masked]>
> 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:
> 
> > > There is a category of standards track documents foreseen in RFC2026
> > > called "applicability statements", described at
> > > 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
> > >
> > > somewhere. There’s at least the use of a 6LBR for address looking up
> > > in unicast.
> > > >
> > > > Take care,
> > > > Pascal
> > > >
> > > 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."
> > > >>
> > > 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
> > > >>
> > > 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 [email-masked]
> > > >>> Administrative

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 7 Jul 2020 15:52:52 +0000

Pascal, as a brief response getting a "Care-of" address in a visited network with
the possibility of causing a multi-link subnet  is something OMNI seeks to avoid.
OMNI is about "Bring-your-own-addresses", and OMNI does have a mesh
networking story - see Section 12.1.

Thanks - 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.
> 
> 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.
> 
> > > > >>> ----

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Jul 2020 10:43:20 +0200

Le 07/07/2020 à 17:20, Pascal Thubert (pthubert) a écrit :
> 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 
>> <[email-masked]> Sent: mardi 7 juillet 2020 16:03 To: 
>> Pascal Thubert (pthubert) <[email-masked]>; 6man Chairs <6man-
>>  [email-masked]> Cc: 6man WG <[email-masked]> 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:
>> 
>>> I have seen only supporting comments, and even a path for a 
>>> proper RFC type
>> indicated by Brian below.
>>>> -----Original Message----- From: Brian E Carpenter 
>>>> <[email-masked]> Sent: lundi 1 juin 2020 01:21
>>>> To: Pascal Thubert (pthubert) <[email-masked]> Cc: 6man WG 
>>>> <[email-masked]> Subject: Re: Interested in wireless ?
>>>> 
>>>> Pascal,
>>>> 
>>>> There is a category of standards track documents foreseen in 
>>>> RFC2026 called "applicability statements", described at 
>>>> 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
>>>> 
>>>> somewhere. There’s at least the use of a 6LBR for address 
>>>> looking up in unicast.
>>>>> 
>>>>> Take care, Pascal
>>>>> 
>>>> 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:
>>>>>> 
>>>>>>  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."
>>>>>> 
>>>>>> Regards Brian Carpenter
>>>>>>> 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
>>>> IPv6 models for wireless. This may appear useful in a world 
>>>> where the vast majority of devices are connected that way.
>>>>>>> 
>>>>>>> Keep safe,
>>>>>>> 
>>>>>>> Pascal
>>>>>>> 
>>>>>>> Administrative Requests: 
>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6 
----
>>> [email-masked] Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6