Robert, Talking MPLS, I don’t see a way to use MPLS label “prefix” … this is a discussion we already had together. I think you are trying to sell IPv6 SR that I will unfortunately not buy again ☺
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, July 24, 2014 08:48 To: Kireeti Kompella Cc: m...@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-la...@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label Hi Kireeti, I quite disagree about the more state argument. If you treat mpls label as prefix with mask which is all this boils down to there is no more state either in data or control plane. As to the point of not perfect load balancing it all depends on your hash function. If you always advertise at least as big block as you have max parallel links on any interface you should be fine. Best , R. On Jul 24, 2014 2:12 PM, "Kireeti Kompella" <kire...@juniper.net<mailto:kire...@juniper.net>> wrote: Hi Robert, On Jul 24, 2014, at 03:21 , Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Therefor an alternative of using any form of entropy labels in data plane all together would be to allocate a SID blocks (say 64 or 128 wide) and allow SPRING header imposition to use such pools of SIDs per group of flows to effectively allow for efficient load balancing in the network. We’re rehashing (pun unintended) the entropy label discussion. Before we settled on entropy labels the way we did, we discussed advertising label blocks in LDP. There are two problems: a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more state in the forwarding plane (and to some extent, in the control plane). b) if you use small blocks, you get uneven load balancing; if you use large blocks, you blow up the state more. Kireeti _________________________________________________________________________________________________________________________ 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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
