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

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

> The draft is needed for L2 proxy only (smartphone).

Says you, though you seem to speak it as an absolute truth which IMHO is incorrect at this stage of the document. 

I believe the draft has a lot more value than that. And the kube proxy is one example that I'd love to see detailed in the v6ops collink document. I still 100% agree with myself in that quote you're making.

>> 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.
> I have not understood this.

A "host" may get an address or a prefix from multiple sources, e.g., DHCP, IPAM, autoconf, manual. This is the host's problem, the router does not care.
The router may need to inject it in any of multiple protocols, e.g., ND proxy, EVPN (BGP), LISP, RIFT. Conversely, this is the router's problem and the host does not want to know.

So what you do not want (that would be a hell of a bad architecture in my book) is to tie directly the router with the DHCP server. Because that only solves one situation. You want an UNI that is agnostic to both the device provisioning system and the NNI. IPv6 ND has that sort of interface (with RS/RAs for now) and it makes sense to use and extend it.

What you do not want either is a non-standard solution whereby a proprietary interface binds the (say DHCP-PD) delegator with the router. Some network admins want at least 2 vendors in their networks that proprietary is antagonistic.

The current state of the art of IPv6 forces the vendors to do both of those "bad things", and that will hinder the deployment of the collink document. The good news is that we now have a WG doc (draft-ietf-6lo-prefix-registration) that aims at solving both issues. Since it is not 6MAN, I wish to raise interest and get contribution from this list too, sooner the better. 

All the best, 

Pascal


> -----Original Message-----
> From: Vasilenko Eduard <[e-mail]>
> Sent: Tuesday, August 1, 2023 12:54 PM
> To: Pascal Thubert (pthubert) <[e-mail]>; Brian E Carpenter
> <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: RE: Clarifications: Architectural comments on draft-ietf-6man-ipv6-
> over-wireless-
> 
> > > 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.
> IMHO: Not a good one. Unnecessary complexity.
> 
> > 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.
> The draft is needed for L2 proxy only (smartphone).
> L2 virtual switch is transparent - could not participate anyway.
> L3 virtual router could behave like a router, i.e. request DHCP-PD.
> Hence, K8S would have a value from it only if somebody would implement a
> special networking plugin for K8S that would play L2 proxy role.
> Initially, you insisted on expanding use cases:
> https://mailarchive.ietf.org/arch/msg/v6ops/1JjfSxRsO8-I-uE2U4kFqfk4YhI/
> 
> > 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.
> I have not understood this.
> 
> Eduard
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Tuesday, August 1, 2023 1:18 PM
> To: Vasilenko Eduard <[e-mail]>; Brian E Carpenter
> <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: RE: Clarifications: Architectural comments on draft-ietf-6man-ipv6-
> over-wireless-
> 
> 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-wirele
> > ss-
> > 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
> > > > ------------------------------------------------------------------
> > > > --