P4 2016 draft: ttl handling in simple switch about p4-spec

[vgurevich]

Hello Ben,

You are correct, that's exactly what will happen.

Note, however, the table check_tll that is applied after the table
ipv4_match. The control plane can create an entry there that will match on
the headers.ip.ttl==255 and choose the Drop_action and that's how I think a
reasonable control plane will initialize the table (in addition to that I'd
also add an entry to drop a packet when headers.ip.ttl==0).

It is precisely why I'd really like to add table initializers to the
language.

The other point I want to make is that this is an example code and thus it
is missing a whole bunch of other checks that the "real" data plane
programs would typically perform and this is simply done for the clarity of
the example.

Happy hacking,
Vladimir

On Mon, Aug 15, 2016 at 8:02 PM, Ben Pfaff [email protected] wrote:

It appears to me that the simple switch will happily decrement TTL 0 to
become TTL 255. This seems like surprising behavior to me, even in such a
simple implementation.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#33, or mute the thread
https://github.com/notifications/unsubscribe-auth/AMPb8_88V8FZGuavDktwgbUPcBoZu0Cmks5qgShbgaJpZM4Jk_NT
.

[blp]

Note, however, the table check_tll that is applied after the table ipv4_match. The control plane can create an entry there that will match on the headers.ip.ttl==255 ....

I don't see how: at least in my copy here the ipv4_match table only has a single key field, which is for the IP destination address. If the intent is for this table to match on TTL then it should be declared as a key field; I'm happy to pivot this bug report toward fixing that if you think it's the actual bug.

From my point of view it would be cleaner to combine TTL decrement and check in a single table, but of course that's a debatble matter of opinion.

The other point I want to make is that this is an example code and thus it is missing a whole bunch of other checks that the "real" data plane programs would typically perform and this is simply done for the clarity of the example.

Well, yes, of course, but I would have expected that the bits that are implemented are done with some level of care.

[vgurevich]

Hi Ben,

On Tue, Aug 16, 2016 at 11:49 AM, Ben Pfaff [email protected]
wrote:

Note, however, the table check_tll that is applied after the table
ipv4_match. The control plane can create an entry there that will match on
the headers.ip.ttl==255 ....

I don't see how: at least in my copy here the ipv4_match table only has a
single key field, which is for the IP destination address. If the intent is
for this table to match on TTL then it should be declared as a key field;
I'm happy to pivot this bug report toward fixing that if you think it's the
actual bug.

Here is the code excerpt from the doc (page 22). I highlighted the
appropriate place. If you check the definition of the table check_ttl
you'll see that it matches on the exact value of header.ip.ttl:

  *apply* {
      Ipv4Address nextHop; // temporary variable


      *if* (parseError != NoError) {
            Drop_action();  // invoke drop directly
           *return*;
      }

      ipv4_match.apply(nextHop); // Match result will go into nextHop
      *if* (outCtrl.outputPort == DROP_PORT) *return*;

      check_ttl.apply();
      *if* (outCtrl.outputPort == CPU_PORT) *return*;

      dmac.apply(nextHop);
      *if* (outCtrl.outputPort == DROP_PORT) *return*;

      smac.apply();
}

From my point of view it would be cleaner to combine TTL decrement and

check in a single table, but of course that's a debatble matter of opinion.

Usually this is done separately. As per RFC1812 you might need to apply
different rules, based on whether the packet is destined to the local CPU
(in this case you typically would not decrement the TTL and accept all
values, including TTL=0) or not (and in that case you would probably drop
packets with both TTL=0 and TTL=1).

Happy hacking,
Vladimir

You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#33 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMPb8zs4GFmMaRDVby09a81RQOTIqZOCks5qggYvgaJpZM4Jk_NT
.

[blp]

If you check the definition of the table check_ttl you'll see that it matches on the exact value of header.ip.ttl:

Oh, in check_ttl. I misread your comment as saying that ipv4_match could match on ttl.

OK, fine, leave it.