Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

From: Glen Kent <[email-masked]>
Date: Sun, 15 Feb 2015 16:38:31 +0530

Nobo,

Why do you need this mechanism to discover the remote S-BFD discriminators,
when you already have ISIS and OSPF extensions to discover the remote S-BFD
targets.

Glen

On Thu, Jan 29, 2015 at 4:16 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> > To summarize:
> > - I will spawn off a separate thread for the alert discriminator soon.
>
> Hello BFD WG,
>
> Finally getting around to follow up on this AI.
>
>
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/?include_text=1
>
> The document describes one simple extension: Let's make S-BFD
> discriminator zero(0) to have a special meaning.
>
> The primary driver for this is to allow an S-BFD initiator to discover the
> target S-BFD discriminator, by sending an S-BFD ping packet with
> your_disc=0 and getting back a valid S-BFD pong packet with "my_disc=<S-BFD
> discrimiantor>". In other words, when an S-BFD reflector receives an S-BFD
> ping packet with your_disc=0, it processes it because S-BFD discriminator
> zero(0) has a special meaning.
>
> Motivation for using this approach to discover the target S-BFD
> discriminator is described in Section 2.1 of the document.
>
> I think it is most important to discuss this, thus let's leave out
> discussions on other use of the S-BFD alert discriminator (i.e., Section
> 2.2) for now.
>
> Personally, I think this is very useful extension to the S-BFD mechanism
> that we've been working on. I'm curious to see what others think?
>
> Thanks!
>
> -Nobo
>
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 16 Feb 2015 15:48:29 +0000

Hi Glen,

I appreciate you providing a comment on this topic.

Yes there are ISIS and OSPF extensions to discover remote S-BFD discriminators. This will cover many scenarios and can also be leveraged to detect discriminator collisions within the IGP domain. There are couple of other scenarios which we think in-band discovery of remote S-BFD discriminators (i.e., alert discriminator) will be helpful.

First is monitoring of a target beyond the IGP domain (e.g., inter-AS, MS-PW, etc).

Second is usage of S-BFD in a scenario where there is no ISIS/OSPF running (e.g., IP/MPLS statically provisioned networks, TP, etc).

Third is to avoid requiring some further applications to define S-BFD discriminator advertisements when they want to use S-BFD (e.g., simple tunnels).

I hope this clarifies the “why” question, but do let us know if you think it doesn’t or if you think it doesn’t provide sufficient reasons to construct an in-band S-BFD discriminator discovery mechanism.

We also tried to briefly capture these in section 2.1 of the document (draft-akiya-bfd-seamless-alert-discrim). It would also be helpful if you can browse through them.

Thanks!

-Nobo

From: Glen Kent [mailto:[email-masked]]
Sent: Sunday, February 15, 2015 6:09 AM
To: Nobo Akiya (nobo)
Cc: Marc Binderberger; Sam Aldrin; [email-masked]; [email-masked]
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Nobo,

Why do you need this mechanism to discover the remote S-BFD discriminators, when you already have ISIS and OSPF extensions to discover the remote S-BFD targets.

Glen

Hello BFD WG,

The document describes one simple extension: Let's make S-BFD discriminator zero(0) to have a special meaning.

The primary driver for this is to allow an S-BFD initiator to discover the target S-BFD discriminator, by sending an S-BFD ping packet with your_disc=0 and getting back a valid S-BFD pong packet with "my_disc=<S-BFD discrimiantor>". In other words, when an S-BFD reflector receives an S-BFD ping packet with your_disc=0, it processes it because S-BFD discriminator zero(0) has a special meaning.

Motivation for using this approach to discover the target S-BFD discriminator is described in Section 2.1 of the document.

I think it is most important to discuss this, thus let's leave out discussions on other use of the S-BFD alert discriminator (i.e., Section 2.2) for now.

Personally, I think this is very useful extension to the S-BFD mechanism that we've been working on. I'm curious to see what others think?

Thanks!

-Nobo