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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
