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 improv
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
that this can be used (roughly
speaking) ~anywhere you can figure out a way to control it~ seems a bit odd.
Yours,
Joel
On 5/16/17 11:25 PM, Erik Kline wrote:
On 14 May 2017 at 03:21, Tom Herbert mailto:t...@herbertland.com>> wrote:
On Sat, May 13, 2017 at 11:03 AM, Joel
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 wrote:
If we want the documents to be informational, then it should be about a
context where we understand how to build the
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
ce we 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-----
Fr
: Ron Bonica ; Joel M. Halpern
; 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
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07
I cannot quite
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
t
I have re-read this document. I think it is a useful document that
captures that state of a complex tradeoff and makes effective
recommendations. I support publishing it as a BCP.
If the authors make further additions, adding a mention of ECMP as a
particular case of stateless load balancers
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 to
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 12:11
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 fi
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
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
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 all
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
reas
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 n
providing 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: [In
l-capable 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. Ha
he core 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: in
, 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
I am probably in the minority, but I thought I would mention one
additional reason why I would not want to hold up forming the LISP
working group while trying to figure out how one tests / performs
experiments on huge scale issues.
While I have my concerns about whether LISP is the right answe
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 wast
3 Sep 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 a
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 i
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
f.org
[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
..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.c
Thank you Med. These changes resolve all of my concerns.
Yours,
Joel
On 8/21/2012 11:22 AM, mohamed.boucad...@orange.com wrote:
Re-,
This version integrates the comments from J. Halpern. Many thanks to Joel for
the review.
A diff is provided below to see the changes.
Cheers,
Med
-Mes
29 matches
Mail list logo
