Re: [mpls] MPLS Network Functions

I think it may be worth considering a third category.  Essentially that 
represented by an IPv6 destination option before a routing header.  Or 
behavior associated (say as an SRH TLV) with all the entries in an SRH. 
  That is, something to be done / processed by all the identified 
routersin the label list, but not by all routers along the path.

Yours,
Joel

On 10/1/2021 4:13 PM, John E Drake wrote:
> 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.
> 
> 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, 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.)
> 
> 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.
> 
> 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.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 