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. 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.

Regards,
Greg

On Mon, Feb 18, 2019 at 7:53 PM Reshad Rahman (rrahman) <rrah...@cisco.com>
wrote:

> Hi Greg,
>
>
>
> So the text below is for what you had mentioned in a previous email: “The
> draft proposes to update RFC 5880 in regard to the behavior of BFD system
> in Demand mode so that such system MAY start Poll sequence to inform the
> remote BFD system of the change in BFD session state, i.e. signal RDI.” But
> isn’t that already covered in section 6.6
> <https://tools.ietf.org/html/rfc5880#section-6.6> of 5880?
>
>
>
>    If Demand mode is active on either or both systems, a Poll Sequence
>
>    MUST be initiated whenever the contents of the next BFD Control
>
>    packet to be sent would be different than the contents of the
>
>    previous packet, with the exception of the Poll (P) and Final (F)
>
>    bits.  This ensures that parameter changes are transmitted to the
>
>    remote system and that the remote system acknowledges these changes.
>
>
>
> Regards,
>
> Reshad (no hat).
>
>
>
> *From: *Greg Mirsky <gregimir...@gmail.com>
> *Date: *Monday, February 18, 2019 at 1:03 PM
> *To: *Jeffrey Haas <jh...@pfrc.org>
> *Cc: *"Reshad Rahman (rrahman)" <rrah...@cisco.com>, Martin Vigoureux <
> martin.vigour...@nokia.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
> *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
>
>
>
> Hi Jeff,
>
> here's the text from the draft that describes the behavior on the BFD
> system:
>
>    If the Detection timer at the egress LER expires it MUST send BFD
>
>    Control packet to the ingress LER with the Poll (P) bit set, Status
>
>    (Sta) field set to Down value, and the Diagnostic (Diag) field set to
>
>    Control Detection Time Expired value.  The egress LER sends these
>
>    Control packets to the ingress LER at the rate of one per second
>
>    until either it receives the valid for this BFD session control
>
>    packet with the Final (F) bit set from the ingress LER or the defect
>
>    condition clears and the BFD session state reaches Up state at the
>
>    egress LER.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas <jh...@pfrc.org> wrote:
>
> On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> > As for your question of what is the change proposed in the draft I'll
> point
> > to section 6.6 RFC 5880 that describes the Demand mode. It states that
> the
> > periodic transmission of control messages MUST be stopped.
>
> Correct.
>
> > The draft
> > defines, and that is what I consider the update to section 6.6, the
> > procedure by which the system in Demand mode initiates the Poll sequence
> to
> > inform the remote BFD system of RDI.
>
> Would you clarify where in your draft this is discussed?
>
> > Greg
>
> -- Jeff
>
>

Reply via email to