Re: [mpls] Concerns about ISD

[Robert Raszuk <[e-mail]>]

Hi Tony,

> If you’re going to involve the control plane, then it would seem like
Robert’s proposal (or what I understand of it),
> would imply that you push EVERYTHING into the control plane.  Why bother
with data plane encodings at all?

I know You know it but just for the record to the list in my proposal data
plane still needs to contain a fixed 4+4=8 octet reference.

4 octets fora special reserved *single* label and next 4 to contain the
actual reference ID to any special handling. Almost identical to today's
ELI/EL encoding.

That tuple would be always above first top most label on the stack.

And either all nodes would inspect it or only those which based on the top
most label can tell if there is something to inspect or not.

It is essentially an idea stolen from pretty common use of pointers to
memory :)  The actions and metadata distributed outside of data plane would
be a tuple: destination_node+referenece+action_data/metadata/parms etc ...

Happy Easter !
Robert






On Fri, 15 Apr 2022 at 22:04, Tony Li <[e-mail]> wrote:

>
> Hi Haoyu,
>
>
> 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
> <https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda#no1>*
>
>
>
> You’re assuming a TCAM and your only metric here seems to be the storage
> cost.  Many folks don’t do parsing using a TCAM and the performance cost is
> in the reads, not in the storage.
>
>
> *Moreover, in another
> draft https://www.potaroo.net/ietf/all-ids/draft-andersson-mpls-eh-label-stack-operations-03.txt
> <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.*
>
>
>
> If you’re going to involve the control plane, then it would seem like
> Robert’s proposal (or what I understand of it), would imply that you push
> EVERYTHING into the control plane.  Why bother with data plane encodings at
> all?
>
>
> 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 *
>
>
>
> If I understand your proposal, and we want >8 bits for both of these
> fields, then each would require 3 octets of overhead. Storing the EL/GIS
> value might take 2 or 3 octets.  Alignment would take you to 8.
>
> If I look at the same thing with the FAI draft, I get:
>
> FAI: 4 octets
> NFFRR: included in the above, so 0 octets
> Entropy: 4 octets (30 bits, plus overhead)
> GISS: 4 octets (30 bits, plus overhead)
>
> Total: 12 octets
>
>
> *(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 ).*
>
>
>
> It’s true that we have a standard for it. It’s fairly common, so then the
> interesting question is what happens when it is present in the label stack
> along with MNA?  If we do not incorporate EL into MNA, then an
> implementation has to deal with both MNA and EL independently.  What order
> are they in? How do they interact? If we use the standard ELI/EL encoding,
> that’s 8 octets just for entropy.  OTOH, if we incorporate EL into MNA,
> then when using both, we can collapse the encoding.  For example, in the
> example above, entropy is 4 octets, resulting in a savings of 4 octets.
> Half price! And that’s assuming that you don’t use the smaller entropy/GISS
> encodings which would give an even greater savings.
>
> Tony
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>