Hi, That is also solved problem ;)
We already know how to encode label offset. Using the same encoding you can treat offset value as number of significant bits within the 20 bit label. We do not need to extend this to current label use cases. Hence there is no issue with backwards compatibility. Very basic and simple ;) Cheers, R. On Jul 24, 2014 7:05 PM, <stephane.litkow...@orange.com> wrote: > Robert, > > > > From a practical point of view , how do you represent such MPLS label > range with a prefix ? > > [70, 170] > > [17, 69] > > > > MPLS was not designed for “label aggregation” scheme … > > Or we need to change of labels are allocated from the label space for all > label consumers … to permit this aggregation. > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 12:54 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Kireeti Kompella; m...@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-la...@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > 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. > > > > _________________________________________________________________________________________________________________________ > > 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
