Subject: [spring] Roman Danyliw's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 10 Apr 2019 12:51:10 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-spring-segment-routing-mpls-19: No Objection

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-segment-routing-mpls/

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

(1) Section 1.  Shouldn’t RFC8402 be “[RFC8402]”?

(2) Section 1.  First use of the acronym, but above there was no “Segment
Routing (SR)”.

(3) Section 2.1.  Editorial.  s/,…,etc/, etc./

(4) Section 2.4.  The variable name in the text is “Size” and “size” in the
equation.  They should be consistent.

(5) Section 2.4.  Per Step #5 of the collision resolution procedure, could you
please clarify what is a “non-zero algorithm”?

(6) Section 2.5.1.  Could you please clarify what “better administrative
distance means”.  Per the tie-breaking rules above, I assume you mean it is a
lower administrative distance.

(7) Section 2.5.1, for the sub-bullets under “The fields of each FEC are
encoded as follows”, consider adding periods to the first two bullets:

s/significant bits are set to zero/ significant bits are set to zero./

s/the numerical value for IPv6/the numerical value for IPv6./

(8) The Security Considerations references [RFC8402] to lay out the assumed
trust model and a few of the possible implications (malicious looping, evasion
of access control, hiding of the source of DoS attacks) if this model is
violated.  I concur on the language in the reference.  I believe there are a
few more things to explicitly point out:

** Per the implications, routing traffic through an observation point
controlled by the attacker is another key privacy and integrity concern.

** Per the already stated implication, “malicious loop” feels too soft as the
overall availability of the network can be affected (e.g., loops, slowing
traffic down).

FWIW, I’m not raising this to a DISCUSS because there is no normative language
to address these issues, only additional proposed cautionary language of the
threat.