On Mon, 6 May 2019 at 10:48, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> 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 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? >
Perhaps I'm not understanding the question, however isn't there effectively already an NH value that can represent and carry Ethernet (and other link-layer type frames) - GRE? Yes GRE adds a bit of overhead, but however you get all of what it already supports then. (Perhaps it could be useful to be able to carry MPLS over SR between MPLS islands during a transition to SR, and that would be an example of what you get if using GRE.). Regards, Mark. > 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
