[spring] Deborah Brungard's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)

["Deborah Brungard" <[e-mail]>]

Deborah Brungard has entered the following ballot position for
draft-ietf-spring-problem-statement-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The main focus of my discuss are the disparaging comments on MPLS and
RSVP-TE for the apparent purpose of justifying the need for SPRING. The
statements in Section 3.3, paragraph 2, are not accurate. As an IETF
document, even though Informational, it harms another IETF technology.
This paragraph needs to be removed. Very disappointing to see this unfair
comparison of centralized control vs. distributed control in an IETF
document.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As others commented, the document is missing the identification of key
requirements, “MUST”.

The Abstract’s last sentence and Section 3.1 say the objective is to
address use cases where removal of signaling and path state in the core
is a requirement. Yet, 3.1.1 and 3.2 only say it “SHOULD” work without
the addition of a signaling protocol. If any requirement is a “MUST”, it
would seem this requirement needs to be a “MUST”. There is no need to
make statements that RSVP-TE is complex and not scalable to justify. Just
say simply you do not want to use a distributed control plane for your
problem. This is not the first time for this requirement. As for no need
for state at transit nodes, it’s not quite true, as there probably is a
need to map the SR “label” to a label stack instruction and a forwarding
instruction. Hint, the “MUST” would be similar to MPLS-TP requirements
[RFC5654], “SPRING MUST support the capability for network operation
without the use of any control-plane protocols.”

The interchangeability of the terms “SPRING” and “segment routing” are
confusing. I think if you would clarify the control model, it may help
with the definitions.

Section 1: “allow optimal virtualization by putting policy state in the
packet header” and “policy is completely virtualized away from midpoints
and tail-ends” doesn’t parse. By definition, it’s not “virtual” if it’s
in the packet header. Seems to be a marketing statement, not a technical
requirement.

Section 2: It seems the document is already defining the solution for
IPv6 segment routing. It would help to say what is the actual requirement
– packets should be forwarded transparently through a legacy v6 network?
Identifiable by SPRING-capable devices?

Section 3: These use cases appear to be defining desired capabilities for
a controller, not SPRING. It would be helpful to clarify what are the
requirements for the dataplane’s “simple support” e.g. section 3.2 on FRR
appears to be requirements on the controller, not the dataplane. And
3.3.1.2.1 on a capacity planning process in the controller.

Section 3.3 Traffic Engineering: While this is labelled Traffic
Engineering, the examples are only on traffic placement. Only a subset of
Traffic Engineering. The other key aspect of TE is resource reservation.
The text should clarify and refer to traffic placement and not the
general term “TE”.

Section 3.3.1.1 are all load balancing examples – not “TE”. While valid
and useful, should not confuse the reader that it is TE.

Section 3.3.1.2.2 I don’t think everyone would agree that a stateful PCE
is an SDN controller. I think there is some confusion, especially the
next paragraph, on a controller vs. orchestrator. There’s a lot of
marketing hype in this section, best would be to say something generic
and what it is doing (technically) e.g. “centralized-based optimization”
(next paragraph). The requirements in this section seem to be generic,
not “SDN”. I don’t understand the last one, “no delay is introduced to
programming the midpoints and tail-end along the path”. Compared to what?
If a change, is there a change for traffic placement within the network?
Before a change, there also is delay - the controller usually will sync
with the current state of the network. This sounds marketing “highly
responsive to change”. State the requirement for SPRING.

Missing requirements: OAM, any requirements on limiting the increased
headers and overall frame size?