[rbridge] trill-adj circuit scope

[Les Ginsberg (ginsberg)]

Donald -

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

   Les


> 
> 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
> regardless.
> 
> > 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
> draft-ietf-trill-adj.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com