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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 10 Apr 2019 14:51:31 -0700

Warren Kumari 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:
----------------------------------------------------------------------

Thank you for a well written / easy to understand document.

I have a few suggestions / nits. Please note: If the WG has already discussed
these, and come to other decisions, I'm fine with that...

1:  "In order to have a node segment to reach the node, a network operator
SHOULD configure at least one node segment per routing instance, topology,
algorithm. " Perhaps: "segment per (routing instance, topology, algorithm)."
(or "set of ..", or "combination of..." or something - not quite sure how best
to word, but this seems slightly confusing).

2:  "If the SRGB of a node does not conform to the structure specified in this
section or to the previous two rules, then this SRGB MUST be completely ignored
by all routers in the routing domain and the node MUST be treated as if it does
not have an SRGB." Shouldn't this be logged somewhere?

" The rules applicable to the SRGB are also applicable to the SRLB, except rule
that says that the SRGB MUST only be used to instantiate global SIDs  into the
MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB
and/or SRLB is a matter of future study" 3: I think there is a missing word(s)
between 'except rule' - perhaps "for the"? 4: Missing period.

5: "For the purpose of incoming label collision resolution, a routing instance
is identified by a single incoming label downloader to FIB." - is downloader
the right word here?

6: "If the derived numerical value varies for the same configuration, then an
implementation SHOULD make numerical value used to identify a routing instance
configurable." This is a philosophical point, but it seems like I might always
want to be able to configure this -- perhaps just "Implementations SHOULD
make...? "

7: "This document defines the default tie breaking rules that SHOULD be
implemented. An implementation MAY choose to support different tie-breaking
rules and MAY use one of the these instead of the default tie-breaking rules.
All routers in a routing domain SHOULD use the same tie-breaking rules to
maximize forwarding consistency." Is there any reason not to require that all
implementations implement these rules (mandatory to implement)? I don't want to
end up in a situation where I buy boxes from Vendor X, and then cannot add
Vendor Y, because they don't share a set of rules.

8:  "R2 is the next-hop along the shortest path towards R8. By applying the
steps in Section 2.8 the outgoing label downloaded to R1’s FIB corresponding to
the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown
in Figure 2." - I was initially confused by the [1000,5000] as it isn't
represented like this in the figure. Perhaps change either this text, or the
text in the figure?