Re: [OSPF] Neighbour processing

[Acee Lindem <acee.lindem at ericsson.com>]

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 should be as described in the second full bullet on page 159 (Section 15) in RFC 2328. 

Hope this helps,
Acee  


|
|