[rbridge] Should we optimize the common case?
Gray, Eric
Eric.Gray at marconi.com
Thu Nov 16 07:34:41 PST 2006
Silvano,
Actually, no. We cannot stop making this argument, especially
in this venue. Arguing that it might be appropriate to use IP is
ALWAYS a legitimate argument in the IETF. Period.
--
Eric
--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com]
--> Sent: Thursday, November 16, 2006 10:11 AM
--> To: Gray, Eric; Guillermo Ibáñez; J. R. Rivers
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: RE: [rbridge] Should we optimize the common case?
-->
-->
--> 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
-->
More information about the rbridge
mailing list