Re: [L2tpext] Alvaro Retana's Discuss on draft-ietf-isis-sbfd-discriminator-02: (with DISCUSS)

Jeffrey Haas <jhaas@pfrc.org> Wed, 18 November 2015 18:59 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00701A6F7F; Wed, 18 Nov 2015 10:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level:
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcR_WHNN5BXJ; Wed, 18 Nov 2015 10:59:02 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF90C1A6F81; Wed, 18 Nov 2015 10:59:01 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 615B71E1D1; Wed, 18 Nov 2015 13:59:41 -0500 (EST)
Date: Wed, 18 Nov 2015 13:59:41 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
Message-ID: <20151118185941.GA30062@pfrc.org>
References: <20151118170601.5815.13593.idtracker@ietfa.amsl.com> <D2721A64.EAB62%aretana@cisco.com> <20151118182609.GD32083@pfrc.org> <9F972E95-3DBC-45C7-8D25-5A3490942480@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9F972E95-3DBC-45C7-8D25-5A3490942480@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/l2tpext/Ej1Yw8f44A64ongRb4ax6yHxUJg>
Cc: "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-bfd-seamless-base@ietf.org" <draft-ietf-bfd-seamless-base@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, "l2tpext@ietf.org" <l2tpext@ietf.org>
Subject: Re: [L2tpext] Alvaro Retana's Discuss on draft-ietf-isis-sbfd-discriminator-02: (with DISCUSS)
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2015 18:59:03 -0000

Acee,

On Wed, Nov 18, 2015 at 06:49:18PM +0000, Acee Lindem (acee) wrote:
> > We'll give the authors a chance to reply, but basically:
> > - discriminators must already be domain-wide unique.
> > - The uniqueness property tends to imply provisioning.
> > - Thus the foreknowledge for the mapping is probably implied.
> 
> I hate to be a killjoy, but if everything is pre-provisioned, what is the benefit of advertising the S-BFD discriminators in the IGPs? 

I did say "imply". :-)

There's also a slight difference between provisioning for purposes of making
sure things are unique domain wide and putting a copy of that mapping on
every single node.  That's at least one reason to distribute in the IGP.

And the other case would be something like derived from router-id.  

> > See section 5, second to last paragraph for reinforcement that it's a local
> > matter.
> > 
> > The better questions are "why would you give a given node more than one
> > discriminator?"  The typical case is likely to be for scaling the number of 
> > BFD sessions on that node.
> 
> For this use case, pre-provisioning could be avoided with a standard algorithm to choose among multiple discriminators. 

Even for this case, I'd hesitate to be too proscriptive.  Trying to describe
an algorithm to provide load-balancing domain-wide with unknown loads is
likely to be wrong... and hard to compete with "pick one at random" in many
cases.

-- Jeff