Subject: [mpls] MPLS Network Functions

From: John E Drake <[email-masked]>
Date: Fri, 1 Oct 2021 20:13:45 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Oct 2021 16:27:27 -0400

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:
> 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.)
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Oct 2021 20:37:18 +0000

Joel,

An excellent suggestion.  We could model this with another SPL with the semantics that only the node removing the nodal SID at the top of stack should process the NFFs.

Yours Irrespectively,

John

> -----Original Message-----
> From: Joel M. Halpern <[email-masked]>
> Sent: Friday, October 1, 2021 4:27 PM
> To: John E Drake <[email-masked]>; [email-masked]
> Cc: Manish Gupta <[email-masked]>
> Subject: Re: [mpls] MPLS Network Functions
> 
> [External Email. Be cautious of content]
> 
> 
> 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
> 
> > 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.
> >
> > 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
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls
> > __;!!NEt6yMaO-gk!W-
> 2uWK_B4d3zEOkFvIsHxo0qqBT7iTd7K4VwzaIMcodAcB6BauQGJ4Zcz3fY0B8$
> >

---

From: Tarek Saad <[email-masked]>
Date: Tue, 5 Oct 2021 17:01:43 +0000

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 <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Date: Friday, October 1, 2021 at 4:14 PM
To: [email-masked] <[email-masked]>
Cc: Manish Gupta <[email-masked]>
Subject: [mpls] MPLS Network Functions
Hi,

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.

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

---

From: John E Drake <[email-masked]>
Date: Tue, 5 Oct 2021 18:14:32 +0000

Tarek,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Tarek Saad <[email-masked]>
Sent: Tuesday, October 5, 2021 1:02 PM
To: John E Drake <[email-masked]>; [email-masked]
Cc: Manish Gupta <[email-masked]>; Kireeti Kompella <[email-masked]>
Subject: Re: MPLS Network Functions

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://urldefense.com/v3/__https:/trac.ietf.org/trac/mpls/wiki/MPLSOpenDT__;!!NEt6yMaO-gk!Xj5Bp9FmvcTS21X_MXY_Quq1yyRJI6XVIOcSnx6lMVCDc6WuOOJmxu3hPq_bm-0$> and ongoing wikis<https://urldefense.com/v3/__https:/trac.ietf.org/trac/mpls/wiki/MPLSOpenDT*OngoingDesignWikis__;Iw!!NEt6yMaO-gk!Xj5Bp9FmvcTS21X_MXY_Quq1yyRJI6XVIOcSnx6lMVCDc6WuOOJmxu3hAH1a5Vg$> .

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.

[JD]  I think Loa had already scheduled me for this week's meeting?

See more inline..

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

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://urldefense.com/v3/__https:/trac.ietf.org/trac/mpls/wiki/thoughts-on-positioning__;!!NEt6yMaO-gk!Xj5Bp9FmvcTS21X_MXY_Quq1yyRJI6XVIOcSnx6lMVCDc6WuOOJmxu3h-UTLvpQ$> about positioning of such ancillary data.

[JD]  The point I was making is that for a given NF, there will be an RFC defining its NFF position, its ancillary data (if any), and where that ancillary is to be placed.

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.

[JD]  I discussed this with Stewart and Adrian and having two SPLs has several advantages, viz, a P router only needs to deal with the NFs it is expected to support and it allows hop-by-hop and end-to-end functions to evolve independently and without destructive interference.  E.g.,  if an end-to-end NF was defined at bit position X and it had complex ancillary data, this might adversely affect simple hop-by-hop NFs that were defined subsequently at bit positions after X.

[JD]  I would characterize this as a false economy.  In this proposal, a P router has a single behavior rather than having two.

[JD]  Good

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://urldefense.com/v3/__https:/trac.ietf.org/trac/mpls/wiki/MPLSOpenDT*OngoingDesignWikis__;Iw!!NEt6yMaO-gk!Xj5Bp9FmvcTS21X_MXY_Quq1yyRJI6XVIOcSnx6lMVCDc6WuOOJmxu3hAH1a5Vg$> 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.

[JD]  I had considered whether we should re-use the structures defined in this proposal for user-defined network functions but wasn't sure whether this might be considered to be too confining.

Regards,
Tarek

Yours Irrespectively,

John

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!Xj5Bp9FmvcTS21X_MXY_Quq1yyRJI6XVIOcSnx6lMVCDc6WuOOJmxu3hbQAIQ7M$>