Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing

From: mike shand <[email-masked]>
Date: Fri, 01 May 2009 10:14:21 +0100

On 30/04/2009 Radia Perlman wrote:
> b) for information like the neighbor list that can be
> arbitrarily large, figure out a way of encoding it in the
> spirit of CSNPs, so that partial information can be included.
> For instance, CNSPs say "this CSNP refers to all the LSPs from
> IDs between x and y". We could do the same for the TRILL-Hellos,
> as in "this TRILL-Hello neighbor list includes all neighbors
>
> with IDs between x and y".
So how would this work? For the hellos do we still have to send both 
(all) fragments at the same rate in order to maintain the adjacencies? 
i.e. double the hello load? Or is it sufficient to update the holding 
time on the basis of receiving ANY fragment, even though it may not 
confirm two way connectivity with you becuase you are not mentioned in 
that fragment?

    Mike

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

---

From: James Carlson <[email-masked]>
Date: Fri, 1 May 2009 10:50:02 -0400

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.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 09:18:32 -0700

Re (see below)

Yes. You'd update the holding timer based on any fragment (not just the 
fragment in
which your ID appears). It's not that big a deal to have your ID appear 
in the neighbor
list less often, and assume that the state is the same as when you saw 
it last.

We could have an optional second TLV in the TRILL-Hello that says 
"recent changes", that could
list neighbors whose state has recently changed, and aren't in that
fragment's range, as long as there aren't very many of them.

Radia

---

From: James Carlson <[email-masked]>
Date: Fri, 1 May 2009 12:30:16 -0400

mike shand writes:
> </blockquote>
> So does this mean that all these hellos need to be sent on all the
> VLANs?<br>

Yes, we do need to send Hellos (of a sort) on all of the configured
VLANs.  The Hellos sent on those other VLANs need not include as much
information as the primary ones.

There's more about this in the TRILL specification.

---

From: mike shand <[email-masked]>
Date: Fri, 01 May 2009 17:21:11 +0100

James Carlson wrote:

VLANs?

Mike

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 10:08:26 -0700

Re: What VLANs are which things sent on:

As James Carlson says (below), there was a lot of controversy about 
which VLANs to send things on, with
one extreme being "send on all VLANs" and the other being "send only on 
a single VLAN", and
we finally worked out a compromise, and it's in the spec.

But to summarize:
The DRB "sprays" on lots of VLANs (the default being all the VLANs it is 
capable of
communicating on, but it can be configured to send on fewer). The only 
information
that needs to appear in the non-designated-VLAN TRILL-Hello is "ID, 
priority".

Non-DRB sends only on the designated VLAN, plus any VLANs for which it 
is appointed designated forwarder.

Not in the spec yet: MTU testing (probe, ack) would only be on the 
designated VLAN

**********
Now a refinement that would be useful to discuss:

While we're on the subject, one extra field that could make things even 
safer would
be a TLV for "this is the (ID, priority) of who I think is DRB". Let's 
say R1 should be DRB
based on (ID, priority).
I'd suggest that if R2 hears
R3's Hello on any VLAN (not necessarily the designated VLAN),
then R2 may transmit a TRILL-Hello to inform R3 about R1 (in case
for some reason R3 can't hear R1).
The other possible safety thing is what was in Digital's bridge spec, 
and I'm not sure whether it
made it into 802.1d, which is the "bad hello" mechanism. Translating 
that mechanism into TRILL, it would
be that if R1 is DRB, and keeps hearing R2 claiming to be DRB, then R1 
continues to try becoming DRB,
but stops forwarding traffic to/from the link.

I could imagine us either just ignoring these cases as too far-fetched 
to worry about, or incorporating
these extra safety features on the theory that loops are really really 
bad and it's not that big a deal
to do these things.

Radia

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 01 May 2009 10:25:35 -0700

Radia,

> but stops forwarding traffic to/from the link.
I'm happy if at least R1 stops forwarding traffic to/from the link,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 10:31:54 -0700

Re: two types of Hellos.

This is where a lot of people have misunderstood me. We are *not* 
proposing two types of Hellos.
Admittedly, that is what's in the latest version of the TRILL spec, but 
we are replacing that with some variant of
what I said on the list a couple days ago.

There will be no such thing as "protective Hellos". There is only a 
single type
of periodic message, which we'll call TRILL-Hellos.

There are also MTU probes, and MTU acks, but these are not periodic.

Radia

Ali Sajassi (sajassi) wrote:
> James,
>
> If we need to send "protective hello" on each VLAN in order to monitor
> the connectivity of that VLAN over .1Q bridged network as described in
> section 4.2.4.2, then so be it (although I think we can do it more
> efficiently as I will talk in next paragraph). However, this is not the
> point that I am driving at. If you need to have two types of TRILL
> hellos messages (e.g., neighbor discovery vs.. protective), then that's
> O.K.

---

From: mike shand <[email-masked]>
Date: Fri, 01 May 2009 18:41:27 +0100

On 01/05/2009 Radia Perlman wrote:
> be a TLV for "this is the (ID, priority) of who I think is DRB".
The LAN ID field in the IS-IS hello already tells you who the sender 
thinks is the DIS, but it doesn't include the priority. Instead it has 
the ID assigned by the DIS. Why would you want the priority?

    Mike

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 1 May 2009 10:20:19 -0700

James,

If we need to send "protective hello" on each VLAN in order to monitor
the connectivity of that VLAN over .1Q bridged network as described in
section 4.2.4.2, then so be it (although I think we can do it more
efficiently as I will talk in next paragraph). However, this is not the
point that I am driving at. If you need to have two types of TRILL
hellos messages (e.g., neighbor discovery vs.. protective), then that's
O.K. My point is that we should be able to use the same IS-IS hello
message with MTU padding for both because I don't think the frame size
can exceed 1522 bytes !! (please refer to my email on scenarios for
TRILL access/trunk ports regarding why it cannot exceed 1522).

Now regarding more efficient mechanism for sending TRILL hellos. Two
cases to consider:

1) .1Q network is running STP/RSTP: In this case, there is only a single
active topology in the .1Q network and we can have a single VLAN that
covers the entire active topology (e.g., VLAN 1). Then just monitoring
this VLAN will be sufficient - e.g., if this VLAN is partitioned, then
the network is partitioned and all the other VLANs are partitioned. In
other words, in this scenario, there is no need to send protective hello
messages (per VLAN).

