[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

[Donald Eastlake]

Hi Mike,

Thanks for your comments, responses below...

On Wed, Nov 26, 2008 at 1:18 PM, mike shand <mshand at cisco.com> wrote:
>
>...
>
> 1. The problem of IIH space limitations (typically a maximum of < 1500
> octets) and potential number of VLAN tags (4.2.3.1.1) is not discussed.
> Even if some range based compression is used there is the possibility of
> pathological distributions of VLAN ids (e.g. just the odd ones) causing
> problems. There needs to be some guidance on what limitations this may
> impose etc.

That's a reasonable point. The Hello contents are in 4.2.3.1.2. The
only bulky items are 3 (enabled VLANs) and 6 (appointed forwarders).

Item 3 is usually present and relates, so to speak, to the
configuration of the 802.1Q part of the RBridge port and so could be
pretty arbitrary. For that reason, draft-eastlake-trill-isis proposes
that it be bit encoded so it can't take too much more than 512 bytes
(in the worst case it takes three TLVs/sub-TLVs to fit the data).

Item 6 is only in the DRB's Hello but you may want to specify VLANs
for each of several other RBridges if you are load sharing the
forwarding function. This obviously won't fit in the general case and
there should be a comment to that effect. On the other hand, I don't
see this as a big problem.  The DRB appointing some other RBridge as
forwarder for one or more VLANs or blocks of VLANs is just an
optimization. Its probably OK, in my opinion, if the DRB can't do such
appointments with complete generality due to the Hello frame size
limit.

I think some discussion of this should be added as you suggest.

> 2. The number of IIHs required to be sent when large numbers of VLANs
> are in use (4.2.3.1.1) is of some concern. Again there needs to be some
> discussion of what impact this may have in terms of limiting the
> scaleability of the protocol, and whether such limitations are acceptable.

There was considerable discussion in the TRILL WG on the number of
Hellos to be sent. Some wanted Hellos to always be sent on all VLANs,
considerably more than the default specified in this protocol
specification draft. Some wanted fewer Hellos, possibly just Hellos on
the Designated VLAN. However, fewer Hellos are not safe in general
unless you also use the optional decapsulation check. See Sections 3.2
of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(However, note that that draft has not been updated for the latest
changes in the protocol draft; I'm working on a -01).

> 3. The loop avoidance mechanisms described in 4.2.3.3 needs to be
> verified by the IS-IS WG. In addition the last bullet needs some further
> explanation as to what aspect "already provided in IS-IS" is being
> referenced.  IS-IS will normally only elect a single DIS in such
> circumstances, but there is no provision for disabling forwarding as is
> implied here.

TRILL loop avoidance is unrelated to IS-IS routing loop avoidance.
TRILL loop avoidance is just about minimizing the probability that a
frame which is decapsulated by one RBridge port onto a link will be
picked up and re-encapsulated by another RBridge port connected to
that link (where a link may be a bridged LAN). In fact, the sketch of
a proof that persistent loops do not occur in RBridge campuses, which
appears in Section 4 of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-00.txt
(which, as I mention above, is out of date and needs to be updated),
simply assumes that there are no persistent IS-IS routing loops (and
no persistent loops within any bridged LANs). So, while I welcome any
review and intelligent comment, given that TRILL loop avoidance is
unrelated to IS-IS routing loop avoidance, it is not clear to me why
the TRILL loop avoidance mechanisms need to be blessed by the IS-IS
WG.

On your second point concerning the last bullet point in Section
4.2.3.3, I think you are correct to question it. It seems superfluous
and a little confused.
       As I understand it, TRILL IS-IS Hellos injected by the same
RBridge into a link through different ports are distinguished by their
source MAC addresses. In any case, it would be plausible that, under
some circumstances, the DRB would want to appoint as a forwarder some
other of its own port's that are attached to the same link. This might
seem like an odd and useless thing to do if you imagine the link as a
hunk of classic Ethernet cable but, in fact, the ports may be
connected to different areas of an arbitrarily complex bridged LAN.
       In any case, I think this last bullet point item should simply
be deleted.

> 4. The VLAN mapping detection (4.2.3.1.3) needs to be verified by IS-IS
> WG. In particular the mechanism of setting the  mapping detected bit in
> the next 5 hellos seems dangerous, since such messages could be lost in
> the looping which would ensue when mapping was configured. This should
> either be latched until reset, or at the very least latched until it is
> detected that it has been actioned by the DRB.

The TRILL VLAN mapping detection is only there for TRILL loop
avoidance. A mapping of VLAN X to Y inside a link is only a problem if
different RBridge ports are appointed forwarder for X and Y on that
link. That's why, by default, RBridges send Hellos on a port in all
VLANs for which they are appointed forwarder for that port. If a
VLAN-X frame is decapsulated onto a link and picked up and
re-encapsulated as a VLAN-Y frame, while you're not there yet, you
have taken a big step towards having a loop. (A second link doing VLAN
Y to X mapping and one broadcast frame and you're sunk...)
       But having it latch until the DRB acknowledges it seems like a
reasonable idea.

> 5. It is not clear how the existing VLAN mapping detection will
> interoperate with the proposed VLAN mapping extensions discussed in
> Minneapolis.

TRILL VLAN mapping detection concerns mapping that is occurring
between RBridges on a path that includes an initial RBridge port below
the EISS interface, a link which may be a bridged LAN, and a final
RBridge port below the EISS interface. On the other hand, the VLAN
mapping extension in
http://tools.ietf.org/id/draft-perlman-trill-rbridge-vlan-mapping-00.txt
that was discussed in Minneapolis provides for VLAN mapping in the
core of the cut-set RBridges between two regions. As far as I can see,
these two kinds of VLAN mapping are orthogonal.

> 6. Section 4.2.1 states that a pseudonode is assigned a 7-octet ID
> USUALLY by appending another octet to the 6 octet system ID owned by the
> DRB. This suggests that the possibility of some other way is intended.
> If so this needs to be described.

Probably Radia should answer this one. However, if the assertion in
that section that "The only constraint is that the 7-octet ID be
unique within the campus, and that the 7th octet be nonzero." is not
correct, then the section needs to be re-written. However, if that
assertion is correct, I see no reason why the method used by any
particular DRB to determine the campus-unique 7-octet ID needs to be
discussed or described. There are a number of obvious ways to do this
which generally leverage off the global uniqueness of MAC addresses.

> 7. The second para of 4.2.4.1 (ESADI participation) needs some rational
> for the sending of CSNPs by the non-DRB.

Another item probably for Radia...but as I recall the idea is that
participants, other than the DRB, know they should be getting a CSNP
occasionally. If they don't get one in a long enough time, they send
one on the theory it might help and can't hurt.

> 8. Section 4.4.2.1 (TRILL IS-IS frames) states "If the frame protocol is
> not IS-IS NSAP..." What does this mean?

The wording is poor... You get to 4.4.2.1 on receipt of a frame
addressed to All-IS-IS-RBridges. You want to discard the frame if it
isn't an IS-IS frame. The "frame protocol" is the Ethertype or SNAP
SAP 5-octet protocol or the LSAPs... anyway, I think this is just
trying to say that it must be an IS-IS frame encoded in the usual LLC
way even if there is currently or in the future an IS-IS Ethertype or
the like... i.e., if there is now, or in the future, some other way of
encoding the IS-IS protocol in a frame, RBridges need not support it.

> Mike

Thanks again for the comments,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com