Subject: [Mipshop] LC revisions

From: Rajeev Koodli <[email-masked]>
Date: Thu, 12 Feb 2004 17:09:38 -0800

Hello folks,

here is the list of issues and the corresponding resolutions
indented with `>'

Thanks,

-Rajeev

--------

Tuple notation [ap-id,ap-info] and *content* is not consistent
throughout. For example, ap-info should be defined (does it
include the lla and prefix information as shown under 6.1.2?

> New definition in the Terminology, and fixes elsewhere

TTL == 255 in ICMP messages is not explained. presumably, this
comes from ND, but that (normative) reference is missing altogether.

> Reference to ND. References split to normative and informative

Terminology - Aren't some of those terms already defined in
draft-ietf-seamoby-terminology? If so, just refer to that when
appropriate.

Suggest change of name:

        OLD: Router Solicitation for Proxy
        NEW: Router Solicitation for Proxy Advertisement

> Done.

This seems to be incorrect:

       Proxy Router Advertisement (PrRtAdv)
                A message from the PAR indicating a MN to undergo
                handover

It's more akin to a msg which aids in movement detection, no?

> Revised the definition

Several places throughout the document says: "MUST be implemented
and SHOULD be supported." Do you mean enabled instead of supported?

> Changed to MUST be supported and SHOULD be used

section 6.1.1 (Title is missing the abbreviation: RtSolPr)

        Can the 'U' bit be abused? Why wouldn't an MN not turn it
        on *always*. In which case why even have a bit? I.e. is this
        something that can be provided at the discretion of the PAR
        without any input from the MN? If so instead a bit issue
        a recommendation on the PAR that it provide this service if
        at all possible. One question, why would buffering be provided
if
        the LLA of the new point of attachment is a wildcard?
        Should clarify.

> After raising the issue on the ML, the consensus favored deprecating
  the `U' bit. Accordingly, buffering at PAR is allowed, but the MN
  need not request it.

section 6.1.2 (PrRtAdv)

        Only codes 0, 1 and 2 are listed, but 3 is also defined.
        Might as well not list them here and refer the reader to
        the list below (this is futureproof).

        Tuple description and notation is not consistent, please fix.

> Done.

section 6.3.1 (FBU) and 6.3.2 (FBACK)

        Please let's not assign header values, other than tentatively
        (noting that final assignment is up to IANA).

        This points to the need for an IANA considerations section.

> New IANA considerations section

References section

        Must split into "Normative" and "Informative"

> Done.

------

1. Errata:

    Page 18, ICMP Fields/Code: should be 0, 1, 2, 3;
    Page 27, 6.3.3 "Type value for FBACK is 10", should be changed to
                           "Type value for FNA is 10";

> New IANA section

2. Questions, welcome any comments. :)

Page 19, Code Value =0, isn't it a must to provide New Prefix
Information?
otherwise, no way to construct New CoA.

> New code value for the unsolicited case. The New Prefix Info option is

a MUST

Page 30, The LLA option, if the length is in 8 octets, there is no way
to figure out the valid length of link-layer length. for example,
802.3, link-layer addr length is 6 octets, the valid length of the
entire option is 9 octets, but the length field must be filled with 2,
because 9 is not a multiple of 8. Shouldn't we use PAD options,
instead of  specify the link layer length
in this way?

> All options other than the NAACK option are now in units of octets.

Page 31 6.4.4. for NAACK options,  if new Care-of address is supplied,
is it implies that the nCoa's life-time is the same as the life time
for the Prefix in the router advertisement? If so, I think it's better
to state that.

> Is it necessary ? Since it is like any address configured using RA
information.

-------------

1) In the case FMIPv6 is combined with advance DAD to reduce
hand-over processing time, I suppose an NCoA (a pooled
Duplicated-free address in the NAR) should be notified to
the MN by an FBack message prior to its movement. However,
on page 25 of FMIPv6 ID-00(mipshop), The Destination Address
of an FBack message is noted "The NCoA".
I suppose the destination address of an FBack message shall
be "the source address of the FBU message" to carry the
message to the MN on the old link in such case.

> This creates a problem if FBU is sent from the old link and the MN
moves without waiting for the FBack. So, keep the current solution of
always sending it to NCoA, but allowing sending to PCoA as well.

2) In the case of "predictive HO", I suppose a PAR had
better start buffering when it receives an FBU message
instead of a RtSolPr message to reduce buffering delay.
So, I suppose If an MN knows it can send an FBU message
prior to its movement, it should send a RtsolPr message with
its U bit "off", and the PAR starts buffering when it
receives an FBU message, and sends a HI message to the NAR
with its U bit "on".

> This proposes a `U' bit in FBU. This is not useful since NAR will
start buffering in this case.

3)In the case the network notifies MNs of NCoAs with FBack
messages, I suppose there should be some way to notify an MN
by a PrRtAdv message that the NCoA will be notified by an
FBack message. For example a new code of PrRtAdv or code "0",
but NCoA=all "0".

> Motivation not clear. An FBack message with an IP address (NCoA)
will suffice.

--------

Using PrRtAdv both as a response to PrRtSol and as a handover trigger:
specify more explicitly

> New code value for distinguishing the network-initiated handover.
  New attachment point LLA option is a MUST

Identifier value in gratuitous PrRtAdv could create re-transmission
confusion

> New code value for the unsolicited case

How does PAR know MN's IP address when sending PrRtAdv gratuitously ?

>Knowing the L2 address, a lookup of ND cache or inverse ND provides
the IP address

PrRtAdv needs Prefix Valid Lifetime and Prefix Preferred

> This will be confusing, as well as hard for PAR to keep track of. A
normal RA will do.

How does PAR know FBU is sent from new link ?

> Source IP address = NCoA (as opposed to PCoA when FBU is sent from
old link)

------

> Change ``stateful'' to ``assigned''

> PrRtAdv Code values re-defined. Together with the Sub-Type field in
  LLA option, which is always present, different scenarios are
  realized.

> Access Point definition in the Terminology section

> Numerous editorial fixes

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