Re: [mpls] MPLS Network Functions

[Tarek Saad <[e-mail]>]

Hi John,

Thanks for this summary.
>From reading through, several of the suggestions that you make may have been covered by the Forwarding Action Indicator (FAI) and Forwarding Actions Data (FAD) proposal that is being discussed weekly by the MPLS DT. It would be great if you can highlight if/where you diverge with any conclusions the MPLS DT has reached - you can refer to the MPLS Open DT wiki<https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT> and ongoing wikis<https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT#OngoingDesignWikis> .

Let me know if you’d like to present at the upcoming MPLS DT meeting on Thursday 10/07, and I can work with the co-Chairs to schedule it.

See more inline..


From: mpls <[e-mail]> on behalf of John E Drake <jdrake=[e-mail]>
Date: Friday, October 1, 2021 at 4:14 PM
To: [e-mail] <[e-mail]>
Cc: Manish Gupta <[e-mail]>
Subject: [mpls] MPLS Network Functions
Hi,

The proposal detailed below, is derived from the forwarding actions (FA) work but is an attempt to simplify it.   Given that we will be defining functions not directly related to forwarding, we are using the term 'network functions' rather than 'forwarding actions'.

When defining a network function, it is necessary to define whether that function is hop-by-hop, processed by every transit node on the packet's path from ingress  node to egress node, or end-to-end, processed only by the  egress node, whether that function requires ancillary data and if so, what is that ancillary data and whether it should be placed in label stack entries (LSE) or after the BoS (BoS data).  If a given network function is directly related to forwarding and requires ancillary data, that data SHOULD be placed in LSEs.
[TS]: yes, this is inline with what the Open DT has been proposing for In Stack Data (ISD) and Post Stack Data (PSD). There are thoughts that Kireeti has put together here<https://trac.ietf.org/trac/mpls/wiki/thoughts-on-positioning> about positioning of such ancillary data.


Both types of network functions are represented in the MPLS label stack by a set of label stack entries (LSE) termed a network function label stack block (NFLSB).  An NFLSB consists of a special purpose label (SPL), one
for hop-by-by and one for end-to-end
[TS]: Having 2 Indicator SPLs may be an option. However, the DT discussed a single forwarding-action registry, where the function (itself) indicates whether it’s hop-by-hop or end-to-end. We may need to assess the benefits of standardizing 2 separate SPLs vs a single SPL.

, followed LSEs which define which network functions are to be performed on the containing packet, the network function flags (NFF), and the ancillary data for each network function whose NFF is set and which requires ancillary data, in the same order as the NFFs are defined.  A NFLSB is delimited either by a trailing SPL or the bottom of stack bit being set in the last LSE in the NFLSB.  In order to facilitate transit node processing, if both types of NFLSBs are present in a packet the hop-by-hop NFLSB MUST precede the end-to-end NFLSB and transit nodes SHOULD ignore the end-to-end NFLSB.  Similarly, if there is BoS data for both types of network functions, the BoS data for the hop-by hop network functions MUST precede the BoS data
  for the end-to-end functions.  (It should be noted that the non-label fields in each of the two SPLs are as defined today simply because there is no need to re-purpose them.)
[TS]: it may still be desirable (inline with the FAI proposal) to repurpose those SPL bits to allow carrying FA(s) that do not require any ancillary data (e.g. NFRR action). This optimizes # of labels needed for carry such actions (without requiring a separate LSE to carry FAs).

The NFFs are encoded in a set of one or more LSEs, where each LSE consists of a 1 bit continuation field followed by 19 bits of NFFs, the BoS field, and 11 bits of NFFs.  Each NFF is associated with a specific, defined network function and if an NFF is set the corresponding function is nominally to be performed on the containing packet.  An initial set of network functions will be defined and over time will be supplemented with additional network functions.  The NFFs MUST be defined contiguously.
[TS]: yes, a similar suggestion was made for providing extensiblity for the # of FAs to be encoded in a label stack.


The continuation field, if set, indicates that there is another NFF LSE following the current one.  This field MUST be understood by any node that understands either type of NFLSB because even if it doesn't understand the meaning of specific NFFS it needs to understand how many NFF LSEs are present in order to skip over them to reach ancillary data carried in the MPLS label stack for the NFFs it does understand.  It should be noted that it is an error if both the continuation bit and the BoS bit are set in a given LSE, and in this case the packed should be discarded.

Each per-NFF LSE ancillary data is encoded  using  the entire LSE except for the BoS field..

The per-NFF ancillary data, both LSEs and BoS data MUST be in the same order as the NFFs.  I.e., there were six defined network functions, with NFFs 1 and 4 requiring in-stack ancillary data, NFFs 2 and 5 not requiring ancillary data, and NFFs 3 and 6 requiring BoS data,  and all of the flags were set in a given received label stack, then the after the NFFs, the MPLS label stack should contain LSEs with the ancillary data for NFFs 1 and 4 and the BoS data should contain the ancillary data for NFFs 3 and 6.  Each piece of BoS data should indicate with which network function it is associated.

If NFF 3 and/or NFF 6 were set then a transit node would know to look for BoS data.  If only NFF 3 was set then the first piece of BoS data would be for it and would indicate NFF 3.  If only NF 6 was set then the first piece of BoS data would be for it and would indicate NFF 6.  If both NFF 3 and NFF 6 were set then the first piece of BoS data would be for NFF 3 and would indicate NFF 3 and the second piece of BoS data would be for NFF 6 and would indicate NFF 6.  (It should be noted that the same logic applies to LSE ancillary data.)

When constructing the end-to-end NFLSB and BoS data the ingress node should only include network functions  understood both by it and by the egress node.

A transit node must understand every NFF up to a given bit position;  i.e., it can't selectively understand individual network functions.  However, this doesn't mean that a transit node must support every function it understands - if a given NFF is set and the transit node does not support the defined function it merely skips over the ancillary data LSEs for that NFF, if present. When a transit node reaches the last NFF that it understands it considers the rest of the NFLSB to be opaque and skips over it.

To handle user-programmable network functions,  the ASLA approach should be used.   I.e.,  There is a separate user-programmable network functions SPL with an IANA assigned value indicating that what follows is a set of MPLS LSEs defining the user-programmable network functions.  The contents of the MPLS label stack after this SPL are essentially opaque to a node that does not understand them and would be delimited by another SPL or by BoS.  I.e., the contents of the MPLS label stack after that SPL and any associated BoS data are not subject to IETF standardization.
[TS]: we have an Open Item<https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT#OngoingDesignWikis> to discuss a proposal for user-programmable actions in the network – including how to disseminate within the network and how a node would decode/interpret the meaning of LSEs that carry user-programmable function/action in the packet.

Regards,
Tarek

Yours Irrespectively,

John


Juniper Business Use Only

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls