Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

"Nobo Akiya (nobo)" <> Wed, 14 May 2014 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB0C51A0103; Wed, 14 May 2014 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.152
X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YhWfgqVNDsj5; Wed, 14 May 2014 08:48:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 001021A02C0; Wed, 14 May 2014 08:48:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1456; q=dns/txt; s=iport; t=1400082497; x=1401292097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zff8cwTPn/qtJJ6ZWSXoufGMe+vkrTvJzn3S4IqlUrI=; b=L8iwUTv1QVdaTpx63NCQ5U9w6cZwisXcJBF9rrVAgR6YxAeZ/5weDUBL +JoiKcyOExHFtKK6B3g7qDxh9f2kJy2YijrERYuLmm6JKST/ZVRm40Tac ofLYlsMczyvzJhlqlH9rXU2eVOqvqoRAsDmNoYaitlecS1sD56Ijd4eWk w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43794591"
Received: from ([]) by with ESMTP; 14 May 2014 15:48:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s4EFmAol004839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 15:48:10 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:48:10 -0500
From: "Nobo Akiya (nobo)" <>
To: Jeffrey Haas <>, Hannes Gredler <>
Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8A==
Date: Wed, 14 May 2014 15:48:10 +0000
Message-ID: <>
References: <> <> <> <> <> <20140514153641.GC13993@pfrc>
In-Reply-To: <20140514153641.GC13993@pfrc>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Les Ginsberg \(ginsberg\)" <>, "" <>, "" <>
Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 May 2014 15:48:51 -0000

Hi Jeff,

> On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote:
> > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote:
> > > Thanx for the comments.
> > > I don't see how your proposal solves the problem you are attempting to
> address. The sender of the S-BFD packet has no control over what interface
> is used to receive the packet on the target node. Associating it with a prefix
> will not help in that regard.
> >
> > well it would help first endpoint discovery and pinning down BFD traffic to
> particular line card.
> Indeed.  In the SPRING related case (or even some MPLS scenarios), traffic
> may be heavily steered to a given interface.  This interface may not even be
> to a router, but may be an ingress for a SFC device and that ingress is critical
> for the execution of the chain.

In those cases, one should be sending S-BFD packet in-band, which would go through the specific interface/LC to reach the reflector session on the target node (i.e. outage will be detected regardless of the discriminator used). So having separate reflector discriminator won't be adding further benefit.

Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is terminating on LC2, then outage of LC1 can cause the "no S-BFD response" on the tunnel terminating on LC2. However, I would think this is a limitation with implementation.