Subject: Re: [netlmm] Last hop link-local behavior

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 6 Mar 2007 07:33:26 -0800 (PST)

Julien,
  Thanks for using PMA not MAG 
I think that is the natural term to use too.
Another note, I read DNAv6, the underlying assumption there is the shared link concept. I do not think that it applies the newly emerged p2p link concept. 
Are there technical issues in supporting MN connected to a shared link but allocated HoA prefix/address from its home link?

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]
Sent: Tuesday, March 6, 2007 2:05:59 AM
Subject: Re: [netlmm] Last hop link-local behavior

Folks,

Forgot to reply to that note...

I am assuming that support of "shared link-local 
behavior" means that support of shared links as last 
hop of the domain.

In that case, I tend to agree with Vidya's statement 
that shared link on the last hop seems reasonable to 
support, and could be made in a manner that does not 
break anything.

However, I think that if we want not to break DNAv6, 
then we'd have to ensure link-local uniqueness across 
the entire NETLMM domain (and that is different, as 
Vidya noted below, from saying that shared link-local 
semantics spans the entire NETLMM domain, i.e. two 
nodes on different links can communicate using their 
link-local addresses.)

Such domain-wide uniqueness is needed because two MNs 
attached to two different links, with a single 
colliding link-local, might attach to the same shared 
link.

This can be achieved by having the PMA defending any 
link-local already used in the domain when a MN does 
DAD upon first attachment. To know which address to 
defend, the PMA would need to consult the LMA.

That behavior is certainly specific to support of 
shared link, and is not needed for pt-to-pt links, as 
we discussed earlier. 

Bottom line is that if we want to support shared links, 
I think we need to specify this behavior in the MN-AR 
interface (PMA defending addresses), and in the NETLMM 
protocol draft (PMA consulting LMA to know already 
registered addresse.) 

What do you think?

--julien

On Tuesday 13 February 2007 07:08, Narayanan, Vidya 
wrote:
> All,
> This is a topic on which we have had a lot of
> discussion on the list. I tried collecting offlist
> feedback on potential problems with having last hop
> shared link-local behavior and have been unable to
> get any useful pointers to what is really broken
> with that model. If the shared link-local semantics
> spanned the entire NETLMM domain, it is obviously
> problematic and we've all agreed that is not
> required. However, at this point, shared link-local
> behavior on the last hop (between the MN and the AR)
> seems reasonable to support.
>
> I suggest that we document clearly that this means
> that the AR is serving as the default router and
> that upon movement, the MN will lose all its
> link-local neighbors and that may impact some
> applications relying on the link-local reachability
> of some of the neighbors. This is especially true if
> the applications are unaware of the link change (as
> would typically be the case when the global IP
> address remains the same) and hence doesn't expect
> all the link-local neighbors going away.
>
> Thoughts?
>
> Thanks,
> Vidya
>
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
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: Julien Laganier <[email-masked]>
Date: Wed, 7 Mar 2007 14:43:45 +0100

Behcet,

On Tuesday 06 March 2007 16:33, Behcet Sarikaya wrote:
> Another note, I read DNAv6, the underlying
> assumption there is the shared link concept. 

I think DNAv6 is orthogonal to shared/p2p property of 
the underlying link.

> I do not think that it applies the newly emerged p2p
> link concept. 

But Vidya's note that triggered my answer (see below) 
explicitly asked about supporting shared links as last 
hop of a NETLMM domain. 

So it seems like in that context shared links 
considerations applies, and p2p links aren't to be 
discussed :)

> Are there technical issues in supporting MN connected
> to a shared link but allocated HoA prefix/address
> from its home link? 

See my note below, there's an issue of two MN with same 
link local, not colliding yet since they're attached 
to different links. When they later move onto the same 
*shared* link, link local collision does occur.

This collision won't be detected a priori because per 
DNAv6, DAD isn't re-executed when subnet prefix does 
not change, which is always the case when changing 
links in a single NETLMM domain. 

So we might want to make sure two MN in a single NETLMM 
domain never configures same link-local because they 
might move onto the same link later on.

Best,

--julien

> then we'd have to ensure link-local uniqueness
> across the entire NETLMM domain (and that is
> different, as Vidya noted below, from saying that
> shared link-local semantics spans the entire NETLMM
> domain, i.e. two nodes on different links can
> communicate using their link-local addresses.)
>
> Such domain-wide uniqueness is needed because two
> MNs attached to two different links, with a single
> colliding link-local, might attach to the same
> shared link.
>
> shared link, and is not needed for pt-to-pt links,
> as we discussed earlier.
>
> Bottom line is that if we want to support shared
> links, I think we need to specify this behavior in
> the MN-AR interface (PMA defending addresses), and
> in the NETLMM protocol draft (PMA consulting LMA to
> know already registered addresse.)
>
> What do you think?
>
> --julien
>
> > feedback on potential problems with having last
> > hop shared link-local behavior and have been
> > unable to get any useful pointers to what is
> > really broken with that model. If the shared
> > link-local semantics spanned the entire NETLMM
> > domain, it is obviously problematic and we've all
> > agreed that is not required. However, at this
> > point, shared link-local behavior on the last hop
> > (between the MN and the AR) seems reasonable to
> > support.
> >
> > applications relying on the link-local
> > reachability of some of the neighbors. This is
> > especially true if the applications are unaware of
> > the link change (as would typically be the case
> > when the global IP address remains the same) and
> > hence doesn't expect all the link-local neighbors
> > going away.
> >
> > Thoughts?
> >
> > Thanks,
> > Vidya
> >
> >