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

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

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