Subject: [rbridge] RBridge Ingress Address

From: pkoganti at Brocade.COM (Phanidhar Koganti)
Date: Tue, 6 Mar 2007 12:45:09 -0800

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Mar 2007 13:50:11 -0800

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

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>