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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 18 Nov 2015 17:16:05 +0000

Jeff/Reshad:

Hi!  How are you?

I need you to please drive the discussion below.  The outcome should be
consensus on how the mapping between multiple discriminators and
applications/use cases on a node should be handled.  I can guess at 3
potential outcomes:

1. The "applications (e.g., OSPF/IS-IS)" should handle it.
2. The S-BFD Base specification will detail how to do it (not requiring
additional work from the applications).
3. We'll deal with this issue somewhere else (not requiring additional
work from the applications).

[Maybe there are more options.]

Please keep isis/ospf/l2tpext in the loop.

Even in the best case, we're probably going to need some clarification in
draft-ietf-bfd-seamless-base.

BTW, if you decide to follow this thread..  I fat fingered the address of
the l2tpext WG. :-(

Thanks!

Alvaro.

On 11/18/15, 12:06 PM, "iesg on behalf of Alvaro Retana (aretana)"
<[email-masked] on behalf of [email-masked]> wrote:

>Alvaro Retana has entered the following ballot position for
>draft-ietf-isis-sbfd-discriminator-02: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>It has been pointed out during the processing of this document (and other
>similar ones, draft-ietf-ospf-sbfd-discriminator, for example) that the
>functionality provided is only the advertisement of S-BFD discriminators,
>but not a mechanism to map these discriminators to specific applications
>or use-cases in the nodes.  That mapping has been declared out of scope.
>
>However, the Base S-BFD draft (draft-ietf-bfd-seamless-base) assumes that
>the advertisers of the multiple discriminators will in fact provide the
>ability for the mapping.  Specifically, the base S-BFD document reads in
>Section 3. (Seamless BFD Overview):
>
>   An S-BFD module on each network node allocates one or more S-BFD
>   discriminators for local entities, and creates a reflector BFD
>   session.  Allocated S-BFD discriminators may be advertised by
>   applications (e.g., OSPF/IS-IS).  Required result is that
>   applications, on other network nodes, possess the knowledge of the
>   mapping from remote entities to S-BFD discriminators.
>
>This text reads to me that S-BFD is expecting the mapping to be somehow
>provided by the "applications (e.g., OSPF/IS-IS)".  There's no other
>explicit discussion about the mapping in that document.
>
>I'm putting a DISCUSS on this document to hold its processing while the
>requirements from the S-BFD point of view are clarified.  The answer to
>that question should be a discussion in the BFD WG (cc'd in this
>message), in coordination with the providers of the advertisements (so
>far the isis, ospf and l2tpext WGs have active drafts in this area).
>
>One possible outcome of this required discussion is clearly that the
>mapping is in fact outside the scope of advertising protocols (such as
>IS-IS).  Other possible outcomes may require this document to be
>modified.
>
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Nov 2015 13:26:09 -0500

> Hi!  How are you?

I *was* almost caught up with my BFD work post-IETF, thanks. :-)

> BTW, if you decide to follow this thread..  I fat fingered the address of

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.

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.

I leave comments about more clever things to do with this for the authors.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2015 18:49:18 +0000

Hi Jeff, et al, 

> On Nov 18, 2015, at 1:26 PM, Jeffrey Haas <[email-masked]> wrote:
> 

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? 

> BFD sessions on that node.

For this use case, pre-provisioning could be avoided with a standard algorithm to choose among multiple discriminators. 

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Nov 2015 13:59:41 -0500

Acee,

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

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2015 19:29:27 +0000

Jeff, 

On 11/18/15, 1:59 PM, "Jeffrey Haas" <[email-masked]> wrote:

>> 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". :-)
>

In any case, it seems that multiple reviewers have asked from some
discussion of how this mapping is or at least might be done and I don’t
think it belongs in the IGP drafts.

Thanks,
Acee 

>> For this use case, pre-provisioning could be avoided with a standard
>>algorithm to choose among multiple discriminators.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Nov 2015 14:31:17 -0500

> think it belongs in the IGP drafts.

Agreed.

-- Jeff