[rbridge] Additional comments on Base Protocol Specifications

[Donald Eastlake]

Hi Ayan,

On Mon, Apr 20, 2009 at 7:53 PM, Ayan Banerjee <ayabaner at cisco.com> wrote:
> 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.

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.

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

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

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

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.

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

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

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

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
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090421/88c93ca8/attachment-0001.html