Re: An idea: GxSE

["Paul Francis" <yoid2000@home.com>]

Agree with all your points.  yes, this moves complexity out of routing and
into the application.

Also, the multi-party application scenario I gave (A inside a site, talks to
B outside a site, B learns A's GR addresses from the socket interface, then
conveys them to C) is the easy case.  A harder case is A inside the site,
talks to B inside the site, then B wants to convey A's GR addresses to C.  B
won't know A's GR addresses because they are in the same site, so when A
tells C about B's SK address (the only address B knows), C would have to
deduce A's GR addresses from A's SK address combined with B's GR address
prefixes learned from the socket.

This in turn places constraints on A's and B's GR prefixes...i.e., they must
be the same.

Yuck.

PF



----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
To: "Paul Francis" <paul@francis.com>
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>; <multi6@ops.ietf.org>
Sent: Monday, June 25, 2001 1:32 AM
Subject: Re: An idea: GxSE



> I think you are mis-understanding the model a little here (cause I wasn't
> clear about this aspect in the original message).  Applications should
> operate in terms of passing the entire list of addresses around.  SK
> addresses should not be thought of as some magic token that can be used by
> applications to learn GR addresses.  Applications should know the GR
> addresses from the start.

How does an application learn its own GR addresses?

> 1.  A DNS lookup on the FQDN will return you the GR addresses (if you are
> outside the target's site), suggesting that at least for the initial
> contact, the application should be aware of the FQDN not the addresses.

For the peer this is fine. But what about itself?


> When host A talks to host B, host B learns the list of addresses by making
> one of the above calls.  Ideally host A never "identifies" itself to host
B
> in the application, host B simply does the first call while the socket is
> still up, learns the whole list, and uses the whole list whenever it
> identifies A, either internally or when talking to a third application at
> host C.  If for some reason it is necessary for host A to send its
identity
> to host B in the application layer, host A should preferably use its FQDN,
> but could also use its SK address.

I see how that can be made to work.
The point is that I think this is a significant change in the way
applications
deal with their own addresses. Today they can just use getsockname(int
sock,...) and pass this to peers.

Thus whatever the new architecture needs to be for applications (handling
addresses) the ramifications of this is best understood by folks with
apps clue. I don't know how many of those we have on this list.

BTW: Working out how IKE would work in the GxSE architecture would be
a good test. (Even though IKE isn't a multi-party application it passes
IP addresses around.)


> An alternative approach would be to have the host attach a syntactically
> correct address-list extension, but with empty place-holders for the GR
> prefix list (instead of the "address-list trigger" extension I suggested
> before).  There would be a learning mechanism, whereby address-list
> extensions would have a field indicating the number of GR prefixes, and
this
> field would be set on incoming packets.  So if the host doesn't know the
> number of prefixes, it would use a default, say 4.  If it chooses too
small
> of a number, then it would learn that in a subsequent return packet.  Of
> course now the partner host would not have the complete list, but this
would
> not be a disaster.  (Alternatively the sending host could always add one
> more GR prefix placeholder than it thinks it needs, to catch the case
where
> a new prefix has recently been added.)

I had the same idea. At least it works better than changing the length
of the packets in the border routers.

> Of course one could take this one step further, and simply have the
> destination host return the source host's list of GR prefixes in the
return
> packet, so that the source host knows it too (on a connection by
connection
> basis---this would not be something the source host could generalize about
> once the connection was closed).  This could be an option selectable by
the
> application...(ah, the complexity creeps in!!!!)

In a sense your moving the complexity of the routing system to handle
scalable multihoming to the transport and applications layers.

  Erik