Subject: RE: [netlmm] Addressing Model Discussion Conclusion

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Aug 2006 14:03:10 -0700

in RFC 3314, there is an implicit assumption that there
is a GTP link between the terminal and the GGSN. its a
point-to-point link.

Vijay 

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 11:29 AM
> To: Vijay Devarapalli; Mohamed Khalil
> Cc: [email-masked]
> Subject: Re: [netlmm] Addressing Model Discussion Conclusion
> 
> The same way it is done in RFC 3314.
> 
>             jak
> 
> ----- Original Message ----- 
> From: "Vijay Devarapalli" <[email-masked]>
> To: "Mohamed Khalil" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 09, 2006 11:09 AM
> Subject: Re: [netlmm] Addressing Model Discussion Conclusion
> 
> 
> > Mohamed Khalil wrote:
> >> Hi Syan,
> >> 
> >> I think p2p link or shared link is independent of how the 
> network prefix
> >> will be assigned to the MT. In both shared and p2p we 
> still could assign
> >> a unique network prefix to the MT.
> > 
> > in a shared link, how do you restrict the MN to just
> > one prefix. the MN would would see all the prefixes.
> > a plain IPv6 MN may start configuring address from
> > all the prefixes it sees.
> > 
> > Vijay
> > 
> >> 
> >> -----Original Message-----
> >> From: Syam Madanapalli [mailto:[email-masked]] 
> >> Sent: Wednesday, August 09, 2006 9:57 AM
> >> To: Roberts Phil-APR042
> >> Cc: [email-masked]
> >> Subject: Re: [netlmm] Addressing Model Discussion Conclusion
> >> 
> >> 
> >> Hi,
> >> 
> >> When one or more unique prefixes are used per MN, MN and 
> AR should be on
> >> p2p link, So I am wondering how is this p2p link is 
> modeled. Is there a
> >> plan to use any p2p protocols below the IP layer or it is 
> assumed that
> >> the layer 2 provides a p2p connection so that the AR sees 
> each MN at
> >> different interface?
> >> 
> >> -Syam
> >> 
> >> 
> >> On 8/9/06, Roberts Phil-APR042 <[email-masked]> wrote:
> >>>
> >>>
> >>> The WG has been discussing what kind of addressing model 
> to use for 
> >>> NETLMM for the past few weeks. It seems from the email like most 
> >>> people favor the prefix per mobile node model over a shared link 
> >>> model, though there is still a lack of shared 
> understanding about the 
> >>> details of how the prefix per mobile node model should be 
> implemented.
> >> 
> >>> From the discussion, it does seem though as if there are fewer 
> >>> technical issues with using that model for the kinds of 
> deployments 
> >>> that are envisioned for NETLMM at least initially. Is 
> there anybody at
> >> 
> >>> this time that has any significant issues with making the 
> prefix per 
> >>> mobile node the default NETLMM model initially?
> >>>
> >>>
> >>>
> >>> Note that this does not preclude people bringing forth 
> further work 
> >>> down the line on the shared link model once we have the initial 
> >>> charter complete and are ready to recharter.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> > 
> > 
> > _______________________________________________
> > 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, 9 Aug 2006 19:24:35 -0700

thanks for the correction. 

my point was that it is a point-to-point link, where 
each link gets it own /64 prefix and the prefixes 
never leak.

Vijay

ps: I got a lot of emails correcting me on this. :)

