[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ps & req in multi-prefix-env


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