Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 1 Jun 2005 20:22:57 -0700 (PDT)

Hello:

As per Basavaraj's request, I am posting my comments on this draft.

Thanks,
-Samita
---------------------------------------------------------------------------

Overall: This document has a lot of information of which significant part can 
         go to the appendix for details. Please shorten this draft. Currently,
         it is too long; at the end the reader can easily forget the purpose.
         This draft needs an editorial change for clear objectives/goals,
         list of deployable proposals and analysis of the suggested ones.
         Again, some more data to show when and how RO might be useful in 
         certain applications would be useful. 

section 1:
  " Mobile IPv6 [29], its
   IPv4 counterpart [28], and the Host Identity Protocol [9] are three
   dominant mobility-management protocols that the IETF has developed to
   facilitate the continued use of existing transport protocols and
   applications in an Internet with mobility support."

   Reference [9] refers to the 00 version of hip draft. At the present,
   both MIP6 and MIP4 are in more mature state than HIP. This sentence
   could be reworded to say something like "additionally  IETF is developing
   Host Identity Protocol [9] for mobility management".

   Typo :  Page 5 : s/has send/has sent/
           Page 6: s/lightway/lightweight/

section 2:

     Like to see the description in this section be a bit short and concise.
     Refering to draft-ietf-mip6-ro-sec makes sense to shorten
     this section.

Section 3.1:
       Like the diagram.
       3.2:
        s/could built/could build/
        Please shorten this section

      3.3:        
      "tree types" - three types?
        Here is a good place to refer to ro-sec document and point to certain
        sections of that document.

  Section 4.
         This paragraph is not clear. Please list the three items (latency,
         signalling and security improvement) as goals for clear readability.

   4.1 Last line could be:
       The delays introduced by the rest of the stack can be significant(see
        Section 6.3.1).
 4.2
      s/section Section 3/Section 3/

     "For example, of the 716 Mbps signaling
   overhead generated by 100 million route-optimized mobile nodes, 220
   Mbps goes through a home agent."

   Is this a deployment scenario? 100 milllion MNs per one HA?

Section 5.1 and 5.2

 Not clear about the enhancement of using "IP-address test" and "Protected 
Tunnel".
 Does it suggest a separate IP-address test other than HoTI COTI ?
 Is the "protected tunnel" between MN and CN - not sure what message these two
sections are carrying.

Section 5.3:

  After successful BU to HA, the MN-HA tunnel is created if it is not a refresh.
  So, how does the MN send optimistic RO to CN using Hoti msg while the tunnel
  is not configured yet ?

Section 5.5 :

   Please use a diagram to describe concurrency. It is too much text to follow.

Section 5.12 - 5.17:

   There are too many options to confuse the reader. Why do we need to list so
   many of them ? I think, mobopts draft should pick the strong improvement
  alternatives and list them in the main section. The rest should go to the
  appendix in a concise form. It has got too much information to process.

Section 6;
 What are the criteria to evaluate recent proposals?
 If section 5 lists all the proposals in much abbreviated form, then it'd
 be nice if this section analyzes the primary proposals in a concise manner.

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

---

From: Christian Vogt <[email-masked]>
Date: Thu, 02 Jun 2005 09:39:00 +0200

Hi Samita and Gerardo,

thank both of you very much vor your detailed comments on 
draft-irtf-mobopts-ro-enhancements-00.

We'll wait a little longer in case there are additional reviews.  You'll 
hear from us then.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Jun 2005 13:36:27 +0200

Hi Samita,

I incorporated your comments into the document.  Responses are inline.

Again, thanks a lot for the review.

- Christian

++++

> Overall: This document has a lot of information of which significant
> part can go to the appendix for details. Please shorten this draft.
> Currently, it is too long; at the end the reader can easily forget
> the purpose. This draft needs an editorial change for clear
> objectives/goals, list of deployable proposals and analysis of the
> suggested ones. Again, some more data to show when and how RO might
> be useful in certain applications would be useful.

James also listed a few sections that he thinks should be shortened.
You added sections 2, 3.2, and 5.12 through 5.17.  At the moment, I am
collecting these pointers.  Will cut the sections at the next stage.

> section 1: " Mobile IPv6 [29], its IPv4 counterpart [28], and the
> Host Identity Protocol [9] are three dominant mobility-management
> protocols that the IETF has developed to facilitate the continued use
> of existing transport protocols and applications in an Internet with
> mobility support."
> 
> could be reworded to say something like "additionally  IETF is
> developing Host Identity Protocol [9] for mobility management".

Ok, it's reworded.

> Typo :  Page 5 : s/has send/has sent/ Page 6: s/lightway/lightweight/
> 
Fixed.

> section 2:
> 
> Like to see the description in this section be a bit short and
> concise. Refering to draft-ietf-mip6-ro-sec makes sense to shorten 
> this section.

Ok.  The due reference to draft-ietf-mip6-ro-sec is now in the text.  As
far as shortening goes, see my first comment.

> Section 3.1: Like the diagram.

Thanks. :)

> 3.2: s/could built/could build/ Please shorten this section

See my introductory text.

> 3.3: "tree types" - three types? Here is a good place to refer to
> ro-sec document and point to certain sections of that document.

