Subject: Re: [Isis-wg] Benoit Claise's No Objection on draft-ietf-isis-sbfd-discriminator-02: (with COMMENT)

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

On 11/18/15, 11:05 AM, "Isis-wg on behalf of Les Ginsberg (ginsberg)"
<[email-masked] on behalf of [email-masked]> wrote:

Les:

Hi!

>I do appreciate that people would like an answer to the question of how
>to map multiple discriminators to use cases - but that is not within the
>purview of this document (or its companion OSPF document). We are simply
>defining how to transport an opaque (to the IGP) value. Anything further
>belongs in the base S-BFD document. I think further discussion on this
>point belongs there. (I have made the same statement in regards to the
>same discussion within the context of
>http://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ .)

I think we're in a situation where we have documents/assumptions pointing
at each other.  While you may be right[*], I think we need to settle
before going forward.

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

Right after sending this e-mail I'm going to put a DISCUSS on this draft
to hold it so we (including the BFD WG, etc.) can answer who is expected
to do what.

Thanks!

Alvaro.

[*] I know the same point was brought up by Acee in the OSPF list, and the
l2tpext draft also takes on the same solution approach.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 18 Nov 2015 17:47:55 +0000

Alvaro -

Neither IS-IS nor OSPF are the "application" here. We are simply the transport for an opaque piece of information. It makes no sense to me to ask the IGPs to clarify what is an issue between S-BFD and an application.

   Les

> -----Original Message-----
> From: Alvaro Retana (aretana)
> Sent: Wednesday, November 18, 2015 8:51 AM
> To: Les Ginsberg (ginsberg); Benoit Claise (bclaise); The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Benoit Claise's No Objection on draft-ietf-isis-sbfd-
> discriminator-02: (with COMMENT)
> 
> >to map multiple discriminators to use cases - but that is not within
> >the purview of this document (or its companion OSPF document). We are
> >simply defining how to transport an opaque (to the IGP) value. Anything
> >further belongs in the base S-BFD document. I think further discussion
> >on this point belongs there. (I have made the same statement in regards
> >to the same discussion within the context of
> at each other.  While you may be right[*], I think we need to settle before
> going forward.
> 
> provided by the "applications (e.g., OSPF/IS-IS)".  There's no other explicit
> discussion about the mapping in that document.
> 
> Right after sending this e-mail I'm going to put a DISCUSS on this draft to hold
> it so we (including the BFD WG, etc.) can answer who is expected to do what.
> 
> Thanks!
> 
> Alvaro.
> 
>

---

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

On 11/18/15, 12:47 PM, "Les Ginsberg (ginsberg)" <[email-masked]>
wrote:

Les:

>Neither IS-IS nor OSPF are the "application" here. We are simply the
>transport for an opaque piece of information. It makes no sense to me to
>ask the IGPs to clarify what is an issue between S-BFD and an application.

What you say makes sense.

It also makes sense to me that one could argue that since we're
transporting opaque information we could also include an extra piece of
opaque information to let someone else know what the first piece was for.
Note that I'm offering that scenario just as an example of the fact that
there are at least a couple of potential interpretations.

Because of the language used in the Base S-BFD draft (where it does call
OSPF/IS-IS an "application", [1]), I just want to play it safe and make
sure we're not pointing at each other and that result won't be that no one
does the mapping.

Thanks!

Alvaro.

[1]

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 18 Nov 2015 19:27:15 +0000

Alvaro -

I think you are referring to this text from https://www.ietf.org/id/draft-ietf-bfd-seamless-base-05.txt

Section 3

"...Allocated S-BFD discriminators may be advertised by
   applications (e.g., OSPF/IS-IS)."

This is (in my view) poorly worded bordering on inaccurate.

In the context of the IS-IS/OSPF drafts we are defining a way to advertise the S-BFD Discriminator(s) assigned to a given node. This does not imply any usage of these values by the IGPs. 

It is conceivable that the IGPs could find a use for an S-BFD session and in that context the IGPs would be an S-BFD client and considered an "S-BFD application". But that is NOT what is covered in the current IGP drafts - nor is it within scope.
So I reiterate, the current discussion regarding how applications decide which S-BFD discriminator should be used is out of scope for the existing IGP drafts.

The entire discussion belongs in the BFD WG. 

   Les

> Sent: Wednesday, November 18, 2015 10:12 AM
> >transport for an opaque piece of information. It makes no sense to me
> >to ask the IGPs to clarify what is an issue between S-BFD and an application.
> 
> It also makes sense to me that one could argue that since we're transporting
> opaque information we could also include an extra piece of opaque
> information to let someone else know what the first piece was for.
> Note that I'm offering that scenario just as an example of the fact that there
> are at least a couple of potential interpretations.
> 
> OSPF/IS-IS an "application", [1]), I just want to play it safe and make sure
> we're not pointing at each other and that result won't be that no one does
> the mapping.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> [1]
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 18 Nov 2015 19:48:35 +0000

On 11/18/15, 2:27 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Les:

>I think you are referring to this text from
>https://www.ietf.org/id/draft-ietf-bfd-seamless-base-05.txt
>
>Section 3

Yes, that's what I quoted below (and in the DISCUSS itself).

>   applications (e.g., OSPF/IS-IS)."

The next sentence says:  "Required result is that applications, on other
network nodes, possess the knowledge of the mapping from remote entities
to S-BFD discriminators."

>This is (in my view) poorly worded bordering on inaccurate.

At the very least the text is confusing.  I think you can interpret it
either way.

>In the context of the IS-IS/OSPF drafts we are defining a way to
>advertise the S-BFD Discriminator(s) assigned to a given node. This does
>not imply any usage of these values by the IGPs.
>
>It is conceivable that the IGPs could find a use for an S-BFD session and
>in that context the IGPs would be an S-BFD client and considered an
>"S-BFD application". But that is NOT what is covered in the current IGP
>drafts - nor is it within scope.
>So I reiterate, the current discussion regarding how applications decide
>which S-BFD discriminator should be used is out of scope for the existing
>IGP drafts.
>

Agreed, the discussion should be there.  I have asked the Chairs to lead
that discussion (while keeping everyone else in the loop: isis, ospf,
l2tpext).

There is nothing specified in an S-BFD document that talks about the
mapping topic (except for the text above).  As I said below, it worries me
that S-BFD is expecting the "applications" (yes, the draft could've
probably used a better word and not lumped the IGPs in there...but it did)
to do something that is not being done.

Alvaro.

>>transporting
>>sure