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

From: [email-masked]
Date: Thu, 06 Feb 2014 18:33:47 -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           : TRILL: ESADI (End Station Address Distribution Information) Protocol
        Authors         : Hongjun Zhai
                          Fangwei Hu
                          Radia Perlman
                          Donald Eastlake
                          Olen Stokes
	Filename        : draft-ietf-trill-esadi-05.txt
	Pages           : 36
	Date            : 2014-02-06

Abstract:
   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topologies and
   link technologies.  TRILL supports multi-pathing of both unicast and
   multicast traffic.  Devices that implement the TRILL protocol are
   called TRILL Switches or RBridges (Routing Bridges).

   ESADI (End Station Address Distribution Information) is an optional
   protocol by which a TRILL switch can communicate, in a Data Label
   (VLAN or Fine Grained Label) scoped way, end station addresses and
   other information to TRILL switches participating in ESADI for the
   relevant Data Label.  This document updates RFC 6325, specifically
   the documentation of the ESADI protocol, and is not backwards
   compatible.

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

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-esadi-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, 8 Feb 2014 12:26:03 -0500

This version has a number of editorial changes and clarifications.

As per Erik Nordmark's message, there are also some technical changes
that, I believe, are confined to Section 4.4. The provision posted
here:
http://www.ietf.org/mail-archive/web/trill/current/msg06090.html
has been included but, overall, I think the section has been
simplified. Comments welcome.

Based on other correspondence I have received, I think there is a sign
error is the offset equation in Section 4.4.  "(100 - Random(Jitter))"
should just be "Random(Jitter)".

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

On Thu, Feb 6, 2014 at 9:33 PM,  <[email-masked]> wrote:
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: [email-masked]
Date: Tue, 18 Feb 2014 09:21:30 +0800

After the techincal changes, the current version(-05 version) looks good 
to me. As one of the authors I support the last WG call for this draft. :)

> should just be "Random(Jitter)".

Agree. The change gives the originator plenty of time to transmit the 
fragment and gives much more time for the fragment to be propagated 
through the campus.

Thanks,
Hongjun Zhai
---------------------------------------------
Add: No.68 Zijinghua Road, Yuhuatai District,
Nanjing City, R.P. China, 210012

Tel: +86 025 52877345
Email: [email-masked]
---------------------------------------------

Donald Eastlake <[email-masked]> 
发件人:  "trill" <[email-masked]>
2014-02-09 01:26

收件人
"[email-masked]" <[email-masked]>
抄送

主题
Re: [trill] I-D Action: draft-ietf-trill-esadi-05.txt

Thanks,
Donald

---

From: Haoweiguo <[email-masked]>
Date: Wed, 19 Feb 2014 01:16:38 +0000

Hi authors,

   I have one comment as follows:

   As ESADI is a Data Label(VLAN or FGL) scoped solution, each edge RBridge needs to
   establish ESADI session for each VLAN or FGL.  If a RBridge owns large number of VLAN or FGL, the number
   of ESADI session is huge and is a big burden for the RBridge's CPU.
   So Management Data Label for ESADI may be used for this purpose.

   Every RBridge should be configured with a globally unique management data label.
   Rbridges establish ESADI session using this management Data Label. In extreme
   case, we can use one management ESADI session for all data labels. With this
   approach CPU consumption can be greatly reduced on every RBridge. The
   correspondence of management Data Label and L2 VNs can be statically configured on
   every RBridge. The operator must make sure the configuration consistency for all
   RBridges.

   Do you think management data label mechanism should be introduced for this purpose?

   thanks

   weiguo

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2014年2月18日 9:21
收件人: Donald Eastlake
抄送: trill; [email-masked]
主题: Re: [trill] I-D Action: draft-ietf-trill-esadi-05.txt

Thanks,
Hongjun Zhai

Tel: +86 025 52877345

2014-02-09 01:26

收件人

主题

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 19 Feb 2014 11:52:26 +0800

Hi Weiguo,

Thanks for your comments. My response as follows.

> of ESADI session is huge and is a big burden for the RBridge's CPU. 

Even if there are a huge number Data Labels (VLANs or Fine Grained Labels) 

enabled in a TRILL campus, an ESADI RBridge does not need to participate 
in 
all these Data Labels. Usually, it needs only to enable ESADI instances 
for 
some of the Data Labels in which there are end stations attached to it. 
And the number of the Data Labels is not huge in most practical 
deployment. 
So I do not think the big burden for the RBridge's CPU exists in the 
practical deployments.

> every RBridge. The operator must make sure the configuration consistency 
for all

Even the big burden exists theoretically; the Management Data Label 
has no help to reduce the burden for the ESADI RBridge's CPU. 
Instead, it might increase the burden to some ESADI RBridges. 
For example, assume RB1 enable ESADI function only in VLAN10, it needs 
to receive the ESADI packets just in this VLAN according to the current 
ESADI mechanism. However, if the Management Data Label is used, RB1 
has to receive all the ESADI packets which includes MAC address 
reachability information for many VLANs in which other ESADI RBridges 
participate. Furthermore, the using of Management Data Label will force 
ESADI LSPs to contain Data Label in their MAC address Reachability TLVs, 
which conflicts with the future Data Label mapping scheme that may be 
adopted.

