[Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

[Alvaro Retana <[e-mail]>]

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.