2) .1Q network is running MSTP: In this case, there are several active
topologies (one per MSTI). So, in this case, we can just have a single
VLAN per MSTI that covers the entire active topology for that MSTI. If
there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only
need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the
number of MSTIs because we have this info from BPDU in root-collision
detection procedure.

Cheers,
Ali

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Friday, May 01, 2009 7:50 AM
> To: Ali Sajassi (sajassi)
> Cc: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing
> 
> > 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.
> 
> 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.
> 
> --

---

From: James Carlson <[email-masked]>
Date: Fri, 1 May 2009 14:08:05 -0400

> be a TLV for "this is the (ID, priority) of who I think is DRB". Let's 

That seems like a wise move to me.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 1 May 2009 14:09:40 -0400

Hi Ali,

On Thu, Apr 30, 2009 at 1:48 PM, Ali Sajassi (sajassi)
<[email-masked]> wrote:
>
> Hi Radia,
>
> Thanks for the description of the solution. It was very nice and
> concise. However, I'd like to get some clarification regarding the
> scenario(s) in which such solution is required.
>
> The original problem was that the IS-IS hello messages can get lost over
> 802.1Q (because of Eth frame size exceeding 1522 bytes) and thus
> resulting in multiple AFs selection and creating loop over 802.1Q
> network. This was unacceptable because TRILL was forming a loop over
> 802.1Q network with standard-sized frame of 1522. I can think of three
> scenarios that can be considered here:

The loop was of shorter native frames.

RBridge ports can implement 802.1AE or other protocols below the EISS
layer that insert additional tags, including future protocols not yet
devisee, so don't focus too sharply on some specific legnth.

> 1) 802.1Q network is only used to transport native Ethernet packets
> (e.g., Rbridge ports connected to 802.1Q network are configured as
> access ports only). In this scenario, no TRILL encapsulated packets are
> sent over the bridged network and thus IIHs that are sent over 802.1Q
> network should not be padded with any consideration for TRILL header
> overhead - e.g., IIHs needs only to get padded to 1500 bytes.
>
> In this scenario, since the padded IIHs adhere to 1500 byte-limit of
> 802.1Q network, there is no issue with IIHs getting dropped by the
> bridged network. The TRILL mechanism for DRB & AF selection and
> root-bridge collision detect should work just fine and there should be
> no transient loop created either in the bridged network or the TRILL
> network.

I don't know what you think you are implying by referring to the
bridged LAN between RBridges as "802.1Q network" but it can consist of
an abritrary mesh of arbitrarily configured repeaters, hubs, 802.1D,
and 802.1Q bridges of various vintages with various feature sets
variously configured and enabled/disabled.

You seem to be suggesting padding all the "hellos" but this makes no
sense to me. If they were guaranteed to get through, the padding was
useless waste of bandwidth. If they don't get through, you have
multiple appointed forwarders and your network can melt down. One
reason they might not get through with padding are RBridge ports
adding 802.1AE or other tags.

You cannot be safe with padded "hellos" on any port that can receive
or transmit native frames.

> 2) 802.1Q network is only used as transit network for TRILL encapsulated
> packets (e.g., Rbridge ports connected to 802.1Q network are configured
> as trunk ports only).  In this scenario, IIHs should get padded with
> consideration for TRILL header overhead in mind which means if the
> bridged network doesn't have support for bigger MTU, then these IIHs get
> dropped. However, dropping of these IIHs doesn't cause any harm since
> there is no access ports over this bridged network and all it means is
> that TRILL nodes don't see each other over the bridged network and thus
> they don't form adjacencies with each other. Since there is no access
> ports and there is no AFs (Appointed Forwarders), there will be no loop
> over this bridged network.

I believe you are correct. TRILL encapsulated frames are safe. It is
only native frames that are problematic. RBridge ports configured as
P2P could just use IS-IS P2P Hellos. And ports configured as trunk
ports could use padded padded "hellos" since the worst that would
happen is that you have fewer LSP adjacencies.

> 3) 802.1Q network can be used to transport both Native Ethernet packets
> and TRILL encapsulated packets (e.g., Rbridge ports connected to 802.1Q
> network are configured as both access and trunk ports). In this
> scenario, IIHs MTU size should default to the one for access port -
> e.g., without any consideration for TRILL header overhead. In other
> words, it should work just like scenario-1. In such scenario, no IIHs
> can get dropped over the 802.1Q network because the TRILL never pads
> them to more than 1500 bytes of payload.

For the reasons stated above, I disagree your description of the
arbitrary bridged LAN between RBridges as "the 802.1Q network" and I
do not believe your claim that no IS-IS Hellos can get dropped.

> So, in summary, I cannot see how a loop can be formed using
> standard-based 802.1Q frame size of 1522 based on the above three
> scenarios. If you have some other scenario(s) in mind, can you describe
> it or them. It should be noted that I am talking about standard 802.1Q
> frame size for the above scenarios (and not jumbo frame size based on
> 802.3as).

In summary, any system attempting to operate in range of conditions
that the current RBridge base protocol specificaiton addresses will be
unreliable if "hellos" are padded on any RBridge port that can
send/receive native frames.

> Ali

Thanks,
Donald

