Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

[Behcet Sarikaya <[e-mail]>]

Hello Pascal,

My apologies. You had answered my question (almost three weeks ago) in this
mail which was misplaced in my inbox in the sent mail, so I hadn't seen it.


On Wed, May 31, 2023 at 12:26 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello Behcet
>
>
>
> The filename of the draft is misleading. The title and content have
> evolved. The title is now “Architecture and Framework for IPv6 over
> Non-Broadcast Access”. The chairs decided to keep the filename to avoid
> misleading the readers about the draft continuity. Bottom line is that the
> doc is not about how we do IPv6 in all sorts of wireless media, but how we
> do IPv6 over NBMA, with application on wireless.
>
>
>
> You’ll note that the architecture therein is compatible with Wi-Fi BSS,
> Wi-Fi ESS, Wi-Fi mesh and BLE mesh. It is also compatible with various
> adhoc networking technologies.
>
>
>
> But, to your point, the applicability statement focusses on Wi-Fi. This is
> because there’s no writing elsewhere about it, and Ethernet and by
> extension Wi-Fi appears to fall into 6MAN to discuss. For BLE, RFC 7668
> already refers to RFC 6775. For BLE mesh, RFC 9159 already refers RFC 6775,
> RFC 8505, and RFC 8928. So we are already covered there. Note that I have
> no idea why you consider any of that as archaic; IMHO that’s actually the
> state of the art, and as Brian points out, the only archaic thing on the
> table is insisting on using SLAAC in line cards and media that departed so
> much from what that lead to the design of RFC 4862 3 decades ago, and
> really in the previous millennium.
>
>
>
> Finally LPWAN as defined at the IETF is too constrained to have any ND at
> all. So we expect that the address mappings are configured as part of the
> SCHC context. There’s nothing this architecture and framework can do to
> help there, it’s really a different scope and world.
>
>
>
> So what’s your suggestion? I could extend the applicability with content
> from the 2 paragraphs above. Would that make the document better?
>
>
>


Yes, that could be I think a good idea in an effort to keep the document
more complete in coverage.

PS. I hate gmail on Macbook Pro (Safari).

Behcet



> All the best,
>
>
>
> Pascal
>
>
>
>
>
> *From:* Behcet Sarikaya <[e-mail]>
> *Sent:* Tuesday, May 30, 2023 7:04 PM
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* IPv6 List <[e-mail]>
> *Subject:* Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless
>
>
>
>
>
>
>
> On Fri, May 26, 2023 at 11:23 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
> Can you please start a thread on that? I need to understand if you wish
> more IoT as problem statement, as architecture, or as applicability, since
> the draft has the 3 aspects. And more specific items than the below.
>
>
>
>
>
> I am sure you know LPWAN, my suggestion is to explain how IPv6 works in
> LPWAN. You talk about what 6LowPAN did, which is fine but it is long gone.
>
>
>
> Also Bluetooth Mesh needs to be mentioned. Bluetooth Mesh can span the
> whole building not just one floor, so IPv6 operation probably deserves a
> section?
>
>
>
> There is also FIDO or industrial IoT.
>
>
>
> So these three issues would make your draft more contemporary instead of a
> bit archaic.
>
>
>
>  My two cents.
>
>
>
> Behcet
>
> In the meantime I’ll publish what I have done since 0 as a base. This
> includes the acronym move, and a thin P2MP section that Eduard asked for.
>
>
>
> Cheers,
>
> Pascal
>
>
>
> *From:* Behcet Sarikaya <[e-mail]>
> *Sent:* Friday, May 26, 2023 5:39 PM
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* IPv6 List <[e-mail]>
> *Subject:* Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless
>
>
>
>
>
>
>
> On Fri, May 26, 2023 at 10:17 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
> I’m not ignoring it Behcet. In fact I made that change for the acronyms.
>
>
>
> Wait a minute, it is not only that.
>
> I also asked more IoT content.
>
> I think it would help to cover each major IoT technology as, for example,
> we did in our T2TRG draft separately and clearly.
>
>
>
> Behcet
>
>
>
> Regards,
>
>
>
> Pascal
>
>
>
> Le 26 mai 2023 à 17:09, Behcet Sarikaya <[e-mail]> a écrit :
>
> 
>
> Hi Bob,
>
>
>
> I made a review already, Pascal wants to ignore it, it is fine with me.
>
>
>
> Behcet
>
>
>
> On Thu, May 25, 2023 at 10:36 AM Bob Hinden <[e-mail]> wrote:
>
> Behcet,
>
>
>
> On May 25, 2023, at 7:58 AM, Behcet Sarikaya <[e-mail]>
> wrote:
>
>
>
> Hi all,
>
>
>
>
>
> On Wed, May 24, 2023 at 4:48 PM Michael McBride <
> [e-mail]> wrote:
>
> Looks good Pascal. Agree its ready to progress.
>
>
>
> [MCAST PROBLEMS] can be now be replaced with RFC 9119.
>
>
>
>
>
> And you may want to consider moving the acronyms up from page 13 to page 3.
>
>
>
> I had already suggested this long time back.
>
>
>
> Having said that I am surprised Pascal all of a sudden is asking WGLC.
>
>
>
> I read what he wrote as asking for reviews now in order to get to a w.g.
> last call later.
>
>
>
> Reviews would be good.
>
>
>
> Bob
>
>
>
>
>
>
>
> I said give me a break to myself 😀.
>
>
>
> Behcet
>
>
>
> Question on your Bonjour reference. Bonjour uses mDNS. Is that what you
> are referring to with “Excessive use of broadcast by protocols such as
> ND-Classic and Bonjour led network administrators to install multicast rate
> limiting to protect the network.”? We didn’t get into Bonjour in 9119 but
> we did get into mDNS a bit, ie, when many devices are using it. Just want
> to make sure we are saying that same thing.
>
>
>
> Thanks,
>
> mike
>
>
>
> *From:* ipv6 <[e-mail]> *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* Tuesday, May 23, 2023 11:52 PM
> *To:* IPv6 WG ([e-mail]) <[e-mail]>
> *Subject:* [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless
>
>
>
> Dear WG:
>
>
>
> We adopted that draft to publish it as informational; it is at the same
> time a state of the art, a problem statement, and an applicability
> statement.
>
>
>
> The issues are clear and present, see also
> draft-ietf-v6ops-nd-considerations. We face customer situations where
> clients are not properly served because ND snooping fails to locate them
> all with a painful regularity. This impacts all sorts of situations, from
> wireless to fabrics / EVPN.
>
>
>
> Note that This is indeed very related to the SLAAC operation and IPv4 is
> mostly immune. Meaning that the IPv6 experience is of more broadcasts and
> less reliability.
>
>
>
> In order to progress in solving the issues raised, it makes sense to
> publish soon and move on. The draft has been progressing as an individual
> submission for a long time and it is mostly complete, IMHO. So my intent is
> to ask for WGLC sooner than later. To get there, reviews would be highly
> appreciated.
>
>
>
> Many thanks in advance : )
>
>
>
> 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
> --------------------------------------------------------------------
>
>