Re: [mpls] Comments on draft-jags-mpls-mna-hdr-04 - Ordered bit

[Haoyu Song <[e-mail]>]

Hi Tony,

Thanks for the detailed analysis and I agree with what you said.

Best regards,
Haoyu

-----Original Message-----
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, January 6, 2023 12:36 PM
To: Haoyu Song <[e-mail]>
Cc: Joel Halpern <[e-mail]>; [e-mail]
Subject: Re: [mpls] Comments on draft-jags-mpls-mna-hdr-04 - Ordered bit


Hi Haoyu,

There are a couple of cases to think about concerning unknown actions.  They can occur due to two main causes:

- Attack traffic: someone is injecting traffic into the network and trying to get something bad to happen.  They inject some MNA traffic trying to get nodes to crash or get the network to misbehave.

- Errors: something got messed up either in the management plane, in path computation, or due to topology changes and traffic is not ending up where it was expected to go.  So we end up with a MNA action at a node that doesn’t support it.  The most likely case is that someone is trying to add a new action to the network.

In the case of attack traffic, it doesn’t matter what we do, as long as implementations do not corrupt the state of the network.  Performing actions in the packet might cause some counters to increment incorrectly, but it should not affect the forwarding of other, non-attack traffic.  The U bit is irrelevant in this case because it could be set to anything and we should assume that it would be set to whatever would do the most harm.  Note that we’re not out to stop attack traffic here.  That’s not in scope for MNA.

In the case of errors, there are a number of cases.  

The first question is getting node capabilities correct. In section 8, the draft says:

    • Each participating node MUST signal the network actions that it supports.

This information needs to propagate to the PCE.  How that happens is out of scope for this document, but one can imagine that the information might be advertised in the IGP, BGP-LS, or DROID.  

The PCE then needs to compute its path using this information so that the path supports the requested actions. This is a straightforward extension to the CSPF computations that PCE’s already do. There’s not much that we can do to help the PCE do its job.

Even if the PCE does its job, and traffic flows down the correct path, there can be link or node failures. These can trigger fast reroute or TI-LFA changes. Or a router can simply screw up its LFIB and forward incorrectly.  

The bottom line is the same: an error has already occurred.  The question is what to do about it.  

Nothing that we can do will fix the error.  We cannot correct whatever problem has happened. Yes, we can and should notify management that there is a problem, but the next packet with the same set of actions will result in the same error all over again. What’s important at this point is to not corrupt the state of the network for non-erroneous traffic. Hopefully, there are no network actions that could ever do that. So, how do we handle this error? Well, we could get complicated, of course.  But is it worth it?  

You’re recommending that we perform no actions at all.  That’s certainly acceptable.  You can certainly skip all of the actions if your parser completes before any actions are taken.  As I mentioned previously, we don’t want to require this implementation architecture because it would cause other implementations to go to a two-pass evaluation too.

What’s currently there is to skip the unknown action (plus any other flags in that opcode).  This is simple for single-pass implementations to deal with. As you note, this could well be inconsistent as other actions may have been performed. Assuming that those have not corrupted the state of the network tho, this should not have created errors for other traffic.  More likely, there might be some counters that are slightly incorrect.  Yes, this is not optimal, but then again, this is not an exercise is formal correctness, this is a pragmatic approach to error handling.  One error has already happened. As a consequence, other things might not be right.  We can live with that.

Regards,
Tony


> On Jan 6, 2023, at 10:40 AM, Haoyu Song <[e-mail]> wrote:
> 
> Do you mean the ingress node has to learn what’s known and unknown for all the nodes on the path before inserting the set of actions?
>  If so, we need to make such statement clearly.
> If not, then the ingress node has no idea which node knows what. If some action dependency exists, the reasonable action is to drop the packet.
>  Best,
> Haoyu   From: Joel Halpern <[e-mail]> 
> Sent: Friday, January 6, 2023 10:28 AM
> To: Haoyu Song <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [mpls] Comments on draft-jags-mpls-mna-hdr-04 - Ordered 
> bit  The device processing the action list knows it can ignore the unknown entry because the U bit is set.  If it can't be ignored,  don't set the U bit.
> This does require that the administrator have a reasonable idea of what is devices do and do not support.  And that he evaluate carefully how he introduces new functionality.  But those constraints seem inevitable.  Yes, i would prefer more robust feature introduction.  But I don't know how to get there.  So I (we, I hope) settle for the U bit.
>  Yours,
> Joel
> On 1/6/2023 1:21 PM, Haoyu Song wrote:
> Hi Tony,
>  The question is： if an action is unknown to a device, how can the device know if there’s dependency between this unknown action and any other known actions?
>  On the one hand, we require the strict sequential semantics, on the other hand, we allow some missing steps in the chain with the risk that it might accidentally change the sequential semantics. Isn’t this self-contradictory?
>  So if we assume the sequential execution semantics, then we can’t 
> just ignore an unknown action. We have to drop the packet to be safe 
> if an unknown action is met  Best, Haoyu
>  From: Tony Li <[e-mail]> On Behalf Of Tony Li
> Sent: Friday, January 6, 2023 9:58 AM
> To: Haoyu Song <[e-mail]>
> Cc: Joel Halpern <[e-mail]>; [e-mail]
> Subject: Re: [mpls] Comments on draft-jags-mpls-mna-hdr-04 - Ordered bit
>   Hi Haoyu,
>  Usually the action processing happens after the header parsing. Once the parsing is done, the data plane already know if all the actions are supported or not, so in this case, no unwinding is needed.
>   That is one implementation choice.  Another one is to parse and perform actions in one pass.
>  As you know, we try not to constrain specifications to a single implementation.
>  
> 
> 
> If we decided to not allow such a policy, then when an unknown action is met, our only option is to drop the packet (due to the potential dependency concern and sequential semantics). If this is desired, it seems we should also drop the U-bit. Thoughts?
>   As currently described, another policy is to skip just the unrecognized action (plus any dependent actions in the case of flags). This is easily implementable with either implementation architecture:
>  If you are parsing everything first, then you simply discard the actions that should be skipped.
>  If you are executing sequentially, then you skip the unknown action and the remainder of the opcode.
>  The U bit is still useful in that it allows the network manager some control.  Introducing a new action into a network is already going to be challenging and allowing the manager to decide whether to discard mishandled traffic or deliver it any way would greatly reduce the risk involved.
>  Tony
>  _______________________________________________
> mpls mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C01%7Chaoyu.song%40futur
> ewei.com%7Ccd2abadadfc44341ba9508daf025ad93%7C0fee8ff2a3b240189c753a1d
> 5591fedc%7C1%7C0%7C638086341905442633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=%2Fuoi961%2FUn%2FN1wgawxLcnRbyXB%2Fjd5prVR4ejvs0wZs%3D&rese
> rved=0