[rbridge] Should we optimize the common case?

[Radia Perlman]

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.
>>
>>   
>