Thanks & Regards
Nitin
-----Original Message-----
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of Sunil
Patro
Sent: Thursday, February 23, 2006 3:24 AM
To: OSPF at PEACH.EASE.LSOFT.COM
Subject: Re: Detecting router id change in p2p-over-lan connection
Hi Everyone,
Thanks for all the feedback.
Can I safely assume that the final behavior is what Acee's recommended
paragraph says below?
"If the system ID or the router ID in an incoming hello packet
doesn't match the the system ID or router ID for an established
adjacency
over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore,
if OSPF hello suppression as described in [DEMAND] is active for the
adjacency, it MUST be terminated and renegotiated."
Thanks,
Sunil
-----Original Message-----
From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM] On Behalf Of
Naiming
Shen
Sent: Tuesday, February 21, 2006 9:43 PM
To: OSPF at PEACH.EASE.LSOFT.COM
Subject: Re: Detecting router id change in p2p-over-lan connection
Hello Acee,
Your suggested paragraph looks fine with me.
Even though this sentence assumes there is really a
router-id change from a DC neighbor. A router probably
should send a 'neighbor probing' [RFC 3883], if no
response, then reset the adjacency and start
the renegotiation; otherwise it should still ignore
the new join on the p2p-over-lan link.
But I would consider router-id change over a demand
circuit over a p2p-over-lan on OSPF link a
'misconfiguration';-) so it does not matter too much.
Your version is fine.
thanks.
- Naiming
Acee Lindem said the following on 02/21/2006 02:47 PM:
Hello Naiming,
Naiming Shen wrote:
Acee Lindem said the following on 02/21/2006 06:04 AM:
Naiming Shen wrote:
Agree with Dave's argument, and this is the same idea as in the
current draft of p2p-over-lan (section 4.5):
... If the system ID or the
router ID of incoming hello packet does not match the system
ID or
the router ID of already established adjacency over this
p2p-over-lan
circuit, it MUST discard the packet. The implementation should
offer
logging and debugging information of the above events.
Do we need to change anything here?
Hi Naiming,
Given that this situation can happen in the case of
misconfiguration
or
router-ID change, I wouldn't optimize for the former. Especially
considering Kalyan's point that if hello's are suppressed, the
router-id change
will either not be recognized or require additional logic. I'd
vote
to either
leave it unspecified (consistent with RFC 2328's omission of
router-id
change P2P link handling) or discard the old neighbor and bring up
an adjacency with the new (which is what at least one
implementation
does
today).
Hello Acee,
The original idea in the draft was to prevent multiple routers
joinning
onto the same LAN rather than handing the router-ID change from the
same router. Even through there is a side effect to it.
For the router-ID change issue. If one is willing to change
router-ID
or system-ID during normal operation, there are more things broken
and there is nothing wrong to wait until the current adjacent
timeout.
Agreed.
If the hello is suppressed over the link, then the behaviour is not
bounded by this paragraph since it does not say the purpose is to
detect neighbor router-id change.
I disagree here. It says "MUST discard packet". That sounds pretty
bounding to me :^).
Also there is little reason to
suppress a hello over p2p-over-lan links. Thus I don't think
router-id is an issue with this sentence.
I agree - but there is nothing in this draft or RFC 1793 that
precludes
it.
Since p2p-over-lan is different from normal p2p circuit that
multiple
routers can easily join the same LAN unintentionally. If we ignore
the new station to join, then we can prevent the adjacency constant
flapping(this does not happen to normal p2p link), the worst it can
happen is slow to handle router-id change as mentioned above, which
is a non issue. Thus I think it's a good thing to ignore the extra
adjacency joinning. This sentence does not govern the normal p2p
link
behaviour so the implementation is ok(even prefered) to reset the
existing adjacency on a normal p2p link. Thus I don't think we
should say we must reset the current adjacency for p2p-over-lan.
My preference of this sentence in the draft is with this order:
- leave it as is
- change the MUST to SHOULD
- remove the router-id related sentence
How about leave it "almost" as is:
If the system ID or the router ID in an incoming hello packet
doesn't
match the the system ID or router ID for an established
adjacency
over
a p2p-over-lan circuit, the packet MUST be discarded.
Futhermore,
if OSPF hello suppression as described in [DEMAND] is active for
the
adjacency, it MUST be terminated and renegotiated.
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits",
RFC 1793, April 1995.
Thanks,
Acee
thanks.
- Naiming
Thanks,
Acee
Thanks,
Acee
thanks.
- Naiming
Dave Katz said the following on 02/20/2006 08:53 PM:
RFC2328 is silent on what to do if you see a different router ID
on
a P2P link; if you take it literally, you will create two
adjacencies (temporarily), advertise both in your router LSA,
and
your network will most likely black hole traffic until one of
them
times out.
On real P2P links, this will suffice (if you don't mind a
network
outage for the dead time of the old adjacency) and things will
eventually stabilize since it is "impossible" (cough) two get
two
neighbors in 2Way. The fact that it is underspecified doesn't
matter that much.
In the P2P-over-LAN case, there needs to be a mechanism to try
to
do something useful if there turn out to be more than two
routers
on the link. I don't think it's reasonable to say "gee it's
misconfigured, we don't care what happens to the network."
It seems to me that there are two possible cases, namely, use
the
old adjacency until it times out (effectively ignoring the
hellos
from the new guy) or to form an adjacency with the new guy (and
blow away or otherwise ignore the old guy.)
The first case has the advantage of stability and
simplicity--the
third router that shows up for the party will be ignored by both
parties. There is a potential for a circle of one-way
adjacencies
to stabilize, but this will still be stable (there won't be a
usable adjacency across the subnetwork.)
The second case has the advantage that it adapts more quickly
when
something changes. Some implementations already do this for the
pure P2P case. However, it is destabilizing in the
misconfiguration case, as the router will flap its router LSA
each
time another Hello is received. Probably the only reasonable
way
out would be to detect the flap and then choose one neighbor
and
stick to it, ignoring the other (which degenerates into the
first
case.)
Given all of this, I'd propose that the right thing to do is the
first case, and suffer through the dead time (or use BFD and
suffer through the detection time.)
(A third possible case would be to actually bring up the
adjacency
and end up running full-mesh multipoint, which would probably
even
work, but would be butt ugly.)
--Dave
On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote:
Kalyan Bade wrote:
Acee,
This might not work if the interface is defined as demand
circuit.
Good point - We're in the process of discussing whether this
behavior
should be in the
draft. Possibly, handling detection of a router-id change on
a
P2P
over
LAN link
differently than a normal P2P link may be a bad idea.
How about bringing down the neighbor (rather than ignoring)
when
a third
neighbor on a P2P over LAN sends a new hello? This creates
unnecessary
flaps, but again having more than 2 routers on a p2p LAN is a
misconfig.
Atleast, the processing will be similar to a regular p2p
interface.
That would be fine and consistent with what most routers do on
normal P2P links. I think the
P2P over LAN specific router-ID change processing should be
removed from the draft.
Thanks,
Acee
Thanks,
Kalyan.