Re: [spring] SRv6 Network Programming: ENH = 59

[Tom Herbert <[e-mail]>]

On Mon, May 6, 2019 at 7:26 AM Ron Bonica <[e-mail]> wrote:
>
> Tom,
>
> Likewise, how painful would it be to allocate a new next-hop type?
>
Ron,

Relative to using an existing protocol number it is painful. If this
is an assigned Internet protocol number then the implication is that
it can be used as next header value of any protocol, not just the
narrow use case of segment routing. That requires changes to host
implementation, middelbox and routers (e.g will packets containing the
new protocol number even be forwarded?), tooling, security, etc. Also,
as I pointed out, if this breaks the traditional four byte aligment of
IP protocols then that will adversely impact performance on some CPU
architectures (definitely has been a problem on SPARC, some uncommon
cases in x86, and it looks like it might be an issue for ARM also).
The performance hit can be substantial especially if a software trap
must be taken on every unaligned access.

Tom

>                                                       Ron
>
>
>
> Juniper Internal
>
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Sunday, May 5, 2019 11:10 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Mark Smith <[e-mail]>; Xiejingrong
> > <[e-mail]>; SPRING WG <[e-mail]>; 6man
> > <[e-mail]>
> > Subject: Re: [spring] SRv6 Network Programming: ENH = 59
> >
> > On Sun, May 5, 2019 at 7:49 PM Ron Bonica <[e-mail]> 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 segment routing header is already
> > adding significantly to packet overhead with an arbitrary list of sixteen byte
> > quantities.
> >
> > Tom
> >
> > > 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 <[e-mail]>
> > > > Sent: Sunday, May 5, 2019 9:37 PM
> > > > To: Xiejingrong <[e-mail]>
> > > > Cc: Tom Herbert <[e-mail]>; Ron Bonica
> > > > <[e-mail]>; SPRING WG <[e-mail]>; 6man
> > > > <[e-mail]>
> > > > Subject: Re: [spring] SRv6 Network Programming: ENH = 59
> > > >
> > > > On Mon, 6 May 2019 at 11:15, Xiejingrong <[e-mail]>
> > > > 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:[e-mail]] On Behalf Of Tom Herbert
> > > > > Sent: Monday, May 06, 2019 9:11 AM
> > > > > To: Ron Bonica <rbonica=[e-mail]>
> > > > > Cc: SPRING WG <[e-mail]>; 6man <[e-mail]>
> > > > > Subject: Re: SRv6 Network Programming: ENH = 59
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, May 5, 2019, 5:47 PM Ron Bonica
> > > > <rbonica=[e-mail]> 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 [e-mail]
> > > > > 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
> > > > > [e-mail]
> > > > > 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=