On Tue, May 7, 2019 at 7:17 AM Tom Herbert <t...@herbertland.com> wrote: > > On Tue, May 7, 2019 at 7:05 AM Mark Smith <markzzzsm...@gmail.com> wrote: > > > > > > > > On Tue., 7 May 2019, 23:39 Joel M. Halpern, <j...@joelhalpern.com> wrote: > >> > >> That is not what Next-Header means. > >> Even with this explanation, it is clear that 59 is NOT the right value > >> for the next header. > > > > > > If the SID value isn't a reserved for this purpose, permanent and globally > > unique value, how would a troubleshooting tool like Wireshark know to > > decode the Ethernet packet after the no next header? > > > > Any capex cost savings from not encoding this information in the packet > > will be eliminated by the opex costs of increased time to resolve faults > > and the corresponding negative reputation with customers consequences. > > > > The more obvious it is how something works, the quicker and easier it is to > > fix when it breaks. This is the really the principle of least astonishment. > > > > https://en.m.wikipedia.org/wiki/Principle_of_least_astonishment?wprov=sfla1 > > > There are already many IP protocols that allow encpasulation of non-IP > protocols. The aforementioned GRE and EtherIP, but also MPLS also (as > well as UDP variants of these in GRE/UDP, MPLS/UDP). > > If this is just encapsulating Ethernet then the correct type is > EtherIP "EtherIP: Tunneling Ethernet Frames in IP Datagrams" > (RFC3378). EtherIP has a two byte encapsulation header, but really its > primary purpose is to align the Ethernet payload (e.g. it could be an > IP protocol) to four bytes as stated in the RFC "The 16-bit header > field provides memory alignment advantages in some implementation > environments." AFAICT lignment is still relevant on
That is aligment is still relevant on modern CPU architectures (e.g. ARM, RISC-V). I also believe that concerns that the additional two byte header is not hardware friendly are unwarranted. Parsing buffers, cache lines, etc. are typically sized to power of two bytes. So if a packet with an encapsulated Ethernet header may have length 4N + 2, and parsing bufferor cache line size of 4M. If the packet fits into the parsing buffer then 4N + 2 <= 4m=M. But then adding an additional two bytes for EtherIP still keeps the packet in the parsing buffer range since 4N + 2 + 2 <= 4M also. Tom > > > > Regards, > > Mark > > > > > >> > >> Yours, > >> Joel > >> > >> On 5/7/19 3:08 AM, Pablo Camarillo (pcamaril) wrote: > >> > Hi Ron, > >> > > >> > We use the next header value 59 to identify at the receiver that there > >> > is no other kind of Internet Protocol beneath to be processed. > >> > Note that we are *not* using 59 to identify the fact that it is an > >> > ethernet header (i.e. other non Internet-Protocols would also use the 59 > >> > to identify that no further IP header processing has to be performed). > >> > The SID identifies that an Ethernet header follows the IPv6 extension > >> > headers. > >> > > >> > Thanks, > >> > Pablo. > >> > > >> > -----Original Message----- > >> > From: ipv6 <ipv6-boun...@ietf.org> on behalf of Ron Bonica > >> > <rbonica=40juniper....@dmarc.ietf.org> > >> > Date: Monday, 6 May 2019 at 02:48 > >> > To: SPRING WG <spring@ietf.org>, 6man WG <i...@ietf.org> > >> > Subject: SRv6 Network Programming: ENH = 59 > >> > > >> > 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 Header [RFC8200]. When the SID > >> > corresponds to function End.DX2 and the Next-Header value is 59, we know > >> > that an Ethernet frame is in the payload without any further header." > >> > > >> > According to Section 4.7 RFC 8200, " The value 59 in the Next > >> > Header field of an IPv6 header or any extension header indicates that > >> > there is nothing following that header. If the Payload Length field of > >> > the IPv6 header indicates the presence of octets past the end of a > >> > header whose Next Header field contains 59, those octets must be ignored > >> > and passed on unchanged if the packet is forwarded." > >> > > >> > Does the WG think that it is a good idea to reuse the Next Header > >> > value 59? Or would it be better to allocate a new Next Header value that > >> > represents Ethernet? > >> > > >> > Ron > >> > > >> > > >> > Juniper Internal > >> > > >> > -------------------------------------------------------------------- > >> > IETF IPv6 working group mailing list > >> > i...@ietf.org > >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > > >> > > >> > > >> > _______________________________________________ > >> > spring mailing list > >> > spring@ietf.org > >> > https://www.ietf.org/mailman/listinfo/spring > >> > > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> i...@ietf.org > >> Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
