[Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06
Alvaro Retana <aretana.ietf@gmail.com> Wed, 28 November 2018 15:52 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 B8BAB129385; Wed, 28 Nov 2018 07:52:45 -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 8pjrRgBkKZuM; Wed, 28 Nov 2018 07:52:41 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 A3D94128CF3; Wed, 28 Nov 2018 07:52:38 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id f18so22351172otl.11; Wed, 28 Nov 2018 07:52:38 -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; bh=tZUPHAUkU+L0mjjIFOxeL5ImEwdn6k3rXmjDm7EHj+k=; b=BddX7bMB0YISGW9rghIY2n07eAEeXvinRo9paxhoVuCJLnN5bzL8vc1GzhMaSiO7de CcuCINztCUeSqaFdudcJWjUnOIsMiNpVZzrye3tD0rzzOBSiYl9AiGgTt/Na9cF7h5BS pMHeVtimS7dDpVcGzLGeytub4YhP0T8WWa0rrnyQaHebQdpLJcX0sSzFIyVUaR5TzMYy En7VJdhufaQw0dNuzradIW0g7HG/QaFKFrYPCukc4tY2TrGsGnUbS1KPb9Hd/DGguShp e3fFizIltMAnKUF053YDyhqudMqvGCmKCT8bbs16zEThW5er3eBTP1zWdACjt2bMnvzV q8IQ==
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=tZUPHAUkU+L0mjjIFOxeL5ImEwdn6k3rXmjDm7EHj+k=; b=WXqEb658d/4BNMlG7N1NOWcshHbmPWFBmFGIcjukprjoFdtt/OWkpGnpQIBwerO2oK htwVY/svYTqa4HIQAWyiNkLGuXKCteNbux/ZzkQCPUIOJrtXhH4Q0ip+ywSZVg1677Ey CjUMtkD9Y/uKW//qWajEAnYI5rHr7xEI3TQAG84ziWZj270mD3oXZ110iufjqudqZNqS vUf+QAmqWjKyqXMEcVT1AwkNV0ueDaK4vm2JYPlgG+JFinsDuD2rFfFtri3j7KaI4yi4 /Pe9nOTRE7Pn9U2WwF7jNSPtIS/yiplBrKyty8+Q9f96f1WNg2CNgQy9TLBcxn90jJ68 noyw==
X-Gm-Message-State: AGRZ1gKIZNNPTrYhKUJI9rtCK4LdoSLVm43eQ7no7SVGcrTXcEqYc4th DDqUYFuVOBUSn/09SdEIHugNyYufw5cWGvILuCfpMA==
X-Google-Smtp-Source: AFSGD/X90/4MsVoKMQGr4wdCCSy6KsJ0V1L9zuYgvI4VEAa9hXj0Lf2PKXPDEC/0eIDWYnWlSv6lhWzVDx7FQvIvabA=
X-Received: by 2002:a9d:588c:: with SMTP id x12mr21819889otg.139.1543420357244; Wed, 28 Nov 2018 07:52:37 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Nov 2018 07:52:35 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 28 Nov 2018 07:52:35 -0800
Message-ID: <CAMMESsxauJAHnmDjKhRRevWrYY3ddSK5Rme_Z8RR=_1tiW-3=Q@mail.gmail.com>
To: draft-ietf-ospf-ospfv2-hbit@ietf.org
Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>, lsr@ietf.org, lsr-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000021fd3f057bbb8eb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LkYCwSPRhxGQIPzPmjz2uka6pMk>
Subject: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06
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, 28 Nov 2018 15:52:46 -0000
Dear authors: I just finished reading this document. Even though it is relatively short, I have significant concerns and I think it needs more work. Please take a look at the detailed comments in-line below -- I'm highlighting some of the issues here. (1) What is the Update to rfc2328? Please be specific in both the Abstract and the Introduction to indicate how rfc2328 is Updated. Also, see my question about rfc6987 in §6. (2) Operational/Deployment Considerations. There are several places (specially in §3) where the specification offers a choice (e.g. by using MAY). Some of those choices would be better informed if there was a discussion of the considerations behind them. Please take a look at rfc5706 (specially §2). Either a discussion close to where the behavior is specified or a separate section is ok. Please also keep migration in mind (see comments in §5). (3) Both the IANA and Security Considerations sections need more details. I will wait for them to be addressed before starting the IETF Last Call. Thanks! Alvaro. [The line numbers come from idnits.] ... 11 H-bit Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-06 [nit] Please make the title more descriptive. "non-transit router", "host mode", etc. come to mind. 14 Abstract 16 OSPFv3 defines an option bit for router-LSAs known as the R-bit in 17 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in 18 OSPF topology flooding, however it will not be used as a transit 19 router. In such cases, other routers in the OSPFv3 routing domain 20 only install routes to allow local traffic delivery. This document 21 defines the H-bit functionality to prevent other OSPFv2 routers from 22 using the router for transit traffic in OSPFv2 routing domains as 23 described in RFC 2328. This document updates RFC 2328. [minor] Describing the functionality in terms of OSPFv2 would have been nice. IOW, there's no need (in the Abstract) to force the reader to go figure out what OSPFv3 already did to decide if it's worth reading this document or not. [major] What is the Update to rfc2328? Please be specific, both here and in the Introduction: don't just mention the section updated, but (more important) what is the update about. "This document updates rfc2328 by assigning a bit...changing the SPF process...creating a registry..." All/none/something else? Note that the answer to "what is the update?" doesn't have to be all. I think that the registry creation is a must. But Updating because of the SPF changes means that you expect an rfc2328 implementation to consider the H-bit when running SPF. I think you really mean that implementations of this document (i.e. not all rfc2328 implementations) have to use the modified SPF. That is my guess...please consider the answer carefully. ... 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. [major] As far as I can tell, the first version of draft-keyupate-ospf-ospfv2-hbit (the predecessor of this document) was published in 2015. So the copyright text above doesn't apply. Are we missing other predecessors? If not, then this issue should be easy to fix. In at least the XML editor that I use, there's an option to indicate pre-RFC5378 work, or not. In this case it seems like it should be No. ... 85 1. Introduction [minor] Same comment as for the Abstract: describing the functionality in terms of OSPFv2 would have been nicer. You can still make the reference to the R-bit at the end, if you really want to. 87 OSPFv3 [RFC5340] defines an option bit for router-LSAs known as the 88 R-bit. If the R-bit is clear, an OSPFv3 router can participate in 89 OSPFv3 topology flooding without acting as a transit router. In such 90 cases, other routers in the OSPFv3 routing domain only install routes 91 used for local traffic. 93 This functionality is particularly useful for BGP Route Reflectors, 94 known as virtual Route Reflectors (vRRs), that are not in the 95 forwarding path but are in central locations such as data centers. 96 Such Route Reflectors typically are used for route distribution and 97 are not capable of forwarding transit traffic. However, they need to 98 learn the OSPF topology for: 100 1. SPF computation for Optimal Route Reflection functionality as 101 defined in [I-D.ietf-idr-bgp-optimal-route-reflection] 103 2. Reachability resolution for its Route Reflector Clients. [nit] Clearly route reflection is not the only motivation for this work. The justification only related to RRs seems gratuitous. Just a nit... 105 This document defines the R-bit functionality equivalent for OSPFv2 106 defined in [RFC2328] by introducing a new router-LSA bit known as the 107 "H-bit". This document updates appendix A.4.2 of RFC 2328. [nit] s/OSPFv2 defined in [RFC2328]/OSPFv2 [RFC2328] It sounds as if "the R-bit functionality equivalent for OSPFv2" is already in rfc2328. [major] Please be specific about what the Update is. ... 117 3. H-bit Support 119 This document defines a new router-LSA bit known as the Host Bit or 120 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 121 set indicates to other OSPFv2 routers in the area supporting the 122 functionality that it MUST NOT be used as a transit router. The bit 123 value usage of the H-bit is reversed from the R-bit defined in OSPFv3 124 [RFC5340] to support backward compatibility. The modified OSPFv2 125 router-LSA format is: [minor] "...MUST NOT be used as a transit router" Put a forward reference to §4. [nit] The text keeps making reference to the R-bit. Even though there is a relationship, the H-bit is an independent feature. IOW, I don't think there's a need to explain the relationship to OSPFv3. [minor] On the same topic: The comparison to OSPFv3 is made and the "reverse" bit setting is justified "to support backward compatibility", but that is not explained anywhere. I was hoping that §5 (Auto Discovery and Backward Compatibility) would say something, but it doesn't. 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | LS age | Options | 1 | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Link State ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Advertising Router | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | LS sequence number | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | LS checksum | length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |H|0|0|N|W|V|E|B| 0 | # links | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Link ID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Link Data | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | # TOS | metric | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | ... | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | TOS | 0 | TOS metric | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Link ID | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Link Data | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ... | 158 bit H 159 When set, an OSPFv2 router is a non-transit router and is 160 incapable of forwarding transit traffic. [nit] Please label the figure: Figure 1... [minor] Even though it seems obvious from the figure, please be explicit in saying that the H-bit is the first bit (or however that bit is identified)... 162 When the H-bit is set, an OSPFv2 router is a non-transit router and 163 should not be used to forward transit traffic. In this mode, the 164 other OSPFv2 routers in the area SHOULD NOT use the originating 165 OSPFv2 router for transit traffic, but MAY use the OSPFv2 router for 166 local traffic destined to that OSPFv2 router. [minor] The first/second sentences seem redundant: "should not be used to forward transit traffic...SHOULD NOT use the originating OSPFv2 router for transit traffic". [major] When would the non-transit router be used for transit? IOW, why use "SHOULD NOT" and not "MUST NOT"? [major] "MAY use the OSPFv2 router for local traffic destined to that OSPFv2 router" I'm not sure what behavior is being specified here. The text sounds as if it was optional to even consider the router as a traffic destination. Is that the intent? Why? What would make a network operator decide one way or the other? 168 An OSPFv2 router originating a router-LSA with the H-bit set SHOULD 169 advertise all its non-local router links with a link cost of 170 MaxLinkMetric as defined in Section 3 of [RFC6987]. This is to 171 increase the applicability of the H-bit to partial deployments where 172 it is the responsibility of the operator to ensure that OSPFv2 173 routers not supporting the H-bit do not install routes causing 174 routing loops. [major] When would a router not advertise MaxLinkMetric? IOW, why use SHOULD and not MUST? [major] What are "non-local router links"? I always thought of links to be local to the router...what am I missing? [nit] s/advertise all its non-local router links with a link cost of MaxLinkMetric as defined in Section 3 of [RFC6987]/advertise all its non-local router links with a link cost of MaxLinkMetric [RFC6987] 176 When the H-bit is set, IPv4 prefixes associated with local interfaces 177 in other areas MAY be advertised in summary LSAs. Non-local IPv4 178 prefixes, e.g., those advertised by other routers and installed 179 during the SPF computation, MAY be advertised in summary-LSAs if 180 configured by policy. Likewise, when the H-bit is set, only IPv4 181 prefixes associated with local interfaces MAY be advertised in AS- 182 external LSAs. Non-local IPv4 prefixes, e.g., those exported from 183 other routing protocols, MUST NOT be advertised in AS-external-LSAs. 184 Finally, when the H-bit is set, an Area Border Router (ABR) MUST 185 advertise a consistent H-bit setting in its self-originated router- 186 LSAs for all attached areas. [minor] Some of the behavior specified in this paragraph may be non intuitive -- for example: "When the H-bit is set, IPv4 prefixes associated with local interfaces in other areas MAY be advertised in summary LSAs." During normal operation (aka rfc2328), these prefixes are always advertised (assuming normal areas, etc.)...and given that these are local to the router, it can be argued that one is not using the router as transit...on the other hand, going to a different area can be interpreted as transit. In either case, it would be nice if more was said about the optional nature of including these prefixes in the summary LSA. What are the operational considerations? [minor] The same comment for "prefixes associated with local interfaces MAY be advertised in AS-external LSAs". [major] "Non-local IPv4 prefixes...MAY be advertised in summary-LSAs if configured by policy." Doesn't advertising result in the router being transit? Doesn't it defeats the purpose of setting the H-bit? But there may be operational reasons to do so -- e.g. if the router is the only ABR... [major] "Non-local IPv4 prefixes...MUST NOT be advertised in AS-external-LSAs." This behavior seems consistent with the purpose of the H-bit, but not with the rest of the paragraph. Again, why is this different (operationally) than transiting for non-external inter-area prefixes. [major] "...an Area Border Router (ABR) MUST advertise a consistent H-bit setting in its self-originated router-LSAs for all attached areas." What do you mean by "consistent"? Do you mean "the same", i.e. be non-transit for all areas? Do you mean "compatible", i.e. so that the setting avoids potential loops or black holes? Please be specific. And please explain why -- again, what are the operational considerations? ... 214 5. Auto Discovery and Backward Compatibility 216 To avoid the possibility of any routing loops due to partial 217 deployment, this document defines a OSPF Router-Information LSA 218 functional capability bit known as the Host Support capability. [minor] A reference to rfc7770 would be nice. [mayor] I'm guessing that the RI LSA MUST be area-scoped, right? Please be specific. 220 Auto Discovery via announcement of the Host Support Functional 221 Capability ensures that the H-bit functionality and its associated 222 SPF changes SHOULD only take effect if all the routers in a given 223 OSPF area support this functionality. [major] When can the functionality take effect even if not all routers in the area support it? Or maybe it is that it won't take effect even if all routers support it... IOW, why SHOULD and not MUST? [major] There's no guarantee that the RI LSA will reach a router before the route-carrying LSAs -- which I think implies that SPF could be run before verifying full H-bit support. The result may be a loop...or a loop may exist until the lack of area-wide support is verified... IOW, it seems to me that this auto discovery mechanism may not work as expected. Migration is an important Deployment Consideration. [major] What is the process to verify area-wide support? Should the router build a tree...run SPF...inspect the LSAs...?? I'm assuming/hoping that this is a common enough operation that it is specified already somewhere else... 225 Implementations are encouraged to provide a configuration parameter 226 to manually override enforcement of the H-bit functionality in 227 partial deployments where the topology guarantees that OSPFv2 routers 228 not supporting the H-bit do not compute routes resulting in routing 229 loops. More precisely, the advertisement of MaxLinkMetric for the 230 router's non-local links will prevent OSPFv2 routers not supporting 231 the H-bit from attempting to use it for transit traffic. [minor] The text seems to indicate what the second sentence is a clarification of the first one: "Implementations are encouraged to... More precisely..." But in reality you are talking about two different things: the ability to consider the H-bit even in partial deployments, *and*, advertising MaxLinkMetric. Please consider rewording to clarify. 233 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 235 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with 236 a Type-2 metric, the advertised Type-2 metric is taken as more 237 significant than the OSPF intra-area or inter-area path. Hence, 238 advertising the links with MaxLinkMetric as specified in [RFC6987] 239 does not discourage transit traffic when calculating AS external or 240 NSSA routes. Consequently, OSPF routers implementing [RFC6987] or 241 this specification should advertise a Type-2 metric of LSInfinity for 242 any self-originated AS-External-LSAs or NSSA-LSAs in situations when 243 the OSPF router is acting as a stub router [RFC6987] or implementing 244 this specification. [major] Should there be Normative language in this paragraph? [major] This paragraph talks about what a stub router (rfc6987) should do. In order to do that, this document should be tagged to Update rfc6987. Is that the intent? 246 7. IANA Considerations 248 IANA is requested to create the OSPF Router-LSA bit registry with the 249 following assignments: 251 Value Description Reference 252 0x01 Area Border Router (B-bit) [RFC2328] 253 0x02 AS Boundary Router (E-bit) [RFC2328] 254 0x04 Virtual Link Endpoint (V-bit) [RFC2328] 255 0x08 Historic (W-bit) [RFC1584] [major] Even though rfc1584 is classified as Historic, that doesn't mean that the bit is as well, or that it has been deprecated (at least I didn't see that in rfc5110). Please put a name to it -- "wild-card multicast"? 256 0x10 Unconditional NSSA Translator (Nt-bit) [RFC3101] 257 0x20 Unassigned 258 0x40 Unassigned 259 0x80 Host (H-bit) This Document [major] What should be the assignment policy (rfc8126)? [minor] Besides the 8 bits above, the Router-LSA (rfc2328) has another 8 bits (to the right) that seem unassigned...should they be included in this registry as well? [major nit] I couldn't find where rfc2328 talks about the value of these bits being 0 and what to do if they are not. By creating this new registry, you have the opportunity to (at least) clarify that. 261 This document also defines a new Router Functional Capability 262 [RFC7770] known as the Host Support Functional Capability. This 263 document requests IANA to allocate the value of this capability from 264 the Router Functional Capability Bits TLV. [minor] s/TLV/Registry 266 8. Security Considerations 268 This document introduces no new security considerations beyond those 269 already specified in [RFC6987], [RFC2328], and [RFC5340]. [major] <SecDir hat on> [*] This section says nothing! rfc6987 has no Security Considerations to speak of (sorry!)...rfc2328's Security Considerations only talk about authentication, and there's no mention of rfc5709 or rfc7474...and rfc5340 doesn't apply because this document is not about OSPFv3 -- also, rfc5340 doesn't have specific Security Considerations related to the R-bit. <hat off> [*] I don't really have a SecDir hat...just pretending I do. Suggestion: tell the reader why there are no new security considerations. "This document introduces functionality to do a, b, and c... Non of that affects security..." Of course, more words would be nice. There is one specific item that I think should be mentioned as a risk. §5 talks about using Auto Discovery "to avoid the possibility of any routing loops due to partial deployment". Even with proper authentication, there is the possibility that a (rogue) router can advertise the Host Support capability without really supporting it (there's no way to verify!!). The result can be a loop... I don't think this issue can be mitigated, but mentioning it would go a long way in demonstrating that you at least thought about the issues. ... 279 10.1. Normative References ... 290 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 291 RFC 3101, DOI 10.17487/RFC3101, January 2003, 292 <https://www.rfc-editor.org/info/rfc3101>. 294 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 295 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 296 <https://www.rfc-editor.org/info/rfc5340>. [minor] These 2 references can be Informative. ... 307 10.2. Informative References ... 319 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 320 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 321 DOI 10.17487/RFC6987, September 2013, 322 <https://www.rfc-editor.org/info/rfc6987>. [major] Because of the specification of the use of MaxLinkMetric, this reference has to be Normative. rfc6987 is already in the DownRef registry.
- [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06 Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbi… Padmadevi Pillay Esnault
- Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbi… Acee Lindem (acee)
- Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbi… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbi… Keyur Patel