Re: [OSPF] More Comments on OSPF S-BFD Discriminator

"Acee Lindem (acee)" <> Mon, 09 November 2015 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 436151B8632; Mon, 9 Nov 2015 14:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBq4ACLic70N; Mon, 9 Nov 2015 14:24:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BC4A1B8631; Mon, 9 Nov 2015 14:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9639; q=dns/txt; s=iport; t=1447107856; x=1448317456; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6k+nQRo4SjZqZaR7ny2XNJ/ct2yY18hyqUeH/z6XhH4=; b=RczjDrqUFxM5rEocE2yE53WpIMrb3etYAgsFK6k1cchm7MxmcQKdlVzA IrnZP/LE41T3zoP+wQiyC/5zKEEaluSMu+VOs0mTQjMmqKo1+JdluzjSn o2eQaUaZnYFzmdIQol9yBbXyLNHXXXwwaOt7mXmRV/sdwSc36Kv548RTW A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.20,267,1444694400"; d="scan'208,217"; a="43458286"
Received: from ([]) by with ESMTP; 09 Nov 2015 22:24:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tA9MOFPB024612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2015 22:24:15 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 Nov 2015 17:24:14 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Mon, 9 Nov 2015 17:24:14 -0500
From: "Acee Lindem (acee)" <>
To: Manav Bhatia <>
Thread-Topic: [OSPF] More Comments on OSPF S-BFD Discriminator
Thread-Index: AQHRGDvPHGJIFP17wUyU2okv88d/op6USjYA
Date: Mon, 09 Nov 2015 22:24:14 +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: multipart/alternative; boundary="_000_D26686563CED2aceeciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, OSPF WG List <>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator
X-Mailman-Version: 2.1.15
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: Mon, 09 Nov 2015 22:24:18 -0000

Hi Manav,

From: Manav Bhatia <<>>
Date: Friday, November 6, 2015 at 11:35 AM
To: Acee Lindem <<>>
Cc: "<>" <<>>, "Alvaro Retana (aretana)" <<>>, OSPF WG List <<>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Hi Acee,

Sorry for the late response.

We will add the following text in the next update

“When multiple S-BFD discriminators are advertised how a given discriminator is mapped to a specific use case is out of scope for this document.”

I’m still struggling with the utility of automatic discovery of multiple S-BFD discriminators if one has no way to map them to an endpoint or the corresponding service.


Will address the other minor comments in the next rev.

Cheers, Manav

On Mon, Oct 26, 2015 at 5:37 AM, Acee Lindem (acee) <<>> wrote:
I have one major comments and I’ve copied Alvaro since he is reviewing the
base S-BFD drafts.

  If an OSPF router advertises multiple BFD discriminators, how do the
other OSPF routers in the OSPF routing domain map the S-BFD discriminators
to the OSPF router IP endpoints and services?

I also have some minor comments:

  1) This draft should reference the RFC 4970BIS draft as this is in RFC
EDIT state.
  2) Section 2.1 - The base RFC 4970BIS draft states that unrecognized
TLVs are ignored (as stated in section 3). This is not specific to this
  3) Section 2.2 - This says the Opaque ID must be 0. Note that an OSPF
router can now originate multiple OSPF RI LSAs instances. I think this TLV
should be allowed in an OSPF RI LSA subsequent to the first.
  4) Section 2.2 - I don’t think we should advocate sending an empty OSPF
Router Information LSA. I’d remove this case.


OSPF mailing list<>