[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Detecting router id change in p2p-over-lan connection
Acee,
What does "MUST be terminated and renegotiated." mean?
Does "terminated" mean to move into the DOWN nbr state
OR IS IT the Init state?????
Will a empty hello get us there?
Doesn't it just get us to the Init state?
Is that what is intended?
Mitchell Erblich
---------------------
Acee Lindem wrote:
>
> Hi Sunil,
>
> Sunil Patro wrote:
>
> >Hi Everyone,
> >
> >Thanks for all the feedback.
> >
> >Can I safely assume that the final behavior is what Acee's recommended
> >paragraph says below?
> >
> >
> I believe that is the consensus and barring a very compelling argument
> otherwise, this will be
> the final text.
>
> Thanks,
> Acee
>
> >"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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >
> >
> >