y header-only
> checksums.
>
> Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 1:57 PM
> > To: Templin (US), Fred L
> > Cc: Joel Halpern ; int-area
> > Subject: Re: [Int-area] [EXTERNAL] R
> Cc: Joel Halpern ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
> EXT email: be mindful of links/attachments.
>
>
>
> On Tue, Nov 14, 2023 at 1:33 PM Templin (US), Fred L
> w
ter.
Tom
>
> Thank you - Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 12:55 PM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel Halpern
> > ; int-area
> > Subject: Re: [I
ember 14, 2023 12:55 PM
> To: Templin (US), Fred L
> Cc: Templin (US), Fred L ; Joel Halpern
> ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
> EXT email: be mindful of links/attachments.
&g
ade header
> > > > > > > checksum verification a SHOULD
> > > > > > >
> > > > > > > at intermediate hops but a MUST at the final destination?
> > > > > >
> > > > > > Fred,
> >
; > > Fred,
> > >
> > > So this is a type of new checksum of L4 checksum, not the TCP/UDP
> > > checksum defined in RFC793/RFC768? Do you really need this checksum to
> > > cover the transport layer header, could it just be over pseudo header?
> >
hecksum to
> > cover the transport layer header, could it just be over pseudo header?
> > (that would greatly simplify router operations)
> >
> > Tom
> >
> >
> > >
> > > Fred
> > >
> > > > -Original Message-
> >
: Tuesday, November 14, 2023 11:02 AM
> To: Templin (US), Fred L
> Cc: Templin (US), Fred L ; Joel
> Halpern ; int-area a...@ietf.org>
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
> EXT email
Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 10:02 AM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel Halpern
> > ; int-area
> > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > Inter
(US), Fred L
> Cc: Templin (US), Fred L ; Joel Halpern
> ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
> EXT email: be mindful of links/attachments.
>
>
>
> On Tue, Nov 14, 202
flight.
Tom
>
>
>
>
>
> Thanks - Fred
>
>
>
> From: Int-area On Behalf Of Templin (US), Fred L
> Sent: Tuesday, November 14, 2023 7:28 AM
> To: Tom Herbert
> Cc: Joel Halpern ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service mode
Templin (US), Fred L
Sent: Tuesday, November 14, 2023 7:28 AM
To: Tom Herbert
Cc: Joel Halpern ; int-area
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
Tom, the IP parcel / advanced jumbo header checksum is on the same order of
That is a useful link, Andy – thank you for that.
Fred
From: Andrew G. Malis
Sent: Tuesday, November 14, 2023 4:08 AM
To: Templin (US), Fred L
Cc: Tom Herbert ; int-area
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT
Hi Roland,
The outcome of this discussion is that the only change I would ask for links
that support
IP parcels and advanced jumbos is for the far end of the link to deliver frames
with CRC
errors to higher layers (along with a "CRC error" flag, of course). The link
would still run
the CRC func
] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT email: be mindful of links/attachments.
On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L
mailto:40boeing@dmarc.ietf.org>>
wrote:
Joel, I am asking this only for IP parcels and advanced jumbo
To: Templin (US), Fred L
Cc: Robinson, Herbie ; int-area@ietf.org
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT email: be mindful of links/attachments.
Fred,
MD5 is insecure, see RFC 9155 for the details.
Cheers,
Andy
Fred,
About the Ethernet CRC, I would be happy if we left the IEEE standards
> alone to continue to
>
> do the CRC calculations as they have always done as long as there is a way
> to get the receiver
>
> to deliver packets that contain FEC errors to IP instead of dropping them
> unconditionally.
On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L wrote:
> Joel, I am asking this only for IP parcels and advanced jumbos over links
> that support them natively.
> When a router with a link that supports IP parcels and advanced jumbos
> natively receives an
> ethernet frame with bad CRC, it fir
2023 2:27 PM
> *To:* 'Robinson, Herbie'
> *Cc:* int-area@ietf.org
> *Subject:* RE: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
>
>
> I don’t mind entertaining alternatives to MD5 – SHA1?
>
>
>
&g
Thank you for this – useful insights, and appreciated.
Fred
From: Robinson, Herbie
Sent: Monday, November 13, 2023 3:25 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: RE: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT
Cc: int-area@ietf.org
Subject: RE: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
[EXTERNAL SENDER: This email originated from outside of Stratus Technologies.
Do not click links or open attachments unless you recognize the sender and know
opinions.
Fred
From: Templin (US), Fred L
Sent: Monday, November 13, 2023 2:27 PM
To: 'Robinson, Herbie'
Cc: int-area@ietf.org
Subject: RE: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
I don’t mind entertaining alternatives to
Joel, I am asking this only for IP parcels and advanced jumbos over links that
support them natively.
When a router with a link that supports IP parcels and advanced jumbos natively
receives an
ethernet frame with bad CRC, it first checks to see if it is an IP
parcel/advanced jumbo. If so, the
r
to:tom=40herbertland@dmarc.ietf.org>>;
Templin (US), Fred L
mailto:Fred.L.Templin=40boeing@dmarc.ietf.org>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
E
rbertland@dmarc.ietf.org>>;
Templin (US), Fred L
mailto:Fred.L.Templin=40boeing@dmarc.ietf.org>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT email: be mindful of li
lin (US), Fred L
Cc: int-area@ietf.org
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT email: be mindful of links/attachments.
The NICs I have worked on have a mode that allows packets with CRC failures to
be delivered wit
Tom, I think to put this discussion into proper contest we need to remember
that this is about
IP parcels and advanced jumbos, and not about ordinary IP packets. An IP parcel
is a ready-made
vehicle for FEC since it includes up to 64 transport layer segments – simply
include multiple copies
of t
The NICs I have worked on have a mode that allows packets with CRC failures to
be delivered with a status bit indicating the CRC error. If I remember
correctly, CRC logic amounts to just a handful for gates; so, arranging to
disable it would not be worth the effort at the standardization level.
28 matches
Mail list logo
