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 :)
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. IMHO, I would be in favor of doing nothing if all vendors can publicly confirm that their current generation of HW are able to inspect between 10/15 labels :) Otherwise reusable EL and even EL at top of the stack sounds good to me. EL at top of the stack may make some MPLS people crazy, but I personally found this kind of forwarding straightforward compared to reusable EL (I like it also). EL at top of the stack may be compared to a MPLS router alert label at top of the stack ... We may also need to deal with cases where some SPRING nodes are not ELC on the transit path, do we want to loose the EL or just try to avoid the non ELC node(s) by reinserting ELI/EL at a position it could be reused further in the path on the next ELC capable SPRING node. Anyway as I said at the beginning, unfortunately for us (Service Providers), the technical solution is at more than 80% a vendor discussion ... Thanks again for bringing this back on the table :) Best regards, Stephane -----Original Message----- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir Sent: Monday, July 21, 2014 10:38 To: spring@ietf.org Cc: draft-kini-mpls-spring-entropy-la...@tools.ietf.org Subject: [spring] SPRING MPLS and Entropy Label Hi SPRING, draft-kini. authors, I have a few comments on the discussion within this draft - and a quick question on the intention around the document. - I feel that it would be useful to provide some clarification as to where we expect entropy to be required for load-sharing in the draft. The current wording (to me) could be read to say that where Adj-SID is used, then there is no requirement to consider placement for EL since there will be no load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in draft-filsfils-spring-segment-routing-04), or the underlying transport for an IGP adjacency can be multi-path (e.g., an aggregated Ethernet link) this is not true unless a head-end PE can guarantee that a particular adjacency is made up of a transport that has only 1 path (i.e., explicitly requires no load-balancing). I'm not sure how the iLER would actually determine this, short of the definition of new per-adjacency advertisement capabilities. Even if it were able to, then it seems the result is very likely to be that an approach that requires per-hop entropy labels to be injected is going to guarantee label stack depth >= 3*[number of path SIDs]. I think that the above means that the current draft under-estimates the depth of the stack when considering an EL per tunnel (§3.2), which might amplify some of the concerns raised for this option. - §3.4 - I am not clear how we would really implement this option. If we learn midpoint capabilities, and then tune our placement of the EL based on these, then it seems like the only viable approach is really to consider _all_ midpoints, and tune the placement according to the "shallowest" midpoint in the network. This is because, whilst we might expect that there is routing via some particular path, this might change if there is ECMP between mid-points nodes where some paths have different capabilities than others, and equally might change whilst re-routing occurs. In terms of discovery of the capabilities of a mid-point -- do we need to consider how, in a multi-area network, we discover the capabilities of a mid-point which might not have information about it leaked between areas? - Finally, it'd be good to determine what the intention of the authors for this document is. Do we expect that we make a recommendation as to what equipment vendors who are going to support SR-MPLS should optimise for? At the moment, the document is good at classifying the different approaches that _could_ be taken, but potentially requires an operator/vendor to consider optimisation for both a) reading very deep into the stack when acting as an LSR, b) pushing very deep stacks when acting as iLER, c) potentially implementing more complex swap() operations, whereby some reshuffling of the EL is required. My feeling is that it would be very useful for this document to be able to make a clear recommendation as to which of these approaches should be optimised for, and hence we should debate their technical efficacy. It'd be good to understand whether the authors are intending to do this, or rather classify the approaches. Cheers, r. _______________________________________________ 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
