Hi Alvaro, On Wed, Jan 18, 2017 at 3:32 PM, Alvaro Retana <[email protected]> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-trill-rfc6439bis-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.4 (Overload and Appointed Forwarders) talks about potential > Appointed Forwarders which are overloaded. In IS-IS, a node with the > overload bit set "shall not" (ISO 10589) be considered for transit. > However, the use of "SHOULD NOT appoint an RBridge in overload" and > "SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential > hole in the proper forwarding of TRILL data packers. Why aren't MUST > NOT/MUST used? Is there something in the specific use of IS-IS by TRILL > that I am missing?
The Appointed Forwarder function has to do with accepting frames from end stations for ingress and egressing frames to end stations. It does not have anything to do with TRILL Data packet transit routing. Consider the following case: two TRILL switches (RBridges) RB1 and RB2 are connected by a link L1 that also has end stations on it. The end stations are all in VLAN X. There are other end stations in VLAN X in the TRILL campus not on L1 but all of these other end stations are directly connected to RB2. RB2 is in overload. Under these circumstances, RB2 should be the Appointed Forwarder for VLAN X as that way traffic between all of the VLAN X end stations can be forwarded by RB2 without any IS-IS routing at all. RB2 will just be, in effect, forwarding native frames between RB2 ports (although, for consistency, the TRILL specifications say that RB2 ingresses this VLAN X traffic by encapsulating it into a TRILL Data frame, and then notices it is destined for an end station on a local port, immediately decapsulates it, and sends it out that port). > I think this should be an easy DISCUSS to clear; either point to the > piece I'm missing, or don't use an overloaded node. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
