[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim6 @ NANOG (forwarded note from John Payne) (fwd)
Hi Igor,
El 10/03/2006, a las 13:53, Igor Gashinsky escribió:
Hey Marcelo,
Comments in-line...
:: > No, it can not. Cogent, being a SFI peer, will only advertise
*their
:: > customer* blocks, which the UUnet address will not be a part of
(but
:: > ip-cogent will be, but the server doesn't know that the 2 are
equivalent).
:: > Therefore, since I only see this user from the ip-uunet, unless I
somehow
:: > know that this guy is also ip-cogent, I can only respond to him
via full
:: > transit (ie expensive) providers, in this case uunet. If the
:: > servers/network/whatnot was aware that locator1 = {ip-uunet,
ip-cogent}
:: > and then able to equate the two, *then* we could make a correct TE
:: > decision somewhere (the where is still to be determined, but at
least now
:: > we are capable of it).
:: >
:: > Ah, I see the confusion here.. so, in my example, I have no
issues about
:: > the inbound path (client->server), my issues is with TE on the
*outbound*
:: > path (server->client). Since I only see customer blocks from SFI
peers,
:: > the sheer fact that the client picked ip-uunet has dictated that
I would
:: > need to answer to him via ip-uunet, which means I have to do so
over the
:: > uunet link, whereas in ipv4, I see the entire map, and I'm aware
that
:: > locator1 is behind both uunet and cogent, and I can chose to take
the
:: > cogent path.
:: >
::
:: In the PI case, the client don't have a way to know which address
prefix it
:: should preffer for the source address. But i guess this the same
that in the
:: v4 case...
No, in the v4 world they have only 1 address. They could chose to send
it
out any link they want, but it's still 1 address.
but here you are assuming that all end-sites that are multihomed get to
announce their address block in the DFZ, which seems too much imho.
I mean, in v4 there are some big multihomed sites that have their own
prefix announced, but there are also small sites that are multihomed
that they use NAT and PA addresses from each of their providers. I mean
assume that a soho has a dsl access and a CATV access, do you think it
will be able to announce its prefix (which in many cases will consist
in a single public IP address) through BGP?
:: assuming the the client does have PA addresses (I mean, i am not
:: assuming that all multihomed clients can get their PI block, since
this does
:: not seems sustainable in the future, right?
:: I know that this is just an example.
:: But my point is that: i agree that things with the shim and PA
addressing are
:: different than in the PI BGP world
:: But this doesn't necessarily imply that you cannot achieve similar
:: behaviours, (probably using different tools)
I'm specificly talking about the case where the client is PA, and
server
is PI. So, how do you get the server to realize that the the client,
which
connected from ip-uunet, is also ip-cogent (which is something that BGP
knows in v4, and is very important for outbound TE), and do so without
adding an enormous amount of state/latency/overhead?
I agree that in the case that the client is PA and the server is PI you
will need to establish the shim context and rehome the communication
after, which requires state.
However, in the case that i was considering before was when both the
server and the client have PA addresses. In this case, the client will
prefer the common ISP addresses thanks to RFC3484
Anyway i guess we understand each other now and i agree that in the
scenario that you were considering, TE would require state.
...
:: So i guess you got a point there, but i would say that this is yet
another
:: concequence of using PA addressing rather than PI for multihoming
Yes, but who deemed it as an "acceptable" concequence?
I guess my point is that while trade-offs will have to be made in order
to accomplish the goal, and some people might call them "acceptable",
people should remember that in the end, those tradeoffs will be
concidered
against the current model, and quite frankly, unless *every* TE
mechanism
which we use today (not neceserily the tools, but the policy itself)
can
be implemented in a manner which will scale, and not induce undue
overhead on
the servers, I'm not going to be implementing shim6, and from all my
conversations with quite a few of my peers in the content provider/xSP
world, they won't be either. So, if you want people to adopt it, please
build it with *no less* useful functionality then what we currently
have.
Well, i guess it is not really about what is acceptable but rather
about what is possible... i mean
In v4 there are two ways of multihoming, announcing the multihomed site
prefix through BGP or acquiring multiple prefixes from each of the
providers (and probably using NAT)
In the second case it is the same in v4 or in v6 (only that since there
is shim protocol for v4, there is no failure protection for established
communications). In this configuration either in v4 or in v6 you don't
have the TE capabilities that you would have in the PI case.
I would argue that the second form of multihoming will become
predominant since the amount of small sites becoming multihomed with
the widespread adoption of DSL CATV and this technologies for small
sites will encourage those (who don't have access to premium services
of the ISP) to get fault tolerance through becoming multihomed.
So i would argue that the problem is not shim specific and it is not
even v6 specific, but it is simply a concequence of cheap technologies
that are becoming available and that enable lots of small users to
multihome...
As these technologies prevail, you need alternative approaches to BGP
injection to support them. Those alternative approaches may not provide
the same features, i agree. The goal is to try to make them as good as
possible so that they can provide as similar features as the currently
available
I mean, we do agree that it is not possible to inject a Prefix into the
dfz by each soho site with two dsl lines (neither in v4 nor in v6),
right?
Regards, marcelo
-igor