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

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Rob,

Thanks a lot for your detail review and comments. I will work on them and get back.

Thanks,
Ketan

From: spring <[e-mail]> On Behalf Of Rob Shakir
Sent: 25 July 2018 11:49
To: SPRING WG List <[e-mail]>; [e-mail]
Subject: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01

(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.