[Lsr] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensions / draft-ietf-isis-segment-routing-extensions)
Alvaro Retana <aretana.ietf@gmail.com> Wed, 10 April 2019 20:31 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400A112032A; Wed, 10 Apr 2019 13:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level:
X-Spam-Status: No, score=-1.737 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 0Mp6qTjcN2yr; Wed, 10 Apr 2019 13:31:24 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 EC2191203F5; Wed, 10 Apr 2019 13:31:11 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id d24so3147082otl.11; Wed, 10 Apr 2019 13:31:11 -0700 (PDT)
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=oq24BhDLPgV8miZroJLtTbjgp/ei5TB38OC/3YlVb/Q=; b=adQJ5aKjGe2TcOvpH2fyHaomfTk7J6aCxk2ObyMepvBISJe12Ur1Qn6F+keBr58tdz u2ffNBFD0OyQHLFmF3oTSuUQqmYRc/qqPd7eFArAgk4ePT46n8kzysLeV1ObrTpk0pCb lCZSHMnk+OjFiGiOZIytFsrsCLLW952BBC5LNps9upvW3E9IM31pKw8TJn4ekp5beW0b JjEiyc71+DpF/VwU9G2HHyRPoE+ol95gckssA4/+phP4hVOEFZYH/f+3J7hAXIfh8eMD oDXOUpzM/pFWnj0AFRcTN22ZgU8+D6Gl7Lu5d72nYhH8gFOT49lRwNnJeF1oggGpVa5a EO6g==
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=oq24BhDLPgV8miZroJLtTbjgp/ei5TB38OC/3YlVb/Q=; b=q16kJ8b24T+sYnxpgEXliYYkUSoTgXLGBOuT08N82cE0RU6hArUoe2XEe3DaatkDFR VZNhvFtAkwItGBRmWJ7AP7wckMdBWtNvb8KeeC9P8acsVIRs18ftmb3QwUNyafnFGsRP m0Ue7haj1gp4gktaKzgQaYySnNx7dbi5OCnGwuoAqB+uQoAb+j/SogFBZkmMeiqss3+H roo1wPClbMJsUz79GeZ3jlOe/EswF+kvrp5bbWyn+bjyVbsmUwFXD+s2rGhGJlmuoGMu TcuYLEcXE4gIQJSgcgJI38bZOYcWfdtwM/21jOceGnepP1BfB1b/n7HMvoRafgMO2zX9 tSew==
X-Gm-Message-State: APjAAAVEUd3zDlkUXYnCij+VELGOhBy/daT+P9/DEkuIli2mYj1VYvmO M49wf1K5oPINhba9YhNY2PiyAvBS7PrNGGa8nqfVTA==
X-Google-Smtp-Source: APXvYqw1KDzlk0XSJH6ynN4VPMl9JkgsrfLdwDlymp8JQ+dbEvfg0Ly4JApfTlxI0Wkd7R4gDGuo3fqiDIniO+hH848=
X-Received: by 2002:a05:6830:1103:: with SMTP id w3mr30807456otq.28.1554928270966; Wed, 10 Apr 2019 13:31:10 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Apr 2019 13:31:10 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Wed, 10 Apr 2019 13:31:10 -0700
Message-ID: <CAMMESsxRGWhgUOniQBiELTc4FaaG5gDaA08FQ_KfcEDdB_HfHg@mail.gmail.com>
To: draft-ietf-spring-segment-routing-mpls.all@ietf.org, draft-ietf-ospf-segment-routing-extensions.all@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org, draft-ietf-isis-segment-routing-extensions.all@ietf.org
Cc: SPRING WG <spring@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003e12b8058632f35b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Eq5By1hBw9qrucpbjrvVdywYUQU>
Subject: [Lsr] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensions / draft-ietf-isis-segment-routing-extensions)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 20:31:27 -0000
Hi! I just entered a DISCUSS position related to draft-ietf-spring-segment-routing-mpls (see below). I believe that the issue needs to be solved in conjunction with the IGP extension drafts, so I’m copying the authors/shepherds/chairs here. Thanks! Alvaro. On April 10, 2019 at 4:25:22 PM, Alvaro Retana via Datatracker ( noreply@ietf.org) wrote: ---------------------------------------------------------------------- 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
- [Lsr] Fwd: Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-s… Vigoureux, Martin (Nokia - FR/Paris-Saclay)
- Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-s… Alvaro Retana
- Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-s… Ahmed Bashandy