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

[Eric Gray]

Folks,

	There was one other change I was asked to make at the last 
meeting.  There were comments about the fact that the Architecture
draft assumes IS-IS. Since this was the result of direction from
the working group chairs and ADs - as a consequence of removing the
"routing requirements" draft from the chartered goals - this was 
what I was supposed to do.  However, there was an action item I
did not realize I had picked up out of that discussion until just
now re-reading the minutes from the last meeting.

	The note was as follows:

"General opinion seemed to be that the architecture document should
 pull in some condensed routing requirements information and then
 have text saying 'looks like we are using IS-IS' or the like. 
 Should be such as to permit other protocols than IS-IS in the
 future."
_____________________________________________________________________

In addressing this note, I propose to add new text - after the 
following two paragraphs (in the the Introduction section):

"Peer information may be acquired via the routing protocol, or may be
 discovered as a result of RBridge-specific peer discovery mechanisms. 
 Details of specific peer information requirements - as well as how
 this information will be acquired is specified in protocol
 specifications (e.g. - [3]).  

"Topology information is expected to be acquired via the link-state
 routing protocol."

After the above paragraphs, I propose to add the following text:

"In addition to the requirement that the routing protocol should be 
 an existing link-state routing protocol, which possibly provides a 
 mechanism for (or re-use of an existing) neighbor/peer discovery, 
 the routing protocol should be able to work with minimal (or no) 
 configuration - using algorithmically derived addressing, for 
 example, assuming the use of addresses is required.

"Given the potential choices, IS-IS routing has been chosen at this
 time, and is assumed in this Architecture.  The fact that this is
 assumed in this architecture is - in no way - intended to preclude
 use of another link state routing protocol, or any other routing
 protocol, in any solution not described in this Architecture."

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray
> Sent: Friday, February 22, 2008 10:51 AM
> To: James Carlson
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Proposed changes to the architecture 
> based onIETF-70...
> 
> James,
> 
> 	Also, from the minutes of the last meeting:
> 
> "Designated RBridge (DRB) text in architecture document doesn't follow
>  the protocol document in providing for DRB to assign encaps/decaps
>  role. It should describe the constraint - that the protocol must have
>  a mechanism so that a native frame is not encaps by more than one RB.
> 
> "Eric Gray: I'll change that."
> 
> Note that - while this part of the minutes provides an "encapsulated"
> (like the pun?) form of the actual discussion, and is sufficient to
> justify the need for the changes I proposed - it does not really do
> justice to the entire discussion.  Hopefully it is not actually going
> to be necessary to repeat the entire discussion at the next meeting.
> 
> --
> 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
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>