Subject: Re: [netlmm] Re: Ticket #166: Host Multi-Homing

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Aug 2007 13:26:07 -0700 (PDT)

Hi Sri,
  In sec. 6.8 of the base draft, you said:
One of the workarounds for this issue is to set the DNAv6
   configuration parameter, DNASameLinkDADFlag to TRUE and that will
   force the mobile node to redo DAD operation every time the interface
   comes up, even when DNAv6 does detect a link change .is it when dnav6 does detect or does not detect a link change?
I am confused?

Thanks,

--behcet
----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: Marco Liebsch <[email-masked]>
Cc: Hesham Soliman <[email-masked]>; Christian Vogt <[email-masked]>; NetLMM Mailing List <[email-masked]>
Sent: Tuesday, August 7, 2007 8:29:22 PM
Subject: RE: [netlmm] Re: Ticket #166: Host Multi-Homing

Hi Marco, 

> -----Original Message-----
> From: Marco Liebsch [mailto:[email-masked]] 
> Sent: Tuesday, August 07, 2007 1:19 AM
> To: Sri Gundavelli
> Cc: Christian Vogt; Hesham Soliman; NetLMM Mailing List
> Subject: Re: [netlmm] Re: Ticket #166: Host Multi-Homing
> 
> Hi Sri,
> 
> Sri Gundavelli wrote:
> > Hi Marco,
> >
> >
> > On Mon, 6 Aug 2007, Marco Liebsch wrote:
> >
> >> Hi Christian,
> >>
> >> That depends on the nature of the MNID and how the MNID is 
> mapped to
> >> the HNP. If the MNID is the same for both interfaces, then there
> >> is no conflict. If the MNID(s) distinguish interfaces (e.g. using
> >> the MAC address), mapping of such MNID to the same HNP should be
> >> avoided. This is beyond what the base spec describes, as the HNP
> >> assignment is out of scope. So, maybe the spec should cover a note,
> >> that resolving different MNIDs to the same HNP is not allowed.
> >> That's maybe more useful than just stating 'host multi-homing
> >> not supported'.
> >>
> >
> >
> > Hi Marco,
> >
> > There is a 1:1 relation between a mobile node and its identifier.
> > That is the implicit assumption. Now, for any reasons if the
> > identifiers are different across interfaces, the protocol does
> > not keep a relation between those identifiers and will allocate
> > different home network prefixes for different identifiers. So,
> > the current issues will not be valid in such scenario.
> I think there are two implicit assumptions, on the MNID and on
> the resolution of the MNID to an HNP. The assumption on the
> MNID is ok, but then the Term section should not indicate, that
> the MNID can be "... or any other type of identifier which may
> be specific to the access technology".

I think, this is a good point. We will word it differently. 

> 
> The assumption on how to resolve the MNID to an HNP is really
> implicit. If this is clear enough, good.
> 
> 
> >
> > But, I did not think, operators will allocate different identifiers
> > for different access technologies and expect seamless mobility
> > across those interfaces.
> >
> > If need be, we can state this assumption explicitly.
> I am fine with what you proposed in the reply to Christian and
> to take over Julien's and Vijay's text.
> 

Ok. Thanks

Sri

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

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 08 Aug 2007 14:27:27 -0700

Behcet Sarikaya wrote:
>    comes up, even when DNAv6 does detect a link change .
> 
> is it when dnav6 does detect or does not detect a link change?

It is typo. It should be "...even when DNAv6 does not detect a link 
change".

Vijay

> Cc: Hesham Soliman <[email-masked]>; Christian Vogt 
> <[email-masked]>; NetLMM Mailing List <[email-masked]>
> ------------------------------------------------------------------------
>