[IPv6] Clarifications: Architectural comments on draft-ietf-6man-ipv6-over-wireless-

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Eduard:

1) I agree with Brian
2) The way you put it, I read it that you are misinterpreting my intention and spreading news that do not help.

So, my real words are like:

- everything we have today still works and is still perfectly usable when this IPv6'o'NBMA architecture gets deployed. Some subnets use the traditional broadcast way, some will be the NBMA way only, and there will benefits for that, some will be hybrid with a proxy function (RFC 8929) that allows the registered (e.g., Wi-Fi or sleeping devices) to appear as normal devices in the broadcast world.

- when I propose to make this architecture available everywhere I'm *not* saying that people will have to deploy it. An unmanaged network will probably remain using SLAAC for a very, very long time. Or v4. Or 4-20mA if you've been around factories.

- Using the registration mechanism effectively creates an NBMA situation *always*, even if at L2 there's a single Ethernet hub (yes I do mean the good old hub here) that connects it all. Because the logical view in that case is that of a shared link with e.g., sleeping low power ethernet devices that connect over the ethernet to their serving router (acting as sleep proxy) using P2P IP Link abstractions. This is already a logical overlay. While at the same time, your good old PCs connect using the transit link (broadcast, 1-1 mapping Subnet/link) abstraction and use, e.g., SLAAC. In other words you can have a single L2 link (which a hub effectively is and opposed to a switch which is an emulation with learning bridges and so on), and multiple IP Links.

- you're also confused between links and subnets when you say " Yes, WiND (RFC 8505) is capable to move the boundary to longer than/64 "per link". An IP Link is a connection between nodes. RFC 8505 typically uses P2P Links. There is no concept of associating Links and prefixes, see fig 1 of https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-over-wireless-04#name-ip-links. 

- Prefixes are associated to IP Subnets, and IP Subnets can be attributed to nodes (see draft-ietf-6man-ra-pref64) is you want to. In that case the node can use draft-ietf-6lo-prefix-registration to tell the router. The *very* cool thing about it is the fractal approach in the way the responsibilities get split. I tried to explain that in https://datatracker.ietf.org/doc/html/draft-thubert-nina but how do they say, that was 15+ years ago and the world was not ready. 

- thanks to Brian's comments, the architecture has no concept of /64. This is why it is in fact aligned with Lorenzo and Jen's work. Say the Subnet prefix length is /48 and you delegate /64s and you get a version of it that I understand has Lorenzo's preference. Say the length is /64 and the "host" can autoconf longer than /96 and you get my preference. Who cares about preferences? We're giving a tool box to the admins. Their decision.     	

In any case: please be very careful when you place words in my mouth. At least word it like, "it is my understanding that Pascal is proposing". Because I do not recognize what you're expressing there.

All the best, 

Pascal

