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

[Przemyslaw Krol <[e-mail]>]

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]> 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]>
>> 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]
>


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