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

["MALLIK MUDIGONDA (mmudigon)" <[e-mail]>]

Hi Nobo,

I am convinced. If Sam doesn’t have any further comments I think we are good to go.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 26 November 2014 7:25 am
To: Sam Aldrin <[e-mail]<mailto:[e-mail]>>
Cc: Cisco Employee <[e-mail]<mailto:[e-mail]>>, Marc Binderberger <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim

Hi Sam,

Good points, please see in-line with [NOBO].

-----Original Message-----
From: Sam Aldrin [mailto:[e-mail]]
Sent: Monday, November 24, 2014 8:29 PM
To: Nobo Akiya (nobo)
Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim
[resending as mailer complained, mail is too long; removed earlier content
as well)
Hi Nobo et al,
I have finally read the 'alert discriminator' document.

[NOBO] Thanks!

Keeping the solution aside, what makes it special that the use case cannot
be documented in 'use case' ID?

[NOBO] I have flip-flopped on the document structure but here's my current thoughts.

Currently the S-BFD use case document describes the use cases for the core S-BFD functionality described in the S-BFD base document.

As you described below, we do not yet have the WG consensus on the alert discriminator use cases nor the mechanism, and this is something which needs to get discussed more.

However, there is no reason to halt the progress of S-BFD use-case/base/ip documents as there is no dependency from them to the alert discriminator.

Therefore at this point it makes sense [to me] that we:
1) Progress S-BFD use-case document.
2) Progress S-BFD base/ip documents.
3) Discuss the use-cases/mechanism of the alert discriminator, without creating a dependency from (1, 2) to the alert discriminator.

Irrespectively, while explaining the solution, the problem has to be
explained anyway.

[NOBO] Agree.

But, when there is use case document, like other use cases, adding the use
case will be good, doesn't it?

[NOBO] If they are use cases for the base functionality, then definitely yes. If there are use cases that require further extensions to the base functionality, then I think the answer really depends (like where we are).

I know it will only delay the use-case document, which I am an editor of it.
Want to understand the rationale behind it. (Read emails, but don't think I
am convinced).

[NOBO] I hope above provides more context on where we are?

Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2).
I am not sure if it is indeed needed as BFD was not used so far like this.
Just a simple extension or not is different matter. Whether we should be
doing it with BFD (not just S-BFD) is more important and needs to be
discussed.

[NOBO] Fully agree that we need to discuss above further.

And I do not think that it should be part of S-BFD use case at this point.

[NOBO] Excellent! So we are in sync about the document structure then. Let push proceed with this path, and spawn off a separate thread to discuss the validity of the alert discriminator use-cases and the mechanism. Sounds like a plan?

Thanks!

-Nobo

cheers
sam