Re: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs

This is all very right, Carsten.

> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a
> no-brainer, if that foo has points where the 6LBR functionality is naturally
> centralized.

No brainer it is, but for Lorenzo's issues on state preservation or reconstruction upon router reboot.

> Not so easy for brownfield, i.e., in networks where classic ND is already used in
> some hosts and some routers.  “Efficient ND” (which was essentially RFC 6775
> for Ethernet and thus also traditional Wi-Fi) mostly didn’t take off at the time
> because we didn’t articulate a cohabitation (“transition”) strategy.  I’m sure
> we can do that if we put a little more focus on it, leading to another
> specification that describes how to run in mixed classic/efficient ND networks.

For I started that at 6lo and there is text in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coexistence is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at some point it is not a 6lo problem anymore and that work should really move somewhere else. 

Being non-maintenance, it seems too early for 6MAN. If so maybe we should form a short-lived WG to sort out the issues raised by Lorenzo,  yours (coexistence) and mine (limit use of broadcast / interface with a fabric mapping server and do unicast lookup when possible).

All the best,

Pascal

> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; 6lo@ietf.org; V6 Ops List
> <v6ops@ietf.org>; 6man <6man@ietf.org>
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs
> 
> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a
> no-brainer, if that foo has points where the 6LBR functionality is naturally
> centralized.
> 
> Not so easy for brownfield, i.e., in networks where classic ND is already used in
> some hosts and some routers.  “Efficient ND” (which was essentially RFC 6775
> for Ethernet and thus also traditional WiFi) mostly didn’t take off at the time
> because we didn’t articulate a cohabitation (“transition”) strategy.  I’m sure
> we can do that if we put a little more focus on it, leading to another
> specification that describes how to run in mixed classic/efficient ND networks.
> 
> Grüße, Carsten
> 
> 
> > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> >
> > Hello Brian:
> >
> > Yes, I'm willing to make the case.
> >
> > There are a number of reasons to enable a registration method on beyond
> 6lo networks:
> > - It is useful in wireless in general because it addresses non-transit
> > multipoint links (see
> > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless
> > /) and NBMA ML-subnets
> > - it is useful in particular in Wi-Fi because it reduces the need for broadcast
> quite dramatically.
> > - It is useful in a switched fabric to maintain an accurate state in
> > the overlay mapping server (see
> > https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/)
> > - It is useful in a situation of host mobility in general, (see the
> > discussion in
> > https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 )
> > - It is useful for routers with hardware assist forwarding to avoid
> > the punting dance and dropping of packets
> > - It provides SAVI properties with a workable Secure ND (see
> > https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/)
> > - It provides an abstract interface to the router to get routing
> > services (already used with RIFT, RPL, see
> > https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and
> > ND proxy, see
> > https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/)
> > - It solves a number of problems including Jen's, but also sleeping devices on
> non-6lo networks, remote DOS against router and ND cache, and more.
> >
> > All in all I see it as a much needed modernization of ND to cope with the
> evolutions of the network (IOT, Wi-Fi and overlays) and with the new needs
> and behaviors (instant connectivity, fast roaming).
> >
> > All the best,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson
> >> Sent: jeudi 4 juillet 2019 02:58
> >> To: 6lo@ietf.org; V6 Ops List <v6ops@ietf.org>; 6man <6man@ietf.org>
> >> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> >>
> >>
> >> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> >>>> I’m interested to have a parallel discussion on where RFC 8505 can
> >>>> not apply. In the products and use cases I’m aware of, it could,
> >>>> since we are actually faking it by snooping ND and DHCP to achieve
> >>>> similar but less accurate results.
> >>
> >>> So if you are advocating a generalisation of RFC8505 to non-6lo
> >>> LANs, that's certainly a discussion we could have, IMHO.
> >>
> >> I think that it could be applied in situations of servers, such as
> >> data centers where there are multiple tenants. (Many VM
> >> infrastructures have shared front-end networks)
> >>
> >> I think that temporary addressess are not a feature in some of those
> >> deployments that everyone wants, and thus having a registration
> >> system is a feature.
> >>
> >> This does not solve the smartphone on new WIFI issue, which is a
> >> different situation completely.
> >>
> >> --
> >> ]               Never tell me the odds!                 | ipv6 mesh networks [
> >> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> >> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> >