, March 24, 2022 1:42 PM
To: Templin (US), Fred L ; Joel M. Halpern
Cc: int-area
Subject: RE: [Int-area] IP Parcels improves performance for end systems
Understood. But some router or whatever will need to do the parcel break and
assembly anyway. In high speed network, this is much more
challenging
re routers will see no changes
while the end systems will see the benefits of more efficient packaging through
the use of parcels.
Fred
-Original Message-----
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, March 24, 2022 12:41 PM
To: Templin (US), Fred L
Cc: int-are
able links can
begin to proliferate in the edges at a pace that suits them.
BTW, coincidentally, my professional career got started in 1983 also.
Admittedly,
I did not get into network driver and NIC architecture support until 1986.
Fred
-Original Message-----
From: Joel M. Halpern
enough benefit to justify the work.
Yours,
Joel
On 3/24/2022 3:05 PM, Templin (US), Fred L wrote:
Hi Joel,
-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, March 24, 2022 11:41 AM
To: Templin (US), Fred L
Cc: int-area
Subject: Re: [Int-area] IP
This exchange seems to assume facts not in evidence.
And the whole premise is spending resources in other parts of the
network for a marginal diminishing return in the hosts.
It simply does not add up.
Yours,
Joel
On 3/24/2022 2:19 PM, Templin (US), Fred L wrote:
The category 1) links are
I do not believe the community has an agreed definition of identifier or
locator. We do have some relatively common usage for locator. As far
as I know there is no fully acurate and written down definition even for
that.
Note also that while Dino likes LISP for lots of things (for good
I sure hope you are wrong about where things are going. Because the
logical consequence of the placement and addressing picture you paint is
that all innovation in applications and uses of the Internet comes from
incumbent players who have the leverage and resources to be present at
almost
Joe, I am missing something in your wish.
Ethernet, when it defines new heders, also revises the definition of the
actual frame format on the wire. The IETF does not own the frame format
on the wire. We do not own the link MTU.
Unless we want to reinvent X.25 with linkwise fragmentation and
There is plenty of L2TP still in use.
Yours,
Joel
On 6/9/2021 6:23 AM, Stewart Bryant wrote:
Sequence number checking in the forwarder is always a problem because it
is stateful so I doubt that many high-scale or high-speed forwarders
ever did this.
I think there is an undisclosed assumption
Assuming your interpretation is correct (which seems to match what I
have seen), that would also seem to indicate that allowing them to
hijack an existing code point for their use is also not appropriate.
Yours,
Joel
On 9/22/2019 11:20 AM, Adrian Farrel wrote:
Hi Bob,
I think it would be
Brian, I would think the text just above the paragraph Alissa quoted
would already cover what you ask for. It begins:
Developers SHOULD NOT develop new protocols or applications that
rely on IP fragmentation.
Yours,
Joel
On 8/6/2019 8:55 PM, Brian E Carpenter wrote:
On 07-Aug-19
As far as I can tell (as a mostly observer who is now shepherding this
document) the working group seemed very reluctant to get too specific
about what were or were not constrained environments where fragmentation
might (reasonably?) be expected (or not expected) to work.
I fear that trying
Thanks Ron. The changes related to our discussions nicely address my
concerns.
Yours,
Joel
On 12/12/17 4:14 PM, Ron Bonica wrote:
Folks,
I have posted a new version of draft-ietf-intarea-probe reflecting IETF LC
comments from Joel, Stewart, Stephan, Yaron and Amanda. Please take a look at
Bonica <rbon...@juniper.net>; Joel M. Halpern
<j...@joelhalpern.com>; gen-...@ietf.org
Cc: draft-ietf-intarea-probe@ietf.org; int-area@ietf.org; i...@ietf.org;
pals-cha...@tools.ietf.org; mpls-cha...@ietf.org; l2tpext-cha...@ietf.org; The
IESG <i...@ietf.org>
Subject: Re: [Gen-ar
can't enumerate every type of pseudowire endpoint, we might as
well just call it a pseudowire endpoint and provide no further information
about the type.
Ron
-Original Message-
From: Joel M
Thank you Ron.
On the E-bit (or P-Bit), is the important goal that it is a virtual
interface, that it is pseudowire, or ? It might help there text
indicating what a receiver might do differently based on this bit being
set or unset.
Having said that, Ethernet Pseudowire is at least a clearer
in data centers.
I think you understand my point, so I will not belabour it.
Yours,
Joel
On 5/17/17 1:53 AM, Tom Herbert wrote:
On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
If we want the documents to be informational, then it should be about a
context wh
at 11:03 AM, Joel M. Halpern
<j...@joelhalpern.com <mailto:j...@joelhalpern.com>> wrote:
> It appears to me that there are contexts in which it is likely that ILA is
> useful.
>
> Using the example of the progression of LISP, I have concern with the
&g
It appears to me that there are contexts in which it is likely that ILA
is useful.
Using the example of the progression of LISP, I have concern with the
current approach of NOT spelling out how and where it would be used.
LISP started out as experimental in significant part because it was not
Brian, in my experience working group adoption is more than the working
group agreeing to work on the topic. It is generally the working group
agreeing that the given document is a good basis for starting the work.
Yes, there will almost always be need for improvement. Sometimes
major
[mailto:int-area-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : lundi 20 août 2012 22:52
À : Internet Area
Objet : [Int-area] Nat Reveal Analysis
My thanks to the authors for submitting a revised version of
draft-ietf-intarea-nat-reveal-analysis-03.
I have looked at this document, and have a few
the damage can be restricted to a home premises or
a large number of customers when NPTv6 is used or any other deployment context
requiring the share the first 64 bits.
Does this makes sense to you?
Cheers,
Med
-Message d'origine-
De : Joel M. Halpern [mailto:j...@joelhalpern.com]
Envoyé
it into section 3 (privacy)?
I believe the concerns raised above can be easily addressed, and once
done this document seems to be ready for advancement.
Yours,
Joel M. Halpern
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo
Joe,
I am missing something.
There is an observation that the behavior described in this document
has privacy implications.
Either that statement is true, or it is not. If it is not true, then
there is no need to do anything.
However, it appears likely the statement is true.
If it
2010, at 21:43, Joel M. Halpern wrote:
This document appears to be in good shape. I do have one minor
concern, and one quibble.
THe minor concern is that the document implies that encapsulating
packets with IP options is easily done and a general answer. It is
easily done when MPLS is used across
There does seem to be one significant benefit for being able to get the
same size block from different providers.
If you have used one size, and change providers, if the prefix length
gets longer, you have to rework your plan. And if it gets shorter, but
you don't rework your plan, you are
26 matches
Mail list logo
