Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10

[Tim Chown <[e-mail]>]

Hi,

Comments on-line as TC>

On 8 Nov 2019, at 01:07, Padma Pillay-Esnault <[e-mail]<mailto:[e-mail]>> wrote:

Hi Tim

Thank you for your review and comments.

See below PPE.

On Thu, Nov 7, 2019 at 2:22 PM Tim Chown via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Reviewer: Tim Chown
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The document describes a mechanism by which a node running OSPFv2 can repel
transit traffic if it is on the shortest path (and an alternative path exists -
though this is not wholly clear in the document). It defines a Host-bit (H-bit)
that allows the router to advertise that it is not a transit router, and it
describes the changes needed to support the H-bit within a domain, and
mitigations against potential routing loops.

General comments:

Should the document also state that it updates RFC 2328?


PPE> No. This has been discussed previously during the AD review.
This feature is an optional feature and RFC2328 does not require it for normal operations.

TC> OK, no problem.

I think the document could be clearer on the behaviour when the H-bit and
MaxLinkMetric are used when there is only one path available, i.e. there is no
redundant / alternative path.  Section 4 of RFC 6987 implies that if there is
only one path the router can still be used as a transit router, by the nature
of the definition of MaxLinkMetric.  The document has 3 or 4 places where it
hints at behaviour, but I think it could be more explicit.


PPE>   This feature goes one step further than RFC 6987 which is a best effort at stopping transit traffic.
We believe that the behavior is clear that a "host router" is NOT used for transit  traffic regardless whether it is the last resort path or not.
Please note the CURRENT version does not restrict the feature on a specific number of paths (last resort or not) or metric value (MaxlinkMetric or not) or make any assumption in that way.

However, I proposed to add this text in an earlier thread  to make it even more explicit.

CURRENT:
This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router for transit traffic in OSPFv2 routing domains.

SUGGESTED NEW:
This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router by excluding it in path calculations for transit traffic in OSPFv2 routing domains.

TC> OK, thanks, that is certainly better.

It may be worth explicitly stating that OSPFv3 is not mentioned due to it
having an R-bit defined for indicating whether a node/router can be used for
transit traffic (see Sections 2.7 and A.2 of RFC 5340).


PPE> There was an earlier discussions regarding mentioning the OSPFv3 functionality and eventually these references were removed in subsequent versions of the H-bit draft.
The R-bit is not exactly the same as H-bit, even though both are used for the similar functionality, they rely on different mechanisms in the protocol.

TC> Yes, I realised the R and H-bits are different though with similar functionality.  I didn’t realise only having read this draft now that the OSPFv3 text had been removed by WG consensus, in which case I am happy.


The reasons given in Section 1 for the need for the H-bit are different to
those given in Section 1 of RFC 6987 for the capability.  Should these be more
consistent?   Also, the document later mentions “a router being gracefully
isolated” as a reason, but this is not mentioned in Section 1.


PPE>  We believe that this the document covers this case in bullet 1 and bullet 3 in section1.

CURRENT

1.  To isolate a router to avoid blackhole scenarios when there is a
       reload and possible long reconvergence times.
<...>
3.  Overloaded routers could use such a capability to temporarily
       repel traffic until they stabilize.

To make it even more explicit:

SUGGESTION
1. To gracefully isolate a router to avoid blackhole scenarios when there is a
       reload and possible long reconvergence times.

TC> That’s good, thank you.

Let me know if this addresses all your comments

TC> It does.

Best wishes,
Tim


Thanks
Padma

Nits:

In the abstract:
Change
“This document defines a bit (Host-bit)”
to
“This document defines a Host bit (H-bit)”
for consistency
And “is a non-transit router.”” - remove the spurious “.

Section 8:
Where it says “beyond those already known in OSPF”, say OSPFv2.