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

[Sam Aldrin <[e-mail]>]

Hi Nobo,

Thank you for the reply.

Inline for my comments.

-sam
> On Nov 25, 2014, at 5:55 PM, Nobo Akiya (nobo) <[e-mail]> wrote:
> 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];
>> [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.
Ah ok! I didn't know there would much worry about Alert Discriminator as a use case. If you say, it was not discussed much, then I am ok with your reasoning.
> 
> 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.
Sounds fair. Additionally, you should start discussion on alert discriminator as well. Feel it has usefulness. 

> 
>> 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).
Nod. 
> 
>> 
>> 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?
Affirm. clear now.

> 
>> 
>> 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?
Yes, indeed is a plan.

-sam
> 
> Thanks!
> 
> -Nobo
> 
>> 
>> cheers
>> sam