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

Jeffrey Haas <jhaas@pfrc.org> Tue, 19 February 2019 17:42 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5C4130F7B for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Feb 2019 09:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7nKmx8RERs0 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Feb 2019 09:42:14 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96F130F5B for <rtg-bfd@ietf.org>; Tue, 19 Feb 2019 09:42:14 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 381D21E2D8; Tue, 19 Feb 2019 12:41:11 -0500 (EST)
Date: Tue, 19 Feb 2019 12:41:10 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Message-ID: <20190219174109.GN28950@pfrc.org>
References: <20190216184510.GF28950@pfrc.org> <CA+RyBmUHm5YnbuFp6oiXUVnVS+0kfSW8xdJqjwC+HiP_WfqKBA@mail.gmail.com> <20190218152544.GG28950@pfrc.org> <CA+RyBmUGwZj0AuQWT+atzeN9uR4i5ffpzeKsMM_fRYB5BVmFVw@mail.gmail.com> <20190218162350.GH28950@pfrc.org> <CA+RyBmUs-C6JC=O-k-hyRtNeJ-CTR++syEs6vteGDmcAotTw6g@mail.gmail.com> <20190218173351.GI28950@pfrc.org> <CA+RyBmXN=0FYoHWt4TzPg05_ZoC9RbsOSvoFAte9doDY8_JDgg@mail.gmail.com> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <CA+RyBmVtLXSZfADQ9YgBEWj+d_X=zXh6SwSfqrUSNWiVNTwNXA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+RyBmVtLXSZfADQ9YgBEWj+d_X=zXh6SwSfqrUSNWiVNTwNXA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/coLQBIGDkAaxXoOXku5oAVbeB4I>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2019 17:42:16 -0000

A reminder from 5880's state machine (6.8.6)

:       Else
[...]
:           Else (bfd.SessionState is Up)
:               If received State is Down
:                   Set bfd.LocalDiag to 3 (Neighbor signaled
:                       session down)
:                   Set bfd.SessionState to Down
: 
:       Check to see if Demand mode should become active or not (see
:       section 6.6).

[...]
:       If the Poll (P) bit is set, send a BFD Control packet to the
:       remote system with the Poll (P) bit clear, and the Final (F) bit
:       set (see section 6.8.7).

A change of state doesn't need a poll sequence.
A change of state is dealt with prior to considering demand mode
considerations.
Poll behavior is considered after both of these.


On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote:
> Hi Reshad,
> thank you for your question. I've thought that it is the case but then have
> asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead uses
> a combination of multicast and unicast Poll sequences to verify whether the
> particular MultipointTail considers the p2mp BFD session Up.

Because tails are normally expected to be silent.  A core motivation of
splitting the active tail procedures from the original draft is there are
many applications where the head doesn't need or want the state from the
tails.

In cases where the head does care, the differing procedures attempts to
determine a given tail's perception of the state.  A multipoint poll would
determine if the tail is hearing the session via the multipoint BFD packets.
In absence of that, unicast might be used, although it doesn't verify that
multipoint connectivity is working.  Section 5 of the draft goes through the
different scenarios.

>  Would it be
> simpler, assuming that the quote describes the same behavior as proposed in
> the draft, to enable MultipointTail to send Poll sequence with RDI? Thus
> I've concluded that RFC 5880 does not cover the scenario and have started
> the draft.

You keep on mentioning RDI.  Are you intending to have this in the context
of RFC 6428?  If so, the discussion is really against the procedures in that
RFC which are deviations from core RFC 5880/5884 behaviors.

This is really the point lacking clarity.

-- Jeff