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

Toerless Eckert <tte@cs.fau.de> Wed, 02 June 2021 17:34 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 95FE43A13D0 for <mpls@ietfa.amsl.com>; Wed, 2 Jun 2021 10:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id INz-c5hAZaGE for <mpls@ietfa.amsl.com>; Wed, 2 Jun 2021 10:34:20 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822E83A13CF for <mpls@ietf.org>; Wed, 2 Jun 2021 10:34:20 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6C35F548017; Wed, 2 Jun 2021 19:34:13 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5E3514E764D; Wed, 2 Jun 2021 19:34:13 +0200 (CEST)
Date: Wed, 02 Jun 2021 19:34:13 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: kireeti@juniper.net, mpls@ietf.org
Message-ID: <20210602173413.GA53463@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/oD6EKawUzfK-OOn3pIp2ojvgKVA>
Subject: [mpls] kireeti/mpls: draft-kompella-mpls-mspl4fa / draft-bryant-mpls-aux-data-pointer
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 17:34:24 -0000

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.