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
Non-Juniper
> -----Original Message-----
> From: Bob Hinden <[email protected]>
> Sent: Wednesday, May 8, 2019 2:45 PM
> To: Ole Trøan <[email protected]>
> Cc: Bob Hinden <[email protected]>; Ron Bonica
> <[email protected]>; Tom Herbert <[email protected]>; SPRING WG
> <[email protected]>; IPv6 List <[email protected]>
> Subject: Re: SRv6 Network Programming: ENH = 59
>
> Ole,
>
> > On May 8, 2019, at 11:13 AM, Ole Troan <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
