RE: S-BFD Discriminator Types?

["Nobo Akiya (nobo)" <[e-mail]>]

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

> -----Original Message-----
> From: Mach Chen [mailto:[e-mail]]
> Sent: Wednesday, May 28, 2014 5:26 AM
> To: Nobo Akiya (nobo); [e-mail]
> 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
> 
> > -----Original Message-----
> > From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Nobo
> > Akiya (nobo)
> > Sent: Friday, May 23, 2014 9:33 AM
> > To: [e-mail]
> > 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.
> >
> > 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