Subject: Re: [Mip6] How to store DNS records about HAs, (draft-ietf-mip6-bootstrapping-split-02.txt)?

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 1 May 2006 11:38:49 +0200

Hi Alex and Kuntal,

one comment below...

> > If operator considers storing 3 fqdns in each phone as not minimal,
> what
> > protocol would operator use to store each location's HA address in the
> > DNS?  And how would MN know to query the DNS for a specific location
> HA
> > when all it has is just one fqdn?
> >
> [KC>] Normally, allocation of the most optimum home agent based on the
> MN's point of attachment is done in the network. I think your question
> is a valid one, i.e. how does the operator do that using DNS. May be
> some clarification is required on this (if not there already).
>

Currently this is not possible using the solution defined for split
scenario. In this draft, only HA discovery is possible and this is not
possible to achieve a "location-based" HA assignment. Note that this
is also a consequence of split scenario definition: there is no link
between the location of the MN (i.e. ASP) and the MSP.

IMO, this limitation is well covered in the draft, also discussing
load balancing. But, please any suggestion on how to improve the
document is welcome.

I think HA assignment is much more useful in integrated scenario; this
is why the DT chose DHCP in that scenario.

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 14:01:33 +0200

Gerardo Giaretta wrote:
>>> protocol would operator use to store each location's HA address 
>>> in the DNS?  And how would MN know to query the DNS for a 
>>> specific location
>> HA
>> [KC>] Normally, allocation of the most optimum home agent based on 
>> the MN's point of attachment is done in the network. I think your 
>> question is a valid one, i.e. how does the operator do that using 
>> DNS. May be some clarification is required on this (if not there 
>> already).
>> 
> 
> scenario. In this draft, only HA discovery is possible and this is 
> not possible to achieve a "location-based" HA assignment. Note that 
> this is also a consequence of split scenario definition: there is no 
> link between the location of the MN (i.e. ASP) and the MSP.
> 

Yes.

Improving a document is a useful.  It's also good to keep the document
short and tractable.

For split, (1) specify that HA updates the DNS with its own address,
maybe via DHCP, with a new type of SRV record or (2) eliminate the claim
of SRV helping with load balancing.  The latter seems to me to be least
work.

For integrated, clarify what is the pre-configured information before
bootstrapping (NAI apparently).  Clarify that a domain name encompasses
several subnets each comprising its own set of HAs.  Clarify how using
only one NAI key for searching addresses this search (a search should
retrieve only one subnet's set of HAs, not entire domain's).  This seems
much work to me.

Does this make sense?

Alex
PS: I don't think there's a clearcut  difference between "HA discovery"
and "HA assignment".  DHAAD is mainly discovery but its effect is that
MN gets its HA address, thus it is assigned the HA address.

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 2 May 2006 18:04:17 +0200

Hi Alex,

I will reply for the split document, letting Kuntal the details of the
integrated.
> of SRV helping with load balancing.  The latter seems to me to be least

We have already stated that a fine-grained load balancing is not
possible using DNS. We have this paragraph in section 5.1:

        This document does not provide a specific mechanism to load
balance different
        Mobile Nodes among Home Agents. It is possible for an MSP to
achieve coarse-
        grained load balancing by dynamically updating the SRV RR
priorities to reflect
        the current load on the MSP's collection of Home Agents.
Mobile Nodes then use
        the priority mechanism to preferentially select the least
loaded HA. The
        effectiveness of this technique depends on how much of a load
it will place on
        the DNS servers, particularly if dynamic DNS is used for
frequent updates.

Isn'it enough?

> MN gets its HA address, thus it is assigned the HA address.

I think there is a big difference from an operator perspective; the HA
assignment implies that an operator may assign a specific HA to a
specific MN.

This is not possible with HA discovery (e.g. based on DNS).
This is possible using the solution provided in the integrated draft.

--Gerardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 18:42:53 +0200

