On 08/05/2019 19:13, Ole Troan 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.
Agreed, it has to last for the entire lifetime of the Internet.
Indeed, I wonder if we should do what we did with MPLS reserved/special
purpose labels and create an extension mechanism now rather than when
we actually run out of space. That way less critical applications
can use the less convenient longer identifier.
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?
Looking at NH=97 there seems to be an existing solution in place that
exactly addresses the need for carrying Ethernet over IP, so I don't see
why that is not used. It is only 16 bits and a single check to confirm
the version, and if implementers and operators are convinced that the IP
address is sufficiently safe as a check, then it is only two extra bytes
to write on transmit and two bytes to skip receive.
The extra bits that NH=97 has reserved may also be useful in the long
term. For example it seems likely that an OAM/ACH mechanism will
eventually be needed at this encapsulation layer (just as it was
eventually needed with the Ethernet over MPLS pseudowire). It would be
hard to retrofit an OAM indicator with NH=59, but trivial with NH=97.
So trivial in fact, I suspect that it ought be considered as part of the
initial specification.
I suspect that we will be far more likely regret this use of 59 in the
long term than we will regret changing to 97 at this early stage.
- Stewart
Cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
