[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.202.214.17 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. Alvaro. Major: 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 interoperability. 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: I-D.ietf-isis-segment-routing-extensions, I-D.ietf-ospf-ospfv3-segment-routing-extensions, I-D.ietf-ospf-segment-routing-extensions. OTOH, this one should be Normative: RFC5036 Minor: 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” routes/label. 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 [I-D.bashandy-rtgwg-segment-routing-ti-lfa].” 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 to: 4: “ 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." 4.1.1: " 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. Nits: 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). N4. s/R-LFA/RLFA N5. Please put the reference for Option C when it is first mentioned.
- [spring] AD Review of draft-ietf-spring-segment-r… Alvaro Retana
- Re: [spring] AD Review of draft-ietf-spring-segme… Alvaro Retana
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy
- Re: [spring] AD Review of draft-ietf-spring-segme… Alvaro Retana
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy