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

From: Julien Laganier <[email-masked]>
Date: Tue, 6 Mar 2007 09:05:59 +0100

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Mar 2007 13:02:47 -0800

Hi Julien,
We have discussed some concerns with having to support domain-wide
link-local uniqueness in the past. Let's discuss this further at the
meeting. Instead of the MN-AR draft discussion, I will add some time on
the agenda to discuss the shared last hop behavior and DNA interactions
in greater depth. 

Thanks,
Vidya

> -----Original Message-----
> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Tuesday, March 06, 2007 12:06 AM
> To: [email-masked]
> Cc: Narayanan, Vidya
> Subject: Re: [netlmm] Last hop link-local behavior
> 
> Folks,
> 
> 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.)
> 
> attached to two different links, with a single colliding 
> link-local, might attach to the same shared link.
> 
> 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
> 
> > 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
> >
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 7 Mar 2007 19:47:27 -0800

Achieving domain-wide link-local address uniqueness is very difficult. I
posted
some scenario's where it can get really complex. Establishing uniqueness on 
a single LMA is not sufficient. If nodes that are homed at different LMA's
visit the same MAG, now the MAG has to establish uniqueness across all the
LMA's. The protocol can get really complex to avoid this one corner case.
If DNAv6 MUST be assumed, we need to think of simple solution, such as 
configuring AR's with the link-local addresses of the other AR's or some
other simple technique. We can have some discussions in Prague.

Thanks
Sri

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 1:03 PM
To: Julien Laganier; [email-masked]
Subject: RE: [netlmm] Last hop link-local behavior

Hi Julien,
We have discussed some concerns with having to support domain-wide
link-local uniqueness in the past. Let's discuss this further at the
meeting. Instead of the MN-AR draft discussion, I will add some time on the
agenda to discuss the shared last hop behavior and DNA interactions in
greater depth. 

Thanks,
Vidya

> From: julien laganier [mailto:[email-masked]] On Behalf Of 
> Julien Laganier
> 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
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 8 Mar 2007 13:15:21 +0100

Hi Sri,

On Thursday 08 March 2007 04:47, Sri Gundavelli wrote:
> Achieving domain-wide link-local address uniqueness
> is very difficult. I posted some scenario's where it
> can get really complex. 

True, it gets complex whenever more than one LMA is 
used in the domain. 

One could say that it isn't domain-wide link-local 
address uniqueness which brings complexity/difficulty, 
but rather to have multiple LMAs :)

> Establishing uniqueness on a single LMA is not
> sufficient. 

Except if only one LMA is involved per domain ;)

> If nodes that are homed at different  
> LMA's visit the same MAG, now the MAG has to
> establish uniqueness across all the LMA's. 

As an alternative, a special designated LMA could be 
the sole LMA responsible of keeping track of 
link-local addresses. That would avoid to check 
uniqueness with each of the LMAs of the domain: 
uniqueness would only be check with the designated 
LMA.

> The protocol can get really complex to avoid this one
> corner case. If DNAv6 MUST be assumed, we need to
> think of simple solution, such as configuring AR's
> with the link-local addresses of the other AR's or
> some other simple technique. 

Yes we already agreed that having single link-local for 
all ARs would solve the problem for p2p links. But 
only for p2p links. 

I've been making the point that supporting *shared* 
links requires domain-wide link local uniqueness.

> We can have some discussions in Prague.

Certainly.

Best,

--julien

> We have discussed some concerns with having to
> support domain-wide link-local uniqueness in the
> past. Let's discuss this further at the meeting.
> Instead of the MN-AR draft discussion, I will add
> some time on the agenda to discuss the shared last
> hop behavior and DNA interactions in greater depth.
>
> Thanks,
> Vidya
>
> > From: julien laganier
> > [mailto:[email-masked]] On Behalf Of
> > Julien Laganier
> > 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
> > 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
> > 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.
> >
> > 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
> >
> > > discussion on
> > > 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
> >
> > > same) and hence doesn't expect all the
> > > link-local neighbors going away.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Vidya
> > >
> > >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 8 Mar 2007 10:43:43 -0800

Hi Julien,

Ok. Lets capture this and resolve this in Prague.

Regards
Sri 

-----Original Message-----
From: julien laganier [mailto:[email-masked]] On Behalf Of Julien
Laganier
Sent: Thursday, March 08, 2007 4:15 AM
To: Sri Gundavelli
Cc: 'Narayanan, Vidya'; [email-masked]
Subject: Re: [netlmm] Last hop link-local behavior

Hi Sri,

On Thursday 08 March 2007 04:47, Sri Gundavelli wrote:
> Achieving domain-wide link-local address uniqueness is very difficult. 
> I posted some scenario's where it can get really complex.

True, it gets complex whenever more than one LMA is used in the domain. 

