Subject: S-BFD Discriminator Types?

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 23 May 2014 01:32:40 +0000

Hi [S-]BFDers,

As part of next set of changes for the bfd-seamless-base document, I wanted us to revamp sections 3 and 4 which have become stale. 

Current texts implies that we create following relationships in the BFD Target Identifier Table.

S-BFD Discriminator  --> BFD Target Identifier --> BFD Target Identifier Type

This is no longer necessary. Mapping of local S-BFD discriminators to local entities can be created, but that's an implementation matter. This mapping does not have to be mandated in the document.

Which puts us in:

Option #1:

Define S-BFD Discriminator Types (renamed from BFD Target Identifier Type), and define following relationships.

S-BFD Discriminator --> S-BFD Discriminator Type.

Now, the other question that I have is, do we need to define S-BFD Discriminator Types, and they be IANA maintained? I do realize that there will be several "types" of S-BFD discriminators over time. However, when S-BFD discriminators are advertised by applications, then those applications will be advertising what each S-BFD discriminator is for (mapping to specific entity). Therefore, the application implies the "type" and the mapping implies the "context".

If there is going to be any application that will be advertising multiple S-BFD discriminator "types", then it _is_ beneficial for S-BFD base to define those types. However, I am not finding any such use case at the moment. That means, it is possible for us to clean up sections 3 and 4 even further, and go with:

Option #2:

Do not define any BFD Target Identifier Types nor S-BFD Discriminator Types.

Any thoughts on this?

-Nobo

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 28 May 2014 06:42:47 +0530

Hi Nobo,

I remember having this discussion with you earlier (when the details had
still not been fleshed out) where i was not convinced upon the need to
define SFD Discriminator  --> BFD Target Identifier --> BFD Target
Identifier Type in the draft.

I understand that there can be various S-BFD descriminator types. We could
have one that identifies a network node. We could potentially have another
that defines an application running within a VM context and so on.

However, i dont see why we would ever need S-BFD descriminator ->
descriminator type mapping for the interop purposes -- afterall whatever
gets into an IETF draft is primarily to help interop between different
vendors. Wouldnt this be an implementation specific issue?

Cheers, Manav

On Fri, May 23, 2014 at 7:02 AM, Nobo Akiya (nobo) <[email-masked]> wrote:

> Hi [S-]BFDers,
>
> As part of next set of changes for the bfd-seamless-base document, I
> wanted us to revamp sections 3 and 4 which have become stale.
>
> This is no longer necessary. Mapping of local S-BFD discriminators to
> local entities can be created, but that's an implementation matter. This
> mapping does not have to be mandated in the document.
>
> Which puts us in:
>
>
> Option #1:
>
> Define S-BFD Discriminator Types (renamed from BFD Target Identifier
> Type), and define following relationships.
>
> Now, the other question that I have is, do we need to define S-BFD
> Discriminator Types, and they be IANA maintained? I do realize that there
> will be several "types" of S-BFD discriminators over time. However, when
> S-BFD discriminators are advertised by applications, then those
> applications will be advertising what each S-BFD discriminator is for
> (mapping to specific entity). Therefore, the application implies the "type"
> and the mapping implies the "context".
>
> If there is going to be any application that will be advertising multiple
> S-BFD discriminator "types", then it _is_ beneficial for S-BFD base to
> define those types. However, I am not finding any such use case at the
> moment. That means, it is possible for us to clean up sections 3 and 4 even
> further, and go with:
>
>
> Option #2:
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 28 May 2014 09:25:55 +0000

Hi Nobo,

Regarding the S-BFD identifier types, since the usage of S-BFD Discriminator/identifier is to identify a specific S-BFD session, and the purpose of the session is up to the application. IMHO, if there is no use case that requires different types, we'd better go with option 2.

Best regards,
Mach
 
> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
> Sent: Friday, May 23, 2014 9:33 AM
> To: [email-masked]
> Subject: S-BFD Discriminator Types?
> 
> Hi [S-]BFDers,
> 
> As part of next set of changes for the bfd-seamless-base document, I wanted us
> to revamp sections 3 and 4 which have become stale.
> 
> This is no longer necessary. Mapping of local S-BFD discriminators to local entities
> can be created, but that's an implementation matter. This mapping does not have
> to be mandated in the document.
> 
> Which puts us in:
> 
> 
> Option #1:
> 
> Now, the other question that I have is, do we need to define S-BFD Discriminator
> Types, and they be IANA maintained? I do realize that there will be several
> "types" of S-BFD discriminators over time. However, when S-BFD discriminators
> are advertised by applications, then those applications will be advertising what
> each S-BFD discriminator is for (mapping to specific entity). Therefore, the
> application implies the "type" and the mapping implies the "context".
> 
> If there is going to be any application that will be advertising multiple S-BFD
> discriminator "types", then it _is_ beneficial for S-BFD base to define those types.
> However, I am not finding any such use case at the moment. That means, it is
> possible for us to clean up sections 3 and 4 even further, and go with:
> 
> 
> Option #2:
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 28 May 2014 14:44:23 +0000

Hi Manav, Mach,

Thanks for providing your thoughts, and I agree. I think we should proceed with option #2 (i.e. not define IANA maintained S-BFD discriminator types). If anybody don't think this is the way to go, feel free to chime in and let us discuss further.

Thanks,
Nobo

> From: Mach Chen [mailto:[email-masked]]
> Sent: Wednesday, May 28, 2014 5:26 AM
> To: Nobo Akiya (nobo); [email-masked]
> Subject: RE: S-BFD Discriminator Types?
> 
> Hi Nobo,
> 
> Regarding the S-BFD identifier types, since the usage of S-BFD
> Discriminator/identifier is to identify a specific S-BFD session, and the
> purpose of the session is up to the application. IMHO, if there is no use case
> that requires different types, we'd better go with option 2.
> 
> Best regards,
> Mach
> 
> > local entities can be created, but that's an implementation matter.
> > This mapping does not have to be mandated in the document.
> >
> > Which puts us in:
> >
> >
> > Option #1:
> >
> > Discriminator Types, and they be IANA maintained? I do realize that
> > there will be several "types" of S-BFD discriminators over time.
> > However, when S-BFD discriminators are advertised by applications,
> > then those applications will be advertising what each S-BFD
> > discriminator is for (mapping to specific entity). Therefore, the application
> implies the "type" and the mapping implies the "context".
> >
> > If there is going to be any application that will be advertising
> > multiple S-BFD discriminator "types", then it _is_ beneficial for S-BFD base
> to define those types.
> > However, I am not finding any such use case at the moment. That means,
> > it is possible for us to clean up sections 3 and 4 even further, and go with:
> >
> >
> > Option #2:
> >