>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>> Sent: Wednesday, April 29, 2009 9:21 PM
>> To: [email-masked]
>> Subject: [rbridge] Proposed resolution of DRB election/MTU testing
>>
>> Moving to a new thread, since the "Why is MTU discovery
>> important" thread was getting too long (and the subject line
>> had nothing to do with most of the discussion).
>>
>> Hopefully we can quickly close the issue of DRB election/MTU
>> discovery.
>> And then finally close on the base protocol document...
>>
>> I was participating in an off-list
>> group of people discussing the issue, which was useful in
>> clarifying certain aspects.
>> I will summarize the proposed solution.
>>
>> First, refreshing people as to what the issue is:
>>
>> The problem: The Hello protocol in IS-IS may elect multiple
>> DRs, since routers ignore routers with whom they do not have
>> 2-way connectivity. Somewhat orthogonally, IS-IS LAN Hellos
>> are padded, to avoid forming adjacencies with neighbors that
>> you can't speak the minimum acceptable size with.
>>
>> This behavior is fine for layer 3, but not for layer 2, where
>> it will form loops if there are multiple DRBs.
>>
>> So ignoring this issue for TRILL is not an option.
>>
>>
>> ***********************
>> A bit of background on IS-IS
>>
>> IS-IS is modular, in that there are two sublayers, that in
>> DECnet we called the "subnetwork independent sublayer"
>> and the "subnetwork dependent sublayer". The subnetwork
>> dependent sublayer has neighbor adjacency forming protocols
>> for different types of links.
>>
>> What we are proposing for TRILL is support for a new type of
>> link within IS-IS's "link dependent sublayer". This is for
>> Ethernet links that are not explicitly pt-to-pt.
>>
>> What we need to accomplish with this protocol:
>>
>> a) elect exactly one DRB
>> b) figure out what the campus-wide minimum MTU size, "S", is
>> (to know what the minimum acceptable link MTU size is). LSP
>> fragment sizes must not be larger than this minimum
>> c) test neighbor-neighbor links to see if they support size S
>> d) remove links from the topology that do not support the
>> campus minimum size S
>>
>> *****************************
>>
>> Electing exactly one DRB
>>
>> This will be based on periodic messages, which we'll call
>> TRILL-Hellos, similar to IS-IS LAN Hellos, but they are
>> different in two aspects: they are not padded, and election
>> is based solely on (ID, priority), and not on whether
>> connectivity is 2-way. In other words, R2 defers to R1 if R1
>> has higher (ID, priority), whether or not there is 2-way
>> connectivity between R2 and R1.
>>
>> TRILL-Hellos must be periodic and frequent, so as to avoid
>> having RBs not know about each other. They will be sent on
>> the set of VLANs that the TRILL spec already says Hellos
>> would be sent on.
>>
>> TRILL-Hellos contain all the same information that the TRILL
>> spec already claims is in Hello messages. (other than the
>> difference that they won't be padded).
>>
>> So basically, the changes in the TRILL spec so far are
>> 1) rename Hello to "TRILL-Hello message"
>> 2) do not pad the message
>> 3) election will be based solely on the fields (ID, priority).
>>
>> Note: Although the neighbor list is included in a
>> TRILL-Hello, (as it is in an IS-IS LAN Hello), it does not
>> affect selection of DRB.
>> But the neighbor list still needs to be there for all the
>> RBridges to know which neighbors they have 2-way connectivity
>> with, for the purpose of reporting links in LSPs.
>>
>> *******************************
>>
>> figuring out what the campus-wide minimum MTU size is:
>>
>> This will be done based on a TLV in LSPs (which already
>> exists in IS-IS -- the originatingLSPBufferSize, TLV 14).
>> If that TLV is absent,
>> it is the same as requesting "1470". The campus-wide minimum
>> MTU size chosen is the smallest size "S" reported in any LSP.
>>
>> LSP fragments must not be bigger than S, and links that
>> cannot support S will not appear in the topology (meaning,
>> they will not be reported in LSPs)
>>
>>
>> ***************************************************
>> testing neighbor-neighbor links to ensure they support "S".
>>
>> We will have new messages: MTU probe, and MTU ack. Both are
>> padded to size S.
>>
>> It will be optional whether and when to send an MTU probe,
>> but mandatory to send an ack in response to receipt of an MTU
>> probe. The ack is padded to the same size that the probe was
>> padded to, and is unicast to the RBridge from which the probe
>> was received. Probes may be unicast or multicast. They may be
>> sent periodically (but far less frequently than DRB election
>> messages). Or they might be sent only in response to an event
>> such as hearing from a new neighbor RBridge. Both MTU probes
>> and acks are sent only on the Designated VLAN.
>>
>> If R1 fails to get an ack from R2, R1 still reports R2 in its
>> neighbor list, but with a flag saying "failed minimum MTU test".
>>
>>
>>
>> ****************
>> Links that are not 2-way for any reason, including not
>> supporting the minimum campus-wide MTU S, are not reported in LSPs.
>>
>> That means that if R1 is DRB, and it does not have 2-way
>> connectivity to R2, R1 does not list R2 as a neighbor, in the
>> pseudonode LSP.
>> R2 does not report a link to the pseudonode.
>>
>> If neither R2 nor R3 are DRB, they both have 2-way
>> connectivity to the DRB, but not to each other, then they do
>> both report connectivity to the pseuodnode. However, if R2
>> receives a packet that needs to be forwarded to R3 across
>> that link, R2 sends the packet to the DRB instead. (Note:
>> This behavior is already specified in IS-IS)
>>
>> *******************
>> Concern was raised about the size of TRILL-hellos. Might they
>> wind up being too big to fit? This concern would apply
>> whether Hellos are padded or not.
>>
>> For instance, one topology
>> people envision is a core that connects hundreds of customer
>> sites into a giant Ethernet. The technology that creates the
>> core is irrelevant to TRILL, other than having Ethernet-like
>> characteristics, in terms of being multiaccess and supporting
>> multicast.
>>
>> In that case, if the customer's Ethernet is running TRILL,
>> the core would appear to TRILL to be a giant Ethernet with
>> hundreds of neighbors. In other words, all the hundreds of
>> RBridges connected to the core would see all of the other
>> RBridges on the core as neighbors on this "link".
>>
>> IS-IS has carefully designed packet formats for LSPs and
>> CSNPs, so that they can be arbitrarily large, transmitted in
>> pieces, with each piece being able to be independently
>> processed. For some reason though we didn't design Hellos
>> that way. We should take the opportunity to design
>> TRILL-Hello messages with that effect.
>>
>> There are some things in TRILL-Hellos that don't really need
>> to be reported frequently (like which VLANs you support). And
>> some things (like the neighbor list) that might wind up being
>> too large to fit into a single packet.
>>
>> Other information (such as ID and priority) really should go
>> in every TRILL-Hello.
>>
>> I'd suggest we do two things in the encoding of TRILL-Hellos
>>
>> a) figure out which fields can be left out some of the time,
>> and specify that those fields, if absent, just mean they are
>> absent, not, for instance, that you don't support any VLANs.
>>
>> For instance, CNSPs say "this CSNP refers to all the LSPs
>> from IDs between x and y". We could do the same for the
>> TRILL-Hellos, as in "this TRILL-Hello neighbor list includes
>> all neighbors with IDs between x and y".
>>
>> ***********************************
>>
>> Radia
>>
>>
>>
>>
>>
>>

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 11:43:55 -0700

Re: Mike Shand asking if we really need to say "I think the DRB's ID and 
priority is x,y", given that
the IS-IS Hello contains the LAN ID.

You really need priority too, otherwise, if R3 hears that R2 thinks that 
R1.17 is the LAN ID (aka "pseudonode ID"),
R3 has no way of whether R1 should be higher priority or not.

