Subject: [rbridge] Ingress Rbridge address and BCN

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 13:35:44 -0400

Radia,

	I don't know where the idea that we only need a 2-byte
nick-name comes from.  When did we change from the idea of using 
an MPLS (or MPLS-like) SHIM with 19 bits to represent specific
RBridges to using a completely different SHIM and only requiring 
16-bits of RBridge identification?

	That means we've determined that we need fewer identifiers
by at least a factor of 8.  Have we reached that conclusion?

	I know that this has been discussed, but I do not know that 
there has been any conclusion out of that discussion.  I do not
agree that this conclusion is correct, but have not said anything
because I did not see the idea gaining ground in serious mailing
list discussion.

	IMO, if we go to using both ingress and egress in the SHIM,
we need to go to a 2-word SHIM with a full 20 bits (each) used to 
identify both the ingress and the egress.

	If we did that, I would advocate a SHIM format like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                Egress                 |  CoS  |       TTL     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|               Ingress                 |         Rerved        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

It is possible to argu that it might be more efficient to have 
the Ingress "label" first, but the format would otherwise stay 
the same.  I would prefer it in the order shown.

	I also disagree with the notion that there's no advantage in
keeping an MPLS-like SHIM format.  I think that people who argue
that there is no advantage in having a very similar format, have
not yet discussed this with implementers.

--
Eric 

--> -----Original Message-----
--> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
--> Sent: Friday, October 27, 2006 12:32 PM
--> To: Gray, Eric
--> Cc: Wadekar, Manoj K; rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> I think the intent is that RBridges not keep endnode 
--> information they 
--> don't need to keep. So for instance,
--> if the BCN is being sent to an endnode in VLAN A, an intermediate 
--> RBridge that does not have a
--> VLAN A link would not know about the endnodes in VLAN A. It 
--> would know 
--> which links are in VLAN A,
--> so it wouldn't have to send the BCN to every link, but it 
--> wouldn't know 
--> which VLAN A link had the endnode.
--> And also, it would be reasonable to have a core of RBridges 
--> that don'e 
--> have any endnodes.
--> 
--> Potential ways of dealing with BCN, and their costs:
--> a) make all RBridges know about all endnodes, just in case 
--> they want to 
--> send a BCN
--> b) flood BCNs to more links than necessary (the links in 
--> the VLAN) when 
--> the endnode is unknown
--> to the RBridge initiating the BCN
--> c) include the ingress RBridge in the shim header.
--> 
--> I'm not that excited about BCN---it's a new functionality, 
--> who knows if 
--> it will ever be widely deployed,
--> etc. However, what's interesting about it is that it does present a 
--> reason why it is useful to have
--> ingress RBridge there. Which means we might stumble on 
--> other things in 
--> the future.
--> 
--> I was a bit uncomfortable about overloading a field with "sometimes 
--> ingress sometimes egress".
--> Since we changed over to nicknames so we only need 2 bytes 
--> to specify 
--> each RBridge (rather than
--> 6 bytes for each), I'm leaning to doing this. The cost is 
--> an extra 2 
--> bytes in the header, and not being
--> MPLS-like, but given that people have said being MPLS-like and not 
--> "exactly MPLS" is not that
--> much of an advantage, the cost then becomes 2 bytes, which 
--> seems worth 
--> it for what seems
--> like a more conventional design (encapsulating with both 
--> ingress and 
--> egress).
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Manoj,
--> >
--> >	Once again, the assumption that cores do not retain 
--> "addresses of
--> >all the end-stations in [the] whole cluster" is a 
--> "convenient assumption"
--> >for making the argument that another mechanism is required.
--> >
--> >	Currently, there would be no requirement for retaining all such 
--> >addresses as you have to be careful not to send BCN 
--> messages to those
--> >end-stations that don't support them.  Moreover, as 
--> mentioned previously,
--> >it is trivially easy to determine what address information 
--> should be kept.
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: rbridge-bounces at postel.org 
--> >--> [mailto:rbridge-bounces at postel.org] On Behalf Of 
--> Wadekar, Manoj K
--> >--> Sent: Friday, October 27, 2006 11:21 AM
--> >--> To: rbridge at postel.org
--> >--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> >--> 
--> >--> Yes, for large clusters, if cores do not maintain addresses 
--> >--> of all the
--> >--> end-stations in whole cluster - then only way to get BCN 
--> >--> back to ES, is
--> >--> to send them to ingress rbridge-address and then have 
--> that ingress
--> >--> rbridge forward BCN to end station with appropriate ES address.
--> >--> 
--> >--> If so, ingress rbdridge address seems to be requirement to me.
--> >--> 
--> >--> Thanks,
--> >--> - Manoj
--> >--> 
--> >--> -----Original Message-----
--> >--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> >--> Sent: Friday, October 27, 2006 8:00 AM
--> >--> To: Radia.Perlman at sun.com; Wadekar, Manoj K
--> >--> Cc: rbridge at postel.org
--> >--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> >--> 
--> >--> 
--> >--> If the congestion is detected in the core of the TRILL 
--> >--> network, how do
--> >--> you signal back to the source host if you don't know 
--> which is the
--> >--> ingresss RBridge? 
--> >--> 
--> >--> You cannot look-up the inner MAC address, because in 
--> the core of the
--> >--> network you don't keep the inner MAC addresses in the 
--> >--> table. Correct?
--> >--> 
--> >--> This is a clear reason while you need the ingress 
--> RBridge address.
--> >--> 
--> >--> -- Silvano
--> >--> 
--> >--> > -----Original Message-----
--> >--> > From: rbridge-bounces at postel.org 
--> >--> [mailto:rbridge-bounces at postel.org]
--> >--> On
--> >--> > Behalf Of Radia.Perlman at sun.com
--> >--> > Sent: Thursday, October 26, 2006 5:02 PM
--> >--> > To: Wadekar, Manoj K
--> >--> > Cc: rbridge at postel.org
--> >--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> >--> > 
--> >--> > Hi Manoj,
--> >--> > 
--> >--> > I'm confused about BCN. Wouldn't congestion notification 
--> >--> need to go to
--> >--> the
--> >--> > original endnode source,
--> >--> > and not the ingress RBridge?
--> >--> > 
--> >--> > Radia
--> >--> > 
--> >--> 
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> rbridge at postel.org
--> >--> http://mailman.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
-->

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 27 Oct 2006 11:21:08 -0700

Summary of below---asking how many RBridges anyone would ever expect to
need in a single campus.

>16-bits of RBridge identification?
The number 19-bits was chosen just because the MPLS label field was 20 bits,
and we were stealing one to indicate whether the field was "ingress" or 
"egress".
There was no science behind 19-bits other than it happened to be there, and
seemed uncontroversially way more than we'd actually need, so would
clearly be big enough.

If we weren't using an MPLS-like header, then we can actually think about
what size field we'd need. We wouldn't want the nickname space to be
too densely used, so 16 bits would support, say, 30,000 RBridges.

So the question is---how many RBridges would anyone need? Remember, this 
is for
your "LAN"---it's not intended to replace layer 3. What size bridged 
networks
are people building today? More than 1000 bridges?

So if nobody is building anything more than 1000 bridges, say, then 16 
bits is
safe. If 16 bits isn't safe, then sure, we can pick a different size field.

Radia