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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 16 Nov 2006 10:06:35 -0500

Guillermo,

	Are you sure we are not?  Are there not a plethora of L2
overlay services based on one or more IP-based tunneling schemes?

--
Eric 

--> -----Original Message-----
--> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] 
--> Sent: Thursday, November 16, 2006 1:42 AM
--> To: Gray, Eric
--> Cc: J. R. Rivers; rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 
--> 
--> Gray, Eric escribi?:
--> > 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...
--> >   
--> If this is so, why are not using IP to scale up  Metro 
--> Ethernet Networks 
--> and Provider Backbone Bridges? 
--> > --
--> > 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 18:18:30 +0100

Of course there are a lot of them that do.
But there are others that do not: Provider Backbone Bridges performs 
Ethernet based
tunnelling. 
Guillermo