Re: ps & req in multi-prefix-env

2007/4/4, Fred Baker <fred@cisco.com>:

On Apr 3, 2007, at 2:26 AM, Ruri Hiromi wrote:

> Hello,
>
> For WGLC, I would like to confirm the description about "multi-
> interface" issue.
>
> In the documents(http://www1.tools.ietf.org/html/draft-ietf-v6ops-
> addr-select-req-01) at section4(3) and (4), we wrote about comments
> given at IETF67.
>
> (1) should or must?
>  In our original requirement, we thought multi-prefixes with single
> interface.  Now we inserted  the additional description about the
> problems(s) to be considered at the situation of multi-prefixes
> with multi-interfaces.  My question here is; which is better to
> declare "the multiple interface issue SHOULD be considered?" and
> "the multiple interface issue MUST be considered?"?   which phrase
> is suitable?

I'm a little uncomfortable with the distinction in this context. The
way I use the terms, which dates from the development and editing of
what we now call RFC 1812, "MUST" implies that something breaks if
you don't do it, while "SHOULD" implies that there may be cases in
which it is valid to not do the action - and the implementation that
doesn't do the "should" is on the hook to make that case.

For example an IP router MUST apply a longest-match-first lookup to
determine what route entry to use - if it doesn't, it will send
packets the wrong way. On the other hand, while it is legal and
sensible to configure IP prefixes in terms of a prefix length, at the
time that RFC 1812 was written it was common practice to use subnet
masks and to not require that they be contiguous (eg expressible as a
length). In the context of the era, the statement

   The <Subnet-number> bits SHOULD be contiguous and fall between the
   <Network-number> and the <Host-number> fields.  More up to date
   protocols do not refer to a subnet mask, but to a prefix length; the
   "prefix" portion of an address is that which would be selected by a
   subnet mask whose most significant bits are all ones and the rest
are
   zeroes.  The length of the prefix equals the number of ones in the
   subnet mask.  This document assumes that all subnet masks are
   expressible as prefix lengths.

made sense. There were other ways to do things that we were in fact
trying to stamp out, and have a decade later succeeded in stamping out.

In this context, the authors have argued that they are dealing with a
special case network and system rather than the general case. In the
general case, multi-LAN servers are pretty common, and multihomed
networks with multiple DMZs are pretty common among the Fortune 1000
list of companies. In the specific case of a home or a cube farm,
single-interfaced hosts predominate by a huge percentage, and among
non-fortune-1000 companies single homing and single-DMZ multihoming
are pretty common. So I struggle with the question "who is your
target audience". The people most likely to use your solution sound
to me like the parties that you say you're not addressing.

In that context, what breaks if you don't address the multi-LAN
server case? I think what "breaks" is that the administrators of
those systems won't find your solution adequate, something you have
already said you are perhaps OK with.

> (2) how? any ideas? references?
>  If you already have an idea to solve this, could you feed us details?

Goodness. To my admittedly small mind, the multiple-prefixes-on-one-
interface case is a special case of multiple-prefixes-on-many-
interfaces. Solve the latter and the former should fall out.

This is why I urged that you consider asking the network about
destination address choice in some way. Since the host doesn't know
the details of routing, it has two choices: to ask the network, which
does, or to perform its own measurements and maintain some degree of
memory in cache form.

> ====
> (current description)
> 3) Issues that need big RFC 3484 change.
>     - Multiple Interfaces Issues
>
>       Dave Thaler gave us comments that multiple-interface hosts may
>       face policy collision and distribution of dst address selection
>       policy and src address selection policy should be separated.
>       Also, per-interface policy table was proposed.
>
>       After all, this is a policy collision problem.  To make a host
>       have one policy table per network interface doesn't solve policy
>       collision issue.  Source address selection is performed after
>       output interface is selected, but destination address
> selection is
>       before output interface selection.  In this case, destination
>       address selection uses all the policy tables a host has, so here
>       collision can happen.
>       Separating destination address selection and source address
>       selection will have a big change on RFC3484 policy table
>       definition.  Though it may be a good idea to avoid source
> address
>       selection policy collision.
> ====
>
> Thanks in advance,
> -------------------------------
> Ruri Hiromi
> hiromi@inetcore.com
>
>