[spring] Comments on draft-filsfils-spring-sr-policy-considerations-01

[Rob Shakir <[e-mail]>]

(As an individual contributor)

Hi Authors,

Per my comments in SPRING at IETF 102, I have a number of comments/concerns
about the contents of this document. Please find them below. I look forward
to discussing them in more detail.

   - (2) What is the intention of the diagram shown in this section? It
   seems to be completely an implementation detail that an implementation has
   the "SRPM" that acts as a central resolution point. For instance, what
   should a reader learn from the fact that the SRPM is not a standard RIB
   resolution process? If there are suggestions that one wants this
   implementation - should there be some discussion of the complexity of this
   new API between say, the BGP daemon and a general RIB process?
   - (2) My general feedback on this section is that this is implementation
   discussion, that does not add to the IETF content that we are publishing
   within SPRING. Like we have had discussion of use case drafts, I think this
   is similar but from the implementor side. I'd like to discuss the value
   that this content has.
   - (3.1) I think that this section has some useful content, but it's
   buried by starting out by defining the algorithms. Why not make this
   section be focused towards the constraints that must be considered when
   calculating a SID stack for a particular path. i.e., the key points seem to
   be:
   - Use of the IGP metric as the metric for path optimisation is
      desirable, especially in constrained push or readable depth environments,
      because it allows the minimum number of deviations from the shortest path
      and therefore labels.
      - If a different metric is used, then this implies that every time
      that metric differs from the IGP metric, then this will result in
      additional SIDs.
         - There is no mention of flex-algorithm in this section. It seems
         relevant given that you can also mitigate the problem that is
trying to be
         solved here by having a set of prefix SIDs per metric.
      - It may be advantageous to sacrifice optimality of the path
      calculation solution by relaxing the optimisation constraints.
         - The draft should talk about the operational considerations here
         - i.e., it implies that you can actually tolerate the margin in the
         optimisation objective for the service.
         - The "just pick the best you can do within N SIDs" is dangerous,
         since it means that the network delivers a service that
*isn't* what the
         operator asked for - which may result in service degradation (e.g.,
         consider live/live where there is a maximum latency difference that is
         tolerable between the two feeds).
      - (3.2) I'm unclear of the value of this text. It seems to me that
   we're restating some of the optimisation objectives that are known for
   general TE (and, for example, are described by - say RFC3209). What is it
   that we're trying to communicate to the reader here -- can it be covered by
   "existing path calculation considerations, such as resource affinity
   [rfc3209] can be applied to the path calculation of SR paths"?
   - (3.4) I'm again going to question the value of this section -- it
   doesn't seem to give enough detail of the algorithm that you're proposing
   to be generally useful, and points out it is a node-local behaviour. If
   there's a desire to get to a common understanding of how to take a path and
   compress its SID stack, then let's write this out.
   - (4) See my comments on Section 2 of this document, why is describing
   how the interaction between different processes within what sounds like a
   single implementation something that we should publish within the IETF?
   - (5+5.1+5.2) The core point that seems to be being made here is that -
   within a single IGP area the head-end has all the visibility it requires;
   if there are multiple areas, there are ways that a head-end could get
   access to the areas that it is not part of (e.g., BGP-LS). Is anything more
   being said here? Do the implementation details that there are BGP-LS RRs
   actually matter?
   - (5.3) Similarly to the above, this seems to assume one particular
   mechanism of building a centralised system, that doesn't need any new
   extensions in the IETF. Is this something that we need to document?
   - (6.2) This section seems to imply that there can never be allocations
   from the SRLB that are not dynamically advertised via some other protocol.
   Is this really true?
   - (8) Given that there is a separate draft discussing this -- what is
   the motivation to have this in this document?

Thanks,
r.