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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 14 Nov 2006 16:35:24 -0800

Radia,

May I propose:

c) Your b) proposal plus the option that on point-to-point link we can use a well know destination MAC address, i.e. RBridge-Next-Hop. 

This allows building a simplified HW that works only on point-to-point links and that does not keep a next hop adjacency table.

-- Silvano

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Tuesday, November 14, 2006 6:59 AM
> To: Guillermo Ib??ez
> Cc: Caitlin Bestler; J. R. Rivers; Silvano Gai; rbridge at postel.org
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> The first RBridge has to recognize a true MAC address, so we can't
> reassign endnodes hierarchical
> addresses. I think trying to see nickname | nexthop as a hierarchical
> address is just confusing, especially
> since the "hierarchical address" will change at every hop. With the
> LIDs, it's sort of like a hierarchical
> address, but not really, since lots of endnodes (all the ones on the
> same link) will share the same "hierarchical
> address". But with Sanjay's proposal of folding "egress nickname" and
> "next hop nickname" into the
> destination address of the hop-by-hop header, this is *not* a
> hierarchical address of the destination endnode.
> And besides, this doesn't change the technical proposal, so trying to
> think of it that way is, I think, a digression.
> 
> The real question I think is between two proposals, with variants:
> 
> a) have 2 byte + Ethernet header: by folding next hop and egress
> nickname into "destination MAC" and
> transmitting RBridge and ingress RBridge nickname into "source MAC",
> with TTL as the only thing left over,
> with possible variant being folding TTL into the source and destination
> MACs as well.
> 
> b) have 6 byte + Ethernet header; putting ingress and egress RBridge
> nicknames and TTL into the 6 bytes;
> with possible variant being a variable length shim to add things like
> LIDs.
> 
> I'd prefer b) with fixed length at 6 bytes. My second choice is a) with
> the 2 byte addition for TTL, since
> I think also folding TTL into the MACs will be even more confusing.
> 
> Radia
> 
> 
> 
> I do think we should allow advertisement of MAC address ranges in IS-IS
> endnode reports, because
> in some cases this will make smaller tables.
> 
> I'd prefer the "true" hop by hop header, where next hop and this hop is
> used as the MAC addresses,
> and a shim header with 6 bytes, partially because it is simpler to
> understand, and will be perceived as
> pretty straightforward compared with what routers do; i.e., take a piece
> of information, put an end-to
> end header (e.g., IP header, but in our case the shim with
> ingress/egress RBridge and
> TTL) on the information, and then hop by hop put a link-specific header
> on (e.g.,
> an Ethernet header).
> 
> Radia
> 
> 
> 
> Guillermo Ib??ez wrote:
> 
> > 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.
> >>
> >>
> >