Subject: [trill] Charter Revision Active-Active Item

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 May 2013 22:05:55 -0400

Hi,

Item "(2) Active-Active connection at the edge of a TRILL campus.
(draft-ietf-trill-cmt, draft-hu-trill-pseudonode-nickname)"

There appeared to be agreement that work should be done in this space
but a better problem statement / scope was requested.

Comments?

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 May 2013 22:08:56 -0400

Just speaking as a WG participant, I've come up with the attached,
which incorporates some comments from others. It could be expanded
into an internet draft if desired.

Thanks,
Donald

---

From: Haoweiguo <[email-masked]>
Date: Fri, 3 May 2013 02:53:50 +0000

Hi Donald,
For Active-Active access scenario, the following requirements also should be considered:

Support fast node and link failure detection.
Support LACP configuration and state synchronization.
Support MAC-Sharing to avoid always broadcasting

The detail of the above requirements have been described in the draft <draft-hao-trill-rb-syn-00>.
thanks
weiguo

________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2013年5月3日 10:08
到: [email-masked]
主题: Re: [trill] Charter Revision Active-Active Item

Thanks,
Donald

---

From: Haoweiguo <[email-masked]>
Date: Fri, 3 May 2013 03:06:33 +0000

Hi Donald,
Active-Active normally means dual-home, in trill multi-homing scenario, CE may be accessed to more than two edge RBs. so the terminology of Active-Active had better be modified to All-Active to support more general multi-access scenario.
thanks
weiguo
________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2013年5月3日 10:05
到: [email-masked]
主题: [trill] Charter Revision Active-Active Item

Hi,

Comments?

Thanks,
Donald

---

From: Yizhou Li <[email-masked]>
Date: Fri, 3 May 2013 11:14:27 +0800

Currently we have appointed forwarder (AF) mechanism for multi-access link
connecting to edge RBridges. As AF only allows one RBridge forwarding frames
for a single VLAN, it is normally considered as VLAN scoped active-standby
though traffic can be load balanced among VLANs.

The word "active-active" used in item 2 excludes the problems identified for
current AF mechanism and non active-active scenarios. I think something like
"multi-access connections at the edge" is a better description. Problems in
multi-access connections but not typical active-active scenarios include the
following in my opinion,

1. Simplified AF mechanism with the approach specified by RFC6325 appendix
A.3. draft-yizhou-trill-tc-awareness described STP topology change problem
within this scenario too.
2. Optimization of AF mechanism, e.g
- Better convergence time for failure recovery. Currently (3*) Hello timer
is used to detect the neighbor RB failure and then DRB should re-assign the
VLANs previously delegated to the failed RB to others. It takes too long
time in practice. I believe at least for access link (not equipment) failure
some optimization can be done for traditional AF mechanism to improve the
detection timer and AF re-assignment.    
3. Common problems for both active-active and active-standby (AF like
mechanism) cases. E.g. rapid MAC address purge at the remote RBridge when
existing nickname-MAC correspondence becomes invalid at local. 

I propose one of the following to be present in the charter.
1) Specify a larger scope for item 2. E.g. replace active-active with
multi-access
Or
2) Add another item. Something like, Enhancement of current multi-access
connection mechanism at the edge of a TRILL campus.

Thanks,
Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Donald Eastlake
Sent: Friday, May 03, 2013 10:06 AM
To: [email-masked]
Subject: [trill] Charter Revision Active-Active Item

Hi,

Comments?

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: Olen Stokes <[email-masked]>
Date: Mon, 6 May 2013 12:20:49 -0700

Thanks for the proposal.  We may want to add some clarification to the discussion about looping during transient conditions associated with a topology change.  Loops contained completely inside the TRILL network would have a TTL count to help mitigate the problem.  However, a loop where a packet continually leaves the TRILL network and then re-enters the TRILL network will not receive benefit from the TTL count.  Such a loop should not be permitted even during a transient period. 

Cheers,
Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Thursday, May 02, 2013 10:09 PM
To: [email-masked]
Subject: Re: [trill] Charter Revision Active-Active Item

Just speaking as a WG participant, I've come up with the attached, which incorporates some comments from others. It could be expanded into an internet draft if desired.

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

On Thu, May 2, 2013 at 10:05 PM, Donald Eastlake <[email-masked]> wrote:
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 6 May 2013 23:45:24 -0400

Hi Olen,

Thanks for suggesting this clarification. I agree that only transient
loops protected by the hop count are acceptable.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 6 May 2013 23:56:01 -0400

Hi,

> Active-Active normally means dual-home, in trill multi-homing scenario, CE may be accessed to more than two edge RBs. so the terminology of Active-Active had better be modified to All-Active to sup…

I'm not sure....  I agree that "Active-Active" is a bit misleading and
when I draw diagrams I try to always include three TRILL switches at
the edge so it is clear that it is not limited to two. "All-Active"
sounds more accurate but people are not used to it. They are used to
saying "Active-Active" and I think they usually understand that it can
be more than two...

> Support fast node and link failure detection.

Yes.

> Support LACP configuration and state synchronization.

I think LACP or the like may be a part of one solution for the case
where the TRILL switches cannot see each others Hellos, so I do not
think the problem statement should mention it. There may also be a
solution where they can see each others Hellos...

> Support MAC-Sharing to avoid always broadcasting

Minimizing unknown destination MAC flooding seems like a good goal.

Thanks,
Donald

---

From: Jon Hudson <[email-masked]>
Date: Mon, 6 May 2013 21:05:51 -0700

Active-Active just means nothing is passive  

It comes from the term active-passive. Where there is often multiple passive objects waiting to become active. 

It does not imply 2,3,4 etc. 

Just means that every path or device is active, and not passively waiting to take over for a failed unit/node.

---

From: Haoweiguo <[email-masked]>
Date: Tue, 7 May 2013 09:28:05 +0000

Hi Donald,
Pls see [hwg] inline.
thanks
weiguo
________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2013年5月7日 11:56
到: Haoweiguo
Cc: [email-masked]
主题: Re: 答复: [trill] Charter Revision Active-Active Item

Hi,

[hwg]: Yes, "Active-Active" is a bit misleading, but people usually understand that it can be more than two.

> Support fast node and link failure detection.

Yes.
[hwg]: OK

[hwg]: I think multi-chassis LACP is important in active-active solution. Otherwise, in trill active-active access scenario, LACP can't be run between edge RB and end system,
it will impose restriction on active-active access through LAG and LACP. Maybe we can modify the point as following:
      Support LAG access. LACP can be run between edge RB and end system.

[hwg]: OK

Thanks,
Donald