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
> -----Original Message-----
> From: Mark Smith <markzzzsm...@gmail.com>
> Sent: Sunday, May 5, 2019 9:37 PM
> To: Xiejingrong <xiejingr...@huawei.com>
> Cc: Tom Herbert <t...@herbertland.com>; Ron Bonica
> <rbon...@juniper.net>; SPRING WG <spring@ietf.org>; 6man
> <i...@ietf.org>
> Subject: Re: [spring] SRv6 Network Programming: ENH = 59
>
> On Mon, 6 May 2019 at 11:15, Xiejingrong <xiejingr...@huawei.com>
> 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 complexity and CPU at each of the hops at the
> end of the links.
>
> It is has been my understanding that bandwidth has been getting cheaper
> faster than CPU for quite a number of years, has that flipped around?
>
>
> >
> > Jingrong
> >
> >
> >
> > From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert
> > Sent: Monday, May 06, 2019 9:11 AM
> > To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>
> > Cc: SPRING WG <spring@ietf.org>; 6man <i...@ietf.org>
> > Subject: Re: SRv6 Network Programming: ENH = 59
> >
> >
> >
> >
> >
> > On Sun, May 5, 2019, 5:47 PM 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?
> >
> >
> >
> > Tom,
> >
> >
> >
> > There's already ETHERIP number (97). Why not use that?
> >
> >
> >
> > Tom
> >
> >
> >
> >
> > Ron
> >
> >
> > Juniper Internal
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > i...@ietf.org
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=c3_vQkaWUv9VrZu2hHe
> > xkrpuWDPuNaF_aDmPsT-
> K5v4&s=xMl4vY3Oo9yoWumPFQIkAs4LDEgbsazb28zbejhHM9w
> > &e=
> > --------------------------------------------------------------------
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_spring&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcW
> > zoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=c3_vQkaWUv9VrZu2h
> > HexkrpuWDPuNaF_aDmPsT-
> K5v4&s=yCRyw1w61_gizFeEYqfNsMjzIFPqI1pSUdqeNS6nQ
> > o0&e=
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
