[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

Brian,

Thanks a lot on your comments.

                                ... the other host can
   alternate between IPv4 and IPv6 without any effects on the upper
   layer protocols.


The last phrase isn't strictly true IMHO. If a change of path changes
the MTU or the QoS, this can have an effect on the ULP, especially for
real time applications.

I changed this to read:

                                    ... the other host can alternate
      between IPv4 and IPv6, without needing to tear down and
      re-establish upper layer protocol connections or associations.
      In other words, the way upper layer protocols need to react to
      cross-IP-version handovers does not differ from the way they
      needs to react intra-IP-version handovers.

Better?


4.1 End-host mobility
... 
           The upper
   layer protocols need to know about the address and connectivity
   change only for QoS and other similar purposes.


Not necessarily. The QoS management system may need to know, depending
on the QoS mechanisms in use - and that is a control plane, not a
ULP.


I'm afraid I don't quite understand your comment.  Anyway, I changed
the text to read

                               The upper layer protocols do not
        need to know about the address and connectivity change
        but perhaps to react to changed QoS, MTU, or for other
        similar purposes.  In most cases, they do not need to
        know.

Any better?

Hmm. I find the whole treatment of "interfaces" confusing. As you describe
them, they don't correspond to physical interfaces or to virtual interfaces
such as tunnel end points. They are only collections of addresses, which
you choose to group for SPI purposes. That may or may not be a useful thing,
but it would be much less confusing to use a different word instead
of overloading "interface." 

I changed the term to "Address Group", and updated the rest of the
spec accordingly.

Note,
however, that especially in the case of site multi-homing one of the
addresses may become unreachablewhile the other one still works. In
the typical case, however, this does not require the host to inform
its peers about the situation, since even the non-working address
still logically exists.

It's just as well you don't require this notification. The last node to
know that an address is unreachable is the node that address belongs to.
Unreachability is discovered at the other end of the multihomed
session. 

Thanks.  I'll try to note this in the other draft; I don't see how
this would be formulated here.

   The readdressing protocol is designed to be piggybacked on a number
   of existing HIP exchanges. ...

   The protocol is an asymmetric protcool where one host, called the
   Mobile Host, informs another host, called the Peer host, about
   changes of IP addresses on one of its interfaces.


That doesn't help with multihoming, since the host doesn't know about
its own address changes due to sudden unreachability.


While I agree with your comment, I'm afraid I don't quite see the
point.  The assumption is that the HIP hosts announce their
multi-homing situation as soon as they create HIP associations,
modulo possible privacy and policy concerns.  Hence, when a host
becomes unreachable through one of its addresses, its peers already
know about the other potential addresses.

Should I discuss this in the forthcoming -nikander-multi6-hip-
draft?

Section 8.4 Changing the preferred address mentions that:

   A host MAY want to change the preferred outgoing address for many
   reasons, e.g., because traffic information or ICMP error messages
   indicate that the currently used preferred address may have become


That is meant to cover the case where ULP information, such as TCP
timeouts, indicate that the preferred address needs to be changed.
But maybe the term "traffic information" is inaccurate and should be
replaced with something better.  Any suggestions?

--Pekka