Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi Robert,

FEC labels can be used to indicate the existence of AD. In https://datatracker.ietf.org/doc/draft-andersson-mpls-eh-label-stack-operations/03/ we describe such a method to avoid unnecessary label stack scans in some cases.  However, this does need involving control plane and it reduces the label number space as well.

On the other hand, if we assume the indicator and AD are both at BoS, the time to reach it is linear to the number of labels in the stack. Parsing a normal label just needs a few clock cycles, so we need to know a reasonable max label depth expected. If it is around a dozen, only a few tens of cycles are needed. The cost is still acceptable.

Best regards,
Haoyu

From: mpls <[e-mail]> On Behalf Of Robert Raszuk
Sent: Wednesday, April 20, 2022 4:23 AM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Tianran Zhou <zhoutianran=[e-mail]>; [e-mail]; John E Drake <jdrake=[e-mail]>
Subject: Re: [mpls] Concerns about ISD


That is correct.

That is why I have suggested to contain the information in the top label in respect to requirement for further processing of the stack or not.

While it is true that forwarding hardware can read say 200-300 bytes of packer header it does not mean that it does something with every single octet of it as part of forwarding decision.

Thx,
R.

On Wed, 20 Apr 2022 at 11:59, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Agreed, and this applies not only the ELI, but any label which are not the at the top of stack. As specified in section 3.9 of RFC 3031, the classic MPLS forwarding operation is based on the top label only:

   Although, as we shall see, MPLS supports a hierarchy, the processing
   of a labeled packet is completely independent of the level of
   hierarchy.  The processing is always based on the top label, without
   regard for the possibility that some number of other labels may have
   been "above it" in the past, or that some number of other labels may
   be below it at present.

We need to assume this is the default behavior of the legacy LSRs.

Best regards,
Jie

From: mpls [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Wednesday, April 20, 2022 4:09 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; John E Drake <jdrake=[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Concerns about ISD

Jie,

I think we have the same understanding. Not every LSR parses the entire label stack in search for ELI. And for hashing what I recall most implementations just take multiple LSEs not specific EL. EL just happens to be part of it making it more random.

My understanding is that ELI marker is primarily used for handling (apply special operations like insertion or removal) of EL tuple.

Thx,
Robert.



On Wed, 20 Apr 2022 at 09:57, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

This is also the point I raised on the DT meetings.  Neither RFC 3031 nor RFC 6790 mandate the lookup of a bSPL down in the label stack.

RFC 6790 mentions an optional mechanisms based on the lookup of ELI in the label stack so that only EL is used for load balancing. And RFC 8662 (Entropy label for SR) says:

“Then, this entropy label can be used as part of the hash keys used by an LSR.  Using the entropy label as part of the hash keys reduces the need for deep packet inspection in the LSR while keeping a good level of entropy in the load-balancing.  When the entropy label is used, the keys used in the hashing functions are still a local configuration matter, and an LSR may use solely the entropy label or a combination of multiple fields from the incoming packet.”

As long as entropy label is part of the hash key, the expected load balancing result could be achieved.

Best regards,
Jie

From: mpls [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Wednesday, April 20, 2022 4:17 AM
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>>; John E Drake <jdrake=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD


> That died a long time ago, when the Entropy Label came out.

I don't see it that way. And perhaps that was also Haoyu's point.

There is a significant functional and performance difference from using N labels for hashing vs checking (doing lookup) if you recognize value of specific labels embedded down deep in the label stack.

Thx,
R.


On Tue, 19 Apr 2022 at 22:11, Tony Li <[e-mail]<mailto:[e-mail]>> wrote:

Hi Robert,

If those 9 are not MNA capable, then they would see a label (bSPL) that they don’t recognize and should drop the packet.

The whole idea is to avoid having them to even look beyond their own transport label.


That died a long time ago, when the Entropy Label came out.

Tony