Subject: [Mobike] Comments on draft-ietf-mobike-design-01.txt

From: <[email-masked]>
Date: Tue, 11 Jan 2005 10:49:15 -0600

Most of my comments are nits, although some are more substantial.  Take
what you think is helpful.  I didn't have time to review the whole
document in one sitting so more comments will come later.

 Available address:

      This definition is reused from
      [I-D.arkko-multi6dt-failure-detection] and refers to addresses
      which are available by an peer.  A few conditions must hold before
      an address in such a state.

1) I don't understand this.  I read the i-d referenced above and I did
understand that.  I think you need to replace this with more of that i-d
text.  I'm not sure how much of it to cut and paste.  What is here is
just too brief IMHO.

Peer Address Set:

      A subset of locally operational addresses that will sent
      communicated to another peer.  A policy available at the peer
      indicates which addresses to include in the peer address set.
      Such a policy might be impacted by manual configuration or by
      interaction with other protocols which indicate newly available
      addresses.  Note that the addresses in the peer address set might
      change over time.

2) Confusing.  The problem is that the word peer is ambiguous.  I fixed
it by actually labeling the two peers as peer A and peer B.  Here is a
suggestion:
 
We denote the two peers in this Mobike session by peer A and peer B.  A
peer address set is a subset of locally operational addresses of peer A
that are sent to peer B.  A policy available at peer A indicates which
addresses to include in the peer address set.  Such a policy might be
impacted by manual configuration or by interaction with other protocols
which indicate new (note: newly is not a word) available addresses.  

   3.1  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node attaches to, for example a wireless LAN, to obtain connectivity
   to some security gateway.  This security gateway might connect the
   mobile node to a corporate network, to a UTMS network or to some
   other network.

3) You mean UMTS, not UTMS, but wouldn't it be better to say 3G network?

Since only MOBIKE is relevant
   for this discussion the end-to-end communication between the MN and
   some destination server is not shown in Figure 1.

4) ... Since only MOBIKE communication from the MN to the gateway is
relevant for this discussion the end-to-end communication between the MN
and
some destination is not shown in Figure 1. (Two changes: a) add from the
MN to the gateway and b) delete server in destination server, doesn't
have to be a server)

As a result, some form
   of protocol exchange, denoted as 'MOBIKE Address Update',
5) As a result, a
   protocol exchange, denoted by 'MOBIKE Address Update',
(OK, very picky)

The protocol messages will
   travel along a new path whereby the old path and the new path will
   meet at the cross-over router.
6) There is really no technical significance of "meeting" at some router
labeled CR and calling it a cross over router (and we don't really know
what a cross over router is).  I would just label it as R instead of CR
and say:
The protocol messages will travel along a new path.

Potential future path through the network
                     (if Peer A and Peer B chance their preferred
                      address)

                     Figure 2: Multihoming Scenario
7) ... if Peer A and Peer B change (chance should be change)

Note, that the load-balancing inside one IKE SA is not provided by
   the MOBIKE protocol.  Each client uses only one of the available IP
   addresses at a given point in time.
8) Note that Mobike does not support load balancing between multiple IP
addresses.  That is, each peer uses only one of the available IP
addresses at a given point in time. (this is clearer to me, also you
switch from using the word peer to using the word client)

Let me know if you have questions.

-- Maureen
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Jan 2005 11:30:58 +0100

hi maureen, 

thanks for the review. please find some comments inline: 
 
> Most of my comments are nits, although some are more 
> substantial.  Take what you think is helpful.  I didn't have 
> time to review the whole document in one sitting so more 
> comments will come later.
> 
>  Available address:
> 
> 1) I don't understand this.  I read the i-d referenced above 
> and I did understand that.  I think you need to replace this 
> with more of that i-d text.  I'm not sure how much of it to 
> cut and paste.  What is here is just too brief IMHO.
> 

i see. i tried to avoid to perform a copy-and-paste but sometimes it is
necessary for editorial reasons. 

> 2) Confusing.  The problem is that the word peer is 
> ambiguous.  I fixed it by actually labeling the two peers as 
> peer A and peer B.  Here is a
> suggestion:
>  
> We denote the two peers in this Mobike session by peer A and 
> peer B.  A peer address set is a subset of locally 
> operational addresses of peer A that are sent to peer B.  A 
> policy available at peer A indicates which addresses to 
> include in the peer address set.  Such a policy might be 
> impacted by manual configuration or by interaction with other 
> protocols which indicate new (note: newly is not a word) 
> available addresses.  

i wanted to include an example to make it clearer. however, your suggestions
also seems to be fine for me. thanks./ 

> 3) You mean UMTS, not UTMS, but wouldn't it be better to say 

true. 

> 4) ... Since only MOBIKE communication from the MN to the 
> gateway is relevant for this discussion the end-to-end 
> communication between the MN and some destination is not 
> shown in Figure 1. (Two changes: a) add from the MN to the 
> gateway and b) delete server in destination server, doesn't 
> have to be a server)

sounds good as well./ 

>    protocol exchange, denoted by 'MOBIKE Address Update', 

also fine with me./ 

> 6) There is really no technical significance of "meeting" at 
> some router labeled CR and calling it a cross over router 
> (and we don't really know what a cross over router is).  I 
> would just label it as R instead of CR and say:

you are certainly right. i have reused one of my nsis figure where the cr is
a special node. i will fix it./ 

> 8) Note that Mobike does not support load balancing between 
> multiple IP addresses.  That is, each peer uses only one of 
> the available IP addresses at a given point in time. (this is 
> clearer to me, also you switch from using the word peer to 
> using the word client)

ok. 

> Let me know if you have questions.
thanks for your suggestions. 
i will incorporate them into the next version of the draft. 

ciao
hannes