Subject: [trill] draft-ietf-trill-cmt

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 9 Nov 2012 00:51:35 +0000

draft-ietf-trill-cmt-01 has been submitted. This addresses comments and feedback received as part of the last call.

Cmt draft specifically address the RPF issues at the active-active edge.

Failure scenarios and recovery from configurations errors etc are addressed in draft-hu-trill-pseudonode-nickname and

http://www.ietf.org/proceedings/85/slides/slides-85-trill-7.pptx

Thanks
Tissa

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, November 08, 2012 4:13 PM
To: Tissa Senevirathne (tsenevir)
Subject: Confirmation for Auto-Post of I-D draft-ietf-trill-cmt

Hi,

The IETF datatracker draft submission service has received your draft draft-ietf-trill-cmt-01, and requires a confirmation step in order to be able to complete the posting of the draft.

Please follow this link to the page where you can confirm the posting:
Confirmation URL: http://datatracker.ietf.org/submit/status/46375/confirm/5a7339f8bc1d02fbab941fc9e96abdc55711327c/

Best regards,

	The IETF Secretariat
	through the draft submission service

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Nov 2012 17:08:07 -0500

Hi.

I've got a fairly basic question about this document.

What exact customer/deployment scenario is it trying to address?

It says:

>    This document specifies a concept of Affinity sub-TLV to solve
>    associated RPF issues at the active-active edge. Specific methods in
>    this document for making use of the Affinity sub-TLV are applicable
>    where multiple RBridges are connected to an edge device through link
>    aggregation or to a multiport server or some similar arrangement
>    where the RBridges cannot see each other's Hellos.

I view Link Aggregation Groups (LAGs) as an L2 construct that would be
hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the
presence of multiple links between a pair of switches from STP, so STP
only sees one link (the LAG) rather than the individual links. Thus, I
would expect RBs to want to only know of a single link (i.e., the LAG)
and not have any understanding that the link may actually be a LAG.

Moreover, Figure 1 is not describing LAG, but multi-chassis LAG
(MLAG). MLAG is not standardized (all implementations are proprietary
and there is no interoperability between vendors). Moreover, MLAG
implementations are pretty restricted -- last I checked, MLAG products
were limited to only 2 switches. So the figure in the document showing
MLAG involving an arbitrary number of "N" switches seems a stretch.

Do I have the right understanding of what is meant by "LAG" in the
draft?

The idea that RBs would be aware of individual links within a LAG
kind of defeats the purpose of having LAGs. Is that really what is
being proposed?

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 19 Nov 2012 23:58:20 -0500

Hi Thomas,

Let me describe what I think it going on.

> What exact customer/deployment scenario is it trying to address?

Scenarios in which customer wants active-active end station connectivity.

TRILL can provide ECMP and multi-pathing and rapid fail-over in the
links between RBridges. This draft is aimed at specifying a building
block (the Affinity sub-TLV) and giving an example of use of that
building block towards getting the same capabilities for end station
connectivity to the campus..

> and not have any understanding that the link may actually be a LAG.

There are various references in various TRILL documents that agree
with you that the classic two end-point LAG appears to TRILL as a
single link with a single port at each end. This draft gives, as
examples of the use of the Affinity sub-TLV, multi-port servers which
do not forward frames between those ports, and what is usually called
multi-chassis LAG (MC-LAG) where you have one device (such as a
bridge) on one end and multiple devices on the other end that conspire
to act like one device. (MC-LAG is commonly supported but using
proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV,
that is seeking to extend LAG to allow more than one device on each
side.)

draft-hu-trill-pseudonode-nickname is an example of another use of the
Affinity sub-TLV not related to LAG. If I recall correctly, at the
Atlanta meeting I repeatedly paired the trill-pseudonode-nickname
draft with the trill-cmt draft and suggested people consider them
together.

> MLAG involving an arbitrary number of "N" switches seems a stretch.

I'm not sure the number of RBridges in the edge group matters so much
or that you know about all MC-LAG implementations. In any case, a
multi-port server could have more than two ports.

