[spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

Alvaro Retana <aretana.ietf@gmail.com> Wed, 20 December 2017 18:37 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 546A9129C6E; Wed, 20 Dec 2017 10:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5lQYNfPz7UAy; Wed, 20 Dec 2017 10:36:59 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EF41267BB; Wed, 20 Dec 2017 10:36:56 -0800 (PST)
Received: by mail-oi0-x236.google.com with SMTP id w125so15268272oie.7; Wed, 20 Dec 2017 10:36:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=/d9cFXnE9xpuIZkUn/rjhOY398xP1aB5NSDFRk/bG5w=; b=VQU+5lddZQV6sAx5rE01Yh9YHgU7vuLo85wJvhSlX3wVklTHU/KAJ4fYzJBrSxXpYQ xuz1JWKI3bwTkKBuAum2sSa8rXhbdZbC9xxUo9xz0q9n95aGMbxDS+O3wW/+kCP1NN3k WRUI5D2PKO2xgXwFlf7taRqHOuhVwvt0Zlq+nkGStSiweOh3t9QWNAU9YUGNeta/E0GQ zRa3gmKpMxiQe3oqA9DKGRsQdfFezbZteSyLljxllOSOBekMBmym5wa1ZXIFOf1Wj0K+ 7KM7g/VhD8uLAMZChADonG8DKswV0TtqKt1zNS4sAoS0cuFnsBsaZJt5CBqNjRxD4jO9 ov/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=/d9cFXnE9xpuIZkUn/rjhOY398xP1aB5NSDFRk/bG5w=; b=AmSja1sXamRBH74YKuph9MaewBEahSKykFU2+gebHaII4bNpqsCQStx/kTdMgnHgHT 9qcn/rwMUW7O89ZfonX5tpqL4HW+TgUbPOZ7gkV1DtHjbJGCrMHy68f9PINyQvIbcWTi L/Dc1I0GDUKbJC9Z8Z4U/84GdkYf1kqfPTiGjV5tEeLU3PPHO9Zb8Glzrr36yoM9I+fX TQwAu7kYF9tluebVyuqBLpEHuxwqRDJeZbA+mxmbC2RLn9BvyAVCRN3Bc5tXBwh69hEQ rIIydMhHnZKJD/y66s/gdvOrdu4PWK8DPyhXEKA871dUDcRAxB+xbKFD69HZyEi/TQGJ k6RA==
X-Gm-Message-State: AKGB3mJSORzWkp2G+kqH9m+ElD7L1uiwttB79wo0LtrTHqat2t4lK5uL 3x3CDcWbSjhNuz2cA55UVEeLTEbVjJvJmzRrw7Y=
X-Google-Smtp-Source: ACJfBovgMtis0ZmwHBt6T5+Dj4YNj3G0JSYBbXX2BGm1a5E/pk+9dltbkbmfxAqngIBCw6Jzikb1Dd/BdEjJ902c5VI=
X-Received: by with SMTP id n17mr5646683oig.46.1513795015125; Wed, 20 Dec 2017 10:36:55 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 20 Dec 2017 13:36:54 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 20 Dec 2017 13:36:54 -0500
Message-ID: <CAMMESsy8EVCanj6-XAQf8QUfuuxW3t+V3Trje58OyeoEKfrPKA@mail.gmail.com>
To: draft-ietf-spring-segment-routing-ldp-interop@ietf.org
Cc: spring-chairs@ietf.org, Martin Vigoureux <martin.vigoureux@nokia.com>, spring@ietf.org
Content-Type: multipart/alternative; boundary="001a113adb4023af5a0560c9de8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wCtx1K0O11zIlbqsE-1nbqahXC8>
Subject: [spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 18:37:01 -0000

Dear authors:

I just finished reading this document.  I have some Major comments below
that I would like to see addressed before starting the IETF LC.

Thanks for your work on this document.



M1. From Section 2: "An MCC, operating at node N, MUST ensure that the
incoming label it installs in the MPLS data plane of Node N has been
uniquely allocated to himself.”  I’m sure this sentence is not meant as a
new Normative statement for all MCCs, right?  I think that the “MUST” is
out of place since the text is really stating a fact.  s/MUST/must

M2. SRMS Definition and Operation

M2.1. Section 4.2.1. (SR to LDP Behavior) uses normative language to
describe the operation of the SRMS in ways that I think are not needed for

M2.1.1. "The SRMS MUST be configured by the operator in order to
advertise Node-SIDs
on behalf of non-SR nodes.”  Section 4.2 already says that "The mappings
advertised by one or more SRMSs result from local policy information
configured by the operator.”, so the sentence in 4.2.1 is at best
redundant.  In any case, what can be enforced from a specification point of
view by that “MUST”?  s/MUST/must

M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs
SHOULD be present for redundancy.”  These MUST|SHOULD seem to indicate a
statement of fact.  Again, from a specification point of view, what can be
enforced?  s/MUST|SHOULD/must|should. Note also that in 7.2 the text says
that "Multiple SRMSs can be provisioned in a network for redundancy.”,
which seems to be the right thing (no Normative language).

M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

M2.3. Section 7.2 also says that: "When the SRMS advertise mappings, an
implementation SHOULD provide a mechanism through which the operator
determines which of the IP2MPLS mappings are preferred among the one
advertised by the SRMS and the ones advertised by LDP.”  First off, I think
that the SHOULD is out of place because it is not specifying any specific
action (the mechanism is not explicit). Second, this statement (with the
Normative SHOULD) is in conflict with (from 2.2. (IP2MPLS co-existence)):
"if both LDP and SR propose an IP to MPLS entry (IP2MPLS) for the same IP
prefix, then the LDP route SHOULD be selected.”  Solution: s/SHOULD/should

M3. Manageability Considerations

M3.1. The text in Section 7.1. (SR and LDP co-existence) is almost the same
as in Section 2.2. (IP2MPLS co-existence); the difference is that 7.1’s
first bullet says that "by default the LDP route MUST be selected”, while
2.2 uses SHOULD instead.  Which one is it?  Obviously, having the same text
is two places adds nothing to the document — please consolidate.

M3.2. [minor] The last bullet in 7.1/2.2 says that the "policy MAY be
locally defined.  There is no requirement that all routers use the same
policy.”  Given that in this case “all routers” really refers to the edge
nodes (at the IP2MPLS boundary), it seems like it makes sense that either
choice could be ok.  Maybe I’m wrong, but I’m guessing that giving
preference to LDP (MUST/SHOULD above) has to do with the assumption that it
is supported everywhere, while SR might not yet be…so it supports the
migration case in Section 3.  Is that a reasonable guess?  It would be
nice, to provide some justification for the default LDP preference so that
operators have a better idea of when it might be ok to use SR instead.

M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no specific mitigation (except maybe strict configuration/programmability
control by the operator) can be mentioned.

M5. References:  These references don’t need to be Normative and can be
made Informative:
 OTOH, this one should be Normative: RFC5036


P1. As with all the other SR-related documents, please take out “service
chain” from the text.

P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”.   BTW, note that
rfc3107 has been obsoleted by rfc8277 — you make references to “BGP3107”

P3. Please define (or reference) the MPLS2MPLS, MPLS2IP and IP2MPLS
terminology (only IP2MPLS is expanded).

P4. From Section 3: “...the SR infrastructure is usable, e.g. for Fast
Reroute (FRR) or IGP Loop Free Convergence to protect existing IP and LDP
traffic.  FRR mechanisms are described in
 draft-ietf-spring-resiliency-use-cases may be a better reference.

P5. Section 3: "However, any traffic switched through LDP entries will
still suffer from LDP-IGP synchronization.”  While that statement is true,
it seems out of place since there is no other discussion about LDP-IGP
synchronization anywhere — if you want to keep it, please add a reference.

P6. Sections 4 and 4.1.1 have very similar, redundant text.  To avoid
confusion, please consolidate it in one place.  This is what I’m referring

“  If the SR/LDP node operates in LDP ordered label distribution control
   mode (as defined in [RFC5036]), then the SR/LDP node MUST consider SR
   learned labels as if they were learned through an LDP neighbor and
   create LDP bindings for each Prefix-SID and Node-SID learned in the
   SR domain."

"  A SR node having LDP neighbors MUST create LDP bindings for each
   Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
   stitch the incoming LDP label to the outgoing SR label.  This has to
   be done in both LDP independent and ordered label distribution
   control modes as defined in [RFC5036]."

Note that this same text (as in 4.1.1 above) is repeated exactly in 4.2.1 —
where the SRMS is discussed.  To me, it seems out of place there (4.2.1) as
the behavior is true whether an SRMS is in use or not.  In line with the
above, it may be better to consolidate redundant text in one place —
Section 4 seems good to me.


N1. s/This draft(s)/This document

N2. s/Ship-in-the-night/Ships-in-the-night

N3. Please don’t use “we”, use the 3rd person instead.  Just a personal
preference (= nit).


N5. Please put the reference for Option C when it is first mentioned.