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

[Przemyslaw Krol <[e-mail]>]

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]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [e-mail]