Adding the MPLS wg to this discussion. [Apologies for the spam.]
r. On 21 Jul 2014, at 10:38, Rob Shakir <r...@rob.sh> wrote: > 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
