Re: [OSPF] Neighbour processing

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

|-----Original Message-----
|From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se] 
|Sent: Thursday, November 19, 2009 3:15 AM
|To: Acee Lindem
|Cc: ospf at ietf.org
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <acee.lindem at ericsson.com> wrote on 18/11/2009 20:45:13:
|> See inline.
|>
|> |OK, this helps a lot. There is just one thing I don't get:
|> |Why can you not use the packet IP src address for Vlinks?
|> |It must have one, right?
|>
|> I'm sure some implementations do just that :^) However, the 
|intent of 
|> the protocol is that the control packets take the same path as OSPF 
|> computes across the transit area.
|>
|>
|> |When would this src address differ from the address calculated at 
|> |route time?
|>
|> When the routing across the transit area is asymetric.
|>
|>
|> |Suppose one uses packet IP src address anyway, what would the down 
|> |side be?
|>
|> If the routing asymetric, there could possibly be inconsistencies 
|> between the data plane and control plane.
|
|Is there any case where using IP src is better? I am thinking 
|about this stmt in section 15:
|        Note that when one (or
|        both) of the virtual link endpoints connect to the Transit area
|        via an unnumbered point-to-point link, it may be impossible to
|        calculate either the virtual interface's IP address and/or the
|        virtual neighbor's IP address, thereby causing the virtual link
|        to fail.
|
|Would using IP src help when one fails to calculate neighbor's 
|IP address?

I don't see a requirement for this. OSPFv2 has been deployed in the largest networks since the mid-90s and this restriction hasn't been a concern. 
Thanks,
Acee



|
| Jocke
|
|