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

[Ron Bonica <[e-mail]>]

Tom,

Likewise, how painful would it be to allocate a new next-hop type?

                                                      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=