[Lsr] AD Review of draft-ietf-ospf-mpls-elc-12
Alvaro Retana <aretana.ietf@gmail.com> Sat, 29 February 2020 05:03 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 25DF33A07A7; Fri, 28 Feb 2020 21:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 R6BKS7lhUeb2; Fri, 28 Feb 2020 21:03:54 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 80B933A07A6; Fri, 28 Feb 2020 21:03:51 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id c62so4443607edf.0; Fri, 28 Feb 2020 21:03:51 -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 :content-transfer-encoding; bh=V4vOxHpqONVYzpAePA3/tfTTaHDgCcdmhHyn8Qhn84k=; b=CW2zdgM9CNXtIZdeprs99X23kBCcM+fpuzthPYMB1sxReE1Sl1CDs3GVN6hXcZhgSG S6SXtIUm6gBDOoZtRhK7+6a8W9qYfo9vVdUZF3o3Dmcizqpa0zP+0xU/6lvEvYc58nQe S4KKM/7HlScAfDyJ7nG6wPpj7EW4fE2W30MsLxzWpnUauu1MAIXYIosvNgxKStEMMRkj s5PZ/Q5MfV1+TwAwD2VfVT/nIwwJBoGDQMDl3ErRogtgrDWwRw0pWNhujSpLOtHjir6i ZBz3QyFTQZ1OFOAKSz1sPPvp38E6mVK35IkVy1ZpRMArrIJN43eBwA0A1h3XDHw/3Lki nEZw==
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 :content-transfer-encoding; bh=V4vOxHpqONVYzpAePA3/tfTTaHDgCcdmhHyn8Qhn84k=; b=eU06cmlr9WdTEJHqoiXtAFZtXbH3v1F/xRekgy6bI5chLLqcc6mn2j1zCh/VR6lpxa 7knPgY/dcivS1BrGo11K1YqMz6QZQ2nkkTuIfCUpnnmCfaTxyNoGqN3UOhgDzpkgJvDI R+C1SWZ1ZfzvHBhAcX4WeJb5G1ENrnbPnDJKgQ00OFfcqG0ddWyxyLaH7RrCmsNoCJN/ e7jE7tDaoDbwLBxifyMtV4385exhQ6MTrkQunkQUN2MhpT7mVHsAaWaSj4sy5ka0Cf+e 39CeoywLHbaTLtDDyVPH7MYlqW9EI/UqywjFWpsmZs/iBmzursb+aVVRVnZVyA0tDOVJ AwBw==
X-Gm-Message-State: APjAAAWmuelfcmwb5mm7mG1ip6KnpPJ2LMx/dOBt2gwOAv9P4xRkK1JO hkE387hwTRn+MHeZ3x+3SW+eRpcxPXTFoFIJlT6dyaYu
X-Google-Smtp-Source: APXvYqygJ0FSMu/W77dcfVS5hQB0/RL9lRjwHJ6AETUSBudx+WU6Yk1xa6E5z17ZJskzqJQwJywE05/99EQ8HZ1e5WY=
X-Received: by 2002:a17:906:cf8f:: with SMTP id um15mr6773489ejb.289.1582952629263; Fri, 28 Feb 2020 21:03:49 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Feb 2020 21:03:48 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Fri, 28 Feb 2020 21:03:48 -0800
Message-ID: <CAMMESsw00M=+VM7KOS-pNjZnu-FRCJt6-cop3bTAFBTtNx+B8Q@mail.gmail.com>
To: "draft-ietf-ospf-mpls-elc@ietf.org" <draft-ietf-ospf-mpls-elc@ietf.org>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Yy0XpGK6WWCvkmme7Z4anaYMWkA>
Subject: [Lsr] AD Review of draft-ietf-ospf-mpls-elc-12
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: Sat, 29 Feb 2020 05:03:57 -0000
Dear authors: This is my review of draft-ietf-ospf-mpls-elc-12. I reviewed this document alongside draft-ietf-isis-mpls-elc-10, so many comments are the same/similar. Thank you for the work in both of them! I will progress both documents together, so I will wait for both of them to address my comments before starting their IETF LC. Thanks!! Alvaro. [Line numbers from idnits.] ... 14 Signaling Entropy Label Capability and Entropy Readable Label-stack 15 Depth Using OSPF [minor] s/Label-stack/Label 16 draft-ietf-ospf-mpls-elc-12 18 Abstract 20 Multiprotocol Label Switching (MPLS) has defined a mechanism to load- 21 balance traffic flows using Entropy Labels (EL). An ingress Label 22 Switching Router (LSR) cannot insert ELs for packets going into a 23 given tunnel unless an egress LSR has indicated via signaling that it 24 has the capability to process ELs, referred to as Entropy Label 25 Capability (ELC), on that tunnel. In addition, it would be useful 26 for ingress LSRs to know each LSR's capability of reading the maximum 27 label stack depth and performing EL-based load-balancing, referred to 28 as Entropy Readable Label Depth (ERLD). This document defines a 29 mechanism to signal these two capabilities using OSPF and OSPFv3. 30 These mechanism is particularly useful in the environment where 31 Segment Routing (SR) is used, where label advertisements are done via 32 protocols like OSPF and OSPFv3. [nit] s/given tunnel/given Label Switched Path (LSP) [nit] s/as Entropy Label Capability/as the Entropy Label Capability [nit] s/capability of reading/capability for reading [minor] s/OSPF and OSPFv3/OSPFv2 and OSPFv3/g [minor] Add some text in the Introduction pointing at the generic use of "OSPF" to mean both OSPFv2 and OSPFv3. [minor] "protocols like OSPF..." That last sentence sounds as if there were other options; for example advertise labels with IS-IS and then use the extensions here. It's just a minor point, but I think that maybe that last sentence is not needed. ... 83 1. Introduction ... 96 In addition, in the cases where stacked LSPs are used for whatever 97 reasons (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it 98 would be useful for ingress LSRs to know each intermediate LSR's 99 capability of reading the maximum label stack depth and performing 100 EL-based load-balancing. This capability, referred to as Entropy 101 Readable Label Depth (ERLD) as defined in 102 [I-D.ietf-mpls-spring-entropy-label] may be used by ingress LSRs to 103 determine the position of the EL label in the stack, and whether it's 104 necessary to insert multiple ELs at different positions in the label 105 stack. [minor] s/stacked LSPs/LSPs I'm assuming there's no special significance of "stacked" in this case, as this is the only place in the document that it is used. [nit] s/in the cases where LSPs are used for whatever reasons/in cases where LSPs are used 107 2. Terminology 109 This document makes use of the terms defined in [RFC6790], [RFC7770] 110 and [I-D.ietf-mpls-spring-entropy-label]. [minor] I'm not sure why rfc7770 is referenced here; what terminology is needed from it? 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [BCP14] [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. [major] s/[BCP14]/BCP 14 118 3. Advertising ELC Using OSPF 120 Even though ELC is a property of the node, in some cases it is 121 advantageous to associate and advertise the ELC with the prefix. In 122 multi-area networks, routers may not know the identity of the prefix 123 originator in a remote area, or may not know the capabilities of such 124 originator. Similarly, in a multi domain network, the identity of 125 the prefix originator and its capabilities may not be known to the 126 ingress LSR. [nit] s/with the prefix/with a prefix [minor] Is there a difference that are you trying to highlight between multi-area and multi-domain? The last two sentences seem redundant to me; using "domain" should be enough. 128 If a router has multiple line cards, the router MUST NOT announce ELC 129 unless all of its line-cards are capable of processing ELs. 131 If the router supports ELs on all of its line cards, it SHOULD 132 advertise the ELC with every local host prefix it advertises in OSPF. [major] From a general router architecture point of view, I understand what you mean by line-card. But, strictly speaking from a specification point of view, what is a line-card? Would using "interface" instead be an acceptable generalization? [major] "it SHOULD advertise the ELC for every local host prefix" If ELs are supported in all the interfaces, when would a router not set the ELC? IOW, why is "MUST" not used instead of "SHOULD"? [major/related] The two paragraphs seem to be redundant -- I think that only the second one is needed; suggestion (assuming my interpretation of the questions above): If a router supports ELs on all of its interfaces, it MUST set the E-flag (ELC Flag) for every attached prefix it advertises. 134 When an OSPF Area Border Router (ABR) advertises the prefix to the 135 connected area based on the intra-area or inter-area prefix that is 136 reachable in some other area, it MUST preserve the ELC signalling for 137 such prefix. [] Suggestion> When an OSPF Area Border Router (ABR) distributes information between connected areas it MUST preserve the ELC setting. 139 When an OSPF Autonomous System Boundary Router (ASBR) redistributes 140 the prefix from another instance of the OSPF or from some other 141 protocol, it SHOULD preserve the ELC signaling for the prefix. The 142 exact mechanism used to exchange ELC between protocol instances on 143 the ASBR is outside of the scope of this document and is 144 implementation specific. [nit] s/redistributes the prefix/redistributes a prefix [minor] s/ELC signaling/ELC setting [nit] s/ and is implementation specific./. ... 156 3.2. Advertising ELC Using OSPFv3 158 [RFC5340] defines the OSPFv3 PrefixOptions that are advertised along 159 with the prefix. A new bit in the OSPFV3 PrefixOptions is used to 160 signal the ELC for the prefix: [minor] s/[RFC5340] defines the OSPFv3 PrefixOptions that are advertised along with the prefix./[RFC5340] defines the OSPFv3 PrefixOptions field to indicate capabilities associated with a prefix. [nit] s/OSPFV3 PrefixOptions/OSPFv3 PrefixOptions field ... 165 4. Advertising ERLD Using OSPF [major] draft-ietf-mpls-spring-entropy-label says that "To advertise an ERLD value, a SPRING router: MUST be entropy label capable". This requirement must be translated to this document so that the ERLD is only advertised if the ELC is also advertised. I'm assuming that the ERLD should be ignored if the ELC is not advertised -- but that should be explicitly defined as well. If the ELC is advertised, but the ERLD isn't, what value should be assumed, 0? 167 A new MSD (Maximum SID Depth) type of the Node MSD sub-TLV [RFC8476], 168 called ERLD is defined to advertise the ERLD of a given router. The 169 scope of the advertisement depends on the application. 171 Assignment of a MSD-Type for ERLD is defined in 172 [I-D.ietf-isis-mpls-elc]. [minor] Instead of the last two paragraphs: The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc]. ... 181 5. Signaling ELC and ERLD in BGP-LS ... 186 The ELC Flag included in the OSPFv2 Extended Prefix TLV and the 187 OSPFv3 PrefixOptions, as defined in Section 3, is advertised using 188 the Prefix Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 189 Prefix NLRI Attribute as defined in section 2.3.2 of 190 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. [nit] Suggestion> The ELC is advertised using the Prefix Attribute Flags TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 192 The ERLD MSD-type introduced for OSPF in Section 4 is advertised 193 using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as 194 defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd]. [nit] Suggestion> The ERLD-MSD is advertised using the Node MSD TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 196 6. Acknowledgements [major] Move this section to just before the References. ... 202 7. IANA Considerations 204 This document requests IANA to allocate one flag from the OSPFv2 205 Extended Prefix TLV Flags registry: 207 0x20 - E-Flag (ELC Flag) 209 This document requests IANA to allocate one flag from the OSPFv3 210 Prefix Options registry: 212 0x04 - E-Flag (ELC Flag) [major] IANA has already assigned the values. Suggestion> Early allocation has been done by IANA for this document as follows: - Flag 0x20 in the OSPFv2 Extended Prefix TLV Flags registry has been assigned to the E-Flag (ELC Flag). IANA is asked to update the registry to reflect the name used in this document: E-Flag (ELC Flag). - Bit 0x04 in the "OSPFv3 Prefix Options (8 bits)" registry has been assigned to the E-Flag (ELC Flag). IANA is asked to update the registry to reflect the name used in this document: E-Flag (ELC Flag). 214 8. Security Considerations 216 The security considerations as described in [RFC7770] and 217 [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. [minor] Why? Also, I think that some of the other references should be added here. Suggestion: This document specifies the ability to advertise additional node capabilities using IS-IS and BGP-LS. As such, the security considerations as described in [RFC5340], [RFC7770], [RFC7752], [RFC7684], [RFC8476], [I-D.ietf-idr-bgp-ls-segment-routing-ext], [I-D.ietf-idr-bgp-ls-segment-routing-msd] and [I-D.ietf-mpls-spring-entropy-label] are applicable to this document. 219 Incorrectly setting the E flag (ELC capable) (during origination, 220 inter-area advertisement or redistribution) may lead to black-holing 221 of the traffic on the egress node. [minor] s/E flag (ELC capable)/E flag [major] "...may lead to black-holing of the traffic on the egress node." I'm not sure I understand how, but the ELC advertisement should be accompanied by the ERLD-MSD -- see my questions at the beginning of §4. 223 Incorrectly setting of the ERLD value may lead to poor load-balancing 224 of the traffic. [minor] "may lead to poor load-balancing" If the ERLD is low, then the traffic may not be load balanced at all...that is not "poor", it is "0". ... 252 10.1. Normative References 254 [BCP14] , <https://tools.ietf.org/html/bcp14>. [major] A reference to BCP14 is not needed. The ones to [RFC2119] and [RFC8174] are enough. ... 275 [I-D.ietf-mpls-spring-entropy-label] 276 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 277 Shakir, R., and J. Tantsura, "Entropy label for SPRING 278 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 279 progress), July 2018. == Outdated reference: draft-ietf-mpls-spring-entropy-label has been published as RFC 8662 281 [I-D.ietf-spring-segment-routing-mpls] 282 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 283 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 284 data plane", draft-ietf-spring-segment-routing-mpls-22 285 (work in progress), May 2019. == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 [minor] This reference can be Informative. ... 326 10.2. Informative References 328 [I-D.ietf-ospf-segment-routing-extensions] 329 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 330 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 331 Extensions for Segment Routing", draft-ietf-ospf-segment- 332 routing-extensions-27 (work in progress), December 2018. == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665
- [Lsr] AD Review of draft-ietf-ospf-mpls-elc-12 Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-ospf-mpls-elc-12 Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-ospf-mpls-elc-12 Alvaro Retana