Subject: [rbridge] I-D Action:draft-ietf-trill-rbridge-af-02.txt

From: [email-masked]
Date: Tue, 19 Apr 2011 16:00:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : RBridges: Appointed Forwarders
	Author(s)       : R. Perlman, et al.
	Filename        : draft-ietf-trill-rbridge-af-02.txt
	Pages           : 19
	Date            : 2011-04-19

The IETF TRILL protocol provides optimal pair-wise data forwarding
without configuration, safe forwarding even during periods of
temporary loops, and support for multipathing of both unicast and
multicast traffic. TRILL accomplishes this by using IS-IS link state
routing and by encapsulating traffic using a header that includes a
hop count. Devices that implement TRILL are called RBridges.

TRILL supports multi-access LAN links that can have multiple end
stations and RBridges attached. Where multiple RBridges are attached
to a link, native traffic to and from end stations on that link is
handled by a subset of those RBridges called Appointed Forwarders,
with the intent that native traffic in each VLAN be handled by at
most one RBridge.  The purpose of this document is to improve the
documentation of the Appointed Forwarder mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-af-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 24 Apr 2011 15:54:14 -0700

Section 2.2 states:

"When the DRB sends any appointments in a TRILL Hello, it
   must send all appointments for that link in that Hello."

This policy seems inconsistent w the policy for other information sent
in hellos and with one of the motivations for introducing a different
Hello protocol than that used by the base IS-IS specification. Section
2.5 of TRILL_ADJ states:

" One other issue with TRILL LAN Hellos is to ensure that subsets of
   the information can appear in any single message, and be processable,
   in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even
   though they are not padded, can become very large..."

Yet here a strategy is adopted which REQUIRES ALL information regarding
AF to be sent in a single hello. Please explain the inconsistency.

***********************************

Section 2.2.2 discusses the frequency of sending AF information and (by
implication) how reliable announcement of the AF information is
achieved. It states that the DRB in most cases will receive an
indication from the non-DRBs as to whether they consider themeselves AF
for a given VLAN. This is based on the information in the VLAN Flags
sub-TLV (#1) of the MT-PORT_CAP TLV (143). But this requires Rbridges to
send IIHs on every VLAN for which they are the AF. In the terms used by
RFC-Trill this means that the set of Announcing VLANS MUST == the set of
Enabled VLANs. This does not scale well.

****************************************

Section 2.2.3 does an analysis suggesting that the space available in an
IIH should be more than adequate to allow advertisement of the complete
set of AF information in a single hello. This analysis assumes that the
set of enabled VLANs on the non-DRB Rbridges on a circuit is disjoint
(with the exception of the Designated VLAN). This raises some concerns.

1)In the event of the failure of a non-DRB Rbridge it would seem that
assignment of a different Rbridge to be AF for the VLANs for which the
failed Rbridge had been AF now requires manual intervention to be
effective i.e. additional VLANs have to be enabled on the Rbridge which
is assuming the AF duties of the failed Rbridge.

2)If the DRB fails, one of the non-DRB Rbridges will assume the role of
DRB. If the set of enabled VLANs on the new DRB is a subset of the union
of enabled VLANs for all Rbridges on the circuit (as is required for the
analysis in Section 2.2.3 to be correct) then its ability to function as
DRB is compromised.

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 29 Apr 2011 23:17:37 -0400

Hi Les,

> AF to be sent in a single hello. Please explain the inconsistency.

It is necessary for all the neighbors to be communicated in Hellos in
order to correctly know the network topology. Due to the TRILL Hello
bounded size, the TRILL Neighbor TLV was made fragmentable to
accomplish this.

Appointed forwarders are different. By default, the DRB is appointed
forwarder for all VLANs, which should enable correct behavior. The
optional ability to load split by assigning native frame handling for
some VLANs to other RBridges on the link was something requested by
some memebers of the TRILL WG, presumably to optimize the path of some
native traffic or in cases where the link is a complex bridged LAN.

Complex link arrangements with large numbers of appointed forwards do
not seem like a particularly good idea, especially given that they are
torn down and have to be re-established if the DRB changes.

By default the set of announcing VLANs is the set of enabled VLANs.
The upper limit on the number of Hellos scales as 2*V + N where there
are V VLANs on which end station service is offered and N RBridges on
the link. This is worse than the N Hellos you need in TRILL if there
is no end station service being offered on the link. But it is better
than the V*N Hellos that some people in the TRILL WG wanted.

It is true that in general, with randomly scattered VLANs, VLAN
enablement might have to change. (On would hope there are at least
some networks where appointed forwarders could be set based on solid
blocks of contiguous VLANs.) But I'm not sure why you assume manual
intervention. I would think that if a network manager was maintaining
complex sets of appointed forwarder VLANs on a link, they would have
some system using SNMP or some other configuration protocol to control
VLAN enablement appropriately.

> analysis in Section 2.2.3 to be correct) then its ability to function as

Sure, but it isn't a fatal compromise or anything. Say RB2 is the new
DRB because RB1 failed. And RB2 wants to appoint RB3 AF for VLAN
42. RB3's appointed forwarder status should have been reset when it
saw the DRB change. If RB2 doesn't have VLAN 42 enabled, so it can't
see Hellos on that VLAN from RB3, then it doesn't get
confirmation... Let's say there are lots of appointed forwarders and
RB2 is a real head-in-the-sand kind of RBridge that only has the
Designated VLAN enabled. Well, it should be sending out the AF
information at least once a holding time and things should straighten
out eventually. The problems might be that (1) it would take longer
for an AF to get appointed if the initial attempt fails because the
DRB wouldn't get notice of the failure and try again more quickly, and
(2) there might be some case involving misconfiguration where more
than one RBridges got appointed for the same VLAN, in which case they
should just inhibit each other until things are straightened
out. Generally speaking, the appointed forwarder system is designed to
be robust and fail in the direction of not providing service for a
brief period rather than looping.

>   Les

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge