Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 May 2021 09:54:47 +1200

Hi,

IMHO this draft now includes some important new material, namely definitions of two terms "IP Link" and "IP Subnet" (at https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html#name-terminology ). While I'm not sure yet that I completely agree with the text, I think the topic is very important, since the previous doctrine has effectively been that all "links" behave like Ethernet. And, by the way, the socket API incorporates that doctrine.

(This is something that gave us quite a lot of angst in ANIMA, especially in clarifying the "link" model in the Autonomic Control Plane, since we depend on link-local multicast.)

Regards
   Brian

On 18-May-21 02:45, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 Neighbor Discovery on Wireless Networks
>         Author          : Pascal Thubert
> 	Filename        : draft-thubert-6man-ipv6-over-wireless-09.txt
> 	Pages           : 25
> 	Date            : 2021-05-17
> 
> Abstract:
>    This document describes how the original IPv6 Neighbor Discovery and
>    Wireless ND (WiND) can be applied on various abstractions of wireless
>    media.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wireless-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 18 May 2021 06:52:21 +0000

Hi all,
Sometimes, IPv6 Links are connected into
a "single entity" (except from Proxy-ND RFC 4389) or
a Multi-Link Subnet (from RFC 8929) or
something without a name in the draft-ietf-bess-evpn-proxy-arp-nd-13

And then IP Prefix is attached to this structure.
It is not good that the IP prefix is attached to the structure that does not have the name!

There are 2 options here:
1. call it the "IPv6 link" too. Probably not good, because ND messages are not transparent between L2 domains in all such solutions.
2. give it the name. draft-thubert-6man-ipv6-over-wireless-09 proposes to call it MLSN. Why not?

On the broad scope, the IP prefix is attached not to the link, but to the entity at the next layer of hierarchy. It should be somehow reflected in standards.

PS: This is the biggest thing that I see in draft-thubert-6man-ipv6-over-wireless-09
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, May 18, 2021 12:55 AM
To: 6man <[email-masked]>
Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

Hi,

Regards
   Brian

On 18-May-21 02:45, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 06:59:47 +0000

Many thanks Brian;

Though writing code and deploying networks is core to many of us, we also end up teaching, writing papers and publishing informational documents in other bodies such as ETSI. It was during a discussion for an ETSI doc that we realized we were missing those definitions. 

But above there's a need to regain a degree of freedom in how we use links and subnets. The lack of definitions leads to overloading and confusion, which in turn leads to confine us within the commonly understood model that is ethernet.

As we separate the definition of the IP link from that of the lower layer, and separate the definition of subnet from that of IPv4, we regain a degree of freedom that enables us to build IPv6 abstractions over any new medium and build subnets of any size and shape.

Happy to discuss the exact terms of the definitions.

Keep safe,

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: lundi 17 mai 2021 23:55
> To: 6man <[email-masked]>
> IMHO this draft now includes some important new material, namely
> definitions of two terms "IP Link" and "IP Subnet" (at
> https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-
> 09.html#name-terminology ). While I'm not sure yet that I completely
> agree with the text, I think the topic is very important, since the
> previous doctrine has effectively been that all "links" behave like
> Ethernet. And, by the way, the socket API incorporates that doctrine.
> 
> (This is something that gave us quite a lot of angst in ANIMA,
> especially in clarifying the "link" model in the Autonomic Control
> Plane, since we depend on link-local multicast.)
> 
> Regards
>    Brian
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 May 2021 17:05:57 +1000

On Tue, 18 May 2021, 07:55 Brian E Carpenter, <[email-masked]>
wrote:

> https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html#name-terminology
> ). While I'm not sure yet that I completely agree with the text, I think
> the topic is very important, since the previous doctrine has effectively
> been that all "links" behave like Ethernet. And, by the way, the socket API
> incorporates that doctrine.
>

RFC 3819, Advice for Internet Subnetwork Designers, also being BCP 89,
would seem to me to be the or close to the IETF's definition of a "link"
since it is providing advice on the design of them:

Abstract

   This document provides advice to the designers of digital
   communication equipment, link-layer protocols, and packet-switched
   local networks (collectively referred to as subnetworks), who wish to
   support the Internet protocols but may be unfamiliar with the
   Internet architecture and the implications of their design choices on
   the performance and efficiency of the Internet.

Regards,
Mark.

> (This is something that gave us quite a lot of angst in ANIMA, especially
> in clarifying the "link" model in the Autonomic Control Plane, since we
> depend on link-local multicast.)
>
> Regards
>    Brian
>
> submission

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 12:31:14 +0000

RFC 3819 is mostly not an overlap with what we’re trying to do here, Mark. But that’s a cool reference to keep in mind, thank you for this.

Pascal

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: mardi 18 mai 2021 9:06
To: Brian E Carpenter <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

On Tue, 18 May 2021, 07:55 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

RFC 3819, Advice for Internet Subnetwork Designers, also being BCP 89, would seem to me to be the or close to the IETF's definition of a "link" since it is providing advice on the design of them:

Abstract

Regards,
Mark.

Regards
   Brian

On 18-May-21 02:45, [email-masked]<mailto:[email-masked]> wrote:
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 May 2021 15:35:39 +0000

>RFC 3819 is mostly not an overlap with what we’re trying to do here, Mark.

See also RFC3366.

From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 18, 2021 5:31 AM
To: Mark Smith <[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

Pascal

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: mardi 18 mai 2021 9:06
To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

Abstract

Regards,
Mark.

Regards
   Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 18 May 2021 16:19:32 +0000

Hi all,
Current ND is not compatible with any Wireless, especially for low power or roaming scenarios. Hence, the proper discussion would be helpful.
Hence, I propose to adopt draft-thubert-6man-ipv6-over-wireless in 6man.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 18, 2021 10:00 AM
To: Brian E Carpenter <[email-masked]>; 6man <[email-masked]>
Subject: RE: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

Many thanks Brian;

Keep safe,

Pascal

> > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wirele
> > ss
> > /
> >
> > 09.html
> > https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wirel
> > es
> > s-09
> >
> >

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 May 2021 16:31:50 +0000

It is premature to propose adoption without first considering the alternative:

https://datatracker.ietf.org/doc/draft-templin-6man-aero/
https://datatracker.ietf.org/doc/draft-templin-6man-omni/

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Vasilenko Eduard
> Sent: Tuesday, May 18, 2021 9:20 AM
> To: 6man <[email-masked]>
> Though writing code and deploying networks is core to many of us, we also end up teaching, writing papers and publishing informational
> documents in other bodies such as ETSI. It was during a discussion for an ETSI doc that we realized we were missing those definitions.
> 
> But above there's a need to regain a degree of freedom in how we use links and subnets. The lack of definitions leads to overloading and
> confusion, which in turn leads to confine us within the commonly understood model that is ethernet.
> 
> As we separate the definition of the IP link from that of the lower layer, and separate the definition of subnet from that of IPv4, we regain
> a degree of freedom that enables us to build IPv6 abstractions over any new medium and build subnets of any size and shape.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 17:11:43 +0000

Hello Fred

I fail to understand why you present Aero as an alternative. 

This draft discusses links and subnet models and how existing RFCs can be applied to those models. It is a BCP type of work looking at existing stuff and trying to make sense of it.

Seems that aero is defining new mechanisms and falls in the std track category. Where exactly do they compete?

Regards,

Pascal

> Le 18 mai 2021 à 18:32, Templin (US), Fred L <[email-masked]> a écrit :
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 May 2021 19:38:43 +0000

Pascal,

Apologies, I should have presented the URL's in the reverse order and
recommended looking first at OMNI which specifies details of the OMNI
interface and link model. AERO is a companion document that specifies
internetworking considerations for nodes that employ OMNI interfaces,
but please start first with OMNI:

Thanks - Fred

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Tuesday, May 18, 2021 10:12 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Vasilenko Eduard <[email-masked]>; 6man <[email-masked]>
> This draft discusses links and subnet models and how existing RFCs can be applied to those models. It is a BCP type of work looking at
> existing stuff and trying to make sense of it.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 20:36:02 +0000

Fred,

This does not tell me why you bring this work in this discussion. I do not see that disrupting this thread can help your work to progress. 

I agree with Eduard that it is a good time to poll and see whether 6MAN wishes to adopt this work. 

Maybe this is not the place for creating educational material such as this.

Whether this doc gets published here or not, it is my hope that we can debate and possibly reach a consensus on our basic concepts.

Regards,

Pascal

> Le 18 mai 2021 à 21:38, Templin (US), Fred L <[email-masked]> a écrit :
> 
> Pascal,
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 May 2021 20:54:11 +0000

Pascal,

Sorry to be disruptive, but you think you have a generalized solution for
wireless and I think I have a generalized solution for wireless. Mine includes
a familiar link model that builds on mature standards and BCPs and as near
as I can tell does so in an optimal fashion. OMNI is no longer research or a
pre-prototype toy; OMNI is engineering-ready for IETF progression.

Fred

> Sent: Tuesday, May 18, 2021 1:36 PM
> Subject: [EXTERNAL] Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> Fred,
> 
> >>>> Current ND is not compatible with any Wireless, especially for low power or roaming scenarios. Hence, the proper discussion would
> be
> >>>> helpful.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 May 2021 09:06:22 +1200

> RFC 3819 is mostly not an overlap with what we’re trying to do here, Mark. But that’s a cool reference to keep in mind, thank you for this.

Specifically, it says:

   Subnetworks fall into two categories: point-to-point and shared.  A
   point-to-point subnet has exactly two endpoint components (hosts or
   routers); a shared link has more than two endpoint components, using
   either an inherently broadcast medium (e.g., Ethernet, radio) or a
   switching layer hidden from the network layer (e.g., switched
   Ethernet, Myrinet [MYR95], ATM).

and that is exactly what is no longer always true.

   Brian

> 
>  
> 
> Pascal
> 
>  
> 
> *From:* ipv6 <[email-masked]> *On Behalf Of *Mark Smith
> *Sent:* mardi 18 mai 2021 9:06
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt
> 
>  
> 
>  
> 
> On Tue, 18 May 2021, 07:55 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     IMHO this draft now includes some important new material, namely definitions of two terms "IP Link" and "IP Subnet" (at https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html#name-terminology <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html#name-terminology> ). While I'm not sure yet that I completely agree with the text, I think the topic is very important, since the previous 
doctrine has effectively been that all "links" behave like Ethernet. And, 
by the way, the socket API incorporates that doctrine.
> 
>  
> 
> RFC 3819, Advice for Internet Subnetwork Designers, also being BCP 
89, would seem to me to be the or close to the IETF's definition of a "link" since it is providing advice on the design of them:
>     On 18-May-21 02:45, [email-masked] <mailto:[email-masked]> wrote:
>     > 
>     >         Title        
   : IPv6 Neighbor Discovery on Wireless Networks
>     >         Author        
  : Pascal Thubert
>     >       Pages          
 : 25
>     > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ <https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/>
>     > 
>     > https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html>
>     > 
>     > https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wireless-09 <https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wireless-09>
>     > 
>     > 
submission
>     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>     > 
>     > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>     > 
>     > 
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>     > Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>     > 
> 
>     [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 21:06:44 +0000

Fred,

But this draft is educational about the art of what we have. You’re fighting the wrong draft and I do not see that it helps you progress your own work. But it’s a free world.

Regards,

Pascal

> Le 18 mai 2021 à 22:54, Templin (US), Fred L <[email-masked]> a écrit :
> 
> Pascal,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2021 21:24:14 +0000

I agree with that Brian; 

the definition is too limiting for many networks we observe today, typically networks where one will not set the onlink bit in a PIO.

In a sense it was already an over-limiting definition at the time that rfc was published, e.g., some implementations like Proteon/IBM could model a frame relay network as P2MP or NBMA in the late 90’s. In the same time frame, RFC 2461 recognized the existence of NBMA and the need for further studies to support it.

I guess we’re here to broaden the picture.

More importantly, the rfc describes the lower layer network as opposed to the abstraction of it that one choses to apply at the IO layer. It is important to remind the user that the L3 model is a conscious decision that is not fully dictated by the lower layer subnetwork.

Regards,

Pascal

> Le 18 mai 2021 à 23:06, Brian E Carpenter <[email-masked]> a écrit :
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 May 2021 21:53:46 +0000

> In the same time frame, RFC 2461 recognized the existence of NBMA
> and the need for further studies to support it.

The OMNI link model is exactly NBMA, which is a fortuitous inheritance
from the ISATAP days (also related to Brian's 6over4).

Fred

> Sent: Tuesday, May 18, 2021 2:24 PM
> In a sense it was already an over-limiting definition at the time that rfc was published, e.g., some implementations like Proteon/IBM could
> model a frame relay network as P2MP or NBMA in the late 90’s. In the same time frame, RFC 2461 recognized the existence of NBMA
> and the need for further studies to support it.
> 
> More importantly, the rfc describes the lower layer network as opposed to the abstraction of it that one choses to apply at the IO layer. It
> is important to remind the user that the L3 model is a conscious decision that is not fully dictated by the lower layer subnetwork.
> 
> Regards,
> 
> Pascal
> 
> >>    IMHO this draft now includes some important new material, namely definitions of two terms "IP Link" and "IP Subnet" (at
> <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless-09.html#name-terminology> ). While I'm not sure yet that I
> completely agree with the text, I think the topic is very important, since the previous
> >>    (This is something that gave us quite a lot of angst in ANIMA, especially in clarifying the "link" model in the Autonomic Control Plane,
> since we depend on link-local multicast.)
> >>
> >>    Regards
> >>       Brian
> >>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 19 May 2021 06:05:07 +0000

The problem is even bigger:
the most popular L2 technology in the world (by number of interfaces) claims that it is shared multi-access
then fails to sustain this claim.
Because WiFi is P2MP in reality.
Let us treat it as P2MP - many problems would disappear.

It is already a decade late to do what has been promised in RFC 4861:
" However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., Non-Broadcast
   Multi-Access (NBMA) links), alternative protocols or mechanisms to
   implement those services will be specified (in the appropriate
   document covering the operation of IP over a particular link type)."

Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, May 19, 2021 12:24 AM
To: Brian E Carpenter <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

I agree with that Brian; 

Regards,

Pascal

>> *Subject:* Re: I-D Action: 
>> draft-thubert-6man-ipv6-over-wireless-09.txt
>> 
>>  
>> 
>>  
>> 
>> <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireles
>> s-09.html#name-terminology> ). While I'm not sure yet that I 
> doctrine has effectively been that all "links" behave like Ethernet. 
> And, by the way, the socket API incorporates that doctrine.
>> 
>>  
>> 
>>> ss/ 
>>> <https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wirel
>>> ess/>
>>> 
>>> <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wirele
>>> ss-09.html>
>>> 
>>> ess-09 
>>> <https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wire
>>> less-09>
>>> 
>>> 
>>> <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> 
>>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>> <http://www.ietf.org/shadow.html> or 
>>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>> 
>> 
>>    Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 May 2021 07:51:47 +0000

Agreed;

The original Wi-Fi emulated a broadcast domain to benefit from the IP support over ethernet.
One of those short term solutions that end up lasting a lot longer than desirable.

Ideally the choice of the IP link model (set of P2P, P2MP, or leverage the broadcast emulation as today) should be available at L3.
That's if/when we do our piece of the work. 

I refuse to sit on the problem and claim that the issue is on the IEEE side, to provide a cheap, reliable and efficient multicast. And ignore the laws of physics from the ivory tower of L3. The result has been a 20-years status quo of using an efficient broadcast that defeats the purpose of L3 multicast and hinders the adoption of IPv6 over Wi-fi.

Let's just  do the work. If 6MAN is not the place to publish it, at least we'll have done the necessary hand waving.

Keep safe;

Pascal

> From: Vasilenko Eduard <[email-masked]>
> Sent: mercredi 19 mai 2021 8:05
> To: Pascal Thubert (pthubert) <[email-masked]>; Brian E Carpenter
> <[email-masked]>
> Cc: 6man <[email-masked]>
> the most popular L2 technology in the world (by number of interfaces)
> claims that it is shared multi-access then fails to sustain this claim.
> the definition is too limiting for many networks we observe today,
> typically networks where one will not set the onlink bit in a PIO.
> 
> In a sense it was already an over-limiting definition at the time that
> rfc was published, e.g., some implementations like Proteon/IBM could
> model a frame relay network as P2MP or NBMA in the late 90’s. In the
> same time frame, RFC 2461 recognized the existence of NBMA and the need
> for further studies to support it.
> 
> More importantly, the rfc describes the lower layer network as opposed
> to the abstraction of it that one choses to apply at the IO layer. It is
> important to remind the user that the L3 model is a conscious decision
> that is not fully dictated by the lower layer subnetwork.
> 
> Regards,
> 
> Pascal
> 
> >> RFC 3819 is mostly not an overlap with what we’re trying to do here,
> Mark. But that’s a cool reference to keep in mind, thank you for this.
> >
> > Specifically, it says:
> >
> >> On Tue, 18 May 2021, 07:55 Brian E Carpenter,
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> >>
> >>    Hi,
> >>
> > 89, would seem to me to be the or close to the IETF's definition of a
> "link" since it is providing advice on the design of them:
> >>
> >>
> >>
> >> Abstract
> >>