Subject: RE: S-BFD discriminator for ISIS?

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

Hi Marc,

Simplicity of using <=4 byte IDs as target discriminator is still strong, as it allows S-BFD to be quickly plugged into various scenarios where apps are already signaling the IDs or there is no signaling at all. At the same time, how do we want to handle >4 byte IDs ... it looks like consensus [so far] is static config for near future, and possibly some sort of auto mechanism later.

Related but slightly tangent topic is the point you brought up: impact to discriminator implementations. I agree that this is a good topic to discuss further. Considering that S-BFD will use new UDP port, I'm under the impression that new set of rules can be implemented by vendors, i.e. old rules do not have to be carried over, although more code recycling the better.

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

There wasn't any discussion around this (impact to discriminator implementations) at Vancouver, discussion was more centered around need for use-case draft (which is in progress) and shaking out the quirks from the base draft. Let us continue to think and discuss.

-Nobo

> -----Original Message-----
> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Saturday, February 01, 2014 2:13 AM
> To: Nobo Akiya (nobo)
> Cc: Sam Aldrin; [email-masked]
> Subject: RE: S-BFD discriminator for ISIS?
> 
> 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:
> > 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]
> >>> So I had a chat with ISIS person.
> >>>
> >>> 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?
> >>
> >
> > 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.
> >
> >>> 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.
> >
> > 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.
> >
> >>
> >>> 1. One approach would be to simply have operators configure network
> >>> 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.
> >
> > 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
> >
> >>
> >>
> >> Regards, Marc
> >>
> >>
> >>
> >>
> >>>
> >>> 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: Gregory Mirsky <[email-masked]>
Date: Sun, 2 Feb 2014 00:10:08 +0000

Hi Marc, Nobo, et. al,
glad to have our discussion back.
I'm all for explicit mapping of NE and discriminators. Using IGP lets us not only advertise the discriminator but to withdraw the advertisement at will. With this approach we may manage to keep BFD and S-BFD discriminator spaces as one, if we find this goal worth pursuing.
And if we find that Seamless BFD is useful in Segment Routing network, then label advertised by IGP can be viewed as implicit discriminator. If that is the case, why not to use extensions proposed for SR in SPRING WG, perhaps with extra twists, to advertise discriminators for S-BFD. What do you think?

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Friday, January 31, 2014 11:13 PM
To: Nobo Akiya
Cc: [email-masked]; Sam Aldrin ([email-masked])
Subject: RE: S-BFD discriminator for ISIS?

Hi Nobo,

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

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?

Regards, Marc

On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote:
>> and learned by the other systems, with ISIS as the distribution mechanism?
>> 
> 
>>> But the question is, how does ISIS choose what discriminator to allocate?
>>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 3 Feb 2014 13:49:07 +0000

Hi Greg, Marc, Sam, et al,

I'm starting to agree that explicit mapping and advertisement of NE and discriminators is the right way to go.

> And if we find that Seamless BFD is useful in Segment Routing network,
> then label advertised by IGP can be viewed as implicit discriminator. If that
> is the case, why not to use extensions proposed for SR in SPRING WG,
> perhaps with extra twists, to advertise discriminators for S-BFD. What do
> you think?

If we go with explicit mapping and advertisement of NE and discriminators, then IGPs are already advertising discriminators, even in SR network. We can use what's already advertised (i.e. NE to discriminator mapping), as opposed to using label/index as discriminators. Perhaps there'll be some additions specific to SR that'll require us to keep bfd-seamless-sr draft alive, but bigger fish really becomes publishing IGP extensions to carry BFD discriminators.

Going with this approach, however, does leave a hole in the scenario where there are no signaling that can carry discriminators. But number of such scenarios is probably much smaller than what we can address with NE/discriminator mapping/advertisement. Let's cross the bridge when we get there.

-Nobo

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Saturday, February 01, 2014 7:10 PM
> To: Marc Binderberger; Nobo Akiya (nobo)
> I'm all for explicit mapping of NE and discriminators. Using IGP lets us not
> only advertise the discriminator but to withdraw the advertisement at will.
> With this approach we may manage to keep BFD and S-BFD discriminator
> spaces as one, if we find this goal worth pursuing.
> And if we find that Seamless BFD is useful in Segment Routing network,
> then label advertised by IGP can be viewed as implicit discriminator. If that
> is the case, why not to use extensions proposed for SR in SPRING WG,
> perhaps with extra twists, to advertise discriminators for S-BFD. What do
> you think?
> 
> 	Regards,
> 		Greg
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Feb 2014 14:34:03 -0500

On Sun, Feb 02, 2014 at 12:10:08AM +0000, Gregory Mirsky wrote:
> I'm all for explicit mapping of NE and discriminators. Using IGP lets us
> not only advertise the discriminator but to withdraw the advertisement at
> will. With this approach we may manage to keep BFD and S-BFD discriminator

I'm definitely not a fan of just grabbing IP addresses and using them.  Thus
I'm happy to see discussion moving toward other options.

> then label advertised by IGP can be viewed as implicit discriminator. If
> that is the case, why not to use extensions proposed for SR in SPRING WG,

I'd be very cautious about this as well for several reasons:
- Labels have a much smaller space than a BFD Discriminator.
- Labels can change for whatever reason and putting additional couplings on
  them outside of the MPLS forwarding plane is probably not the best idea.
- IGPs will take time to converge.  Frequent changes tend to get throttled.
  Relying on any mechanism that causes numbers to be negotiated on remote
  nodes via iterations of IGP convergence is not pretty.

-- Jeff