Subject: [rbridge] Should we optimize the common case?

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Tue, 14 Nov 2006 08:51:13 -0800

I've worked on such systems, and while the address summarization creates a degree of scale, you generally find that the fixed association between endnode and switch is very restricting and limiting.  

This is one of the reasons that I find TRILL very clean... the relationship between an endnode and an rbridge is that of convenience, not requirement.

I can build multi-homed networks... assuming that an edge rbridge can maintain multiple endhost->rbridge associations without changing the forwarding constructs of the rbridge "core".  This occurs because each edge rbridge advertises reachability to the host.

I can redirect frames through an rbridge network without changing the underlying L2 constructs (as required by many IDS/crypto protocols).  Then I can forward them to their intended destinations.

All of these require support from coordinating edge rbridges... the endhosts, other edge rbridges, and core rbridges are blissfully unaware of these goings on.

All this comes from partitioning the system into a simple, fast, cheap HW forwarding plane and a fully SW managed control plane.

JR

> -----Original Message-----
> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] 
> Sent: Tuesday, November 14, 2006 2:37 AM
> To: Caitlin Bestler; Radia Perlman; J. R. Rivers; Silvano Gai
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> I think there is a misunderstanding.  This is IMHO a 
> practical alternative:
> -An RBridge port is connected to a  "link" and receives frames from 
> multiple hosts:  The RBridge builds an internal translation table of  
> global MACs to hierarchical MACs (HMACs) assigned by him and replaces 
> global MAC by hierarchical MAC in the original frame.
> -These hierarchical MAC addresses for hosts contain the RBridge 
> Nickname, so it becomes *part* of the complete host address 
> transmitted 
> as "original" frame.  So these addresses should contain 
> RBridge Nickname 
> with host nickname appended (internal grouping of host nicknames per 
> RBridge port ID would also help). To be defined.
> - Hierarchical MAC MAY also be used in the ARP response packets (when 
> RBridge acts as proxy ARP or by interception of the host response 
> packet), so the requester obtains the hierarchical MAC 
> address instead 
> of the global one and uses it for all transactions.
> - The hosts with hierarchical MAC addresses do not need being 
> announced 
> by the RBridges in their host lists, because their DR RBridge 
> nickname  
> is included in the hierarchical MAC address of host in the "original" 
> (now altered with HMAC) frame.
> - Frames with inner hierarchical destination address need 
> only to read 
> the destination RBridge Nickname to obtain the egrees RBridge 
> (no need 
> to look host-RBridge table). The host list mechanism is not used by  
> hosts whose RBridge handles them with hierarchical addressing. 
> Both types, global and local hierarchical addresses may 
> coexist. Local 
> hierarchical save processing and enhance scalability.
> Hope this clarifies.
> Guillermo
> 
> PD.
> Other issues
> -DHCP-like mechanism
> Hierarchical MACs can be assigned with DHCP like mechanism to 
> hosts, but 
> IMHO this has impact on end nodes, so it can not be the standard 
> mechanism, only an option.
> - Generic hierarchical MAC addresses and masks (ref. Dr. 
> Morales slide)
> I proposed the generic addressing format  that includes hierarchical 
> masks looking for a generic addressing space, that could be useful to 
> scale further RBridges in the future. I understand that at 
> this stage of 
> definition of RBridges to look for a fully generic format could be 
> disruptive. However, the need for a generic hierarchical addressing 
> space in Ethernet is growing.
>  
> 
> 
> 
> Caitlin Bestler escribi?:
> > Radia Perlman wrote:
> >   
> >> Not sure I've been following this, but let me conjecture what
> >> people are suggesting, and if I'm right about the suggestion,
> >> I think it's a good idea. Correct me if it's not what people are
> >> saying. 
> >>
> >> So I think what they are saying is the following:
> >> a) there are cases where an RBridge has a block of addresses
> >> (like DHCP) that it hands out to endnodes
> >> b) in that case, it would be nice if the RBridge can
> >> announce, in its LSP, the whole range of addresses, rather
> >> than reporting each individually
> >> c) the change would be an ability to express a range in the
> >> endnode announcement. This seems easy, but I think it would
> >> be best done with a 2nd TLV in IS-IS. The 1st TLV would be 
> individual
> >> addresses. The 2nd TLV would be pairs of addresses (low, high). Or
> >> (low, increment), as in "starting with address X,
> >> 32 addresses" (which would take up a bit less space than two MAC
> >> addresses. 
> >>
> >> I don't think of this as a hierarchical address---I just
> >> think of it as a range of addresses reachable from one RBridge.
> >>
> >>     
> >
> > Reduction in the total number of reports required to support N
> > addresses is probably the only benefit of "hierarchical addresses"
> > that we can achieve if we are going to support global-scope MAC
> > addresses as well. Which I'm certain everyone agrees is a given.
> >
> >   
>

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 15 Nov 2006 16:32:14 +0100

While agreeing with some of the arguments, I see far from ideal for 
scalability that RBridges advertise host lists with a number of host L2 
addresses impossible to consolidate.
Looking for some hierarchy and structure in L2 addresses, although not 
easy at first glance, may provide long term benefits in scalability.
Guillermo