Subject: Re: Detecting router id change in p2p-over-lan connection

From: Kalyan Bade <[email-masked]>
Date: Mon, 20 Feb 2006 14:39:08 -0800

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.

Thanks,
Kalyan.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 20 Feb 2006 18:25:50 -0500

>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

---

From: Dave Katz <[email-masked]>
Date: Mon, 20 Feb 2006 20:53:01 -0800

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:

> 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.
>>
>>
>

---

From: Naiming Shen <[email-masked]>
Date: Mon, 20 Feb 2006 21:39:37 -0800

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?

thanks.
- Naiming

Dave Katz said the following on 02/20/2006 08:53 PM:
> (temporarily), advertise both in your router LSA, and your network  will 
> most likely black hole traffic until one of them times out.
> 
> link.  I don't think it's reasonable to say "gee it's misconfigured,  we 
> don't care what happens to the network."
> 
> 
> 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.)
> 
> 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
> 
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Feb 2006 09:04:56 -0500

> 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).

Thanks,
Acee

Thanks,
Acee

>> 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.
>>
>> neighbors in 2Way.  The fact that it is underspecified doesn't 
>> matter  that much.
>>
>> 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.)
>>
>> 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.)
>>
>> 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.)
>>

---

From: Dave Katz <[email-masked]>
Date: Tue, 21 Feb 2006 08:13:19 -0800

On Feb 21, 2006, at 6:04 AM, Acee Lindem wrote:

> 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

My libertarian streak says to leave anything unspecified that does  
not impact interoperability (a philosophy absent from the OSPF spec,  
which has normative text for all kinds of unnecessary things.)   
Indeed, the handling of this case is not an interoperability issue.

Given the failure modes caused by misconfiguration, however, I would  
campaign for having a SHOULD on detecting the misconfiguration, which  
will otherwise look like mysterious adjacency flapping, or the  
inability for adjacencies to come up, or something.  It should be  
pretty trivial to detect the fact that you're actively receiving  
Hellos from multiple systems on what is supposedly a point-to-point  
medium.

--Dave

>>> 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."
>>>
>>>
>>> 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.)
>>>
>>> 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
>>>
>>>
>>>> P2P over LAN specific router-ID change processing should be  
>>>> removed  from the draft.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>> Thanks,
>>>>> Kalyan.
>>>>>
>>>>>
>>>>
>>
>

---

From: Naiming Shen <[email-masked]>
Date: Tue, 21 Feb 2006 12:09:47 -0800

> an adjacency with the new (which is what at least one implementation does

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.
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. 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.

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

thanks.
- Naiming

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Feb 2006 17:46:19 -0500

Hi Dave,

> Hellos from multiple systems on what is supposedly a point-to-point  

I agree that the likelihood of misconfiguration is much  greater and 
should be detected,

Thanks,
Acee

>>>> your network  will most likely black hole traffic until one  of 
>>>> them times out.
>>>>
>>>> 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 
>>>> 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  
>>>> when  something changes.  Some implementations already do this  for 
>>>> the pure  P2P case.  However, it is destabilizing in the

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Feb 2006 17:47:34 -0500

Hello Naiming,

> and there is nothing wrong to wait until the current adjacent timeout.

Agreed.

> 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

I agree - but there is nothing in this draft or RFC 1793 that precludes it.

>  - 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

>>>> 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.)
>>>>

---

From: Naiming Shen <[email-masked]>
Date: Tue, 21 Feb 2006 21:43:21 -0800

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Feb 2006 13:17:58 -0500

Hi Naiming,

If we wanted to limit it, we could say that demand circuit configuration 
is not
allowed on p2p-over-lan interfaces as an alternative. However,
if we leave the question unanswered you can best believe it will come 
back during
one of the last calls. Between the 2 alternatives, I like the 
alternative that
allows hello suppression to be tested on p2p-over-lan (even if it isn't
practical).

Thanks,
Acee

>>>>>> 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.
>>>>>>
>>>>>> 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.)
>>>>>>