Jeff Pickering wrote:

Radia,

Just for clarification, when determining
"The campus-wide minimum MTU size chosen is the smallest size "S" 
reported in any LSP",
I am assuming you need to look all LSPs, not just "reachable via spf" 
ones. Correct?
What happens when S shrinks and there are already extant LSPs with 
size > old S?

Jeff

Yes, you'd have to look at all LSPs, look at the "S" contained in each 
one, and choose the smallest S
as the campus-wide S. (though with the minimum value of S set to be an 
architectural constant,
say 1470).

As for whether it's just "reachable via spf", I'd say yes, it should 
only be ones reachable via spf.
Otherwise, one bad LSP from an about-to-die router can make the rest of 
the campus have
to stick with a low value of S until that LSP times out.

As for already extant LSP fragments that are now bigger than S -- good 
question!

Obviously, the source of those LSPs
needs to reformat its LSP and flood the newer, smaller-fragmented LSP.

However, as to what to do with LSPs in your database before they get 
reflooded from the source -- I'd
say time them out. In DECnet we had something where one router R could 
decide to time out
some other router, R2's, LSP, by setting the time to zero and 
reflooding.
 But then I remember
some sort of controversy about that (perhaps worrying about the security 
of allowing someone
to do that, since there couldn't be a way of cryptographically 
preventing a malicious router
from prematurely timing out someone else's LSP if it has to be possible 
for a nonmalicious router
to legitimately time out someone else's LSP). Is that timing-out 
mechanism still in IS-IS?

But anyway, I don't have any strong opinions on what to do with LSP 
fragments of size > S
that already exist. Seems like the possibilities are:
a) silently discard them
b) "noisily" time them out (i.e., flood them with age 0)
c) use them as if they're OK

Radia
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

I can't think of any reason that IS-IS would preclude splitting on 
zillions of paths, and it wouldn't
affect any packet formats. It's just localized behavior, certainly as 
long as the paths are all
equal cost paths.

So it seems like all that's necessary is not to explicitly say that 
there is a limit to the number of choices
that an RBridge can choose.

And perhaps tweak the MIB not to explicitly preclude it as well.

I can't imagine why that limit was ever put in...I'm curious if anyone 
remembers what the reasoning was.
I don't remember it being there in DECnet.

Radia

Ian Cox wrote:

A lot of requests today are based around getting larger etherchannels
between switches to get more cross sectional bandwidth. If you use
etherchannels and TRILL ECMP together you have a way to build larger
connectivity between nodes.

Example

Max ECMP = 16 paths, etherchannel = 16 members, 256 total links

Question comes down to how much cross sectional bandwidth is enough?

Ian

Jeff Pickering wrote:

Both 10589 and RFC4444 specify a max for maximumPathsSplits of 32. In a
datacenter environment, I
am hearing requests for values much larger than this. Is there any point
in trying to modify this? We are
already doing non-standard 10589 stuff anyway. Just looking for feedback.

Jeff

------------------------------------------------------------------------

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

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

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

Ali Sajassi (sajassi) writes:

Regarding your comment that loop can happen as the result of one-way
connectivity via partitioned VLAN, AFAIK DRB selection is done over
designated VLAN and if that VLAN is partitioned, then the bridged
network is partitioned because this VLAN is expected to be reachable via
all the access ports. And if the bridged network is partitioned, the it
is O.K. to have a DRB for each of the partitions. So, where is the loop?

Suppose A and B are RBridges that are communicating over VLAN 1 as the
primary VLAN.  They're forwarding for VLANs 2, 3, and 4 as well.

Now suppose that VLAN 1 becomes partitioned.  Both can now become DRB.
They are still forwarding for those other VLANs, though, and this
potentially means we have two forwarders on the same VLAN, which leads
to fatal forwarding loops.

It's a problem that's specific to TRILL, because of the L2 work that
it does.  It's not something that would happen with an L3 protocol.

I was curious since several people have told me over the years (since 
DECnet)
that the top 6 bytes *have to*
be the system ID of the DR. I was wondering where that requirement came 
from, and whether it's just folklore, or whether
there is now anything in IS-IS that would break if the top 6 bytes of a 
LAN ID were not
equal to the system ID of the DR?

Note that this question really doesn't have much to do with closing on 
the details of the proposal in this thread...I just

am curious.
Radia Perlman wrote:

That would mean that TRILL IS-IS frames would look like:

outer Ethernet header:
  . SA (obvious)
  . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended 
recipient)
  . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos
      that need to be "sprayed")
  . new Ethertype = l2-IS-IS

*If* an IS-IS frame can ever be less than the Ethernet minimum of 60 
bytes, then there might be an issue here.

L3 IS-IS using the 802.3 header with a length field in place of an 
Ethernet type can tell from that length field the actual size of the 
frame before the sender padded it out to 60.

If TRILL IS-IS doesn't use the 802.3 length field then we'd need some 
other way to tell how large the frame was prior to padding to 60 bytes.

(Other protocols, like IP, which uses an Ethernet type have their own 
length field so they don't need the 802.3 length field. I don't know if 
IS-IS has its own length field or whether it relies on the 802.3 length 
field.)

    Erik
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

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