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

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 02:09:39 +0000

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 <[email-masked]> On Behalf Of Rob Shakir
Sent: 25 July 2018 21:19
To: SPRING WG List <[email-masked]>; [email-masked]
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.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 22 Oct 2018 05:48:20 +0000

Hello All,

Version 2 of the draft has been submitted that incorporates updates to address comments from Rob and a few other editorial nits.

https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-02

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 19 October 2018 07:40
To: 'Rob Shakir' <robjs=[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: RE: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01

Hi Rob,

Thanks,
Ketan

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Shakir
Sent: 25 July 2018 21:19
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01

Hi Authors,

---

From: Rob Shakir <[email-masked]>
Date: Mon, 22 Oct 2018 21:50:12 -0700

Ketan, Authors,

Thanks for the update. Further responses are in-line marked [rjs].

My key feedback here is that I feel like we're not really on the same page
as to what this draft is trying to communicate. Perhaps if we agreed this,
then it'd be clearer what the right direction for the document is.

I'd really encourage the WG to read this doc and provide the authors with
feedback -- especially if you have an implementation, or are implementing
SR-TE Policy in your network.

On Thu, 18 Oct 2018 at 19:10 Ketan Talaulikar (ketant) <[email-masked]>
wrote:

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

[rjs] I don't think that the edits that are made to this section
particularly add anything. If the intention is the conceptual overview, I
don't understand why we refer to say, the "SRP process". Conceptually,
shouldn't this be describing interaction between functional blocks? i.e.,
we have a functional block in the architecture that is responsible for
learning candidate paths (it's an implementation detail from where...), and
selects the active path, installing it into the RIB or FIB.

If the intention is to have this be conceptual, my suggestion would be to
make the language refer to architectural concepts - rather than what seem
to be realisations of the idea, and to convert the diagrams into lists that
describe what each block is doing. Others may have thoughts on this too -
especially where they have other implementations.

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

[rjs] I don't think that we agree at all on whether this section is useful
in its current form. What is the message that we're trying to convey in
this section of the document? If it is that there are possible algorithms
that may be used by an operator dependent on their service, I'm not clear
that we need to document this. The value to me *would be* that we cover
some of the caveats of calculating policies that are specific to SR --
i.e., SID stack depth being something that is influenced by divergence from
the shortest path, and the fact that we might need to sacrifice the optimal
solution to pathing based on these constraints, then I think it'd be
useful. The current text does not get this across clearly.

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

[rjs]: Again, we might have to agree to disagree here. I did not make an
assertion that someone was familiar with RSVP-TE, but that they were
familiar with *TE* -- there are networks that meet these constraints that
do not use SR or RSVP-TE.... Again, I'd find it very useful to understand
what the authors are trying to communicate in this section. If it's that
there are particular trade-offs, sure, let's find new wording -- but if
not, then I'm not clear why SPRING needs to standardise an incomplete list
of optimisation criteria.

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

[rjs]: If there's really value in this high-level description (I'm not sure
I agree...) -- it seems like then restructuring this section to write out
the algorithm then use it to illustrate how it operates on a network after
this.

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

[rjs]: In my view, this example would be best _as succinctly_ as possible
to demonstrate the preferences in the actual draft. It seems to me that the
explanations themselves are quite wordy to make a couple of clear points:

 - BGP path selection is unaffected by SR-TE policy.
 - If a protocol does not make its own path selection, then SR-TE policy
attributes are considered to differentiate between them.
 etc.

Ideally, this should be clear in the policy architecture draft itself. If
it can't be made clear, then I think we should seriously consider whether
we have the right level of complexity here.

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

[rjs]: For the above points -- I think we've clearly seen in the WG and
IESG that there is not a huge amount of appetite to publish use case
drafts. From an operational perspective, I also don't really find these
sections that useful since they don't really give me enough information to
be able to figure out an implementation. I'd be interested whether the
working group thinks that they are sufficiently of interest to include in
this document.

Cheers,
r.

> Thanks,
>
> r.
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Przemyslaw Krol <[email-masked]>
Date: Tue, 30 Oct 2018 09:44:46 -0700

Howdy,

I tend to agree that in the current shape,
draft-filsfils-spring-sr-policy-considerations-02
<https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-02>
document
attempts to cover architectural, operational and use-case aspects which may
not be optimal. To that point, if we can agree whether it is supposed to be
a more operationally-focused extension to its
parent draft-ietf-spring-segment-routing-policy draft or more of a use case
overview, we could make relevant adjustments/augmentations to accommodate
that. I personally see a value in both options but based on Rob's feedback,
the latter one may not be suited for SPRING WG.

thanks,
pk

On Mon, Oct 22, 2018 at 9:50 PM Rob Shakir <[email-masked]> wrote:

>> *[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.*
>>
>
> [rjs]: If there's really value in this high-level description (I'm not
> sure I agree...) -- it seems like then restructuring this section to write
> out the algorithm then use it to illustrate how it operates on a network
> after this.
>
>
>>
>>    - (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.*
>>
>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]