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

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

Hi Rob,

Thanks for your review and comments. Please find inline below our responses.

Will work on posting an update to the draft to incorporate your comments.

Thanks,
Ketan

From: spring <[e-mail]> On Behalf Of Rob Shakir
Sent: 25 July 2018 21:19
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?
[KT] We will clarify in the text that the section provides a conceptual overview of components/functionality that work with each other to implement SR Policy on a headend. The intention is not to define APIs between the blocks since those are implementation details. We have several drafts related to the SR Policy functionality – besides the architecture draft, there are extensions to BGP (BGP-SRTE & LS), PCEP then we have Yang model. This draft puts these blocks into reference so implementers get an idea of the functionality that maps to say BGP and the SR Policy processes (e.g. draft-ietf-idr-segment-routing-te-policy).

  *   (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.
[KT] There is a difference between documenting implementation details and providing a conceptual overview of the implementation aspects. Especially when defining an architecture which involves multiple protocols and functional blocks. I find it valuable as an implementer myself.

  *   (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.
[KT] We will put a forward reference to the Flex Algo section here.

     *   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).
[KT] We will add text clarifying this aspect. However, the point is also that the operator may be OK with the “best possible” and so such an option may be useful in some deployments.

  *   (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"?
[KT] We do not assume that anyone that is deploying SR Policies is familiar with RSVP-TE. RFC3209 does cover resource affinity but not the others. Some of the constraints are unique to SR. Hence, there is a value in specifying the available constraints.

  *   (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.
[KT] Agree that this is a node local behavior. However, the high level description does indicate how an implementation could go about determining a path to a SID in an efficient manner.

  *   (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?
[KT] These examples are important to illustrate how the candidate path selection tiebreaker rules work in different conditions. The interactions are also valuable to understand the selection which happens say within BGP (based on its best path) for BGP-SRTE and the selection that then happens at SR Policy level. This section was originally placed in the Appendix of the SR Policy Architecture draft since the candidate path selection tiebreaker rules were specified in that draft. Later was move to this informational draft.

  *   (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?
[KT] The intention is to provide guidance for some of the deployment options for achieving this functionality.

  *   (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?
[KT] We explain while taking an example of a mechanism based on IETF standards that is available for operators looking to deploy this model.

  *   (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?
[KT] I don’t believe this was the intention. We will clarify this in the text.

  *   (8) Given that there is a separate draft discussing this -- what is the motivation to have this in this document?
[KT] This section gives and overview of the proposal with an example of optical circuit. It also clarifies that the concept described is applicable not just for optical links but in general to other types of layer 2 circuits and tunnels as well. The draft-anand-spring-poi-sr goes into the details of the use-case, protocol mechanism and extensions specifically for optical networks only.
Thanks,
r.