Hi Alvaro Thanks for the thorough review.
I went through all the minor and nits and agree and will make the changes. Therefore I will only discuss here the 2 major comments to be addressed. Please see below PPE On Fri, Sep 20, 2019 at 1:11 PM Alvaro Retana <[email protected]> wrote: > On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault ( > [email protected]) 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. > > PPE > I agree that the the specification should be singular. I propose this change OLD: Therefore, non-local IPv4 prefixes, e.g., those exported from other routing protocols, MUST NOT be advertised in AS- external-LSAs for routers acting permanently as a host. NEW: Therefore, non-local IPv4 prefixes, e.g., those exported from other routing protocols, SHOULD NOT be advertised in AS- external-LSAs for routers acting permanently as a host. The last sentence below the MUST is correct to correctly repel. Current : In addition to the procedure described above, temporary host routers advertising type 2-metric External LSAs MUST set the metrics to LSInfinity to repel traffic.(see Section 6 of this document). (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. > > PPE > OK. I am fine with this proposed change and I will remove the last bullet. Thanks Padma 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. > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
