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

From: Radia Perlman <[email-masked]>
Date: Mon, 16 Feb 2009 21:22:24 -0800

Ayan -- I"ll answer two of the things you mentioned.

Ayan Banerjee wrote:
>
> 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 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.
>   
I think that combining the ESADIs into one would be a complication, and 
it involves more overhead
since RBridges would have to keep information for VLANs they are not 
interested in. So I think
that in most cases, having the separate ESADIs would work best. An 
RBridge is allowed to ignore
all ESADIs and only learn from data traffic, and it could choose to 
listen to ESADIs on some
subset of VLANs, and learn from data traffic on the others.
>
>
> 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 think that if R1 and R2 have two pt-to-pt links between them, they 
should not be reporting both of
them in their LSP.  There's already a tie-breaker for pseudonodes, 
right? Maybe I don't understand this issue.

Radia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Feb 2009 10:58:51 -0500

Hi Ayan,

See below...

On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee <[email-masked]> wrote:
> Radia and Donald,
> ...
> 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 believe that this is a significant

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.

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

> 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
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Ayan Banerjee <[email-masked]>
Date: Wed, 25 Feb 2009 10:31:03 -0800

Radia,

Some comments inline.

Thanks,
Ayan

> subset of VLANs, and learn from data traffic on the others.

I do not disagree with the fact that a single EASDI will imply that Rbridges
that are not interested in some VLANs will have additional information.
However, for the Rbridges that have multiple VLANS configured on them and
need to run multiple instances will find this onerous. I believe you are
suggesting in that case data-path learning is the way to go (since control
plane learning is optional)? I was proposing that why not in addition have a
single instance ESADI (since it is optional anyways) to account for that
scenario. 

> right? Maybe I don't understand this issue.

The issue is when there are parallel links between a pair of nodes, you do
want the tree to be bi-directional on the same link. As a result, we would
need extended circuit id to break the tie. This mandates 3-way handshake on
P2P links.

---

From: Ayan Banerjee <[email-masked]>
Date: Wed, 25 Feb 2009 10:46:56 -0800

Donald,

Please see below. 

Thanks,
Ayan

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

> all, a brief section on P2P Hellos seems reasonable.

Thanks this would make things clearer.

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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Feb 2009 21:18:19 -0500

Hi Ayan,

It looks like we are essentially in agreement on your first two
points. See below on your third point.

> tree is computed along only one of them.

What does it mean when you say "only one of them becomes a member of
the tree"? How does that happen? As I say above, remotely from the
RBridges with these two (or more) between them, I don't think you
should be able to tell that there is more than one connection. And if
you could, you shouldn't care whether one or the other is used or
traffic is split across them. The topology is still the same
regardless of which of these happens. And if you did care, there is no
place in the LSP to add tie breaking info.

And locally (that is, you are one of the two multiply connected
RBridges), it's should just a local choice how to send, and you should
have to be able to receive on any of the parallel links.

Apparently the problem you see is just with the Reverse Path
Forwarding Check at the receiving end of two or more parallel links
between the same pair of RBridges.

I responded above on that point by saying "You should accept TRILL
traffic on both connections and we should say that [in the protocol
specification] 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.)" Isn't that a satisfactory
answer? (Maybe I shouldn't have said "both" because there could be
more than two...) Why should the local RBridges be forced to tie break
and leave all but one of there parallel point-to-point links idle?

Thanks,
Donald