You are right; I put the reference in.

> Section 4. This paragraph is not clear. Please list the three items
> (latency, signalling and security improvement) as goals for clear
> readability.

Rewrote that part.

> 4.1 Last line could be: The delays introduced by the rest of the
> stack can be significant(see Section 6.3.1).

Ok.

> 4.2 s/section Section 3/Section 3/
> 
> "For example, of the 716 Mbps signaling overhead generated by 100
> million route-optimized mobile nodes, 220 Mbps goes through a home
> agent."
> 

I pass this question on to the folks working at operators or services
providers...

> Section 5.1 and 5.2
> 
> Not clear about the enhancement of using "IP-address test" and
> "Protected Tunnel". Does it suggest a separate IP-address test other
> than HoTI COTI ? Is the "protected tunnel" between MN and CN - not
> sure what message these two sections are carrying.

These two sections describe technique used in RFC 3775.  Their purpose
is mainly for completeness.

Anyway, I changed the first paragraphs of both section 5.1 and 5.2 to
make this clearer.  Also, the introductory text of section 5 mentions
that the section starts with techniques already used by RFC 3775.

> Section 5.3:
> 
> After successful BU to HA, the MN-HA tunnel is created if it is not a
> refresh. So, how does the MN send optimistic RO to CN using Hoti msg
> while the tunnel is not configured yet ?

The SA at the HA may point to an old CoA at the time the HoTI is
received because IPsec processing of the HoTI does not depend on the
CoA.  RFC 2401 defines that source addresses of the outer IPv6 headers
are not checked.  So the HoTI can pass even when sent from a new CoA.

However, the SA must be up-to-date when processing the HoT.  After all,
that message must be encapsulated somehow and eventually reach the MN at
its new attachment point.

See also RFC 3776, section 3.2 (Return Routability Signaling), section
5.2.2 (Return Routability Signaling; yes, the name is the same), and
section 6.6 (HoTI from the MN).

> Please use a diagram to describe concurrency. It is too much text to

Good idea.  Added a diagram.

> Section 5.12 - 5.17:
> 
> There are too many options to confuse the reader. Why do we need to
> list so many of them ? I think, mobopts draft should pick the strong
> improvement alternatives and list them in the main section. The rest
> should go to the appendix in a concise form. It has got too much
> information to process.

Yes, James also mentioned cutting these sections.  I see your point.

> Section 6; What are the criteria to evaluate recent proposals? If
> section 5 lists all the proposals in much abbreviated form, then it'd

In fact, much of the details that were discussed in this section
actually belonged to the Enhancement Toolbox section, so I moved it
over.  Also, I clarified the objective of this section, and rewrote
parts of it to make it more concise.

Allright.
- Christian

Samita Chakrabarti wrote:
> Thanks, -Samita
> This draft needs an editorial change for clear objectives/goals, list
> of deployable proposals and analysis of the suggested ones. Again,
> some more data to show when and how RO might be useful in certain
> applications would be useful.
> 
> section 1: " Mobile IPv6 [29], its IPv4 counterpart [28], and the
> Host Identity Protocol [9] are three dominant mobility-management
> protocols that the IETF has developed to facilitate the continued use
> of existing transport protocols and applications in an Internet with
> mobility support."
> 
> Typo :  Page 5 : s/has send/has sent/ Page 6: s/lightway/lightweight/
> 
> 
> 
> section 2:
> 
> Refering to draft-ietf-mip6-ro-sec makes sense to shorten this
> section.
> 
> 
> Section 3.1: Like the diagram. 3.2: s/could built/could build/ Please
> shorten this section
> 
> 3.3: "tree types" - three types? Here is a good place to refer to
> ro-sec document and point to
certain
> Section 4. This paragraph is not clear. Please list the three items
(latency,
> 4.1 Last line could be: The delays introduced by the rest of the
> stack can be
significant(see
> Section 6.3.1). 4.2 s/section Section 3/Section 3/
> 
> "For example, of the 716 Mbps signaling overhead generated by 100
> million route-optimized mobile nodes, 220 Mbps goes through a home
> agent."
> 
> Tunnel". Does it suggest a separate IP-address test other than HoTI
> COTI ? Is the "protected tunnel" between MN and CN - not sure what
> message
these two
> Section 6; What are the criteria to evaluate recent proposals? If
> section 5 lists all the proposals in much abbreviated form, then it'd

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 16 Jun 2005 11:17:22 -0700

> Again, thanks a lot for the review.
Thanks for the update.

>> while the tunnel is not configured yet ?

I see your point below on security association. However, I was asking 
whether this method
assumes that the optimisitc RO (HOTI) is sent through the old MN-HA 
tunnel before the new
tunnel is built  between MN-HA with the new COA?   Since HOTI does not 
depend on COA,
it is doable. Otherwise, BU to HA needs to be done first and then 
re-config the tunnel and then
HOTI through the new tunnel.

-Samita

---

From: Christian Vogt <[email-masked]>
Date: Fri, 17 Jun 2005 07:26:41 +0200

Hi Samita,

yes, you are right.

The HoTI needs to be sent through the *old* MN-HA tunnel when the MN 
chooses to send the HoTI/CoTI right after the BU for home registration.

- Christian