Subject: [trill] draft-eastlake-trill-multi-topology - WG adoption call (extension 7/30 to 8/16)

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Aug 2015 09:30:49 -0400

This extends the 2 week WG adoption call for
draft-eastlake-trill-multi-topology (7/16 to 8/16).  You can find the draft
at 

http://datatracker.ietf.org/doc/draft-eastlake-trill-multi-topology

Please indicate if 

a)      If you find the technology for the multi-topology to adequately
handles multiple topologies, and
b)      If you know of deployments this technology could be useful. 

This WG adoption call began at: 

https://mailarchive.ietf.org/arch/msg/trill/uYMlktr6m4nmHHINChKjqPit8BY

Sue Hares

---

From: Haoweiguo <[email-masked]>
Date: Wed, 5 Aug 2015 09:52:26 +0000

Support the adoption.  This draft provides a comprehensive solution for TRILL MT.

Thanks,

weiguo

________________________________
From: Susan Hares [[email-masked]]
Sent: Tuesday, August 04, 2015 21:30
To: [email-masked]
Cc: 'Donald Eastlake'; 'Alia Atlas'; 'Jon Hudson'
Subject: [trill] draft-eastlake-trill-multi-topology - WG adoption call (extension 7/30 to 8/16)

This extends the 2 week WG adoption call for draft-eastlake-trill-multi-topology (7/16 to 8/16).  You can find the draft at
http://datatracker.ietf.org/doc/draft-eastlake-trill-multi-topology
Please indicate if

a)      If you find the technology for the multi-topology to adequately handles multiple topologies, and

Sue Hares

---

From: Liyizhou <[email-masked]>
Date: Thu, 6 Aug 2015 01:09:10 +0000

I support the adoption of the set of multi-topology drafts.  It is useful in IPv4/IPv6 hybrid deployment.
This draft is in good shape. It provides the basic support of MT capability advertisement in trill campus which is useful in unique/single/aggregate nickname approaches.

Thanks,
Yizhou

From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 04, 2015 9:31 PM
To: [email-masked]
Cc: 'Donald Eastlake'; 'Alia Atlas'; 'Jon Hudson'
Subject: [trill] draft-eastlake-trill-multi-topology - WG adoption call (extension 7/30 to 8/16)

Sue Hares

---

From: gayle noble <[email-masked]>
Date: Sat, 08 Aug 2015 21:11:53 -0700

I support adoption of this draft.
I also have the following corrections.
corrections
1.   page 3 last paragraph
["of an multi-topology campus" should be "of a multi-topology campus"]
(as written)
Multi-topology TRILL supports regions of topology ignorant TRILL 
switches as part of an multi-topology campus; however, such regions 
can only ingress, egress, or transit TRILL Data frames in the special 
base topology zero.
(should be)
Multi-topology TRILL supports regions of topology ignorant TRILL 
switches as part of a multi-topology campus; however, such regions 
can only ingress, egress, or transit TRILL Data frames in the special 
base topology zero.

2.   page 5 section 2.2 paragraph two - first sentence
["by removing a reference (see Section 2.4)" the section two reads 
real strange and is not a proper sentence. I think it should be re-worded
(as written)
  A link is only usable for TRILL Data packets in non-zero topology T 
if (1) all TRILL switch ports on the link advertise topology T 
support in their Hellos and (2) if any TRILL switch port on the link 
requires explicit TRILL Data packet topology labeling (see Section 
2.4) every other TRILL switch port on the link is capable of 
generating explicit packet topology labeling.
(I'd write)
  A link is only usable for TRILL Data packets in non-zero topology T 
if (1) all TRILL switch ports on the link advertise topology T 
support in their Hellos and (2)if any TRILL switch port on the link 
requires explicit TRILL Data packet topology labeling then every 
other port on the link can generate such labeling. (See Section 2.4.1 
on explicit topology labeling.)

3.   page 6 section 2.4 section paragraph - first sentence
"sometimes used" should be "sometimes be used"]
(as written)
Examples of fields that may sometimes used to determine topology are 
values or ranges of values of the payload VLAN or Fine Grained Label 
[RFC7172], packet priority, IP version (IPv6 versus IPv4) or IP 
protocol, Ethertype, unicast versus multi-destination payload, IP 
Differentiated Services Code Point (DSCP) bits, or the like.
(should be )
Examples of fields that may sometimes be used to determine topology 
are values or ranges of values of the payload VLAN or Fine Grained 
Label [RFC7172], packet priority, IP version (IPv6 versus IPv4) or IP 
protocol, Ethertype, unicast versus multi-destination payload, IP 
Differentiated Services Code Point (DSCP) bits, or the like.

4.   page 6 value 1's meaning second sentence
["lable" should be "label"]
(as written)
Such a port is capable of determining TRILL Data packet topology 
without an explicit lable for all of the topologies it supports and 
thus does not require such a label in received TRILL Data packets.
(should be)
Such a port is capable of determining TRILL Data packet topology 
without an explicit label for all of the topologies it supports and 
thus does not require such a label in received TRILL Data packets.

5.   page 7 part of table Value 2/3 (Noticed by Donald Eastlake)
[The first line of the entry for "2/3" is outdented rather than 
indented. It's a bit hard to notice this problem since it is split 
over a page boundary. So the first line of the "2/3" entry need to be 
indented some.]
(as written)
           determination for that packet, the TRILL switch MUST discard
           the packet.
2/3 Requires an explicit topology label in received TRILL Data packets
           except for topology zero. Any TRILL Data packets received
           without such a label is classified as being in topology zero.
           Also capable of inserting an explicit topology label in TRILL
           Data packets sent. (Values 2 and 3 are treated the same,
           which is the same as saying that if the 2 bit is on, the 1
           bit is ignored.)
(should be)
             determination for that packet, the TRILL switch MUST discard
             the packet.
2/3       Requires an explicit topology label in received TRILL Data
              packets except for topology zero. Any TRILL Data packets
              received without such a label is classified as being in topology
              zero. Also capable of inserting an explicit topology label in
              TRILL Data packets sent. (Values 2 and 3 are treated the
              same, which is the same as saying that if the 2 bit is on, the 1
              bit is ignored.)

6.   page 9 section 3.1 first paragraph - first sentence
["announement" should be "announcement" ]
(as written)
There is no change in the determination or announement of adjacency 
for topology zero as specified in [RFC7177].
(should be)
There is no change in the determination or announcement of adjacency 
for topology zero as specified in [RFC7177].

And  ... acronyms used but not defined
BFD             Bidirectional Forwarding Detection
ESADI End Station Address Distribution Information
IS-IS           Intermediate System to Intermediate System
MAC            Media Access Control
Sub-TLV       Link-type sub-Type-Length-Values
TLV             Type Length Value

Thank you Donald for explaining the technical stuff to me I miss by 
not being at the meetings. >*sparkles*<
gayle

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 11 Aug 2015 03:04:37 +0000

The "Explicit Topology Label" appears as an ether tag in the TRILL Data packets. This technology does not consume the limited bits of nicknames. It's a scalable way. I am in favor of it.
I believe the specifications in this document are comprehensive and can adequately handle the multi-topologies in TRILL. Hence, support as a coauthor.

We've already seen deployments of TRILL in the small to medium enterprise data center networks. Now, I also see its potential of deployments in the small scale home networks.

Thanks,
Mingui

Sue Hares