[rbridge] Proposed changes to the architecture based on IETF-70...

[Eric Gray]

James,

	I don't think "problem statement" is the real requirement
relating to this issue.  Speaking strictly from what shoud be 
included in an architectural overview, it is a FACT that there
is no architectural requirement that a DRB election process is
required (emphasis on "election") - or that there necessarily
must be a "designated RBridge" in any (unscoped) general sense.

	In a way, I might have been guilty of laziness because I
felt 1) it is obvious we are going to use some sort of election
process (why re-invent the wheel?) and 2) it seemed obvious -
based on continuing cycles of discussion - that we would most
likely end up using existing technical approaches to elect a
DRB for some reasonable VLAN-based, or interface-based, basis.

	The point was made that this is not necessarily a valid
assumption to make at the architectural level and that, at that
level, what is really needed is to spell out what is required.

	Having been called on my laziness, I agreed to spell out
what the architectural requirements - with respect to what is 
actually needed when more than one RBridge might act as the 
ingress and/or egress.

	They break down into two categories: 

1) why there should be - at least in some cases - a designated
   ingress and/or egress RBridge, under what general conditions
   this might be required and what are the limitations that we
   may expect to apply otherwise.
2) what the advantages and disadvantages are for using some 
   form of automated process for handling the scenarios where
   such a function is required - such as an election process -
   as opposed to some form of hardwired or configured approach.

	I believe the changes I've proposed effectively replace
the earlier assumption of a DRB election process with the more
complicated architectural requirements that - in the end - are
very likely going to justify using a DRB election process.

	I guess - as nearly as I can define such a thing - the
"problem statement" is this:  in a general sense, there is no
particular reason why a DRB election process would be needed
in every possible solution to the TRILL problem space.  As I
have since learned, this breaks down into the 2 specific areas
listed above - i.e. - why "election", and why "DRB"?

	Hopefully this helps...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Friday, February 22, 2008 9:48 AM
> To: Eric Gray
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Proposed changes to the architecture 
> based on IETF-70...
> Importance: High
> 
> Eric Gray writes:
> > Several people pointed out that the architecture should not assume a
> > DRB election process will be used.  This is technically correct, and
> > - for that reason - not directly something that needs consensus to
> > change, at least in theory.
> 
> Could someone please post the problem statement?  Besides just making
> the DRB election "optional," I think it'd be good to have a summary
> statement of what problem is solved by making it possible to run
> without DRB election.
> 
> (I'm guessing this was discussed somewhere ... but I wasn't able to
> locate it in the archives.)
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> 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
>