Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt
Alvaro Retana <aretana.ietf@gmail.com> Fri, 20 September 2019 20:11 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 5D7C11208BF for <lsr@ietfa.amsl.com>; Fri, 20 Sep 2019 13:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 hvjmMkbNO5vu for <lsr@ietfa.amsl.com>; Fri, 20 Sep 2019 13:11:38 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 B14B2120099 for <lsr@ietf.org>; Fri, 20 Sep 2019 13:11:37 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id v38so7561362edm.7 for <lsr@ietf.org>; Fri, 20 Sep 2019 13:11:37 -0700 (PDT)
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=3JqV5wy5PcgVAJhIomNJjBvys4sz7OCFkHHLIWy0MRA=; b=RP3iN+5xiBvcrSCBN2DFHvEbCUPDNc5q8DySc4iMJNYYgQYjUHs8rodBAG6ufCmcFG eZqGpRRk1Zlv0FguQoWJLbvfOQzDj5jF9izsoBaRGxqY06qlqqa/3kM9PJoL2bo/cwlt sns/u6Oj4N09RY9tblqd9JQtqRB6xUOkFxXRNr/29XZVm5oEtMtU/Rm1BzCQo1nsKYkE jTIPyW0Y2/Cygr5Z0o72TLNwklsVW9qBCPyHJxcVpnIfeflGyWXbsnYXhhcnLMOnYWZT LcD3Ka0gDayRkUuCRL6Ue1J8n18hnQGwwPDlr2tv1OJpjCZBO4AJn6yQ0kL2XiZ8sNNy AkOA==
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=3JqV5wy5PcgVAJhIomNJjBvys4sz7OCFkHHLIWy0MRA=; b=M9sK05oV5LxJtprrKfXpk0nmaK/g2OwPtc2X8q8+hqdmX15G+4gkTZLReCTctBTrdZ zWMQXrY4caeN/dUw4FeUPlABMjai+nN1mDkY+EREGCt9IssxjtGUx2dFW40p9tQ6mg65 kVcHK664IJJ+9CzeFC4ukQR74xbMXVAZKsG2MCIfxLeWWF9Q22xdYy4V0hS/JGZzEXa5 vAL/TZIGZPF2GfLoiKVed8aUQ32OsFWFR1uYz8r4TQQ0aJgLUINVSOHJL6KUEKHB1T+B 92Ayx9/pg9nc3FYCilV+KwqpRY4xJ/cyGNK4VZ+CnvzwIDlmWZu3ZfcgPWkQk7q8PeDq LQrQ==
X-Gm-Message-State: APjAAAW8PuU6RhgPHAGKYVuiTugH2MuQ2Y4UhZPmPEPp5JDIf7vBLQoj naQWYIXVYWfqvxFOE0dg2cNlOlvx4V99ty/rqb4=
X-Google-Smtp-Source: APXvYqxTahEW3Zz1r0URh5wzjtObNd2qXJuvIZHHaleI9s3QjObd3sTP8f00ttdWNdeLo3+z0xhV1rHmcJXIkxS7qKI=
X-Received: by 2002:a50:e719:: with SMTP id a25mr23990988edn.258.1569010295995; Fri, 20 Sep 2019 13:11:35 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 20 Sep 2019 13:11:35 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com>
References: <156843700176.32063.1393096099535829916.idtracker@ietfa.amsl.com> <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com> <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 20 Sep 2019 13:11:35 -0700
Message-ID: <CAMMESsyqP4w3m6E_CFXfRvAO99ihXJuEzTL+3b3fT=s051LqAw@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>, manbhard@cisco.com, "Acee Lindem (acee)" <acee@cisco.com>, Keyur Patel <keyur@arrcus.com>, "Serpil Bayraktar (serpil)" <serpil@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000578264059301ad76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zs4cfS9z7vXbK_sNHku4-66nEQg>
Subject: Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt
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: Fri, 20 Sep 2019 20:11:40 -0000
On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault ( padma.ietf@gmail.com) wrote: FYI the draft is posted. Padma: Hi! Thanks for the revision! I went through the changes and have some mostly-editorial nits/minor comments (see below, based on -09). There are a couple of major items, introduced by the new text, that should be addressed before moving on: (1) §3 (last paragraph) introduces different behavior for permanently vs temporarily acting as a host. From the point of view of the H-bit, what is the difference? It seems to me that in both cases the H-bit would be set: the router would be acting as a host NOW. How long it keeps the H-bit set seems to be the distinction between permanent and temporary...but the behavior should not change because of that. IOW, the specification of what happens when the H-bit is set should be singular -- you may be able to soften some of the MUSTs (to SHOULD) if the exceptions are justified other than using time. (2) The last bullet in §5...adds the fact that support for the H-bit can be verified from the RI LSA *or* the router-LSA itself. That fact is not considered before: if the RI LSA hasn't been received (or doesn't include the new capability), but the router-LSA does have the H-bit set, should it be assumed that the router supports the capability? Because this option hasn't been mentioned before (requiring the capability to be advertised), I think we should simply eliminate that last bullet. Thanks! Alvaro. [Line numbers from idnits.] ... 14 Abstract 16 The Open Shortest Path First Version 2 (OSPFv2) does not have a 17 mechanism for a node to repel transit traffic if it is on the 18 shortest path. This document assigns a new bit (Host-bit) in the 19 OSPF Router-LSA bit registry and in the OSPF Router Informational 20 Capability Bits Registry that enables a host router to advertise that 21 it is a non-transit router. It also describes the changes needed to 22 support the Host-bit in the domain. In addition, this document 23 updates OSPF Stub Router Advertisement (RFC6987) to advertise for 24 type-2 External and NSSA LSAs with a high cost in order to repel 25 traffic effectively. [minor] s/This document assigns a new bit (Host-bit) in the OSPF Router-LSA bit registry and in the OSPF Router Informational Capability Bits Registry that enables a host router to advertise that it is a non-transit router./This document defines a new bit (Host-bit) that enables a router to advertise that it is a non-transit router." [nit] s/to advertise for type-2/to advertise type-2 [minor] s/OSPF Stub Router Advertisement (RFC6987)/RFC 6987 ... 75 1. Introduction ... 105 This document describes the Host-bit (H-Bit)functionality that 106 prevents other OSPFv2 routers from using the router for transit 107 traffic in OSPFv2 routing domains. This document defines the Host- 108 bit in the OSPFv2 Router Properties Registry and if the host-bit is 109 set then the calculation of the shortest-path tree for an area, as 110 described in section 16.1 of [RFC2328], is modified by including a 111 new check to verify that transit vertices DO NOT have the host-bit 112 set. [nit] s/(H-Bit)functionality/(H-Bit) functionality [minor] s/This document defines the Host-bit in the OSPFv2 Router Properties Registry and if the host-bit is set then the calculation of the shortest-path tree...transit vertices DO NOT have the host-bit set./If the host-bit is set then the calculation of the shortest-path tree...transit vertices DO NOT have the host-bit set (see Section 4). [nit] Please be consistent: Host-bit, host-bit, H-bit... [minor] Add some text here (with a forward reference to Section 6) about the Update to rfc6987. ... 122 3. Host-bit Support 124 This document defines a new router-LSA bit known as the Host Bit or 125 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 126 set indicates that it MUST NOT be used as a transit router (see 127 section 4) by other OSPFv2 routers in the area supporting the 128 functionality. [nit] s/section 4/Section 4 130 If the host-bit is NOT set routers MUST act transit routers as 131 described in [RFC2328] ensuring backward compatibility. [minor] I don't think there's really Normative value in using MUST to say: "behave as always". I would even go as far as removing the sentence...but if you want to keep it, here's a suggestion... NEW (suggestion)> If the H-bit is not set then backwards compatibility is achieved as the behavior will be the same as in [RFC2328]. ... 166 Host Bit in Router-LSA 168 0 1 2 3 4 5 6 7 169 +-+-+-+-+-+-+-+-+ 170 |H|0|0|N|W|V|E|B| 171 +-+-+-+-+-+-+-+-+ 173 Host Bit [minor] Label this figure too. 175 Bit H is the high-order bit of the OSPF as shown above. When set, an 176 OSPFv2 router is a Host (non-transit) router and is incapable of 177 forwarding transit traffic. In this mode, the other OSPFv2 routers 178 in the area MUST NOT use the host router for transit traffic, but use 179 the host router only for its local destinations. [minor] "Bit H is the high-order bit of the OSPF as shown above." Of the OSPF what?? [minor] s/but use the host router only for its local destinations./but may send traffic to its local destinations. 181 An OSPFv2 router originating a router-LSA with the H-bit set MUST 182 advertise all its router links with a link cost of MaxLinkMetric 183 [RFC6987]. This is to increase the applicability of the H-bit to 184 partial deployments where it is the responsibility of the operator to 185 ensure that OSPFv2 routers not supporting the H-bit do not install 186 routes causing routing loops. [minor] s/advertise all its router links/advertise all its non-stub links [minor] I see that §5 has the same text, and it is explicitly talking about partial deployments. Let's take the second sentence out (the explanation will come later). [nit] s/routing loop/forwarding loop/g 188 When the H-bit is set, an Area Border Router (ABR) MUST advertise the 189 same H-bit setting in its self-originated router-LSAs for all 190 attached areas. The consistency of the setting will prevent inter- 191 area traffic transiting through the router by suppressing 192 advertisement of prefixes from other routers in the area in its 193 summary LSAs. Only IPv4 prefixes associated with its local 194 interfaces MUST be advertised in summary LSAs to provide reachability 195 to end hosts attached behind a router with the H-bit set. [nit] s/summary LSAs/summary-LSAs [nit] s/attached behind a router/attached to a router 197 When the H-bit is set the host router cannot act as an AS Boundary 198 Router (ASBR). Indeed, ASBR are transit routers to prefixes that are 199 typically imported through redistribution of prefixes of other 200 routing protocols. Therefore, non-local IPv4 prefixes, e.g., those 201 exported from other routing protocols, MUST NOT be advertised in AS- 202 external-LSAs for routers acting permanently as a host. However, in 203 use cases such as an overloaded router or a router being gracefully 204 isolated, these routers are only temporarily acting as host routers 205 and therefore SHOULD continue to advertise their External LSAs but 206 ensure that they do not attract traffic. In addition to the 207 procedure described above, temporary host routers advertising type 208 2-metric External LSAs MUST set the metrics to LSInfinity to repel 209 traffic.(see Section 6 of this document). [minor] s/exported/imported [minor] s/MUST NOT be advertised in AS-external-LSAs for routers acting permanently as a host./MUST NOT be advertised in AS-external-LSAs if the H-bit is set. [major] The new text introduces different behavior for permanently vs temporarily acting as a host. From the point of view of the H-bit, what is the difference? It seems to me that in both cases the H-bit would be set: the router would be acting as a host NOW. How long it keeps the H-bit set seems to be the distinction between permanent and temporary...but the behavior should not change because of that. IOW, the specification of what happens when the H-bit is set should be singular -- you may be able to soften some of the MUSTs (to SHOULD) if the exceptions are justified other than using time. ... 237 5. Auto Discovery and Backward Compatibility 239 To avoid the possibility of any routing loops due to partial 240 deployment, this document defines a OSPF Router Information (RI) LSA 241 [RFC7770] with and an area flooding scope and a new bit assigned in 242 the OSPF Router Informational Capability Bits Registry. Bit: [nit] s/avoid/reduce [minor] s/defines a OSPF Router Information (RI) LSA [RFC7770] with and an area flooding scope and a new bit assigned in the OSPF Router Informational Capability Bits Registry. Bit:/defines an OSPF Router Information (RI) LSA [RFC7770] capability. The RI LSA MUST be area-scoped. 244 Bit Capabilities 246 7 Host Router Support capability [nit] Name this table. ... 253 In normal operations, there is no guarantee that the RI LSA will 254 reach all routers in an area in a timely manner that may result in 255 rooting loops in partial deployments. For example, in a new router 256 joins an area which previous had only H-bit capable routers with 257 H-bit set then it may take some time for the RI to propagate to all 258 routers. [nit] s/operations,/operation [nit] s/manner that may result in rooting loops/manner, which may result in forwarding loops [nit] s/in a new router/if a new router [nit] s/which previous had only H-bit capable routers with H-bit/which previously had only H-bit capable routers with the H-bit ... 268 o All routers, with the H-bit set, MUST advertise all of the 269 router's non-local links with a metric equal to MaxLinkMetric in 270 its LSAs in order to avoid OSPFv2 (unless last resort) routers not 271 supporting the H-bit from attempting to use it for transit 272 traffic. [minor] s/router's non-local links/router's non-stub links [minor] s/MaxLinkMetric/MaxLinkMetric [RFC6987] 274 o All routers supporting H-Bit MUST check all the RI LSAs of nodes 275 in the area before actively running the modified SPF to account 276 for the H-bit in order to verify that all routers are in routing 277 capability. If any router does not have the H-Bit support then 278 all routers in the areas MUST run the normal SPF. [minor] s/If any router does not have the H-Bit support then all routers in the areas MUST run the normal SPF./If any router does not advertise the Host Router Support capability then the SPF Modifications (Section 4) MUST NOT be used in the area. 280 o Any router not supporting the H-bit capability is detected (by 281 examination of RI- LSA or RTR LSA in the area database) then all 282 routers in the area MUST revert back to normal operations. [major] This last paragraph is a repetition of the one before it. But it adds the fact that support can be verified from the RI LSA *or* the router-LSA itself. That fact is not considered before: if the RI LSA hasn't been received (or doesn't include the new capability), but the router-LSA does have the H-bit set... 284 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 286 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with 287 a Type-2 metric, the advertised Type-2 metric is taken as more 288 significant than the OSPF intra-area or inter-area path. Hence, 289 advertising the links with MaxLinkMetric as specified in [RFC6987] 290 does not discourage transit traffic when calculating AS external or 291 NSSA routes with Type-2 metrics. [minor] s/NSSA-LSA/NSSA-LSA [RFC3101] Also, please add an Informative reference. 293 Consequently, OSPF routers implementing [RFC6987] and required to be 294 the last resort transit then they MUST advertise a Type-2 metric of 295 LSInfinity-1 for any self-originated type 2 AS-External-LSAs or NSSA- 296 LSAs. However, in situations, the router needs to repel traffic and 297 acts as a host router then, in addition of the host bit procedure 298 described in this document they MUST advertise a Type-2 metric of 299 LSInfinity for any self-originated type 2 AS-External-LSAs or NSSA- 300 LSAs. [major] I think the text above is confusing because of the parts about "required to be the last resort transit" or "needs to repel traffic", which are not easily verified and normatively hard to enforce. Also, rfc6987 doesn't use rfc2119 keywords... NEW> Consequently, [RFC6987] is updated so that the Type-2 metric in any self-originated AS-External-LSAs or NSSA-LSAs is advertised as LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric MUST be set to LSInfinity. 302 7. IANA Considerations ... 311 This document requests the IANA to assign the Bit Number value of 7 312 to the Host Router Support Capability in the OSPF Router 313 Informational Capability Bits Registry. [RFC7770] [nit] That reference is not needed. ... 319 8. Security Considerations 321 This document introduces the H-bit which is a capability that 322 restricts the use of a router for transit except for its local 323 destinations. This is a subset of the operations of a normal router 324 and therefore should not introduce new security considerations beyond 325 those already known in OSPF. The feature, however does introduce the 326 flooding of a capability information that allows discovery and 327 verification that all routers in an area are capable before turning 328 on the feature. In the event that a rogue or buggy router advertises 329 incorrectly its capability there are two possible cases: [minor] s/transit except for its local destinations./transit, while only its local destinations are reachable. [nit] s/known in OSPF/known in OSPF [RFC2328] 331 o The router does not have the capability but sends H-Bit set in its 332 LSAs: In this case, there is a possibility of a routing loop. 333 However this is mitigated by the fact that this router should be 334 avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) 335 of this router will mitigate this situation. In any case, a 336 router advertising the H-bit capability without its links cost 337 equal to MaxLinkMetric may be an indicator that this is a rogue 338 router and to be avoided. [nit] s/sends H-Bit/sends the H-Bit [minor] s/and to be avoided/and should be avoided 340 o The router has the capability but sends the H-Bit clear in its 341 LSAs: In this case, the router merely prevents support of other 342 H-bit routers in the area and all the routers to run the modified 343 SPF. The impact is also mitigated as other H-Bit routers in the 344 area also advertise MaxLinkMetric cost so they will still be 345 avoided unless they are the last resort path.
- Re: [Lsr] Fwd: New Version Notification for draft… Alvaro Retana
- Re: [Lsr] Fwd: New Version Notification for draft… Alvaro Retana
- Re: [Lsr] Fwd: New Version Notification for draft… Padma Pillay-Esnault
- Re: [Lsr] Fwd: New Version Notification for draft… Alvaro Retana
- Re: [Lsr] Fwd: New Version Notification for draft… Padma Pillay-Esnault