Re: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt

"Ketan Talaulikar (ketant)" <> Fri, 28 July 2017 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B50F131EFE for <>; Thu, 27 Jul 2017 19:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LAo_t2nJpJ3J for <>; Thu, 27 Jul 2017 19:21:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D493131F00 for <>; Thu, 27 Jul 2017 19:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4312; q=dns/txt; s=iport; t=1501208460; x=1502418060; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jiW2pVZnwjJ3oMEcmaUn3yRXX2YjxdDXvP2KhUou7do=; b=G5XeqfGp1k0vrQfElJAuz4cp7tZ7OhhuOoG9+Q2qYcpumCeeZnLIbJRZ s6ZTU2hKAUsMIYud77/ypVq+5tft9JcNySMhQGS73ww+jf5zPN6/a8mdz 8zAhc0VPuQgFQW/DJG33POL/0GukbM6p7m4l0MH7FygZssRCTnYEyLciZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.40,423,1496102400"; d="scan'208";a="275526485"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 02:20:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v6S2KxAc029630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Fri, 28 Jul 2017 02:20:59 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 21:20:58 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 21:20:58 -0500
From: "Ketan Talaulikar (ketant)" <>
To: "Acee Lindem (acee)" <>, OSPF WG List <>
Thread-Topic: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt
Thread-Index: AQHS5UdL63grjfjKXUi/Svr//ip4JqJoxBoA
Date: Fri, 28 Jul 2017 02:20:58 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Jul 2017 02:21:03 -0000

Hi Acee/WG,

I would like to bring up that this draft does not cover the application to Traffic Engineering applications (RSVP-TE/SR-TE). It only talks about and covers the traditional OSPF SPF computation. For truly achieving the objective, I believe this draft should also cover TE and all other types of computations which would result in transit traffic going through the node.

I realized that TE applicability was never specified explicitly even for RFC6987/RFC3137 and very likely that implementations might have adopted different mechanisms in applying the max-metric to TE as well that can cause interop issues. Perhaps that warrants a bis?


-----Original Message-----
From: OSPF [] On Behalf Of Acee Lindem (acee)
Sent: 15 June 2017 01:19
To: OSPF WG List <>
Subject: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt

The question of OSPFv2 complete blocking of transit routing support
(similar to OSPFv3) seems to come up every year or so. I’d like to WG last
call this document. Does anyone see any issues?

On 6/14/17, 12:44 PM, "OSPF on behalf of"
< on behalf of> wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts
>This draft is a work item of the Open Shortest Path First IGP of the IETF.
>        Title           : H-bit Support for OSPFv2
>        Authors         : Keyur Patel
>                          Padma Pillay-Esnault
>                          Manish Bhardwaj
>                          Serpil Bayraktar
>	Filename        : draft-ietf-ospf-ospfv2-hbit-03.txt
>	Pages           : 8
>	Date            : 2017-06-14
>   OSPFv3 defines an option field for router-LSAs known as a R-bit in
>   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
>   OSPF topology distribution without acting as a forwarder to forward
>   the transit traffic.  In such cases, an OSPF router would only accept
>   traffic intended for local delivery.  This draft defines R-bit
>   functionality for OSPFv2 defined in RFC2328.
>The IETF datatracker status page for this draft is:
>There are also htmlized versions available at:
>A diff from the previous version is available at:
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at
>Internet-Drafts are also available by anonymous FTP at:
>OSPF mailing list

OSPF mailing list