I think it is equally important to note that given an existing way of
encapsulating Ethernet in IP, one ought to have a good reason for
creating a different one. There is no indication that this use case
needs anything different than next-header 97.
And Ole, no next-header does not, as far as I can tell from 8200 and its
predecessors mean "the end of IP processing."
Yours,
Joel
On 5/9/19 7:17 AM, Stewart Bryant wrote:
On 09/05/2019 10:12, Ole Troan wrote:
On 9 May 2019, at 11:05, Stewart Bryant <stewart.bry...@gmail.com>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