Thanks,
Hongjun Zhai

Tel: +86 025 52877345

Haoweiguo <[email-masked]> 
发件人:  "trill" <[email-masked]>
2014-02-19 09:16

收件人
"[email-masked]" <[email-masked]>, Donald Eastlake 
<[email-masked]>
抄送
trill <[email-masked]>, "[email-masked]" <[email-masked]>
主题
[trill] 答复:  I-D Action: draft-ietf-trill-esadi-05.txt

   Hi authors,
   I have one comment as follows:
   As ESADI is a Data Label(VLAN or FGL) scoped solution, each edge 
RBridge needs to
   establish ESADI session for each VLAN or FGL.  If a RBridge owns large 
number of VLAN or FGL, the number
   of ESADI session is huge and is a big burden for the RBridge's CPU. 
   So Management Data Label for ESADI may be used for this purpose.
 
   Every RBridge should be configured with a globally unique management 
data label.
   Rbridges establish ESADI session using this management Data Label. In 
extreme
   case, we can use one management ESADI session for all data labels. With 
this
   approach CPU consumption can be greatly reduced on every RBridge. The
   correspondence of management Data Label and L2 VNs can be statically 
configured on
   every RBridge. The operator must make sure the configuration 
consistency for all
   RBridges. 
 
   Do you think management data label mechanism should be introduced for 
this purpose? 
   thanks
   weiguo

Thanks,
Hongjun Zhai

Tel: +86 025 52877345

收件人

主题

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 Feb 2014 11:30:20 -0500

Hi,

See some more detailed comments below but, overall, speaking as a WG
participant, I think this draft should go through without technical
changes other than the minor correction here:
http://www.ietf.org/mail-archive/web/trill/current/msg06102.html

On Tue, Feb 18, 2014 at 10:52 PM, <[email-masked]> wrote:
> > RBridge needs to establish ESADI session for each VLAN or FGL.  If
> > a RBridge owns large number of VLAN or FGL, the number of ESADI
> > session is huge and is a big burden for the RBridge's CPU.
>
> Even if there are a huge number Data Labels (VLANs or Fine Grained
> Labels) enabled in a TRILL campus, an ESADI RBridge does not need to
> participate in all these Data Labels. Usually, it needs only to
> enable ESADI instances for some of the Data Labels in which there
> are end stations attached to it.  And the number of the Data Labels

Also, it is not clear that ESADI would be used for all Data Labels. It
is fine for some Data Labels to continue to use data plane learning
while others use ESADI.

> is not huge in most practical deployment.  So I do not think the big
> burden for the RBridge's CPU exists in the practical deployments.
>
> > Every RBridge should be configured with a globally unique
> > management data label.  Rbridges establish ESADI session using

I agree that it is useful for a TRILL campus to have a campus-wide
management data label for reasons that are not related to ESADI.
There is a personal draft that includes this:
draft-eastlake-trill-nick-label-prop-02.txt. However, I think that
draft, which needs more work, should be separate from the ESADI draft.

Thanks,
Donald

> > this management Data Label. In extreme case, we can use one
> > management ESADI session for all data labels. With this approach
> > CPU consumption can be greatly reduced on every RBridge. The
> > correspondence of management Data Label and L2 VNs can be
> > statically configured on every RBridge. The operator must make
> > sure the configuration consistency for all RBridges.
>
> Instead, it might increase the burden to some ESADI RBridges.  For
> example, assume RB1 enable ESADI function only in VLAN10, it needs
> to receive the ESADI packets just in this VLAN according to the
> current ESADI mechanism. However, if the Management Data Label is
> used, RB1 has to receive all the ESADI packets which includes MAC
> address reachability information for many VLANs in which other ESADI
> RBridges participate. Furthermore, the using of Management Data
> Label will force ESADI LSPs to contain Data Label in their MAC
> address Reachability TLVs, which conflicts with the future Data
> Label mapping scheme that may be adopted.
>
> Thanks,
> Hongjun Zhai
> "[email-masked]" <[email-masked]>, Donald Eastlake <[email-masked]>
> 抄送

---

From: Haoweiguo <[email-masked]>
Date: Fri, 21 Feb 2014 07:09:13 +0000

OK. I support this draft to become WG draft as ESADI base protcol. 
In the future, we can write a separate draft for management data label solution to reduce ESADI session number. 
Thanks
weiguo

________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2014年2月20日 0:30
收件人: [email-masked]
抄送: Zhai Hongjun; Haoweiguo
主题: Re: [trill] 答复: I-D Action: draft-ietf-trill-esadi-05.txt

Hi,

Thanks,
Donald