Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi Tony, please see my inline response. Thanks.

Haoyu

From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, April 15, 2022 11:56 AM
To: Haoyu Song <[e-mail]>
Cc: John E Drake <jdrake=[e-mail]>; Tianran Zhou <zhoutianran=[e-mail]>; [e-mail]
Subject: Re: [mpls] Concerns about ISD


Hi Haoyu,

If you continue to read the indicator draft, you’ll find it may be possible to reach the EHs faster.


I’m sorry, I’m not sure which document you’re referring to.

Yes, I realize that you could store a length of the label stack in the EHI LSE.  That would allow you to index directly to PSD rather than linear parsing for the bottom of stack.  However, that’s not the established MPLS mechanism. :-)  Moreover, it causes a redundancy and inconsistency problem: both the length and the bottom of stack must been coordinated.  What happens if they are inconsistent? Is an implementation supposed to cross-check them? If so, we’re back to linear search for the S bit. And the redundancy seems wasteful of bits.

[HS] Sorry, I forget to include the link. Here it is https://datatracker.ietf.org/doc/html/draft-song-mpls-eh-indicator-04.   Yes, this is some special processing limited only to the SPL. We include such possibility in the document for community discussion. It doesn’t mean we fully support it.

Even we don’t use that mechanism, the parsing latency is indeed linear to the label stack depth.


Thank you.



But if you check the cost of parsing ISD, this can still be a better choice.


Please explain that.  As previously discussed, parsing the full stack to find the bottom of the stack requires more read/load operations. That would seem to mandate poorer performance.

[HS] Assuming the label stack depth is L,  it needs L steps to reach the EH.  The question here is: what’s the reasonable value of L?   The total parsing cost and latency also need to include the parsing of the AD items. If we include this into consideration, we would see PSD would still win overall. Please see pg. 7 of the slides for the analysis https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda#no1
Moreover, in another draft https://www.potaroo.net/ietf/all-ids/draft-andersson-mpls-eh-label-stack-operations-03.txt we describe a way to avoid unnecessary scan of the label stack with the help from the control plane.


Moreover, the stack of stack can help to reduce the label stack depth to reach the EHs.


I’m not following that.  It seems to me that if there is a hierarchical stack, then for an implementation to support all of the network actions, it has to parse all of the hierarchy plus all of the extension headers.

[HS] Yes you are right. Then this optimization works for the case where label stack sections can be spliced (e.g., in normal processing, one never needs to scan the entire label stack). For the hierarchical case, such arrangement may help to scope the EHs, but it doesn’t help the reachability.

For the EH encoding efficiency, I appreciate your input. Currently it follows the IPv6 EH type (i.e., using NH + LENGTH to delineate every EH). There could certainly be room for improvement.


Ok.  If I understand your proposal correctly, there are 4 octets of overhead (HEH) at the start. Then, for each network action, there would seem to be at least 3 octets of overhead, plus any associated data, plus alignment.

Let’s suppose that we want to encode NFFRR, entropy, and GISS in one packet.  By my math, the cost is:

EHI: 4 octets
HEH: 4 octets
NFFRR: 4 octets
Entropy: 8 octets
GISS: 8 octets

Total: 28 octets

Do I have that right?

[HS] It’s right if you think 8 octets are needed for Entropy and GISS (BTW, I wonder why we want to redefine entropy. We have already have a standard for it and we don’t need to do anything more about it ).

Tony