Reviewer: Joel Halpern
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new
I followed up with Ron on this a bit off-list to try to understand the
goal of the E (or P) bit. (My understanding was clealry not a show
stopper for advancing the draft.) After some explanation, I asked the
following question (Ron suggested I send it to the list.)
It seems you are trying t
Bob was going to engage Alissa in a conversation. Bob, have you gotten
anywhere? I think she may be on vacation.
Yours,
Joel
-Original Message-
From: Ron Bonica
Sent: Thursday, August 15, 2019 9:59 AM
To: Brian E Carpenter ; Alissa Cooper
; Tom Herbert
Cc: Joel Halpern ;
draft
[mailto:int-area-boun...@ietf.org] On Behalf Of Bob Hinden
>> Sent: Thursday, September 05, 2019 11:29 AM
>> To: int-area@ietf.org
>> Cc: IESG ; Joel Halpern ;
>> draft-ietf-intarea-frag-frag...@ietf.org; Suresh Krishnan
>> ; intarea-cha...@ietf.org
>> Subject:
(Sorry, I had missed this call for adoption.)
As far as I can tell, this is a bad idea. It asks the network to do
significant extra work in order to provide a small improvement in the
performance of the hosts. Under the rare circumstance that the host is
sending a very large amount of data i
No, intermediate reassembly is not an optimization.
First, it is a bad idea. It is very painful for routers to perform
reassembly. They have to burn expensive resources managing such
aempted reassesmbly. It has major cost even if the router decides
to give up and forward the pieces.
A
logical next step of allowing multiple
segments to travel together
in the same packet, which may or may not be subject to fragmentation
and reassembly.
But, let’s not get so hung up on the middlebox question that we forget
the benefits
for end-to-end.
Fred
*From:*Joel Halpern [mailto:j...@j
From your description, it seems clear that the SCHC header is not an
extension header. It does not follow the rules for extension headers.
Instead, it is an upper layer / carried protocol, just like IP in IP, or
UDP carrying all sorts of interesting network layer headers.
Yours,
Joel
On 9/
My reading of 8200 is that an extension header MUST start with a one
byte "Next Header" field. SCHC does not. Therefore, it is a carried /
upper layer protocol, not an extension header. Much like IPv6 (in
IPv6). Or UDP (with carrying an application protocol or carrying some
routing header l
Field.
It is just at the end of the datagram, before the ICV.
On 9/7/22 17:35, Joel Halpern wrote:
My reading of 8200 is that an extension header MUST start with a one
byte "Next Header" field. SCHC does not. Therefore, it is a carried
/ upper layer protocol, not an extension header.
or SCHC as carrying
an upper layer protocol. They carry what is in our architecture a
Transport Layer protocol, acting in many ways as part of the IP layer
itself...
Fun.
On 9/7/22 17:35, Joel Halpern wrote:
My reading of 8200 is that an extension header MUST start with a one
byte "
u mention " UDP-carrying headers-with-next-header as
extension headers" ?
Thanks a lot for your clarifications,
Antoine Fressancourt
-Original Message-
From: Int-area On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz
Cc: Internet Are
I support adoption of this document.
The use for the protocol number makes sense.
Yours,
Joel
On 9/13/2022 10:15 PM, Wassim Haddad wrote:
Dear IntArea WG,
We are starting a 2-week call for adoption of*“**Internet Protocol
Number for SCHC”*draft:
https://datatracker.ietf.org/doc/draft-mos
I am unable to parse the statement below as written. I presume I am
missing something that is clear to the writer.
I can understand asking that IKE(v3?) and IPSEC ESP be upgraded to
support quantum resistant algorithms. As I understand it, the security
community is doing that. if there are
Thank you for bringing this proposal forward. I think it is an
interesting idea worth developing.
A couple of small points that I think it would be helpful to clarify.
I believe that there is no intent to require that all limited domains
using RFC 8754 also used the TD Ethertype defined by th
Robert, the SRv6 SRH specification (and b derivation all the SRv6
related specifications) is explicit that it is for use in a limited
domain. It is not intended to allow or enable SRv6 to be sent over
arbitrary portions of the Internet without suitable encapsulation (and
probably at least auth
Not quite, but close.
Routers which are not upgraded, and receive packets with the new
ethertype, will drop them. Which theoretically is fine for routers
which are not intended to be on SRv6 paths. Practically, since you want
to be able to run the paths where you need them, you probably do n
Top posting two small but important points to Fred:
1) Changing Ethernet CRC behavior is up to IEEE. IETF is not free to
redefine that.
2) There are approaches for links with long delays (sometimes even
longer than the 8 minutes to which you refer). If you want to propose
different mechani
ernet becomes
more and more mobile and more and more interplanetary. I think that should
already be
of interest to Intarea.
Fred
-Original Message-
From: Joel Halpern
Sent: Monday, November 13, 2023 1:59 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: [EXTERNAL] Re: [Int-ar
I am not sure Iunderstand Eliot's disagreement. Or Brian's. While the
cases you were envisioning when the term was first coined may have been
pure L3, the practical requirements operators have articulated is
explicitly to be able to fail closed, to avoid accidentally allowing
limited domain pr
:
On Sat, Oct 19, 2024 at 2:29 PM Joel Halpern wrote:
I agree that we need to be careful about scaling. Conversely, if the
set of things needing to be filtered at the domain edge is large, we
can't expect ACLS to work well for it either. Even if the ACL can look
at whatever new thing is
we standardize.
I believe we agree that pretending stuff won't leak in or out without
reliable enforcement is a technical mistake.
Yours,
Joel
On 10/19/2024 5:23 PM, Eliot Lear wrote:
Hi Joel
On 19.10.2024 22:58, Joel Halpern wrote:
I am not sure Iunderstand Eliot's disagreement. Or
I am trying to think why IP (as distinct from TCP / QUIC / ..) would
care about ordering at all. I suppose the corner case of reordered
fragments could be considered relevant to IP. But mostly, this seems to
belong at transport, not IP.
Yours,
Joel
PS: I think the wording in the draft coul
This document describes useful behaviors, and seems a good document for
the IETF to work on. I support WG adoption.
Yours,
Joel
On 5/12/2025 10:19 AM, Juan Carlos Zuniga (juzuniga) wrote:
Dear IntArea WG,
Draft
https://datatracker.ietf.org/doc/draft-chroboczek-intarea-v4-via-v6/
was pres
BNGs are still a big busienss. And BNG resale /emote control uses L2TP
in many cases. The BBF has been working on (and published a first
version of) protocol for control of split BNG. L2TP is commonly used
for these use cases.
Yours,
Joel
On 6/9/2021 7:50 AM, Stewart Bryant wrote:
Which a
25 matches
Mail list logo
