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

I'm still working on the review and will get back to you later. Here I just give some of my thoughts on the action order issue you raised. 
First, we shouldn't confuse the header parsing order and processing order. Usually, we parse all the headers up front  and then process them in desired order.
Second, the NA should be made independent of each other. i.e., there is no intrinsic order that must be obeyed; and it also means each NA should be either in stack or post-stack  but not to be split into two places.
So in general the order to organize the EHs doesn't matter functionally. Hope this helps.


BTW, it's weird that I didn't receive the original email of this thread until I saw Tianran's reply. Not sure what happened on the email server.

Best,
Haoyu

-----Original Message-----
From: Loa Andersson <[e-mail]> 
Sent: Tuesday, August 30, 2022 8:11 AM
To: Tianran Zhou <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09

Tianran,

Inline please.

On 2022-08-30 02:26, Tianran Zhou wrote:
> Hi Loa,
> Thanks very much for your review.
> Some quick answer to your major concerns.
> Please see in line with my reply.
> 
> Best,
> Tianran
> 
> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: Tuesday, August 30, 2022 12:14 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; DetNet Chairs <[e-mail]>
> Subject: Update to the bullets on the first page of my review of 
> draft-song-mpls-extension-header-09
> 
> Folks,
> 
> I just sent out a mail with my review of draft-song-mpls-extension-header-09.
> 
> It was very quickly pointed that I have a bunch of typos in the three bullets on the first page. The three bullets should have been:
> 
> •  I’m concerned about the inclusion of text on  “accessing the
>      original protocol type and payload” in this document. Accessing
>      protocol types (except for the first nibble) and payload is out of
>      scope for MPLS, and thus for MNA.
> 
> 
> ZTR> As you mentioned the "first nibble" is in the scope of MPLS. Since we have HEH, we can use some bits to quickly identify the original protocol.

If the document meant that checking the the first nibble is ok, but that we should not go further it should say that, not talk about "accessing the original protocol header and the payload.

Something that has been said so many times that I'm starting t feel hoarse:

- the first nibble in MPLS does not give a positive identification on
   "original protocol" or "payload", what it does is giving an indication
   that the payload and protocol is not IPv4 or IPv6 and load sharing
   should be avoided (RFC4928).
   For example a Ethernet Pseudowire without a control word could give
   you any result if you think the first nibble is determinism.

> 
> •  I’m still concerned that we are not considering the processing order
>      between NAIs. I believe that for NAIs using post stack data only the
>      EHs could be inserted in the right order after the HEH. However, what
>      if the NAI relies on ISD ancillary data; and that NAI must be
>      processed after one of the post stack data NAI, but before another?
>      How is that handled?
> 
> ZTR> Do you mean the case when the ISD is not enough, hence requires a PSD? 
No.

> I am not sure if there is such use case. 
Neither am I, but since that is not what I said, I think it is moot.

IMHO, if we anyway need PSD,we can put everything in the PSD. Why we need to split a feature into different parts?

The result of the poll was that ISD is allowed, but that the use of ISD need to be carefully carefully motivated on a case by case basis. The ISD is there, it may be used, we can't just wish it away.

What I have been talking about is the processing order between different NAs. The result of the processing might be effected by the order.

I tried to bring this up a couple of times, but not found to much interest.

Consider the following thought experiment.

Let us assume that we have have a packet that needs to have three NAs persormed, NA-a, NA-b and NA-c.

If all NAs uses post stack data, the method described in the order you want then executed, that could be any order e.g. NA-a, NA-b and NA-c, or NA-a, NA-c and NA-b or even NA-c, NA-b and NA-a, or what ever, you just have to determine the order.

What John (and to some extent Kireeti) proposed also have problems, if I understand what was proposed is that the indicators for the NAs should be put in a flag field in the order they were defined (or at least numbered in the IANA registry). If NA-a has a lower number that NA-b which is lower numbered than NA-c, the execution order will be NAa, NA-b and NA-c. And as I see it in current specifications for the proposal from John and Kireeti, and we can't change that. Though I could think of methods to change, but lets wait with that a bit.

Now let us say that NA-b uses ISD.

Let us assume that the processing order if NA-a, NA-b and NA-c.

The problem with draft-song-mpls-extension-header is that it will do NA-a and NA-c, but not NA-b.

The proposal from John/Kireeti would work, as long as the order of execution an specification is the same. But I don't think we can rely on that.

Hope this helps.

/Loa




> 
> •  The authors have started the process of transforming this into an MNA
>      document, but the transformation is incomplete.
> 
> 
> Sorry about this!
> 
> /Loa
> 
> 

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