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

[Vasilenko Eduard <[e-mail]>]

Hi Pascal,
"Something here, different there, yet more different over there". IPv6 is suffering from complexity. Even more complexity would hurt.
Despite that "fractal approach" is something cool.

Your example below (find a local printer) was based on MLSN assumption. It was for ordinary building and WiFi environment.
Hence, I do not understand the comment "I have not proposed". You assumed that Campus would have MLSN.

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