Gerardo Giaretta wrote:
> Hi Alex,
> 
> I will reply for the split document, letting Kuntal the details of 
> the integrated.
>>> IMO, this limitation is well covered in the draft, also 
>>> discussing load balancing. But, please any suggestion on how to 
>>> improve the document is welcome.
>> 
>> Yes.
>> 
>> Improving a document is a useful.  It's also good to keep the 
>> document short and tractable.
>> 
>> For split, (1) specify that HA updates the DNS with its own 
>> address, maybe via DHCP, with a new type of SRV record or (2) 
>> eliminate the claim of SRV helping with load balancing.  The latter
>>  seems to me to be least work.
>> 
> 
> This document does not provide a specific mechanism to load balance 
> different Mobile Nodes among Home Agents. It is possible for an MSP 
> to achieve coarse- grained load balancing by dynamically updating the
>  SRV RR priorities to reflect the current load on the MSP's 
> collection of Home Agents. Mobile Nodes then use the priority 
> mechanism to preferentially select the least loaded HA. The 
> effectiveness of this technique depends on how much of a load it will
>  place on the DNS servers, particularly if dynamic DNS is used for 
> frequent updates.
> 
> Isn'it enough?

Looks ok, if I assume that "fine-grained" load balancing is the one
achieved with DHAAD and "coarse-grained" load balancing is the one
assigning HA from different subnets.

Maybe one should add that when assigning a HA from subnet different than
the previous (with coarse-grained load balancing) the MN HoA will
change and previous communications are not guaranteed to be continued.

>> For integrated, clarify what is the pre-configured information 
>> before bootstrapping (NAI apparently).  Clarify that a domain name
>>  encompasses several subnets each comprising its own set of HAs. 
>> Clarify how using only one NAI key for searching addresses this 
>> search (a search should retrieve only one subnet's set of HAs, not
>>  entire domain's).  This seems much work to me.
>> 
>> Does this make sense?
>> 
>> Alex PS: I don't think there's a clearcut  difference between "HA 
>> discovery" and "HA assignment".  DHAAD is mainly discovery but its
>>  effect is that MN gets its HA address, thus it is assigned the HA
>>  address.
>> 
> 
> I think there is a big difference from an operator perspective; the 
> HA assignment implies that an operator may assign a specific HA to a 
> specific MN.

I agree that it may be advantageous for an operator to use a central
server assigning HA to MN centrally.

> This is not possible with HA discovery (e.g. based on DNS). This is 
> possible using the solution provided in the integrated draft.

Ok.

I think I look too much at MIP6 as a set of HAs running on every subnet,
while you seem to look at it as a central server independent of the
existing subnets, which assigns HAs to MN.

For example, with integrated scenario bootstrapping one could
accommodate a central server of a cell phone operator dynamically
assigning HA to its phone terminals.  But couldn't accommodate one's
laptop in an enterprise network, which is usually deep in that
Enterprise's subnet topology.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 May 2006 10:22:22 -0700

Alexandru Petrescu wrote:
> maybe via DHCP, with a new type of SRV record or 

I dont think this should be specified in the
split bootstrapping document. this is out of
scope for this document.

regarding your proposal, the HA does not use
DHCP to get it owns address. so it can't use
DHCP to update its DNS entries.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 20:20:32 +0200

Vijay Devarapalli wrote:
>> address, maybe via DHCP, with a new type of SRV record or
> 
> I dont think this should be specified in the split bootstrapping 
> document. this is out of scope for this document.
> 
> regarding your proposal, the HA does not use DHCP to get it owns 
> address. so it can't use DHCP to update its DNS entries.

I think you're right, but then how?

I think that if we agree that the "cold" bootstrapping should happen
only once, when out-of-the-box,  offering new HA/HoA data then
subsequent power-ups and related bootstrapping should offer same subnet
HA/HoA.  This can be achieved only if the DNS retrieves same data based 
on same key (maybe the fqdn).

But if we think that "cold" bootstrapping with a change in HoA happens 
any time the phone powers up then yes, no need to relate the HA 
subnet/HoA to the key MN uses for bootstrapping.

Alex