Subject: S-BFD discriminator for ISIS?

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 31 Jan 2014 23:25:07 +0000

Hi BFDers,

So I had a chat with ISIS person.

Obviously we need ISIS to advertise S-BFD discriminator.
But the question is, how does ISIS choose what discriminator to allocate?

Discriminator should be as much unique as possible in the domain, if not guaranteed unique.
This is to ensure reflector session does not respond to falsely self-terminating S-BFD packet.

1. One approach would be to simply have operators configure network wide unique 4-byte for each ISIS. 

2. Another approach would be to compute 4-byte from *local stuff*, and come up with a conflict resolution mechanism.

My initial thought is that (1) is reasonable for immediate needs.
But wanted to check with others on the list.

Any comments and/or preferences?

-Nobo
(as individual contributor)

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 31 Jan 2014 17:11:48 -0800

Hi Nobo,

Option #1 is a reasonable approach and is the understanding for the solutions discussed thus far. Eventually support for #2 should be there as well, but that does take time and discussions to come to a common solution. 

Cheers
-sam

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 31 Jan 2014 17:39:33 -0800

Hello Nobo,

must have missed some discussions ...

> Obviously we need ISIS to advertise S-BFD discriminator.

... but you mean the discriminator of the reflecting node is not 
identical with the IPv4 address anymore but potentially independent and 
learned by the other systems, with ISIS as the distribution mechanism?

Good! :-)

> But the question is, how does ISIS choose what discriminator to allocate?

Maybe a nitpick but ISIS should transport the discriminator value of a 
particular site but should not have knowledge how to choose a 
discriminator. Just another 32bit number for ISIS to send as TLV.

Saying this if ISIS finds a conflict in it's database, i.e. two 
identical discriminators from different nodes, then raising an alarm 
would be useful (not necessary though).

> wide unique 4-byte for each ISIS. 

sounds like a working solution to start with. Also it provides a simple 
answer to an area I think is an implementation detail, outside BFD or 
even ISIS protocol specification.

Regards, Marc

> 2. Another approach would be to compute 4-byte from *local stuff*, 
> and come up with a conflict resolution mechanism.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 1 Feb 2014 02:31:31 +0000

Thanks for comments Sam and Marc.

[combining reply in one]

[Sam wrote]
> Option #1 is a reasonable approach and is the understanding for the
> solutions discussed thus far. Eventually support for #2 should be there as
> well, but that does take time and discussions to come to a common
> solution.

That's good to hear that you also think option #1 is reasonable. More comments about option #2 below.

[Marc wrote]
> ... but you mean the discriminator of the reflecting node is not identical
> with the IPv4 address anymore but potentially independent and learned by
> the other systems, with ISIS as the distribution mechanism?
> 

IPv4 address can remain the same, i.e. IPv4 address used as discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to distribute system-id (6 bytes) to discriminator (4 bytes) mapping.

> discriminator. Just another 32bit number for ISIS to send as TLV.

True. It could be outside of ISIS as well, but some entity will have to do it.

> 
> Saying this if ISIS finds a conflict in it's database, i.e. two identical
> discriminators from different nodes, then raising an alarm would be useful
> (not necessary though).

Exactly. BFD won't be able to detect the conflict but BFD client (ISIS in this case) is in better position to identify the conflict. Upon conflict, which node need to change then, and how to change w/o affecting reflector session already bouncing packets back. These sort of questions will need to be answered, when we (WG) think it's wanted/needed.

> answer to an area I think is an implementation detail, outside BFD or even
> ISIS protocol specification.

Good :)

If there are other agreements to option #1 (config approach) or arguments against it, I certainly would like to hear. It will help improve usability of S-BFD out in the wild.

-Nobo

> > 2. Another approach would be to compute 4-byte from *local stuff*, and
> > come up with a conflict resolution mechanism.
> >

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 31 Jan 2014 23:13:18 -0800

Hi Nobo,

> IPv4 address can remain the same, i.e. IPv4 address used as 
> discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to 
> distribute system-id (6 bytes) to discriminator (4 bytes) mapping.

hmm. You know from our private discussions that I personally think 
using IPv4 addresses as discriminator values is, well, not optimal ;-)

But before explaining this I would say having one mechanism that 
"covers it all" would be a good thing (tm). Like ISIS covers both IPv4 
and IPv6, you don't have to learn a new mechanism.

So for a network node you would have it's labels and it's discriminator 
value (or values?). For simplicity of this discussion lets say assigned 
by an administrator with a full overview. Then ISIS distributes this. 
Some node X wants to BFD-test the path to node Y? Okay, X has learned 
via ISIS the necessary information.

Generic, I haven't talked anywhere about IPv4 or IPv6 :-)

Back to my "not optimal": so far a node was free to choose what 
discriminator values it wants to use. The BFD peer (in RFC5880 sense) 
just copied the value back. This freedom of choice has been used to 
simplify implementations, e.g. only using the lower bits to index into 
arrays or match in TCAMs. And so far all the standards have abide and 
not imposed a condition or structure on the discriminator values 
(except zero).

Sure, you can get the Address-as-discriminator scheme working. But why 
taking this freedom for the implementor away?

But I wasn't in Vancouver and may have missed something :-)

Regards, Marc

On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote:
> IPv4 address can remain the same, i.e. IPv4 address used as 
> discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to 
> distribute system-id (6 bytes) to discriminator (4 bytes) mapping.
> 
> Exactly. BFD won't be able to detect the conflict but BFD client 
> (ISIS in this case) is in better position to identify the conflict. 
> Upon conflict, which node need to change then, and how to change w/o 
> affecting reflector session already bouncing packets back. These sort 
> of questions will need to be answered, when we (WG) think it's 
> wanted/needed.
> 
>> 
> If there are other agreements to option #1 (config approach) or 
> arguments against it, I certainly would like to hear. It will help 
> improve usability of S-BFD out in the wild.
> 
> -Nobo
> 
>> 
>> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>>>