|
Hi all, I have read the Segment Routing Problem Statement and Requirements draft and I have a couple of comments on it.
Editorial: The Abstract states that “Multicast use-cases and requirements are out of scope of this document”, but this (or equivalent) statement
does not appear anywhere in the body of the document. IMHO and FWIW this contradicts the last para in Section 4.3 of RFC 7322 that states that “the RFC should be self-contained as if there were no Abstract”. Technical: The draft requires, in Section 2, that “The SPRING architecture SHOULD leverage the existing MPLS dataplane without any modification...”.
In addition, in Section 3.3 it requires that "The SPRING architecture SHOULD allow incremental and selective deployment without any requirement of flag day or massive upgrade of all network elements"
. My reading (FWIW) of these two requirements is that SPRING with MPLS dataplane
should work on existing MPLS forwarding HW. If this understanding is correct, it is in potential conflict with another requirement formulated in the Section1 of the draft: "The SPRING architecture SHOULD allow optimal virtualization:
put policy state in the packet header and not in the intermediate nodes along the path".
This conflict stems from the following (admittedly, naïve) observation:
1.
The policy state representing the desired source route must be pushed in its entirety onto the packet by the source (here source is interpreted in the same way as in the draft itself) and must be parsed by all
the transit nodes.
2.
The amount of the policy state
grows (linearly?) as the number of elements in the source route selected by the packet. In particular, the policy representing
a strict route could be potentially quite large.
3.
In the nodes that use hardware-based forwarding, the size of the policy state that can be pushed and parsed with the expected throughput is
inherently limited. These limits differ for different implementations but
they usually cannot be exceeded without replacing the forwarding hardware.
4.
Passing “offending” packets for software handling could result in dramatic decrease of throughput. S In the case of the MPLS dataplane, the policy state is expressed as the MPLS label stack where each segment is represented by a label stack entry. AFAIK, existing (and probably future) forwarding HW that supports
MPLS is inherently limited (the limits differ for different implementations) both regarding the
number of labels that could be pushed on the packet, and regarding the total depth of the label stack that it can parse.
Note: The limit on the
number of labels that can be pushed on a packet by forwarding HW is obvious. The limit on
that can be parsed becomes essential in the scenarios when ECMP is used, because:
•
As per RFC 7325, Section 2.4.5.1., “The most entropy is generally found in the label stack entries
near the bottom of the label stack (innermost label, closest to S=1 bit)”
•
As per Section 2.4.5.2 of the same RFC, “Inspecting the IP payload provides the most entropy in provider networks. The practice of looking
past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs”.
•
Both these methods (hashing the label stack and hashing IP header) obviously
require parsing the entire label stack. The limits of forwarding HW could be considered an implementation problem,
were it not for the draft requiring (and I fully agree with validity of this requirement)
that SPRING could be used on existing MPLS-capable HW. From my POV the document should at least explicitly acknowledge this conflict
as part of the SPRING problem statement. Preferably it should also include some guidelines for its resolution:
•
One possibility that comes to mind could be a requirement to provide the information about hardware-specific limitations to traffic-engineering entities in order to avoid computation of paths that do not meet HW-imposed
constraints.
•
Another possibility is to clearly indicate that loose route options are preferable for using with SPRING. To the best of my understanding this could be translated into a requirement for a new type of constrained
path computation algorithms that yield loose (rather than strict) routes Of course there may be other (and, possibly, better) ways to resolve this conflict. But, from my POV,
if it is not acknowledged explicitly, its resolution becomes much more problematic. Hopefully, these LC comments would be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@xxxxxxxxxxx -----Original Message----- The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'SPRING Problem Statement and Requirements' <draft-ietf-spring-problem-statement-06.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2016-01-05. Exceptionally, comments may be sent to
iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed' and therefore it is not limited to the originator of the packet (i.e.: the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ spring mailing list |