Re: [OSPF] Neighbour processing

[Joakim Tjernlund <joakim.tjernlund at transmode.se>]

Acee Lindem <acee.lindem at ericsson.com> wrote on 17/11/2009 23:52:42:
>
> Hi Joakim,
> See inline.
>
> |-----Original Message-----
> |From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> |Sent: Tuesday, November 17, 2009 10:50 AM
> |To: Acee Lindem
> |Cc: ospf at ietf.org
> |Subject: RE: [OSPF] Neighbour processing
> |
> |Acee Lindem <acee.lindem at ericsson.com> wrote on 17/11/2009 16:40:10:
> |>
> |> |-----Original Message-----
> |> |From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> |> |Sent: Tuesday, November 17, 2009 10:24 AM
> |> |To: Acee Lindem
> |> |Cc: ospf at ietf.org
> |> |Subject: RE: [OSPF] Neighbour processing
> |> |
> |> |Acee Lindem <acee.lindem at ericsson.com> wrote on 17/11/2009 14:36:10:
> |> |>
> |> |> Hi Joakim,
> |> |> If the inteface state is Waiting, then the BackupSeen event is
> |> |> scheduled. For more advanced interface states, the NeighborChange
> |> |> event is scheduled. You would never schedule both of them.
> |> |> Hope this Helps,
> |> |
> |> |Yes it does, thanks.
> |> |Clarification though: "never schedule both of them" is that
> |per bullet?
> |> |If the first bullet schedules either a BackupSeen or NeighborChange
> |> |should the next bullet be skipped?
> |>
> |> Yes. Only one bullet is applicable and the conditions
> |predicating each
> |> bullet should be mutually exclusive.
> |
> |Thanks, this makes sense.
> |
> |>
> |> |
> |> |New question same chaper(10.5) there is:
> |> |        When receiving an Hello Packet from a neighbor on a
> |broadcast,
> |> |        Point-to-MultiPoint or NBMA network, set the neighbor
> |> |        structure's Neighbor ID equal to the Router ID found in the
> |> |        packet's OSPF header.  For these network types, the neighbor
> |> |        structure's Router Priority field, Neighbor's
> |Designated Router
> |> |        field, and Neighbor's Backup Designated Router
> |field are also
> |> |        set equal to the corresponding fields found in the received
> |> |        Hello Packet; changes in these fields should be noted for
> |> |        possible use in the steps below.  When receiving an
> |Hello on a
> |> |        point-to-point network (but not on a virtual link) set the
> |> |        neighbor structure's Neighbor IP address to the packet's IP
> |> |        source address.
> |> |
> |> |I don't understand how virtual link fits. Should a Vlink be
> |> |considered to be in the same group as "broadcast,
> |Point-to-MultiPoint
> |> |or NBMA network" or is it its own group?
> |> |If so what should be for vlinks?
> |>
> |> A virtual link will have the same interface states as a
> |point-to-point
> |> interface except the Loopback state isn't applicable. Also, the
> |> InterfaceUp event only occurs when the virtual link endpoint
> |is reachable across the transit area.
> |
> |This seems to indicate that I should treat a Vlink the same as
> |a p2p link above, however the paragraph explicitly say I
> |should not so now I am confused :) Exactly what should be done
> |to a Vlink in the above context?
>
> This statement only refers to the setting of the Neighbor IP address in the
> RFC's reference Neighbor data structure. For virtual links, this address

Yes and that was what I wondered about. The stmt does not cover Vlinks I think
so what should one do with Neighbour data when the link in question is a Vlink?

Why should one only set the Neighbor IP address for a PtoP link?
What should Neighbor IP address be for the other link types?

> should be as described in the second full bullet on page 159 (Section 15) in RFC 2328.