Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

[Padma Pillay-Esnault <[e-mail]>]

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 <[e-mail]>
wrote:

> On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault (
> [e-mail]) 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.
>
>