[rbridge] Proposed resolution of DRB election/MTU testing

[Les Ginsberg (ginsberg)]

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Friday, May 01, 2009 12:40 PM
> To: Les Ginsberg (ginsberg)
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing
> 
> Les Ginsberg (ginsberg) wrote:
> >
> >
> >> R1.17 is the LAN ID (aka "pseudonode ID"),
> >> R3 has no way of whether R1 should be higher priority or not.
> >>
> >
> > 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...)
> >
> >
> 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.

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

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

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.

> 
> I don't feel strongly about this. There's trivial overhead to
including
> the field in the TRILL-Hello.
> >
> > 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
> >
> >
> 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.

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

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