[rbridge] Should we optimize the common case?

[Silvano Gai]

Eric,


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Gray, Eric
> Sent: Wednesday, November 15, 2006 1:32 PM
> To: Guillermo Ibáñez; J. R. Rivers
> Cc: rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> 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...

Can we stop making this argument? It is not constructive.
I think Guillermo understand the difference between Layer 2 and IP, as well as we do.

I am not sure I agree the TRILL should use Hierarchical MAC addresses, but I definitely agree that this has been proposed in several different forums/occasions and it has some value.

We also need to clearly say that there are two different possible uses of Hierarchical MAC Addresses:

1) The switch assigns to the end node of a hierarchical MAC address. This goes in the inner header.

2) The switch uses in the outer header hierarchical MAC addresses to encode different kind of information.

IMHO 1) is interesting but it does not support legacy and therefore is pragmatically difficult. I also don't believe in NATting the MAC addresses.

2) can be explored and used if needed.

-- Silvano


> 
> --
> 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
> -->
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge