On 09/05/2019 10:12, Ole Troan wrote:
On 9 May 2019, at 11:05, Stewart Bryant <[email protected]> wrote:
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.
But it’s not that nh=59 can be used to imply that Ethernet follows. That would
be very bad.
It’s that ip processing stops here.
Then if the two ends have agreed the meaning of the remaining payload and how
to process it, that’s fine. If that signaling is in-band e.g in a particular
SID or out-of-band, the principle is the same.
Yes, but experience suggests that having no control word and no ability
to retrofit one is a long term problem waiting to happen.
Stewart
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
