Stephane, This has NOTHING TO DO with IPv6. I am not even sure based on what you draw such strange conclusion ....
I am talking pure about MPLS data plane (even without any IP above) and how we can solve the load balancing problems. At min I expect for any discussion to be valid to discuss and compare all options. Note also that SPRING does not use LDP so I am much less interested in solving the LDP load balancing issues. Rgs, R. On Thu, Jul 24, 2014 at 6:46 PM, <stephane.litkow...@orange.com> wrote: > 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 J > > > > *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> wrote: > > Hi Robert, > > > > On Jul 24, 2014, at 03:21 , Robert Raszuk <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
