Subject: Re: [rbridge] [Isis-wg] Comments ondraft-ietf-trill-rbridge-af-02.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 2 May 2011 09:41:11 -0700

Donald -

I suspect we are at an impasse - but interestingly not on technical
issues but rather on what the minimal requirements of the protocol might
be.

I commented on how AF advertisement diverges from the newly introduced
ability of providing partial updates in hellos. You replied that in the
case of AF this shouldn't be needed because the set of Rbridges used to
act as AF should always be small.

I commented on the poor scalability of having to send hellos on all the
VLANs for which one is appointed forwarder. The math you provided (2*V +
N) supports my conclusion.

I commented on the fact that in order for the advertisement logic
presented in the draft to work the set of VLANs supported by some
Rbridges would have to be altered following the addition/subtraction of
an Rbridge from the LAN. You agreed.

Where we disagree is regarding the significance of these issues.

You apparently believe a customer will not want to load balance AF
functionality across a diverse set of Rbridges. I suspect at least some
customers will want this ability.

You apparently believe that receiving (2*V + N) hellos/LAN each hello
interval is not a significant issue in the presence of a large # of
supported VLANs - I disagree.

You apparently believe that customers will find the restrictions on VLAN
configuration in order to make AF advertisement work as described in
this draft acceptable. These restrictions include:

a)Disjoint sets of enabled VLANs on the set of Rbridges to be used as AF
b)Reconfiguration of the set of enabled VLANs on Rbridges in the event
the set of Rbridges on a LAN changes (addition or removal, planned or
unplanned)
c)Reconfiguration of the set of enabled VLANs on an Rbridge which
becomes DRB following failure of the old DRB

These restrictions amount to static configuration of AF - which is
especially ironic given the emphasis on minimal configuration for TRILL
RBs.
I would be very surprised to find that customers would be happy with
this. 

In the big picture, I think there is a need for a scalable way to
advertise AF assignments and have this be adaptable in the face of RB
failure, maintenance, introduction, etc. and to have delivery of this
information be reliable. I don't think the current draft meets these
requirements.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Donald Eastlake
> Sent: Friday, April 29, 2011 8:18 PM
> To: Les Ginsberg (ginsberg); [email-masked]
> Cc: isis mailing list
> Subject: Re: [rbridge] [Isis-wg] Comments ondraft-ietf-trill-rbridge-
> af-02.txt
> 
> Hi Les,
> 
> On Sun, Apr 24, 2011 at 6:54 PM, Les Ginsberg (ginsberg)
> <[email-masked]> wrote:
> 
> > 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.
> 
> 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.
> 
> > ***********************************
> >
> > 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.
> 
> 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.
> 
> > ****************************************
> >
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 8 May 2011 21:56:50 -0400

Hi Les,

> act as AF should always be small.

I guess we differ on the definition of "small" in this context.

> N) supports my conclusion.

That's default behavior, not mandatory if you configure different
behavior.

> an Rbridge from the LAN. You agreed.

The particular technique given in the draft to accommodate many
perversely scattered VLANs generally requires changing VLAN
enablement. That's not the same as saying you would always have to
change VLAN enablement.

> Where we disagree is regarding the significance of these issues.

Right.

> customers will want this ability.

I don't think a customer will want to load balance native traffic
to/from a link by VLAN across hundreds of RBridges. I think that 65+
or so diverse RBridges (actually up to twice that if VLANs are not
perversely scattered) will be diverse enough.

> supported VLANs - I disagree.

It may or may not be an issue depending on the capabilities of the
links and RBridges involved. (Note that TRILL Neighbor TLVs, probably
a TLV in a TRILL Hello that is relatively expensive to process, is
only processed in the N Hellos on the Designated VLAN and is probably
not present in Hellos on other VLANs.) However, I don't know what you
can do if there isn't a better default that preserves robustness and
other characteristics.

For example, you can cut the (2*V + N) Hellos to N Hellos by
configuring the announcing VLANs set at the RBridge ports on the link
to be the null set. This would be safe on a link in the absence of
devices such a bridges, for example on a LAN link that is actually
point-to-point, as is very common in modern networks. (Although in
that case it might be easier to just configure it as a point-to-point
link.) So, if the network manager is sure their configuration is like
that, they can reduce the number of Hellos to N.

Given the wonderous and complex ways in which bridges and bridge ports
can be configured, it is hard for me to see how you can be reasonably
loop safe without having something like the inhibition mechanism and
having each RBridge periodically send a message on each VLAN for which
it is an Appointed Forwarder. It is convenient for this message to be
a Hello for DRB election and other reasons.

> a)Disjoint sets of enabled VLANs on the set of Rbridges to be used

This is only needed if many VLANs are perversely configured on a link
and even then does not apply to the DRB. If there are a small number
of VLANs or if there are many but the are rationally allocated to
Appointed Forewarders in contiguous blocks, there is no need to use
this technique.

> the set of Rbridges on a LAN changes (addition or removal, planned or

This is never needed unless the set of RBridges on the link acting as
Appointed Forwarders changes. RBridge can come and go. As long as
those RBridges are only used for TRILL Data through traffic (plus
control traffic such as TRILL IS-IS frames) and don't become DRB and
change the Designated VLAN, no changes would be needed in the enabled
VLANs on any of the RBridges on the link.

Nor, with RBridges that are or are to be Appointed Forwarders, is this
needed if you have a small number of VLANs you are dealing with or a
large number that are rationally organized so that appointments can be
made for contiguous blocks.

On in the case where there are many VLANs where you want to do
perversely scattered appointments do you need to use the technique
outlined in the draft... Probably the simpler alternatives and the
cases where they are applicable should get more mention in the draft.

> becomes DRB following failure of the old DRB

As above, this would be required only under limited circumstances. And
since this RBridge knows it has become DRB, it doesn't seem very hard
for it to change its own VLAN enablement on the port that became DRB.
And should the DRB fail to enable some VLAN that it wants some other
RBridge to be Appointed Forwarder for, things still work, the DRB just
doesn't get feedback on the AF status of other RBridges on the link.
This might slow down convergence to the desired AF state.

> I would be very surprised to find that customers would be happy with

The idea in TRILL is that things should work with minimal
configuration. The do as far as appointed forwarders go. The DRB is
it, with no particular configuration required. If you want to try to
load share native traffic from a link by VLAN, that seems like a great
place to apply various forms of creative cleverness and knowledge of
the traffic characteristics of the end stations and network which is
unreasonable to expect to be in TRILL standards documents. In many
case something is going to have to configure the load sharing. And if
many VLANs are perversely scattered, VLAN enablement will probably
need to be configured. I see no reason why such enablement cannot be
automated.

Thanks,
Donald