Hi Rob, see inline. [MPLS WG added to discussion]
On Mon, Jul 21, 2014 at 7:38 AM, 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]. > Sri> You are correct. If a SID identifies multiple physical paths as in the case of Adj-SID identifying a bundle, then load balancing on that segment would be useful. When there is no information that every SID of a LSP maps to a single physical path, a load-balancing mechanism should be used for that LSP. I agree that today there is no mechanism to give such information about the mapping, so load balancing on every segment is useful. Whether that is achieved by using an EL per segment as described in sec 3.2 thereby resulting in a label stack of 3*#SIDs is something to be discussed. The draft lists the downsides of choosing that option. > > 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. > Sri> The draft does not estimate stack depth (without EL) since the depth is dependent on the degree of strict-hop traffic-engineering desired by the application. If you meant to say that the label stack is deep due to the application trying to make it as close to the desired physical path but you end up using the EL per segment anyways since there isn't information to determine for sure whether the mapping is to a single physical path, then yes the label stack will be very deep. > > - §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. > Sri> This is correct. In case of re-routing from ingress, the algorithm to compute EL depths have to be re-computed. If the re-route is like FRR via a bypass LSP, the PLR may want to insert ELs if load-balancing is desired along the bypass. > > 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? > Sri> Option in 3.4 runs into such complications in case of multi-area. All such cases have not been addressed yet for the option in 3.4 > > - 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. > Sri> The first goal of the draft was to list the various approaches. But the final goal is to come up with recommendations through the discussions on the various approaches. > > Cheers, > r. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > Thanks Sri
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
