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

From: Przemyslaw Krol <[email-masked]>
Date: Tue, 6 Nov 2018 10:23:40 +0700

Greetings,

Would it be possible to close this (scope of this document) while in BKK?
We could then take the draft editing work offline and come back with it
before PRG. Hopefully this would let all involved parties be clear on the
purpose of this document and make soliciting feedback easier.

thank you,

On Tue, Oct 30, 2018 at 11:44 PM Przemyslaw Krol <[email-masked]> wrote:

> 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:
>
>> 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
>>>
>>
>
> --
> Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]
>

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

---

From: "Clarence Filsfils (cfilsfil)" <[email-masked]>
Date: Tue, 6 Nov 2018 11:56:12 +0100

Prem,

Ketan can call me in when you meet locally and I can help remotely.

Cheers,
Clarence

On 06/11/2018 04:23, Przemyslaw Krol wrote:
> Greetings,
> 
> Would it be possible to close this (scope of this document) while in 
> BKK? We could then take the draft editing work offline and come back 
> with it before PRG. Hopefully this would let all involved parties be 
> clear on the purpose of this document and make soliciting feedback easier.
> 
> thank you,
> 
> 
> 
> 
> On Tue, Oct 30, 2018 at 11:44 PM Przemyslaw Krol <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Howdy,
> 
>     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
> 
>         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] <mailto:[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./*
> 
> 
>         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:____
> 
>                   o 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.____
>                   o 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./*____
> 
>                   o 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:
> 
>           - 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.____
> 
>             [email-masked] <mailto:[email-masked]>
>     Przemyslaw "PK" Krol |	 Strategic Network Engineer	ing
>     [email-masked] <mailto:[email-masked]> 	
> 
> 
> 
> -- 
> Przemyslaw "PK" Krol |	 Strategic Network Engineer	ing [email-masked] 
> <mailto:[email-masked]> 	
> 
> 
>