> From: Pradeep, Peter (Peter) [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 6:30 PM
> To: Vijay Devarapalli; 'James Kempf'; 'Mohamed Khalil'
> Cc: [email-masked]'
> Subject: RE: [netlmm] Addressing Model Discussion Conclusion
> 
> Vijay
> 
> GTP link is not between the Terminal and GGSN.
> GTP link is between the GGSN & the SGSN.
> 
> Pradeep
> 
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, August 10, 2006 2:33 AM
> To: James Kempf; Mohamed Khalil
> Cc: [email-masked]
> Subject: RE: [netlmm] Addressing Model Discussion Conclusion
> 
>

---

From: "Julien Laganier" <[email-masked]>
Date: Fri, 11 Aug 2006 21:11:23 +0200

Hi Vijay,

> Julien Laganier wrote:
> > 
> > On Thursday 10 August 2006 20:41, Vijay Devarapalli wrote:
> >> Julien Laganier wrote:
> >>>> you would need to update router discovery. see section
6.2.6
> >>>> of RFC 2461.
> >>>>
> >>>>     A router MAY choose to unicast the
> >>>>     response directly to the soliciting host's address
(if the
> >>>>     solicitation's source address is not the unspecified
> >>>> address), but the usual case is to multicast the
response to the
> >>>> all-nodes group.
> >>> No we do not need to update router discovery / RFC2461.
Per 2461
> >>> sending unicast RAs is allowed (this is a MAY above) so
we are
> >>> allowed to do it, and we can specify in a NetLMM spec
that a MAG
> >>> MUST send unicast RAs.
> >> sure you can do this but its not enough. you would
> >> need to modify a bunch of things for this to work.
> > 
> > Agree with most of what you proposed below. Just a
terminology point 
> > however. We do not need to update/modify/override/relax
anything in 
> > 2461; we're just using the flexibility provided by 2461
(there are no 
> > MUST preventing anything of what is needed.) What we'd
need is to 
> > specify what behavior we want to have in the context of that 
> > flexibility.
> 
> call it whatever you want. point is you need additional
> specification in the NETLMM WG. with a mobile node and a
> access router that implements RFC 2461 you can't restrict
> the MN to one prefix on a shared link.

That's what I said above: we do need to specify MAG behavior,
we do not need to update 2461.

[...]

> >> - relax the SHOULD in section 4.2 of RFC 2461
> >>      A router SHOULD include all its on-link prefixes
> >>      (except the link-local prefix) so that multihomed
> >>      hosts have complete prefix information about on-
> >>      link destinations for the links to which they
> >>      attach.
> > 
> > Well, most likely we're going to advertise prefixes as
"not on-link" 
> > i.e. 'L' bit is reset, so perhaps it is somehow consistent
with the 
> > above.
> 
> the 'L' bit set to 1 says the prefix are on-link. 'L' bit
> set to 0 says nothing. the prefix may or may not be on-link. :)
> 
>        L              1-bit on-link flag.  When set,
indicates that this
>                       prefix can be used for on-link
determination.  When
>                       not set the advertisement makes no
statement about
>                       on-link or off-link properties of the
prefix.  For
>                       instance, the prefix might be used for
address
>                       configuration with some of the
addresses belonging
>                       to the prefix being on-link and others
being off-
>                       link.

We discussed that already; see:

<http://www1.ietf.org/mail-archive/web/netlmm/current/msg00053.html>

[...]
 
> >> - an unsolicited router advertisement cannot be avoided
> >>    since this is needed by the MN to obtain the link
> >>    layer address of the MAG (through the source link
> >>    layer address option in the router advertisement).
> >>    now we have to figure out what the timer should be
> >>    for the unsolicited router advertisements.
> > 
> > I don't understand why the MN need an *unsolicited* RA. If
the MN has 
> > DNA it will issue an RS when it gets link_UP trigger, and
the MAG 
> > will reply with a *solicited* RA containing its link-local
and 
> > link-layer addresses.
> 
> two things to consider
> 
> 1. are you going to require DNA between the MN and the MAG
> for NETLMM to work?

Yes DNA has been the assumption so far. You can check in the
archive, which is weirdly no longer accessible, but luckily
cached by Google:

Google for "netlmm/2006-March/000845.html" and look at the
cached page.

> 2. if there is more than one MAG on the access link, every
> MAG would receive this router solicitation. then you have
> to figure out which one manages the MN. maybe multiple MAG
> on a shared link has not been discussed enough so far.

My personal opinion on that matter is that a typical NetLMM
deployment as only one router per link. If router redundancy
is desired then one can use VRRP. Other persons may
agree/disagree.
 
> things would be lot simpler if you assume point-to-point
> links.

Perhaps, but they are also simpler if we assume one router per
link (or VRRP.) And, as I already said before goal #7 of our
requirement draft calls for link layer agnosticism.

Best,

--julien

PS: I'm going to be off two weeks so I will probably not be
able to continue discussion until I come back.

Cet été, pensez aux cartes postales de laposte.net !