Subject: [rbridge] What is important in RBridge version 1.0?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 07:48:58 -0700

The current discussion of TTL/broadcast storm/etc made me think what is
important in TRILL version 1.0 and what can be delayed to version 2.0 or
dealt with in separate documents.

Here is my list:

1) excellent support for shortest path/multipath
   * core instance of IS-IS
   * nickname assignments
   * DR election

2) A super stable frame format, so that companies may start to code
their ASIC

3) Broadcast storm suppression
   * Radia RPF proposal

4) learning from data traffic (backward learning as bridges do)

5) Spanning Tree interoperability at the edges
   * simple form, receiving BPDUs only

6) A last call no later than the end of the year.

I propose we focus our discussion on these points without which we don't
have a viable standard.

Let's delay/move to other documents:

1) ARP/ND proxy

2) per VLAN IS-IS instance

3) IGMP learning

What do you think?

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 09:02:20 -0700

> 1) excellent support for shortest path/multipath

Different paths yes, but not "multipath", which presumes multiple
concurrent paths.

> 2) A super stable frame format, so that companies may start to code

Always (in all versions, IMO).

> 3) Broadcast storm suppression

Avoidance. I might include loop avoidance here.

>    * Radia RPF proposal

TTL to break forwarding loops.

Existing spanning tree (as much as possible) to avoid broadcast loops.

No *new* protocols unless absolutely necessary.

> Let's delay/move to other documents:

Agreed on all below.

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070503/91067539/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 09:55:39 -0700

Joe,

"multipath", which, as you say, presumes multiple concurrent paths is
the main reason for TRILL.

We don't need to do anything in the standard, since ISIS allows the
computation of multiple concurrent paths. It is up to the product to
decide how many path they will support, exactly as it happens in
routers.

More inline

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Thursday, May 03, 2007 9:02 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] What is important in RBridge version 1.0?
> 
> 
> 
> Silvano Gai wrote:
agreed

> TTL to break forwarding loops.
agreed

> Existing spanning tree (as much as possible) to avoid broadcast loops.

Are you speaking of Spanning Tree or Spanning Tree Protocol?

> > Let's delay/move to other documents:
I am glad

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 10:12:16 -0700

> the main reason for TRILL.

Different traffic (i.e., different flows) using different paths
concurrently is the main reason for TRILL.

Multipath - as I understand how the term is typically used in the IETF -
is a way for the same traffic (i.e., a single flow) to use multiple
paths concurrently. That is NOT a primary reason for TRILL, though, if
ISIS provides it already that's fine. I wouldn't list it as a primary
issue, though.

Besides, isn't the PAS supposed to list these (and doesn't it, to some
extent?)

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070503/fa51ba49/signature-0001.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 11:03:28 -0700

Joe,

The current draft does not define the term flow and IMHO MUST not define
it.
IS-IS, OSPF, FSPS, etc enable load balancing, but do not specify the
granularity of load balancing, the number of path and the path selection
algorithm. These are product features.

Many commercial products allow to configure round robin, source only,
source-dest pair, five tuple load balancing.

-- Silvano

> Sent: Thursday, May 03, 2007 10:12 AM
> To: Silvano Gai
> >>> The current discussion of TTL/broadcast storm/etc made me think
what
> > is

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 03 May 2007 11:14:14 -0700

> The current draft does not define the term flow and IMHO MUST not define

Agreed; I was using it as an example of how to differentiate
interpretations of the term 'multipath' only.

> algorithm. These are product features.

OK, so let me be specific:

TRILL v1.0 does not need to support load balancing. If we get it for
free, so be it.

TRILL v1.0 does need to allow different edge pairs to use
non-overlapping communication paths (is that "flow"-free enough)?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070503/b1fac6bb/signature.bin