One could say that it isn't domain-wide link-local address uniqueness which
brings complexity/difficulty, but rather to have multiple LMAs :)

> Establishing uniqueness on a single LMA is not sufficient.

> If nodes that are homed at different LMA's visit the same MAG, now the 
> MAG has to establish uniqueness across all the LMA's.

As an alternative, a special designated LMA could be the sole LMA
responsible of keeping track of link-local addresses. That would avoid to
check uniqueness with each of the LMAs of the domain: 
uniqueness would only be check with the designated LMA.

> The protocol can get really complex to avoid this one corner case. If 
> DNAv6 MUST be assumed, we need to think of simple solution, such as 
> configuring AR's with the link-local addresses of the other AR's or 

Yes we already agreed that having single link-local for all ARs would solve
the problem for p2p links. But only for p2p links. 

I've been making the point that supporting *shared* links requires
domain-wide link local uniqueness.

Certainly.

Best,

--julien

> meeting.
> Instead of the MN-AR draft discussion, I will add some time on the 
> > [mailto:[email-masked]] On Behalf Of Julien Laganier
> > 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.
> >
> > That behavior is certainly specific to support of shared link, and 
> > is not needed for pt-to-pt links, as we discussed earlier.
> >
> > > 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.
> > >

---

From: Julien Laganier <[email-masked]>
Date: Fri, 9 Mar 2007 09:20:46 +0100

Hi Sri,

Forgot to mention that, FWIW, our charter says "Out of 
scope for the first design are: [...] multiple 
mobility anchor points."

Multiple mobility anchor support doesn't go easily (if 
not conflict) with shared link support (because of 
multicast RAs, link-local uniqueness...) 

So, if the WG wants shared links support, such support 
should not be impeded by issues introduced by multiple 
mobility anchors.

But of course we can decide we don't want to support 
shared links.

Another possibility would be to support multiple 
mobility anchors on p2p links only, while shared links 
dould be limited to a single mobility anchor (and 
extensions to handle multiple could come later as an 
extension if there is interest.)

I think last option makes sense since it seems to 
satisfy both deployments scenarios of NETLMM: 

    - large NETLMM domains that needs multiple mobility
      anchor will typically be cellular network with
      p2p links.

    - shared links probably means 802.11, and hence
      smaller NETLMM domains that can be handled with a
      single mobility anchor.

--julien

On Thursday 08 March 2007 19:43, Sri Gundavelli wrote:
> > Achieving domain-wide link-local address
> > uniqueness is very difficult. I posted some
> > scenario's where it can get really complex.
>
> address uniqueness which brings
> complexity/difficulty, but rather to have multiple
> LMAs :)
>
> > If nodes that are homed at different LMA's visit
> > the same MAG, now the MAG has to establish
> > uniqueness across all the LMA's.
>
> > The protocol can get really complex to avoid this
> > one corner case. If DNAv6 MUST be assumed, we need
> > to think of simple solution, such as configuring
> > AR's with the link-local addresses of the other
> > AR's or some other simple technique.
>
> Yes we already agreed that having single link-local
> for all ARs would solve the problem for p2p links.
> But only for p2p links.
>
> > From: Narayanan, Vidya
> > [mailto:[email-masked]] Sent: Tuesday, March
> > 06, 2007 1:03 PM
> > > Julien Laganier Sent: Tuesday, March 06, 2007
> > > 12:06 AM
> > > To: [email-masked]
> > > Cc: Narayanan, Vidya
> > > 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.
> > >
> > > That behavior is certainly specific to support
> > > of shared link, and is not needed for pt-to-pt
> > > links, as we discussed earlier.
> > >
> > > links, I think we need to specify this behavior
> > > in the MN-AR interface (PMA defending
> > > addresses), and in the NETLMM protocol draft
> > > > 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.
> > > >
> > > > all its link-local neighbors and that may
> > > > impact some applications relying on the
> > > > link-local reachability of some of the
> > >
> > > neighbors. This
> > >
> > > > ______________________________________________
> > > >_ netlmm mailing list
> > > > [email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 9 Mar 2007 10:41:58 -0800

Hi Julien,

I think, multiple MAG support is very important for 
any deployment. Right now, the inclination is to 
support shared-links on the last hop (not the shared
prefixes), this was highly desired by Fred and some
others.

We need to solve the collision issue for the DNAv6
supported scenario. We will create one open issue for
this.

Thanks
Sri

-----Original Message-----
From: julien laganier [mailto:[email-masked]] On Behalf Of Julien
Laganier
Sent: Friday, March 09, 2007 12:21 AM
To: Sri Gundavelli
Cc: 'Narayanan, Vidya'; [email-masked]
Subject: Re: [netlmm] Last hop link-local behavior

Hi Sri,

--julien