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

[Greg Mirsky <[e-mail]>]

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.
And so far we were discussing RFC 5880 though the scope of the draft is on
the use of Demand mode over MPLS LSP. 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 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.

Regards,
Greg


On Tue, Feb 19, 2019 at 8:44 PM Jeffrey Haas <[e-mail]> wrote:

> Greg,
>
> We seem now to be converging on the substance of your draft.  Thanks for
> sticking with this.
>
> On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote:
> > thank you for pointing to the sloppy terminology I've used referring to
> > what is the proposed update to RFC 5880. In fact, the draft, as I should
> > have done too, refers to the Diag field. Below are quotes from RFC 5880
> to
> > help me explain the intended update:
> >
> >    - is section 6.1 Poll sequence in Demand mode MAY be used by any peer
> to
> >    verify the bidirectional path continuity (connectivity):
> >
> >    If either system wishes to verify
> >    bidirectional connectivity, it can initiate a short exchange of BFD
> >    Control packets (a "Poll Sequence"; see section 6.5) to do so.
> >
> >    - similarly, the first paragraph in section 6.5:
> >
> >    A Poll Sequence is an exchange of BFD Control packets that is used in
> >    some circumstances to ensure that the remote system is aware of
> >    parameter changes.  It is also used in Demand mode (see section 6.6)
> >    to validate bidirectional connectivity.
> > Again, no reference that the Poll sequence MAY be used to signal the
> change
> > in the Diag field.
> >
> >    - And the very last sentence of section 6.6:
> >
> >    Resolving the issue of one system requesting Demand
> >    mode while the other requires continuous bidirectional connectivity
> >    verification is outside the scope of this specification.
> > Is what is in the scope of the draft we discuss. (Apologies for taking
> too
> > much time to find the right text in RFC 5880.)
>
> I think we're still in the scope of what 5880 permits.
>
> Consider the following:
> :6.8.17.  Concatenated Paths
> :
> :   If the path being monitored by BFD is concatenated with other paths
> :   (connected end-to-end in series), it may be desirable to propagate
> :   the indication of a failure of one of those paths across the BFD
> :   session (providing an interworking function for liveness monitoring
> :   between BFD and other technologies).
> :
> [...]
> :
> :   A system MAY signal one of these failure states by simply setting
> :   bfd.LocalDiag to the appropriate diagnostic code.  Note that the BFD
> :   session is not taken down.  If Demand mode is not active on the
> :   remote system, no other action is necessary, as the diagnostic code
> :   will be carried via the periodic transmission of BFD Control packets.
> :   If Demand mode is active on the remote system (the local system is
> :   not transmitting periodic BFD Control packets), a Poll Sequence MUST
> :   be initiated to ensure that the diagnostic code is transmitted.  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.
>
>
> We thus see here:
> 1. You can propagate state, perhaps your RDI, in a session that is Up.
> 2. If we are in demand mode, by initiating the poll sequence.
>
> Your point about 6.6 and asymmetric configuration of demand mode perhaps
> should be considered in the context of the word "bidirectional".  In a
> profile where we have gone half duplex on the session (one side async
> continuous, other demand), we're likely in a mode where we mostly want
> unidirectional information.  This seems to be perhaps along the lines of
> what you're looking for.  And in such a case, shifting into the poll to
> pass
> along RDI is perfectly reasonable.
>
> If the above reflects a rough understanding of the use case, the core
> content of your draft reduces to:
> - RFC 5880 permits state, such as RDI, to be communicated on an Up session
>   when in demand mode via a poll sequence in the Diag field.
>
> -- Jeff
>