Host Router Support for OSPFv2
RFC 8770
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Alvaro Retana Yes
Roman Danyliw No Objection
Éric Vyncke (was Discuss) No Objection
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-) The deployment issue (section 5) had raised a DISCUSS of mine and I appreciated your reply, so, I have cleared this DISCUSS. Feel free to ignore my COMMENTs and NIT. == COMMENTS == -- Generic -- Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful. -- Section 1 -- A description of "Closet Switches" would be welcome. -- Section 3 -- Isn't the wording "host router" an oxymoron ? == NITS == -- Section 8 -- I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations)
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
I'm going to complain about some wording in Section 5 that Ben already called out, but I'll try to put in some specific suggestions for corrections here:
In normal operation, there is no guarantee that the RI LSA will reach
all routers in an area in a timely manner, which may result in
forwarding loops in partial deployments.
This wording makes it sound exactly the opposite of what you mean, that if the RI LSA *does* reach all routers in a timely manner it can cause forwarding loops. I suggest this:
NEW
In normal operation, it is possible that the RI LSA will fail to
reach all routers in an area in a timely manner. That can result
in forwarding loops in partial deployments.
END
For example, if a new
router joins an area, which previously had only H-bit capable routers
with H-bit set then it may take some time for the RI to propagate to
all routers.
First, change "area, which" to "area that" (no comma). That fixes a usage problem.
But second, Ben and I are both unsure whether you mean that the new router does or doesn't support the H bit, or whether it matters. Maybe the right approach here is to say a little more about what happens. Something like this (adjust as needed to make it correct):
NEW
For example, if a new
router joins an area that previously had only H-bit capable routers
with H-bit set then it may take some time for the RI to propagate to
all routers. While it is propagating, the area as a whole is unsure of
the status of the new router, and that can cause <what problem?>
END
o All routers, with the H-bit set, MUST advertise all of the
router's non-stub links with a metric equal to MaxLinkMetric
Both commas need to be removed here.
o All routers supporting H-Bit MUST check all the RI LSAs of nodes
in the area before actively running the modified SPF to account
for the H-bit in order to verify that all routers are in routing
capability.
This is very awkwardly worded and is really hard to decipher. I *think* you mean to say this:
NEW
o All routers supporting the H-Bit MUST check the RI LSAs of all
nodes in the area to verify that all nodes support the H-Bit before
actively using the H-Bit feature.
END
Did I get that right?
(Benjamin Kaduk; former steering group member) No Objection
Abstract
The Open Shortest Path First Version 2 (OSPFv2) does not have a
mechanism for a node to repel transit traffic if it is on the
shortest path. This document defines a bit (Host-bit) that enables a
nit: I suggest to add "protocol" after "(OSPFv2)" to match the definite
article "The".
Section 1
The OSPFv2 specifies a Shortest Path First (SPF) algorithm that
(same nit about adding "protocol")
This functionality is particularly useful for a number of use cases:
nit: "this functionality" seems to refer to "the SPF algorithm that
identifies transit verticies based on their adjacencies", so I suggest
rewording to "such functionality would be useful" or "A mechanism to
move traffic away from the shortest path" or similar.
Section 4
I suggest noting that the (lettered) sub-procedures of step (2) remain
unchanged.
Section 5
In normal operation, there is no guarantee that the RI LSA will reach
all routers in an area in a timely manner, which may result in
forwarding loops in partial deployments. For example, if a new
router joins an area, which previously had only H-bit capable routers
with H-bit set then it may take some time for the RI to propagate to
all routers.
It's currently only implicit that this new router does not support the
H-bit; shall we make it explicit?
o All routers supporting H-Bit MUST check all the RI LSAs of nodes
in the area before actively running the modified SPF to account
for the H-bit in order to verify that all routers are in routing
capability. If any router does not advertise the Host Router
nit: the grammar here is a little wonky, particularly for "all routers
are in routing capability" but perhaps also for "to account for the
H-bit".
Section 6
When calculating the path to an OSPF AS-External-LSA or NSSA-LSA
[RFC3101] with a Type-2 metric, [...]
nit: is this saying "calculating the path to [an LSA]"? That's not a
usage I'm familiar with; can the AS-External-LSA or NSSA-LSA really
serve as a destination in this sense?
Section 7
Thank you for phrasing this as "this document requests the IANA to
assign", since until these specific values are officially assigned we
are technically "squatting" on them. (The respective registration
policies of Standards Action and IETF Review give us pretty good control
that nothing else is going to swoop in on them, though.)
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Three comments/questions: 1) This sentence in section 3: "An OSPFv2 router advertising a router-LSA with the H-bit set indicates that it MUST NOT be used as a transit router (see Section 4) by other OSPFv2 routers in the area supporting the functionality." Isn't the MUST here too restrictive? What if the router is the part of the only path to a certain host? Or is the assumption that this host is some kind of endhost/deadend, but then it should never be on the shortest path anyway, or? Later on you say "When the H-bit is set, the OSPFv2 router is a Host (non-transit) router and is incapable of forwarding transit traffic." However, there might also be routers that don't understand the H bit and therefore will route traffic over this host anyway, no? 2) Shouldn't this document update RFC2328, given section 4 and this sentence in section 2: "If the H-bit is set then the calculation of the shortest- path tree for an area, as described in section 16.1 of [RFC2328], is modified by including a check to verify that transit vertices DO NOT have the H-bit set (see Section 4)." (And why is DO NOT in upper letters?) 3) Is there an attack that by spoofing the H-bit an attacker could influence the routing such that traffic is router over a malicious node instead? I guess there are multiple ways to impact the routing that way and this might not be specific to the H bit but maybe still worth thinking about it once more...? Nit: Section 5: "The RI LSA MUST be area-scoped. Bit:" -> I guess the "Bit:" should be removed.
(Suresh Krishnan; former steering group member) No Objection