> - Restructured to make the draft more normative.
> - Addressed several comments from Pierre Pfister and others
> - Tried to make the description more generic and less datacenter
> virtualization specific (eliminated references to nvo3 specific terms)
> - Supporting material has been moving to
> -
The Internet works today with billions of nodes connected. Why is that? Because
not all of them are in single routing hardware. I realize aggregation allows
for billions of individual addresses, but let’s compare this to DNS where an
entry equals an individual address.
Maybe “mapping entries gl
> On Feb 27, 2020, at 7:29 PM, Tom Herbert wrote:
>
> To me, security, robustness, and interoperability are more important
> than performance for end users. We
You chose a 3-tuple to a 1-tuple tradeoff . There is no tradeoff. One must
deliver a 4-tuple.
My 2 cents,
Dino
__
Micahel, the was a mis-spelling of the intarea mailing list in your post.
Correcing it with this reply.
Dino
> On Nov 8, 2021, at 12:34 PM, Dino Farinacci wrote:
>
>> Hi Dino, that an interesting discussion today.
>> But too short, and not really resulting in anything s
> Dino Farinacci wrote:
>>> Hi Dino, that an interesting discussion today.
>>> But too short, and not really resulting in anything specific.
>
>> Yeah, maybe so Michael but I hope it fosters discussion, new ideas, and
>> brings people together.
>
> M
Here's my single feature request the network layer should provide:
(1) I want to be connected ALL THE TIME, I want my computer to use all its
links, either cabled or radio, ALL THE TIME.
(2) I do not want to turn on and off wifi to get my device/computer to connect
when it is currently not conn
e OMNI link.
>
> 6. MTU assurance - the ability to deliver packets of various robust
> sizes between peers without loss due to a link size restriction,
> and to dynamically adjust packets sizes to achieve the optimal
> performance for each independent traffic flo
dresses the MTU question only. Your message also indicated that
> the different solutions have an equivalence of function for supporting the
> other
> M's, but they are not equivalent.
>
> Fred
>
>> -Original Message-
>> From: Dino Farinacci [mailto:fari
> Many thanks for the reply. Let me tie this back to my question regarding the
> draft: would you think it being a useful exercise to link the extensions
> described in the GA draft with those desired features from a user
> perspective? Would you be able/willing/happy to contribute to this?
Ple
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Thursday, December 02, 2021 1:05 PM
> To: Stewart Bryant
> Cc: int-area@ietf.org; Dirk Trossen
> Subject: Re: [Int-area] Side meeting follow-up: What exact features do we
> want from the I
course, those IDs are moving around all the time, topologically.
Dino
> On Dec 2, 2021, at 4:38 PM, Brian E Carpenter
> wrote:
>
> On 03-Dec-21 11:17, Dino Farinacci wrote:
>> You missed the point maybe. Common functions should be performed at the
> waist so appli
> I don't want everyone to "ping " :-)
Then you don't make your EID available. But you can source from it.
> Not everyone wants to be easy to find, in fact for privacy it's really
When I say "everyone" I mean services you want to make available. And you may
not want to make them available to th
> I think the discussion is about to talk which layer should the features be
> added to. (network? Host? Or the abstracted waist?)
>
> It is true that users expect more features from the NETWORK as a lot of you
> proposed, but users are definitely know nothing about TCP/IP or OSI or ATM
> arch
> My point, which appears not to be tracking, is I *wish* protocol layers
> didn’t have such strict MTUs, but rather expanded as headers were added *at
> all layers*, in the same *spirit* as Ethernet does.
The Internet can do this. Just make the MTU 1400. Then you can add up to 100
bytes of he
space.
>
> I wonder if we are able to describe this as a possible way to add features.
> Assuming we are able somehow to get rid of the MTU issue, it seems we gain a
> degree off freedom, how this translates specifically for the addressing?
>
> Ciao
>
> L.
&g
Last email was the main point I wants to get across. Now to answer your
questions inline.
> On Dec 6, 2021, at 4:28 AM, Luigi Iannone wrote:
>
> Having said that, this is not caused by addressing itself, right?
Right, IMHO.
> Certainly large addresses eat a lot of that MTU space.
Well
> Dino,
Hey Tom. I should make it clear that I am replying to email in the context of
"user requirements", that means end user requirements. Hence my comment about
1400.
> Definitely at least for a limited domain. For instance, AFAIK Google
> is using 9K MTUs in their internal networks. Whether
> That may help, but only in limited cases.
>
> E.g., let’s say you run IPsec tunnel mode for IPv6, which eats the majority
> of that space. Now that traffic runs over a second IPsec tunnel that you
> don’t know about.
>
> That’s the problem - and why MTU (i.e., having a max in the first place)
> Thanks for clarification.
> Then expectations of users intuitively from my side can be:
>
> (1) I want to be agnostic to the network protocols (I do not want to know
> Bluetooth, ZigBee, thread, Airdrop, or any others). I just hope that if I buy
> an IoT device, I can take control of it by my
> Having said that, products may do this because security trumps all.
>>
>> But you make another point which is pretty fundamental and foundational.
>> Should data links be MTU-less, so to speak? And can they really do that. I
>> won't hold my breath.
>
> I don’t know yet, but I do know that’s
ia erasure codes.
Dino
> On Dec 7, 2021, at 10:42 AM, Tom Herbert wrote:
>
> On Mon, Dec 6, 2021 at 6:17 PM Dino Farinacci wrote:
>>
>>> Dino,
>>
>> Hey Tom. I should make it clear that I am replying to email in the context
>> of "user requirem
And note if you get rid of data link MTUs, your head-of-line-blocking issue
gets worse. Also note 1280 is not 53, and hence we have an international large
scale network running, unlike ATM.
Dino
> On Dec 7, 2021, at 2:48 PM, to...@strayalpha.com wrote:
>
> On Dec 7, 2021, at 12:15 PM, Brian E
tly a necessary evil. Evil that should
> be avoided where possible, but necessary that MUST be supported.
>
> Joe
>
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Dec 7, 2021, at 3:46 PM, Dino Farinacci wrote:
>>
>> Right, I un
> This conversation is missing some fundamental points – really the most
> important
> points – which are the minimum sizes guaranteed to work everywhere. For IPv6,
> the minimum MTU/MRU are 1280/1500. For IPv4, they are only 68/576 but since
> the IPv4 network supports fragmentation we can nomina
> [jiayihao] Here I mean our data is controlled by our service provider not
> user themselves. For example, if I bought a movie X from an online streaming
> provider A, I still do not own this movie X and have to pay again if I want
> to watch movie X from online streaming provider B. However, I
> On Dec 8, 2021, at 8:30 AM, Templin (US), Fred L
> wrote:
>
> Absolutely not talking about translation - talking about concatenation and
> adaptation.
Those terms are too general. Please be more specific.
Dino
___
Int-area mailing list
Int-are
ually find networks that bridge from the enterprise to the Internet?
That is a brain-dead and dangerous design and I never see that.
Dino
> On Dec 8, 2021, at 3:07 PM, Templin (US), Fred L
> wrote:
>
> Dino -see below:
>
>> -Original Message-----
>> Fro
ot;, in
this specific product case, is doing layer 3 routing.
On these types of devices, bridging is done on a set of ports called
switchports and appear to the router as an SVI (Switched Virtural Interface)
that is viewed as a layer 3 port.
In any event, my response is the same &quo
> On Dec 8, 2021, at 5:33 PM, Templin (US), Fred L
> wrote:
>
> Dino, my response to your response is "MTU diversity everywhere, with 576 as
> the
> minimum cell size". I know Joe won't like that, but I can't get him to give a
> straight
> answer.
Does that mean no app should send more than
ven use jumbos if
> they want
> and if the path will support it. If that has not come across to you, please
> go back and
> read my messages.
>
> Fred
>
>> -Original Message-
>> From: Dino Farinacci [mailto:farina...@gmail.com]
>> Sent: Wednesday,
> It's a bit unfair to generalize like this. There's the classical Internet
> with mail and streaming, and there are special applications.
Well I am really not. The LISP design will fragment packets after it
encapsulates at the ITR so the ETR reassembles and then decapsulates. So this
"abstract
> Dino, 'iperf3' proves that applications can sometimes get better performance
> by using
> packet sizes larger than the path MTU even though IP fragmentation is invoked.
In loss-less networks. And what about firewalls, that forward packets they
should be filtering because fragment 0 transport i
Agree and wish we can get back on Dirk/Luigi's topic.
Dino
> On Dec 9, 2021, at 12:14 PM, Hesham ElBakoury wrote:
>
> I am not sure if these discussions are related to IP addressing which what we
> should focus on.
>
> Thanks
>
> Hesham
>
> On 12/9
> If we don't want to share a common transmission resource, then why do we need
> globally unique addresses to use in IP packet headers? Locally unique
> addresses would do just as well.
Just to answer this question specifically. We may not need globally unique
addresses. But I need a unique ad
> If we care about the peer-to-peer property, varying addresses require a
> rendezvous process based on a non-varying identifier. It's then the latter
> that becomes the handle for surveillance and forensics. The real impact of
> CGNAT is to push that factoid into surveillance models; it gives I
> As a network layer person I personally find this a pretty sad situation, and
> I would like it to be otherwise. But the capital markets don't listen to me.
> They are busy talking up the content and cloud folk who are busy pushing out
> replicated content ever closer to the consumer, and they
I don’t know. I haven’t read the details. And is what he is proposing spec’ed
with protocol details? The devil (and reality) is in the details (and then
there are years of deployment details to contend with).
Dino
> On Dec 18, 2021, at 5:50 AM, Hesham ElBakoury wrote:
>
>
> Is the final co
> On Dec 18, 2021, at 5:50 AM, Hesham ElBakoury wrote:
>
> Is the final conclusion from the discussion in this thread that features
> innovation in the future is in the application not the network ?
I don’t think there is a binary answer (or question). Innovation comes in many
forms but I ca
Let’s just see if the Gen-Z, web3.0, blockchain, and metaverse generation can
make pure decentralized peer-to-peer come to reality.
Dino
> On Dec 18, 2021, at 5:00 AM, Stewart Bryant wrote:
>
>
>> I have no idea when I last sent a packet from my client host to any other
>> client host.
>
> From a user perspective, the choice is clear: privacy and security are
> top requirements. We know that payload encryption goes a long way, and
> hopefully encryption of the transport layer headers will become
> dominant so that intermediate nodes will stop meddling and ossifying
> the transport
>> wrote:
>> On 19-Dec-21 11:34, Dino Farinacci wrote:
>> >> From a user perspective, the choice is clear: privacy and security are
>> >> top requirements. We know that payload encryption goes a long way, and
>> >> hopefully encryption of the transp
> Tom, reading your message makes me think you have not read my drafts. The
> answers to the perceived issues you are raising are all there. I do not see
> anything
> new in what you are saying to make me believe otherwise.
So there is a lot of email on this list where folks reference documents (
This idea has been used in ethernet backplanes (as well as cell based) in
switches/routers. The term is frequenty referred to as "super framing" and has
been for at least 20 years.
Maybe a suggestion of "super-packet" would be more appropriate.
The idea works well in short/higher-reliability p
I think it does but leave it to others to comment if complete.
Dino
> On Jan 18, 2022, at 3:27 AM, Luigi Iannone wrote:
>
> Hi All,
>
> Thank you all for the fruitful discussion in this thread.
> I am trying to summarize a bit the discussion and here is what I see:
>
> · The ”where”
> The IAB feels that this is unfortunate, and that the transition to
> IPv6 would be an ideal occasion to provide upper layer end-to-end
> protocols with temporally unique identifiers. The exact nature of
> these identifiers requires further study."
So if the IAB, or the community at large, feels
> 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.
> 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
> 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
> 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
>
>
>> 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 thin
> 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.
> 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".
is reelevant to this doc.
>
> Cheers
>Toerless
>
> On Fri, Feb 25, 2022 at 03:10:47PM -0800, 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 tr
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
> There is a base case to the recursion, i.e., where logical information meets
> fermions and bosons (literally). But that tells you only that base layer; it
> tells you nothing about the meaning of the headers you see inside, e.g., in
> OSI, they would be 1,2,3,4,5,6,7, but in an IP tunnel, the
There is no UDP port number assigned for GRE because it does not run over UDP.
It runs DIRECTLY over IP. Check the RFC if you don’t believe me.
Dino
> On Feb 28, 2022, at 9:29 PM, to...@strayalpha.com wrote:
>
>
>>> On Feb 28, 2022, at 8:00 PM, Dino Farinacci wrote:
&
Okay, we are synced.
Dino
> On Feb 28, 2022, at 10:35 PM, Joe Touch wrote:
>
> In the example I gave, I was equating GRE *to* UDP, not saying it ran over
> UDP, though it can (port 4754, per RFC 8086).
>
> Joe
>
>> On Feb 28, 2022, at 10:15 PM, Dino Farinacci wro
> For example: The use of locator/identifier in RFC6830 (LISP) i think is,
> to use the White Knight's terminology, only what an address is
> called by an xTR (or the LISP instance) but nothing more: It does not
> defining what the nature of the locator or identifier addresses are.
An identifier (
> Thanks. Not contradicting what i claimed... I think.
You think right.
> My point was specifically that the LISP locator helps LISP to "locate" another
> xTR, but that is different from whether or not the locator by the nature
Yes, where the EID is close to or the EID/RLOC are co-located in the
> The addressing related point here is IMHO the RFC 6115 definition for
> identifiers may be more suitable for drone uses than the LISP-MN proposal
> treats EIDs: drones must carry static identifiers for authentication of
> control handover, while the EID assignment in the proposal reads to me a
> On Mar 7, 2022, at 4:18 AM, Jens Finkhaeuser wrote:
>
> Different sections of the draft claim different things; some claim EIDs never
> change, others talk about multiple EIDs used in different scenarios. I find
> section 5.1 interesting: "It is anticipated that these EIDs will change
> infr
> [AFT] If you are interested in identifiers being hashes of public keys, you
> might be interested in self-certifying identifiers, used for instance in
> storage systems.
Check on draft-ietf-lisp-ecdsa-auth for how LISP does "CGAs" for EID assignment.
Dino
> Dino,
>
> thank you for this and your other answers!
Anytime.
> I can see that it's possible to treat EIDs as sufficiently static to treat
> them as (stand-ins for) unique identifiers.
Yes, that is correct.
> I can still (quite easily) construct scenarios with drones where the
> EID-to-RLO
Right, moving the problem does not fix the problem and changes the cost/benefit
ratio as well.
Dino
> On Mar 24, 2022, at 2:30 PM, Joel M. Halpern wrote:
>
> Fundamentally Fred, by not having the host send things in timely pieces you
> have created work. Having some other platform do that wo
> essentially describes a process of creating an "electronic WhitePages"
> for registering and publishing compatible routers, then use "high-usage
> trunks" (static links) to make the predetermined connection between specific
> routers, instead of the common Internet practice of listening fo
> 1)" ... but overlay routers do not drop packets to/from 240.0.0.0/4
> addresses. ... encapsulated packets ... ": For the first part, correct.
> All SPRs do similarly, because the entire RAN is an overlay network, although
> appears as a private network to the Internet core. For t
Your comments are welcome.
Thanks,
Dino
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for
> draft-farinacci-lisp-satellite-network-00.txt
> Date: April 1, 2022 at 10:49:20 AM PDT
> To: "Dino Farinacci" , &quo
Resent correcting int-area.
Dino
> On Apr 2, 2022, at 8:43 AM, Dino Farinacci wrote:
>
>
>>
>> Hi Dino,
>
> Thanks for the comment Sharon.
>
>> Im not sure if it makes sense, but when we were in the satellite IP session
>> in IETF,
>&
> Dino,
>
> Thanks for the question.
>
>> When a provider proxy aggregates, it means they will summarized more
>> specific routes they have stored in their routing table. Like ISP-A above
>> has routes P.1, P.2, and P.3. When ISP-A advertises a P prefix, it is
>> indicating it can reach all mo
> Hi Dino,
>
So here are the options:
(1) ISP-A advertises P to ISP-B (and may also advertise more specifics to
other peers for policy reasons).
(2) ISP-A advertises P.1, P.2, and P.3 to ISP-B and ISP-B advertises P to
its peers.
The questions is *where
> On Apr 5, 2022, at 4:47 PM, Tony Li wrote:
>
>> Not at all clear that its a small amount of bandwidth.
>
>
> Other than a DoS attack, why would it be significant?
Good point. It would only be for traffic to more-specifics that didn’t exist.
> So the draft is supposed to help people think
And Pro-Life? ;-)
Dino
> On Oct 21, 2022, at 11:50 AM, John Gilmore wrote:
>
> Alexandre Petrescu wrote:
>> it might make sense to try to make IPv6 to be quantum resistant.
>
> Relax, have no fear. Both IPv4 and IPv6 are already fully buzzword
> compliant. They are climate change compatible
In answering this question we need to keep in mind that such
techniques as (a) caching routing and forwarding information, (b)
use of separate mapping system for Loc/ID mapping, (c) relying on
probing for determining path feasibility are essential/fundamental
to LISP. In other words, these techniq
LISP has too many fundamental problems to be considered a
potentially practical solution. Some of these problems require
LISP is not perfect and still evolving but let me point out that every
design has fundamental problems. At this scale, it's very hard to be
perfect Robin. And as Noel
In the "stateless" case, having the LISP ITR return
packet-too-bigs with degenerate MTUs (i.e., MTUs less
than 1500) is going to leave source hosts with an
unsatisfactory experience that they would not incur
without an ITR/ETR in the middle.
Ah, then that motivates to upgrade MTUs.
In the stat
The approach in the current LISP draft still relies on ICMPs
coming from anonymous network middleboxes (which Dino himself
has said that we cannot depend on), and provides insufficient
I did not say that. I said you cannot depend on ICMP Unreachables. But
ICMP TooBig and Time-Exceeded message
On Jan 24, 2009, Dino Farinacci wrote:
4 - LISP-ALT's Aggregation implies provider dependence.
This is Christian Vogt's critique:
http://psg.com/lists/rrg/2008/msg00259.html
Not true. Aggregation here is for the EID-prefix. Service providers
do
not carry EID-prefixes in thei
I am not completely opposed to there being a LISP-WG. I am just
saying that I think the LISP development has been hurried in a
number of respects, that it doesn't necessarily need a WG and
that a WG could detract attention from more promising other
approaches.
How about the world is going too s
I imagine you could create LISP-ALT RFCs by the end of 2010 and
have interoperable implementations in software and in some
hardware routers by the end of 2011.
Writing RFCs is probably the first 10% to completion.
You know how long it takes for multiple vendor implementations to get
released,
Dino -
I think we should experimentally compare ALT with other mapping
systems
before we decide whether pull-based or push-based mapping systems are
better. Dismissing push-based mapping systems without corroborating
data would be a bit premature in my opinion.
Agree.
In the absence of ex
cant they? I thought one of the nice things about the loc/id split was
I could number my internals out of whatever I wanted, spread over
creation and the attachment points were the only things that required
aggregation, no?
Yes you can.
Dino
___
Int-
81 matches
Mail list logo
