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

From: gayle noble <[email-masked]>
Date: Thu, 13 Dec 2012 08:44:09 -0800

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