I'll repeat what said in behave a few days ago. I think this
capability actually gives the e2e guys (whom I count myself among) 99%
of what they are looking for while giving rrg-etc, which is to say
"the ISPs", 99% of what they're looking for.
GSE/8+8 gives us the ability to manage the addresses we exchange in
routing down to a number of prefixes on the order of (eg equivalent to
a small multiple of) the number of autonomous systems. PI addressing,
which is where we are in fact going, gives us a number of prefixes on
the order of the number of things that want ot attach to the network,
which is on the order of hundreds of thousands to millions now and
tens of millions pretty soon, per Marshall Eubanks' analysis for
NANOG. As specified, it calls for the use of some form of local
address in the edge networks and a translation to PA at the DMZ
between the edge and the core.
What the Apps are looking for is a way to connect across the network
core to provide whatever services they want to provide. If we make
that hard for them, they will ignore the troubled lower layers and run
lots of little tubes over the top of the core - and the ISPs will
suddenly be unable to sell anything other than commodity bandwidth to
them. Any ISP that has any notion of selling services needs to be very
aware that making life hard for the applications bites them very hard
and very fast.
So, what specifically do the applications want? They want a
predictable address for a machine on the other side of the network
that they can reach, and they want the junk cleared out of their way.
They want not just routes that work, but routes that work well. They
are generally willing to have the addresses underneath them change if
they can recover from the hit easily.
What they don't want is a lot of excess work, like connection setup
delays, or large infrastructure they have to manage. If it's the only
way to accomplish what they want, they will do it, but they would
actually prefer to get that as a simple service from the network. They
mostly want to avoid unneeded overheads
Take a look at ftp://ftpeng.cisco.com/fred/gse/nat66-gse.html. What
I'm working on is what I call the "rendezvous problem", which I
describe in some detail in section 1.4.1 and test with a vengeance (or
at least intend to) in the prototype discussed in section 3. I think
that fundamentally we have to convince or transports that their
underlying addresses are not a single local and a single peer address,
but two equivalence classes of addresses. Basically, if we are
communicating with a remote peer and we receive the next datagram from
one of the addresses in that peer's equivalence class, we accept it as
coming from the peer. There are several ways that might be
accomplished, which I look at in section 2.2 (and if I have missed
any, I will be happy to have it pointed out to me); they include
literally building those equivalence classes, and picking up one of
several identifiers that might act as surrogates for them.
What we need to avoid is knee-jerk thinking. NAT44 has been a real
disaster from a number of perspectives. I understand why Tony and
others want to not repeat that. That said, "changing the address in
flight" doesn't automatically lead to those issues as long as I can
predictably select the remote host I am interested in and communicate
with it reliably. What results in those issues is depending on network
layer addresses exchanged in protocols unrelated to the network layer,
and the maintenance of ephemeral state at choke points. I want
stateless translation, and I want higher layer protocols to work with
names instead of numbers. I like Margaret's NAT66 proposal because it
enables me to select and route datagrams to a remote host of my
choosing without huge firewall traversal mechanisms and map/encaps
databases like LISP proposes, while keeping routing scalable for the
ISP.
I have been very, very disappointed with the discussion on the topic
so far. I have gotten to the point of recognizing "I don't want
translation and I would rather burn books than have it discussed" and
cutting them off very short. If we can't discuss it, we guarantee that
we will wind up with the same PI unscalable internet that we have
today, just with longer addresses, because we guarantee that we will
make the same mistakes. Either that, or we will make new mistakes that
are equally bad, like assuming that if we can build a map/encaps
overlay that shifts the unscalability out of the ISPs we have
accomplished something of value, when those same ISPs are going to
have to run the map/encaps databases that the unscalability is
shuffled off to, or like assuming that making life simple for the ISPs
by moving the complexity to the edge networks is smart.
No, let's not do that. Let's actually sit down and design something
that is actually simple and accomplishes the task, which is to
simultaneously make life straightforward for application designers,
for those who manage edge networks, and for those that manage ISP
networks. Let's solve the problem IPv6 set out to solve - to build a
better next generation network.
I believe that the IESG decided to have this discussion on behave for
now.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf