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

[Jeffrey Haas <[e-mail]>]

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