Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09

[Haoyu Song <[e-mail]>]

Hi Tony,

Agree. That depends on the use cases. If there were inter-dependency between some use cases, then that should be stipulated in the use case documents to avoid any ambiguity. 

Haoyu

-----Original Message-----
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Tuesday, August 30, 2022 3:59 PM
To: Haoyu Song <[e-mail]>
Cc: Loa Andersson <[e-mail]>; Tianran Zhou <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09


Hi Haoyu,

Well, we’ve already pretty clearly said that we will have a number of different scopes. Clearly if two actions do not have intersecting scopes, then there’s no issue.

However, we’re going to have actions with interesecting scopes. Now, you COULD, as you say ‘infer’ an ordering, but that leaves open the possibility of misinterpretation on the part of an implementer. 

So, I agree that the headers need not be arranged in processing order, but we do need a deterministic, specified order of operations. Otherwise, we just get a mess.

Tony


> On Aug 30, 2022, at 3:44 PM, Haoyu Song <[e-mail]> wrote:
> 
> Hi Tony,
> 
> What I mean is that the header parsing and processing should not be mixed together. The headers are parsed in the order the headers appear in a packet, but the processing order doesn't need to be strictly in this order.
> 
> For example, an IOAM header may need to be processed at both ingress side and egress, and yet some other actions are only processed at ingress side and some others only at egress side. There can be hardly any clear order here.
> 
> Even if some actions have some inter-dependency (we need some solid use case examples here in the context of MNA), it can infer some header processing order that the implementation should follow, but still it doesn't mean the headers must also be arranged in the processing order. 
> 
> Best regards,
> Haoyu
> 
> -----Original Message-----
> From: Tony Li <[e-mail]> On Behalf Of Tony Li
> Sent: Tuesday, August 30, 2022 12:11 PM
> To: Haoyu Song <[e-mail]>
> Cc: Loa Andersson <[e-mail]>; Tianran Zhou <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
> Subject: Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09
> 
> 
> Hi Haoyu,
> 
>> How is the desired order communicated?
>> 
>> [HS] The desired order is an implementation issue for device vendor. It doesn't need to be communicated or dicated by standard. 
> 
> 
> So that means that an operator and buy box X, use it, replace it with box Y and suddenly get a completely different result?
> 
> Suppose that a packet has two actions encoded.  One is to increment a counter, the other has an error and causes the packet to be dropped. Is it ok if box X drops before counting and box Y counts before dropping?
> 
> The ideal of orthogonal semantics would be wonderful, but the reality is that we can’t guarantee that, especially in the face of user-defined actions.
> 
> So, how would a head-end encode options to achieve a given intent if each box has its own unique interpretation of the semantics?   
> 
> What if the semantics drift over software releases?  Does the head end have to know the definitive behavior of every box and every release?
> 
> Tony
>