Subject: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

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

This email extends the 2 week WG adoption call for
draft-zhang-trill-multi-level-single-nickname to go from 7/16 to 8/16/2015. 

The draft can be accessed at: 

http://datatracker.ietf.org/doc/draft-zhang-trill-multilevel-single-nickname

Please include in your response an evaluation of the technology and places

this technology might be deployed.

Sue Hares and Jon Hudson

---

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

This draft provides an applicable solution for TRILL multi-level. Support the adoption.

Thanks,

weiguo

________________________________
From: Susan Hares [[email-masked]]
Sent: Tuesday, August 04, 2015 21:41
To: [email-masked]
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

This email extends the 2 week WG adoption call for draft-zhang-trill-multi-level-single-nickname to go from 7/16 to 8/16/2015.

Sue Hares and Jon Hudson

---

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

I have responded  in the adoption call of draft-perlman-trill-rbridge-multilevel.

I support the adoption of the solution for multi-level as it is a necessary feature to solve the scalability issue of trill campus.

I support this single nickname solution to be adopted if WG has no intention to advance the other unique/aggregated nickname approaches.

However if we want to make all three solutions available, are they going to co-exist?

Thanks,
Yizhou

From: trill [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 04, 2015 9:42 PM
To: [email-masked]
Cc: 'Donald Eastlake'; 'Jon Hudson'
Subject: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

Sue Hares and Jon Hudson

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 Aug 2015 14:17:14 -0400

Hi,

On Wed, Aug 5, 2015 at 9:51 PM, Liyizhou <[email-masked]> wrote:
> I support the adoption of the solution for multi-level as it is a necessary
> feature to solve the scalability issue of trill campus.
>
> I support this single nickname solution to be adopted if WG has no intention
> to advance the other unique/aggregated nickname approaches.
>

I think there are two types of solutions: unique nickname and
aggregated nickname. Unique nickname is pretty straight forward and
there are not that many choices in deciding how to do it. I believe it
can also be done in software with existing hardware. There are more
choices in aggregated nicknames which are inherently more complex but
more scalable. Aggregated nickname schemes are also likely to requires
some firmware/hardware changes to handle high data rates. I think we
should only standardize one aggregation nickname method. But both
unique and aggregated methods should be able to co-exist.

As a TRILL campus grows it is reasonable to go to multi-level using
unique nicknames with a "small" number of level 1 areas, then at some
point start adding aggregated level 1 areas and perhaps eventually go
to all aggregated. This issue is discussed in the perlman draft.

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

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

---

From: gayle noble <[email-masked]>
Date: Thu, 06 Aug 2015 14:38:28 -0700

I support this draft for adoption.
I do have the following suggestions and corrections

These are the acronyms used but not defined
APPsub-TLV  Application sub-TLV
E-L1FS         Extended Level 1 Flooding Scope [RFC7356]
E-L2FS  Extended Level 2 Flooding Scope [RFC7356]
FGL            Fine Grained Label [RFC7172]
FS-LSP         Flooding Scoped Link State PDU [RFC7356]
PDU             Protocol Data Unit
TLV             Type Length Value

corrections

1.   page 5 section 3.2 - first paragraph - first sentence
[Both L1 and L2 are areas so "each L1 area and L2" reads a bit weird.]
(as written)
Distribution trees for flooding of multi-destination packets are 
calculated separately within each L1 area and L2.
(I'd write)
Distribution trees for flooding of multi-destination packets are 
calculated separately within each L1 and L2 area.

2.   page 9 second paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if this packet is originated from an area out of the connected areas, 
RB1 should replicate this packet and flood it on the proper Level 1 
trees of all the areas in which it acts as the DBRB.
(I'd write)
if this packet originated from an area out of the connected areas, 
RB1 should replicate this packet and flood it on the proper Level 1 
trees of all the areas in which it acts as the DBRB.

3.   page nine third paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if the packet is originated from one of the connected areas, RB1 
should replicate the packet it receives from the Level 1 tree and 
flood it on other proper Level 1 trees of all the areas in which it 
acts as the DBRB except the originating area (i.e., the area 
connected to the incoming interface).
(I'd write)
if the packet originated from one of the connected areas, RB1 should 
replicate the packet it receives from the Level 1 tree and flood it 
on other proper Level 1 trees of all the areas in which it acts as 
the DBRB except the originating area (i.e., the area connected to the 
incoming interface).

4.   page 9 fourth paragraph - third sentence
["can well appear" would read smoother as "can appear"]
(as written)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as 
area border RBridges but they can well appear in an L1 area acting as 
non-area-border RBridges.
(I'd write)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as 
area border RBridges but they can appear in an L1 area acting as 
non-area-border RBridges.

5.   page 11 second paragraph - third sentence
["will finally flooded" should be "will finally be flooded"]
(as written)
This packet will finally flooded to RB77 via RB30.
(should be)
This packet will finally be flooded to RB77 via RB30.

---

From: Liyizhou <[email-masked]>
Date: Fri, 7 Aug 2015 01:28:01 +0000

So single nickname solution is considered as a type of aggregated nickname approach, right?

I am ok with the logic of unique and aggregated nicknames. When number of nicknames is not a concern, unique nickname probably is good for us. And then grow to aggregated nickname later.

Thanks,
Yizhou

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Friday, August 07, 2015 2:17 AM
To: Liyizhou
Cc: Susan Hares; [email-masked]; Jon Hudson
Subject: Re: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

Hi,

On Wed, Aug 5, 2015 at 9:51 PM, Liyizhou <[email-masked]> wrote:
> I support the adoption of the solution for multi-level as it is a 
> necessary feature to solve the scalability issue of trill campus.
>
> I support this single nickname solution to be adopted if WG has no 
> intention to advance the other unique/aggregated nickname approaches.
>

I think there are two types of solutions: unique nickname and aggregated nickname. Unique nickname is pretty straight forward and there are not that many choices in deciding how to do it. I believe it can also be done in software with existing hardware. There are more choices in aggregated nicknames which are inherently more complex but more scalable. Aggregated nickname schemes are also likely to requires some firmware/hardware changes to handle high data rates. I think we should only standardize one aggregation nickname method. But both unique and aggregated methods should be able to co-exist.

As a TRILL campus grows it is reasonable to go to multi-level using unique nicknames with a "small" number of level 1 areas, then at some point start adding aggregated level 1 areas and perhaps eventually go to all aggregated. This issue is discussed in the perlman draft.

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

> Subject: [trill] draft-zhang-trill-multi-level-single-nickname - WG 
> Adoption Call extension (7/16 to 8/16/2015)
>
>
>

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 7 Aug 2015 06:48:34 +0000

Hi Gayle,

Appreciate the review! These comments will surely be incorporated when the draft is updated.

Thanks,
Mingui

From: trill [mailto:[email-masked]] On Behalf Of gayle noble
Sent: Friday, August 07, 2015 5:38 AM
To: [email-masked]
Subject: Re: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

corrections

1.   page 5 section 3.2 - first paragraph - first sentence
[Both L1 and L2 are areas so "each L1 area and L2" reads a bit weird.]
(as written)
Distribution trees for flooding of multi-destination packets are calculated separately within each L1 area and L2.
(I'd write)
Distribution trees for flooding of multi-destination packets are calculated separately within each L1 and L2 area.

2.   page 9 second paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if this packet is originated from an area out of the connected areas, RB1 should replicate this packet and flood it on the proper Level 1 trees of all the areas in which it acts as the DBRB.
(I'd write)
if this packet originated from an area out of the connected areas, RB1 should replicate this packet and flood it on the proper Level 1 trees of all the areas in which it acts as the DBRB.

3.   page nine third paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if the packet is originated from one of the connected areas, RB1 should replicate the packet it receives from the Level 1 tree and flood it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface).
(I'd write)
if the packet originated from one of the connected areas, RB1 should replicate the packet it receives from the Level 1 tree and flood it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface).

4.   page 9 fourth paragraph - third sentence
["can well appear" would read smoother as "can appear"]
(as written)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as area border RBridges but they can well appear in an L1 area acting as non-area-border RBridges.
(I'd write)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as area border RBridges but they can appear in an L1 area acting as non-area-border RBridges.

---

From: honjun.zhai <[email-masked]>
Date: Sun, 16 Aug 2015 22:48:18 +0800 (CST)

<p><br /></p><p><br /></p><p>Support as a co-author.</p><p><br /></p><p>By using the BRB's nicknames as the area aggregation nicknames for the flow destined to another area, this draft gives a relatively simple aggregation nickname solution for &nbsp;the mult-level TRILL.</p><p><br /></p><p>Thanks,</p><p>Hongjun Zhai</p>