Subject: [mpls] The MPLS WG has placed draft-andersson-mpls-mna-fwk in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Mon, 04 Apr 2022 22:19:24 -0700

The MPLS WG has placed draft-andersson-mpls-mna-fwk in state
Candidate for WG Adoption (entered by Loa Andersson)

The document is available at
https://datatracker.ietf.org/doc/draft-andersson-mpls-mna-fwk/

Comment:
The document has been made a "candidate" so we can manage the document in the
working group.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Apr 2022 21:45:11 +0200

Dear WG,

I have read this draft with interest.

However I can not resist asking why are we trying so much here to follow
the SPRING model and load a pile of actions into each and every packet in
the form of action sub-stack ?

IMO focus should be on data plane simplicity yet full flexibility as far as
network programming and current and future action execution.

To me it looks like all we need to insert into a packet during edge
imposition just a new  single label (20 bit should be more then enough)
which would act as slice/color/flow_aggregate ID (further called action
ID). Similarly as we are inserting today an Entropy Label.

Then what ID corresponds to which local actions *should be all carried in
control plane not in every packet.*

Each node during packet inspection does two label lookup (forwarding and
action ID). If the lookup does not result in any special actions the normal
MPLS forwarding continues. If it does without modifications to label
stack** proper set of actions are performed and forwarding continues.

** Assumption is made that we are dealing with domain wide labels. But this
model can also work with local labels as in base MPLS architecture.

Kind regards,
Robert

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Apr 2022 13:15:31 -0700

Hi Robert,

Thank you for your comments, as always.

Before we get into the specifics of the framework, are you in agreement with the use cases presented in https://datatracker.ietf.org/doc/html/draft-saad-mpls-miad-usecases-01 <https://datatracker.ietf.org/doc/html/draft-saad-mpls-miad-usecases-01> and the requirements as documented in https://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements-03? <https://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements-03?>

Tony

> On Apr 6, 2022, at 12:45 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Dear WG, 
> 
> However I can not resist asking why are we trying so much here to follow the SPRING model and load a pile of actions into each and every packet in the form of action sub-stack ? 
> 
> IMO focus should be on data plane simplicity yet full flexibility as far as network programming and current and future action execution. 
> 
> To me it looks like all we need to insert into a packet during edge imposition just a new  single label (20 bit should be more then enough) which would act as slice/color/flow_aggregate ID (further called action ID). Similarly as we are inserting today an Entropy Label. 
> 
> Then what ID corresponds to which local actions should be all carried in control plane not in every packet. 
> 
> Each node during packet inspection does two label lookup (forwarding and action ID). If the lookup does not result in any special actions the normal MPLS forwarding continues. If it does without modifications to label stack** proper set of actions are performed and forwarding continues. 
> 
> ** Assumption is made that we are dealing with domain wide labels. But this model can also work with local labels as in base MPLS architecture. 
> 
> Kind regards,
> Robert
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Apr 2022 22:26:09 +0200

Hi Tony,

Yes I agree with both drafts quoted.

The framework outline I proposed meets all listed and unlisted use cases as
decoupling of actions from packets via indirection removes the complexity
from never ending data plane changing.

What actions (or set of actions together) are applied to each packet
becomes a simple control plane job and is signalled completely outside of
data plane.

I also believe the proposed model meets all ADI requirements as specified
in section 3 of draft-bocci.

Thx a lot,
R.

On Wed, 6 Apr 2022 at 22:15, Tony Li <[email-masked]> wrote:

> Before we get into the specifics of the framework, are you in agreement
> with the use cases presented in
> https://datatracker.ietf.org/doc/html/draft-saad-mpls-miad-usecases-01 and
> the requirements as documented in
> https://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements-03?
>
> Tony
>
>
> IMO focus should be on data plane simplicity yet full flexibility as far
> as network programming and current and future action execution.
>
> ** Assumption is made that we are dealing with domain wide labels. But
> this model can also work with local labels as in base MPLS architecture.
>
> Kind regards,
> Robert
>
>
>

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Apr 2022 13:48:44 -0700

Hi Robert,

Let me see if I understand your proposal.  Let’s suppose that we’re trying to address in-situ OAM.  The ingress LSR would be responsible for inserting an NAS that’s only two LSEs. The second LSE would carry a flow id. The control plane would then be responsible for propagating the OAM functionality to each node on the path before the packet was launched. Each LSR would then recognize the flow ID and perform the OAM action (likely a reply packet).  Do I have that right?

If so, I agree that that’s not currently covered by the current framework document.

Tony

> On Apr 6, 2022, at 1:26 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Tony,
> 
> The framework outline I proposed meets all listed and unlisted use cases as decoupling of actions from packets via indirection removes the complexity from never ending data plane changing. 
> 
> What actions (or set of actions together) are applied to each packet becomes a simple control plane job and is signalled completely outside of data plane. 
> 
> I also believe the proposed model meets all ADI requirements as specified in section 3 of draft-bocci. 
> 
> Thx a lot,
> R.
> 
> On Wed, 6 Apr 2022 at 22:15, Tony Li <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Robert,
> 
>> On Apr 6, 2022, at 12:45 PM, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear WG, 
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Apr 2022 14:35:51 -0700

Hi Tony and Robert,
I have a question regarding the IOAM example. Suppose an operator expects
to collect the on-path information for the particular data flow. In that
case, as I understand IOAM, the IOAM profile must be signaled throughout
the whole domain as the path packets follow through the domain may change.
I agree that that approach works for, for example, the IOAM Direct Export
style of collecting and transporting on-path telemetry information. But I
don't see how Incremental or Preallocated IOAM Trace options can work
without storing information as PSD in the data packet associated with the
IOAM profile. What am I missing in the mechanism proposed by Robert?

Regards,
Greg

On Wed, Apr 6, 2022 at 1:49 PM Tony Li <[email-masked]> wrote:

>
> Hi Robert,
>
> Let me see if I understand your proposal.  Let’s suppose that we’re trying
> to address in-situ OAM.  The ingress LSR would be responsible for inserting
> an NAS that’s only two LSEs. The second LSE would carry a flow id. The
> control plane would then be responsible for propagating the OAM
> functionality to each node on the path before the packet was launched. Each
> LSR would then recognize the flow ID and perform the OAM action (likely a
> reply packet).  Do I have that right?
>
> The framework outline I proposed meets all listed and unlisted use cases
> as decoupling of actions from packets via indirection removes the
> complexity from never ending data plane changing.
>
>> Then what ID corresponds to which local actions *should be all carried
>> in control plane not in every packet.*
>>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Apr 2022 23:40:14 +0200

Hi Tony,

In my proposal there is no NAS if we define NAS as Network Action
Sub-Stack.

We have normal vanilla label stack where top most label is followed by
Action_ID Label (AIL). That Action_ID is not swapped and stayed with the
packet till the packet reaches Egress LSR.

/* Above AIL you can have other labels (for example VPN Service Labels or
EL etc .. */

AIL is just like an EL a tuple AIL reserved label from Special Purpose MPLS
Label pool say #8 immediately followed the atual Action ID label.

So in your example ingress LSR will spill out the packet as

DST label (hop by hop or domain wide)
AIL pair (say #8 special purpose + ID_in_Situ OAM)

The control plane would be setup well ahead of anyone asking Edge LSR to
impose such stack. I think you are talking about postcard mode so yes when
selected transit LSRs will see such packets they will be instructed ahead
of such packet arrival to generate ippm postcards.

To further simplify a data plane when the same packet needs to be rather
dropped then undergo FRR (or subsequent FRR) we would still use single
Action ID except this time meaning of such Action ID would result in two
actions. iOAM + FRR avoidance.

So even if for some flows one may envision a wild zoo of actions we
would still avoid the balloon effect on data plane.

And that scheme can be incrementally deployed on today's networks and as
transport MPLS can use traditional LDP (with any allocation mode
unsolicited or DoD or SR-MPLS with concept of global labels). In fact let's
also observe that if we would use the above model we could also vastly
improve SR-MPLS as instead of imposing segment list with say bunch of adj
based SIDs/labels a single label is enough with Action_ID indicating path
preference via the network (essentially like enhanced use of binding SID
:).

Many thx,
Robert

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Apr 2022 23:42:56 +0200

Hi Greg,

Yes I was just understanding Tony reference ti IOAM as postcard trigger.

In fact for true packet ippm I am not sure how this would work with MPLS
packets and today's hardware. With or without embedded network actions in
MPLS header :)

Many thx,
R.

On Wed, 6 Apr 2022 at 23:36, Greg Mirsky <[email-masked]> wrote:

>> Let me see if I understand your proposal.  Let’s suppose that we’re
>> trying to address in-situ OAM.  The ingress LSR would be responsible for
>> inserting an NAS that’s only two LSEs. The second LSE would carry a flow
>> id. The control plane would then be responsible for propagating the OAM

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Apr 2022 14:59:46 -0700

Hi Robert,
thank you for the expedient response. I agree that the group can decide on
which methods of IOAM data collection and transport are better suited for
MPLS networks.

Regards,
Greg

On Wed, Apr 6, 2022 at 2:41 PM Robert Raszuk <[email-masked]> wrote:

>>>> However I can not resist asking why are we trying so much here to
>>>> follow the SPRING model and load a pile of actions into each and every
>>>> packet in the form of action sub-stack ?
>>>>
>>>> IMO focus should be on data plane simplicity yet full flexibility as
>>>> far as network programming and current and future action execution.
>>>>
>>>> Each node during packet inspection does two label lookup (forwarding
>>>> and action ID). If the lookup does not result in any special actions the
>>>> normal MPLS forwarding continues. If it does without modifications to label

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Apr 2022 15:28:07 -0700

Hi Robert,

> In my proposal there is no NAS if we define NAS as Network Action Sub-Stack. 
> 
> We have normal vanilla label stack where top most label is followed by Action_ID Label (AIL). That Action_ID is not swapped and stayed with the packet till the packet reaches Egress LSR. 
> 
> /* Above AIL you can have other labels (for example VPN Service Labels or EL etc .. */
> 
> AIL is just like an EL a tuple AIL reserved label from Special Purpose MPLS Label pool say #8 immediately followed the atual Action ID label. 

AIL plus an Action ID label sure looks like a NAS to me. :)

> The control plane would be setup well ahead of anyone asking Edge LSR to impose such stack. I think you are talking about postcard mode so yes when selected transit LSRs will see such packets they will be instructed ahead of such packet arrival to generate ippm postcards. 
> 
> To further simplify a data plane when the same packet needs to be rather dropped then undergo FRR (or subsequent FRR) we would still use single Action ID except this time meaning of such Action ID would result in two actions. iOAM + FRR avoidance. 
> 
> So even if for some flows one may envision a wild zoo of actions we would still avoid the balloon effect on data plane. 
> 
> And that scheme can be incrementally deployed on today's networks and as transport MPLS can use traditional LDP (with any allocation mode unsolicited or DoD or SR-MPLS with concept of global labels). In fact let's also observe that if we would use the above model we could also vastly improve SR-MPLS as instead of imposing segment list with say bunch of adj based SIDs/labels a single label is enough with Action_ID indicating path preference via the network (essentially like enhanced use of binding SID :). 

It seems to me that you could also set up this behavior using RSVP.

In fact, you could go one step further and not use MNA at all and just set up LSPs with whatever forwarding semantics you want, including IOAM. Yes, ok, this would not be 100% purely following the path of the original LSP. It’s not clear that adding MNA of any flavor would do exactly the same anyway.

In any case, yes, this is an interesting proposal.  I would like to encourage you to write a draft.

I am not sure that anything in your proposal is precluded by the current framework document.  If you have specific comments or suggestions, please articulate them.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 01:10:39 +0200

Hi Tony,

+

> In fact, you could go one step further and not use MNA at all and just set
> up LSPs with whatever forwarding semantics you want, including IOAM. Yes,
> ok, this would not be 100% purely following the path of the original LSP.
> It’s not clear that adding MNA of any flavor would do exactly the same
> anyway.
>

Yes I think flattening the transport layer to execute required actions
would be clearly doable, but I am afraid it is very unscalable. The biggest
selling point of SR has been since day one no service state in transit
network elements.

Bottom line I am afraid it will not fly neither using soft state signalling
nor LSP based embedded actions.

Decoupling those clearly has real advantages.

> encourage you to write a draft.

Thank you.

> I am not sure that anything in your proposal is precluded by the current
> framework document.  If you have specific comments or suggestions, please
> articulate them.
>

