[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] GSE?
Again, I would like to get out of the mode of talking about individual
proposals. If folks want to have a conceptual discussion about
transformation solutions in general, I'd welcome that.
Tony
|-----Original Message-----
|From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
|Sent: Thursday, June 12, 2008 4:22 PM
|To: Xu Xiaohu
|Cc: tony.li@tony.li; lixia@CS.UCLA.EDU; 'Routing Research Group'
|Subject: Re: [RRG] GSE?
|
|Hi,
|
|I think the interesting question is: how many of those
|issues apply to ILNP?
|
|Also remember that some of the esd-analysis issues were
|disputed, which is really why the document never became
|an RFC.
|
| Brian
|
|On 2008-06-12 16:29, Xu Xiaohu wrote:
|> Hi Tony and Lixia,
|>
|> How about launching the review and discussion on the listed
|issues of GSE in
|> draft-ietf-ipngwg-esd-analysis-05 one by one, so as to see
|whether some of
|> them are still big issues from current point of view and to
|find something
|> we can do now to fix these issues?
|>
|> Best regards,
|> Xiaohu XU
|>
|>> -----邮件原件-----
|>> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Tony Li
|>> 发送时间: 2008年6月12日 1:35
|>> 收件人: 'Mayutan A.'; 'Robin Whittle'
|>> 抄送: 'Routing Research Group'
|>> 主题: RE: [RRG] GSE?
|>>
|>>
|>> Hi Mayutan, Robin,
|>>
|>> Isn't the Six-One proposal by Christian Vogt an
|enhancement of the
|>> GSE.
|>> http://www.watersprings.org/pub/id/draft-vogt-rrg-six-one-01.txt
|>>
|>> Correct me if I am wrong.
|>>
|>> You are exactly correct. I still encourage folks to read GSE
|> independently,
|>> just so you have some perspective on Christian's changes.
|>>
|>> Also, some of the work that Ran Atkinson has done has been
|in part derived
|>> from GSE.
|>>
|>>
|>> GSE seems to have been developed briefly around 1997. I
|>> understand
|>> that applying it to IPv6 as used today would
|involve major
|>> changes
|>> in routers, host stacks and some or all applications.
|>>
|>> There may well be some major attractions in
|doing this, if
|>> it could
|>> be done, but it sounds like a radical thing on
|which to bet
|>> the
|>> future of the Net.
|>>
|>>
|>> Welcome to the IRTF. Our job is research. No job too
|large, no change
|>> unthinkable.
|>>
|>>
|>> Could you or someone else put together a
|proposal and link
|>> to it
|>> from the RRG wiki? An 8 page summary and
|analysis document
|>> would be
|>> good too.
|>>
|>>
|>> Others should feel free to step up here. I'm trying to
|remain neutral.
|>>
|>>
|>> A crucial part of this would be the time-frame for
|>> transitioning the
|>> current IPv6 system to whatever it is you are
|planning, and
|>> then
|>> having a transition plan for most end-users
|from IPv4 to the
|>> new system.
|>>
|>> I think it would also be good to explain why you would
|>> prefer to do
|>> this in a hurry for IPv6 - due to whatever
|urgency you or
|>> other
|>> people might think about the IPv4 scaling
|problem - rather
|>> than
|>> fixing the IPv4 problem with a map-encap scheme and then
|>> being able
|>> to take more time on whatever it is you propose
|for IPv6.
|>>
|>>
|>> I'm not in a hurry to do anything. There's no need. I'd
|much rather Get
|> It
|>> Right. Whatever we do here is forever.
|>>
|>>
|>> I haven't read enough to know how it provides
|multihoming
|>> and
|>> portability (of the ESD part of the address)
|when changing
|>> ISPs.
|>>
|>>
|>> The ESD would be a constant when changing ISPs. That's the
|whole point.
|>> Identifiers are decoupled from locators.
|>>
|>>
|>> So how does the Routing Goop and STP get set
|when the packet
|>> leaves
|>> the site for another? Does a router change
|them or does the
|>> sending
|>> host have to get it right. Does there need to
|be a mapping
|>> function
|>> and consequently a mapping database to
|determine what to set
|>> these
|>> to, since the ESD is what uniquely identifies the
|>> destination host?
|>>
|>>
|>> Presumably set by a router when you exit the subnet and/or
|the site. Yes,
|>> there needs to be a mapping database to determine
|destination RG and ESD.
|>> One might reasonably extend DNS to do this. No mapping
|database is needed
|>> in the site's local routers as they would presumably be
|configured with
|> the
|>> RG or learn it via some other management mechanism such as
|SNMP, DHCP, the
|>> IGP, or your favorite NMS.
|>>
|>>
|>> What lead to the demise of GSE ten years ago?
|>>
|>>
|>> I wasn't directly involved, but my read was that it was
|politics. Because
|>> it modified v6, it was unacceptable to those that felt that v6 was
|> perfect.
|>> We seem to be over that now...
|>>
|>> Regards,
|>> Tony
|>>
|>>
|>> --
|>> 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