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

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Apr 2011 10:41:42 -0700

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
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 29 Apr 2011 14:56:07 -0400

Hi Erik,

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

Thanks.

> make sense to put a definition for it in section 1.1?

I think it would make sense to add something in Section 1.1 like:

A "trunk port" is a port configured with the "end station service
disable" bit on, as described in Section 4.9.1 of [RFCtrill].

> help understand all the mechanisms that affect AF.

Ah, that should be added to the list in Section 3.

> cause one or more of the RBridges to be inhibited for that VLAN".

OK, that would be a good addition.

>         initially believe it is DRB.

OK.

>         initially believe it is DRB.

I don't actually see what's all that confusing in the current wording
but I'm fine with changiing to the wording you suggest and it may be
clearer.

> RFCtrill talks only about the common spanning tree, thus I assume the

Yes. If you are attached to a bridged LAN running the multiple
spanning tree protocol, TRILL only pays attention to the base common
spanning tree.

>    (3) its VLAN inhibition timer for that link for VLAN-x is not expired.

OK.

> multidestination frame/ or something like that.

I guess I'm OK with your suggested change. There is also the somewhat
obscure case where a frame being routed as a known unicast arrives at
the egress but the destination MAC addess is not known there, in which
case the native frame is flooded out all ports the are in the frames
VLAN and provide end station service.

> mac address? Does it matter?

I don't think it matters very much. But on balance it is probably
better to learn from received native frames, even if you are
inhibited. So I think the text in Section 4 where it says:

   If a VLAN-x Appointed Forwarder for a link is inhibited and receives
   a native frame in VLAN-x that would normally be ingressed from that
   link, the native frame is ignored.

should have "except for address learning" added to the end.

>   Erik

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Apr 2011 15:07:23 -0700

> disable" bit on, as described in Section 4.9.1 of [RFCtrill].

OK

> but I'm fine with changiing to the wording you suggest and it may be

The current item 2 says
       2. When an RBridge believes that it has become DRB on a link, ...
which looks confusing. Based on item 1 I'd expect it to say something 
about the initial setting, but it looks like it only talks about the 
case when it becomes a DRB. It might be that it always becomes a DRB 
initially, but that is a bit too subtle.

I hope that explains my request for working it more explicitly.

    Erik