Tom,
If the authors of the network programming draft are willing to impose the
two-byte header between the SRH and the Ethernet frame, 97 works.
I will let them speak for themselves regarding there willingness to do so.
Ron
Juniper Internal
> -----Original Message-----
> From: Tom Herbert <t...@herbertland.com>
> Sent: Wednesday, May 8, 2019 3:17 PM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: Bob Hinden <bob.hin...@gmail.com>; Ole Trøan
> <otr...@employees.org>; SPRING WG <spring@ietf.org>; IPv6 List
> <i...@ietf.org>
> Subject: Re: SRv6 Network Programming: ENH = 59
>
> On Wed, May 8, 2019 at 11:55 AM Ron Bonica <rbon...@juniper.net> wrote:
> >
> > Bob,
> >
> > The value 97 is tempting, but it already has a meaning that is slightly
> different from what the authors of draft-ietf-spring-srv6-network-
> programming intend. According to RFC 3378, a value of 97 means that the
> next header will be as depicted in Figure 2 of RFC 3378.
> >
>
> Ron,
>
> The spring draft states:
>
> "If the outer header is pushed without SRH, then the DA must be a SID of type
> End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header must be 59
> (IPv6 NoNextHeader). The received Ethernet frame follows the IPv6 header
> and its extension headers."
>
> That describes Ethernet over IP encapsulation.
>
> RFC3378 states:
>
> "EtherIP datagrams contain a 16-bit header and a variable-length
> encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP fields."
>
> That also describes Ethernet in IP encapsulation. The only difference is the
> presence of the two byte EtherIP header. As already mentioned this is
> important for maintaining alignment of the encapslated Ethernet payload, and
> is otherwise inconsequential overhead.
>
> So I don't see why EtherIP won't work here. Can you please clarify your
> concern?
>
> Tom
>
>
>
>
>
> > Ron
> >
> >
> >
> > Non-Juniper
> >
> > > -----Original Message-----
> > > From: Bob Hinden <bob.hin...@gmail.com>
> > > Sent: Wednesday, May 8, 2019 2:45 PM
> > > To: Ole Trøan <otr...@employees.org>
> > > Cc: Bob Hinden <bob.hin...@gmail.com>; Ron Bonica
> > > <rbon...@juniper.net>; Tom Herbert <t...@herbertland.com>; SPRING
> WG
> > > <spring@ietf.org>; IPv6 List <i...@ietf.org>
> > > Subject: Re: SRv6 Network Programming: ENH = 59
> > >
> > > Ole,
> > >
> > > > On May 8, 2019, at 11:13 AM, Ole Troan <otr...@employees.org>
> wrote:
> > > >
> > > > Ron,
> > > >
> > > >> <adding the SPRING mailing list, because this is a SPRING draft>
> > > >>
> > > >> Folks,
> > > >>
> > > >> Sections 4.4 through 4.12 of
> > > >> draft-ietf-spring-srv6-network-programming-
> > > 00 define a set of SIDs that have the following things in common:
> > > >>
> > > >> - they are consumed by the egress node (SL == 0)
> > > >> - they tell the egress node how to forward the payload into a VPN
> > > >>
> > > >> If the payload is IPv4, the next-header value in the SRH must be
> > > >> IP4 (value
> > > 4).
> > > >> If the payload is IPv6, the next-header value in the SRH must be
> > > >> IPv6 (value
> > > 41).
> > > >> If the payload is Ethernet, the next-header value in the SRH must
> > > >> be No
> > > Next Header (value 59).
> > > >>
> > > >> In the interest of consistency, we should probably allocate a new
> > > >> next-
> > > header value for Ethernet and use it.
> > > >
> > > > It's a fairly precious name space though.
> > >
> > > According to https://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__www.iana.org_assignments_protocol-2Dnumbers_protocol-
> > > 2Dnumbers.xhtml&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > > ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> > >
> AWF2EfpHcAwrDThKP8&m=ZtmZfCpk7bYpJSSTREggt8Xm8yHpWgrVBTFHi5a
> > > UtW4&s=Qir8baDHTQf5RGhmFCDSbGShFV8dE_dqL1reoBpkiUE&e=
> > >
> > > 143-252 Unassigned
> > >
> > > Seems like a lot left. Plus there are many that are clearly not
> > > used anymore, so there isn’t a shortage.
> > >
> > >
> > >
> > > > What would a general IP stack do with an Ethernet frame? It's kind
> > > > of a neat
> > > feature that "IP processing terminates here".
> > > > Or are we going to specify Ethernet over IP?
> > >
> > > Look at the the registry, it looks to me we have already
> > >
> > > 97 ETHERIP Ethernet-within-IP Encapsulation [RFC3378]
> > >
> > > From the abstract:
> > >
> > > EtherIP tunnels Ethernet and IEEE 802.3 media access
> > > control frames in IP datagrams so that non-IP traffic can traverse an
> > > IP internet.
> > >
> > > This be appropriate for SRv6 network programming.
> > >
> > > Bob
> > >
> > >
> > > >
> > >
> > >
> > > > Cheers,
> > > > Ole
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
