Hi Jeff, 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.) Regards, Greg On Tue, Feb 19, 2019 at 9:42 AM Jeffrey Haas <jh...@pfrc.org> wrote: > 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 > >
