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

Tim Chown <> Fri, 08 November 2019 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2053012008C for <>; Fri, 8 Nov 2019 05:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id esZqjqZtSwyB for <>; Fri, 8 Nov 2019 05:30:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B23012003F for <>; Fri, 8 Nov 2019 05:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170213; t=1573219856; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lsn8vwsNiDvZUGpW/ozJd3hKG3og1cO9ngggMJ195/M=; b=PTGHzlgXdDi+QTFovh6In7r8QeY9KVmJSXMQptb1t2gowc2TE2nJkmX6CbyAn5d3cqPbR9 UhbzDNYjTF0zER57HEL7r8YS5Xwyh7FxlVl0H5hysuQFHJh1UKcB9kZX5BTjCfn4NA5XUb +W4RxXsEU1IhU+emVFznzYJUCXq3188=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-144-rxtmxrYqNFWvevoWIWBq8w-1; Fri, 08 Nov 2019 13:30:53 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Fri, 8 Nov 2019 13:30:49 +0000
Received: from ([fe80::dd9b:ca7b:536b:6297]) by ([fe80::dd9b:ca7b:536b:6297%5]) with mapi id 15.20.2430.014; Fri, 8 Nov 2019 13:30:49 +0000
From: Tim Chown <>
To: Padma Pillay-Esnault <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10
Thread-Index: AQHVldD+g1OnzyYl10mSOAc4iCGBKaeBRdQA
Date: Fri, 8 Nov 2019 13:30:49 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3601.0.10)
x-originating-ip: [2001:a88:d510:1101:ac94:b4b4:be8f:81fd]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 88ebfe8a-812a-45b3-5fce-08d7644fde6a
x-ms-traffictypediagnostic: AM0PR07MB5490:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(346002)(376002)(366004)(136003)(199004)(189003)(11346002)(76176011)(14454004)(7736002)(6116002)(6246003)(71200400001)(486006)(2906002)(446003)(86362001)(71190400001)(6916009)(46003)(33656002)(478600001)(25786009)(99286004)(476003)(4326008)(36756003)(186003)(102836004)(81156014)(81166006)(786003)(6512007)(236005)(8676002)(53546011)(316002)(6506007)(8936002)(54896002)(2616005)(5660300002)(50226002)(91956017)(256004)(66556008)(14444005)(54906003)(64756008)(66446008)(6486002)(66574012)(6436002)(66946007)(66476007)(229853002)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5490;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JtM9VxocBghY1KA1PJmI4OwPs7LHYFBttO8DopueVep/im/euyUOErRFLf34aalSs/hUnvrqWLb+CK3zFXFxAlV+Q99kG+DCxlJPHostXhtOAeRZFlP/uj4UF0Lx/e4HeZY8qAs2FNN5g+m6LOwK2ZSbgIhHGH+Nf6mZXCUTKcY9kTWAS09S5kDe0FFzcSKQzI3xbWHS9PTRxVQvpL9tQVo+88Zt5C3iZBUxT5aoQe7Xn6EQhHPRTqiBbf87D9oq159vMXBDYcmj9LsPQJ+FecRWaknqb+Uk0zJDOnUHiOomZ9j49m2LmyYvbku5e/IVnL97D//8Se8NdiE9rXTXuV3yqhw08iqKlhi1Pyyw5GoJCucA6WHJtmTrh0wQ1HtT16GHCQNP0mqoYgrKn77gOiI2Z4IK47oWoOYiS0CE6snfom0dy569t5dZsWzuE+Uo
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 88ebfe8a-812a-45b3-5fce-08d7644fde6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 13:30:49.1682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DTwHxgzXmy6DpOrCl5QbGh0Dvzff0Km5mn/9e6iKORia238XklJxruXciqaTduMrU2qFRsg3zJfXltbln/rwVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5490
X-MC-Unique: rxtmxrYqNFWvevoWIWBq8w-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_86F8632CEEC64444AED84180C26A9619jiscacuk_"
Archived-At: <>
Subject: Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv2-hbit-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Nov 2019 13:31:03 -0000


Comments on-line as TC>

On 8 Nov 2019, at 01:07, Padma Pillay-Esnault <<>> 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 <<>> 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.

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.

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.


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:

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,



In the abstract:
“This document defines a bit (Host-bit)”
“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.