[Mobopts] Re: Comments on draft-irtf-mobopts-mpa-framework-00.txt

Hi Marco,
          Appreciate your review and useful feedback and comments on 
draft-irtf-mobopts-mpa-framework-00.txt. Please see inline for the 
answers to your questions and comments.

	We have taken care of many of the comments in the revised version 
(draft-irtf-mobopts-mpa-framework-01.txt) of the draft that we submitted 
recently. I am sending it to the MOBOPTS mailing list for further 
discussion.

Regards
Ashutosh

Marco Liebsch wrote:
 > Hi Ashutosh,
 >
 > please find attached some quick and initial comments, which you
 > may consider as general comments and some editorial comments.
 >
 > Maybe some of my general comments are due to misunderstanding
 > or because I did not dig into this work beforehand. I could
 > not look at all thinks in detail so far, but maybe you find
 > some comments useful for the discussion.
 >
 > See you in Vancouver,
 >
 > marco

**************************************************************************

Comments to Media-Independent Pre-Authentication Framework for
Inter-Domain Handover Optimization,

draft-irtf-mobopts-mpa-framework-00.txt

General:
========

2. Inter-domain Handover

3rd paragraph, last sentence: "...change its L3 identifier depending 
upon..." I don't think the *identifier* changes here, but the *locator*. 
At least for Mobile IP-like protocols. I guess the same is valid for 
SIP, where name@realm is the ID, whereas its registered IP address 
serves as locator.

=> Identifier changed to locator in the respective places

Figure 1:
Figure should look simpler. You use many specific functional components
in the drawing without explaining them in the text. I propose to reduce 
them and keep most relevant ones for this general description. This 
could be the AAAH  and the AAAF (or AAAV). AA is not important here to 
get the point (?). The few key  components should be summarized in the 
text of section 2. Most of these components come back later in Figure 2 
anyhow (AA, etc.)

=> Added the descriptions of AAAv, AAAH, AA, AR etc. briefly to this 
section to describe the components of Figure 1.

6.3 Basic Communication FLow

Comment to Step 3: "...by executing the binding update operation..."
In Mobile IP(v6) sending a binding update is usually triggered by
reception of an on-link router advertisement or agent advertisement and
subsequent configuration of a routable IP address at the interface.
These will not be advertised on the established tunnel by default
(and the tunnel is set up only 'after' the address has been configured, 
right?)

=> This is a good point. In MIPv6, binding update is dependent on 
receipt of on-link router advertisement. Thus, the mobile needs to 
detect the on-link router advertisement from the NAR tunneled through 
the transient tunnel before the proactive binding update could be sent 
out from the mobile. We have added a mechanism to send the RA tunneled 
through the transient tunnel, so that the mobile can send the proactive 
binding update based on the receipt of the router advertisement.

Also the mobile must be modified to distinguish 'local' IP address 
configuration and 'remote' IP address configuration. This requires 
modification of hosts and protocols for MM, Address configuration. Is 
all this supported by an MPA-enabled MN? If modification of Mobile IP is 
required, it's not really agnostic/independent to the mobility 
management protocol, which I understand is one of the design goals. 
However, for a framework is should be ok as it is.

=> There is no need to change the mobility protocols, as such. Thus, 
modification of Mobile IP is not required either. But the host may need 
some modification, so that it can interact properly with the mobility 
protocols, such as Mobile IP or SIP while performing the required 
optimization functions. End host  may need additional software to 
interact with mobility protocols and perform other related MPA related 
functions.

7.4 Address resolution

I would not say DAD is part of address resolution but address 
configuration. I see this rather located in 7.3. But DAD for stateless 
address configuration is not considered, is it? As long as there is no 
tunnel to the target subnet in the CTN, it's difficult to perform DAD 
with the NDP.

=> DAD part has been moved to Section 7.3. Clarified few steps with 
respect to DAD operation for stateless auto-configuration.

7.7.2 Preventing packet loss for multiple interfaces

Why is pre-authentication through the previous interface required
here? The new interface can be powered and attached while the
previous one maintains the session? That's one advantage of
multi-mode terminals. Or did I misunderstand something here?

=> As mentioned elsewhere in the document, applicability of MPA is more 
compelling for single interface case. However, in case of multiple 
interface case, use of previous interface to perform certain MPA related 
operations is desirable for scenarios, such as

1) Saving battery power

2) In case of non-overlapping access or sudden disconnection

3. In case the carrier does not support simultaneous use of multiple 
interfaces.

Authentication and attach to CDMA network via WLAN seems difficult,
as techno/System specific IDs (e.g. IMEI, IMSI) are
used and temporary IDs will be assigned (TMSI). But I must admit, that
this of course depends on how efficient an AA and CA can be integrated 
with a CDMA-based target network and how powerful the protocol interface 
between MN and AA/CA is.

=> In case of multi access networks, for some types of target access 
networks, not all the steps of  MPA could be possible. It could just 
perform pre-authentication vs. combination of pre-authentication and
preconfiguration, or all the steps mentioned in Section 6. In a typical 
WiFi-CDMA handoff operation, some of the PPP context can be set up ahead 
of time by using WiFi interface.

general comment: tunneling data between two ARs belonging to
different domains can imply quite some delay in case such packets
traverse always the top gateway router of the domain. I am wondering
if the proactive tunnel brings always the expected performance gain
compared to MM-tailored solutions.

=> MPA uses a transient tunnel between NAR and the mobile in PoA. It is 
true that, in case of inter-domain handoff, these entities could be 
far-off logically. Thus, the signaling and data during 
pre-authentication period will take a longer route, and thus, may be 
subjected to longer one-way-delay. Thus, it is a tradeoff between larger 
packet loss or larger one-way-packet delay  for a transient period, when 
the mobile is preparing to handoff.

summary: Very good work! Lot of things have been considered, such
as different means for address acquisition, etc. Individual protocol
components and needs have been evaluated thoroughly.
To make an MPA framework for handover working in a particular system,
I expect major modifications to existing components, such as address
configuration, MM, local routing table management on MNs.

=> Since MPA framework is supposed to provide helper techniques to 
optimize the existing mobility management protocols, certain 
changes/modifications are needed on the mobile and router based on what 
part of MPA procedures are used inter-domain handoff.

Editorial:
==========

1.1 Performance Requirements

last paragraph repeats what's aid already above already (ITU delay 
bounds). Looks redundant and can be merged.

=>Merged

2. Inter-domain Handover

4th paragraph: "...will be sujected..." -> "...will be subjected..." (?)

=> changed

3. Existing work on Fast Handover

Minor comment on the first paragraph: MM protocols don't suffer from 
handover delay, rather applications and performance do. MM works even 
with large handover latency.

=> rephrased

"...propose a scheme reduces the delay..."  -> "...propose a scheme 
that/which reduces the delay..."

=> Fixed

4. Applicability of MPA

first paragraph mentions the 'CTN'. You should introduce abbreviations 
first before using them. Just write Candidate Target Network (CTN). 
Later you explain it anyhow in section 5.

=> Description of CTN added

6.1 Overview

"...CTN as well as a execute tunnel..." -> "...CTN as well as execute a 
tunnel..."

"...before attaching to the the target..." -> "...before attaching to 
the target..."

=> typos fixed

6.2 Functional Elements

"...in one more network devices..." -> "...in one or more network 
devices..."

=> Fixed
6.3

[page 20] last sentense CH -> CN

=> Fixed

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts