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

[Loa Andersson <[e-mail]>]

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]