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

[Brian E Carpenter <brc@zurich.ibm.com>]

Pekka,

Pekka Nikander wrote:
> 
> 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?

Fine, thanks

> 
> >
> >> 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?

That is fine. What I meant is that in many implementations of diffserv QOS,
the socket user knows nothing about it - a QOS manager of some kind is
strapped onto the side of the IP stack and directs the IP stack to apply 
different diffserv treatments to different sockets. And actually when
the path changes the QOS manager may well care (because different paths may
have different QOS capabilities).

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

Yes, I really find that much clearer.

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

OK, maybe I read your text too quickly. In general multi6 needs to think
a bit about what actually triggers a multihoming switch.

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

Yes, I think it fits there.

> 
> 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?

At this stage I would stick to something quite general. This is going to
be a question for all solutions, I think.

Regards
   Brian