[rbridge] RBridge Ingress Address

[Radia Perlman]

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



Phanidhar Koganti wrote On 03/06/07 17:13,:

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