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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 15 Nov 2006 16:31:40 -0500

Guillermo,

	In an ideal world, this would be true.  However, these ideas
are recurring and - as a strictly practical issue - they have to 
cooperate in a world that has moved on from past iterations of the 
same ideas.

	For the most part, the answer you're going to find here is:
if you need hierarchical addressing, you've come to the right place 
- just use IP...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 15, 2006 10:32 AM
--> To: J. R. Rivers
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 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
--> 
--> J. R. Rivers escribi?:
--> > 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.
--> >>>
--> >>>   
--> > 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 16 Nov 2006 07:42:17 +0100

Gray, Eric escribi?:
> same ideas
If this is so, why are not using IP to scale up  Metro Ethernet Networks 
and Provider Backbone Bridges?