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. 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? Cheers, Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