The current framework goes in a different direction. Sure it does not
preclude any other direction, but as we all know it vendors would not
implement two different ways to accomplish a similar outcome.

The point of this note was to probe if this proposal would get any traction
among those who are not afraid to think out of the box. Only then will it
be promising enough to dedicate free personal time to writing it up.

Kind regards,
Robert

PS.

As some of you know a few years back I wrote a very similar proposal where
actions and TE info was embedded in part of source IP address when using IP
encapsulation. Ref:
https://datatracker.ietf.org/doc/html/draft-raszuk-teas-ip-te-np-00

Here we are talking about using Action_ID Label instead of source IP
address to carry metadata. But the exact same principle of indirection and
control plane driven network programming applies.

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Apr 2022 16:35:13 -0700

Hi Robert,

> Yes I think flattening the transport layer to execute required actions would be clearly doable, but I am afraid it is very unscalable. The biggest selling point of SR has been since day one no service state in transit network elements. 

Yet it seems like your proposal is exactly creating service state.

> The point of this note was to probe if this proposal would get any traction among those who are not afraid to think out of the box. Only then will it be promising enough to dedicate free personal time to writing it up. 

Well, if you don’t write it up, it’s unlikely to get any traction. :)

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 01:44:35 +0200

Hi,

> Yet it seems like your proposal is exactly creating service state.

Well no more than any other proposal - assuming we are talking about data
plane state.

See when control plane signals action to AIL mapping such action can be a
targeted action. So the state in the data plane will be only installed in
the nodes which actually need to perform special actions.

And that is going to happen irrespective on how we carry the actions -
explicitly in the packet or implicitly in control plane signalling and only
mapping to it in the packet.

Kind regards,
Robert

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Apr 2022 17:13:43 -0700

Hi Robert,

> Well no more than any other proposal - assuming we are talking about data plane state.  

Ummm… Other proposals are putting everything into the data plane, with no reliance on the control plane.  You’re adding a level of indirection from the data plane into control plane state. Not unthinkable, but as you note, it does present scale questions and setup questions.

> See when control plane signals action to AIL mapping such action can be a targeted action. So the state in the data plane will be only installed in the nodes which actually need to perform special actions. 

Almost agreed. Wouldn’t every node along the path need to have state to at least dereference the AIL mapping? Yes, it might be a non-action, but the node can’t know that without performing the dereference.

> And that is going to happen irrespective on how we carry the actions - explicitly in the packet or implicitly in control plane signalling and only mapping to it in the packet. 

Agreed, you can put your actions in the data plane or put them in the control plane with a level of indirection. It’s a tradeoff.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 10:12:43 +0200

Hi Tony,

So I am not so much worried about control plane state - especially that
distribution of those actions mappings could be as simple as configuration
push or pub-sub model. If you think that control plane memory associated
with keeping state of local actions would be an issue then we clearly would
have a different opinion on this.

But please observe that even if you carry action ID in a label stack you
still need to have your hardware understand it (state) and execute such
action (no difference).

The only difference I could think of would be in parameters of actions. But
looking at list of use cases I do not see that it contains such requirement
to embed parameters of executed actions also in each packet.

So in control plane assisted model those parameters would indeed occupy
data plane memory while in packet embedded case (example when they are part
of SRH) they would not.

To the question of dereferencing AIL I am not clear what exactly you are
describing. In my model transit node capable of recognizing AIL is doing a
fixed size 20 bit lookup (label lookup :) which either reveleas local
action or not.

Many thx,
R.

On Thu, 7 Apr 2022 at 02:13, Tony Li <[email-masked]> wrote:

> Ummm… Other proposals are putting everything into the data plane, with no
> reliance on the control plane.  You’re adding a level of indirection from
> the data plane into control plane state. Not unthinkable, but as you note,
> it does present scale questions and setup questions.
>
>
> Almost agreed. Wouldn’t every node along the path need to have state to at
> least dereference the AIL mapping? Yes, it might be a non-action, but the
> node can’t know that without performing the dereference.
>
>
> Agreed, you can put your actions in the data plane or put them in the
> control plane with a level of indirection. It’s a tradeoff.
>
> Tony
>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 7 Apr 2022 03:32:55 -0700

