[rbridge] trill-adj circuit scope
Les Ginsberg (ginsberg)
ginsberg at cisco.com
Mon Mar 7 07:08:22 PST 2011
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Friday, March 04, 2011 6:12 AM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Cc: isis mailing list
> Subject: trill-adj circuit scope
> > Reliable Circuit Scope Flooding
> > --------------------------------
> > [RFCTrill] defines a requirement for reliable circuit scoped
> > flooding of Appointed Forwarder Information (Section 4.4.2) but it
> > is not specified how this is to be achieved. I had hoped this
> > document would provide that specification.
> It sound like you are alluding to a link scoped flooding mechanism
> which I believed you also referred to in an earlier ISIS WG
> post. Presumably something involving some new PDUs like LLSP (link
> local state PDU) and LCSNP (local complete sequence number PDU),
> perhaps both in L1 and L2 versions and possibly with the primary index
> being the SNPA rather than the System ID. It is quite an intriging
> idea. Is there a draft yet? I don't recall seeing one.
The first issue is getting consensus that this is indeed an issue which needs to be addressed - which thus far has not been achieved. I believe it does need to be addressed. Whether what you suggest below is a workable solution can only be evaluated if you provide normative language so we understand the solution. At present, RFCTrill says that the DRB sends AF information - but the manner in which reliability is achieved is unspecified.
If you update whatever spec you feel is most appropriate for this I will review it.
I understand you feel this is out of scope for the review of draft-ietf-trill-adj. But as AF information is sent in IIHs and the reliability is a new circuit-scoped requirement it seemed appropriate for me to mention here.
> In any case, I don't see any need for it in connection with appointed
> forwarders. In particular I'd like to point out the following:
> - Whether an RBridge believes it is the appointed forwarder for a VLAN
> is indicated in TRILL Hellos that it sends on that VLAN. Thus the
> DRB normally has feedback on what other RBridges on the link think
> their Appointed Forwarder status is.
> - An RBridge that believes it is appointed forwader for a particular
> VLAN, when it receives a TRILL Hello on that VLAN from another
> RBridge in which that other RBridge asserts that it is appointed
> forwarder for that VLAN, is temporarily inhibited for that VLAN
> only. This can result in transient loss of end station data but that
> is preferable to a loop. (Such inhibition has no effect on TRILL
> Data frames, only on native frame receipt and transmission.)
> - When an RBridge sees the DRB change and it does not become DRB, it
> clears any fowarder appointments that RBridge thinks it has.
> - The spec states that appointing an RBridge appointed forwarde hss no
> effect except for VLAN(s) that are enabled on a port that RBridge
> has on the link. Since the network manager will normally have
> control over VLAN enablement, this means that you can appoint an
> RBridge forwarder for, say, all even numbered VLAN by only having
> those VLANs enabled and then sending out a forwader appointment
> appointing it for all VLAMs.
> > The lack of reliable flooding means that either:
> > a)Appointed forwarder information MUST be included by the DRB always
> > - which does not scale well
> Since the DRB can normally sense, from their Hellos, what other
> RBridges on the link think their appointed forwarder status is, it
> knows when it needs to refresh the existing appointed forwarder
> information or send a new set of appointed forwarder information. But,
> no doubt, it would be a good practice to send it occasionally
> > OR
> > b)Loops and/or loss of traffic for a given VLAN MAY occur
> The inhibition from receiving a Hello indicating an appointed
> forwarder conflict and other safety features should stop loops. It is
> certainly possible, with perverse configurations, to have loss of
> native traffic.
> In any case, the appointed forwarder mechanism is out of scope for
> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
More information about the rbridge