And I'm not sure we need to have anyone other than the DRB put in the 
LAN ID into
their TRILL-Hello. What purpose does it serve?

And as for whether R1's address is embedded in the LAN ID:
I'd always intended that the LAN ID (the "pseudonode ID") could be any 7 
byte quantity that is guaranteed to
be campus-wide unique. A good way of choosing the LAN ID, if you are 
"R1", is to make the LAN ID
"R1" followed by a byte to distinguish between up to 255 other links R1 
might be DR on. But
really, it just needs to be a unique 7 byte quantity (with 7th byte 
nonzero). Somehow it seemed to morph over the years
into the top 6 bytes MUST be the system ID of the DR, right? Is there 
anything that depends on those
6 bytes being the system ID of the DR, or is it just folklore that it 
has to be the system ID of the DR?

Radia

mike shand wrote:
>> While we're on the subject, one extra field that could make things 
>> even safer would
>>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 1 May 2009 14:52:20 -0400

The set of VLANs on which Hellos need to sent is specified in Section
4.2.4.2 "Hello VLAN Tagging", pages 34-36 of
http://tools.ietf.org/id/draft-ietf-trill-rbridge-protocol-12.txt

A sketch of a proof that that is a sufficient set of VLANs appears in
Section 4 "No Persistent Loops", starting page 11 of
http://tools.ietf.org/id/draft-eastlake-trill-rbridge-notes-01.txt

Thanks,
Donald

On Fri, May 1, 2009 at 12:21 PM, mike shand <[email-masked]> wrote:
> So does this mean that all these hellos need to be sent on all the VLANs?
>
>     Mike
>
>
>
>
>

---

From: James Carlson <[email-masked]>
Date: Fri, 1 May 2009 14:40:12 -0400

> hellos messages (e.g., neighbor discovery vs.. protective), then that's

As Radia said, we're evolving this, but, yes, that's essentially true.

> TRILL access/trunk ports regarding why it cannot exceed 1522).

Even if you don't exceed 1522, there can be problems.  I observed
problems with old gear in our lab that didn't support anything over
1500.  There's no guaranteed-good magic number near or above 1500 that
I know about that could possibly be used here.

That's part of the point.  Specifications are nice to have, and it's
wonderful that someone is out there 'demanding' that everyone support
at least 1522 octets in a message, but none of that actually forces
this to be true.  There are no specification police who will round up
old gear and ship it to a detention facility.

Thus, either we merely assert that certain minimums are required, and
allow the system to fail miserably (and catastrophically) when
confronted with something that's slightly out of spec *OR* we make the
protocols protective of unknown conditions in a harsh world.

I would like to see us opt for the latter.  It's my experience that
specification alone doesn't make it so.

> covers the entire active topology (e.g., VLAN 1). Then just monitoring

That's correct.  We could.  Doing so would demand that customers run
their networks in a particular way to suit our application.  Customers
would be required to configure some particular VLAN to cover the
entire L2 topology.

I'd certainly like to see that happen.  It'd be a great
simplification.  However, if you read through the list archives,
you'll see that a substantial majority of the working group believes
that forcing our collective will onto existing networks where people
are expected to deploy RBridges will not in fact work.

Instead, they won't deploy.  And that'd be a problem.

An equivalent alternative to this single-global-VLAN proposal is to
require that all RBridges in a given L2 area be interconnected either
by direct links or by repeaters alone, with no intervening bridges.
Any STP-type bridges that exist must be on the outside of the RBridge
cloud.

That also solves the problem and is sufficient, but greatly
constrains the deployment scenarios, particularly in the case where
there's a backbone bridged network.

> number of MSTIs because we have this info from BPDU in root-collision

MSTP is unclear to me.  I *think* all we really need to know is the
core instance bridge ID ... but I could certainly be wrong.  I haven't
seen MSTP in use anywhere, and I have no code that supports it.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 May 2009 12:15:37 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Friday, May 01, 2009 11:44 AM
> To: [email-masked]

R3 would know this from the hellos it receives from R1.17.
Or are you suggesting that R3 should take R2's word for it and override
it's own internal logic as to who should be DRB even if it had not heard
from R1? 
(I certainly hope not...)

> their TRILL-Hello. What purpose does it serve?

It serves as confirmation that all ISs have converged on their selection
of the DIS/DRB and that each IS has correctly obtained the pseudo-node
ID as selected/transmitted by the winner of the election. This is useful
in debugging operational problems.

> has to be the system ID of the DR?

The system ID is required to have exactly those properties i.e. it is
required to be unique area wide at Level 1 and unique domain wide at
Level 2. This is obviously necessary so as not to confuse the LSPs
generated by two different systems.

   Les

---

From: James Carlson <[email-masked]>
Date: Fri, 1 May 2009 15:27:40 -0400

> has to be the system ID of the DR?

I think it's the latter.  I seem to recall implementations with very
large numbers of links that used system ID for the first 255 and then
had reserved IDs for the remainder.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 May 2009 11:43:08 -0700

On
> Behalf Of Radia Perlman
> Sent: Friday, May 01, 2009 9:19 AM
> To: Mike Shand (mshand)
> Cc: [email-masked]

Hmmm...so if once I have confirmed two connectivity to neighbor A and I
then update my hold timer whenever I receive a Hello from Neighbor A
regardless of whether I am mentioned in the neighbor list included in
the IIH, then when do I determine that two way connectivity is lost?

You can't cheat on this. If the full set of neighbors are not being sent
every time then you either have to:

Lengthen the hold time for each neighbor so that we can continue to send
hellos at the same rate. The down side of this is longer failure
detection time.

or

Send hellos faster so that each neighbor is mentioned at least once per
hello interval. The downside of this is increased hello overhead.

> fragment's range, as long as there aren't very many of them.

I don't know that you need a second TLV, but I do think you would want
to include a new neighbor in the hello every time during the adjacency
bringup period in order to facilitate the establishment of the two way
adjacency. Of course if two way connectivity is not established after
some period of time then I suppose you would want to make room for other
neighbors - which suggests that the SNP-like range identifier for
neighbors in hellos may not be the solution.

But, before working out all of these details, I would ask whether we
believe the exhaustion of space in hellos is really going to be caused
by having a large number of neighbors? The notion of having one
campus-wide LAN would require a very large number of neighbors on each
Rbridge and a very large number of hellos being sent campus-wide. This
is not the best design for a robust network.

There are, of course, other things (supported VLANs for instance) which
TRILL requires which might cause hellos to exceed their capacity.

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 1 May 2009 14:42:59 -0400

Hi Ali,

> is O.K. to have a DRB for each of the partitions. So, where is the loop?

The DRB selection has to be done on more than "designated VLAN". What
is the "designated VLAN" if all the N different RBridges with ports
connected to an arbitrary bridged LAN are configured to want a
different designated VLAN? The answer is that the DRB gets to dictate
the designated VLAN.

Exactly what VLANs which RBridges need to send "hellos" on was are
area that the TRILL working group considered quite carefully. The set
of VLANs specified in the current draft for protective hellos (which
is the set of VLANs the one new "TRILL Hello" Radia suggested would be
sent on) was the result. While you could send "hellos" on even more
VLANs, a sketch of a proof that the set of VLANs specified in the
current draft is safe is given in Section 4 of
draft-eastlake-trill-rbridge-notes-01.txt (this is not a WG draft and
has not been updated for the latest base protocol specification).

> Besides, how does a partitioned VLAN result in a one-way connectivity
> (in bridged network, it should result in a two-way disconnectivity).

I'm not sure exactly what Radia meant but, as far as I know, if you
don't turn on bridge VLAN ingress filtering, it is quite easy to
configure a bridge port so that it acts as a VLAN diode, letting
frames through one way and not the other for a particular VLAN or
VLANs. The design of the protective hello mechanism in the current
draft allows for arbitrary VLAN diodes in the arbitrary bridged LAN
interconnecting a set of RBridges.

> I have no desire to prolong this discussion; however, I am not clear of
> the failure scenarios that warrant the modifications to IS-IS and I
> would very much prefer to keep the things simple and don't modify IS-IS
> if we don't have to. I agree with you that the proposed solution is more
> flexible, I just don't see where and why such flexibility is needed. So,
> under which of the following the loop is expected:

There is a potential loop in TRILL whenever you have two RBridges
ports, A and B, such that A can emit a native frame in VLAN x that
will get to B but when A sends a hello in VLAN x, it does not get to
B.

> A) loss of connectivity over .1Q bridged network that supports standard
> 1522 bytes frame size: I listed all the scenarios that I could think of
> in my previous email (e.g., different combinations of access and trunk
> ports) and showed that we won't have loops in any of those scenarios.

In my response, I explained why I did not find your message persuasive.

> B) loss of connectivity over .1Q bridged network that doesn't support
> 1522 byte frame size (e.g., it only supports 1100 bytes). Is that the
> scenario of interest ? If so, then this cannot happen because by
> definition a .1Q network MUST support frame size of 1522 bytes. If it
> doesn't support standard frame size, then loop can happen within that
> .1Q network itself that runs MSTP.

While I agree that it is reasonable to assume support of some minimal
message size, there is no assumption that the arbitrary bridged LAN
connecting RBridges is "a .1Q network".

> C) loss of connectivity over .1Q bridge network because of one-way
> connectivity - e.g., partitioned VLAN. This is what you mentioned in
> this email and the question is how partition of designated VLAN will
> result in loop. And how a one-way connectivity can happen in a bridged
> network because if that can happen, then there will be a loop within the
> bridged network that runs MSTP.

It's not TRILL's problem whether or not bridges in the arbitrary
bridge LAN between RBridges support MSTP or whether or not MSTP works
when bridge ports are configured as VLAN diodes. I see no purpose in
discussing this here.

Thanks,
Donald

