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
