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

"Acee Lindem (acee)" <> Fri, 04 August 2017 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B787A1270B4 for <>; Thu, 3 Aug 2017 20:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 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, URIBL_BLOCKED=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 X7rPK8swwFDj for <>; Thu, 3 Aug 2017 20:35:23 -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 BD62A12942F for <>; Thu, 3 Aug 2017 20:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4854; q=dns/txt; s=iport; t=1501817723; x=1503027323; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pkxA9v56R1GdvoVG13PIX82wnkZ3P3iAteHxagCojNE=; b=QaXwHcmU1FFR/ZseJXRSAHauxbH93F0IzU8MjVM1242nPm9BK0g9646L X0yut6yIPVfq9P786sJcWyJF+6DSsQGO6oqI0L7F2WYkvoskWYm5rw4rX 5V4oQYyXtlPuiRnPi5lJcW8Rv9jkIJscyEkwdCbsz0j50OyIyazkl2m6n g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.41,319,1498521600"; d="scan'208";a="281464783"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 03:35:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v743ZM9X013821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Fri, 4 Aug 2017 03:35:22 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 23:35:21 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 23:35:21 -0400
From: "Acee Lindem (acee)" <>
To: "Ketan Talaulikar (ketant)" <>, OSPF WG List <>
Thread-Topic: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt
Thread-Index: AQHTB0gnm5J0uuB2IU61XNm1+z588KJzlrwA
Date: Fri, 04 Aug 2017 03:35:21 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
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, 04 Aug 2017 03:35:26 -0000

Hi Ketan, 

With all the WG documents we have, I wouldn’t put this as a high priority.
Rather, I’d like to focus on getting OSPFv3 Extended LSAs published and
encouraging wider implementation.


On 7/27/17, 10:20 PM, "Ketan Talaulikar (ketant)" <> wrote:

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