Subject: [rbridge] Additional comments on Base Protocol Specifications

From: Ayan Banerjee <[email-masked]>
Date: Mon, 20 Apr 2009 16:53:26 -0700

All,

I had some additional comments on the base protocol specifications.

Thanks,
Ayan

Item1: 
4.2.4.3 Hello Contents
 
   (the last two paragraphs)
   
   For example, if RB1 and RB2 are the only RBridges on the link and RB1
   is DRB, then if RB1 creates a pseudonode that is used, there are 3
   LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25
   reports connectivity to RB1 and RB2, and RB1 and RB2 each just say
   they are connected to RB1.25.  Whereas if DRB R1 set the bypass
   pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and
   RB2 each reporting connectivity to each other.

   A DRB SHOULD set the bypass pseudonode bit for its links unless, for
   a particular link, it has seen at least two simultaneous adjacencies
   on the link at some point since it last re-booted.

In the above, I am not sure how the ³SHOULD² helps an implementation; it
sounds more like a ³MUST². In the sense, in a LAN, all nodes have to behave
differently than they do in L3-IS-IS. Some implementation can decide not to
set the bypass bit, however, if the ³bypass² bit is set by the DRB, then
these nodes will have to point to the DRB as opposed to its pseduonode. In
essence, support for reception and processing on this ³bypass² option is
mandatory. Can we make either make this statement explicit or remove this
optimization. We can also state the transmission part is only ³optional²
with a SHOULD as defined.

Item2: 
Section 4.2.4.6 
   o  Before appointing a VLAN-x forwarder (including appointing
      itself), wait at least 5 Hello intervals (to ensure it is DRB).

Why is this 5 hello intervals ? How does this interact with the DIS election
etc? 

Item3: 
Section 4.6.2

   When the appointed forwarder lost counter for RBridge RBn for VLAN-x
   is observed to increase via the core TRILL IS-IS link state database
   but RBn continues to be an appointed forwarder for VLAN-x on at least
   one of its ports, every other RBridge that is an appointed forwarder
   for VLAN-x modifies the aging of all the addresses it has learned by
   decapsulating native frames in VLAN-x from ingress RBridge RBn as
   follows: The time remaining for each entry is adjusted to be no
   larger than a per RBridge configuration parameter called (to
   correspond to [802.1Q]) "Forward Delay". This parameter is in the
   range of 4 to 30 seconds with a default value of 15 seconds.

Why does this have to go around with the core TRILL IS-IS database. The core
TRILL IS-IS database is not concerned about ESADI information. Can this not
be sent using the ESADI LSPs itself?

Item 4.7.1
      TRILL traffic disable (access port) bit: ....

      Alternatively, the DRB MAY choose to creates a pseudonode for the
      access link, which indicates a slightly more relaxed policy. If it
      does create a pseudonode, it reports metrics normally but sets the
      IS-IS overflow bit in the pseudonode. This will cause IS-IS SPF
      routing to avoid sending transit data on the link if any other
      path is available but it will still be available as a path of last
      resort; however, TRILL IS-IS frames such as LSPs and CSNPs will be
      sent over the link. In addition, if a pseudonode is created by the
      DRB for an access link, all the RBridges on the access link report
      connectivity to the pseudonode as usual and the DRB reports
      connectivity in the LSP it creates for the pseudonode.

This is not normal operation for IS-IS. If the overload bit is set in the
ZEROth fragment, all LSP fragments are to be ignored from that IS. This
section needs revision. However, I have a question before we get there.

Assume that AC bit is set on ports p1 and q1 on nodes P and Q respectively.
The nodes P and Q have a ³bridged² network simulating an access network
towards their south side. When the hellos are received by the nodes P and Q,
they will form adjacencies and elect a DRB. Such a DRB¹s behavior is somehow
different from one in which AC bits are not set. If this is true  how? Can
you point me to the draft where this is explained in a bit more detail. If
missing, can we add it in please.

Also, assume now that q1 did not have the AC bit set. It was connected in
the fashion given above. In this case when P is the DRB, it asserts the AC
bit  what happens as a result? Of course, if Q is the DRB what happens? Can
you please point me to section in the draft, if missing, can these be
explained in more details.

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 21 Apr 2009 10:32:28 -0400

Hi Ayan,

On Mon, Apr 20, 2009 at 7:53 PM, Ayan Banerjee <[email-masked]> wrote:
> In the above, I am not sure how the “SHOULD” helps an implementation; it
> sounds more like a “MUST”. In the sense, in a LAN, all nodes have to
behave
> set the bypass bit, however, if the “bypass” bit is set by the DRB, then
> essence, support for reception and processing on this “bypass” option is
> optimization. We can also state the transmission part is only “optional”

Sure. The SHOULD is only intended to apply to setting the bit. The intent
was that RBridges MUST act in accordance with the state of this bit in the
DRB's Hellos.

> Why is this 5 hello intervals ? How does this interact with the DIS
election

As per http://www.postel.org/pipermail/rbridge/2009-March/003345.html, there
isn't actually any such thing as a "hello interval" and it should, instead,
reference holding time. This has no effect on the DRB election. It just says
that when an RBridge becomes the DRB, it needs to wait a bit before acting
as an appointed forwarder (or appointing another RBridge as forwarder).

> be sent using the ESADI LSPs itself?

This has nothing to do with ESADI information. Addresses learned via ESADI
stay around as long as their source RBridge maintains them in the link state
database.

This is the RBridge equivalent of the way bridges trim the timers for
addresses in their caches when they receive a topology change indication.
RBridges do a much more targeted version of this, only trimming the timers
for addresses they learned from the specific RBridge that had the change in
native frame connectivity.

> The nodes P and Q have a “bridged” network simulating an access network
> they will form adjacencies and elect a DRB. Such a DRB’s behavior is
somehow
> different from one in which AC bits are not set. If this is true – how?
Can
> missing, can we add it in please.

I agree that this section of the draft needs to be clarified.

> bit – what happens as a result? Of course, if Q is the DRB what happens?
Can
> explained in more details.

The intent is that whatever the DRB says about its port to the link being an
access port dominates. So is P thinks its port is an access port and Q
thinks its port isn't, then if P wins the DRB election Q is required to
behave as if its port was an access port and if Q wins then P is required to
behave as if its port was not an access port.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge