Hi Suresh,
Suresh Krishnan wrote:
Hi Ralph,
Snipped a whole lot of old quoting
On 10-08-26 08:18 PM, Ralph Droms wrote:
Suresh...
But the multicast RAs don't advertise prefixes, right, so the
subscriber nodes won't be able to complete SLAAC?
Correct.
I think the point is
Suresh - a further comment on using standard stacks. There is a potential
problem with using RA as sign of life: if the node receives an unsolicited RS
before it sends an RA, the node will accept that RS and never send an RA. The
node waits a random interval between 0 and 1 seconds before
Josh Littlefield pointed out where I was confused - I reversed RS and RA, so my
text should have read:
...a further comment on using standard stacks. There is a potential problem
with using RS as sign of life: if the node receives an unsolicited RA before
it sends an RS, the node will accept
Hi Ralph,
Snipped a whole lot of old quoting
On 10-08-26 08:18 PM, Ralph Droms wrote:
Suresh...
But the multicast RAs don't advertise prefixes, right, so the subscriber nodes
won't be able to complete SLAAC?
Correct.
I think the point is to use standard node stacks: Windows 7, OS X,
Suresh,
I would not say it is a problem with the deployment architecture. As I
said in mails to Thomas and Woj, the issue occurs in other deployment
architectures that need to use different prefixes over the same shared
L2 domain (e.g. WLAN AP with 2 SSIDs mapped into 2 VLANs on the fixed
Hi Thomas,
On 10-08-27 07:42 PM, Thomas Narten wrote:
Suresh,
I would not say it is a problem with the deployment architecture. As I
said in mails to Thomas and Woj, the issue occurs in other deployment
architectures that need to use different prefixes over the same shared
L2 domain (e.g.
Hi Ralph,
On 10-08-27 10:51 AM, Ralph Droms wrote:
References: 4c61959a.7040...@innovationslab.net 1b6d0317d3ad964fbf3956defa3524d505c580f...@eusaacms0701.eamcs.ericsson.se
aanlktimguhnaeb0oxisyj2yc0d_pwisp4b9yz7p4a...@mail.gmail.com
On 26 August 2010 00:47, Suresh Krishnan suresh.krish...@ericsson.comwrote:
Hi Woj,
I think this is the basis of our disagreement. There are no assumptions
that this document is making. There are usage scenarios not involving the
mechanism proposed in this document that are relevant to
I htink Woj is right and raises some fundamental issues.
The RS/RA mechanism *assumes* that routers send out periodic multicast
advertisements. Having nodes send out an RS to solicit RAs is a sort
of optimization, intended to prod routers into sending out an RA
immediately. But the sending of
To: Suresh Krishnan
Cc: Brian Haberman; IPv6 WG Mailing List
Subject: Re: RS Lost failure scenario (Was Re: Consensus call on
adopting:draft-krishnan-6man-rs-mark-06.txt)
On 26 August 2010 00:47, Suresh Krishnan
suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com wrote:
Hi Woj,
I
Hi Thomas
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Thomas
Narten
Sent: August-26-10 8:38 AM
To: Wojciech Dec
Cc: Brian Haberman; IPv6 WG Mailing List; Suresh Krishnan
Subject: Re: RS Lost failure scenario (Was Re: Consensus call
Alan Kavanagh alan.kavan...@ericsson.com writes:
The RS/RA mechanism *assumes* that routers send out periodic multicast
advertisements. Having nodes send out an RS to solicit RAs is a sort of
optimization, intended to prod routers into sending out an RA immediately.
But the sending of RSes
Hi Thomas,
On 10-08-26 08:37 AM, Thomas Narten wrote:
I htink Woj is right and raises some fundamental issues.
Yes. And nobody said anything to the contrary. I problem is that the
issue is orthogonal to the mechanism described in the RS mark draft.
Even if draft-krishnan-6man-rs-mark was
Suresh...
On Aug 26, 2010, at 7:20 PM 8/26/10, Suresh Krishnan wrote:
Hi Thomas,
On 10-08-26 08:37 AM, Thomas Narten wrote:
I htink Woj is right and raises some fundamental issues.
Yes. And nobody said anything to the contrary. I problem is that the issue is
orthogonal to the mechanism
Hi Suresh,
thanks for looking further into this problem, and publishing an updated
draft 07. Let me however stress that this problem is one very strictly tied
to the (supposed?) usage context of the RS-mark mechanism, and thus it
really needs to be described/addressed in the rs-mark draft, not
Hi Woj,
On 10-08-25 04:31 AM, Wojciech Dec wrote:
Hi Suresh,
thanks for looking further into this problem, and publishing an updated
draft 07. Let me however stress that this problem is one very strictly
tied to the (supposed?) usage context of the RS-mark mechanism, and thus
it really
On 25 August 2010 17:18, Suresh Krishnan suresh.krish...@ericsson.comwrote:
Hi Woj,
On 10-08-25 04:31 AM, Wojciech Dec wrote:
Hi Suresh,
thanks for looking further into this problem, and publishing an updated
draft 07. Let me however stress that this problem is one very strictly tied
to
Hi Woj,
On 10-08-25 11:56 AM, Wojciech Dec wrote:
I respectfully disagree. Here's why. The RS-mark mechanism describes
how RSs are marked and how the responding solicited-RAs are sent. It
has got nothing to do with other neighbor discovery messages. e.g.
Unsolicited multicast
18 matches
Mail list logo
