Hi all,
The WG chairs have asked that I mention that I will be presenting this draft at
IETF 113 this week and now would be a fine time to discuss this on the mailing
list.
*I* think that they’re worried that you’re going to mug me. :)
Jokes on you tho, I’m going to be virtual.
Talk to you
But if LISP is running in CPE routers, the enterprise has a say on which paths
are used to get to a destination EID. So I would argue the enterprise does have
impact.
Dino
> On Feb 28, 2022, at 12:49 PM, to...@strayalpha.com wrote:
>
> FWIW:
>
>> On Feb 28, 2022, at 9:46 AM, Toerless Eckert
I didn't say you said tunnel. I was stating for clarity, since people think
LISP does tunnels (because we have terminlogy that implies it, ex. Ingress
Tunnel Router (ITR)). Tunnels, from the original introduction of them were
virtual/logical point-point interfaces in a router/switch implementati
FWIW:
> On Feb 28, 2022, at 9:46 AM, Toerless Eckert wrote:
>
> I just said you can unfortunately not claim to be an Internet ISP and
> not carry the whole bloody BGP routing table by just using LISP
> (unfortunately).
>
> Aka: Joe touch pointed out that something like LISP (on-demand routing
Hey wait. I didn't even say tunnel at all ;-)
I just said you can unfortunately not claim to be an Internet ISP and
not carry the whole bloody BGP routing table by just using LISP (unfortunately).
Aka: Joe touch pointed out that something like LISP (on-demand routing
information
if thats an appr
Thanks, Tony,
Inline
On Fri, Feb 25, 2022 at 01:17:17PM -0800, Tony Li wrote:
> > On Feb 25, 2022, at 9:38 AM, Toerless Eckert wrote:
> > I just ran against control plane resource limitations in products way more
> > often during the decades than i felt necessary knowing what control plane
> > p
> Agreed; it’s what I presented to Russ White, et al., in 2006 as a “recursive
> router”. If done correctly (IMO), it makes a network subnet look like a
> router to the rest of the network.
Right.
>> but to quote Noel "Tunnels were never first class citizens of the Internet
>> architecture".
> On Feb 25, 2022, at 8:14 PM, to...@strayalpha.com wrote:
>
> I looked at ML techniques for predicting connection parameters (e.g., AI
> meets TCB-sharing) years ago, but it turned out to not find anything we
> didn’t know going in (diurnal patterns, association based on routing prefix,
> etc.
FWIW...
> On Feb 25, 2022, at 3:10 PM, Dino Farinacci wrote:
>
>> 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 gigan
Hi, Dino,
Yes, ML can help deal with unpredictable link issues *if* there are some
underlying statistics at work. However, it’s generally more useful to track
such links as faulty and replace them than to use AI to “adapt” to their
failure patterns.
I looked at ML techniques for predicting con
>
>
>> On Feb 25, 2022, at 3:07 PM, Dino Farinacci wrote:
>>
>>
>>>
>>> We use all three in the Internet (longest prefix, ARP/LISP, and RIP/OSPF,
>>> respectively).
>>
>> But we haven't used ML. Wonder what people think about that?
>
> Machine learning?
Yes.
> As in the failed DARPA In
> On Feb 25, 2022, at 3:07 PM, Dino Farinacci wrote:
>
>
>>
>> We use all three in the Internet (longest prefix, ARP/LISP, and RIP/OSPF,
>> respectively).
>
> But we haven't used ML. Wonder what people think about that?
Machine learning?
As in the failed DARPA Intelligent Nets effort?
I
> 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 j
> Yes. My hair is turning gray. AFAICT, this is not written down elsewhere. If
> not published, the concept of an abstraction action boundary might be lost.
> Noel, who deserves 100% of the credit for this has already passed the point
> of caring.
I will vouch for this since the last networking
> We use all three in the Internet (longest prefix, ARP/LISP, and RIP/OSPF,
> respectively).
But we haven't used ML. Wonder what people think about that?
Dino
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
> b) auto-aggregation within routers from routing-plane to forwarding
> plane. Aka: Just don't populate the poor HW tables with all those
> non-aggregated prefixes, but calculate the minimum number of
> sufficient shorter prefixes.
We did that in year 2000. It is/was called FIB compression.
> On Feb 25, 2022, at 9:38 AM, Toerless Eckert wrote:
>
> I just ran against control plane resource limitations in products way more
> often during the decades than i felt necessary knowing what control plane
> performane would be possible with appropriately scaled CPU/memory.
Well, here’s t
On Fri, Feb 25, 2022 at 08:34:29AM -0800, Tony Li wrote:
> > Aka: In one possible universe (where less-stupid router vendors finally
> > start putting powerful enough control plane CPU/memory into routers),
> > i may not predominantly have a scalability issue of the routing subsystem,
> > but only
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
Hi Toerless,
> 1. Is there any specific reason to bring this up now, e.g.: urgency to
> avoid running out of headroom or the like ? Would be good to add that
> to the text for motivation. right now it reads very architectural.
Yes. My hair is turning gray. AFAICT, this is not written down elsew
> On Feb 25, 2022, at 12:02 AM, Toerless Eckert 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 h
21 matches
Mail list logo