Hello everyone,
concerning the first comment: I don't think that a document needs to
explicitly specify all out-of-scope topics in order to be
self-contained. So not exactly a contradiction, just maybe confusing.
Concerning the second comment: This is just another example of the
frequent misunderstanding, that typical use cases for segment routing
would required a lot of explicit path information.
There's more than enough analyses that show that in typical carrier
topologies traffic engineering with segment routing can achieve almost
everything with just adding one or maybe two segments (labels).
However those analyses are not neccessarily public, nor would I think an
Internet Draft or RFC would be a good place for this kind of information.
Maybe we should add a section to draft-ietf-spring-segment-routing-mpls
saying that the operators are responsible for understanding the
capabilities of the hardware they use, and to consider those when
setting up their specific traffic-engineering tricks.
Best regards, Martin
Am 05.01.16 um 20:59 schrieb Alexander Vainshtein:
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 heade/r /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: [email protected]
-----Original Message-----
From: spring [mailto:[email protected]] On Behalf Of The IESG
Sent: Tuesday, December 15, 2015 8:11 PM
To: IETF-Announce
Cc: [email protected]; [email protected];
[email protected]; [email protected];
[email protected]
Subject: [spring] Last Call:
<draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement
and Requirements) to Informational RFC
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
[email protected] <mailto:[email protected]> mailing lists by 2016-01-05.
Exceptionally, comments may be sent to [email protected]
<mailto:[email protected]> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
