Subject: Re: [mpls] Entropy size in draft-decraene-mpls-slid-encoded-entropy-label-id

From: <[email-masked]>
Date: Fri, 1 Apr 2022 16:32:54 +0000

Joel,

Please see inline

> From: mpls <[email-masked]> On Behalf Of Joel M. Halpern
> 
> I am trying to understand if the opposing forces for field size in this
> draft mesh weell or badly.

Thanks for your technical comment and analysis.
 
> As I read the draft, the number of bits being used for what the draft
> calls the slice ID has to be sufficient to represent the number of
> distinct slice-like-things (I think these are roughly what Bestbaer
> calls slice aggregates) that the network forwarding has to be aware of?

Yes.

> While that is a much smaller number than the number of external network
> slices, it still takes 8 or 10 bits on many networks?

I don't really have data on this. And so far, whoever I asked the question to, also had little clue about. Would you have data?
Personally, I would have expected that 100 of aggregate slides seems already plenty to me (both from a management aspect and from hardware capability standpoint on core interfaces (optimized for bandwidth and cost))
 
> Side note:  If it is actually intended to number the external network
> slice instances rather than IETF network slices or bestbar slice
> aggregates, then significantly more bits will be needed.

No, it's not. (i.e. you were correct)
 
> At the same time, we need enough bits left over for effective entropy
> operation within an identified slice-like collection. 

IMO, what we need is enough entropy across all flows (not flows within one slice) so that all ECMP are used roughly evenly.
So even assuming that all traffic belong to slices (which seems debatable to me, at the very least higher than mobile only (pre) aggregation), IMO both the slide ID and the entropy number are usable to hash on.

> While some of
> those will have only a few flows, some of them will have a lot.
> Still,we could hash down to a small field.  But...  this seems likely to
> reduce the efficacy of ECMP within the slice-like-collection.  I do not
> see any discussion of this in the draft.  Has it been analysed for
> sufficiency?

I agree that splitting the 20 bits of entropy labels in two fields is slightly less efficient than a perfect hash. However, EL is 20 bits not because we needed 20 bits, but because we had 20 bits. Also, RFC6790 does not discuss, not to mention specify the " load-balancing function" not how the entropy value is computed. All it says is " apply the load-balancing function to these input fields and let LB be the output. [...] Use LB to generate the entropy label EL.". IMO draft-decraene-mpls-slid-encoded-entropy-label-id is fully compliant with this.
Also, I think that I've been told that some implementations don't fully use the 20 fields; while I'm pretty sure that they would call themselves to be compliant with RFC6790.

Finally, I don't recall that RFC 6790 discussed what was the right number of bits. Hence it seems difficult for subsequent draft to update the analysis.

Yours,
--Bruno
 
> Yours,
> Joel
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

Orange Restricted

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Apr 2022 13:00:06 -0400

To be clear, I am not suggesting that the rules prohibit making this 
change.  Clearly, if we have a rough consensus we can do so.  I see no 
point in debating whether the change is compliant with 6790.
(I do appreciate the discussion on hardware compatibility. )

I do think it is reasonable to ask if 10 or 12 bits of entropy are 
enough to do the job well.

As I recall there was consideration as to whether 20 bits was enough, 
and we concluded that it was.  But are 12?  Maybe.  All I am asking is 
some evaluation of this dimension of the proposal.

There is the related issue that usually when picking field sizes we like 
to have slack, a bigger field than we think we need.  In this case we 
clearly can't do that.  Which is unfortunate but not a show stopper.

Yours,
Joel

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 2 Apr 2022 13:12:30 +0200

Hi Bruno,

> I don't really have data on this. And so far, whoever I asked the question
> to, also had little clue about. Would you have data?
> Personally, I would have expected that 100 of aggregate slides seems
> already plenty to me (both from a management aspect and from hardware
> capability standpoint on core interfaces (optimized for bandwidth and cost))

May I ask a few clarifying questions ...

*A* How do you envision networks handling 2^10 slices if most networks can
not effectively handle 3 bits of QoS ?

*B* Can't the notion of "network slice" be pushed to control plane and
simply map by control plane to different LSPs if we are talking MPLS here
at transport ? Is there any value to keep changing what at the forwarding
level works fine and push notion of 2^10 or more slices to the data plane
of each node ?
*C* Is there any network element which allows 2^10 QoS classes or profiles
?

Bonus questions:

*D* In SR-MPLS networks can't the notion of slice be mapped to SR policy by
controller ?

*E* In SRv6 networks can't the notion of slicing be carried either in SRH
as SR policy or at most be mapped to flow label ?

*F* What is the expected set of different handling of slice N vs slice N+1
in any transit node (still assuming 2^10 slices) ?

Thx,
Robert.

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 2 Apr 2022 17:58:15 -0700

Very correct questions.

Wrt entropy label - its value is never used to define outgoing interfaces/hashing bucket (as someone previously states), it is used to enhance entropy (to avoid polarization) in addition to the data already present, being label stack of a particular depth or some of L3/L4/incoming interface/etc fields.
It doesn’t need to be 20b.

Cheers,
Jeff

> On Apr 2, 2022, at 04:12, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Bruno,
> 
> *A* How do you envision networks handling 2^10 slices if most networks can not effectively handle 3 bits of QoS ? 
> 
> *B* Can't the notion of "network slice" be pushed to control plane and simply map by control plane to different LSPs if we are talking MPLS here at transport ? Is there any value to keep changing what at the forwarding level works fine and push notion of 2^10 or more slices to the data plane of each node ? 
> *C* Is there any network element which allows 2^10 QoS classes or profiles ? 
> 
> Bonus questions: 
> 
> *D* In SR-MPLS networks can't the notion of slice be mapped to SR policy by controller ? 
> 
> *E* In SRv6 networks can't the notion of slicing be carried either in SRH as SR policy or at most be mapped to flow label ? 
> 
> *F* What is the expected set of different handling of slice N vs slice N+1 in any transit node (still assuming 2^10 slices) ? 
> 
> Thx,
> Robert.
>

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 3 Apr 2022 08:48:53 +0100

This is all about deciding how small a number is a good enough approximation to infinity.

Experience shows that whatever number we pick today it will be too small in not so many years time.

For an application to application communication it is less important if we undersized infinity. For a network infrastructure application it is incredibly difficult and expensive to fix an undersized approximation. Therefore we need to make the approximation much larger than we imagine in our wildest dreams.

-Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 3 Apr 2022 12:07:06 +0200

Stewart,

Your note seems to be highly polarized by one solution in mind. Let's be
careful not to overcook it.

Let me observe that if for someone 10 bits with MPLS data plane is not
enough then he could readily jump to 128 bits with v6 data plane and use
src ip address as slide ID (and no hardware change needed :).

Best,
R.

On Sun, 3 Apr 2022 at 09:48, Stewart Bryant <[email-masked]>
wrote:

> For an application to application communication it is less important if we
> undersized infinity. For a network infrastructure application it is
> incredibly difficult and expensive to fix an undersized approximation.
> Therefore we need to make the approximation much larger than we imagine in
> our wildest dreams.
>
> -Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 4 Apr 2022 06:55:09 +0100

Sent from my iPad

> On 3 Apr 2022, at 11:06, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Stewart,
> 
> Your note seems to be highly polarized by one solution in mind. Let's be careful not to overcook it. 

Robert,

No, I am not pushing any solution. I do not care which design is chosen, only that one is chosen that serves us well in the long term.

I was simply noting that there are four numbers in protocol design, 0,1,2, infinity, and that short term expediency can result in too small an approximation to infinity with painful consequences.

S