[mpls] kireeti/mpls: draft-kompella-mpls-mspl4fa / draft-bryant-mpls-aux-data-pointer

[Toerless Eckert <[e-mail]>]

Some thoughts about the functionality and approaches of these two drafts:

Kireetis draft re-designates ca. 8 bits of new SPLs, called FAI SPL.
Every bit indicates a particular forwarding action which is
conditionally executed whent he bit is set. Some of these
conditional actions may require ancillary data below BoS.

IMHO, the best of this proposal is the designation of those
bits to indicate potentially for every hop, which forwarding
actions to take. And the worst part of the proposal is that it
is not extensible, because each bit has a hard-coded semantic.
Another core issue raised by some is of course the question
if/how the ancillary data has to be structured to be most
easily parsable.

Stewarts draft attempts to generalize the use of 8 bits of the SPL
by using it as an 8-bit value pointing to (a block of) ancillary
data below BoS. The goal was to be also indicating which 
function (as indicated by the ancillary data) needs to be
executed by a hop(s) but to be more easily extensible, and
make packets easier to parse. This comes at the downside of
requiring 8-bits for "just" a single block of ancillary data.

Given how i think we have no clear agreement what can and can not
be easily parsed, i wanted to suggest a "best of both worlds"
packet header to see how folks think about "parsability":

In the MPLS labels Stack:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Forwarding Actions Indicator(FAI) SPL  |.|. .|.|0|1|2|3|4|5|6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Instead of fixed actions indicated by Kireetis proposal,
we have 8 conditional action bis {0,...7}, each one indicating
a conditional action: If a particular bit is set, its associated
action is executed. Else that action is not executed.

Below BoS:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| ID  | Action    |   Length  | ...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| ID  | Action    |   Length  |                              
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aka: below BoS, we have a sequence of ancillary data blocks,
which are self-identifying by their action (aka: type) and
chained by length.

When an ancillar data block has it's
C)onditional bit set, then it's ID field indicates which of
the 8 conditional action it is being referred to. For example if
C=1 and ID=5, then this action would only be executed if
bit 5 of the FAI SPL was set. If C=0, the three ID bits could
have other semantics than ID.

If an Action has no further data, it is just 16 bits long
in this encoding. Up to 64 actions, up to 128 byte
length of ancillary data if the unit of Length is 16 bits.

Of course, any of these encoding details are up for discussion,
the main point is to use 8 bits in the FAI to indicate
8 conditional actions in an extensible fashion.

If this proposal looks appealing from the perspective of
extensibility, flexibility and per-hop conditional action
encodings, then the main question really is how we
are vetting what can and can-not be easily done by
high-speed (Terrabits) packet parsers. E.g.: is this
in the same "complexity" ball park as oher proposals.

And i would love us to start having rules of what is and is
not acceptable parsable instead of just "eyeballing" it.

Cheers
    Toerless