1. March 200768th IETF - Prague1 TRILL Working Group Changes from draft-trill-rbridge-protocol-02.txt to draft-trill-rbridge-protocol-03.txt Dinesh Dutt, Cisco Silvano Gai, Nuova Radia Perlman, Sun

2. March 200768th IETF - Prague2 Added the RBridge Model +----------------------------------------------------------+ | Higher Layer Entities | +--+--------------+----------------------+--------------+--+ | \ Trill Layer | RBridge Relay Entity | Trill Layer / | +----+------------+----------------------+------------+----+ | Data Link Layer | | Data Link Layer | +-----------------+ +-----------------+ | Physical Layer | | Physical Layer | +-------+---------+ +-------+---------+ | | P1 P2 An Rbridge Relay Entity that interconnects two Rbridge ports; At least one port (two in the example); Higher Layer Entities, including at least the IS-IS protocol. The TRILL Layer. An RBridge encapsulates incoming IEEE 802.3 frames (in this document also referred to as Ethernet frames) with a TRILL header to forward them to other Rbridges.

3. March 200768th IETF - Prague3 Added examples of Encapsulations +--------------------------------+ | Outer Ethernet Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ +--------------------------------+ | PPP Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+

4. March 200768th IETF - Prague4 Defined the term Multi-Destination It identifies: 1. frames for unknown unicast destinations: the Inner.MacDa is unicast, but the ingress RBridge does not know its location; 2. frames for layer 2 multicast addresses derived from IP multicast addresses: the Inner.MacDa is multicast; 3. frames for layer 2 multicast addresses not derived from IP multicast addresses: the Inner.MacDa is multicast; 4. frames for the layer 2 broadcast addresses: the Inner.MacDa is broadcast; 5. ARP queries: the Inner.MacDa is broadcast; 6. ND queries: the Inner.MacDa is multicast;

5. March 200768th IETF - Prague5 TRILL Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Address | Egress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V (Version): 2-bit. See Section 3.1.1. Hop Limit: 6-bit unsigned integer. See Section 3.1.3. M (Multi-destination): 1-bit. See Section 3.1.2. Reserved: 7-bit. Ingress RBridge Address: 16-bit address. See Section 3.1.4.2. Egress RBridge Address: 16-bit address. See Section 3.1.4.1.

6. March 200768th IETF - Prague6 Added Ethernet Encapsulation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Outer VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Address | Ingress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | InnerSource MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Inner VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. March 200768th IETF - Prague7 Added IVLAN and OVLAN The Outer VLAN Tag: MAY or MAY NOT be present. If present, it is used to enable two RBridges to become adjacent through an Ethernet cloud that support VLANs. The Inner VLAN Tag: contains the VLAN information associated with the original frame. Clarified that in the rest of the document the term VLAN means inner VLAN.

8. March 200768th IETF - Prague8 MAY, SHOULD, MUST (1) Changed some text to utilize RFC2119 terms: –an RBridge MAY suppress the inner VLAN tag for frames with VID = 1. –some RBridges MAY be configured to not be the root of distribution tree – If Ri is a tree root, then any RBridge Rn that needs to send multi-destination traffic MAY select the Ri-tree –An Ingress RBridge MUST flood an ARP/ND query if the target is unknown, but MAY do so for a known target if it wants to assure freshness of the information… –RBridges MUST calculate at least one distribution tree, and by default compute one distribution tree for every Rbridge.

9. March 200768th IETF - Prague9 MAY, SHOULD, MUST (2) –RBridges: SHOULD store a successfully acquired nickname in non- volatile memory and attempt to reuse it on reboot SHOULD implement an "optimized ARP/ND response" MUST learn the location of endnodes. MUST calculate a distribution tree for every RBridge with RequestTree TRUE or for the RBridge with lowest ID if none have RequestTree TRUE MUST comply with the decision of Rn to be the root of a distribution tree –Pseudonodes (shared links) MUST set RequestTree = FALSE

10. March 200768th IETF - Prague10 Miscellaneous Added some pseudo-code for forwarding behavior Removed duplications in the text Fixed other minor issues

11. March 200768th IETF - Prague11 Added Algorhyme V2 1.1. Algorhyme V2 I hope that we shall one day see A graph more lovely than a tree. A graph to boost efficiency While still configuration-free. A network where RBridges can Route packets to their target LAN. The paths they find, to our elation, Are least cost paths to destination! With packet hop counts we now see, The network need not be loop-free! RBridges work transparently. Without a common spanning tree. Ray Perlner