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

[Donald Eastlake <[e-mail]>]

Hi Gayle,

Thanks for these comments. I pretty much agree with them all. Unless
there are some objections, I think these and the changes in the
message at http://www.ietf.org/mail-archive/web/trill/current/msg06666.html
can be incorporated into the draft.

On Mon, Feb 23, 2015 at 10:47 PM, gayle noble <[e-mail]> wrote:
> 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]

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]