> Do I have the right understanding of what is meant by "LAG" in the

I think so -- that is, you correctly understood that in this draft it
actually means MC-LAG.

> kind of defeats the purpose of having LAGs. Is that really what is

The draft is intended to specify the Affinity sub-TLV and to provide
an example where an edge group of RBridges cannot see each other's
Hellos. For the sub-part of the example using MC-LAG, rather than a
multi-port server, I would say the MC-LAG is doing exactly what the
purpose of MC-LAG is.

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

---

From: Jon Hudson <[email-masked]>
Date: Mon, 19 Nov 2012 22:23:35 -0800

Just to add to what Donald said...

This is a case where the draft came out of a need that kept appearing while discussing and trying to solve other challenges ( like a/a host based connections).

As apposed to a "draft if search of a problem" this is really a case of a draft providing a building block that by not existing would prevent other solutions from coming forward.

Now as to the terminology. There is much confusion in the market and with customers as to when something is or is not LAG.

One if of the limitations today of host based LAGs is that they have to go to the same physical switch unless the target switch is part if a proprietary MCT pair, and that the MCT group is itself only a pair.

What many customers want (and is provided today by other proprietary solutions) is N active links to N top of rack switches where the initial common two configs would be two links to two TOR switches from one host, or four active links from a host to four different TOR switches.

This maybe a cause of the confusion caused by the document saying N switches. And is part of the value since as you stated most MLAG solutions are only in a pair, and subpar as a result. 

J

On Nov 19, 2012, at 8:58 PM, Donald Eastlake <[email-masked]> wrote:

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

---

From: "Pat Thaler" <[email-masked]>
Date: Wed, 21 Nov 2012 01:07:03 +0000

Jon and Donald

I'm skeptical about a "building block" to use in future solutions in general and especially for link aggregation or teaming. It's a fairly difficult to generically make a group of bridges pretend to be a single bridge and one should start with an architecture for solution, IMO, rather than starting with pieces that you hope to pull into a future solution. 

"A typical deployment scenario, depicted in Figure
   1, which may have either End Stations and/or Legacy bridges attached
   to the RBridges.  These Legacy devices typically are multi-homed to
   several RBridges and treat all of the uplinks as a single Link
   Aggregation (LAG) bundle [802.1AX]."
End stations support many forms of teaming so they don't "typically" use any one  form. For instance, one is a bridge-independent form of active-active teaming where the end station load balances traffic to various links with different MAC addresses on each link. They generally can't treat links to separate bridges as a single 802.1AX LAG unless the bridges cooperate to support a proprietary multi-chassis LAG. 

LAG is defined by 802.1AX and that term shouldn't be used for other mechanisms for using multiple links. It's better to use something else like "teaming" when one wants to include both 802.1AX and non-802.1AX mechanisms. The groupings identified as LAGs in Figure 1 will not be LAGs unless the bridges are presenting them as a single bridge to the end stations which isn't trivial to get right and is currently proprietary.

DRNI (dual resilient network interconnect) - the capability being added in the 802.1AX-Rev project has a focused objective of defining a mechanism for using a LAG between two provider networks (that's why it's called a "network interconnect") where the links end in more than one bridge (probably two or three bridges) on each side of the aggregation.  End node attachment to a multi-bridge LAG host isn't an objective.

Pat

