Subject: [Mipshop] IESG review related changes to 4140bis

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 18 Jul 2008 13:53:04 -0700

All,

The following changes are to be made to draft-ietf-mipshop-4140bis. 
These changes are required to address IESG comments. Let us know if 
anyone has comments on the changes being proposed. The plan is to have 
one more revision before approving the document.

Please change this in Section 2:

OLD:
    Mobile IPv6 [RFC3775] allows nodes to move within the Internet
    topology while maintaining reachability and on-going connections
    between mobile and correspondent nodes.  To do this a mobile node
    sends Binding Updates (BUs) to its Home Agent (HA) and all
    Correspondent Nodes (CNs) it communicates with, every time it moves.
    Authenticating binding updates requires approximately 1.5 round-trip
    times between the mobile node and each correspondent node (for the
    entire return routability procedure in a best case scenario, i.e., no
    packet loss).  In addition, one round-trip time is needed to update
    the Home Agent; this can be done simultaneously while updating
    correspondent nodes.  The re-use of the home cookie (i.e.,
    eliminating HOTI/HOT) will not reduce the number of round trip times
    needed to update correspondent nodes.  These round trip delays will
    disrupt active connections every time a handoff to a new AR is
    performed.  Eliminating this additional delay element from the time-
    critical handover period will significantly improve the performance
    of Mobile IPv6.

NEW:
    Mobile IPv6 [RFC3775] allows nodes to move within the Internet
    topology while maintaining reachability and on-going connections
    between mobile and correspondent nodes.  To do this a mobile node
    sends a Binding Update (BUs) to its Home Agent (HA) every time it
    moves.

    The mobile node may send data packets via its Home Agent immediately
    after sending the Binding Update, but the Home Agent will not be
    able to route traffic back to the mobile node before it receives
    the Binding Update. This incurs at least half a round-trip delay
    before packets are again forwarded to the right place. There
    is an additional delay for sending data packets if the mobile
    node chooses to wait for a Binding Acknowledgement (BA). The
    round-trip times can be relatively long, if the mobile node and
    its home agent are in different parts of the world.

    Additional delay is also incurred if the mobile node employs
    route optimization. Authenticating binding updates requires
    approximately 1.5 round-trip times between the mobile node and
    each correspondent node (for the entire return routability procedure
    in a best case scenario, i.e., no  packet loss). This
    can be done in parallel with sending Binding Updates to the
    Home agent, and there are further optimizations that reduce
    the required 1.5 round-trips [RFC4449, RFC4651, RFC4866].

    Nevertheless, the signaling exchanges required to update
    your location will always cause some disruption to active
    connections. Some packets will be lost. Together with
    link layer and IP layer connection setup delays there
    may be effects to upper layer protocols. Reducing these
    delays during the time-critical handover period will
    improve the performance of Mobile IPv6.

Please change this in Section 5:

OLD:
    Dist

       A 4-bit unsigned integer identifying the Distance Between MAP and
       the receiver of the advertisement.  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.  The only requirement is that the meaning of the
       Distance field is consistently interpreted within one Domain.  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 value of 3.  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.

    Pref

       The preference of a MAP.  A 4-bit unsigned integer.  A decimal
       value of 15 indicates the highest availability.

NEW:
    Dist

       A 4-bit unsigned integer identifying the Distance Between MAP and
       the receiver of the advertisement, measure in the number of hops
       and starting from 1 if the MAP is on the same link as the mobile
       node. A Distance value of Zero MUST NOT be used.

    Pref

       The preference field, used as an indicator of operator preference.

       A 4-bit unsigned integer.  A decimal value of 15 indicates the
       highest preference. When comparing two potential MAPs, the mobile
       node SHOULD inspect this field as a tie-breaker for MAPs that have
       equal Dist values.

Please change HOTI, COTI, HOT and COT to HoTI, CoTI, HoT and CoT, which 
are the correct way to write these (from RFC 3775).

s/Figure 1: Figure 1:/Figure 1:/

Delete the word "significantly" in Section 2.

Also, please change in Section 11:
OLD:
    Confidentiality may be needed for payload traffic,
    but is not required for binding updates to the MAP.
NEW:
    Confidentiality may be needed for payload traffic, such
    as when the mobile node is unwilling to reveal any traffic
    to the access network beyond what is needed for the mobile
    node to attach to the network and communicate with a MAP.
    Confidentiality is not required for binding updates to the
    MAP.

And remove appendix A entirely.

    Update references as follows:
    - Remove reference RFC 4068
    - Remove reference RFC 4302
    - Remove reference RFC 4303
    - Remove reference RFC 4862
    - Remove reference RFC 2827
    - Remove reference RFC 3971

In Section 3.1, change:
OLD:
    through the MAP option
NEW:
    through Neighbour Discovery [RFC 4861] and the MAP option

Please change this in 3.1:
OLD:
   The Home address used in the BU is the RCoA.
NEW:
   The Home address used in the BU is the RCoA, which the mobile
   node acquires via RFC 4877 [RFC4877] Section 9 mechanisms when
   it first contacts a given MAP.

Please change in Section 5:
OLD:
    Global Address

       One of the MAP's global addresses.  The 64-bit prefix extracted
       from this address MUST be configured in the MAP to be used for
       RCoA construction by the mobile node.

    Although not explicitly included in the MAP option, the prefix length
    of the MAP's Global IP address MUST be 64.  This prefix is the one
    used by the mobile node to form an RCoA, by appending a 64-bit
    identifier to the prefix.  Thus, it necessitates a static prefix
    length for the MAP's subnet.
NEW:
    Global Address

       One of the MAP's global addresses.

Please change in Section 6:
OLD:
    This RCoA is formed in a stateless manner by combining the
    mobile node's interface identifier and the subnet prefix received in
    the MAP option.
NEW:
    This RCoA is formed by the MAP when it is contacted by the mobile node
    for the first time.

Please change in Section 6.1:
OLD:
    The RCoA is formed in a stateless manner.
    After forming the RCoA based on the prefix received in the MAP
    option, the mobile node sends a local BU to the MAP with the A and M
    flags set.
NEW:
    After employing RFC 4877 [RFC4877] to acquire an RCoA,
    the mobile node sends a local BU to the MAP with the A and M
    flags set.

Please change in Section 6.1:
OLD:
    The MAP (acting as a HA) will then
    perform DAD (when a new binding is being created) for the mobile
    node's RCoA on its link and return a Binding Acknowledgement to the
    MN.
NEW:
    The MAP (acting as a HA) will then
    return a Binding Acknowledgement to the
    MN.

Please change in Section 6.2:
OLD:
    The MAP acts as a HA for the RCoA.
NEW:
    The MAP employs [RFC4877] Section 9 procedures for the allocation
    of RCoA, and subsequently acts as a HA for the RCoA.

Please change in Section 12.1:
OLD:
    The IPsec PAD entries described in [RFC4877] for allocating dynamic
    home addresses SHOULD be used by the MAP to allocate the RCoA for
    mobile nodes.
NEW:
    The IPsec PAD entries and configuration payloads
    described in [RFC4877] for allocating dynamic
    home addresses SHOULD be used by the MAP to allocate the RCoA for
    mobile nodes.

Vijay

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