[trill] corrections->draft-hu-trill-pseudonode-nickname-04

[gayle noble <[e-mail]>]

(in my opinion grammatical and spelling corrections)

Abstract (page 1)

(if I understand what is trying to be communicated ???)

However, in some application scenarios, for example an end station is multi-homed to multiple RBridges[,] needs [there is a need] to improve the resiliency and increase the available network bandwidth of the connection.

 

(page 4)

This paragraph is repeated twice

In TRILL protocol, RBridges are identified by nicknames (16-bits). At the edge of TRILL network, some RBridges connect to legacy networks on one side and connect to the TRILL network on the other side. These RBridges are called edge RBridges. For the connectivity between the two types of network, edge RBridges provide frame forwarding service to end stations located in legacy networks. When receiving a native frame from such a local end station S, the service edge RBridge RB1 encapsulates the frame in a TRILL header, addressing the packet to RBridge RBx to which the destination end station D is attached. The TRILL header contains an "ingress RBridge nickname" field (filled with RB1's nickname), an "egress RBridge nickname" field (filled with RBx's nickname), and a hop count. On receiving such a frame, RBx removes the TRILL header and forwards it in native form to D. Meanwhile, based on the de-capsulation of that frame, RBx learns the { ingress RBridge nickname, source MAC address, VLAN ID } triplet. Edge RBridges maintain such triplets in their forwarding tables for the future forwarding of native frames.

 

 

(page 5)

In this document, the concept of [a] Virtual RBridge group, together with its Pseudo-nickname, is introduced to address the rest of above issues.

 

(if I understand what this is trying to communicate)

So, in such a RBridge Group, even if there are more than one RBridge providing frame forwarding service for an end station or the service RBridge changes over from one to another member RBridge in same group, the ingress RBridge nickname associated to this end station needs [need] not be unchanged [changed] in remote RBridges' forwarding tables.

 

2.2. Multi-homing and Link Aggregation to TRILL Network (page 6)

 

In order to improve the reliability of connection to [a] TRILL network, multi-homing technique may be employed by a legacy device which can be a switch or end host. Take Figure 1 as an example, switch SW1 multi-homes to [the] TRILL network by connecting to RB1 and RB2 with respective links. Then the end station S1 can continue to get frame forwarding service from [the] TRILL network even if one of its up-links (e.g., SW1-RB1) fails.

 

SW1 may treat the two links as a LAG (Link Aggregation Group) bundle, so that the two links form [an] active-active load sharing model instead of [the] previous active-standby model.

 

(page 6 and 7)

That is to say, in Figure 1, two RBridges (i.e., RB1 and RB2) provides [provide] frame forwarding service to S1 simultaneously in a VLAN.

 

(page 7)(the word that is not needed)

As stated previously, that [----] simultaneous frame forwarding may result in frame duplication, loops and the flip-flopping of the ingress RBridge associated to the MAC of S1 in remote RBridges' (e.g., RBx) forwarding tables.

 

 After joining RBv, such an [a] RBridge port is called a member port of RBv, and such an [a] RBridge becomes a member RBridge of RBv. An [A]RBv is identified by its virtual nickname in TRILL campus, and this nickname is also referred to as pseudo-nickname in this document.

 

After joining an [a] RBv, a member RBridge will announce its connection to RBv by including the information of that RBv, e.g., the pseudo-nickname of RBv, in its self-originated LSP.

 

NOTE: An [A] RBridge port can join at most one RBv at any time, but different ports on the same RBridge can join the same RBv or different RBvs.

 

Furthermore, for a member RBridge, it MUST move out of an [a] RBv and clear the RBv's information from its self-originated LSPs when it loses all of its member ports of the RBv, due to port failure, configuration, etc.

 

To guarantee member RBridges of an [a] RBv group to ingress (i.e., northbound forwarding) and egress (i.e., southbound forwarding) multi-destination frames properly, and to provide protection in case of member link failure as well, this document proposes to allocate the trees among member RBridges in northbound and southbound directions respectively.

 

4.1. Trees for Native Frames Ingressing (page 9)

 

If the frame is received not from that port [not received from that port], it MUST be dropped.

 

(if I am understanding this sentence "frames regardless" is not needed)

However, member RBridges use RBv's pseudo-nickname other than their own nicknames as the ingress nickname when they forward northbound frames regardless [ --- ]unicast or non-unicast frames.

 

That change [is] beyond the scope of this document.

 

4.2. Designated Forwarder for traffic received on Distribution trees (page 9)

 

[The methodology] Methodology explained above addresses the association of distribution trees to RBx on behalf of RBv for native traffic received from the edge.

 

//(who refers to people - as in Dr. Who >*grin*<)

However, remote RBridge RBn who [which] is unaware of the RBv association[,] may choose to forward traffic along any of the available distribution trees.

 

(Step 4: page 11)[note: I am guessing as to the word wanted represented by the letter e]

However, since only one member RBridge of RBv is elected as AF for e [each] set of VLANs on a shared link and responsible to egress multi- destination TRILL data frames to this link, each member RBridge MUST assign itself as the Designated Forwarder for all the distribution trees to guarantee multi-destination frames on any tree will be egressed onto this link by an member RBridge (please refer Section 5.2.2 for more details).

 

5.2.1. Unicast TRILL Data Frames (page 12)

["in" repeated twice]

When receiving a unicast TRILL data frame, RBn checks the egress nickname in the TRILL header of the frame. If the egress nickname is one of RBn's own nicknames, the frame is processed as defined in in [--] [RFC6325].

 

(page 13)

RBn uses RBk's own nickname, instead of RBv's pseudo-nickname as the egress nickname for the re-encapsulation, and remains the ingress nickname [the ingress nickname remains] unchanged.

 

[both a period and a comma are in the text, only the comma is needed]

[NOTE: When receiving that re-encapsulated TRILL frame, as the egress nickname of the frame is RBk's own nickname rather than the RBv's pseudo-nickname, RBk will process it as Section 4.6.2.4 in [RFC6325].[ -- ], and will not re-forward it to another RBridge.]

 

Else, RBn does not know how to reach the destination; it sends the native frame out of all its member ports of RBv on which it is appointed forwarders [forwarder] for the Inner.VLAN.

 

(page 14 & 15) [I corrected "is" and "it" to plural due to the use of the word frames in this and the following sentence]

Then when [the] TRILL data frames to CE1 is [are] delivered to RB1, it [they] can be re-encapsulated (ingress nickname remains unchanged and egress nickname is replaced by RB2's nickname) by RB1 and forwarded based on the above installed MAC entry. The member RBridge who receives the redirected frames will egress them to CE1.

 

(page 16) ["an not need as links is plural]

* 01: Withdrawal (LAG-IDs in this sub-TLV do not have an [--] active      links from the announcing RBridge for RBv and Designated Forwarder election MUST be recalculated).

 

(page 16 & 17)

If it has the membership, receiving such a sub-TLV where the operation code is 00 or 01 will triggers [trigger] it to re-calculate the Designated Forwarder on each tree for the listed LAGs.

 

(page 19)

Thus, the learned MAC addresses of attached end stations on one member RBridge SHOULD be shared with the rest member [rest of the member] RBridges in the same RBv.

 

As a result, RB1 has to treat the traffic from S1 to Sx as traffic with unknown destination and flood it in TRILL, which adds additional forwarding burden on [the] TRILL network.

 

 Therefore, in addition to local attached end station MAC addresses, the learned remote MAC addresses should also be shared among all member RBridges of an [a] RBv.