> So, I would appreciate if anyone can clearly describe a scenario in
> which a loop can be created by TRILL over a bridge network.
>
> Regards,
> Ali
>
>
>
>
>> Sent: Thursday, April 30, 2009 3:08 PM
>> To: [email-masked]
>> Re: Ali Sajassi's question about how loops could form:
>>
>> To simplify, with any sort of one-way connectivity, the
>> current IS-IS LAN Hello protocol says to ignore (for purpose
>> of DR election) any router with which you don't have 2-way
>> connectivity.
>>
>> One-way connectivity can happen due to lots of reasons -- not
>> just MTU.
>> For example,
>> because of partitioned VLANs.
>>
>> So therefore, it's pretty clear that if you want only a
>> single DRB, you need to defer to anyone you hear from (or
>> about) with better (ID, priority).
>>
>> And separating out the MTU testing into a separate, optional,
>> very infrequent protocol allows flexibility that might be
>> very useful in data centers (actually measuring the MTU, not
>> just saying yes/no). Plus if padded hellos are guaranteed to
>> get through, you don't need to pad them. And if padding them
>> might cause them not to get through, then you'll get loops.
>>
>> Radia
>>
>>
>>
>>
>>  (sajassi) wrote:
>> > Hi Radia,
>> >
>> > The original problem was that the IS-IS hello messages can get lost
>> > over 802.1Q (because of Eth frame size exceeding 1522
>> bytes) and thus
>> > access ports only). In this scenario, no TRILL encapsulated packets
>> > are sent over the bridged network and thus IIHs that are sent over
>> > 802.1Q network should not be padded with any consideration
>> for TRILL
>> > header overhead - e.g., IIHs needs only to get padded to 1500 bytes.
>> >
>> > 2) 802.1Q network is only used as transit network for TRILL
>> > encapsulated packets (e.g., Rbridge ports connected to
>> 802.1Q network
>> > are configured as trunk ports only).  In this scenario, IIHs should
>> > get padded with consideration for TRILL header overhead in
>> mind which
>> > means if the bridged network doesn't have support for
>> bigger MTU, then
>> > these IIHs get dropped. However, dropping of these IIHs
>> doesn't cause
>> > any harm since there is no access ports over this bridged
>> network and
>> > all it means is that TRILL nodes don't see each other over
>> the bridged
>> > network and thus they don't form adjacencies with each other. Since
>> > there is no access ports and there is no AFs (Appointed
>> Forwarders),
>> > there will be no loop over this bridged network.
>> >
>> > 3) 802.1Q network can be used to transport both Native Ethernet
>> > packets and TRILL encapsulated packets (e.g., Rbridge ports
>> connected
>> > to 802.1Q network are configured as both access and trunk
>> ports). In
>> > this scenario, IIHs MTU size should default to the one for
>> access port
>> > - e.g., without any consideration for TRILL header
>> overhead. In other
>> > scenarios. If you have some other scenario(s) in mind, can you
>> > describe it or them. It should be noted that I am talking about
>> > standard 802.1Q frame size for the above scenarios (and not jumbo
>> > frame size based on 802.3as).
>> >
>> > Cheers,
>> > Ali
>> >
>> >
>> >
>> >
>> >> Moving to a new thread, since the "Why is MTU discovery important"
>> >> thread was getting too long (and the subject line had
>> nothing to do
>> >> with most of the discussion).
>> >>
>> >> The problem: The Hello protocol in IS-IS may elect multiple DRs,
>> >> since routers ignore routers with whom they do not have 2-way
>> >> connectivity. Somewhat orthogonally, IS-IS LAN Hellos are
>> padded, to
>> >> avoid forming adjacencies with neighbors that you can't speak the
>> >> minimum acceptable size with.
>> >>
>> >> This behavior is fine for layer 3, but not for layer 2,
>> where it will
>> >> form loops if there are multiple DRBs.
>> >>
>> DECnet we
>> >> called the "subnetwork independent sublayer"
>> >> and the "subnetwork dependent sublayer". The subnetwork dependent
>> >> sublayer has neighbor adjacency forming protocols for
>> different types
>> >> of links.
>> >>
>> >> What we are proposing for TRILL is support for a new type of link
>> >> within IS-IS's "link dependent sublayer". This is for
>> Ethernet links
>> >> b) figure out what the campus-wide minimum MTU size, "S",
>> is (to know
>> >> what the minimum acceptable link MTU size is). LSP fragment sizes
>> >> must not be larger than this minimum
>> >> d) remove links from the topology that do not support the campus
>> >> minimum size S
>> >>
>> different in
>> >> two aspects: they are not padded, and election is based solely on
>> >> (ID, priority), and not on whether connectivity is 2-way. In other
>> >> words, R2 defers to R1 if R1 has higher (ID, priority), whether or
>> >> not there is 2-way connectivity between R2 and R1.
>> >>
>> having RBs
>> >> not know about each other. They will be sent on the set of
>> VLANs that
>> >> the TRILL spec already says Hellos would be sent on.
>> >>
>> >> TRILL-Hellos contain all the same information that the TRILL spec
>> >> already claims is in Hello messages. (other than the
>> difference that
>> >> they won't be padded).
>> >>
>> TRILL-Hello, (as it
>> >> is in an IS-IS LAN Hello), it does not affect selection of DRB.
>> RBridges to
>> >> know which neighbors they have 2-way connectivity with, for the
>> >> purpose of reporting links in LSPs.
>> >>
>> >> This will be done based on a TLV in LSPs (which already exists in
>> >> IS-IS -- the originatingLSPBufferSize, TLV 14).
>> >> If that TLV is absent,
>> >> it is the same as requesting "1470". The campus-wide
>> minimum MTU size
>> >> chosen is the smallest size "S" reported in any LSP.
>> >>
>> >> LSP fragments must not be bigger than S, and links that cannot
>> >> support S will not appear in the topology (meaning, they
>> will not be
>> >> reported in LSPs)
>> >>
>> >>
>> >> We will have new messages: MTU probe, and MTU ack. Both
>> are padded to
>> >> size S.
>> >>
>> >> It will be optional whether and when to send an MTU probe, but
>> >> mandatory to send an ack in response to receipt of an MTU
>> probe. The
>> >> ack is padded to the same size that the probe was padded
>> to, and is
>> >> unicast to the RBridge from which the probe was received.
>> Probes may
>> >> be unicast or multicast. They may be sent periodically
>> (but far less
>> >> frequently than DRB election messages). Or they might be
>> sent only in
>> >> response to an event such as hearing from a new neighbor RBridge.
>> >> Both MTU probes and acks are sent only on the Designated VLAN.
>> >>
>> supporting the
>> >> minimum campus-wide MTU S, are not reported in LSPs.
>> >>
>> connectivity
>> >> to R2, R1 does not list R2 as a neighbor, in the pseudonode LSP.
>> >> If neither R2 nor R3 are DRB, they both have 2-way connectivity to
>> >> the DRB, but not to each other, then they do both report
>> connectivity
>> >> to the pseuodnode. However, if R2 receives a packet that
>> needs to be
>> >> forwarded to R3 across that link, R2 sends the packet to the DRB
>> >> instead. (Note:
>> >> Concern was raised about the size of TRILL-hellos. Might
>> they wind up
>> >> being too big to fit? This concern would apply whether Hellos are
>> >> padded or not.
>> >>
>> >> people envision is a core that connects hundreds of customer sites
>> >> into a giant Ethernet. The technology that creates the core is
>> >> irrelevant to TRILL, other than having Ethernet-like
>> characteristics,
>> >> in terms of being multiaccess and supporting multicast.
>> >>
>> the core
>> >> would appear to TRILL to be a giant Ethernet with hundreds of
>> >> neighbors. In other words, all the hundreds of RBridges
>> connected to
>> >> the core would see all of the other RBridges on the core
>> as neighbors
>> >> on this "link".
>> >>
>> >> IS-IS has carefully designed packet formats for LSPs and CSNPs, so
>> >> that they can be arbitrarily large, transmitted in pieces,
>> with each
>> >> piece being able to be independently processed. For some reason
>> >> though we didn't design Hellos that way. We should take the
>> >> opportunity to design TRILL-Hello messages with that effect.
>> >>
>> >> There are some things in TRILL-Hellos that don't really need to be
>> >> reported frequently (like which VLANs you support). And
>> some things
>> >> (like the neighbor list) that might wind up being too large to fit
>> >> into a single packet.
>> >>
>> >> Other information (such as ID and priority) really should
>> go in every
>> >> TRILL-Hello.
>> >>
>> >> a) figure out which fields can be left out some of the time, and
>> >> specify that those fields, if absent, just mean they are
>> absent, not,
>> >> for instance, that you don't support any VLANs.
>> >>
>> >> b) for information like the neighbor list that can be arbitrarily
>> >> large, figure out a way of encoding it in the spirit of CSNPs, so
>> >> that partial information can be included.
>> >> For instance, CNSPs say "this CSNP refers to all the LSPs from IDs
>> >> between x and y". We could do the same for the TRILL-Hellos, as in
>> >> "this TRILL-Hello neighbor list includes all neighbors with IDs
>> >> between x and y".
>> >>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 12:40:20 -0700

> (I certainly hope not...)
R3 would not necessarily hear R1's TRILL-Hellos, so this is for the case
where R3 can hear R2 and R1, but R3 can't hear R1.
So yes, I was saying that we could have R2 tell R3 about R1.
I didn't put that into the original proposal -- it's an additional 
safety mechanism, and what I hinted
about when I said "R3 defers to any RBridge with higher ID and priority 
that R3 hears from or about".

I don't feel strongly about this. There's trivial overhead to including 
the field in the TRILL-Hello.
> generated by two different systems.
Of course the system ID has to be consistent and unique. I was talking 
about the LAN ID.
There's no reason why R1 couldn't name a pseudonode any 7 byte quantity 
that had
nonzero 7th byte, and top 6 bytes guaranteed not to be used by anyone 
else. So for instance,
if R1 had MAC addresses R1a, R1b, R1c, ... on each of its links, and 
chose R1a as its
system ID, there wasn't anything in the design of DECnet/IS-IS that 
depended on R1 choosing
all its LAN ID's with top 6 bytes = R1a. Given that R1 "owns" MAC 
addresses R1b and R1c as well,
it certainly could give LAN IDs of R1b.15 to one of its links, and 
R1c.12 to another,
and R1a.15 to a third. Just so long as the 7 byte quantity is guaranteed 
unique within the campus.

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

---

From: Jim Burrows <[email-masked]>
Date: Fri, 1 May 2009 15:45:46 -0400

> is not the best design for a robust network.

My answer is "absolutely... eventually".

Remember that we're not merely designing to "make the protocols protective
of unknown conditions in a harsh world" of today as James said, but for the
harsh world of tomorrow, as well. There were discussions that I had 30+
years ago where people dismissed my concerns by telling me how much trouble
it was to tap an Ethernet cable with a big heavy physical tap that drove a
spike into the cable, and the "if they have physical access to your cable,
you're doomed anyway", that come back to haunt us today as essentially the
same protocol is used wirelessly. TRILL is trying to address shortcomings in
the spanning tree design that is 25 years old. Inevitably, something we
don't think of will cause a problem of the scope of the Beth Israel
Deaconess crash, but it would be really good for us to postpone that as far
into the future as possible.

There are pretty plausible scenarios that suggest ways in which the number
of neighbors can readily be huge, so I think we need to assume that we'll
have to deal wit them.

JimB.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 1 May 2009 15:38:37 -0400

Hi Ali,

> TRILL access/trunk ports regarding why it cannot exceed 1522).

If the padded hellos would always get through, the padding did not
good. If the padded hellos would not get through, your network melts
down. Thus, padding hellos sent from ports that can send/receive
native frames is useless.

See my previous email on why I don't currently accept your assertions
about 1522.

> other words, in this scenario, there is no need to send protective hello

I continue to think it is misleading to call the arbitrary mesh of an
arbitrary combination of repeaters, hubs, 802.1D, and 802.1Q bridges
of various vintages with various features enabled/disabled and
variously configured "the .1Q network". Any VLAN or set of VLANs
within this arbitrary bridged LAN which interconnects an arbitrary
number of RBridge ports may be partitioned or may provide only one-way
connectivity. And, in fact, whether they are partitioned and/or
provide only one-way connectivity can be different for every pair of
RBridge ports connected by this arbitrary bridged LAN.

Layer 2 loops are so bad that the TRILL WG has decided it needs to do
what it can to defend again configurations (even what some would call
"mis-configurations") within arbitrary bridged LAN connecting RBridge
ports.

> number of MSTIs because we have this info from BPDU in root-collision

As per my comment above for each of the "active topologies".

In addition, it seems like a bad idea for TRILL to depend on
intricacies of the more elaborate recent 802.1 BPDUs. As far as I
know, 802.1 is continuing to extend and create new forms of BPDUs and
I certainly think that fundamental features of the TRILL protocol such
as loop safety should not depend on necessarily tracking all this and
continually modifying TRILL to take it into account.

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 May 2009 13:06:36 -0700

> From: Radia Perlman [mailto:[email-masked]]
> Sent: Friday, May 01, 2009 12:40 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]

Hmmm...too many R1s in that sentence. Did you mean R3 can hear R2 (but
not R1) while all other interactions are fully transitive?

> that R3 hears from or about".

Please present a state machine which defines how DRB election should
occur on R3 based upon the information R3 receives directly (i.e. ID,
priority it receives directly from the originating ISs) and information
R3 receives indirectly (i.e. ID, priority it receives from an IS other
than the source ID). Please include a description of how this resolves
ambiguous advertisements.

> unique within the campus.

Given that the LANID is also used as the pseudo-node ID in the
pseudo-node LSPs generated for that LAN (and the IS neighbor
advertisements in the non-pseudo-node LSPs), the selection would have to
meet the same constraints as are placed on the systemID. So, yes - one
could use two different MAC addresses as the first 6 octets of the LANID
for two different circuits on which an IS is the DIS so long as both MAC
addresses meet the systemid constraints - but why would you? It
certainly would be more confusing to debug as the pseudo-node IDs would
no longer have any obvious connection to the systemID of the system
which generated them.

   Les

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 May 2009 14:54:36 -0700

Re: Les Ginsberg asking about how R2 would notice R1 stopped hearing 
R2's Hellos if R2 wasn't
in every TRILL-Hello.

This is the same principle as the IS-IS CSNP encoding. The TRILL Hello 
would say:
"This neighbor list is for neighbors between x and y".
That means if your ID is < x or > y, then you don't look for yourself in 
(this) Hello.
If your ID is between x and y, then it is relevant if you appear there 
or not.
(And as Jim said, we need flags for saying whether x is the smallest ID, 
and y is the largest
ID, but that's a detail...)

Nbr list fragmentation does mean that if the neighbor list is fragmented 
into 4 pieces,
that it would take R2 4 times as long to notice whether R1 can hear its 
Hellos, or
that R1 stopped hearing its Hellos. So R1 has to adjust the holding timer
based on how often each neighbor appears explicitly in a fragment.

If we're worried about that (which I don't think we should be), we can 
either have
the DRB send TRILL-Hellos on the Designated VLAN k times as often, if the
neighbor list was in k fragments, or have the extra TLV that I was 
mentioning with
the "recent changes".

It's also somewhat important for non-DRBs R2 and R3 to know if they have 
connectivity
to each other (if they don't, they need to forward to each other through 
the DRB), but
this would be a rare enough case that if we lost data for awhile before 
noticing it,
because R2's neighbor list is fragmented, I wouldn't think it important 
enough to worry about.
It's just data that gets dropped -- no loops or anything.

So at most I think we might want to recommend that the DRB transmit 
fragmented
TRILL-Hellos more frequently, but I think even that is not that important.