> -----Original Message-----
> From: Vasilenko Eduard <[e-mail]>
> Sent: Tuesday, August 1, 2023 12:48 AM
> To: Brian E Carpenter <[e-mail]>; Pascal Thubert
> (pthubert) <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: RE: [IPv6] Architectural comments on draft-ietf-6man-ipv6-over-
> wireless-
> 
> > It isn't proposed for *all* cases, is it?
> Pascal is proposing to extend it to all cases. At least to all wireless cases
> (including WiFi).
> Hence, my objections. I do not believe that "Multi-Link SubNet" should be
> implemented for every basic implementation.
> Ed/
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, August 1, 2023 5:50 AM
> To: Vasilenko Eduard <[e-mail]>; Pascal Thubert (pthubert)
> <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: Re: [IPv6] Architectural comments on draft-ietf-6man-ipv6-over-
> wireless-
> 
> On 01-Aug-23 03:00, Vasilenko Eduard wrote:
> > Hi Brian,
> > Yes, WiND (RFC 8505) is capable to move the boundary to longer than/64 "per
> link".	
> > But they use a routing protocol to stitch the subnet. In addition to a
> different protocol for address resolution.
> > Would many agree to such a solution for all cases? (routing inside a
> > subnet)
> 
> It isn't proposed for *all* cases, is it? If it works better than what we
> have today for some scenarios, that's enough. It perfectly fits the
> permissionless innovation model; as long as it looks like a "normal"
> subnet from the outside, it's fine.
> 
>        Brian
> 
> > Eduard
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E
> > Carpenter
> > Sent: Saturday, July 29, 2023 5:16 AM
> > To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>;
> > Pascal Thubert (pthubert) <pthubert=[e-mail]>
> > Cc: IETF IPv6 Mailing List <[e-mail]>
> > Subject: Re: [IPv6] Architectural comments on
> > draft-ietf-6man-ipv6-over-wireless-
> >
> > On 29-Jul-23 03:05, Vasilenko Eduard wrote:
> >> I am not against the registration. The more stateful router is needed
> anyway.
> >>
> >> But you did attempt below again to explain the necessity of MLSN (many
> links for one subnet).
> >> Michael has shown you very professionally (with deep technical details)
> that MLSN is redundant.
> >> It is not the first time when you fail to explain why MLSN is needed
> always.
> >
> > I hate to stir the hornets' nest, but isn't the answer the currently fixed
> /64 boundary?
> >
> > BCP198 applies. Some would argue that draft-bourbaki-6man-classless-ipv6
> applies.
> >
> >      Brian
> >
> >>
> >> IMHO: it is not possible to drag the whole WiND "as it is" for the ND
> replacement.
> >> MLSN should be detached as a minimum.
> >>
> >> Well, even after this would be a lot of resistance to the more stateful
> router, but it is a different story.
> >> IMHO: the router should be more stateful. I like WiND at the stage
> >> before the MLSN addition:
> >> https://datatracker.ietf.org/doc/html/draft-chakrabarti-nordmark-6man
> >> -efficient-nd-07
> >> Eduard
> >> -----Original Message-----
> >> From: Pascal Thubert (pthubert)
> >> [mailto:pthubert=[e-mail]]
> >> Sent: Friday, July 28, 2023 5:35 PM
> >> To: Vasilenko Eduard <[e-mail]>
> >> Cc: Michael Sweet <[e-mail]>; IETF IPv6 Mailing List
> >> <[e-mail]>
> >> Subject: Re: [IPv6] Architectural comments on
> >> draft-ietf-6man-ipv6-over-wireless-
> >>
> >>
> >>> Hi Pascal,
> >>> A good example to prove the need for MLSN (multi-link subnet) is IoT
> wireless mesh networks.
> >>> I told you already many times that MLSN should be optional, because not
> needed for the great majority of cases (including WiFi).
> >>> But you persist to make it mandatory for every installation, including
> ordinary households.
> >>
> >> I persist saying the opposite. Did it at the Mike yesterday and again In
> mail today. What can. I do to avoid that misunderstanding?
> >>
> >>
> >>> It would not fly. This is a big additional complexity for no reason.
> >>>
> >>> By the way, it is not related to the biggest ND problem: downstream
> multicast.
> >>> Please, solve these 2 problems (MLSN and multicast) separately.
> >>> Then would be the chance for Multicast resolution.
> >>
> >> Do you mean broadcasting lookups on WiFi?
> >>
> >>
> >>>
> >>> When you discuss multicast issues, please assume the ordinary subnet with
> just one L2 link (1:1 relationship).
> >>> The link is probably wireless for the multicast problem to be present.
> >>> A solution is needed for this topology.
> >>
> >> WFM. The principle is the same at L2 and L 3: if it is sure that the
> target iP address is not on the BSS then the AP can drop the NS.
> >>
> >> Trouble is, snooping BD will not give you that assurance. Registration of
> all wireless devices will.
> >>
> >> All the best
> >>
> >> Pascal
> >>
> >>
> >>> Eduard
> >>> -----Original Message-----
> >>> From: ipv6 [mailto:[e-mail]] On Behalf Of Pascal
> >>> Thubert (pthubert)
> >>> Sent: Friday, July 28, 2023 3:51 PM
> >>> To: Michael Sweet <msweet=[e-mail]>
> >>> Cc: IETF IPv6 Mailing List <[e-mail]>
> >>> Subject: Re: [IPv6] Architectural comments on
> >>> draft-ietf-6man-ipv6-over-wireless-
> >>>
> >>> Hello Michael
> >>>
> >>> Very true.
> >>>
> >>> I thought this illustrates the issue of physical vs logical domains. L2
> is tightly locked with physical. So are physical services like a printer.
> That made it a good image.
> >>>
> >>> Whereas L3 can and should be logical. Whatever the admin wants it to be.
> A domain where a packet from a given GUA is topologically correct and packets
> can be delivered back. There are large EVPN overlays around and they fit that
> model.
> >>>
> >>> Now my everyday printing is as you say; I send it to some logical queue
> and press the button on whatever printer I find. Happy to replace this image
> by another, suggestions welcome.
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Pascal
> >>>
> >>>> Le 28 juil. 2023 à 05:00, Michael Sweet
> <msweet=[e-mail]> a écrit :
> >>>>
> >>>> Pascal,
> >>>>
> >>>>>> On Jul 27, 2023, at 5:24 PM, Pascal Thubert (pthubert)
> <pthubert=[e-mail]> wrote:
> >>>>>
> >>>>> Hello Ted
> >>>>>
> >>>>> My message did not land as intended.
> >>>>> The intent is this:
> >>>>>
> >>>>> I have a large building or campus. I want to enter anywhere and obtain
> an address that I can use throughout the campus without renumbering when I go
> to the next building/ level/room.
> >>>>>
> >>>>> Otoh I want that bonjour always finds the nearest printer and that
> printer is in the same room as me or in a closeby room. Certainly not
> anywhere in the campus.
> >>>>
> >>>> OK, so "nearest printer" is a problem we solved for IPP over 10 years
> ago - almost all printers sold since 2010 support AirPrint, which means
> mDNS/DNS-SD + IPP, with DNS LOC records (RFC 1876) advertising their location
> as configured by the admin.  This information is (naturally) also available
> via IPP queries.  Clients can (though few do) show the closest printer to
> them with this information.  All of this happens far above the subnet you are
> on, however...
> >>>>
> >>>> Also, in many environments you don't actually talk directly to a printer
> at all.  So-called "Release Printing" solutions are popular in enterprise
> networks and give you a single point of entry for printing - submit your job
> to a central queue/service, go to any printer, and then release it for
> printing at that printer's console (by swiping your ID badge, or by entering
> a PIN, or whatever). This print service is available via a routable address,
> so again you don't care about the subnet.
> >>>>
> >>>> I don't think printing can be the poster child for this draft...
> >>>>
> >>>> ________________________
> >>>> Michael Sweet
> >>>>
> >>> --------------------------------------------------------------------
> >>> 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
> > --------------------------------------------------------------------