Should the NextHeader values be a union of all the Link layer protocol types
over IPv6, Ethertypes, IP Protocols, Next Headers and Well known ports - maybe,
but it seems tough to get into 8 bits...
Thank the stars that all those application guys use the well known ports for
the correct protocol
Ole,
That's fine, but which ever way the debate ends, the draft should be
consistent. IMHO, the two ways to achieve consistency are:
- Sections 4.4 - 4.12 all use 59
- Sections 4.4-4.12 all use something other than 59
Ron
Thank you for sharing this.
While deployment and interop are clearly shown, as an operator evaluating
if SRv6 is useful or not, i would like to see the real world performance
characteristics. I believe the document would be more useful if it not only
showed what and how, but also the performance u
Two separate things.
First, it clearly is not just about IP processing or we would have no
next-headers for TCP, UDP, or tunnels. Which we do.
Second, we have a value that means that Ethernet Follows. So clearly it
is no-header is no for the Ethernet case.
Finally, since we have a value thaqt
Joel,
> No next header means exactly what the original request, and the
> documentation, says. There is nothing in the packet past this IP header. It
> does not mean that there is some next header defined by some other context.
Why allow for payload to follow and a "must" requirement to forwa
No next header means exactly what the original request, and the
documentation, says. There is nothing in the packet past this IP
header. It does not mean that there is some next header defined by some
other context.
Yours,
Joel
On 5/9/19 8:36 AM, Ole Troan wrote:
I think it is equally impo
> 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
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 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
On 09/05/2019 10:12, Ole Troan wrote:
On 9 May 2019, at 11:05, Stewart Bryant wrote:
On 08/05/2019 19:13, Ole Troan wrote:
Ron,
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 a
On 08/05/2019 19:34, Sander Steffann wrote:
The whole point of these identifies is to tell the reader what the meaning is of what
follows. Using value 59 like this looks like "when we say 'no-next-header' we
actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me o
> On 9 May 2019, at 11:05, Stewart Bryant wrote:
>
>
>
>> On 08/05/2019 19:13, Ole Troan wrote:
>> Ron,
>>>
>>>
>>> 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
On 08/05/2019 19:13, Ole Troan wrote:
Ron,
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 pay
13 matches
Mail list logo
