[Mip6] Samitas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: Review of draft-irtf-mobopts-ro-enhancements-00)

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."
> 
> 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".

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."
> 
> Is this a deployment scenario? 100 milllion MNs per one HA?

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).

> Section 5.5 :
> 
> Please use a diagram to describe concurrency. It is too much text to
> follow.

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
>  be nice if this section analyzes the primary proposals in a concise
> manner.

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

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

Samita Chakrabarti wrote:
> 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
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6