Radia

---

From: sgai <[email-masked]>
Date: Mon, 04 May 2009 06:17:10 -0700

Sorry to be late on replying to this thread,
I support Radia's proposal

-- Silvano

On 4/29/09 9:21 PM, "Radia Perlman" <[email-masked]> wrote:

> Moving to a new thread, since the "Why is MTU discovery important" thread
> was getting too long (and the subject line had nothing to do with most
> of the discussion).
> 
> Hopefully we can quickly close the issue of DRB election/MTU discovery.
> group of people discussing the issue, which was useful in clarifying
> certain aspects.
> 2-way connectivity. Somewhat orthogonally, IS-IS LAN
> Hellos are padded, to avoid forming adjacencies with neighbors
> that you can't speak the minimum acceptable size with.
> 
> IS-IS is modular, in that there are two sublayers, that
> in DECnet we called the "subnetwork independent sublayer"
> What we are proposing for TRILL is support for a new type
> of link within IS-IS's "link dependent sublayer". This
> is for Ethernet links that are not explicitly pt-to-pt.
> 
> b) figure out what the campus-wide minimum MTU size, "S", is (to know
> what the minimum acceptable link MTU size is). LSP fragment
> sizes must not be larger than this minimum
> This will be based on periodic messages, which we'll
> call TRILL-Hellos, similar to IS-IS
> LAN Hellos, but they are different in two aspects: they are
> not padded, and election is based solely on (ID, priority), and
> not on whether connectivity is 2-way. In other words, R2
> defers to R1 if R1 has higher (ID, priority), whether or
> TRILL-Hellos must be periodic and frequent, so as
> to avoid having RBs not know about each other. They will be
> sent on the set of VLANs that the TRILL spec already says Hellos
> would be sent on.
> 
> TRILL-Hellos contain all the same information
> that the TRILL spec already claims is in Hello messages. (other
> than the difference that they won't be padded).
> 
> Note: Although the neighbor list is included in a TRILL-Hello, (as it is in
> an IS-IS LAN Hello), it does not affect selection of DRB.
> But the neighbor list still needs to be there
> for all the RBridges to
> it is the same as requesting "1470". The campus-wide minimum MTU size
> support S will not appear in the topology (meaning, they will not
> be reported in LSPs)
> 
> 
> are padded to size S.
> It will be optional whether and when to send an MTU
> probe, but mandatory to send an ack in response to receipt
> of an MTU probe. The ack is padded to the same size that the
> probe was padded to, and is unicast to the RBridge from
> which the probe was received. Probes may be unicast or
> multicast. They may be sent periodically (but far less
> sent only in response to an event such as hearing from
> a new neighbor RBridge. Both MTU probes and acks are
> sent only on the Designated VLAN.
> 
> If R1 fails to get an ack from R2, R1 still reports R2 in
> its neighbor list, but with a flag saying "failed minimum MTU test".
> 
> 
> 
> ****************
> That means that if R1 is DRB, and it does not have 2-way connectivity
> connectivity to the pseuodnode. However, if R2 receives
> a packet that needs to be forwarded to R3 across that link, R2
> sends the packet to the DRB instead. (Note: This behavior is
> already specified in IS-IS)
> 
> *******************
> Concern was raised about the size of TRILL-hellos. Might they wind up being
> too big to fit? This concern would apply whether Hellos are padded
> or not.
> 
> irrelevant to TRILL, other than having Ethernet-like characteristics, in
> terms of being multiaccess and supporting multicast.
> 
> In that case, if the customer's Ethernet
> is running TRILL, the core would appear to TRILL to be a giant Ethernet with
> hundreds of neighbors. In other words, all the hundreds of RBridges
> connected to the core would see all of the other RBridges on the core
> as neighbors on this "link".
> 
> that they can be arbitrarily large, transmitted in pieces, with each
> There are some things in TRILL-Hellos that don't really need to
> be reported frequently (like which VLANs you support). And some things
> Other information (such as ID and priority) really should go in every
> TRILL-Hello.
> 
> and specify that those fields, if absent, just mean they
> are absent, not, for instance, that you don't support any VLANs.
>

---

From: mike shand <[email-masked]>
Date: Tue, 05 May 2009 13:39:07 +0100

> their TRILL-Hello. What purpose does it serve?
It doesn't serve any purpose in the protocol (although I seem to 
remember you did originally have some idea of performing a consistancy 
check on this). But it is really useful for debugging weird problems by 
looking at what is on the wire, rather than having to rely on what may 
or may not be accurately reported in various routers' management interfaces.

    Mike

---

From: mike shand <[email-masked]>
Date: Tue, 05 May 2009 13:33:55 +0100

am curious.

Its not folk law. The spec does say

"The pseudonode shall be identified by the sourceID of the Designated
Intermediate system, followed by a non-zero pseudonodeID assigned by
the Designated Intermediate system. The pseudonodeID is locally unique
to the Designated Intermediate system."

and

"If this system, as a result of the Designated Intermediate System
election process, considers itself to be designated Intermediate
System, the LAN ID field shall be set to the concatena\tion of this
system’s own system ID and the locally assigned one octet Local Circuit
ID."

and in the part about checking LSPs it says

"c)If the source S of the LSP is an IS or pseudonode for which all but
the last octet are equal to the systemID of the receiving Intermediate
System, and the receiving Intermediate System does not have that LSP in
its database, or has that LSP, but no longer considers it to be in the
set of LSPs generated by this system (e.g. it was generated by a
previous incarnation of the system), then initiate a network wide purge
of that LSP as described in 7.3.16.4.

d) If the source S of the LSP is a system (pseudonode or otherwise) for
which the first ID Length octets are equal to the systemID of the
receiving Intermediate system, and the receiving Intermediate system
has an LSP in the set of currently generated LSPs from that source in
its database (i.e. it is an LSP generated by this Intermediate system),
perform the actions described in 7.3.16.1."

So the way the spec is currently written it MUST be the system ID.

I agree that it would be possible choose any domain wide unique
identifier provided it was consistently used for all these fields, and
that this might be necessary if it were required to support a router
being DIS on more than 255 LANs. Nothing in the protocol would break.
However, it is very convenient from a network analysis point of view to
be able to easily associate a pseudonode LSP with the router ID which
generated it. I suspect some network management tools might break. I
wouldn't want to gratuitously relax this requirement except when
absolutely necessary for being DIS on large numbers of LANs. I'm not
aware of any routers which currently support that.

Mike