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