Subject: Multiple BFD sessions between the same pair of end-points

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Nov 2015 02:26:37 +0000

Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits multiple single-hop BFD sessions between the same pair of end points:
   Each BFD session between a pair of systems MUST traverse a separate
   network-layer path in both directions.  This is necessary for
   demultiplexing to work properly, and also because (by definition)
   multiple sessions would otherwise be protecting the same path.

                Regards,
                                Greg

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 2 Nov 2015 18:37:51 -0800

Does that apply to BFD for VXLAN as well?

> On Nov 2, 2015, at 6:26 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Dear All,

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 Nov 2015 08:58:57 +0530

And pray what is the context? I presume its got something to do with the
BFD WG meeting. Would appreciate some details.

I have a counter example of when one may need multiple BFD sessions between
the same end-points, but i would like to hear the context before i muddy
the waters.

Cheers, Manav

On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky <[email-masked]>
wrote:

> Dear All,
>
> I think that this paragraph from Section 2 of RFC 5881 prohibits multiple
> single-hop BFD sessions between the same pair of end points:
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 3 Nov 2015 12:50:34 +0900

The context was the discussion in the BFD WG on BFD YANG model.

The BFD YANG model is struggling with the need to support multiple BFD sessions between the same endpoints. If 5881 is clear that the BFD session has to traverse different network-layers, then it helps. I do not see the need for different time intervals for different applications as a strong argument to support multiple BFD sessions between the same endpoints. Applications can choose to ignore a DOWN notification if they find it too aggressive. 

> On Nov 3, 2015, at 12:28 PM, Manav Bhatia <[email-masked]> wrote:
> 
> And pray what is the context? I presume its got something to do with the BFD WG meeting. Would appreciate some details.
> 
> I have a counter example of when one may need multiple BFD sessions between the same end-points, but i would like to hear the context before i muddy the waters.
> 
> Cheers, Manav
> 
> On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> Dear All,
> 

