Hi, > We already know how to encode label offset. > > Are you referring to Segment Index as offset of label base ? >
No. SI is already defined for different use. I am describing general concept how we could indicate in 5 bits the number of significant (for forwarding) bits in MPLS label. > Using the same encoding you can treat offset value as number of > significant bits within the 20 bit label. > > Could you give an example of lookup and forwarding structure for your > label range/label prefix ? I see something possible but I still have an > issue with the lookup structure. > The lookup is trivial as there is no LPM needed. You simply do partial match on your mpls labels in the LFIB. thx, R. > > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 13:24 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Kireeti Kompella; spring@ietf.org; > draft-kini-mpls-spring-entropy-la...@tools.ietf.org; m...@ietf.org > *Subject:* RE: [spring] SPRING MPLS and Entropy Label > > > > 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. > > > _________________________________________________________________________________________________________________________ > > 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
