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

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

Hello Eduard

> Hi Pascal,
> "Something here, different there, yet more different over there". IPv6 is
> suffering from complexity. Even more complexity would hurt.

I heard that times and again. It is probably true that complexity and lack of backward compatibility are impediments to IPv6 adoption in all but the larger enterprises.

My conclusion is as follows: if the goal for keeping the mappings of links and subnets to the IPv4 ways was to avoid complexity and simplify adoption, well, the target was missed by a mile or two.

Now, if we can show value to enterprises then who knows? 

The architecture provides value to enterprises that use NBMA networks with broadcast emulation. This includes, enterprises with large Wi-Fi and switched domains, enterprises with EVPN infras, and enterprises with other overlay routing technologies like LISP. The value is reliability. Issues like BUM, silent nodes and wasted state plague those deployments and IPv6 will only make that an order of magnitude worse.

In IoT and industrial, this architecture also enables to connect the traditional IPv4 / NAT design (a line of production is reproduced N times with the exact same IPv4 addressing and less than 100 addresses each), using a /96 delegated prefix at the edge + CLAT as opposed to NAT. This is one of the many reasons why I support Jen and Lorenzo's work. The same thing would work great for K8S (in kube proxies) too, and allow IPv6 flat cloud infras.

Note that the delegated prefix in the use cases above is not granted by DHCP. You do not want to tie DHCP and the routers too directly. Bad architecture.

> Despite that "fractal approach" is something cool.

When you're manipulating 128 bits of addresses, yes it must be. The value was demonstrated with CIDR and routing in the Internet, but there's probably more to be found.

> Your example below (find a local printer) was based on MLSN assumption. It
> was for ordinary building and WiFi environment.

Yes, that's an enterprise use case. The admin wants to tailor the broadcast domain to the services that he installs, e.g., for physical reasons like proximity to the user. And then he wants to tailor his IPv6 mobility domains (where you can move your addresses and prefixes without renumbering) to something larger, which is where an enterprise user moves during the day's work without getting connectivity hassles. 

Real world demands there. 

Think how good we are at renumbering and wonder how good the prefix delegation would be if I had to renumber the "tethered" thingies when I roam from one meeting room to another in a different level / building. 

There comes my suggestion to Lorenzo at 6MAN that the PIO with the new p bit is larger (and encompassing) the delegated prefix. If you're playing with /64 delegations, then make it a 48. This way, hosts will never be confused and autoconf from it. and then place another PIO with a /64 for autoconf.


> Hence, I do not understand the comment "I have not proposed". You assumed
> that Campus would have MLSN.

I'm not moving all networks to that model. It's an option, and there is interop.

All the best

Pascal


> 
> I do not object at all to more stateful router. I object only against MLSN
> that has a good use case only in IoT.
> 
> NBMA may be created just with stateful router and registration protocol. MLSN
> is not mandatory. Even over Ethernet hub.
> 
> When IoT network has /64 for the subnet and many P2P links inside. Then
> numbering for P2P links has longer mask. Right?
> 
> I did know that WiND does not have any limitations for the prefix (not just
> /64). It is a feature of stateful router and registration protocol, not MLSN.
> 
> Eduard
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Tuesday, August 1, 2023 11:35 AM
> To: Vasilenko Eduard <[e-mail]>; Brian E Carpenter
> <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: Clarifications: Architectural comments on draft-ietf-6man-ipv6-over-
> wireless-
> 
> 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-6m
> > >> an
> > >> -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
> > > --------------------------------------------------------------------