[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: ipv6 Digest, Vol 53, Issue 7
From: <Jason.Weil () cox ! com>
Date: 2008-09-22 20:00:58
Message-ID: 8720A864484AB04082CD55A4AEAADAB60481CE4B () CATL0MS01 ! corp ! cox ! com
[Download RAW message or body]
----- Original Message -----
From: ipv6-bounces@ietf.org <ipv6-bounces@ietf.org>
To: ipv6@ietf.org <ipv6@ietf.org>
Sent: Mon Sep 22 15:00:08 2008
Subject: ipv6 Digest, Vol 53, Issue 7
Send ipv6 mailing list submissions to
ipv6@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ipv6
or, via email, send a message with subject or body 'help' to
ipv6-request@ietf.org
You can reach the person managing the list at
ipv6-owner@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6 digest..."
Today's Topics:
1. Re: v4v6interim@ietf.org Mailing list (Marshall Eubanks)
2. RE: v4v6interim@ietf.org Mailing list (Dan Wing)
3. Re: v4v6interim@ietf.org Mailing list (Jari Arkko)
4. Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's
Reaction to Soft Errors) to Informational RFC (Lars Eggert)
5. Fwd: Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt" (hyunwook cha)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Sep 2008 12:53:50 -0400
From: Marshall Eubanks <tme@multicasttech.com>
Subject: Re: v4v6interim@ietf.org Mailing list
To: Jeroen Massar <jeroen@unfix.org>
Cc: Brian Haberman <brian@innovationslab.net>, Internet Area
<int-area@ietf.org>, ipv6@ietf.org, softwires@ietf.org, Dan Wing
<dwing@cisco.com>, 'IPv6 Operations' <v6ops@ops.ietf.org>, Behave WG
<behave@ietf.org>
Message-ID: <F68CB757-31FB-4D0A-8AAA-29F8046728CD@multicasttech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Is there going to be a audio broadcast and jabber room for this
interim ?
If so, how to join ?
If not, aren't these aids now part of the "open participation"
required of IETF interims ?
Regards
Marshall
On Sep 16, 2008, at 5:01 AM, Jeroen Massar wrote:
> Mark Townsley wrote:
>> We have setup an email list for discussion leading up to the interim
>> v4v6 coexistence meeting on October 1-2, 2008 in Montr?al, Canada. If
>> you are registered to attend the meeting, you should already be on
>> the list.
>>
>> The list is open, please subscribe and begin using it for all interim
>> meeting related discussion (technical as well as
>> administrative/logistical).
>
> For people, like me, who are not going to the meeting, but do want to
> follow the discussions and possibly contribute to them, the list,
> signup
> and archives can be found here:
>
> https://www.ietf.org/mailman/listinfo/v4v6interim
>
> I couldn't find a reference to it from those URL's posted, might be
> good
> to put the ref there too.
>
> Greets,
> Jeroen
>
------------------------------
Message: 2
Date: Tue, 16 Sep 2008 11:12:30 -0700
From: "Dan Wing" <dwing@cisco.com>
Subject: RE: v4v6interim@ietf.org Mailing list
To: "'Marshall Eubanks'" <tme@multicasttech.com>, "'Jeroen Massar'"
<jeroen@unfix.org>
Cc: 'Brian Haberman' <brian@innovationslab.net>, 'Internet Area'
<int-area@ietf.org>, ipv6@ietf.org, softwires@ietf.org, 'IPv6
Operations' <v6ops@ops.ietf.org>, 'Behave WG' <behave@ietf.org>
Message-ID: <018701c91827$c91ecd40$c2f0200a@cisco.com>
Content-Type: text/plain; charset="iso-8859-1"
> -----Original Message-----
> From: Marshall Eubanks [mailto:tme@multicasttech.com]
> Sent: Tuesday, September 16, 2008 9:54 AM
> To: Jeroen Massar
> Cc: Mark Townsley; ipv6@ietf.org; 'IPv6 Operations'; Internet
> Area; Behave WG; softwires@ietf.org; Brian Haberman; Jari
> Arkko; Dan Wing
> Subject: Re: v4v6interim@ietf.org Mailing list
>
> Is there going to be a audio broadcast and jabber room for this
> interim ?
At this time, we are not sure of the audio broadcast capabilities
that are available in the meeting room.
> If so, how to join ?
Such specifics will be announced on the v4v6interim@ietf.org mailing
list.
-d
> If not, aren't these aids now part of the "open participation"
> required of IETF interims ?
>
> Regards
> Marshall
>
> On Sep 16, 2008, at 5:01 AM, Jeroen Massar wrote:
>
> > Mark Townsley wrote:
> >> We have setup an email list for discussion leading up to
> the interim
> >> v4v6 coexistence meeting on October 1-2, 2008 in Montr?al,
> Canada. If
> >> you are registered to attend the meeting, you should
> already be on
> >> the list.
> >>
> >> The list is open, please subscribe and begin using it for
> all interim
> >> meeting related discussion (technical as well as
> >> administrative/logistical).
> >
> > For people, like me, who are not going to the meeting, but
> do want to
> > follow the discussions and possibly contribute to them, the list,
> > signup
> > and archives can be found here:
> >
> > https://www.ietf.org/mailman/listinfo/v4v6interim
> >
> > I couldn't find a reference to it from those URL's posted,
> might be
> > good
> > to put the ref there too.
> >
> > Greets,
> > Jeroen
> >
>
------------------------------
Message: 3
Date: Tue, 16 Sep 2008 22:32:22 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: v4v6interim@ietf.org Mailing list
To: Marshall Eubanks <tme@multicasttech.com>
Cc: Brian Haberman <brian@innovationslab.net>, Internet Area
<int-area@ietf.org>, v4v6interim@ietf.org, ipv6@ietf.org,
softwires@ietf.org, Dan Wing <dwing@cisco.com>, 'IPv6 Operations'
<v6ops@ops.ietf.org>, Behave WG <behave@ietf.org>
Message-ID: <48D009C6.3070708@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Marshall,
Several people have indeed indicated desire to participate remotely, and
we are doing everything we can to make that possible.
I think we will at least have a voice stream coming out of the meeting,
jabber scribing (participants, please volunteer to scribe!), and
possibility for questions from jabber. But we are still organizing those
services and I don't want to promise anything more at this stage. See
also some additional information below, copied from Mark's e-mail to the
v4v6interim list. And this discussion should probably continue on that
list as well :-)
By the way -- if there is someone who has not registered for the
physical meeting yet but plans to come, please try to register before
Saturday, September 20th.
Jari
Mark Townsley wrote:
> The ADs are working with the meeting host to see what can be done based
> on what the facility has to offer. Cisco has offered webex hosting so
> that remote participants can at least see what is being presented on the
> projector and what is being said into a microphone, accessible over a
> web and/or PSTN interface for voice (with recording of all this for
> later viewing). But, without good microphones and discipline to use
> them, the experience might be limited. Same for folks that want to chime
> in over the phone, its nice to have some level of "floor control" to
> help moderate the interaction. We could setup a camera as well, but
> without real funding or exceptional volunteer efforts (not to mention
> lending of equipment and good connectivity outside the building), I'm
> not all that optimistic. We will do the best we can with the resources
> available, wish I could say more - perhaps Suresh can jump in and give
> more insight.
------------------------------
Message: 4
Date: Thu, 18 Sep 2008 14:40:14 +0200
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's
Reaction to Soft Errors) to Informational RFC
To: ext Jari Arkko <jari.arkko@piuha.net>
Cc: 'IPv6 Operations' <v6ops@ops.ietf.org>, IETF IPv6 Mailing List
<ipv6@ietf.org>, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org
Message-ID: <409ACC0E-8BE6-4348-9DA5-E02A32D42226@nokia.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi,
the second last call has ended, but I didn't see a review from the v6
community. (But maybe I missed it in the pile of unread email that
built up during my vacation.)
Are the v6 folks OK with this document? If yes, I'd like to move this
forward after the gen-art review has been addressed.
Thanks,
Lars
On 2008-8-13, at 10:00, ext Jari Arkko wrote:
> 6MAN and V6OPS WGs,
>
> This informational document suggests changes to how
> TCP deals with certain classes of ICMP errors. This affects
> behavior in a number situations, including what happens
> to dual stack nodes when they attempt to connect to hosts
> that have both IPv4 and IPv6 addresses.
>
> The document seems reasonable, but I would like to see some
> review from the IPv6 community to ensure that nothing has
> been missed. Please take the time to review this during the
> last call period which ends on August 26th.
>
> Thanks,
>
> Jari
>
> Begin forwarded message:
>
>> From: "ext The IESG" <iesg-secretary@ietf.org>
>> Date: August 12, 2008 17:13:11 GMT+03:00
>> To: IETF-Announce <ietf-announce@ietf.org>
>> Cc: tcpm@ietf.org
>> Subject: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's
>> Reaction to Soft Errors) to Informational RFC
>> Reply-To: ietf@ietf.org
>>
>> The IESG has received a request from the TCP Maintenance and Minor
>> Extensions WG (tcpm) to consider the following document:
>>
>> - 'TCP's Reaction to Soft Errors '
>> <draft-ietf-tcpm-tcp-soft-errors-08.txt> as an Informational RFC
>>
>> This is the second IETF last call for this document, to give the IPv6
>> community
>> sufficient time to review how this document interacts with dual-stack
>> hosts.
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments
>> to the
>> ietf@ietf.org mailing lists by 2008-08-26. Exceptionally,
>> comments may be sent to iesg@ietf.org instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.txt
>
>
------------------------------
Message: 5
Date: Fri, 19 Sep 2008 12:08:39 +0900
From: "hyunwook cha" <hyunwook.cha@gmail.com>
Subject: Fwd: Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
To: narten@us.ibm.com, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org
Message-ID:
<a3c826bd0809182008x58f2fdd9m5fbfc6decfd0c985@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thomas,
I would like to add a few comments as below.
>
> ------- Original Message -------
> Sender : Thomas Narten<narten@us.ibm.com>
> Date : 2008-09-18 22:01 (GMT+09:00)
> Title : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
>
> HYUN WOOK CHA <hyunwook.cha@samsung.com> writes:
>
>> > > First of all, I would like to give a brief summary for the draft.
>> >
>> > > Existing specification (RFC2462) does not give a method on how to
>> > > revoke DHCPv6 clients once they were invoked by the M or O flags of
>> > > RA messages.
>> >
>> > Personally, I do not believe this is wrong or a problem. IMO, it is
>> > just fine that there is no way to revoke an earlier hint that DHC is
>> > available and clients should use it. (DHC has its own ways for dealing
>> > with unresponsive servers -- clients will retransmit at a very low
>> > rate, in such a way that such retransmissions do not cause operational
>> > problems.)
>> >
>>
>> Perhaps this point might be a major conflict. As we both know,
>> consecutive DHCPv6 SOLICIT messages are sent exponentially
>> back-offed if no valid replies are received within timeouts. Since
>> this always holds, I would like to ask you why M/O flags should not
>> be deprecated.
>
> Because the WG doesn't feel that the flags were so problematic that
> they needed to be deprecated? There certainly has been concern that
> existing implementations that do support the M&O bits should not
> become non-complient through deprecation of the M&O flags.
>
> IMO, if we were to start over knowing what we know today, I'd be in
> favor of not having the M&O bits at all. But we are not starting from
> scratch...
>
I am not sure that M&O bits has no value. At this moment, I simply do
not want to enter long debates for this topic. According to the
RFC4861 and 4862, we have freedom to choose handling of M&O bits in
RA. Specification in the RFC 2462 may be considered as an option,
which has been implemented and practiced widely by many vendors. In
this option, we found out the issue that there is no method to revoke
DHCPv6 clients once invoked by RA M/O bits. Thus, we devised our
proposal to address the issue clearly.
>> IMO, revocation of DHCPv6 clients has also benefits if invocation of
>> DHCPv6 clients should be guided by RA flags.
>
> On this point, I have seen little indication that the WG agrees with
> you.
>
>> > Your proposal would differ and (from what I can tell) cause DHC to be
>> > enabled/disabled/enabled/disabled/etc/ over and over again. This seems
>> > like a bad solution in this case.
>> >
>>
>> This is not true. Please refer to the section 4 in our draft.
>
> OK. Sorry for not reviewing this point in advance.
>
>> 4. An Algorithm for the Management of Internal State Variables
>>
>> We introduce an algorithm for the management of the internal state
>> variables as follows. In this algorithm, two timers (M-timer and
>> O-timer) are used, lifetimes of which is chosen to be 3 times of
>> MaxRtrAdvInterval in [RFC4861]. When an RA is received that has the
>> M flag set, ManagedFlag is set to TRUE and the M-timer is started or
>> restarted. When an RA is received that has the O flag set, the
>> OtherConfigFlag is set to TRUE and O-timer is strarted or restarted.
>> If the M-timer goes off, the ManagedFlag is set to FALSE. If the
>> O-timer goes off, OtherConfigFlag is set to FALSE. Thus, once
>> ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed
>> into FALSE after no RA is received with the bit set within lifetime
>> of timers. Thus, state variables can be managed consistently even
>> when a host is connected to multiple routers sending conflicting RA
>> messages, because the RA messages with the bit set will overrule the
>> ones with the bit clear.
>
> Sure, this would work. Though one can question whether the additional
> implementation complexity is worth the benefit.
>
>> If you can not agree with our problem statement, I just hope that
>> you have only the reasons mentioned above.
>
> Right. I just don't see the problem as particularly significant, and I
> don't believe the WG will be able to agree on changing the definition
> of the M&O flags (given past discussions).
>
I agree that the issue itself is not significant. However, we believe
that the issue is a missing part which should be handled clearly so
that implementors may be guided well and our proposal can be
applicable for this.
> If your real concern is that DHC continues to be invoked forever (even
> when no DHC servers are available), wasting network resources, IMO,
> the better place to make changes is in the DHC specification. I.e.,
> the DHC client should backoff more aggressively and "poll" for the
> appearance of a new server very infrequently.
>
> This would be appear to be as simple as changing the value of SOL_MAX_RT:
>
> Parameter Default Description
> -------------------------------------
> SOL_MAX_RT 120 secs Max Solicit timeout value
>
> See Section 17.1.2 in RFC 3315.
>
> Thomas
>
>
>
I do not think that your suggestion is right approach. Why do not you
simply allow to revoke DHCPv6 clients by RA flags through which they
are invoked?
Joseph
------------------------------
_______________________________________________
ipv6 mailing list
ipv6@ietf.org
https://www.ietf.org/mailman/listinfo/ipv6
End of ipv6 Digest, Vol 53, Issue 7
***********************************
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic