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
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
a-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: [Int-area] Disc
(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
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.
ext 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...@joelhalpern
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
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
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 "
.
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. Much
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
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:
tion " 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 Area
Su
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
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
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
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-area
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
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
20 matches
Mail list logo
