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

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Mon, 13 Nov 2006 12:44:55 -0800

Sounds like we are in agreement.

JR

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Saturday, November 11, 2006 7:20 PM
> To: J. R. Rivers; Silvano Gai; Guillermo Ib??ez
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] Should we optimize the common case?
> 
> J. R. Rivers wrote:
> > Hierarchical addresses assume that a single rbridge "owns" a
> > station.  With the current concept of universal mac addresses
> > with rbridge advertisement, a single station can be reached
> > through multiple rbriges... allowing effective dual homing.
> > 
> > I think that hierarchical station addresses require very careful
> > thinking. 
> > 
> > JR
> > 
> > 
> 
> There are possible deployments of rbridges where the rbridge does
> indeed "own" the end nodes, or perhaps it "owns" them in collaboration
> with a partner rbridge. Prime examples would include an "rbridge"
> implemented by a hypervisor and/or NIC to support multiple virtual
> NICs, and a bridge connecting blades on a backplane with external
> ethernet links.
> 
> But even in these environments, the individual OSs may want to
> configure their MAC addresses individually. So hierarchical addresses
> would seem to be a possible enhancement, but there is no obvious
> path to using them generally.
> 
> As an option it would probably take the form of allowing
> announcements of ranges of MAC addresses, rather than
> requiring the  rbridge to announce each individually.
> 
> 
> 
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 13 Nov 2006 17:11:19 -0800

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.

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 13 Nov 2006 18:14:05 -0800

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 14 Nov 2006 11:36:30 +0100

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.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 14 Nov 2006 06:59:17 -0800

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:

> 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.
> - 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.
> hosts whose RBridge handles them with hierarchical addressing. Both 
> types, global and local hierarchical addresses may coexist. Local 
> 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 
> 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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 14 Nov 2006 16:16:43 +0100

Two comments.
Guillermo

Radia Perlman escribi?:
> The first RBridge has to recognize a true MAC address, 
The first RBridge recognizes a true MAC adress and replaces in the 
encapsulated frame with the hierarchical address (MAC swapping).
> so we can't reassign endnodes hierarchical
> since the "hierarchical address" will change at every hop.
The hierarchical address consists of DR RBridge nickname plus host 
nickname (assigned by DR), so it does not change at every hop.
> With the LIDs, it's sort of like a hierarchical
> with possible variant being folding TTL into the source and 
> destination MACs as well.
>
> I'd prefer b) with fixed length at 6 bytes. My second choice is a) 
> with the 2 byte addition for TTL, since
> I do think we should allow advertisement of MAC address ranges in 
> IS-IS endnode reports, because
> I'd prefer the "true" hop by hop header, where next hop and this hop 
> is used as the MAC addresses,
> pretty straightforward compared with what routers do; i.e., take a 
> piece of information, put an end-to
> 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:
>
>> packet), so the requester obtains the hierarchical MAC address 
>> instead of the global one and uses it for all transactions.
>> - 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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 14 Nov 2006 07:28:56 -0800

Ah. I think I misunderstood a bit the intent of the hierarchical 
addresses in my previous
message. I think the suggestion was for
"endnodes" that don't have a fixed MAC address, so nobody would ever learn
their true MAC address. This was not an attempt to assign hierarchical 
MAC addresses to
all the endnodes, which I assumed.
But even so, you want the perceived MAC address never
to change once assigned, and the RBridge nickname might change, creating 
confusion.

We will achieve some scalability by announcing ranges of MAC addresses 
(perhaps even from the local space)
that an RBridge with virtual attached endnodes can assign. If the block 
of MAC addresses is configured, then
it's the "customer's fault" if the addresses are not unique within the 
campus. Perhaps to avoid misconfiguration,
RBridges can announce the block of MAC addresses they are going to 
assign to virtual attached endnodes.
This can either be for just noticing misconfiguration, or can be a 
negotiation -- choosing a different block if
it conflicts with someone else.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 14 Nov 2006 17:28:27 +0100

Further clarifications
Guillermo

Radia Perlman escribi?:
> to change once assigned, and the RBridge nickname might change, 
> creating confusion.
>
The RBridge nickname will change when the DR changes due to the previous 
DR being unavailable or not being root bridge anymore.
> that an RBridge with virtual attached endnodes can assign. If the 
> block of MAC addresses is configured, then
The hierarchical MAC shall contain the DR RBridge nickname plus host 
identifier. If the RBridge nickname is unique within the campus, so will 
be the hierarchical MAC addresses.
I am not in favour of "ranges", but of hierarchy.

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 14 Nov 2006 08:34:03 -0800

Guillermo Ib??ez wrote:
> The first RBridge recognizes a true MAC adress and replaces
> in the encapsulated frame with the hierarchical address (MAC
> swapping).

I think you are suggesting that the RBRidge act as proxy ARP
so that all remote traffic thinks that the local MAC address
is *the* MAC address, complete with translation of MAC addresses
on the fly.

There are some cool possibilities there, but unfortunately I
do not think such a solution is universally viable. For a local
connection applications may attach actual meaning to the MAC
address. Some immediate examples that come to mind include
DHCP servers and the generation of default IPv6 addresses.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 14 Nov 2006 17:52:55 +0100

You are likely right (DHCP and IPv6 defaul). But it is probably
worth to think a moment how to circunvent it before rejecting the 
approach, given the advantages involved.
Hierarchical addresses are an option to global standard host list 
mechanism, they could be enabled and disabled per RBridge.
Guillermo

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 14 Nov 2006 09:21:45 -0800

> is *the* MAC address, complete with translation of MAC addresses

That's now a router. IMO, it should act more like a bridge - it might
use MAC address wrappers to direct ingressed packets to the egress
rbridge, but should NOT affect the ARP table of hosts outside the rbridge.

Removal of the rbridge should ONLY cause reconfiguration of the spanning
tree in the remaining ethernet segments, NOT cause communication failure
due to incorrect ARP entries (i.e., that would destroy "unplug-and-play").

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061114/189c777d/signature.bin