Mahesh Jethanandani
[email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Nov 2015 04:23:00 +0000

Hi Sam,
if path between two VTEPs of the same VXLAN has entropy that BFD MAY exercise, then there MAY be multiple BFD sessions. I see this as closer to 5884clarification then to 5881.

                Regards,
                                Greg

From: Sam Aldrin [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 11:38 AM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: Multiple BFD sessions between the same pair of end-points

On Nov 2, 2015, at 6:26 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Nov 2015 04:26:12 +0000

Hi Manav,
I think that the quote from RFC 5881 applies only to single-hop (and LAG too) IPV4/IPv6 BFD, not to multi-hop or BFD over MPLS LSP. I’m very much interested to learn about use case you have for multiple single hop BFD sessions.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[email-masked]]
Sent: Tuesday, November 03, 2015 12:29 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: Multiple BFD sessions between the same pair of end-points

Cheers, Manav

On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,

                Regards,
                                Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Nov 2015 13:46:47 +0900

Greg,

> On Nov 3, 2015, at 11:26 AM, Gregory Mirsky <[email-masked]> wrote:
> 
> Dear All,

It does.  It will require additional bootstrapping procedures similar to LSPing.

-- Jeff

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 3 Nov 2015 04:55:46 +0000

Greg -

I agree with your characterization.

I would also suggest that RFC 5883 Section 4.1 makes the same statement for multi-hop BFD  - at least from the standpoint of L3 clients.

   Les

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Monday, November 02, 2015 6:27 PM
To: [email-masked]
Subject: Multiple BFD sessions between the same pair of end-points

Dear All,

                Regards,
                                Greg

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 Nov 2015 10:36:54 +0530

I had a BFD session over an MPLS LSP in my mind, which i understand is
outside the scope.

Cheers, Manav

On Tue, Nov 3, 2015 at 9:56 AM, Gregory Mirsky <[email-masked]>
wrote:

> Hi Manav,
>
> I think that the quote from RFC 5881 applies only to single-hop (and LAG
> too) IPV4/IPv6 BFD, not to multi-hop or BFD over MPLS LSP. I’m very much
> interested to learn about use case you have for multiple single hop BFD
> sessions.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Manav Bhatia [mailto:[email-masked]]
> *Sent:* Tuesday, November 03, 2015 12:29 PM
> *To:* Gregory Mirsky
> *Cc:* [email-masked]
> *Subject:* Re: Multiple BFD sessions between the same pair of end-points
>
>
>
> I have a counter example of when one may need multiple BFD sessions
> between the same end-points, but i would like to hear the context before i
> muddy the waters.
>
>
>
> Cheers, Manav
>
>
>
> On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky <
> [email-masked]> wrote:
>
> Dear All,
>

---

From: Santosh P K <[email-masked]>
Date: Tue, 3 Nov 2015 05:22:23 +0000

Greg,
   This statement does not say multiple BFD session on the "same interface" between two system right? It just says that we can have multiple BFD session between two systems probably on different interface who are directly connected. In this case you can still have interface as a key to identify initial BFD packet.

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: [email-masked]
Subject: Multiple BFD sessions between the same pair of end-points

Dear All,

                Regards,
                                Greg

---

From: Santosh P K <[email-masked]>
Date: Tue, 3 Nov 2015 05:25:27 +0000

This is form RFC 5881 section 3.

In this application, there will be only a single BFD session between
   two systems over a given interface (logical or physical) for a
   particular protocol.  The BFD session must be bound to this
   interface.

Which says for singlehop you will have only single BFD session for an interface.  The case where we are struggling in Yang is for multihop BFD session.

Thanks
Santosh P K

Dear All,

                Regards,
                                Greg

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 3 Nov 2015 05:29:55 +0000

Hi Santosh,

Even for single-hop we had discussions about implementations which support the option of having multiple BFD single-hop sessions on 1 interface between 2  endpoints. That was an argument for having the BFD config in routing applications. This is what was discussed today in the WG. And I think Greg's point is that we don't have to support this in the base model, but implementations are have vendor specific model which supports this behaviour.

Regards,
Reshad.

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Santosh P K <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 3, 2015 at 1:25 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Multiple BFD sessions between the same pair of end-points

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Multiple BFD sessions between the same pair of end-points

Dear All,

                Regards,
                                Greg

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 2 Nov 2015 22:48:18 -0800

Reshad,

> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Hi Santosh,
> 
> Even for single-hop we had discussions about implementations which support the option of having multiple BFD single-hop sessions on 1 interface between 2  endpoints. That was an argument for having the BFD config in routing applications. This is what was discussed today in the WG. And I think Greg’s point is that we don’t have to support this in the base model, but implementations are have vendor specific model which supports this behavior.
Are there already vendor specific models/implementations in the single hop case? OR did you mean, there could be vendor specific extensions?

-sam
> 
> Regards,
> Reshad.
> 
> 
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> on behalf of Santosh P K <[email-masked] <mailto:[email-masked]>>
> To: Gregory Mirsky <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Rtg-bfd [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gregory Mirsky
> To: [email-masked] <mailto:[email-masked]>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 3 Nov 2015 07:00:15 +0000

Hi Sam,

Typo in my email indeed. What I meant is that there could be vendor specific extensions if needed.

Also looks like there was confusion in the design team (seemingly caused by my misinterpretation of what was said), there is no known implementation which supports multiple BFD single-hop sessions for the same pair of endpoints (right Santosh?). For MH it's a different story because of multiple-paths.

The DT will get together to clarify and apologies for the confusion.

Regards,
Reshad.

From: Sam Aldrin <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 3, 2015 at 2:48 AM
To: Reshad <[email-masked]<mailto:[email-masked]>>
Cc: Santosh P K <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Multiple BFD sessions between the same pair of end-points

Reshad,

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Santosh,

Even for single-hop we had discussions about implementations which support the option of having multiple BFD single-hop sessions on 1 interface between 2  endpoints. That was an argument for having the BFD config in routing applications. This is what was discussed today in the WG. And I think Greg's point is that we don't have to support this in the base model, but implementations are have vendor specific model which supports this behavior.
Are there already vendor specific models/implementations in the single hop case? OR did you mean, there could be vendor specific extensions?

-sam

Regards,
Reshad.

Thanks
Santosh P K

Dear All,

                Regards,
                                Greg

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 2 Nov 2015 23:01:45 -0800

Thanks for the quick clarification, Reshad.

-sam
> On Nov 2, 2015, at 11:00 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Hi Sam,
> 
> Also looks like there was confusion in the design team (seemingly caused by my misinterpretation of what was said), there is no known implementation which supports multiple BFD single-hop sessions for the same pair of endpoints (right Santosh?). For MH it’s a different story because of multiple-paths. 
> 
> From: Sam Aldrin <[email-masked] <mailto:[email-masked]>>
> To: Reshad <[email-masked] <mailto:[email-masked]>>
> Cc: Santosh P K <[email-masked] <mailto:[email-masked]>>, Gregory Mirsky <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Santosh,
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 Nov 2015 13:15:49 +0000

Hi Reshad,

It really depends on what is considered a “path” over which BFD detects faults, and how the initial demux can be done vs. bootstrapped out-of-band.

RFC 5881 has the text quoted by Greg, because in that case single-hop initialization procedures can be done (by binding the interface to BFD context) and not require out-of-band discriminator bootstrapping.

However, on a single interface between two forwarding endpoints, there could be multiple sessions in a generic application. The simplest example is what is described in the second paragraph of https://tools.ietf.org/html/rfc5882#section-6 <https://tools.ietf.org/html/rfc5882#section-6>. In that case, a path is a specific diffserv code point over IPv4 between two endpoints, and that is the context used for initialization using single-hop procedures. In RFC5885 we chose to allow only one, to use single-hop initialization for example within a tunnel (PW) context.

For the multi-hop case, there could also be multiple sessions between endpoints. If there is only one session, then the initialization can be done using single-hop procedures binding source/dst addresses. However, is there are multiple sessions, as e.g., if there is some ECMP-awareness, then some different and additional mechanism (e.g., out-of-band bootstrapping) is needed. This is described in the second paragraph of https://tools.ietf.org/html/rfc5883#section-3 <https://tools.ietf.org/html/rfc5883#section-3>. In fact, these two options are covered in S4.1 (limit to one session and use src/dst) and S4.2 (allow multiple sessions and use an OOB bootstrapping).

As far as the YANG models, I’d think that single session for both single- and multi-hop covers vast majority of real cases, being pragmatic. If someone wants to have for example multiple sessions between a pair of endpoint addresses in multi-hop, then an OOB mechanism is needed, and I do not believe there is a spec’ed one other than for MPLS.

Thanks,

— Carlos.

> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Hi Sam,
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Nov 2015 13:38:35 +0000

Hi all,
I concur with Carlos, only wanted to add that in the case of BFD in MPLS LSP ability for in-band initialization does not exist (e.g. in the case of PHP, see Section 5 in RFC 5884), and so an OOB initialization procedure was unavoidable.

I’d say we need a very strong use case for multiple BFD sessions between the same pair of endpoints to justify introduction of yet another OOB initialization procedure.

My 2,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, November 03, 2015 3:16 PM
To: Reshad Rahman (rrahman)
Cc: [email-masked]
Subject: Re: Multiple BFD sessions between the same pair of end-points

Hi Reshad,

However, on a single interface between two forwarding endpoints, there could be multiple sessions in a generic application. The simplest example is what is described in the second paragraph of https://tools.ietf.org/html/rfc5882#section-6. In that case, a path is a specific diffserv code point over IPv4 between two endpoints, and that is the context used for initialization using single-hop procedures. In RFC5885 we chose to allow only one, to use single-hop initialization for example within a tunnel (PW) context.

For the multi-hop case, there could also be multiple sessions between endpoints. If there is only one session, then the initialization can be done using single-hop procedures binding source/dst addresses. However, is there are multiple sessions, as e.g., if there is some ECMP-awareness, then some different and additional mechanism (e.g., out-of-band bootstrapping) is needed. This is described in the second paragraph of https://tools.ietf.org/html/rfc5883#section-3. In fact, these two options are covered in S4.1 (limit to one session and use src/dst) and S4.2 (allow multiple sessions and use an OOB bootstrapping).

Thanks,

— Carlos.

On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sam,

Regards,
Reshad.

Reshad,

Hi Santosh,

-sam

Regards,
Reshad.

Thanks
Santosh P K

Dear All,

                Regards,
                                Greg

---

From: Santosh P K <[email-masked]>
Date: Tue, 3 Nov 2015 13:44:11 +0000

Carlos,
OOB for multihop is not there and it is out of scope of RFC. Having said that there are bunch of extension to IGP already which carries BFD discriminator which could be leveraged for OOB for MH BFD session.

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, November 03, 2015 6:46 PM
To: Reshad Rahman (rrahman) <[email-masked]>
Cc: [email-masked]
Subject: Re: Multiple BFD sessions between the same pair of end-points

Hi Reshad,

Thanks,

— Carlos.

Hi Sam,

Regards,
Reshad.

Reshad,

Hi Santosh,

-sam

Regards,
Reshad.

Thanks
Santosh P K

Dear All,

                Regards,
                                Greg

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 4 Nov 2015 00:48:44 +0000

<Speaking as individual contributor>

Hi all,

Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD sessions for MH, I think that the operational model for BFD IP MH should allow for multiple sessions between 2 endpoints (same src/dst/vrf). To support this, we could e.g. add local discriminator to the key.

Note that I am not pushing for another OOB mechanism.

Regards,
Reshad.

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 3, 2015 at 9:38 AM
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Reshad <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Multiple BFD sessions between the same pair of end-points

Hi all,

My 2,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Hi Reshad,

Thanks,

— Carlos.

Hi Sam,

Regards,
Reshad.

Reshad,

Hi Santosh,

-sam

Regards,
Reshad.

Thanks
Santosh P K

Dear All,

                Regards,
                                Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 4 Nov 2015 00:51:41 +0000

That makes sense to me, Reshad, Thanks,

— Carlos.

> On Nov 4, 2015, at 9:48 AM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> From: Alexander Vainshtein <[email-masked] <mailto:[email-masked]>>
> To: "Carlos Pignataro (cpignata)" <[email-masked] <mailto:[email-masked]>>, Reshad <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Email:   [email-masked] <mailto:[email-masked]>
> 
> From: Rtg-bfd [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carlos Pignataro (cpignata)
> Cc: [email-masked] <mailto:[email-masked]>
>> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Sam,
>>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 4 Nov 2015 01:20:17 -0800

Hello Reshad and other BFD experts,

I'm not too deep into YANG et al., so I apologize upfront for this email :-) 
. I understand YANG is about configuration but are we trying to find a common 
way to reflect the various (CLI-)configurations that are out in the market? 
Isn't this, well, a bit restricting?

Should a generic "configuration" of a BFD session not contain all the 
variables of the particular layers? E.g. for the BFD packet itself not just 
timer and multiplier but "my" and "your" discriminator too? For the IP layer 
src/dst IP and egress interface?

The various RFCs 5881, 5883, ... would be special cases that could be 
incorporated. E.g. a "your" discriminator of zero (or lack of this parameter) 
for a single-hop IP-based BFD session would mean to follow RFC5881 and it's 
bootstrapping mechanism.

Maybe this is too generic to start the YANG endeavor. But in these days of 
"programmability" I would expect more than an API that replaces my CLI 1:1.

Regards, Marc

On Wed, 4 Nov 2015 00:48:44 +0000, Reshad Rahman (rrahman) wrote:
> Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD 
> sessions for MH, I think that the operational model for BFD IP MH should 
> allow for multiple sessions between 2 endpoints (same src/dst/vrf). To 
> support this, we could e.g. add local discriminator to the key. 
> 
> From: Alexander Vainshtein <[email-masked]>
> To: "Carlos Pignataro (cpignata)" <[email-masked]>, Reshad 
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> I concur with Carlos, only wanted to add that in the case of BFD in MPLS 
> LSP ability for in-band initialization does not exist (e.g. in the case of 
> PHP, see Section 5 in RFC 5884), and so an OOB initialization procedure was 
> unavoidable.
>  
> I’d say we need a very strong use case for multiple BFD sessions between 
> the same pair of endpoints to justify introduction of yet another OOB 
> initialization procedure.
>  
> My 2,
> Sasha
>  
> Office: +972-39266302
> Cell:      +972-549266302
> It really depends on what is considered a “path” over which BFD detects 
> faults, and how the initial demux can be done vs. bootstrapped out-of-band.
>  
> RFC 5881 has the text quoted by Greg, because in that case single-hop 
> initialization procedures can be done (by binding the interface to BFD 
> context) and not require out-of-band discriminator bootstrapping.
>  
> However, on a single interface between two forwarding endpoints, there 
> could be multiple sessions in a generic application. The simplest example 
> is what is described in the second paragraph of 
> https://tools.ietf.org/html/rfc5882#section-6. In that case, a path is a 
> specific diffserv code point over IPv4 between two endpoints, and that is 
> the context used for initialization using single-hop procedures. In RFC5885 
> we chose to allow only one, to use single-hop initialization for example 
> within a tunnel (PW) context.
>  
> For the multi-hop case, there could also be multiple sessions between 
> endpoints. If there is only one session, then the initialization can be 
> done using single-hop procedures binding source/dst addresses. However, is 
> there are multiple sessions, as e.g., if there is some ECMP-awareness, then 
> some different and additional mechanism (e.g., out-of-band bootstrapping) 
> is needed. This is described in the second paragraph of 
> https://tools.ietf.org/html/rfc5883#section-3. In fact, these two options 
> are covered in S4.1 (limit to one session and use src/dst) and S4.2 (allow 
> multiple sessions and use an OOB bootstrapping).
>  
> As far as the YANG models, I’d think that single session for both single- 
> and multi-hop covers vast majority of real cases, being pragmatic. If 
> someone wants to have for example multiple sessions between a pair of 
> endpoint addresses in multi-hop, then an OOB mechanism is needed, and I do 
> not believe there is a spec’ed one other than for MPLS.
>  
> Thanks,
>  
> ― Carlos.
>  
>> Also looks like there was confusion in the design team (seemingly caused 
>> by my misinterpretation of what was said), there is no known 
>> implementation which supports multiple BFD single-hop sessions for the 
>> same pair of endpoints (right Santosh?). For MH it’s a different story 
>> because of multiple-paths. 
>>  
>> From: Sam Aldrin <[email-masked]>
>> To: Reshad <[email-masked]>
>> Cc: Santosh P K <[email-masked]>, Gregory Mirsky 
>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>> Even for single-hop we had discussions about implementations which 
>>> support the option of having multiple BFD single-hop sessions on 1 
>>> interface between 2  endpoints. That was an argument for having the BFD 
>>> config in routing applications. This is what was discussed today in the 
>>> WG. And I think Greg’s point is that we don’t have to support this in 
>>> the base model, but implementations are have vendor specific model which 
>>> supports this behavior.
>> Are there already vendor specific models/implementations in the single hop 
>> case? OR did you mean, there could be vendor specific extensions?
>>  
>> -sam
>> 
>> 
>>  
>> Regards,
>> Reshad.
>>  
>>  
>> From: Rtg-bfd <[email-masked]> on behalf of Santosh P K 
>> <[email-masked]>
>> To: Gregory Mirsky <[email-masked]>, "[email-masked]" 
>> <[email-masked]>
>> Which says for singlehop you will have only single BFD session for an 
>> interface.  The case where we are struggling in Yang is for multihop BFD 
>> session.
>>  
>> Thanks
>> Santosh P K 
>>  
>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 5 Nov 2015 04:27:14 +0000

Hi Marc,

For classical BFD we are looking at matching with what’s currently in CLI
(config, operational, …).

When we tackle YANG for S-BFD, that’s when we’ll look at the
programmability aspect.

Regards,
Reshad.

On 2015-11-04, 6:20 PM, "Marc Binderberger" <[email-masked]> wrote:

>>> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman)
>>><[email-masked]>
>>> wrote:
>>>  
>>> Hi Sam,
>>>  
>>>> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman)
>>>><[email-masked]>
>>>> wrote:
>>>>  
>>>> Hi Santosh,
>>>>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Nov 2015 18:50:40 -0500

> Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD sessions for MH, I think that the operational model for BFD IP MH should allow for multiple sessions between 2 endpoints (…

I think having operational support is a good thing to have.  It's a small
amount of future-proofing for a case that's getting repeated, if low-grade
discussion.

> Note that I am not pushing for another OOB mechanism.

I also think that bootstrapping a second session in the yang module is
currently out of scope.  

-- Jeff (speaking as an individual contributor)

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Nov 2015 18:54:03 -0500

Marc,

> Isn't this, well, a bit restricting?

Generally, Yang modules in IETF have focused more on configuration at the
start, but Yang and netconf also cover operational state as well, including
notifications.  

> src/dst IP and egress interface?

For operational state, absolutely.

For configuration state, reflecting constraints for provisioning the
existing mechanisms is probably where we want to start.  It could be easily
argued that we could simply provide for completely abstract configuration of
sessions, but that means that the model would fail to enforce constraints
that real implementations have.  The current example of this is multiple
sessions between the same pair of endpoints.

> "programmability" I would expect more than an API that replaces my CLI 1:1.

Arguably, we're more at "generic CLI" than full-out API.  However, this is
mostly my somewhat tainted opinion as i2rs chair. :-)