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

[Toerless Eckert <[e-mail]>]

THanks for the discussion today. I have uploaded the pptx to the wiki including
aded slides capturing the discussion points we had today

Its under the OngoingDesignWiki sections (ConditionalActions).

Cheers
    Toerless

On Wed, Jun 02, 2021 at 07:34:13PM +0200, Toerless Eckert wrote:
> 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

-- 
---
[e-mail]