Subject: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 09:40:43 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-segment-routing-ldp-interop-13: 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-segment-routing-ldp-interop/

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

I may be missing something, but I don't see anything that says whether the
preference field introduced in Section 3.2.3 uses larger values or smaller
values for more-preferred SRMSes.

The introduction of the SRMS is also introducing a new way for a protocol
participant to make claims about route prefixes directed at "third parties"
(non-MS, non-MC routers).  While routing protocols in general do require high
levels of trust in all participants in order for proper routing to occur, this
addition seems to create a "first among equals" situation that could be called
out more clearly in the security considerations.  (I do appreciate that the
requirement for preferring SIDs advertised in prefix reachability
advertisements over those advertised in mapping server advertisements does help
alleviate some of the risk.)

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

I support Alissa's suggestion about the text covering cryptographic authentication.

"[100,300]" and "(100,200)" are each used as an example SRGB.  In
some contexts the round versus square brackets indicate a
distinction between "closed" (includes endpoints) and "open" (does
not include endpoints) intervals.  If there's no need to make such a
distinction, I suggest standardizing one one format.

As was mentioned in the secdir review, it would be good to expand FEC and LFA on first usage.

Section 1

   Section 2 describes the co-existence of SR with other MPLS Control
   Plane. [...]

nit: "other MPLS Control Plane" seems to be an incomplete compound noun
-- is it other control plane technologies that are being considered?

Section 2

   Note that this static label allocation capability of the label
   manager exists for many years across several vendors and hence is not
   new.  Furthermore, note that the label-manager ability to statically
   allocate a range of labels to a specific application is not new
   either. [...]

nits: "has existed", "label-manager's ability".

Section 2.1

   MPLS2MPLS refers the forwarding behavior where a router receives an
   labeled packet and switches it out as a labeled packet.  Several

nit: "refers to", "a labeled packet"

Section 3.2

   This section defines the Segment Routing Mapping Server (SRMS).  The
   SRMS is a IGP node advertising mapping between Segment Identifiers
   (SID) and prefixes advertised by other IGP nodes.  The SRMS uses a
   dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol
   specific and defined in [I-D.ietf-isis-segment-routing-extensions],
   [I-D.ietf-ospf-segment-routing-extensions], and
   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a
better parenthetical?

   The example diagram depicted in Figure 3 assumes that the operator
   configures P5 to act as a Segment Routing Mapping Server (SRMS) and
   advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103)
   and (PE4, 104).

nit: I think this is Figure 2.

Section 3.2.1

   [...] Examples
   of explicit prefix-SID advertisment are the prefix-SID sub-TLVs
   defined in ([I-D.ietf-isis-segment-routing-extensions],
   [I-D.ietf-ospf-segment-routing-extensions], and
   [I-D.ietf-ospf-ospfv3-segment-routing-extensions]).

Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat)
be appropriate for inclusion in this list?

   for that prefix.  Hence assigning a prefix-SID to a prefix using the
   SRMS functionality does not preclude assigning the same or different
   prefix-SID(s) to the same prefix using explict prefix-SID
   advertisement such as the aforementioned prefix-SID sub-TLV.

nit: I think the aforementioned things were a list, so "sub-TLVs" plural
would be appropriate.

Including the name for IS-IS TLV 135 might be helpful for the
reader.