Subject: [Mipshop] David Ward's comments on 4140bis

From: Hesham Soliman <[email-masked]>
Date: Fri, 09 May 2008 13:57:38 +1000

Hi David, 

Please see some comments below.

  In section 7.1 there is a mention of options (e.g. preference) that are
  associated with MAP IP addrs  but, there is a very limited encoding (e.g.
  no flags, or other attributes) in the MAP option. In addition, the
  definition of a Dist is limited to 4 bits. Is that enough? Is it
  reasonable to assume that no semantics are to be associated with distance?

=> The purpose of the distance field is to give a _relative_ distance for
the mobile node. Effectively, if all MAPs in one domain have the same value
in the distance field, then the distance field is not relevant. The number
in the distance field is not the hop count between the MN and the MAP. It is
only there to tell the MN that MAP1 is further (and hence covers a larger
domain) than MAP2. It was intentionally designed to not be a hop count.

 Later, in the selection algorithm for distributed MAPs (9.1) it appears
 that DIST and PREF are directly comparable. Although DIST is used as a
 sorting (akin to hop count although earlier not required), the pref is then
 used to bias selection. The problem with no strict semantics for DIST to be
 hop count (e.g. it could be used as inverse hop count) then you'd get a
 non-optimal selection algorithm.

=> I'm not sure I follow what you mean by exact semantics. I might be
missing something, but according to its definiion and the way it is intended
to be used by the spec, all we need to know is that 10 > 5 therefore 10 is
further than 5. How do you see this being used as an inverse hop count?

 In addition, the PREF variable alone only allows for a very weak
 application of operational policy (since all this has to be hand configured
 - no dynamic specified).

=> There is no requirement for manual configuration. The initial spec had a
dynamic configuration mechanism for the MAP option in the AR but it was
deemed unready for PS. Network admins can integrate dynamic knowledge of the
PREF field (from MAPs) into their configuration tools used to configure the
MAP option in the AR. Those dynamic mechanisms need not be defined in this
spec. But I agree with you that manual config alone will not utilise the
full power of the PREF field.
So essentially we defined the space and the use of those fields but left the
configuration tool for the AR outside the spec.

 Given what we know about policy selection requirements from other
 protocols, something should be mentioned what the RESV space is for or
 allow at this time greater operational options (via more attrs, flags,
etc). 

=> Ok, do you have any suggestions for this? I don't know what we can say
about it. This is the first suggestion I get for this field.

 Next, the section on failure detection and recovery from MAP failures is
 unfortunately not useful because it describes possible failure detection
 methods but, nothing to be standardized. Either something has to be
 specified, referenced or the section has to be removed as an implementor
 has nothing to specified to detect failures.

=> It was recommended by the AD to not use standard language in this part so
we left it as a guidance for admin people and implementers.

Hesham

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 10 May 2008 13:35:59 +1000

> DW: The problem is that it has to have some semantics. Even if used
> the same way across a domain, you can get "poor" answers. Imagine if
> someone set it to inverse hop count and some else set it to randomly
> increasing values. It would be odd. If you don't want it to be hop
> count but, you want it monotonically increasing ... you need to state
> something. I don't understand why you don't want it to be a distance
> vector but, it has to represent something and have some semantics.

=> Oh sure, I think I realise what's happened here. The current doc doesn't
clearly spell out that a larger value means that a MAP is further. So, here
is the current text for the Dist field:

      The only requirement is that the meaning of
      the Distance field is consistently interpreted within one Domain.
      A Distance value of Zero MUST NOT be used.  If the MAP option is
      advertised within an overlap between two different MAP domains
      then this field MUST be consistently interpreted within the
      overlap area. A 4-bit unsigned integer identifying the Distance
      Between MAP and the receiver of the advertisement.  Its default value
      SHOULD be set to 1 if Dynamic MAP discovery is used.  The Distance
      MUST be set to 1 if the MAP is on the same link as the mobile node.
      This field need not be interpreted as the number of hops between MAP
      and the mobile node

I think your comment would be addressed by adding:
A larger value in the dist field indicates that the MAP is further away from
the mobile node. That is, a MAP option with a dist field of 5 indicates that
this MAP is further away from the mobile node than another option with a
dist field of 3. 

Does that address your concern?

> DW: What I am saying (as I mentioned above) without any semantics,
> someone can set it any way they want. Including foolish and
> unintended ways than the spec writer ever imagined. You use dist to
> be a sort and pref to be a weight. Given you have a spec on how they
> are to be used, you have to give the attrs (dist and pref) some meaning.

=> Ok, please let me know if the addition above solves the problem.

> DW: The point isn't really how the pref is configured but, that it is
> a very limited field. For example, the pref is set to "1" on some
> other device. On the local device you want to bias against anything
> that is set to 1. You don't have this flexibility. I don't have any
> strong feelings about your policy knobs other than a lot of
> experience with defining such knobs and the infinite amount of rope
> operators eventually want. They have wanted opaque fields, globally
> unique distinguishing values, mathematical operations on attrs, etc.
> I just brought up that your design doesn't have that flexibility. If
> you don't need or want it in this technology; I am ok.

=> Ok, I appreciate that.

> DW: See above paragraph on some of my experience.
> 
>> 
> DW: I don't find it very useful to to describe options with no MUST
> in a PS. Is there something that all implementations have done to date?

=> Unfortunately not that I'm aware of, I designed a similar approach for a
proprietary technology and it was fine at the time. But there is no public
info on that. 

Hesham

---

From: David Ward <[email-masked]>
Date: Fri, 9 May 2008 09:43:04 -0500

Hesham -

HIH.

-DWard