Comments inline:
On 20/11/2017 23:36, Zafar Ali (zali) wrote:
Hi Adrian,
Some comments are provided in-line.
Please note that, we all want to let this lingering tread die and follow-up on
the next steps noted during this email exchange. I will be happy to have a
webEx call and discuss it further, offline.
No, some of us would like to resolve the issue since it raises
interesting architectural issues with SR.
Thanks
Regards … Zafar
On 11/18/17, 9:08 AM, "Adrian Farrel" <adr...@olddog.co.uk> wrote:
<snip>
>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
>>> Architecture, highly unscalable and complicated to implement.
>>
>> [JD] Do you have any evidence to justify any of your assertions, above?
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:
>
> • The transit node needs to be able to recognize the special label,
read
> the SR Path Identification label and update the counter against
such
> “states”.
Possibly worth noting that existing devices are capable of maintaining many
counters and updating them at line speed.
Several people have noted that ipfix is a process used for accounting in
networks. That approach may have to find the bottom of stack and then match the
packet that follows.
Other approaches (e.g., to ECMP) involve finding the bottom of stack and
hashing on the header of the payload.
Some hardware cannot perform either mechanism. This usually results from a
trade between low cost, high performance, and features. Generally you can't
have all three.
The question is not about if the hardware is able to perform such operations
but regarding breaking the very beauty of SR – no states at the transit/ egress
nodes.
Well, it's more about minimum state. Zero state at egress only applies
for some classes of traffic.
Whilst the intent is for zero state in the transit nodes, this cannot be
at the expense of not being able to manage the network.
In the context of label stack size explosion, the draft also talks about needs
to break an SR Path into sub-paths – thereby creating yet additional states in
the network for accounting reasons (see more detail on this in the following).
Furthermore, SR-MPLS is designed for SDN – the architecture calls for
simplification of the network not adding complexity in the network fabric.
No. SR is not and never has been solely for SDN. On day one there was
the concept that the ingress could compute the path.
Please also note that a network may have a large number of SR Path, thereby
creating another dimension for scaling limitations.
The proposed procedure also does not work for node protection in the network.
The draft essentially calls for ALL nodes to implement procedure proposed in
the document; I am quoting from the draft.
“When using extensions
described in this document for traffic accounting and with node-
protection enabled in the network, it is RECOMMENDED to make sure all
the nodes in the network support the extension.”
If all nodes support this (as recommended), then all nodes support it so
it works during re-route. Indeed this is more important during reroute
since that is when you expect hot spots to form.
The dynamic counter concept is no different to dynamic counters needed
in IPFIX, so it is a concept that a lot of routers already have.
<snip>
> • The draft proposes to push (up to) 3 Labels for each segment in the SR
> Path. That means that label stack is increased up to 3x times!
This is a
> serious a scaling issue.
Maybe there needs to be a change in the text, but what is required is
three labels per ingress being monitored. This is something where SR
really introduces confusion for the OAM systems and we need to work this
through. In "classic" MPLS each label represented a layer in the
network. SR breaks that model, with sadly little comment on this in the
architecture. So we do need to think this through a bit, and understand
whether we need to have a rule stating that there can only be one source
identifier in the stack - meaning that SI can only be BoS and that if
you want to record the source when you introduce a new layer you need to
terminate the old stack and start a new one.
John asked for evidence and you provided a misunderstanding or misreading
of our draft.
The document proposes adding 2 or 3 labels per SR Path (noting as John did,
that this is our own term).
That is not what you say, so perhaps you could retract or provide a pointer
to the text.
Thus, "increased up to 3x times" applies only with the single case where
the imposed label stack has exactly one label *and* the three label option is applied.
So, while what you say is true, it is clearly (and wilfully?) exaggerating the severity
of impact, and it is doubtful that 4-label stack is actually a problem.
There are many scenarios that will require SR-Path-Stats Labels (up to 3 labels) to be present multiple times in the label stack. These scenarios are not uncommon. The following scenarios as noted in the draft.
“The head-end node SHOULD insert the SR-
Path-Stats Labels at a depth in the label stack such that the nodes
in the SR path can access the SR-Path-Identifier for accounting. The
SR-Path-Stats Labels may be present multiple times in the label stack
of a packet.”
“It is possible to partially deploy this feature when not all the
nodes in the network support the extensions defined in this document.
In such scenarios, the special labels MUST NOT get exposed on the top
of the label stack at a node that does not support the extensions
defined in this document. This may require multiple blocks of SR-
Path-Stats Labels to be inserted in the packet header.”
• The controller needs to keep track of transit node capability and
> push the additional per-path labels, accordingly. I.e., the
controller
> also needs to maintain such information for the transit nodes.
In most cases, the controller/ingress only needs to care about the
capabilities of the egress nodes. That is, if the special purpose label reaches
the top of the stack it has to be able to handle it.
The only time when the transit node issue arises is when there is a small
RLD. That information may need to be known by the controller to enable correct
ECMP behavior, and it is distributed in the IGP.
If there is a desire to enable accounting at transit nodes with a small RLD
then the Path ID can be inserted higher up the stack and *that* means that the
controller has to be sensitive as to where in the network the special purpose
label will rise to the top of the stack.
It seems to me that:
- Controllers are not particularly resource constrained: adding a flag per
node
(or even per link!) would not break any scaling behavior.
- Adding another flag to the IGP alongside the RLD is not significant
scaling issue.
The comment here was not so much related to scaling but was for adding complexity to the controller/ ingress node.
As far as I can tell the complexity is exactly the same as the
complexity needed to insert the EL. Indeed you probably insert the
labels at the same time,
and I suppose we should consider having a combined EL/SI SPL.
As you noted above and in the draft, controller/ Ingress node needs to worry
about the following cases every time a path needs to be computed (quoting some
of the cases from the draft).
“When the head-end node
inserts the SR-Path-Stats labels in the label stack, the place in the
stack is decided based on whether the node where the special label
gets exposed is capable of popping those labels.”
“While inserting the SR-Path-Stats labels, the head-end router MUST
ensure that the labels are not exposed to the nodes that do not
support them. “
“Because it is necessary that the SR-Path-Stats labels are removed
when they are found at the top of the label stack, the node imposing
the label stack (the ingress) must know which nodes are capable of
stripping the labels.”
In RLDC limitation cases, “To support traffic
accounting in such cases it is necessary to insert the SR-Path-Stats
Labels within the Readable Label Stack Depth Capability (RLDC) of the
nodes in the SR path.”
“The head-end node SHOULD insert the SR-
Path-Stats Labels at a depth in the label stack such that the nodes
in the SR path can access the SR-Path-Identifier for accounting.”
“The special labels MUST NOT get exposed on the top
of the label stack at a node that does not support the extensions
defined in this document.”
“If the egress has not indicated that it is capable of removing the
SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of
the label stack. In this case the SR-Path-Stats Labels SHOULD be
placed at a point in the label stack such that they will be found at
the top of stack by the latest node in the SR path that is capable of
removing them. “
“SR paths may require large label stacks. Some hardware platforms do
not support creating such large label stacks (i.e., imposing a large
number of labels at once). To overcome this limitation sub-paths are
created within the network, and Binding-SIDs are allocated to these
sub-paths.” … which means controller/ ingress software need to also create/
install sub-paths.
<snip>
These look like exactly the same considerations needed for EL.
Now we need to consider what happens if we have a node that does not
support
the required depth. In both cases the result is the same - the feature
is not
supported, but the packet is correctly forwarded. In this case it will mean
that there is an unmonitored part of the network. That is not so bad in
that
you can at least figure out the region in the network where this happened.
In the case of the same limitation and the EL system the result may well be
a traffic overload as there is little entropy in an SR label stack.
- Stewart
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
