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

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

Are you suggesting address translation in the context of a layer 2 network?

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.
> >
> >   
>