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
