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

Reply via email to