Re: [trill] draft-ietf-trill-rfc7180bis-01

[gayle noble <[e-mail]>]

I read this draft and have the following thoughts/comments on 
communicating the technology >*grin*<

1)    Page 8  first paragraph
(what is written)
The link-state database at an RBridge RB1 can also contain 
information on TRILL Switches that are unreachable by IS-IS 
link-state flooding due to link or RBridge failures.

(my suggestion)
The link-state database at an RBridge, example RB1, can also contain 
information on TRILL Switches that are unreachable by IS-IS 
link-state flooding due to link or RBridge failures.

2) Page 8      2.2 Distribution Trees last sentence of this section
(what is written)
When calculating RPFCs for multi-destination packets, an RBridge RB1 
MAY, to avoid calculating unnecessary RPFC state, ignore any trees 
that cannot reach to RB1 even if other RBridges list those trees as 
trees that other TRILL Switches might use.

(my suggestion - add "such as" before RB1 and make state plural)
When calculating RPFCs for multi-destination packets, an RBridge, 
such as RB1, MAY, to avoid calculating unnecessary RPFC states, 
ignore any trees that cannot reach to RB1 even if other RBridges list 
those trees as trees that other TRILL Switches might use.

3)  Page 8  ("packets is"  I think it should be packets are)
In all cases, the normal Hop Count decrement is performed, and the 
TRILL Data packets is [are] discarded if the result is less than one 
or if the egress nickname is illegal.

4) Page 9  2.4.1 Known Unicast Origination
(what is written)
When an overloaded RBridge RB2 ingresses or creates a known 
destination unicast data packet, it delivers it locally if the 
destination is local.
(my suggestion)
When RB2, an overloaded RBridge, ingresses or creates a known 
destination unicast data packet, it delivers it locally if the 
destination is local.

5) Page 13 [I'd add a "the"]
  A TRILL Switch that is only capable of pruning based on derived MAC 
address SHOULD calculate and use such derived MAC addresses from 
[the] multicast listener IPv4/IPv6 address information it receives.

6) page 20 5.1.1 MTU PDU Addressing
(since the sentence is referring to the previous sentence which I 
missed on first reading)
(it reads)
As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST 
be   sent to the All-IS-IS-RBridges multicast address.

  (I'd change it as follows to avoid confusion)
As TRILL IS-IS PDUs, when multicast on an Ethernet link, these 
multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs MUST be
sent to the All-IS-IS-RBridges multicast address.

7) page  25 third paragraph of 8.1 E-L1FS Support (New)
(exclamation mark used instead of a 1)
  E-L!FS [EL1FS] will commonly be used to flood TRILL GENINFO TLVs 
and enclosed TRILL APPsub-TLVs [RFC7357].

8) Page 29 second sentence from end of page
(exclamation mark used instead of a 1])
Thus the use of this optional APPsub-TLV is backwards compatible with 
legacy lack of E-L!FS  [E-L1FS] support.

9) Page 31   The .fi snuck in and should be removed :)
    5. Add a line to Table 4: TRILL Hello Contents in Section 9.1 as
       follows:

          LAN  P2P  Number  Content Item
          ---  ---  ------  -----------------------------

           M    M     1      Scoped Flooding Support TLV
           .fi


10) page 33 10.2.1 Extended Hop Count
(a period is used after the word "below" instead of a comma)
Optionally,  TRILL switches can use a field composed of bits 14 
through 16 in the Flag Word, as specified below. [,] to extend this 
field to 9 bits.

11) page 34  first paragraph last sentence
("is" should be "are" as it refers to bits 14,15,16  and the Critical 
Reserved bit)
If the optional TRILL Header Flag Word is present, bits 14, 15, and 
16 and the Critical Reserved bit of the Critical Summary Bits is [are] zero.

12) page 34 (replace "but"  with "and")
For known unicast traffic (TRILL Header M bit zero), an ingress TRILL 
switch discards the frame if it determines that the least cost path 
to the egress is (1) more than 64 hops but [and] not all TRILL 
switches on that path support the extended Hop Count feature or (2) 
more than 512 hops.

13) page 34 (I think tree path should be plural also  "from the 
ingress it more" should be "from the ingress is more"  and I would 
replace "but" with "and")
For multi-destination traffic, when a TRILL switch determines that 
one or more tree path [paths] from the ingress it [is] more than 64 
hops but [and] not all TRILL switches in the campus support the 
extended Hop Count feature, the encapsulation uses a total Hop Count 
of 63 to obtain at least partial distribution of the traffic.

14)  page 34 10.2.1.3 Transit Behavior
(I think "file" should be "field")
A transit TRILL switch supporting extended Hop Count behaves like a 
base protocol [RFC6325] TRILL switch in decrementing the hop count 
except that it considers the hop count to be a 9 bit file [field] 
where the extended Hop Count field constitutes the high order three bits.

15) page 37 11.2.1 Reference Updated
(Capability spelt wrong)
All references to [RFC7180] in the TRILL Parameters Registry are 
replaced with references to this document except that the Reference 
for bit 0 in the PORT-TRILL-VER Sub-TLV Capabilty [Capability] Flags 
is changed to  [rfc6439bis].

16) Page 45 second to the last paragraph last sentence
("they" used where "there" should be used)
  But if the network manager wants to control this, they [there] 
should be a way for them to configure the priority to be DRB of the 
TRILL switch ports on the link.

17) page 45/46
(comma should be after "ports")
But TRILL works fine as currently specified on a broadcast link with 
multiple      TRILL switches on it - actually multiple TRILL switch 
ports[, ] since a TRILL switch can have multiple ports connected to 
the same link.

18) page 49
(I'd add "of a" to make sentence smoother)
    Here is an example  [of a ] TRILL LSP PDU sent over a PPP link by 
the same source TRILL switch as the example in B.1.

19) Page 53
(Since it changes from impersonal "implementer"  to personal "you" - 
"you should be the object from the start  so remove "an" add "you, 
the" and a comma after implementer. Also the word "if" is missing in 
the next sentence.)
If /an/ [you, the] implementer, don't care about that optimization 
and don't mind some time outs being longer than they otherwise would 
be, you can just not bother changing the counter, even if you are 
using data plane learning.  On the other hand, if you don't care 
about some time outs being shortened when they otherwise wouldn't, 
you could increment the counter for multiple VLANs even [if] you 
don't lose AF status on a port for all those VLANs but, for example, 
only one of them.

20) Page 56 D.2 Changes to [RFC6325]
(number four   has the word "obtained" twice - remove one please >*sparkles*<)
    4. Adoption of the change of the CFI bit, which was required to be
       zero in the inner frame, to the DEI bit which is obtained /obtained/
       from inner frame ingress or creation.

21) Page 56
(Support spelt wrong)
5. Require all RBridge to suport [support] E-L1FS FS-LSPs flooding.

22) Page 58
(Email is spelt EMail on some and Email on others. Should be 
consistent - Either change Radia Perlman's or the rest .. please)

EMail: [e-mail]
EMail: [e-mail]
Email: [e-mail]
EMail: [e-mail]
EMail: [e-mail]
EMail: [e-mail]