t's right. Thanks!
pars
> Bert
>
>
> > -Original Message-
> > From: James Kempf [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, September 20, 2006 3:03 PM
> > To: Pars MUTAF
> > Cc: Erik Nordmark; ipv6@ietf.org
> > Subject: Re: Proposal to change aspec
TECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>
> Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
> Sent: Wednesday, September 20, 2006 12:49 PM
> Subject: Re: Proposal to change aspects of Neighbor Discovery
>
>
> > Selon James Kempf <[EMAIL
on discussing it.
jak
- Original Message -
From: "Manfredi, Albert E" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, September 20, 2006 1:17 PM
Subject: RE: Proposal to change aspects of Neighbor Discovery
day, September 20, 2006 3:03 PM
> To: Pars MUTAF
> Cc: Erik Nordmark; ipv6@ietf.org
> Subject: Re: Proposal to change aspects of Neighbor Discovery
>
> So here's a counter example.
>
> Suppose there is an IP based but wireless link layer specific
> protocol that
iltering of the RA by the BS is too late. Because the host was
already paged in all cells and woken up.
pars
jak
- Original Message -
From: "Pars MUTAF" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Erik Nordmark" <[EM
nd woken up.
pars
>
> jak
>
> - Original Message -
> From: "Pars MUTAF" <[EMAIL PROTECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>
> Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
> Sent: Wednesday, S
MAIL PROTECTED]>
Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
Sent: Wednesday, September 20, 2006 10:16 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
Selon James Kempf <[EMAIL PROTECTED]>:
Why can't the BS simply filter the RA? It looks at the IP pa
riginal Message -
> From: "Pars Mutaf" <[EMAIL PROTECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>
> Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
> Sent: Wednesday, September 20, 2006 2:25 AM
> Subject: Re: Proposal to change aspects of Ne
;[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
Sent: Wednesday, September 20, 2006 2:25 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
On Mon, 2006-09-11 at 20:02 +0200, Pars Mutaf wrote:
Hello,
the way 3GPP2 does it. Of
> > course, maybe IETF doesn't care in the end whether or not this gets
> > deployed
> > in cellular networks, in which case, leaving it as it is in RFC 2461 and
> > saying "if you feel this is an issue for dormant mode hosts, then
t;[EMAIL PROTECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>
> Cc: "Basavaraj Patil" <[EMAIL PROTECTED]>; ; "ext
> Pars MUTAF" <[EMAIL PROTECTED]>
> Sent: Thursday, August 31, 2006 5:17 PM
> Subject: Re: Proposal to change aspect
Hi all,
I would like to thank Thomas for asking me an explanation
of my point of view (from the previous discussion
Re: Proposal to change aspects of Neighbor Discovery)).
But, I wasn't really hoping an IPv6 WG action on this
issue, in fact. Not because I think it is an L2 problem
(H
Hello,
On Wed, 2006-09-06 at 08:25 -0400, Thomas Narten wrote:
> Pars Mutaf <[EMAIL PROTECTED]> writes:
>
> > Thanks. But I still believe that a host should be able to test
> > if it is reachable in dormant mode (reachable, or reachable within
> > reasonable delay). This is good for dormant mode
Pars Mutaf <[EMAIL PROTECTED]> writes:
> Thanks. But I still believe that a host should be able to test
> if it is reachable in dormant mode (reachable, or reachable within
> reasonable delay). This is good for dormant mode security.
Why? This is a problem statement you are asserting. Rather tha
> The paging channel is not dedicated to one terminal, it serves
> all terminals (there are thousands of terminals in a paging area).
> Paging channels can be overloaded (naturally or maliciously). In
> this case, an incoming session may be missed.
=> This is completely orthogonal to thi
On Wed, 2006-09-06 at 02:29 -0700, Soliman, Hesham wrote:
>
> > Thanks. But I still believe that a host should be able to test
> > if it is reachable in dormant mode (reachable, or reachable within
> > reasonable delay). This is good for dormant mode security.
>
> => I'm not sure that you app
> Thanks. But I still believe that a host should be able to test
> if it is reachable in dormant mode (reachable, or reachable within
> reasonable delay). This is good for dormant mode security.
=> I'm not sure that you appreciate the fact that these are *logical*
channels, where *logical* m
On Tue, 2006-09-05 at 21:48 -0700, Soliman, Hesham wrote:
>
> > Hello,
> > I couldn't understand why NUD is the responsibility of IP,
> > but the other is not.
> >
> > So, why NUD isn't the link-layer's responsibility?
>
> => Because of two reasons:
> - Some link layers fon't have this co
> From: "Soliman, Hesham" <[EMAIL PROTECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>; "Thomas Narten"
> <[EMAIL PROTECTED]>
> Cc: "Erik Nordmark" <[EMAIL PROTECTED]>;
> ; "ext Pars
> MUTAF" <
> Hello,
> I couldn't understand why NUD is the responsibility of IP,
> but the other is not.
>
> So, why NUD isn't the link-layer's responsibility?
=> Because of two reasons:
- Some link layers fon't have this connection-oriented service and
therefore do not do NUD.
- NUD tests reachab
Pars MUTAF" <[EMAIL PROTECTED]>
Sent: Thursday, August 31, 2006 5:17 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery
James Kempf wrote:
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could ind
uot;James Kempf" <[EMAIL PROTECTED]>; "Erik Nordmark"
<[EMAIL PROTECTED]>; "Basavaraj Patil" <[EMAIL PROTECTED]>;
Sent: Tuesday, September 05, 2006 7:52 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
On Tue, 2006-09-05 at 09:35 -0400
To: "James Kempf" <[EMAIL PROTECTED]>; "Thomas Narten"
<[EMAIL PROTECTED]>
Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; ; "ext Pars
MUTAF" <[EMAIL PROTECTED]>
Sent: Friday, September 01, 2006 3:00 AM
Subject: RE: Proposal to change aspec
On Tue, 2006-09-05 at 08:22 -0700, Soliman, Hesham wrote:
> > I wasn't assuming this.
> >
> > NUD checks the traffic channel in both directions. That's OK.
> > But after the NUD procedure, the host enters dormant mode and
> > becomes reachable via another channel: the paging channel that
> I wasn't assuming this.
>
> NUD checks the traffic channel in both directions. That's OK.
> But after the NUD procedure, the host enters dormant mode and
> becomes reachable via another channel: the paging channel that
> wasn't tested.
>
> Consequently, the following scenario is po
On Tue, 2006-09-05 at 09:35 -0400, Thomas Narten wrote:
> > > RAs aren't used for reachability we have
> > > ND/NUD for that.
>
> Once again, NUD (as I understand it, and the way it is defined in
> 2461) is not based on RS/RA exchanges. It is based on NS/NA
> exchanges. Thus, I do not at all under
> > RAs aren't used for reachability we have
> > ND/NUD for that.
Once again, NUD (as I understand it, and the way it is defined in
2461) is not based on RS/RA exchanges. It is based on NS/NA
exchanges. Thus, I do not at all understand the rest of your note.
Further, based on what you wrote below
Hello,
On Thu, 2006-08-31 at 15:45 -0400, Thomas Narten wrote:
> RAs aren't used for reachability we have
> ND/NUD for that.
NUD (RS-RA) becomes useless when the host is in dormant mode and
reachable via a paging channel.
To initiate NUD, the host needs to wake up and send RS. The router's
Hello,
In addition to the previous remarks:
Imagine that you have a friend who calls you to
check if you are still reachable, say every
15 minutes. And imagine that you don't need to
answer!
The periodic RAs are that friend.
This is frankly excellent. They periodically
simulate an incomin
> > 3) The current ND specs have an upper limit of 30 minutes on the
> > interval between router advertisements. That should be
> changed, to
> > allow deployments to use a higher value. (that is the
> > assertion/problem.)
> >
>
> This is certainly possible and one could do it,
James Kempf wrote:
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually
solicit prior to the expiration of the lifetime. The router information
state is still soft state, its just that the renewal is differe
Basavaraj Patil <[EMAIL PROTECTED]> writes:
> Ignoring cellular hosts for a moment, how are periodic RAs useful for any
> host?
They are part of the basic RS/RA reliability mechanism. Instead of
having hosts periodically poll routers, routers periodically send out
RAs. You need one or the other (
1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would
it help if the RAs were unicast rather than multicast? (Or is there
no true unicast in the networks we are talking about). My
assumption is that use of IP multicast is not an issue here, since
no one has suggested this.
Having just gone through this entire thread, some questions.
1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would
it help if the RAs were unicast rather than multicast? (Or is there
no true unicast in the networks we are talking about). My
assumption is that use of IP mult
over some interval.
jak
- Original Message -
From: "Erik Nordmark" <[EMAIL PROTECTED]>
To: "Basavaraj Patil" <[EMAIL PROTECTED]>
Cc: ; "ext Pars MUTAF" <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2006 5:25 PM
Subject: Re: Proposal
Syam Madanapalli wrote:
And by the way, will the expiry of the default router lifetime tigger
the DNA? Is it specified in the DNA Spec?
I don't think that is in the DNA specification.
DNA is triggered by L2 events notifications - 'link up'.
Erik
---
Basavaraj Patil wrote:
Ignoring cellular hosts for a moment, how are periodic RAs useful for any
host? RAs can be used as a means for detecting network attachment status or
to detect movement (prefix change). In the case of a stationary host (as an
example), periodic RAs really are of no benefit
CTED]>
Cc:
Sent: Thursday, August 10, 2006 12:31 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery
Hello Erik,
On 8/11/06, Erik Nordmark <[EMAIL PROTECTED]> wrote:
Syam Madanapalli wrote:
> I am not sure if this works.
> Let us say the router lifetime is X s
Hi Raj,
On Thu, 2006-08-10 at 15:45 -0500, Basavaraj Patil wrote:
> Hello Pars,
>
> Response inline:
>
>
> On 8/10/06 12:38 PM, "ext Pars MUTAF" <[EMAIL PROTECTED]> wrote:
>
> > Selon Basavaraj Patil <[EMAIL PROTECTED]>:
> >
> >>
> >> Inline:
> >>
> >>
> >> On 8/10/06 8:52 AM, "ext Pars
Hello Pars,
Response inline:
On 8/10/06 12:38 PM, "ext Pars MUTAF" <[EMAIL PROTECTED]> wrote:
> Selon Basavaraj Patil <[EMAIL PROTECTED]>:
>
>>
>> Inline:
>>
>>
>> On 8/10/06 8:52 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hello,
>>>
>>> I'm still trying to understand t
Hello Erik,
FRD may help snding an RA when the host wakes up and filters
all multicast RAs. This is problem for hosts that are active,
because FRD will not be able to send RAs to the active hosts.
Or the AP/BS can do the selective filtering for the hosts that are
sleeping?
And by the way, will t
Hello Erik,
On 8/11/06, Erik Nordmark <[EMAIL PROTECTED]> wrote:
Syam Madanapalli wrote:
> I am not sure if this works.
> Let us say the router lifetime is X seconds
> and the host wakes up every Y seconds to retrieve
> any packets from the AP/BS.
> If Y > X then we are not solving the problem.
Syam Madanapalli wrote:
I am not sure if this works.
Let us say the router lifetime is X seconds
and the host wakes up every Y seconds to retrieve
any packets from the AP/BS.
If Y > X then we are not solving the problem.
I think you need to explain what would fail in that case.
In my simple v
Selon Basavaraj Patil <[EMAIL PROTECTED]>:
>
> Inline:
>
>
> On 8/10/06 8:52 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
>
> >
> > Hello,
> >
> > I'm still trying to understand the problem :-)
> > Unless I missed an episode, the context is
> > connection-oriented cellular networks under IP
> >
Inline:
On 8/10/06 8:52 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I'm still trying to understand the problem :-)
> Unless I missed an episode, the context is
> connection-oriented cellular networks under IP
> (whatever that means)
>
> You say that the RA packets (unicas
Hello,
I'm still trying to understand the problem :-)
Unless I missed an episode, the context is
connection-oriented cellular networks under IP
(whatever that means)
You say that the RA packets (unicasted) will wake up
90% of hosts in the subnet. Because roughly %90 of
hosts are dormant, in
In your previous mail you wrote:
I am not sure I understand your argument that the issue of sending periodic
RAs should be handled at the link-layer.
=> I don't understand how my argument was translated in this one too (:-).
If the network layer is going to send the periodic RA, how do
> jak>> Dunno. Most of the terminal engineers I've talked to
> don't want to
> bring up the traffic channel at all if the terminal is in
> dormant mode.
> They're comparing that kind of a design to what they
> currently have where
> dormant mode is entirely controlled by the circui
> Most wireless link protocols that provide robust dormant
> mode support have a
> separate dormant mode (aka paging) signaling channel that is
> extremely
> narrowband and requires very low receiver power to monitor.
> This channel is
> independent of the traffic channel over which IP traffic
> g
Erik,
On 8/9/06 2:00 AM, "ext Erik Nordmark" <[EMAIL PROTECTED]> wrote:
> Syam Madanapalli wrote:
> eady dealing with dormant mode, but network layer
>> may be disturbing this mode; so the draft is proposing few changes to
>> the network layer.
>
> Syam,
> Is the link layer on the Access point/
Hello Erik,
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 12:31 PM
To: Syam Madanapalli
Cc: Francis Dupont; ipv6@ietf.org
Subject: Re: Proposal to change aspects of Neighbor Discovery
Syam Madanapalli wrote:
eady dealing with dormant
Syam Madanapalli wrote:
eady dealing with dormant mode, but network layer
may be disturbing this mode; so the draft is proposing few changes to
the network layer.
Syam,
Is the link layer on the Access point/Base station aware of when a host
goes dormant and when it wakes up?
If it is, then i
inal Message -
> From: "Pars Mutaf" <[EMAIL PROTECTED]>
> To: "Francis Dupont" <[EMAIL PROTECTED]>
> Cc:
> Sent: Tuesday, August 08, 2006 5:18 AM
> Subject: Re: Proposal to change aspects of Neighbor Discovery
>
>
> >
Francis,
I am not sure I understand your argument that the issue of sending periodic
RAs should be handled at the link-layer.
If the network layer is going to send the periodic RA, how do you expect the
link layer to deal with it? This would break the behavior.
On 8/8/06 4:02 PM, "ext Francis D
In your previous mail you wrote:
Are you also proposing that cellular-type protocols, such as 802.16 should
disable their power saving narrowband signaling channels and be forced to
work like 802.11?
=> no, I've said the space where to find a solution is the dormant
mode of the
Selon Basavaraj Patil <[EMAIL PROTECTED]>:
>
> Inline:
>
>
> On 8/8/06 10:54 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> >> From your draft:
> >
> >|Routers that implement the current recommendations would send the
> >|periodic multicast router advertisements every 3
quot;Syam Madanapalli" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 08, 2006 6:50 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
In your previous mail you wrote:
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
t;[EMAIL PROTECTED]>
To: "Francis Dupont" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 08, 2006 5:18 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
Hello,
On Tue, 2006-08-08 at 12:37 +0200, Francis Dupont wrote:
In your previous mail you wrote:
The I-
In your previous mail you wrote:
We are not solving a link layer problem here.
=> I disagree as the dormant mode support is at the link layer.
Problems are the short interval between periodic multicast
^
RAs and an MN currently does not solicit for RAs rather de
Inline:
On 8/8/06 10:54 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote:
> Hello,
>
>> From your draft:
>
>|Routers that implement the current recommendations would send the
>|periodic multicast router advertisements every 30 minutes, which can
>|be a significant problem in mobile/
Hello,
>From your draft:
|Routers that implement the current recommendations would send the
|periodic multicast router advertisements every 30 minutes, which can
|be a significant problem in mobile/cellular network environments.
Why do you think 1 multicast RA per 30 minutes is a signif
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
In your previous mail you wrote:
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
> The I-D:
> draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
> proposes several changes to ND proce
In your previous mail you wrote:
Just to make things clearer, are you:
- agreeing with the document, while at the same time reminding the
general principle that "the link-layer should adapt, not the
network layer", or
- disagreeing with the document based on t
In your previous mail you wrote:
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
> The I-D:
> draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
> proposes several changes to ND procedures and parameters.
>
> => I strongly obj
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
In your previous mail you wrote:
The I-D:
draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
proposes several changes to ND procedures and parameters.
=> I strongly object not about the document itself but about its
principle because IMH
Hello,
On Tue, 2006-08-08 at 12:37 +0200, Francis Dupont wrote:
> In your previous mail you wrote:
>
>The I-D:
>draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
>proposes several changes to ND procedures and parameters.
>
> => I strongly object not about the document itself but
In your previous mail you wrote:
The I-D:
draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
proposes several changes to ND procedures and parameters.
=> I strongly object not about the document itself but about its
principle because IMHO the link-layer should adapt, not the network l
On Mon, 7 Aug 2006, Basavaraj Patil wrote:
Hello,
The I-D:
http://www.ietf.org/internet-drafts/draft-madanapalli-ipv6-periodic-rtr-advt
s-00.txt
proposes several changes to ND procedures and parameters.
Pls review and comment.
Can you justify with power consumptions this proposal?
- I
68 matches
Mail list logo