-----Original Message-----
From: Jon Hudson [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 10:24 PM
To: Donald Eastlake
Cc: Thomas Narten; Tissa Senevirathne (tsenevir); [email-masked]
Subject: Re: [trill] draft-ietf-trill-cmt

J

---

From: [email-masked]
Date: Fri, 23 Nov 2012 14:04:42 +0800

Hi,Tissa

Section 5.1 provides a simple general method to assign different trees to 
different members and it is easy to employ.
But in my opinion, it could be better to allow co-existence of default 
manner（cmt） and manual configuration 
for distribution tree choosing，otherwise if some member RBs are manually 
configured and others are not configured at all, 
compatibility problem with the current algorithm could occur.
So, maybe we should provide a unified tree distribution method which is 
compatible 
with manual configuration and can ensure different member RBs obtain 
different  distribution tree? 

Thanks,
Tina

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Sun, 25 Nov 2012 16:50:20 +0000

Hi Tina

I am not sure I completely understand your question. Are you referring to a scenario where some of the members (e.g. RB1 ) are using some manual configuration and other is using the proposed method (e.g. RB2) in the CMT draft ?

PS: Both RB1 and RB2 are members of the virtual RBridge RBv

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: Re: [trill] draft-ietf-trill-cmt

Hi,Tissa

Section 5.1 provides a simple general method to assign different trees to different members and it is easy to employ.
But in my opinion, it could be better to allow co-existence of default manner（cmt） and manual configuration
for distribution tree choosing，otherwise if some member RBs are manually configured and others are not configured at all,
compatibility problem with the current algorithm could occur.
So, maybe we should provide a unified tree distribution method which is compatible
with manual configuration and can ensure different member RBs obtain different  distribution tree?

Thanks,
Tina

---

From: [email-masked]
Date: Mon, 26 Nov 2012 09:19:28 +0800

Hi,Tissa

Yes，that's exactly what I mean. :)
Should the CMT take this scenario into account？

Thanks,
Tina

"Tissa Senevirathne (tsenevir)" <[email-masked]> 
发件人:  [email-masked]
2012-11-26 00:50

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [trill] draft-ietf-trill-cmt

Hi Tina
 
I am not sure I completely understand your question. Are you referring to 
a scenario where some of the members (e.g. RB1 ) are using some manual 
configuration and other is using the proposed method (e.g. RB2) in the CMT 
draft ?

Hi,Tissa 

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

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 26 Nov 2012 15:44:18 +0000

Hi Tina

Answer is no need and it is already built in. Here is why. We propose to announce the Affinity Capability.  CMT specification is that RBridge announcing that capability must follow the specified tree allocation. If some RBridge is announcing the affinity capability and yet doing manual allocation then it is an implementation error or local policy/administrative matter.

Thanks
Tissa

Sent: Sunday, November 25, 2012 5:19 PM

Hi,Tissa

Thanks,
Tina

"Tissa Senevirathne (tsenevir)" <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012-11-26 00:50

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Hi Tina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [trill] draft-ietf-trill-cmt

Hi,Tissa

Thanks,
Tina _______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: [email-masked]
Date: Tue, 27 Nov 2012 17:21:45 +0800

Hi,Tissa

Maybe the CMT is just to announce the Affinity Capability, IMO, the CMT is 
used to solve the tree allocation problem in RBv.
Such as the figure described in RFC6325 P93 for example: the network 
manager may be want to do some manual configuration in the situation.
                              +---+
                              |RBy|---------------+
                              +---+               |
                             /  |  \              |
                           /    |    \            |
                         /      |      \          |
                      +---+   +---+   +---+       |
                      |RB1|---|RB2|---|RB3|       |
                      +---+   +---+   +---+\      |
                        |       |       |    \    |
                      +---+   +---+   +---+    \+---+
                      |RB4|---|RB5|---|RB6|-----|RBz|
                      +---+   +---+   +---+    /+---+
                        |       |       |    /
                      +---+   +---+   +---+/
                      |RB7|---|RB8|---|RB9|
                      +---+   +---+   +---+
There are two distribution trees in the network, one rooted at RBy will 
predominantly use the vertical links among RB1 through RB9 
while another rooted at RBz will predominantly use the horizontal.
RB1\RB4\RB7\RB8\RB9 are all edge RBs, by default, each will choose the 
shortest path’s tree root to use,
and each may use the two trees to multipathing multi-destination traffic 
at the same time. 
But if we have RB1 and RB7 in a RBv, then we have to allocate different 
trees between RB1 and RB7.
With the current CMT manner, maybe RBz is allocated to RB1, RBy is 
allocated to RB7.
Obviously,RB1 is closer to RBy, so the network manager may want to 
manually configure RBy to RB1 as an algorithm intervention.

As the local policy/administrative matter, how to compatible with manual 
configuration, maybe it is a question within the RBv's tree allocation?

I think this may be solved by choosing a member RB, which is used to 
collect configuration information of RBv,
and execute an unified algorithm to allocate trees for all members within 
the same RBv. 
There are two benefits by doing so: first, it is compatible, second there 
is no need for all other member RBs to execute the algorithm.

Thanks,
Tina

2012-11-26 23:44

收件人

Hi Tina
 
Answer is no need and it is already built in. Here is why. We propose to 
announce the Affinity Capability.  CMT specification is that RBridge 
announcing that capability must follow the specified tree allocation. If 
some RBridge is announcing the affinity capability and yet doing manual 
allocation then it is an implementation error or local 
policy/administrative matter.
 
Thanks
Tissa

Hi,Tissa 

Thanks,
Tina 

收件人

Hi Tina 

  

Hi,Tissa 

Thanks,

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 27 Nov 2012 15:34:46 +0000

Hi Tina

What you are looking at is a local administrative policy, I am not clear what to be specified in a standard. Additionally manual configurations does not provide failover protection. I think it is best to leave the administrative policies to platforms.

Additionally, when multiple tree allocation algorithms are present, we need to ensure that all of the RBv are using the exact same algorithm, which will make matters complicated. So in short, if one would like to use a different algorithm than what is specified in the standard, it is up to them to do so and ensure that they meet

1.       Failover requirements

2.       Algorithm consistency between members

Thanks
Tissa

Sent: Tuesday, November 27, 2012 1:22 AM

Hi,Tissa

Maybe the CMT is just to announce the Affinity Capability, IMO, the CMT is used to solve the tree allocation problem in RBv.
Such as the figure described in RFC6325 P93 for example: the network manager may be want to do some manual configuration in the situation.
                              +---+
                              |RBy|---------------+
                              +---+               |
                             /  |  \              |
                           /    |    \            |
                         /      |      \          |
                      +---+   +---+   +---+       |
                      |RB1|---|RB2|---|RB3|       |
                      +---+   +---+   +---+\      |
                        |       |       |    \    |
                      +---+   +---+   +---+    \+---+
                      |RB4|---|RB5|---|RB6|-----|RBz|
                      +---+   +---+   +---+    /+---+
                        |       |       |    /
                      +---+   +---+   +---+/
                      |RB7|---|RB8|---|RB9|
                      +---+   +---+   +---+
There are two distribution trees in the network, one rooted at RBy will predominantly use the vertical links among RB1 through RB9
while another rooted at RBz will predominantly use the horizontal.
RB1\RB4\RB7\RB8\RB9 are all edge RBs, by default, each will choose the shortest path’s tree root to use,
and each may use the two trees to multipathing multi-destination traffic at the same time.
But if we have RB1 and RB7 in a RBv, then we have to allocate different trees between RB1 and RB7.
With the current CMT manner, maybe RBz is allocated to RB1, RBy is allocated to RB7.
Obviously,RB1 is closer to RBy, so the network manager may want to manually configure RBy to RB1 as an algorithm intervention.

As the local policy/administrative matter, how to compatible with manual configuration, maybe it is a question within the RBv's tree allocation?

I think this may be solved by choosing a member RB, which is used to collect configuration information of RBv,
and execute an unified algorithm to allocate trees for all members within the same RBv.
There are two benefits by doing so: first, it is compatible, second there is no need for all other member RBs to execute the algorithm.

Thanks,
Tina

2012-11-26 23:44

收件人

抄送

主题

Hi Tina

Thanks
Tissa

Hi,Tissa

Thanks,
Tina

2012-11-26 00:50

收件人

抄送

主题

Hi Tina

Hi,Tissa

Thanks,
Tina _______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: [email-masked]
Date: Wed, 28 Nov 2012 11:15:53 +0800

Hi,Tissa

IMO, maybe the following informations should be standarded: 
1）how to choose the member RB
2）how the chosen member RB  to collect the tree configured information 
3）how to announce the tree allocation information

And with regard to failover protection, when any other member RB fails, 
the failure information should be transmitted to the chosen member RB, 
and the chosen member RB will reallocate trees among member RBs except the 
failed one. 
If the chosen member RB had failure, there should be a slave chosen member 
RB elected to be the master.

OK, maybe that will be too complex, and more likely to be a local 
administrative policy, but if the CMT mention about that, it will be more 
impeccable. :)

Thanks,
Tina

2012-11-27 23:34

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [trill] draft-ietf-trill-cmt

Hi Tina
 
What you are looking at is a local administrative policy, I am not clear 
what to be specified in a standard. Additionally manual configurations 
does not provide failover protection. I think it is best to leave the 
administrative policies to platforms.
 
Additionally, when multiple tree allocation algorithms are present, we 
need to ensure that all of the RBv are using the exact same algorithm, 
which will make matters complicated. So in short, if one would like to use 
a different algorithm than what is specified in the standard, it is up to 
them to do so and ensure that they meet
 
1.       Failover requirements
 
Thanks
Tissa

Hi,Tissa 

Thanks,
Tina 

收件人

Hi Tina 

Thanks 
Tissa 

Hi,Tissa 

Thanks,
Tina 

收件人

Hi Tina 

 

Hi,Tissa 

Thanks,

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 28 Nov 2012 03:45:41 +0000

Hi Tina

I must admit, I did not fully understand what you mean by some of the items below

1）how to choose the member RB
Current proposal is to consider all RBridges announcing nickname RBv to be members.
2）how the chosen member RB  to collect the tree configured information
[not clear with what you meant]
3）how to announce the tree allocation information
[currently, each RBridge use a standard algorithm and all RBridges can deduce the trees used by member RBridges RBv]

If you want more complex and extensible solution, I think it is best to write a separate draft.

Thanks
Tissa
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 27, 2012 7:16 PM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]; [email-masked]
Subject: 答复: Re: [trill] draft-ietf-trill-cmt

Hi,Tissa

And with regard to failover protection, when any other member RB fails,
the failure information should be transmitted to the chosen member RB,
and the chosen member RB will reallocate trees among member RBs except the failed one.
If the chosen member RB had failure, there should be a slave chosen member RB elected to be the master.

OK, maybe that will be too complex, and more likely to be a local administrative policy, but if the CMT mention about that, it will be more impeccable. :)

Thanks,
Tina

2012-11-27 23:34

收件人

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Hi Tina

1.       Failover requirements

Thanks
Tissa

Hi,Tissa

Thanks,
Tina

2012-11-26 23:44

收件人

抄送

主题

Hi Tina

Thanks
Tissa

Hi,Tissa

Thanks,
Tina

2012-11-26 00:50

收件人

抄送

主题

Hi Tina

Hi,Tissa

Thanks,

---

From: [email-masked]
Date: Wed, 28 Nov 2012 14:20:33 +0800

Hi,Tissa

Thank you for your quick reply. :)
And maybe my discription is not clear, just as you said, it's a bit 
complicated.

Thanks,
Tina

2012-11-28 11:45

收件人

Hi Tina
 
I must admit, I did not fully understand what you mean by some of the 
items below
 
1）how to choose the member RB 
Current proposal is to consider all RBridges announcing nickname RBv to be 
members.
2）how the chosen member RB  to collect the tree configured information
[not clear with what you meant] 
3）how to announce the tree allocation information
[currently, each RBridge use a standard algorithm and all RBridges can 
deduce the trees used by member RBridges RBv]
 
If you want more complex and extensible solution, I think it is best to 
write a separate draft. 
 
Thanks
Tissa

Hi,Tissa 

Thanks,
Tina 

收件人
"[email-masked]" <[email-masked]> 
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]> 
主题
Re: [trill] draft-ietf-trill-cmt

Hi Tina 

  
1.       Failover requirements 
  
Thanks 
Tissa 

Hi,Tissa 

Thanks,
Tina 

收件人

Hi Tina 

Thanks 
Tissa 

Hi,Tissa 

Thanks,
Tina 

收件人

Hi Tina 

Hi,Tissa 

Thanks,