Subject: RE: Next question...

From: "Tony Hain" <[email-masked]>
Date: Tue, 3 Dec 2002 10:27:34 -0800

Tony Li wrote:
> Folks,
> 
> Have we reached consensus that we need to deal with 
> multihoming policies?  

I thought that was one of the goals of the requirements document...

> And do we agree that doing so at the 
> per-host level doesn't scale?
> 

My interpretation of 'doesn't scale' in this case is that the host
policies are not managed by the network infrastructure team, therefore
per-host can't be part of the multi-homing solution using current
management tools and divisions of labor. If that interpretation is
correct, a simple non-technical approach like having the host and
network management teams actually talk to each other would remove the
scaling issue. Other approaches like better management tools would also
help. Removing per-host from the solution set may make it easier for the
network focused participants to reach consensus, but it blinds the host
& applications from the alternatives. Scaling in this case depends on
your perspective. From the app point of view, a network that does not
react appropriately is useless for anything more than a bit-pipe and
will be routed around or tunneled over (re: POTS, ATM, ...). Managing
fine-grained TE aspects of uncoordinated traffic sources with an IGP
sounds like a nice research topic.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Thu, 5 Dec 2002 21:37:30 -0800

Tony,

> Tony Li wrote:
> 1) Put the locators in the host, so that it can control
>    which locator it wants to use.  This allows the
>    application to change locators if its service is
>    unacceptable.
> 2) Put the locators in the border router.  This frees
>    the host of the management burden, but makes it
>    somewhat harder for a site to provide site-wide
>    policy.

Why would it be harder? For this purpose, I don't see a difference
between the choice of the locator to be used and the choice of the site
exit link. If the choice of the locator is based on the AS-PATH, turns
out to be the same.

> Note that either of these two alternatives could be
> enhanced by further communications.  Either the border
> can inform the host of site policy, or the host can
> inform the border of its local policy.  One could also
> do both, but this is starting to look like a dromedary.

Full-duplex communications between all hosts and the routing system
about policy is probably a utopia. However, some DFZ hosts feeding the
routing system clues about which destination are crappy over which
locators has good value. Some people will scream about hosts making
routing decisions, but there are cases where this could be beneficial as
apps react differently from one another.

> Does that about cover the high points?

Makes sense to me.

Michel.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Dec 2002 00:41:42 -0800

Michel,

|   > Tony Li wrote:
|   > 1) Put the locators in the host, so that it can control
|   >    which locator it wants to use.  This allows the
|   >    application to change locators if its service is
|   >    unacceptable.
|   > 2) Put the locators in the border router.  This frees
|   >    the host of the management burden, but makes it
|   >    somewhat harder for a site to provide site-wide
|   >    policy.
|   
|   Why would it be harder? For this purpose, I don't see a difference
|   between the choice of the locator to be used and the choice 
|   of the site
|   exit link. If the choice of the locator is based on the 
|   AS-PATH, turns
|   out to be the same.

It's harder because as site administrator, I now need to communicate
policy to each system in the enterprise.  That can be daunting.
Ever manage an enterprise with 2000 hosts in it?

|   > Note that either of these two alternatives could be
|   > enhanced by further communications.  Either the border
|   > can inform the host of site policy, or the host can
|   > inform the border of its local policy.  One could also
|   > do both, but this is starting to look like a dromedary.
|   
|   Full-duplex communications between all hosts and the routing system
|   about policy is probably a utopia. 

More like a nightmare.  ;-)

Tony

---

From: "Michel Py" <[email-masked]>
Date: Fri, 6 Dec 2002 19:42:04 -0800

Tony,

> Tony Li wrote: 
> Would you believe that it's because I am an idiot?

No. Find a better excuse. What were you doing at the same time you wrote
this? What did you drink before?

> 2) Put the locators in the border router.  This frees the host
>    of the management burden, but makes it somewhat harder for the
>    host administrator to implement host specific policies without
>    the assistance of the administrator of the border router.  Host
>    specific policies can still be implemented, they just need to
>    be managed by the border router.  The number of unique host
>    policies can be a scalability issue for the border router.

Much better. Now, what is the difference with what you wrote above and
the way TE is done today?

Michel.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Dec 2002 23:20:33 -0800

