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

[Loa Andersson <[e-mail]>]

Tony and Haoyu,

Inlime plz.

On 2022-08-31 00:58, Tony Li wrote:
> 
> Hi Haoyu,
> 
> Well, we’ve already pretty clearly said that we will have a number of different scopes. 

While I agree  that there need to be "a number of different scopes" for 
network actions, I can't really find where we "pretty clearly said 
that". Is it documented anywhere? If not where should we document it?

> Clearly if two actions do not have intersecting scopes, then there’s no issue.

agreed
> 
> However, we’re going to have actions with interesecting scopes. 

Yes, I can't see how that could be avoided.

> 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, 

"arranged" in what meaning, in the packet? in the registry? or?

If we have a encapsulation with the where one header carries a NH, the 
that packet is processed first, and the NH-packet second, right?


but we do need a deterministic, specified order of operations.

agreed, what I wonder is if we can have for example a processing order 
of NA1(psd)->NA2(isd)->N3(psd)?

If we can, doesn't have to be captured in requirements, framework and 
solution specifications?

/Loa
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
>>
> 

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]