[spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)
Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 10 April 2019 20:25 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7A120165; Wed, 10 Apr 2019 13:25:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, Shraddha Hegde <shraddha@juniper.net>, spring-chairs@ietf.org, spring@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <155492791984.22516.1330631144491086257.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 13:25:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/siOuJ6BRnd4sN_PQK8Lq03j0yxY>
Subject: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <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, 10 Apr 2019 20:25:20 -0000
Alvaro Retana has entered the following ballot position for draft-ietf-spring-segment-routing-mpls-19: 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-mpls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) This first point is a cross-document DISCUSS. In short, the assumptions in this document about what an MCC is responsible for are not in line with the corresponding IGP drafts for OSPF [1][2] and IS-IS [3]. This misalignment must be resolved before any of these documents are published. [Note: I'll start a thread with the corresponding WGS, Authors, Shepherds, Chairs and ADs. Let's please discuss this point there.] This document uses the following definition in §2: "We call "MPLS Control Plane Client (MCC)" any control plane entity installing forwarding entries in the MPLS data plane. IGPs with SR extensions...are examples of MCCs." The focus of the IGP drafts is on the transport of the SR information, and not on other functions (see below). Which component is responsible for what is the point that needs clarification -- either in this document, the IGP drafts, or both. These are some specific cases: (1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be applied by the MCC when calculating the MPLS label value corresponding the SID index value "I"." There's nothing in the IGP extension documents that point at this set of rules, and only a passing reference in the OSPF documents about outgoing labels. (1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC than what the IGP documents do. For example: "Within an MCC, apply tie-breaking rules to select one FEC only and assign the label to it." (1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for downloading the correct label value to FIB"...in this case not just calculating the label, but installing it in the FIB. (1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH or CONTINUE operation must be applied using the SID "Si" is beyond the scope of this document. An example of a method to determine the SID "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or the OSPF ones, for that matter) don't talk about how to determine the operation -- if that is out of scope of this document, then where is it specified? (1.5) From §2: An implementation SHOULD check that an IGP node-SID is not associated with a prefix that is owned by more than one router within the same routing domain. If so, it SHOULD NOT use this Node-SID, MAY use another one if available, and SHOULD log an error. rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain." The text above is not in line with that (MUST NOT vs SHOULD). Also, how can "SHOULD check" be Normatively enforced? Both sentences above seem to be trying to specify a behavior for the IGPs. [1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions [2] https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions [3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions (2) §2.5.1: According to §2.5, a "tie-breaking rule MUST be deterministic". However, the specification of the default rules are not: the first step uses the administrative distance, but the specification says that "the FEC types are ordered using the default administrative distance ordering defined by the implementation"...and later that the "user SHOULD ensure that the same administrative distance preference is used on all routers". The combination of different implementations and the lack of an absolute requirement to ensure consistency can easily be non-deterministic. This point is related to the text in §2.6 which talks about how "the ingress node MUST resolve" collisions the same way. Because of the lack of an absolute requirement for consistency, this "MUST" doesn't guarantee the same result. Also related is this text in §2.5.1: "All routers in a routing domain SHOULD use the same tie-breaking rules to maximize forwarding consistency." When would all routers not use the same rules? It seems to me that forwarding consistency is very important and would want to be maximized all the time. IOW, why not use MUST? I'm making this point a DISCUSS item because it is directly related to the ability of multiple implementations to interoperate. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) §2.2: "A global segment MUST be a label, or an index which may be mapped to an MPLS label within the Segment Routing Global Block (SRGB)..." I don't think this sentence fragment is clear: the intent is surely to say that the global segment MUST be mapped within the SRGB (and not that it "MUST be a label"), right? Suggestion: s/A global segment MUST be a label, or an index which may be mapped/A global segment is a label, or an index which MUST be mapped (2) §2.5: "Suppose an anycast prefix...the advertisement of the prefix-SID by some, but not all, of advertising nodes SHOULD NOT be treated as a label collision." I'm not sure how the receiver knows if the SID was advertised "by some, but not all"...or even if the prefix is being used as anycast. Given the Normative language, please explain. IOW, please clarify the difference between a duplicate prefix-SID and an anycast prefix. The use of "SHOULD NOT" above seems to imply that there are cases when the situation should be treated as a label collision...what are those cases? (3) §2.5: "The remaining FECs with the default algorithm...are installed in the FIB...without any incoming labels..." What will these entries be used for? Given that we're talking about an MPLS network, there may be no traffic that matches the FEC (the traffic should be labeled)...if that is the case, then why install in the FIB at all? OTOH, if there is a possibility that unlabeled traffic is received, then this entry (meant for a different purpose) could be used...also not an ideal situation. §2.6 makes the case that in order "to minimize the chance of misforwarding, a FEC that loses its incoming label...MUST NOT be installed in FIB". This inconsistency adds strength to my questions above. (4) §2.5.1: "if more than one competing FEC remains after step 1, select the smallest numerical FEC value" What value? Are you referring to the FEC type (introduced later in this section)? If so, please be explicit and consistent. (5) §2.5.2.1: The illustration seems incomplete as the rules in §2.5.2 say that "the receiving instance MUST compute its local label", but in this case "B decides not to advertise any index". The second part of the example (in §2.5.2.2) seems to complete the scenario. It seems confusing to me that the first part shows an incomplete case...or am I misinterpreting the rules? (6) §2.7: "PUSH, NEXT, and CONTINUE...The specifications of these operations can be found in [RFC8402]. This sub-section specifies how to implement each of these operations in the MPLS forwarding plane." It seems contradictory that the specification is in two places... In any case, I think that this section is unnecessary as it doesn't seem to add anything from what rfc8402 already explains. (7) Nits... s/flooding mechanisms of link state IGPs fits/flooding mechanisms of link state IGPs fit s/to have a node segment to reach the node/to have a node segment reach the node s/per routing instance, topology, algorithm/per routing instance, topology, or algorithm s/except rule/except the rule s/local label serves/a local label serves s/subTLVs/sub-TLVs s/Remaining FECs/The remaining FECs s/installed in FIB/installed in the FIB s/lowest value SHOULD be/lowest value SHOULD be: s/SR Algorithm,)/SR Algorithm)
- [spring] Alvaro Retana's Discuss on draft-ietf-sp… Alvaro Retana via Datatracker
- Re: [spring] Alvaro Retana's Discuss on draft-iet… Ahmed Bashandy
- Re: [spring] Alvaro Retana's Discuss on draft-iet… Alexander Vainshtein
- Re: [spring] Alvaro Retana's Discuss on draft-iet… Ahmed Bashandy
- Re: [spring] Alvaro Retana's Discuss on draft-iet… Alexander Vainshtein