Subject: [rbridge] TTL only - was RE: New fields in shim header?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 12 Oct 2006 07:18:53 -0700

OK,
Let's restrict the discussion to IEEE 802.1-compliant Ethernet networks.

Today the outer header contains: 

   o  L2 destination = next RBridge, or for flooded frames, a new (to be

      assigned) multicast layer 2 address meaning "all RBridges" 

   o  L2 source = transmitting RBridge (the one that most recently 
      handled this frame)

If we want to avoid carrying the egress RBridge address in the shim
header, we need to put it in the outer header - L2 destination.

Is this what you are proposing?

-- Silvano

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Thursday, October 12, 2006 7:07 AM
To: Silvano Gai
Cc: Radia Perlman; rbridge at postel.org
Subject: Re: TTL only - was RE: [rbridge] New fields in shim header?

Silvano Gai wrote:
> Joe,
> 
> Let me focus on the need of RBridge addresses.
> 
> I didn't propose them; they are in the current WG draft:
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
> .txt
> to achieve scalability at the ISIS level.
> 
> The outer MAC addresses are present only if the frame is sent over 802
> link (section 2.9), but it may not be present on other media;
therefore
> TRILL cannot rely on them.
> 
> If you disagree with these two points, I think you disagree with the
> work that has been done in TRILL till now.

I agree with the charter, which limits us to specifying solutions that
work on 802.1 nets:

---
The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
topologies, using an existing link-state routing protocol technology.
---

The fact that the architecture discusses other links is OK; it's
informational anyway.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 12 Oct 2006 07:29:36 -0700

> header, we need to put it in the outer header - L2 destination.

The reason for the single shim rbridge address is a tradeoff, to avoid
populating the inner rbridge nodes with complete ingress tables. That's
a trade-off rather than a requirement.

If we went with strict minimalism, we could avoid the need for that
field; I understand the desire to avoid populating every node with full
tables, though. So I'll update my earlier note and add the single
desination/mulitcast source address field, as per the protocol doc.

As we go beyond that minimal requirement, we're starting to add
capability that looks more like IP than ethernet. IMO, rbridges should
support what ethernet supports, not necessarily what IP is capable of.
If you want IP, use IP.

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/20061012/ecfab487/signature.bin