Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas <[e-mail]>]

Greg,

On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> I'm glad that you feel that our discussion is helpful. I want to point that
> the use of the Poll sequence to communicate to the remote BFD system in the
> Concatenated Paths section is to relay the failure detected in the
> downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> does not specify how the upstream BFD system responds to the situation:
>    Note that if the BFD session subsequently fails, the diagnostic code will
>    be overwritten with a code detailing the cause of the failure.  It is
>    up to the interworking agent to perform the above procedure again,
>    once the BFD session reaches Up state, if the propagation of the
>    concatenated path failure is to resume.

Correct.  That is up to the upstream to determine its behavior.

> And so far we were discussing RFC 5880 though the scope of the draft is on
> the use of Demand mode over MPLS LSP.

MPLS does not magically change the behavior of demand mode specified in the
core RFC.

> And the draft does describe how the
> BFD system acts after it receives the control message with Diag field set
> to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> that, I consider, the draft is complimentary to RFC 5884 whose scope is on
> the Asynchronous mode only.

I continue to have problems understanding how the text in your draft is
intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
allowed to use demand mode" can't be it?

It will help clear this conversation if you simply state your changes in
behavior vs. 5880 and 5884. 

> I believe that the draft addresses practical scenario with the technical
> and innovative solution. And it was recognized as such by several WG
> participants during the WG AP. Much appreciate your consideration.

A reminder that we don't vote.  C.f. RFC 7282, section 6.

-- Jeff