Hi Tony,

I’m pretty much with Robert here, most vendors have been supporting context labels (driven by MVPN and egress protection) for quite some time, distributing context (binding of value to action) over control plane is well understood.

Cheers,

Jeff

From: Robert Raszuk
Sent: Thursday, April 7, 2022 1:12 AM
To: Tony Li
Cc: mpls; [email-masked]
Subject: Re: [mpls] MPLS Network Actions Framework

Hi Tony,

So I am not so much worried about control plane state - especially that distribution of those actions mappings could be as simple as configuration push or pub-sub model. If you think that control plane memory associated with keeping state of local actions would be an issue then we clearly would have a different opinion on this.

But please observe that even if you carry action ID in a label stack you still need to have your hardware understand it (state) and execute such action (no difference).

The only difference I could think of would be in parameters of actions. But looking at list of use cases I do not see that it contains such requirement to embed parameters of executed actions also in each packet.

So in control plane assisted model those parameters would indeed occupy data plane memory while in packet embedded case (example when they are part of SRH) they would not.

To the question of dereferencing AIL I am not clear what exactly you are describing. In my model transit node capable of recognizing AIL is doing a fixed size 20 bit lookup (label lookup :) which either reveleas local action or not.

Many thx,
R.

Hi Robert,

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Apr 2022 07:03:30 -0700

Hi Robert,

> So in control plane assisted model those parameters would indeed occupy data plane memory while in packet embedded case (example when they are part of SRH) they would not. 

You seem to be under the impression that I’m arguing with you.  I’m not. 

> To the question of dereferencing AIL I am not clear what exactly you are describing. In my model transit node capable of recognizing AIL is doing a fixed size 20 bit lookup (label lookup :) which e…

I’m trying to point out that a transit node wil do that 20 bit lookup and needs to find an indication of what its local action should be. Even if a node is expected to take no actions, it would need to be configured to do nothing and simply forward. Thus, the configuration must include every node along the path, not just the nodes where there are actions.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Apr 2022 07:04:37 -0700

Hi Jeff,

If you support Robert’s proposal, then I encourage you to encourage Robert to write a draft.

Tony

> On Apr 7, 2022, at 3:32 AM, Jeff Tantsura <[email-masked]> wrote:
> 
> Hi Tony,
>  
> From: Robert Raszuk <mailto:[email-masked]>
> To: Tony Li <mailto:[email-masked]>
> Cc: mpls <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Thu, 7 Apr 2022 at 02:13, Tony Li <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Robert,
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 16:24:43 +0200

Hi Tony,

> You seem to be under the impression that I’m arguing with you.
>

Not at all :)

> I’m trying to point out that a transit node wil do that 20 bit lookup and
> needs to find an indication of what its local action should be. Even if a
> node is expected to take no actions, it would need to be configured to do
> nothing and simply forward. Thus, the configuration must include every node
> along the path, not just the nodes where there are actions.
>

The way I envision gradual deployment of ALI in LDP or RSVP-TE networks
would be similar to gradual deployment of ELI.

I am still hesitating however of use of capabilities is needed. If LSR does
support and recognizes ALI the fixed lookup on ALI action label would be
performed and proper action can be found (or not). If not the default is to
continue to forward the packet based on the transport label.

So "doing nothing" is default behaviour so not sure if it falls under "would
need to be configured to do nothing" definition.

For "every node on the path" is also not needed. If LSR does not support
ALI it will forward based on top most label treating other labels on the
stack in an opaque way.

Many thx,
R.

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Apr 2022 07:30:59 -0700

Hi Robert,

> So "doing nothing" is default behaviour so not sure if it falls under "would need to be configured to do nothing" definition. 

You didn’t mention that there was a default behavior.  :)

> For "every node on the path" is also not needed. If LSR does not support ALI it will forward based on top most label treating other labels on the stack in an opaque way. 

Of course, you might not get the forwarding decisions or actions that you expected and the packet might not make it to the destination.

Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 7 Apr 2022 18:29:52 +0200

Do not care LI bSPL ;-)

Cheers,
Jeff

> On Apr 7, 2022, at 16:31, Tony Li <[email-masked]> wrote:
> 
> 
> 
> Hi Robert,
>