Subject: [Last-Call] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10

From: Tim Chown via Datatracker <[email-masked]>
Date: Thu, 07 Nov 2019 14:21:59 -0800

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?

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.

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).

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.

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.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 7 Nov 2019 17:07:54 -0800

Hi Tim

Thank you for your review and comments.

See below PPE.

> 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.

> 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.

> 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.

> 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.

Let me know if this addresses all your comments

Thanks
Padma

---

From: Tim Chown <[email-masked]>
Date: Fri, 8 Nov 2019 13:30:49 +0000

Hi,

Comments on-line as TC>

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

Hi Tim

See below PPE.

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

General comments:

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.

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.

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.

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

CURRENT

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.

TC> It does.

Best wishes,
Tim

Thanks
Padma

Nits:

In the abstract:
Change

Section 8:

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 8 Nov 2019 22:11:00 -0800

Hi Tim

> 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 changes were made during the review phase, IMHO the document will
benefit with the addition of a reference.
I will add a sentence in the introduction mentioning that there is a
similar functionality
for OSPFv3 and it is achieved using the R-bit as described in RFC5340.

Thanks
Padma