[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

[Ayan Banerjee]

Donald,

Please see below. 

Thanks,
Ayan


On 2/19/09 7:58 AM, "Donald Eastlake" <d3e3e3 at gmail.com> wrote:

> Hi Ayan,
> 
> See below...
> 
> On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee <ayabaner at cisco.com> wrote:
>> Radia and Donald,
>> 
>> ...
>> 
>> Clarification for EASDI:
>> If my understanding of the draft is accurate, there are possibly 4K
>> vlan-ESADIs and on each node and we are "only" running the CSNP
>> functionality (of traditional IS-IS). The "hello" functionality is not run
>> on them. Consider a router that is interested in all "vlans"; such a router
>> will have to support *all* VLAN-ESADIs.
> 
> I assume by router you mean RBridge. No RBridge "has to support" any
> VLAN-ESADIs. It always works, in the sense that behavior is correct,
> for the RBridge to just learn from the data plane. No one implementing
> an RBridge is required to implement any ESADI support.
> 
> Support/use of ESADI would likely be important in cases where their is
> a Layer 2 registration protocol for end stations and you want to
> transmit the end station MAC address information securely or the rate
> of mobility or arrival/departure of end stations is so high that, in
> the absence of ESADI, you would have excessive black-holing due to
> out-of-date address cache information that has not yet timed out or
> excessive broadcast traffic due to unknown unicast addresses.
> 
> I can think of scenarios where an RBridge is appointed forwarder for
> 4K VLANs. But I have a much harder time thinking of plausible
> scenarios where there are 4K VLANs all of which have the special
> requirements to make ESADI very important. Can you give me an example?
> 

I was envisioning the case when there is only "protocol" based learning of
MAC addresses (and no data path learning). However, if this is not the
intention of ESADI then this is fine.

>>                                                            I believe that
>> this is a significant
>> load on the router. I believe that we should have an optional single-ESADI
>> instance as well; this will allow for control-plane learning of unicast MAC
>> addresses in a more scalable fashion. I am fine with having the optional 4K
>> instances also co-exist; but my preference is to have a single instance for
>> unicast MAC distribution.
> 
> As I say, I don't see why there would ever be thousands of VLANs for
> which the ESADI protocol was being used. But let's assume there are.
> So what exactly do you mean by "instance"? It seems to me its mostly a
> matter of implementation whether it is more "load" on an RBridge that
> for some reason is running ESADI for thousands of VLANs to get
> separate LSPs/CSNPs for each VLAN or some kind of merged single set of
> LSPs/CSNPs that are received, processed, and possibly re-emitted
> hop-by-hop throughout the entire campus.
> 
> In order for this "single-ESADI instance" you propose to work,
> wouldn't all transit RBridges have to implement it? Doesn't that
> impose a big burden, since no RBridge has to implement ESADI right
> now. Doesn't it add a big load to almost all RBridges that are
> actually interested in running ESADI for zero or maybe one or two
> VLANs? Wouldn't they have to actively process all ESADI protocol
> mediated updates for all VLANs? ESADI is carefully designed current to
> impose zero control plane burden on transit RBridges that don't
> implement it and have it enabled. Wouldn't you lose that? Also,
> wouldn't the information in the "single instance" LSPs have to be
> labeled as to what VLAN it applies to? Doesn't that imply the
> specification of a bunch of additional TLVs or optional fields in TLVs
> with VLAN fields? And doesn't that break VLAN translation within
> RBridges or at least make it much more complex?
> 
>> P2P IIHs and LAN IIHs:
>> When TRILL-IS-IS sends out hellos it does so based on the link capability.
>> On P2P links (configured or real ones) it sends P2P IIHs and on multi-access
>> links it sends LAN IIHs. I presume that in TRILL we want to default sending
>> out LAN IIHs (is this accurate?). We should have a section on P2P IIHs and
>> just talk about if any functionality/sub-tlvs are not required for that case
>> (for example, do we need to find a common vlan in P2P like in a LAN -
>> probably not etc). Note that a P2P IIH and LAN IIH will not be bring up an
>> adjacency.
> 
> Yes, I think the default should be LAN Hellos. I'm not sure there are
> many differences between P2P and LAN Hello contents. Couldn't you have
> a "point-to-point" link between two RBridges that was, in fact, over
> carrier Ethernet facilities or something that only provide
> connectivity on, say, VLAN 42? But if there are any differences at
> all, a brief section on P2P Hellos seems reasonable.
> 

Thanks this would make things clearer.

>> Parallel links between rbridges:
>> We need information in the draft that states that we break ties using (a)
>> extended circuit id on P2P links (makes 3-way handshake mandatory) and (b)
>> in a LAN, use lan circuit id.
> 
> I'm confused by what you say. Assume we have RBridges 1 and 2 such
> that there is, say, a point to point link between port A on RB1 and
> port A on RB2 and also between port B on RB1 and port B on RB2. There
> are two points of view depending on whether you are one of these two
> RBridges or some other RBridge in the campus:
> 
> Assume you are some other RBridge, RB3. Do you even see both the A and
> B adjacencies in the link state? I would think not and that this
> should be reported as only a single adjacency in the RB1 and RB2 LSPs.
> If, for some reason, you do see it as two adjacencies, why would you
> care? As long as you know there is connectivity between RB1 and RB2
> you can use that in SPF calculations. I suppose you need a way of
> determining the cost from the two costs you would see but you could
> just use the minimum of the two or something. And if for some really
> bizarre reason, even though you are remote from RB1 and RB2 you not
> only see the two parallel paths in the link state but you actually
> care which path is taken, there is no space in the LSP TLVs to encode
> any tie breaking information such as you suggest. So I don't see any
> need for a tiebreaker here.
> 
> Assume the other case, that you are either RB1 or RB2. I don't see any
> difficulty here either. You should accept TRILL traffic on both
> connections and we should say that as a clarification. (You wouldn't
> want the Reverse Path Forwarding Check or something causing TRILL
> frames on one of the parallel connections to be discarded.) And you
> can send traffic on either connection. Or can do Equal Cost MultiPath
> on both. But if you send over only one of them then, assuming they are
> equal cost, it seems like a purely local decision which one and I
> don't see why we need to specify a tie breaker.

When you have two parallel links and only one of them becomes a member of
the tree, then RPF as you have pointed out will fail on the other. If the
parallel links are part of a bundle, we do not need this. However, if the
user has specifically made them distinct, we need a method to ensure that
tree is computed along only one of them.

> 
>> Thanks,
>> Ayan
>> 
>> P.S. I have not fully cross-checked with version 11 to see all that has gone
>> in, but I will take a look. Also, I will take a closer look on the
>> hello-AF/AC issue with mis-configurations and get back to you.
>> 
>> ...
>> 
> 
> Thanks,
> Donald
> 
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com