Dan Lanciani wrote:
>
> Quality Quorum <[EMAIL PROTECTED]> wrote:
>
> |It seems to me that stability and security of internal enterprise
> |addressing is a very serious requirement.
>
> And why just enterprise? The stability of my home network is more important
> to me than the stability of any
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>
|> Quality Quorum <[EMAIL PROTECTED]> wrote:
|>
|> |It seems to me that stability and security of internal enterprise
|> |addressing is a very serious requirement.
|>
|> And why just enterprise? The stability of my home netwo
I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast. Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.
1) draft-haberman-ipngwg-host-anycast-01.txt (Host-base
There seem to be at least a couple of possible PI schemes that are being or
have been kicked around in the past. Dan referenced a solution that he has
worked on and Tony Hain's geographic scheme, while currently targetted at the
multi-homing problem, might well offer a solution. If we are seri
This is the semantics police speaking:
PI = Does *NOT* scale.
Starting with this assumption leads us to two bad choices. Maybe it
is time to question this assumption?
Same here. I did not comment on this before, but I think that what
Margaret really means here is:
> This is the crux of w
On Mon, 27 Jan 2003, Brian Haberman wrote:
> > There are a _lot_ of issues there, especially if one anycast address can
> > have joins from across multiple routers. Even more so if from across
> > multiple sites/AS's, or more specifically (with some terminology pixie
> > dust) an IGP/iBGP area --
Pekka Savola wrote:
On Mon, 27 Jan 2003, Brian Haberman wrote:
There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers. Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust) an IGP/iBGP
On Mon, 27 Jan 2003, Brian Haberman wrote:
> >>The big issue is with inter-site anycast. A host route from a foreign
> >>domain (i.e. not the prefix owner) could actually prevent anycast
> >>traffic from reaching the owning domain unless explicit config allowed
> >>for the "leaking" of the host ro
>> Michel Py wrote:
>> PI = Does *NOT* scale.
> Dan Lanciani wrote:
> Please define "PI".
ftp://ftp.ripe.net/ripe/docs/ripe-185.txt
> Please define "scale".
One billion end-sites. This is the baseline number for multihoming
solutions. Smaller numbers have been deemed insufficient.
One billion
Margaret Wasserman wrote:
>
> >This is the semantics police speaking:
> >PI = Does *NOT* scale.
>
> Starting with this assumption leads us to two bad choices. Maybe it
> is time to question this assumption?
>
> >Same here. I did not comment on this before, but I think that what
> >Margaret real
Margaret,
>> Michel Py wrote:
>> PI = Does *NOT* scale.
> Margaret Wasserman wrote:
> Starting with this assumption leads us to two bad choices.
I don't agree that we have only two choices. The role of the IETF is not
to pick the least worst among bad solutions but to develop better ones.
> Ma
Michel,
>
> > Tim Hartrick wrote:
> > If we are seriously considering doing PI allocations then
> > we should probably start the process of collecting
> > proposals for how to make it scale.
>
> This is the semantics police speaking:
> PI = Does *NOT* scale.
>
> Tim, I don't doubt your inten
Michel Py wrote:
Margaret,
Michel Py wrote:
PI = Does *NOT* scale.
Do you base this statement on hard evidence or conventional wisdom?
Brian Carpenter wrote:
But the problem remains as hard as it was in 1992. We don't
know how to aggregate routes for such addresses, and we don't
know how to
But the problem remains as hard as it was in 1992. We don't know how
to aggregate routes for such addresses, and we don't know how to scale
the routing system without aggregation. Solve either of those
problems and you're done.
Maybe we can't solve this problem
If not, then we won't have
"Michel Py" <[EMAIL PROTECTED]> wrote:
|>> Michel Py wrote:
|>> PI = Does *NOT* scale.
|
|> Dan Lanciani wrote:
|> Please define "PI".
|
|ftp://ftp.ripe.net/ripe/docs/ripe-185.txt
This is a rather long document and I was hoping you would provide the part of
the definition that you are actually us
I guess my previous message was not sent to the list this morning (the connectivity is
terrible here ;-), so I forward it again
> Margaret,
>
> I think we have no other choice than (B), both technically, and from the "marketing"
>perspective of going or not to deploy IPv6.
>
> I think the scalab
Hi Pekka,
On Mon, 2003-01-27 at 17:40, Pekka Savola wrote:
> On Mon, 27 Jan 2003, Brian Haberman wrote:
> > >>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
> > >>>seq number (or equivalent protocol-specific information) of the
> > >>>just-received TCP SYN, indicating
Hi Tim,
Not to pick on you... You are making some excellent points, and I
want to make sure I understand them.
And, I have serious doubts that
they will ever scale. But, if that is the case and we are going to be
forbidden from seeking other solutions that involve site-local addressing and
re
> >
> > I think that we should find a way to return to stable, globally-routable,
> > provider-independent addresses that are allocated to homes & enterprises.
> > Addresses that do not change when you change ISPs, and that cannot be
> > changed by your ISP. Real PI addresses. Just like the ori
Pekka,
It seems to me that you left out the most
nettlesome problem about why people want address
stability: name mappings, both in the form of DNS
and everywhere else you find raw IP addresses
floating around. In many ways, this mimics the Y2K
problem in that it's very hard to gauge _what_
exac
Dan,
>> Michel Py wrote:
>> One billion routes in the global routing table = does not scale.
> This is the main fallacy in your statement. You are assuming
> that a billion PI address blocks has to equate to a billion
> routes in some global routing table (or even that there has to
> *be* a glob
"Michel Py" <[EMAIL PROTECTED]> wrote:
|>> Michel Py wrote:
|>> One billion routes in the global routing table = does not scale.
|
|> This is the main fallacy in your statement. You are assuming
|> that a billion PI address blocks has to equate to a billion
|> routes in some global routing table
Margaret,
>
> Not to pick on you... You are making some excellent points, and I
> want to make sure I understand them.
>
> >And, I have serious doubts that
> >they will ever scale. But, if that is the case and we are going to be
> >forbidden from seeking other solutions that involve site-lo
Tim,
> Tim Hartrick wrote:
> given the current centralized routing architecture, PI
> addresses don't scale. And, I have serious doubts that
> they will ever scale.
> But, if that is the case and we are going to be forbidden from
> seeking other solutions that involve site-local addressing and
>
Dan,
> Dan Lanciani wrote:
> You are confusing the portability attribute of the address with
> the implementation of its routing. By the definition you chose,
> PI is a type of address. It is not a routing mechanism.
This is not the way "PI" is being understood in the realm that deals
with them,
Ralph,
I don't think that this was discussed completely last IETF. I was wondering
if you could suggest some text for the current Node Requirements doc?
thanks,
John
> -Original Message-
> From: ext Ralph Droms [mailto:[EMAIL PROTECTED]]
> Sent: 21 November, 2002 14:56
> To: Greg Daley;
Hi all,
Last IETF, Thomas expressed some concerns about a MAY support 3041. Notes
from the meeting are:
Thomas: MAY on privacy extensions is too weak. Should be a SHOULD
if you are the type of node to which it applies.
Tony: Shouldn't mention clients servers, etc., as this is too operati
Fred,
> Fred L. Templin
> Your statements seem to be focused on the solutions we have
> at hand today along with the unspoken assumptions we have
> held as truths in the past. I used to think that carefully
> managed hierarchical routing was the only way to go to
> achieve scalability, but I am no
This is not the way "PI" is being understood in the realm that deals
with them, the RIRs. "PI" does not only mean portability, it also means
the routing mechanism that is (and always has been) in use, which is to
announce the prefix in the global routing table, making it grow.
No matter what
"Michel Py" <[EMAIL PROTECTED]> wrote:
|> Dan Lanciani wrote:
|> You are confusing the portability attribute of the address with
|> the implementation of its routing. By the definition you chose,
|> PI is a type of address. It is not a routing mechanism.
|
|This is not the way "PI" is being unders
Hi all,
Currently, updating the node requirements, I am updating the text to say:
In a general sense, MIBs SHOULD be supported by nodes that support a SNMP agent.
At least these should be supported
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt
http://www.ietf
John - the earlier discussions in the ipv6 WG meeting ran long, so we
didn't get a chance to discuss draft-droms-dhcpv6-issues-00.txt, which
includes some text on the 'M' and 'O' bits.
Anyway, I'll be travelling for the next couple of days. I'll review the
text in question and post some text n
Hi Ralph,
> John - the earlier discussions in the ipv6 WG meeting ran long, so we
> didn't get a chance to discuss
> draft-droms-dhcpv6-issues-00.txt, which
> includes some text on the 'M' and 'O' bits.
I understand about that.
> Anyway, I'll be travelling for the next couple of days. I'll r
> What words would you like me to use for portable, globally-routable
> addresses that are assigned to an entity (home, enterprise, etc.) and
> that can be used by that entity regardless of the ISP from which
> they purchase their service, cannot be changed by the ISP, and don't
> need to change if
> What term should I use for that?
"Aggregatable PI addresses", which is however kind of a contradiction in
terms. Addresses are as much aggregatable as their assignment reflects
the underlying topology, which includes the split of the network among
various providers. By definition, a structure
Margaret,
>> Michel Py wrote:
>> This is not the way "PI" is being understood in the realm that
>> deals with them, the RIRs. "PI" does not only mean portability,
>> it also means the routing mechanism that is (and always has been)
>> in use, which is to announce the prefix in the global routing
>
On 27 Jan 2003, Mika Liljeberg wrote:
> > > > I agree with you here .. but ICMP could give you enough strong
> > > > authorization with basically zero added messages.
>
> Not necessarily. If the TCP anycast server were to send the ICMP
> back-to-back with the SYN-ACK, any reordering in the networ
37 matches
Mail list logo
