Hi Ron,
On Mon, 6 May 2019 at 12:49, Ron Bonica wrote:
>
> Mark,
>
> As the header chain (including encapsulations) get longer, the packet becomes
> less ASIC friendly.
>
> Allocating a new Next Header value for Ethernet may be less painful than
> introducing a new encapsulation.
>
That's fair
On Sun, May 5, 2019 at 7:49 PM Ron Bonica wrote:
>
> Mark,
>
> As the header chain (including encapsulations) get longer, the packet becomes
> less ASIC friendly.
>
Ron,
I'm dubious that just a two byte header for EtherIP or four byte
header will be a problem especially in light of the fact that
Mark,
As the header chain (including encapsulations) get longer, the packet becomes
less ASIC friendly.
Allocating a new Next Header value for Ethernet may be less painful than
introducing a new encapsulation.
Ron
Juniper Internal
> --
Hi Tom,
Ethernet Over IP (97) was created by RFC 3378. It indicates that the next
header is an Ethernet over IP encapsulation header (see Figure 1 of RFC 3378).
That is different from an actual Ethernet header.
In SRv6, the next header is an Ethernet header.
On Mon, 6 May 2019 at 11:15, Xiejingrong wrote:
>
> Hi Tom,
>
>
>
> Number 97 is a choice but it has 2 bytes wasting.
>
>
It seems strange to me that as bandwidth is constantly getting
cheaper, people seem to be trying harder and harder to use less of it.
The trade-off is increased code complexit
On Mon, 6 May 2019 at 10:48, Ron Bonica
wrote:
>
> Folks,
>
> According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00,
> when processing the End.DX2 SID, the Next Header must be equal to 59.
> Otherwise, the packet will be dropped.
>
> In the words of the draft, "We convenientl
On Sun, May 5, 2019, 6:15 PM Xiejingrong wrote:
> Hi Tom,
>
>
>
> Number 97 is a choice but it has 2 bytes wasting.
>
Jingrong,
To the contrary, those two bytes are critical, they maintain proper
alignment of network and transport layers. Ask the SPARC engineers about
how much fun it is to deal
Hi Tom,
Number 97 is a choice but it has 2 bytes wasting.
Jingrong
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Monday, May 06, 2019 9:11 AM
To: Ron Bonica
Cc: SPRING WG ; 6man
Subject: Re: SRv6 Network Programming: ENH = 59
On Sun, May 5, 2019, 5:47 PM Ron Bonica
On Sun, May 5, 2019, 5:47 PM Ron Bonica wrote:
> Folks,
>
> According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00,
> when processing the End.DX2 SID, the Next Header must be equal to 59.
> Otherwise, the packet will be dropped.
>
> In the words of the draft, "We conveniently r
Folks,
In draft-ietf-spring-srv6-network-programming, can a packet that is destined
for an End.DX4 SID contain a Fragment header? An Authentication header? An
Encapsulating Security Payload header? A Destination Options header?
My initial guess is that it cannot. According to the draft:
"The e
On Mon, 6 May 2019 at 10:56, Joel M. Halpern wrote:
>
> Using "No next header" to mean "next header Ethernet" seems to me to be
> flat wrong.
>
+1
It fails "truth in advertising" and "the principle of least surprise".
> This also brings up another problem. Having the SID specify the next
> hea
Using "No next header" to mean "next header Ethernet" seems to me to be
flat wrong.
This also brings up another problem. Having the SID specify the next
header, over-riding the next header value, seems to me to be a recipe
for fragility, likely leading to mis-implementation.
Yours,
Joel
On
Folks,
According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, when
processing the End.DX2 SID, the Next Header must be equal to 59. Otherwise, the
packet will be dropped.
In the words of the draft, "We conveniently reuse the next-header value 59
allocated to IPv6 No Next He
13 matches
Mail list logo
