> We already know how to encode label offset. Are you referring to Segment Index as offset of label base ?
> 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. 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<mailto: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> [mailto: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<mailto:m...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; draft-kini-mpls-spring-entropy-la...@tools.ietf.org<mailto: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<mailto: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 ☺ From: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] On Behalf Of Robert Raszuk Sent: Thursday, July 24, 2014 08:48 To: Kireeti Kompella Cc: m...@ietf.org<mailto:m...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; draft-kini-mpls-spring-entropy-la...@tools.ietf.org<mailto: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. _________________________________________________________________________________________________________________________ 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
