Subject: [trill] I-D Action: draft-ietf-trill-cmt-05.txt

From: [email-masked]
Date: Sat, 14 Feb 2015 11:20:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

        Title           : Coordinated Multicast Trees (CMT) for TRILL
        Authors         : Tissa Senevirathne
                          Janardhanan Pathangi
                          Jon Hudson
	Filename        : draft-ietf-trill-cmt-05.txt
	Pages           : 17
	Date            : 2015-02-14

Abstract:
   TRILL facilitates loop free connectivity to non-TRILL legacy
   networks via choice of an Appointed Forwarder for a set of VLANs.
   Appointed Forwarders provide load sharing based on VLAN with an
   active-standby model. Mission critical operations such as High
   Performance Data Centers require an active-active load sharing
   model. The Active-Active load-sharing model can be accomplished by
   representing any given non-TRILL legacy network with a single
   virtual RBridge. Virtual representation of the non-TRILL legacy
   network with a single RBridge poses serious challenges in multi-
   destination RPF (Reverse Path Forwarding) check calculations. This
   document specifies required enhancements to build Coordinated
   Multicast Trees (CMT) within the TRILL campus to solve related RPF
   issues. CMT provides flexibility to RBridges in selecting desired
   path of association to a given TRILL multi-destination distribution
   tree. This document updates RFC 6325.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-cmt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-trill-cmt-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-cmt-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 14 Feb 2015 17:24:45 -0500

This is an editorial revision based on the comments here:
http://www.ietf.org/mail-archive/web/trill/current/msg06618.html

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: gayle noble <[email-masked]>
Date: Mon, 23 Feb 2015 19:21:15 -0800

I read this draft and have the following thoughts/comments about the 
ability of the written words to communicate the technology >*grin*<

1)     Page 3  Terminology
(I'd remove the word "is")
The acronyms and terminology in [RFC6325] /is/ are used herein. Some 
of   these are listed below for convenience with the following along 
with some additions:

2)    page 3
   At first I thought the acronym was repeated in the definition of 
the acronym instead of referring to a reference document. So, for 
clarity to other California Air Heads, I would replace the "[IA]" 
with  [IA-draft]
(so)
IA - Interface Addresses, a TRILL APPsub-TLV[IA]
(would be)
IA - Interface Addresses, a TRILL APPsub-TLV [IA-draft]

3)    page 3  IP/MAC Address Mappings
(remove second "and" )
Traditionally an RBridge learns the MAC and /and/ Data Label (VLAN or 
FGL) to nickname correspondence of a remote host, as per [RFC6325] 
and [RFC7172], from TRILL data frames received.

4)    page 4 - first paragraph
(I'd replace the IA with IA-draft)
(so)
Addresses (IA) APPsub-TLV [IA] enhances the TRILL base protocol by 
allowing IP and MAC address mappings to be distributed in the control 
plane by any RBridge.
(would become)
Addresses (IA) APPsub-TLV [IA-draft] enhances the TRILL base protocol 
by allowing IP and MAC address mappings to be distributed in the 
control plane by any RBridge.

5)    page 4
(reword)
The information may be possibly from different sources.
(to)
The information may possibly be from different sources.

6)    page 4
(as written)
RBridges can then use the Flags Field in IA APPsub-TLV to identify if 
the source is a directory server or local observation by the sender. 
Different confidence level may also be used to indicate the 
reliability of the mapping information.
(I'd re-word it to)
RBridges can then use the Flags Field in IA APPsub-TLV to identify if 
the source is a directory server or a local observation by the 
sender. A different confidence level may also be used to indicate the 
reliability of the mapping information.

7)    page 5
(I'd replace [IA] with [IA-Draft])
(so)
The ingress RBridge may use the IA APPsub-TLV [IA] with the Local 
flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC 
information obtained in this step.
(becomes)
The ingress RBridge may use the IA APPsub-TLV [IA-draft] with the 
Local flag set in ESADI [RFC7357] to distribute any new or updated 
IP/MAC information obtained in this step.

8)    page 6
(I'd replace [IA] with [IA-draft])
(so)
The RBridge may use an IA APPsub-TLV[IA]with the Local flag set to 
distribute the sender's MAC and IP mapping information.
(becomes)
The RBridge may use an IA APPsub-TLV[IA-draft]with the Local flag set 
to distribute the sender's MAC and IP mapping information.

9) last sentence page 6 top of page 7
("initiate" should  be "initiates" as R2 is the noun of the sentence 
at that point)
If the ingress RBridge R1 decides to unicast the ARP/ND request to 
the target's egress RBridge R2 as discussed in subsection 3.2 item a) 
or to flood the request as per [RFC6325], then R2 decapsulates the 
query, and initiate [initiates] an ARP/ND query on the target's link.

10) Page 7
(I'd replace [IA] with [IA-draft])
(so)
The update message can be carried by an IA APPsub-TLV [IA] with the 
Local flag set in ESADI [RFC7357] or as per [DirMech] if push 
directory server is in use.
(becomes)
The update message can be carried by an IA APPsub-TLV [IA-draft] with 
the Local flag set in ESADI [RFC7357] or as per [DirMech] if push 
directory server is in use.

11) page 7
(I think RARP is repeated twice)
(as written)
Handling RARP (Reverse Address Resolution Protocol) Messages 
RARP[RFC903] uses the same packet format as ARP but a 
different  Ethertype (0x8035) and opcode values.
(I think it should be)
Handling RARP (Reverse Address Resolution Protocol) Messages[RFC903] 
uses the same packet format as ARP but a different  Ethertype 
(0x8035) and opcode values.

12) page 7 just before IANA considerations
(the word "to" was left out)
The ingress RBridge should also rate limit the ARP/ND queries for the 
same target to be injected to the TRILL campus [to] prevent the 
possible attack.

13) page 9
(the word "Email" is not formatted the same for all emails. I think 
one format should be chosen and used in all documents. I prefer 
"Email" to EMail" but either is fine as long as they all are the same. )

EMail: [email-masked]
Email: [email-masked]
EMail: [email-masked]
Email: [email-masked]
EMail: [email-masked]

14) just  a note
Acronyms used might be nice to list them all in the document

APPsub-TLV     Application sub-Type-Length-Values
ARP                Address Resolution Protocol
DAD               Duplicate Address Detection
DirMech          Edge Directory Assist Mechanisms
ESADI            End Station Address Distribution Information
FGL                Fine-Grained Label
IA                  Interface Addresses
IP                  Internet Protocol
MAC               media access control address
ND                 Neighbor Discovery
RARP              Reverse Address Resolution Protocol
RBridge           Routing Bridge
SEND              secure neighbor discovery
TLV                 Type Length Value
TRILL              Transparent Interconnection of Lots of Links
TRILL              Tunneled Routing in the Link Layer
TRILL switch     an RBridge

---

From: gayle noble <[email-masked]>
Date: Mon, 23 Feb 2015 19:47:17 -0800

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: [email-masked]
EMail: [email-masked]
Email: [email-masked]
EMail: [email-masked]
EMail: [email-masked]
EMail: [email-masked]

---

From: Liyizhou <[email-masked]>
Date: Tue, 24 Feb 2015 04:11:40 +0000

Gayle, thanks for your review. Will update all the editorial changes.

Yizhou

-----邮件原件-----
发件人: trill [mailto:[email-masked]] 代表 gayle noble
发送时间: 2015年2月24日 11:21
收件人: [email-masked]
主题: Re: [trill] draft-yizhou-trill-arp-optimization-01

I read this draft and have the following thoughts/comments about the ability of the written words to communicate the technology >*grin*<

1)     Page 3  Terminology

2)    page 3
   At first I thought the acronym was repeated in the definition of the acronym instead of referring to a reference document. So, for clarity to other California Air Heads, I would replace the "[IA]" 
with  [IA-draft]
(so)
IA - Interface Addresses, a TRILL APPsub-TLV[IA] (would be) IA - Interface Addresses, a TRILL APPsub-TLV [IA-draft]

3)    page 3  IP/MAC Address Mappings
(remove second "and" )
Traditionally an RBridge learns the MAC and /and/ Data Label (VLAN or
FGL) to nickname correspondence of a remote host, as per [RFC6325] and [RFC7172], from TRILL data frames received.

4)    page 4 - first paragraph
(I'd replace the IA with IA-draft)
(so)
Addresses (IA) APPsub-TLV [IA] enhances the TRILL base protocol by allowing IP and MAC address mappings to be distributed in the control plane by any RBridge.
(would become)
Addresses (IA) APPsub-TLV [IA-draft] enhances the TRILL base protocol by allowing IP and MAC address mappings to be distributed in the control plane by any RBridge.

5)    page 4
(reword)

6)    page 4
(as written)
RBridges can then use the Flags Field in IA APPsub-TLV to identify if the source is a directory server or local observation by the sender. 
Different confidence level may also be used to indicate the reliability of the mapping information.
(I'd re-word it to)
RBridges can then use the Flags Field in IA APPsub-TLV to identify if the source is a directory server or a local observation by the sender. A different confidence level may also be used to indicate the reliability of the mapping information.

7)    page 5
(I'd replace [IA] with [IA-Draft])
(so)
The ingress RBridge may use the IA APPsub-TLV [IA] with the Local flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC information obtained in this step.
(becomes)
The ingress RBridge may use the IA APPsub-TLV [IA-draft] with the Local flag set in ESADI [RFC7357] to distribute any new or updated IP/MAC information obtained in this step.

8)    page 6
(I'd replace [IA] with [IA-draft])
(so)
The RBridge may use an IA APPsub-TLV[IA]with the Local flag set to distribute the sender's MAC and IP mapping information.
(becomes)
The RBridge may use an IA APPsub-TLV[IA-draft]with the Local flag set to distribute the sender's MAC and IP mapping information.

9) last sentence page 6 top of page 7
("initiate" should  be "initiates" as R2 is the noun of the sentence at that point) If the ingress RBridge R1 decides to unicast the ARP/ND request to the target's egress RBridge R2 as discussed in subsection 3.2 item a) or to flood the request as per [RFC6325], then R2 decapsulates the query, and initiate [initiates] an ARP/ND query on the target's link.

10) Page 7
(I'd replace [IA] with [IA-draft])
(so)
The update message can be carried by an IA APPsub-TLV [IA] with the Local flag set in ESADI [RFC7357] or as per [DirMech] if push directory server is in use.
(becomes)
The update message can be carried by an IA APPsub-TLV [IA-draft] with the Local flag set in ESADI [RFC7357] or as per [DirMech] if push directory server is in use.

11) page 7
(I think RARP is repeated twice)
(as written)
Handling RARP (Reverse Address Resolution Protocol) Messages RARP[RFC903] uses the same packet format as ARP but a different  Ethertype (0x8035) and opcode values.
(I think it should be)
Handling RARP (Reverse Address Resolution Protocol) Messages[RFC903] uses the same packet format as ARP but a different  Ethertype
(0x8035) and opcode values.

12) page 7 just before IANA considerations (the word "to" was left out) The ingress RBridge should also rate limit the ARP/ND queries for the same target to be injected to the TRILL campus [to] prevent the possible attack.

13) page 9
(the word "Email" is not formatted the same for all emails. I think one format should be chosen and used in all documents. I prefer "Email" to EMail" but either is fine as long as they all are the same. )

14) just  a note

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: gayle noble <[email-masked]>
Date: Mon, 23 Feb 2015 21:39:32 -0800

Yizhou,
Thank you! >*bow*<
gayle

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 24 Feb 2015 09:51:37 -0500

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 <[email-masked]> wrote:
> I read this draft and have the following thoughts/comments on communicating
> the technology >*grin*<
>
> 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)
> information on TRILL Switches that are unreachable by IS-IS link-state
> flooding due to link or RBridge failures.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>  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.
>
> (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.
>
>  E-L!FS [EL1FS] will commonly be used to flood TRILL GENINFO TLVs and
> enclosed TRILL APPsub-TLVs [RFC7357].
>
> Thus the use of this optional APPsub-TLV is backwards compatible with legacy
> lack of E-L!FS  [E-L1FS] support.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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].
>
>  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
> 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
>    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.
>
> (number four   has the word "obtained" twice - remove one please
>>*sparkles*<)
> (Email is spelt EMail on some and Email on others. Should be consistent -
> Either change Radia Perlman's or the rest .. please)
>
> EMail: [email-masked]

Thanks,
Donald