Segment Routing MPLS Interworking with LDP
draft-ietf-spring-segment-routing-ldp-interop-15

NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem (and have no cycles)" sense.

I might have missed something; and note that this is offered as an
observation, and is explicitly not a blocking comment: this document appears
to offer operational advice for co-existence of LDP and SR, and for
transitioning from LDP to SR in an incremental fashion. I don't see any
protocol specification in here. Based on these observations, it is my opinion
that the contents of this document seem better suited for publication as a BCP
rather than a standards track document. For example: if one were to eventually
progress this document to an Internet Standard, what "implementations" would
one use to evaluate the criteria in section 2.2 of RFC 6140? If we can't
answer that question, I think it's a pretty clear indication that the document
isn't standards track.

---------------------------------------------------------------------------

General:

This document uses IPv4 addresses for example purposes in many places. Please
convert these to IPv6 or a mix of IPv4 and IPv6 addresses. See
https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/
for additional information.

---------------------------------------------------------------------------

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

This document uses non-normative, lowercased versions of these words in several
locations. Please update this section to match the boilerplate in RFC 8174.

---------------------------------------------------------------------------

§3.1.1:

>  A SR node having LDP neighbors MUST create LDP bindings for each
>  Prefix-SID learned in the SR domain by treating SR learned labels as
>  if they were learned through an LDP neighbot.

Nit: "...neighbor."

As a non-specialist I found the organization of 3.2, 3.2.1, and 3.2.2 a little hard to follow, as it seemed to me like the SRMS section should have been introduced first before the discussion of the SR to LDP flow and behavior.

Section 7 says:

"The security associated with these advertisement is
   part of the security applied to routing protocols such as IS-IS
   [RFC5304] and OSPF [RFC5709] which both make use of cryptographic
   authentication mechanisms."

Unless the use of the cited cryptographic authentication mechanisms is required when using these label advertisements, I would suggest saying "which both optionally make use of." Otherwise this seems a little misleading.

Please consider using the RFC 8174 boilerplate for the requirements language section. There are a number of lower case instances of 2119 keywords.

§1, 2nd paragraph: Missing article before " Segment Routing control plane..."

(Clearing DISCUSS, since the question about removed text has been resolved as
an editing error and the text will be restored.  Original COMMENT preserved below.)

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.

Agree with Mirja, seems more appropriate as an informational document (e.g. RFC5145).

I'm not sure if informational status wouldn't be more applicable to this doc but I also fine with Proposed Standard.

nits:
1) In sec 3.1.1 I assume "neighbor" and not "neighbot" is meant...

2) In sec 3.2 this could probably be an upper case MAY:
"Multiple SRMSs may be present in the same network (for redundancy)."