Hi Joakim, See inline. On Jul 8, 2012, at 3:44 PM, Joakim Tjernlund wrote:
> Acee Lindem <[email protected]> wrote on 2012/07/08 20:40:59: >> >> Hi Joakim, >> >> On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: >> >>>> From: Joakim Tjernlund <[email protected]> >>>> To: [email protected], >>>> Date: 2012/07/08 13:07 >>>> Subject: [OSPF] OSPF Hello questions >>>> Sent by: [email protected] >>>> >>>> >>>> In RFC2328, last part of chapter 10.5 it reads: >>>> >>>> o Each Hello Packet causes the neighbor state machine to be >>>> executed with the event HelloReceived. >>>> >>>> o Then the list of neighbors contained in the Hello Packet is >>>> examined. If the router itself appears in this list, the >>>> neighbor state machine should be executed with the event 2- >>>> WayReceived. Otherwise, the neighbor state machine should >>>> be executed with the event 1-WayReceived, and the processing >>>> of the packet stops. >>>> >>>> o Next, if a change in the neighbor's Router Priority field >>>> was noted, the receiving interface's state machine is >>>> scheduled with the event NeighborChange. >>>> >>>> o If the neighbor is both declaring itself to be Designated >>>> Router (Hello Packet's Designated Router field = Neighbor IP >>>> address) and the Backup Designated Router field in the >>>> packet is equal to 0.0.0.0 and the receiving interface is in >>>> state Waiting, the receiving interface's state machine is >>>> scheduled with the event BackupSeen. Otherwise, if the >>>> neighbor is declaring itself to be Designated Router and it >>>> had not previously, or the neighbor is not declaring itself >>>> Designated Router where it had previously, the receiving >>>> interface's state machine is scheduled with the event >>>> NeighborChange. >>>> >>>> o If the neighbor is declaring itself to be Backup Designated >>>> Router (Hello Packet's Backup Designated Router field = >>>> Neighbor IP address) and the receiving interface is in state >>>> Waiting, the receiving interface's state machine is >>>> scheduled with the event BackupSeen. Otherwise, if the >>>> neighbor is declaring itself to be Backup Designated Router >>>> and it had not previously, or the neighbor is not declaring >>>> itself Backup Designated Router where it had previously, the >>>> receiving interface's state machine is scheduled with the >>>> event NeighborChange. >>>> >>>> Some questions: >>>> 1) Is it important that the above events are generated in this order? Is >>>> moving >>>> HelloReceived futher down allowed? >> >> I don't see any advantage to moving it. HelloReceived is a Neighbor FSM >> event and the other events are Interface FSM events. > > ahh, sorry I meant the Router Prio and its NeighborChange. > >> >>>> >>>> 2) Following this list to the letter it seems that one could generate the >>>> same >>>> event several times. There could be 3 NeighborChange and 2 BackupSeen, >>>> is this >>>> the intentions or is it enough to generate each type at most once? >> >> Notice that the events are scheduled and not executed. You only need >> schedule one of each type. > > Yes they are scheduled. Ok, so I only need one of NeighborChange and > BackupSeen but is the > order significant? Could I just always send BackupSeen(if needed) and then > NeighborChange(if needed)? You need to process BackupSeen first as you don't even recognize NeighborChange in Waiting state. BackupSeen signals an end of Waiting state prior to the wait timer expiring. > >> >>> >>> Follow up questions: >>> 3) At what point should the hello options be saved into the internal >>> neighbor state? >>> >>> 4) When should prio, DR and BDR be saved? The text mentions saving these a >>> bit earlier but >>> it is unclear if this should be undone when hello pkg should be >>> stopped( see OneWayRecived for >>> and example). >> >> This is implementation dependent but you must be able to denote differences >> from the previous state. If you want to look at a good open source reference >> implementation, go to: http://www.ospf.org/ > > How is the first received Hello seen w.r.t changed prio, DR and BDR? Either > one accepts those first > values as is and consider prio, DR and BDR equal or you consider them all > changed? It doesn't really matter. Either the first received hello packet includes you as a neighbor from which it has received a hello. In this case, you have a new bi-directional neighbor and you generate a NeighborChange event. If the first hello doesn't include you, you don't generate the NeighborChange event. In either case, you save the values. Hope this helps, Acee > > Thanks for pointer to the reference impl. > > Jocke > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
