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

[Jeffrey Haas <[e-mail]>]

I'm somewhat distracted today due to an upcoming trip, but will try to drive this a bit when I'm back on Monday.

IMO, the topic wanders a bit too closely on the "how much do we need to know to be interoperable" vs. "we don't want to be too proscriptive about things to prevent clever future uses".  The authors seem to be reasonably clear that one is fine and that multiple will require some mapping - maybe.  

Would some text along the lines of "implements SHOULD only send one; sending more than one is the subject of further experiments" help?

-- jeff

> On Nov 18, 2015, at 1:59 PM, Jeffrey Haas <[e-mail]> wrote:
> 
> 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