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

[Donald Eastlake <[e-mail]>]

Hi Erik,

On Mon, Apr 25, 2011 at 1:41 PM, Erik Nordmark <[e-mail]> wrote:
>
> I've reviewed trill-bridge-af to see whether it is ready for last call.
> Overall it looks good.

Thanks.

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

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

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

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

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

OK, that would be a good addition.

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

OK.

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

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.

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

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.

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

OK.

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

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.

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

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   [phone] (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]

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