|   > Tony Li wrote: 
|   > Would you believe that it's because I am an idiot?
|   
|   No. Find a better excuse. What were you doing at the same 
|   time you wrote
|   this? What did you drink before?

Diet Pepsi, I swear! ;-)

|   > 2) Put the locators in the border router.  This frees the host
|   >    of the management burden, but makes it somewhat harder for the
|   >    host administrator to implement host specific policies without
|   >    the assistance of the administrator of the border router.  Host
|   >    specific policies can still be implemented, they just need to
|   >    be managed by the border router.  The number of unique host
|   >    policies can be a scalability issue for the border router.
|   
|   Much better. Now, what is the difference with what you 
|   wrote above and
|   the way TE is done today?

Typically today, there is NO TE within the site and almost nothing
at the SBR.  The easy way of doing outbound TE is to prioritize different
prefixes from the multiple providers in the SBRs routing table.  This
is easy if there's only one SBR, but folks frequently want two to 
protect against a single point of failure.  In that case, the SBRs have
to be linked with IBGP so that they make consistent policy decisions.

TE within a transit domain is another matter entirely, of course.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Sat, 7 Dec 2002 22:25:58 -0800

|   > > If a host needs to send its identifier and locator 
|   information to
|   > > another host (as in the FTP PORT command), what does it send?
|   >
|   >This is what the identifiers are for.
|   
|   So, the identifier would be sent, and there would be some way for
|   the receiving host to obtain a locator that matches the identifier
|   for return traffic?

Yes, there would need to be a hierarchical mapping from identifier
to a set of locators.

Tony

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Sun, 8 Dec 2002 12:35:46 -0500

> From: Margaret Wasserman <[email-masked]>

    > How does this differ from the GSE proposal -- routing goop inserted at
    > the edge routers?

I must confess that at this remove I've forgotten the fine details of GSE. I
do recall that it included more than just dividing the IPv6 address field
into location and identity parts, although I do vaguely recall the function
you alluded to (some of the location information being added at the border).
Could you give us a brief refresher?

    > Would these locators be considered part of the IP address by upper
    > layers?

Did you really mean to ask that exact question, or were you asking instead
"would this location information be considered part of the identity of the
far end, by upper layers?"

If the latter, then I think the answer is definitely "no" - the whole point
is to make "location" separate from identity, so that the former can change
(although the binding between the two needs to be secured to prevent
connection/etc hijacking). I said "location" since that might also include
which ISP you're currently using, for a multi-homed site, even if your actual
network connectivity hasn't changed.

If the former, however, it would depend on i) exactly what scheme you pick
for the two kinds of name (i.e. do you cram it into an IP address, or perhaps
rather into some sort of option read by the higher level), and ii) whether
you change e.g. TCPv6's checksum algorithm. Note that if you *do* make it
part of the IPv6 address, you're partly (mostly?) vitiating the whole point
of having separate location and identity, as discussed in the previous
paragraph.

At this point, it's too late for the combination of i) 8+8 and ii) not
changing TCPv6, since the TCPv6 pseudo-header already includes all 16 bytes.
So note that going with 8+8 now is not really very useful, since without ugly
TCPv6 checksum hacks, it's going to be hard to switch to a different locator
(at least, if your functional goal includes keeping open connections up).

16+16 looks attractive for that reason, plus to which applications which have
already been modified to work with 16 byte identities will continue to work,
too.

	Noel

---

From: "Michel Py" <[email-masked]>
Date: Tue, 10 Dec 2002 21:16:46 -0800

> Craig A. Huegen wrote:
> It is certainly not this.  I would love to be able to hand
> a policy specification to my counterparts in our desktop
> standards group and have them figure out how to apply this,
> in communication, coordination, etc. Less work for my team.
> But I recognize (as detailed in a previous e-mail) that the
> time and effort required to manage the configurations on a
> significant number of hosts and various permutations of host
> capabilities/extensions is far greater than an extensible
> policy infrastructure that allows me as the administrator
> to change policy and immediately have it applied across the
> entire infrastructure.  I can enhance the policy engine on
> less than 30 devices globally as opposed to coordinating
> features from a number of vendors for a number of operating
> systems for 100,000 hosts.

I could not agree more.

Michel.