Subject: Re: [rbridge] Proposed compromise for short/long hellos

From: mike shand <[email-masked]>
Date: Wed, 01 Apr 2009 08:09:15 +0100

Radia Perlman wrote:
> I *do* mean that R2 defers to R1 for DRB even if R1 doesn't list R2 in 
> its Hello.
> This is the same behavior that has to work in TRILL if, for instance, 
> R2 cannot communicate on
> the Designated VLAN.
>
> If R2 can hear R1, and R1 has a better priority for being DRB, then R2 
> does not
> attempt to become DRB even if R1 is refusing to acknowledge R2's 
> existence, and
> therefore they don't form an adjacency.
>
> I'd be somewhat surprised if (layer 3) IS-IS behaves differently. If 
> R2 hears
> R1's Hellos, and R1 is most qualified as DRB, but for whatever reason 
> does not
> list R2 in R1's Hellos, I assume that R2 does not attempt to become a 
> separate DRB.
> But even if that's how IS-IS has evolved since DECnet (that was the 
> behavior I always
> assumed in that case), for TRILL it has to behave the way that I said. 
> It is dangerous
> to have two DRBs on a link, so if R2 knows that R1 is "more qualified" 
> to be DRB, then
> R2 has to defer to R1, even if it does not have "an adjacency" to R1.

 From ISO/IEC 10589 V2 clause 8.4.5

The set of Intermediate systems to be considered includes the local 
Intermediate system, together with all Intermediate systems of the 
appropriate type as follows.
d) For the LAN Level 1 Designated Intermediate System, it is the set of 
Intermediate systems from which LAN Level 1 IIH PDUs are received and to 
which Level 1 adjacencies exist in adjacencyState “Up”.

and from 8.4.2.5.1

The IS shall set the adjacencyState of the adjacency to “initialising”, 
until it is known that the communication between this system and the 
source of the PDU (R) is two-way. However R shall be included in future 
Level n LAN IIH PDUs transmitted by this system.
When R reports the local system’s SNPA address in its Level n LAN IIH 
PDUs, the IS shall
d) set the adjacency’s adjacencyState to “Up”, and

Mike

>
>
> Radia
>
>
>
> mike shand wrote:
>> Radia,
>> I really don't see how this works. When R1 no longer lists R2 as a 
>> neighbor, then the adjacency goes down. But if the adjacency goes 
>> down the DRB election doesn't happen and we are back to the loop. So 
>> you must somehow mean that the adjacency stays UP as far as DRB 
>> election is concerned and DOWN as far as advertising in the LSPs is 
>> concerned.
>>
>> So are you proposing changing the DRB election procedure so that it 
>> doesn't require an adjacency?
>> i.e you elect it from among the hellos that you see on the LAN even 
>> if they don't report mutual connectivity?
>>
>> I really don't understand how these dual adjacency types are supposed 
>> to work.
>>
>> Mike
>>
>>
>> Radia Perlman wrote:
>>> I may have the terminology wrong -- but when I say "R1 drops the 
>>> adjacency to R2" what I
>>> mean is:
>>>
>>> a) In R1's Hellos, R1 no longer lists R2 as a neighbor
>>> b) In R1's LSP, R1 no longer lists a link to R2
>>> c) If it's a pseudonode that connects R1 and R2, then as a 
>>> consequence of R2 not appearing in
>>> R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP.
>>> d) Because the LSPs do not indicate a link between R1 and R2, no 
>>> paths will be computed
>>> by any RBridges that go through R1-R2.
>>>
>>> Radia
>>>
>>>
>>>
>>> Don Fedyk wrote:
>>>> Hi Radia
>>>>
>>>> I'm having trouble understanding if this really fixes the problem or
>>>> just handles one case of IS-IS adjacency failure due to small MTU. 
>>>> What happens after point e) when the adjacency drops? What is the
>>>> forwarding behavior of the RBridges that realizes they cannot form an
>>>> adjacency?
>>>> I think what I'm hearing is the forwarding behavior/treatment of an
>>>> interface when there is an RBridge that knows they cannot form an
>>>> adjacency is different than when RBridges do not know any adjacency
>>>> exists and that seems problematic to me.
>>>> Regards, Don
>>>>
>>>>
>>>>> So to summarize what I think we should do:
>>>>> a) say Hellos MUST NOT be padded
>>>>> b) add a flag for "I support the MTU discovery protocol" to the Hello
>>>>> c) add a TLV in the LSP for "I think the campus-wide minimum MTU 
>>>>> size for a link is x"
>>>>> d) specify a simple MTU discovery protocol which would be a 
>>>>> message that
>>>>> is never forwarded by an RBridge, and which is padded to the size 
>>>>> you want
>>>>> to test, and includes the size in the data, and an RBridge R2 that 
>>>>> receives
>>>>> such a message from neighbor R1 (whether the message was unicast 
>>>>> by R1
>>>>> to R2, or multicast by R1 on the link) acknowledges with the size 
>>>>> in the message:
>>>>> "I received your MTU discovery message with size q"
>>>>> e) if R1 doesn't receive an ack from R2 after sufficiently many 
>>>>> MTU discovery
>>>>> messages, R1 drops the adjacency to R2.
>>>>>
>>>>> Radia
>>>>>
>>>>>
>>>>>
>>>>> Anoop Ghanwani wrote:
>>>>>> Just responding to the thread in general and not
>>>>>> any specific post...
>>>>>>
>>>>>> I think it makes sense to use the non-padded
>>>>>> Hellos just because it is critical that they
>>>>>> be seen. If they are not seen, what could
>>>>>> result is a loop which is very bad.
>>>>>>
>>>>>> As a result of not padding the Hellos, we would
>>>>>> lose the MTU discovery/validation benefit of
>>>>>> L3 IS-IS. For that, we can probably define
>>>>>> a new message.
>>>>>>
>>>>>> If we continue to pad messages, we could get loops as observed by 
>>>>>> Jim. We could define
>>>>>> a new message/protocol specifically to detect
>>>>>> such scenarios, but I personally think it is safer to prevent 
>>>>>> such a scenario by having it
>>>>>> built into the core of the protocol.
>>>>>>
>>>>>> Anoop
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rbridge mailing list
>>>>>> [email-masked]
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>> _______________________________________________
>>>>> rbridge mailing list
>>>>> [email-masked]
>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>
>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: mike shand <[email-masked]>
Date: Wed, 01 Apr 2009 09:36:15 +0100

Radia,

Does this proviso help to avoid the problem? Or is it something else 
which would need to be changed to ensure that a lone Rbridge DOES get 
elected DRB?

ISO/IEC 10589 v2 clause 8.4.5 (penultimate para)

"An Intermediate system shall not declare itself to be a LAN Designated 
Intermediate system of any type until it has at least one “Up” End 
system (not including manual adjacencies) or Intermediate system 
adjacency on the circuit. (This prevents an Intermediate System which 
has a defective receiver and is incapable of receiving any PDUs from 
erroneously electing itself LAN Designated Intermediate System.)"

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 1 Apr 2009 08:32:49 -0400

Hi Mike, Radia

RBridge has a quirk due to its "low configuration nature".  It must be a
DRB when it is the only RBridge (otherwise it partitions the network.)
And it must cease doing this whenever there is a high priority RBridge
attached to the same LAN. RBridges are dependent on IS-IS for detecting
other RBridges.   So if IS-IS every get "confused" about adjacencies
RBridges may get confused about what mode they are operating in. 

Several have pointed out that is the way IGPs(IS-IS and OSPF) work in
L3. But I don't think so.  In L3 the knowledge of a Router that you
can't form an adjacency with, does not affect your forwarding to those
Routers/LANs you do know about.  For non adjacent L3 routers that are
tunneled over some encapsulation if the adjacency fails to form then the
tunnel is simply not used.  You don't change the behavior of your direct
L3 links nor do you change the behavior of your L2 links. If you can't
form an adjacency over a LAN you just don't use that link. (This is in
line with Mike's point below.)

The key difference here is RBridge cares about he total number of
RBridges connected to the LAN (potential adjacencies) and at the same
time the total number of RBridges that are truly adjacent on the LAN.
There is no locally determined fall back position. 

a)If the connected number is 1 you have one behavior. (No adjacencies or
IS-IS not even getting Hellos through.) 
b)If the connected number is 2 or more you have another behavior and
must do election (Delivered IS-IS Hellos regardless of whether IS-IS
forms a proper adjacency or not.)
c)If you form one or more adjacencies you may be the appointed forwarder
even if you are not the DRB. (2 or more functioning IS-IS adjacencies). 

I'm not sure we have covered all the corner cases for this behavior.
And the operating behavior is determined by each RBridge locally.  

Regards,
Don 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of mike shand
> Sent: Wednesday, April 01, 2009 4:36 AM
> To: Radia Perlman
> Cc: TRILL/RBridge Working Group
> Subject: Re: [rbridge] Proposed compromise for short/long hellos
> 
> Radia Perlman wrote:
> > It is dangerous
> Intermediate system of any type until it has at least one "Up" End