So let's find the best compromise ... but we can't stay stuck ...
-----Original Message----- From: Xuxiaohu [mailto:xuxia...@huawei.com] Sent: Tuesday, July 22, 2014 10:39 To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir Cc: m...@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-la...@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label I personally don't believe there is any possibility of making that recommendation at present since each option is only applicalbe in a certain condition. Best regards, Xiaohu ________________________________________ 发件人: spring [spring-boun...@ietf.org] 代表 stephane.litkow...@orange.com [stephane.litkow...@orange.com] 发送时间: 2014年7月22日 22:27 收件人: Rob Shakir 抄送: m...@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-la...@tools.ietf.org 主题: Re: [spring] SPRING MPLS and Entropy Label > It sounds like you'd be supportive of asking the authors to extend > this draft to making a recommendation? :-) Completely right :) -----Original Message----- From: Rob Shakir [mailto:r...@rob.sh] Sent: Tuesday, July 22, 2014 10:23 To: LITKOWSKI Stephane SCE/IBNF Cc: spring@ietf.org; draft-kini-mpls-spring-entropy-la...@tools.ietf.org; m...@ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label Hi Stephane, On 21 Jul 2014, at 22:52, <stephane.litkow...@orange.com> <stephane.litkow...@orange.com> wrote: > Hi Rob, > > Many thanks to raise this important subject back on the table. > Entropy label in SPRING is mainly a matter of what are the current > capabilities of our favorite vendor's current HW ... Unfortunately, I > think we are touching something quite "secret" and vendors would not > share their issues publicly :) There are two things that we need to achieve w.r.t SR/MPLS and EL from my perspective: 1) How do we exploit EL with *today's* hardware such that SR LSPs can be efficiently load shared? 2) Going forward, which of the approaches that this draft identifies for dealing with deep label stacks produced by SR/MPLS should we optimise for? So, yes, I agree that there's something around current capabilities that we need to figure out - but equally, I'd like to visit question (2), such that we can see whether the WG thinks that it is possible that we can reach a recommendation and hence future hardware revisions can potentially focus on optimising for one particular SR/MPLS + EL approach. > I think some options may also introduce some "HW capability" issues : > - reusable EL and EL top of the stack : need multiple MPLS operation > , so it may require forwarding feedback loops on some HWs reducing the > forwarding capacity > > Personally, I don't like (hate :) ), the multiple EL/ELI (at each tunnel > level or at specific point of insertion) because it would again reduce the > available MTU for the customer jumbo frames. ACK - this is one of the reasons that I would like to understand the author's intentions on this draft. At the moment, the draft is a taxonomy of the approaches, but rather stops short of making any recommendations. It sounds like you'd be supportive of asking the authors to extend this draft to making a recommendation? :-) Cheers, r. _________________________________________________________________________________________________________________________ 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 _________________________________________________________________________________________________________________________ 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
