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

[[e-mail]]

Joel,

Please see inline

> From: mpls <[e-mail]> 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
> [e-mail]
> 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.