Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10
Alvaro Retana <aretana.ietf@gmail.com> Thu, 30 November 2017 22:27 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 0AD67127010; Thu, 30 Nov 2017 14:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_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 55Rxv4jt-Toz; Thu, 30 Nov 2017 14:26:57 -0800 (PST)
Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 ADC5C126C0F; Thu, 30 Nov 2017 14:26:57 -0800 (PST)
Received: by mail-ot0-x244.google.com with SMTP id y10so7483450otg.10; Thu, 30 Nov 2017 14:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=NkuJThRgI+ftyL7miHd7R7rneYVSCUNG5q2JeaBIWak=; b=kHLE5zOEVDwpe+18V5geY285iCqElOXeKuRrx84nqT/csNt8U8lAB7K130cIDSTxsX hV9nxIFDrXSWMdWLkibG3VSeDvYToDQRPT8EqfvGJnddcOnTv1n4grfwAzdNMS3P931K uimBV/kjQRlxmrgsBCkK0fL2GGO3rdaVi6XLn8uqS+xEoq4plpbcf5P7aJUE6f5Sx64V p1we70LVVVtgr5Zkoq1hfrBif40uEvp2poHSniBNbAqkAzjZ/hP6lQO3K1dv1AsI/CXd OSUEcwBGYXC91ezYTY9C5sxbX2djoj4T0VLYPAlqn4014kpmE/IydhKIJe24Smgg/VT3 iaeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=NkuJThRgI+ftyL7miHd7R7rneYVSCUNG5q2JeaBIWak=; b=m8dwJFbyGQ4Zj9hoTTpptF6E7XKTNcaqZAGQRTy7rK+UTFx2nYdNGTGpv1s+0kNbzX rTkrMeap4CwtcuGj8K8CYAYX/5xwG0Ju6BeNe7gtPskg/+z4jJuBXsRgB/u0+dv1M1sN hFbNNfljb2AJtJQScUKj52d0tCAiPAfi/gJgrnPEJdSRhzTyxS94LAOwaGPywMUtobvP DVLFsYaPq7MEW+M+CYohLt9u/lYP94+jhk8JLl7jOKkEomWkix3RgkRqC5A9lx4ibWtn dbnftWO0A9UA1yquyN/xRZlgjTy7O//bSpQ53vygjzzQ3hbhoB3tbvCh9C4anuwUtsql duaA==
X-Gm-Message-State: AJaThX6ntpQRaGebcpcAdR1wpKpavplZmvUICR1GPD3cDzquQFVInehc LJQO5qPa6bTkK8F/kqKmB+Zfgel0tsScyjE+Llc=
X-Google-Smtp-Source: AGs4zMZotA0mca7NS7Pe8lEFDqKPkJGKAP/hirASUcXS8g0jPH4T/PX37054tSHClEqLi9dvPkurMFPwLHRHxO6/u7o=
X-Received: by 10.157.22.183 with SMTP id c52mr6119020ote.317.1512080817006; Thu, 30 Nov 2017 14:26:57 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Nov 2017 14:26:56 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESswqFYQe_=zp8cPsuvvxMBFxUEe3t3DvkL=ZnZhA7RZO0w@mail.gmail.com>
References: <74FB72FC-AD69-4EA3-ACA2-739168EE0A44@cisco.com> <aa2ed0f2b0a845cc83b16adda7566b37@XCH-ALN-001.cisco.com> <50d87236662f49bb8a81308dff6abbf5@XCH-RTP-020.cisco.com> <CAMMESswqFYQe_=zp8cPsuvvxMBFxUEe3t3DvkL=ZnZhA7RZO0w@mail.gmail.com>
X-Mailer: Airmail (461)
MIME-Version: 1.0
Date: Thu, 30 Nov 2017 14:26:56 -0800
Message-ID: <CAMMESszXTnoii_dkSPf4iBdKXDtBVdHwApOVOocTMUc1cW0E_Q@mail.gmail.com>
To: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
Cc: SPRING WG <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "draft-ietf-spring-segment-routing-mpls@ietf.org" <draft-ietf-spring-segment-routing-mpls@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
Content-Type: multipart/alternative; boundary="001a1141c090f82ef2055f3abf53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Cw5D7EEDBuMp8G0jk_R9X_SOdzc>
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-mpls-10
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: Thu, 30 Nov 2017 22:27:01 -0000
Ahmed: Hi! It’s been almost a month, and I haven’t seen a reply from you. I will send the document back to the WG by the end of this week. Thanks! Alvaro. On November 2, 2017 at 6:49:10 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: On October 30, 2017 at 2:12:18 PM, Ahmed Bashandy (bashandy) ( bashandy@cisco.com ) wrote: Ahmed: Hi! How are you? ... The main questions/concerns that I have related to this document is not just for the authors, but for the Shepherd and the Chairs too. Q1. Why is this document on the Standards Track? From the Introduction: “This drafts describes how Segment Routing operates on top of the MPLS data plane.” Describes, yes. On the other hand, the Shepherd’s write-up says that it “specifies the generic functions of the architecture” – I don’t see a specification, just a description. As such, I think this document should be Informational. #Ahmed: The new version of the draft specifies many things that are applicable to instantiation of SR over MPLS I’ll take your answer as confirming that the old version (-10) wasn’t really specifying anything. For this new version (-11), can you please be specific on what these “many things” are? I see some new Normative Language in the new 2.x sub-sections. I have some specific comments on that: Q1.A. Section 2.2. (SID Representation in the MPLS Forwarding Plane): The MCC MUST ensure that any label value corresponding to any SID it installs in the forwarding plane follows the following rules: o The label value MUST be unique within the router on which the MCC is running. i.e. the label MUST only be used to represent the SID. o The label value MUST NOT be identical to or within the range of any reserved label value or range [reserved-MPLS <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-11#ref-reserved-MPLS>], respectively. These seem to be new requirements for the MCCs. Given that the protocol extensions (and LDP) are defined (in Section 2) as MCCs, how are they supposed to follow these rules, specially the first one? As far as I can tell, the IGP extensions (for example) can carry Label/SID information from an advertising node, so I don’t know how a local MCC (remote to that advertising node, which is locally "installing forwarding entries in the MPLS data plane”) can guarantee what the label is used for (“only used to represent the SID”). Maybe I’m missing something and this is already specified somewhere else…?? The second rule is just what the MPLS Architecture already specifies, no nothing new, right? BTW, the link in the reserved-MPLS reference doesn’t work — a better reference might be rfc3032 or rfc7274. Q1.B. Section 2.3. (Segment Routing Global Block and Local Block): The following rules apply to the list of MPLS ranges representing the SRGB o The list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane o Every range in the list of ranges specifying the SRGB MUST NOT cover or overlap with a reserved label value or range [reserved- MPLS], respectively. . . . Just like SRGB, the SRLB need not be a single contiguous range of label, except the SRGB MUST only be used to instantiate global SIDs into the MPLS forwarding plane. The first rule (and the text below them) points to the global nature of the SR *global* Block. The architecture document already says that "In SR-MPLS, SRGB is a local property of a node and identifies the set of local labels reserved for global segments.” Nothing new specified here. Q1.C. Section 2.4. (Mapping a SID Index to an MPLS label) introduces an algorithm to calculate the label value. Note that the architecture document now includes an algorithm (in Section 3.1.2) as well — the algorithm in this document doesn’t look to be the same, but even if it is, it would be confusing to specify the same thing in two places. Q1.D. The rest of the sub-sections seem to rehash forwarding behaviors, which, because of the fact that the MPLS architecture is not changing, seem to add nothing interesting or important to this document. Having said all that, I still don’t see a clear justification for this document to be in the Standards Track. Q2. Section 2. (MPLS Instantiation of Segment Routing) is the only one with any real content…but there are only a couple of things in it that are not in the Architecture document: the introduction of the SRLB, and some words about the index – both of which should be really explained in the Architecture document, and not here. I wonder what the value of publishing this document really is. What long-term archival value does it provide? #Ahmed: The long term plan is to move details of MPLS-specific specifications to this document and keep the architecture document more general The “long term plan” ?? What do you mean? The architecture document is already in IETF Last Call — are you saying that both documents still require more changes and are not ready for publication? I really hope that is not what you mean. In any case, you did not answer my question about the value of the document as is. No worries, the intent is not to stop publication, but to understand whether there is something I’m missing and the relationship to the proposed Status. Q3. I also have to wonder about the IPR declared for this document. If most of the information here is already defined, described or specified in draft-ietf-spring-segment-routing, should the IPR declaration apply to that document as well (or maybe instead of this one)? It is not the IETF’s role (including the WG) to discuss whether a piece of IPR is valid or not – I just want to make sure the disclosures apply to the right document. #Ahmed: We will make sure that all IPR is declared That was not my question! And declaring IPR at this point in time is very, very late (rfc6701). I didn’t find a discussion on the list about any of these points. I am concerned about all the text that has been added (which in my opinion doesn’t contribute much to the document), resulting in about a 70% increase the document length! I will wait for your answer to my points above before returning the document to the WG for a thorough review. I have some other specific comments below. Thanks! Alvaro. ... P3. Section 2. (MPLS Instantiation of Segment Routing) says that “a controller-driven network…MAY use the control plane to discover the available set of local SIDs”. The “MAY” implies that there is a choice (i.e. it is optional) and that other discovery mechanisms exist. What are those other choices? Note that earlier in this section you already wrote that IGPs are used for flooding the information. s/MAY/may #Ahmed: This document gives an example of a use of the SRLB. Listing all possible uses of the SRLB is certainly not within the scope of this document. I’m not sure what your answer has to do with my comment…but giving examples is a good reason to *not* use Normative language. In any case, that piece of text was not changed from: In a controller-driven network, some controllers or applications MAY use the control plane to discover the available set of local SIDs on a particular router. In such cases, the SRLB is advertised in the control plane (e.g., using [I-D.ietf-isis-segment-routing-extensions <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-10#ref-I-D.ietf-isis-segment-routing-extensions>]). …to… In a controller-driven network, some controllers or applications MAY use the control plane to discover the available set of local SIDs on a particular router [I.D. filsfils-spring-segment- routing-policy]. The “MAY” is still there (which was the main point of the comment above), and you added a new reference to apparently illustrate the point that the control plane can be used "to discover the available set of local SIDs on a particular router”. Isn’t that already specified in the architecture document? Why do we need this new reference? ... P5. References. Please take a look at rfc8174 and update the “Requirements Language” and associated references. #Ahmed: I agree. I modified the paragraph about requirements language to conform to rfc8174 You forgot to include the rfc8174 reference. Nits N1. I think that the references to *-segment-routing-extensions are superfluous. BTW, the fourth paragraph of the Introduction uses a reference to *-segment-routing-extensions to point at ISIS/OSPF (the protocols!). #Ahmed: I agree. Now we have clear references to each IGP extensions separately The point was that I think all references to the extensions are superfluous — not a request to add them.
- [spring] AD Review of draft-ietf-spring-segment-r… Alvaro Retana (aretana)
- Re: [spring] AD Review of draft-ietf-spring-segme… Martin Vigoureux
- Re: [spring] AD Review of draft-ietf-spring-segme… Alvaro Retana (aretana)
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy (bashandy)
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy (bashandy)
- Re: [spring] AD Review of draft-ietf-spring-segme… Alvaro Retana
- Re: [spring] AD Review of draft-ietf-spring-segme… Alvaro Retana
- Re: [spring] AD Review of draft-ietf-spring-segme… Ahmed Bashandy (bashandy)