[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Long term clean-slate only for the RRG?
> It is not clear to me how any of this discussion helps
> routing research for the Internet.
Would you please present a formal step by step research process, where it start, what is the final goal, the action items list, progress log, etc.? IMO the starting point for any construct is setting fundamental building blocks. In this particular case that would be a clear definition of basic networking elements. While people refer to a lot of terms as "loaded" there is an opportunity to adjust existing definitions for purposes of this research.
Thanks,
Peter
--- On Fri, 7/4/08, Marshall Eubanks <tme@multicasttech.com> wrote:
> From: Marshall Eubanks <tme@multicasttech.com>
> Subject: Re: [RRG] Long term clean-slate only for the RRG?
> To: pesherb@yahoo.com
> Cc: HeinerHummel@aol.com, "William Herrin" <bill@herrin.us>, jnc@mercury.lcs.mit.edu, rrg@psg.com
> Date: Friday, July 4, 2008, 11:04 AM
> It is not clear to me how any of this discussion helps
> routing
> research for the Internet.
>
> Regards
> Marshall
>
> On Jul 4, 2008, at 10:55 AM, Peter Sherbin wrote:
>
> > -MY- point was that Line 1 need not be there at all.
> It is an
> > identifier which serves no role in the routing.
> >
> > It sure does as long as there are more than one person
> living at the
> > same address. The selection does not stop until it
> reached the
> > "end". This is why defining the end point is
> critical. It will help
> > with setting all of the identifier properties.
> >
> > Thanks,
> >
> > Peter
> >
> >
> > --- On Thu, 7/3/08, William Herrin
> <bill@herrin.us> wrote:
> >
> >> From: William Herrin <bill@herrin.us>
> >> Subject: Re: [RRG] Long term clean-slate only for
> the RRG?
> >> To: HeinerHummel@aol.com
> >> Cc: jnc@mercury.lcs.mit.edu, rrg@psg.com
> >> Date: Thursday, July 3, 2008, 3:45 PM
> >> On Thu, Jul 3, 2008 at 3:49 AM,
> >> <HeinerHummel@aol.com> wrote:
> >>> In einer eMail vom 02.07.2008 23:43:24
> >> Westeuropäische Normalzeit schreibt
> >>> bill@herrin.us:
> >>>
> >>>> Layer-3 addresses presently describe two
> >> characteristics of the
> >>>> endpoint: its network location and its
> identity.
> >> In a clean slate
> >>>> environment, it is not obvious to me that
> >> path-selection need know
> >>>> anything about the identity part; it need
> only
> >> know about one of the
> >>>> network locations.
> >>>
> >>> Right. I'd call it "learning from the
> >> postman".A letter isn't checked at the
> >>> ingress postal office whether it is
> deliverable or not
> >> (whether the receiver
> >>> has or has not moved to some other place).
> Instead it
> >> is forwarded to the
> >>> egress postal office without such checking. No
> attempt
> >> is made neither as to
> >>> inform, world-wide, any postal office when
> someone
> >> moves to another
> >>> place. Every year many new residential areas
> are going
> >> to be developed, but
> >>> no postman has ever complained about an
> (increasing)
> >> scalability problem.
> >>
> >> Heiner,
> >>
> >> I'm not sure that speaks to the question. Let
> me borrow
> >> your analogy:
> >>
> >> Line 1: William Herrin
> >> Line 2: 3005 Crane Drive
> >> Line 3: Falls Church, VA 22042
> >> Line 4: United States
> >>
> >> Your point is that a post office in Dublin need
> not know
> >> about 3005
> >> Crane Drive. It need only get the mail to the US.
> The first
> >> post
> >> office in the US need not know about Crane Drive
> either; it
> >> need only
> >> get the mail to the post office for 22042. The
> post office
> >> for 22042
> >> does, however, need to know how to get to 3005
> Crane Drive.
> >>
> >> While that's undoubtedly true, all of lines 2
> through 4
> >> are used for
> >> path selection at various stages of the
> letter's trip.
> >> As Noel said,
> >> they are inherently inseparable from the path
> selection
> >> process.. I
> >> could not, for example, tell the post office in
> Dublin to
> >> deliver a
> >> letter to "3005 Crane Drive, United
> States" or
> >> "Falls Church VA,
> >> United States." It wouldn't reach me.
> >>
> >>
> >> -MY- point was that Line 1 need not be there at
> all. It is
> >> an
> >> identifier which serves no role in the routing. If
> you get
> >> line 1
> >> wrong or leave it off entirely your letter will
> still get
> >> to me.
> >>
> >> Line 1 is valuable for other purposes. I generally
> >> round-file letters
> >> addressed to "Current Resident" and I
> >> wouldn't want to accidentally
> >> open someone else's mail. However, there is no
> inherent
> >> reason that
> >> "William Herrin" must be a part of the
> address.
> >> It would be just as
> >> functional if I found it on a second envelope
> enclosed in
> >> the first.
> >>
> >> This is important, because as it turns out,
> letters address
> >> to:
> >>
> >> Line 1: William Herrin
> >> Line 2: 6857 Lafayette Park Drive
> >> Line 3: Annandale, VA 22003
> >> Line 4: United States
> >>
> >> will ALSO get to me, albeit a little more slowly.
> The
> >> person with my
> >> identity is reachable at multiple locations each
> of which
> >> can be
> >> described in a manner close enough to a hierarchy
> to be
> >> efficient.
> >>
> >> Regards,
> >> Bill Herrin
> >>
> >>
> >> --
> >> William D. Herrin ................
> herrin@dirtside.com
> >> bill@herrin.us
> >> 3005 Crane Dr. ...................... Web:
> >> <http://bill.herrin.us/>
> >> Falls Church, VA 22042-3004
> >>
> >> --
> >> to unsubscribe send a message to
> rrg-request@psg.com with
> >> the
> >> word 'unsubscribe' in a single line as the
> message
> >> text body.
> >> archive: <http://psg.com/lists/rrg/> &
> >> ftp://psg.com/pub/lists/rrg
> >
> >
> >
> >
> > --
> > to unsubscribe send a message to rrg-request@psg.com
> with the
> > word 'unsubscribe' in a single line as the
> message text body.
> > archive: <http://psg.com/lists/rrg/> &
> ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg