[rbridge] Comments on draft-ietf-trill-rbridge-af-02.txt

[Erik Nordmark <[e-mail]>]

I've reviewed trill-bridge-af to see whether it is ready for last call.
Overall it looks good.

A few comments and clarifying suggestions below.

    Erik

----

The document mentions "trunk port", but neither it nor RFCtrill defines
what that is. RFCtrill has some text about it in an appendix. Would it
make sense to put a definition for it in section 1.1?

As I was reading section 2.2.1 I wondered what would happen if a non-DRB
RBridge is disconnected for a while, during which a new DRB is elected
and sends out one or more Hellos with AF, and later switches to sending
Hellos without AF, and then the disconnected RBridge is connected again.
The answer is in the base protocol which says
"When an appointed forwarder observes that the DRB on a link has
changed, it no longer considers itself appointed for that link until
appointed by the new DRB."
But neither section 2.2.1 nor the list in section 3 repeat that
information, and it would be useful to include it in the AF document to
help understand all the mechanisms that affect AF.

---

Section 2.2.1 specifies that appointed forwarders can be encoded
efficiently by relying on VLANs being disabled on certain RBridge ports.
Thus both RB1 and RB2 can be appointed forwarder for VLAN 102 through
4095 as long as e.g., RB1 has all the even VLANs disabled and RB2 has
all the odd VLANs disabled. I didn't find any text about this in the
base specification, thus it would be good to state the sanity checks
that the DRB and RBridges perform so they can detect the case when some
VLAN is enabled on both RB1 and RB2.
If I'm correct that it is the VLAN-x inhibition timer than handles this,
then adding a sentence with a forward reference to that section would
suffice.

Thus I'd suggest adding something like
"Should the network manager have misconfigured the enabled VLANs and
appointed forwarders, resulting in two RBridges believing they are
appointed forwarders for the same VLAN, then item 4 in section 3 will
cause one or more of the RBridges to be inhibited for that VLAN".

---

In section 3 I found this hard to read text:
          All
          inhibition timers are set to expired except the DRB inhibition
          timer that, because each port will initially believe it is DRB,
          is set in accordance with item 2 below.
It would be easier to read as two sentences and s/that/which/:
          All
          inhibition timers are set to expired except the DRB inhibition
          timer which is set in accordance with item 2 below. The DRB
          inhibition timer is handled differently because each port will
          initially believe it is DRB.

---

The item 2 in section 3 doesn't actually say how the DRB inhibition
timer is set initially! It says how it is set when the RB believes it
has become DRB. If the intent is to initially set it to the Holding time
it would make sense to state that in item 1 e.g.,
          All
          inhibition timers are set to expired except the DRB inhibition
          timer which is set to the Holding Time. The DRB
          inhibition timer is handled differently because each port will
          initially believe it is DRB.

---

Section 3 item 6
s/spanning tree root bridge change/common spanning tree root bridge change/
RFCtrill talks only about the common spanning tree, thus I assume the
same thing applies here.

---

I had to read the first paragraph of section 4 at least three times. Too
many negatives and a long distance between inihibited and expired.
I'd suggest rephrasing as:
    An Appointed Forwarder for a link is inhibited for VLAN-x if
    (1) its DRB inhibition timer for that link is not expired, or
    (2) its root inhibition timer for that link is not expired, or
    (3) its VLAN inhibition timer for that link for VLAN-x is not expired.

---

Section has "if appropriate", and I assume that a multidestination frame
is at least possible case when it might be appropriate.
Thus I'd suggest s/if appropriate/if appropriate e.g., for
multidestination frame/ or something like that.

---

There is a slight asymmetry between learning for the decaps and encaps
case. By this I mean that in the decaps case the RB learns the ingress
RB, and then drops the packet. But in the encaps case it says that the
frame is ignored. Does this mean that the RB wouldn't learn the source
mac address? Does it matter?

----

    Erik

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge