Subject: [trill] WG Adoption call for draft-yizhou-trill-arp-optimization (2/15 to 3/1)

From: "Susan Hares" <[email-masked]>
Date: Sun, 15 Feb 2015 14:14:00 -0500

This is a 2 Week WG Adoption call for draft-yizhou-trill-arp-optimization
(2/15 to 3/1).  You can access the draft at: 

http://datatracker.ietf.org/doc/draft-yizhou-trill-arp-optimization/

In your response, please provide technical comments on the draft and discuss
how this fits into TRILL's overall directory service architecture as
deployed in networks.  Amongst your technical comments - please indicate
"support" or "no support" of WG adoption of this draft. 

Sue Hares

---

From: Haoweiguo <[email-masked]>
Date: Mon, 16 Feb 2015 09:02:10 +0000

Support.

This draft provides comprehensive solutions to reduce ARP/ND broadcast traffic in TRILL campus, it is very useful and helpful.

Thanks,

weiguo

________________________________

From: Susan Hares [[email-masked]]
Sent: Monday, February 16, 2015 3:14
To: [email-masked]
Cc: 'Donald Eastlake'; [email-masked]
Subject: [trill] WG Adoption call for draft-yizhou-trill-arp-optimization (2/15 to 3/1)

This is a 2 Week WG Adoption call for draft-yizhou-trill-arp-optimization (2/15 to 3/1).  You can access the draft at:

In your response, please provide technical comments on the draft and discuss how this fits into TRILL’s overall directory service architecture as deployed in networks.  Amongst your technical comments – please indicate “support” or “no support” of WG adoption of this draft.

Sue Hares

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 25 Feb 2015 09:26:52 +0000

I support the WG adoption of this draft. The optimization can help to reduce the broadcast/multicast traffic in a TRILL campus.

As for the question that "how this fits TRILL's overall directory service architecture as deployed in networks?", according to my understanding, it requires TRILL switches to additionally get the IP information. TRILL switches have several ways to get that information and TRILL directory service is one but not only one of those potential ways. 

Thanks,
Mingui

>-----Original Message-----
>From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
>Sent: Monday, February 16, 2015 3:14 AM
>To: [email-masked]
>how this fits into TRILL's overall directory service architecture as deployed in
>networks.  Amongst your technical comments - please indicate "support" or
>"no support" of WG adoption of this draft.
>
>
>
>Sue Hares

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 25 Feb 2015 15:51:31 +0000

Support, 

Linda

>Subject: [trill] WG Adoption call for 
>draft-yizhou-trill-arp-optimization (2/15 to
>3/1)
>
>
>
>This is a 2 Week WG Adoption call for 
>draft-yizhou-trill-arp-optimization (2/15 to 3/1).  You can access the draft at:
>
>
>
>In your response, please provide technical comments on the draft and 
>discuss how this fits into TRILL's overall directory service 
>architecture as deployed in networks.  Amongst your technical comments 
>- please indicate "support" or "no support" of WG adoption of this draft.
>
>
>
>Sue Hares

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

---

From: Jon Hudson <[email-masked]>
Date: Wed, 25 Feb 2015 09:56:12 -0800

Enthusiastically support!!!

ARP is a nightmare for many folks, this brings needed help. 

Jon

> On Feb 25, 2015, at 7:51 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Support, 
> 
> Linda
> 
>

---

From: [email-masked]
Date: Wed, 25 Feb 2015 10:24:26 -0800

I support the WG adoption of this draft.
Thank you!!
gayle

> discuss how this fits into TRILL's overall directory service
architecture as
> deployed in networks.  Amongst your technical comments - please indicate
"support" >or "no support" of WG adoption of this draft.

---

From: gayle noble <[email-masked]>
Date: Wed, 25 Feb 2015 20:44:49 -0800

My thoughts/wording corrections ->[trill] draft-ietf-trill-ia-appsubtlv-02.txt

1)     Abstract
(this sentence is very long and complicated.)
This document specifies a TRILL (Transparent Interconnection of Lots 
of Links) IS-IS application sub-TLV that enables the reporting by a 
TRILL switch of sets of addresses such that all of the addresses in 
each set designate the same interface (port) and the reporting for 
such a set of the TRILL switch by which it is reachable.
(maybe re-adjust it something like this)
This document specifies a TRILL (Transparent Interconnection of Lots 
of Links) IS-IS application sub-TLV that enables the reporting by a 
TRILL switch of sets of information; each set consists of addresses 
and a nickname of the TRILL switch by which those addresses can be 
reached; all of the addresses in a set designate the same end station 
interface (port).

2)      page 10
(I would change "the" to "then")
(as written)
If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], 
the only one byte Types and Lengths could be used.
(it would become)
If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], 
then only one byte Types and Lengths could be used.

3)    page 12
(Should be "topology given" instead of "topology give")
(as written)
   The presence of this sub-sub-TLV indicates that the interfaces 
given in the IA APPsub-TLV are reachable in the topology give.
(I'd change it to)
   The presence of this sub-sub-TLV indicates that the interfaces 
given in the IA APPsub-TLV are reachable in the topology given.

4)    page 12
(This is not real clear as to what it is trying to communicate .. at 
least to me)
(what is written)
It is useful if the IA APPsub-TLV occurs outside of the context of a 
message indicating the topology or if it is desired and permitted to 
override that specification.
(if I figured this out)
You might want to use the Data Label or Topology sub-sub-TLVs where 
the IA APPsub-TLV is not in a message or some other context that 
specifies the Data Label or Topology. (Multi-topologyTRILL really 
isn't fully specified yet but the Topology sub-sub-TLV is provided 
for future use.) Alternatively, even if the IA APPsub-TLV is inside a 
message or some other context, you might want to specify that for 
some particular IA APPsub-TLV, a different Data Label or different 
Topology should be used, so you might want to use the sub-sub-TLV to 
override that specification.

5)    page 14
(I'd change "providing" to "provided")
(what is written)
Security on the wire, or in storage, for this data is to be providing 
by the transport or storage used.
(What I'd put)
Security on the wire, or in storage, for this data is to be provided 
by the transport or storage used.

6)    page 19 last paragraph
(the word "give" is used where I'd use "given")
(as written)
The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be 
treated as if it occurred as a 4th entry inside each of the three Address Sets.
(I'd write)
The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be 
treated as if it occurred as a 4th entry inside each of the three Address Sets.

7)    page 20 last paragraph
(I think "them" should be "then")
(as written)
The OUI would them be supplied by a second Fixed Address sub-sub-TLV 
proving the OUI.
(I think it should be)
The OUI would then be supplied by a second Fixed Address sub-sub-TLV 
proving the OUI.

acronyms
AFN              Address Family Number
APPsub-TLV    Application sub-TLV
ARP              Address Resolution Protocol
Data Label     VLAN or FGL
ESADI           End Station Address Distribution Information
FGL              Fine Grained Label
FS-LSP                   Flooding Scoped Label Switched Paths
IA                Interface Addresses
IETF             Internet Engineering Task Force
IS-IS            Intermediate System to Intermediate System
LAN              Local-Area Network
MAC             Media Access Control
ND               Neighbor Discovery
OUI              Organizationally Unique Identifier
PDU              Protocol Data Unit
RARP            Reverse Address Resolution Protocol
RBridge         An alternative name for a TRILL switch
TLV              Type Length Value
TRILL             Transparent Interconnection of Lots of Links
TRILL switch   A device that implements the TRILL protocol
VLAN            Virtual Local-Area Network

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 26 Feb 2015 13:50:36 -0500

Hi Gayle,

Thanks. Those changes looks like good clarifications and corrections
to the draft. I'll go over them more closely and incorporate them.

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

On Wed, Feb 25, 2015 at 11:44 PM, gayle noble <[email-masked]> wrote:
> This document specifies a TRILL (Transparent Interconnection of Lots of
> Links) IS-IS application sub-TLV that enables the reporting by a TRILL
> switch of sets of addresses such that all of the addresses in each set
> designate the same interface (port) and the reporting for such a set of the
> TRILL switch by which it is reachable.
> This document specifies a TRILL (Transparent Interconnection of Lots of
> Links) IS-IS application sub-TLV that enables the reporting by a TRILL
> switch of sets of information; each set consists of addresses and a nickname
> of the TRILL switch by which those addresses can be reached; all of the
> addresses in a set designate the same end station interface (port).
>
> 2)      page 10
> If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], the
> only one byte Types and Lengths could be used.
> (it would become)
> If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], then
> only one byte Types and Lengths could be used.
>
> 3)    page 12
>   The presence of this sub-sub-TLV indicates that the interfaces given in
> the IA APPsub-TLV are reachable in the topology give.
> (I'd change it to)
>   The presence of this sub-sub-TLV indicates that the interfaces given in
> the IA APPsub-TLV are reachable in the topology given.
>
> 4)    page 12
> (This is not real clear as to what it is trying to communicate .. at least
> to me)
> (what is written)
> It is useful if the IA APPsub-TLV occurs outside of the context of a message
> indicating the topology or if it is desired and permitted to override that
> specification.
> (if I figured this out)
> You might want to use the Data Label or Topology sub-sub-TLVs where the IA
> APPsub-TLV is not in a message or some other context that specifies the Data
> Label or Topology. (Multi-topologyTRILL really isn't fully specified yet but
> the Topology sub-sub-TLV is provided for future use.) Alternatively, even if
> the IA APPsub-TLV is inside a message or some other context, you might want
> to specify that for some particular IA APPsub-TLV, a different Data Label or
> different Topology should be used, so you might want to use the sub-sub-TLV
> to override that specification.
>
> 5)    page 14
> Security on the wire, or in storage, for this data is to be providing by the
> transport or storage used.
> (What I'd put)
> Security on the wire, or in storage, for this data is to be provided by the
> transport or storage used.
>
> The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be treated as
> if it occurred as a 4th entry inside each of the three Address Sets.
> (I'd write)
> The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be treated
> as if it occurred as a 4th entry inside each of the three Address Sets.
>
> The OUI would them be supplied by a second Fixed Address sub-sub-TLV proving
> the OUI.
> (I think it should be)
> The OUI would then be supplied by a second Fixed Address sub-sub-TLV proving
> the OUI.
>
> acronyms

---

From: [email-masked]
Date: Thu, 26 Feb 2015 11:01:15 -0800

Thank you!!! >*bow*<
gayle

Hi Gayle,

Donald