I primarily thought that the document wasn't improving by making statements
about routing and addressing in general given how it does specifically seem
to want to improve the situation for the Internet Architecture, so non-Internet
Architecture considerations would be derailments ?!
Aka: Avoid for the document to have to deal with the type of generic discussion
like what you're opening up in your email (which of course is a fun discussion).
For example:
Is LISP really part of the Internet Architecture ? I thought (unfortunately)
not. E.g.: i don't think i can become an Internet transit ISP without
participating
in the "native" BGP routing. "Hey, i don't want these gigantic BGP Internet
routing tables, and my customers don't need it. I just want do do LISP".
If we didn't have the need for the global Internet BGP routing table,
but had a requirement that every Internet ISP had to use LISP, would
there be a need for Tony to write this document ?
Cheers
Toerless
On Fri, Feb 25, 2022 at 07:40:25AM -0800, to...@strayalpha.com wrote:
>
> > On Feb 25, 2022, at 12:02 AM, Toerless Eckert <t...@cs.fau.de> wrote:
> >
> >> Abstract
> >>
> >> Routing and addressing are inexorably tied, and the scalability of
> >
> > ^
> > Nit:
> > prepend "In the Internet architecture"
> >
> > E.g.: If we would have a better architecture, including LISP, we would
> > arguably have a less than inexorable tie... i think.
>
>
> There are only so many ways to determine paths, e.g.:
> - by the structure of the address itself
> - by flooding, at least until you cache a path
> - by knowing what flooding would have accomplished, e.g., by ‘global
> knowledge’ of the network topology
>
> We use all three in the Internet (longest prefix, ARP/LISP, and RIP/OSPF,
> respectively).
>
> “Better” is relative; structure is more efficient and scalable but harder to
> manage, flooding is least efficient and scalable but requires no management,
> and global knowledge is a bit of a balance between the two.
>
> Or is there some other “better” you’re imagining?
>
> Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
