[rbridge] Proposed details for announcing endnodes

[Eric Gray]

Donald,

	On your second point, this is a specious argument.  The fact
that we (collectively) have decided to take on a specific problem
that we (or at least some of us) feel exists with bridges does not
grant license to including all problems that we (definitely some 
of us this time) also feel exist.  That is a recipe for closure of
the working group, rather than the work...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, April 29, 2008 9:30 PM
> To: Dinesh G Dutt; Joe Touch
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Proposed details for announcing endnodes
> 
> (1) I don't see any point in discussing ARP now since the 
> working group
> has decided to move ARP and similar IP optimization out of the base
> protocol draft to another document which does not yet even exist.
> 
> (2) The purpose of Rbridges is to do better than bridges. Arguments of
> the form 'X is a known problem with bridges so we shouldn't solve it'
> seem odd when the main premise of Rbridges is 'spanning tree 
> is a known
> problem with bridges so we WILL solve it'.
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On
> Behalf Of Dinesh G Dutt
> Sent: Tuesday, April 29, 2008 12:42 PM
> To: Joe Touch
> Cc: rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] Proposed details for announcing endnodes
> 
> Agree with Joe,
> 
> Dinesh
> Joe Touch wrote:
> >
> >
> > Radia Perlman wrote:
> >> Yeah. Moving endnodes is always an issue. Even with bridges. The 
> >> problem with having R1 (the one announcing that endnode E is
> >> attached to R1) having a very short learning cache is that 
> makes R1's
> 
> >> endnode announcement LSP information annoyingly volatile. 
> The problem
> >> with the learning
> >> cache timer being long is that R1 can be a black hole, sucking 
> >> traffic away from where E really is.
> >>
> >> There are some layer 2 protocols, I believe, with explicit 
> >> registration and keep-alives. (anyone care to chime in about which 
> >> protocols
> >> these are?). Endnodes learned that way are good candidates for 
> >> explicitly advertising.
> >>
> >> For attached IP endnodes, R1 could do something like, if it seems 
> >> someone else advertise E, R1 could do an ARP to see if E is
> >> still there. And there might be similar purely layer 2 
> "pings". (are 
> >> there?)
> >
> > I do not believe rbridges should ever issue ARPs. Silent 
> movement is a
> 
> > known problem with existing bridges; this is not an issue 
> we should be
> 
> > solving.
> >
> > Joe
> >
> >
> --------------------------------------------------------------
> ----------
> 
> -- 
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>