Re: shim6 @ NANOG (forwarded note from John Payne) (fwd)

[Igor Gashinsky <igor@gashinsky.net>]

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.

:: 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?

:: > Again, see above, just because S prefers cogent, doesn't mean that it's
:: > aware that this customer is reachable via cogent, and until he is aware,
:: 
:: but he is aware since all the client locators are published in the DNS, 
:: right?

Are you suggesting that we do a DNS lookup for every client connection? I 
think you'll find that it's an unacceptabnle performance penalty for even 
a medium-size provider, not to mention a large-volume one.

:: I guess that the point here is that the one that initiates the communication
:: is the one that decides which locators to use (at least until the shim comes
:: into play)
:: 
:: So, yes for communications initiated by the client, it would be the client
:: the one that selects the locators, hence the providers
:: But as i noted above, the default configuration today, would make the client
:: to preffer the same ISP, which is the desired behaviour

But my point is that this breaks TE. If the server doesn't know that 
IP-uunet and ip-cogent are all same client, then the server (or more 
specificly the hosting/content provider) can not make a proper TE 
decision (because they don't know all the link(s) that client is reachable 
on, and therefore can't make a decision consistent with their policies).

:: I guess that this usage of SRV information shows the underlying problem that
:: the fact of having addresses tightly coupled with the provider would allow
:: attackers to launch DoS attacks to a defined access link, independently of
:: the attackers location. The case you mention is even worse because they use
:: the SRV information in order to identify which is the weaker link
:: 
:: 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.

-igor