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

["Clarence Filsfils (cfilsfil)" <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]> 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)
>         <[e-mail] <mailto:[e-mail]>> 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:____
> 
>                   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:
> 
>           - 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/spring
> 
> 
> 
>     -- 
>     Przemyslaw "PK" Krol |	 Strategic Network Engineer	ing
>     |[e-mail] <mailto:[e-mail]> 	
> 
> 
> 
> -- 
> Przemyslaw "PK" Krol |	 Strategic Network Engineer	ing |[e-mail] 
> <mailto:[e-mail]> 	
> 
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>