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
