Subject: [rbridge] RBridge Ingress Address

From: pkoganti at Brocade.COM (Phanidhar Koganti)
Date: Tue, 6 Mar 2007 17:13:31 -0800

Radia,

Thanks for the response.

In you point c) if can learn end node addresses from the data-path
then why are we not doing it? Wouldn't it be a more scalable solution
for the control plane (ISIS). 

Thanks
Phanidhar Koganti
Brocade
408 333 5455

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Tuesday, March 06, 2007 1:50 PM
To: Phanidhar Koganti
Cc: rbridge at postel.org
Subject: Re: [rbridge] RBridge Ingress Address

You've really kind of answered your own question. Originally the shim 
header only
had a single RBridge nickname. For unicast it was "egress". For 
multicast it was
"ingress". Everything is engineering tradeoffs.  There's seldom a "right

answer",
but often two perfectly reasonable choices, and we don't want the WG 
agonizing forever,
se we seem to have chosen having both ingress and egress.

The cost of having both ingress and
egress is an extra 4 bytes.

The advantages of having both are:
a) some IEEE things (like BCN -- congestion notification) require 
knowing where something
came from, so could use "ingress RBridge"
b) tunneling usually has both source and destination, so it's "more
natural"
c) we might at some point choose, as you suggested, to learn some or all

of the endnodes
based on decapsulated traffic (so only the egress RBridge would learn 
the mapping between
the source MAC and the ingress RBridge)
d) for multicast, it allows multipathing by having the ingress RBridge 
R1 choose a different
tree (not the one rooted at R1), for distributing the multicast frame
e) for multicast, it allows configuring things to compute fewer trees, 
because instead of
requiring all RBridges to compute a tree rooted at every ingress, 
RBridges can request
that they not be tree Roots. (except the RBridges with lowest IS-IS ID 
-- that one has to be the
root of a tree so that there is always at least one tree all the 
RBridges compute).

There might have been other reasons, but these are the ones I could 
remember off the top of my head.

Radia

Phanidhar Koganti wrote On 03/06/07 12:45,:

>Hi,
>
>Went through the below draft briefly and had a basic question. Bear
with
>me if this has already been answered on the list
>
>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0
3
>.txt
>
>For Known DA
>
>  Trill.EgressRBridgesAddress = egress RBRIDGE; 
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>For Unknown DA / Multicast Traffic
>
>  Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution
>Tree
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>In both the above cases the unicast forwarding and the distribution
tree
>to use is conveyed using "Trill.EgressRBridgesAddress". 
>
>My question is where does the "Trill.IngressRBridgesAddress" play a
>role?
>
>
>My second question is
>
>Learning of L2 end-node addresses are done using ISIS TLVs, why can't
we
>learn from the data-path similar to 802.1D/Q? 
>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address)
>
>In such a case there would be use for the
"Trill.IngressRBridgesAddress"
>
>Thanks
>Phanidhar Koganti
>Brocade
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Mar 2007 17:35:17 -0800

There were various arguments about that as well. Personally, I think 
it's reasonable either way,
and actually there might be a reason for some endnodes to be learned one 
way and others another.
For instance, for access points in which endnodes enroll, it is likely 
better to send around announcements
in IS-IS.

Some of the arguments, again, off the top of my head, for why it's good 
to announce at least some of the endnodes

a) sometimes it is clear when an endnode is no longer there (for 
instance, the access point finds out) in
which case it's advantageous to tell everyone

b) for IP nodes, it is possible for the RBridge to ping its attached 
endnodes to make sure they really are there.
Perhaps only in response to seeing some other RBridge announce an 
attached endnode.

c) in general only the egress RBridge will find out about S. If lots of 
people talk to S, then that traffic will
be flooded, unless S's RBridge announces where S is.

d) there might be a node that only occasionally talks and lots of nodes 
send it data, in which case traffic
to it will often be flooded.

e) I think some implementors were telling me that they didn't want to 
have to learn from decapsulated
traffic.

f) we probably do want to announce (layer 3, layer 2) pairs based on 
ARP/ND replies, so as to not require
flooding ARP/ND queries. If most nodes are IP nodes, then that would 
mean most (if not all) would be
advertised anyway.

One reason I was happy the WG wanted to put in ingress RBridge as well 
as egress RBridge was
because of the possibility of implicitly learning some of the endnodes.

Radia