Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 07 July 2017 07:06 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCFB13155C for <dhcwg@ietfa.amsl.com>; Fri, 7 Jul 2017 00:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5Fcr8taALmt for <dhcwg@ietfa.amsl.com>; Fri, 7 Jul 2017 00:05:54 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DB4126579 for <dhcwg@ietf.org>; Fri, 7 Jul 2017 00:05:54 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6775mPC010324; Fri, 7 Jul 2017 09:05:49 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E6AB1201FDA; Fri, 7 Jul 2017 09:05:48 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D08BC202003; Fri, 7 Jul 2017 09:05:48 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6775mhi028898; Fri, 7 Jul 2017 09:05:48 +0200
To: "Bernie Volz (volz)" <volz@cisco.com>, Timothy Winters <twinters@iol.unh.edu>, JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> <CAJE_bqcMLz7JBaSA2h6_xiB3AyxQzkMGfL87WeqKzwxKoSeD-w@mail.gmail.com> <67c761541b674041ba5a2eb0b9ea41fa@XCH-ALN-003.cisco.com> <CAJE_bqeBg-va5zr=4HNrecECg_mmGpWECAc8V5UL0ckhHnJcNQ@mail.gmail.com> <7f897317e79e4576bebc772c45edb703@XCH-ALN-003.cisco.com> <CAJE_bqd72=wKwe3_i3=rArJys1eWLizVdn_q+Dz9yaHFouP_WA@mail.gmail.com> <3227281E-1FC2-448F-A9D2-9E7603A24E15@cisco.com> <m2o9tjrhfn.wl%jinmei.tatuya@gmail.com> <F0056821-DF5B-400E-ABAC-88BCA0EF68C7@cisco.com> <CAOSSMjWMJt1-qJM35kk3Eut=UHSPp-hizR0_nDE87ZMPJaf1vg@mail.gmail.com> <72E71872-9AC3-4D74-B889-B13CE05F62E4@cisco.com> <d64e4247d2bc4fc18a83a3f80591f95c@XCH-ALN-003.cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <6f7fc559-d6c7-9479-2086-c68dac2e0d64@gmail.com>
Date: Fri, 07 Jul 2017 09:05:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <d64e4247d2bc4fc18a83a3f80591f95c@XCH-ALN-003.cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/l_jNJit0sLDRssowihPt-GefRUk>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 07:06:00 -0000

Bernie,

This activity look scomplex to me, but here is my two cents.

Le 24/06/2017 à 23:28, Bernie Volz (volz) a écrit :
> Hi:
> 
> Any feedback on this proposed text?
> 
> It would be nice to be able to publish an -09 before the 7/3 deadline
>  for IETF-99, and perhaps even send this document on to the IESG 
> (assuming Ralph believes there is consensus to do so).
> 
> An alternative, which in retrospect I think I would prefer, would be
> for the PIO to use the remaining preferred and valid lifetime on the
> lease and just say that explicitly. That may be cleanest? So, that
> proposed text would be:
> 
> If the client assigns a delegated prefix to a link to which the
> router is attached, 

What do you mean by the link to which the router is attached?

Is there a link to which the router is not attached?

Is there a link to which the router attaches instead of being attached?

Is it the ff02 link on which it issued a Solicit?

Alex

and begins to send router advertisements for
> 
> the prefix on the link, the preferred and valid lifetime in those 
> advertisements
> 
> MUST be no larger than the remaining preferred and valid lifetimes,
> respectively,
> 
> for the delegated prefix at the time the router advertisement is 
> sent.
> 
> Please let me know which of the two versions you’d prefer, or suggest
> an alternative.
> 
> -Bernie
> 
> *From:*Bernie Volz (volz) *Sent:* Monday, June 19, 2017 3:28 PM *To:*
> Timothy Winters <twinters@iol.unh.edu>; JINMEI Tatuya / 神明達哉 
> <jinmei.tatuya@gmail.com> *Cc:* dhcwg@ietf.org; Ralph Droms
> <rdroms.ietf@gmail.com> *Subject:* Re: [dhcwg] WGLC for
> draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
> 
> Thanks Tim. That’s useful, and shows that we do need to be more
> explicit.
> 
> There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and
>  18.2.10.1) where we have the following text:
> 
> If the client assigns a delegated prefix to a link to which the
> 
> router is attached, and begins to send router advertisements for
> 
> the prefix on the link, the client MUST set the valid lifetime in
> 
> those advertisements to be no later than the valid lifetime
> 
> specified in the IA_PD option.  A client MAY use the preferred
> 
> lifetime specified in the IA_PD option.
> 
> The “no later” has been changed to “no larger”. And, actually the
> IA_PD option is wrong (it should be IAPREFIX option, as that holds
> the lifetimes).
> 
> Perhaps what we really should say is something like:
> 
> If the client assigns a delegated prefix to a link to which the
> 
> router is attached, and begins to send router advertisements for
> 
> the prefix on the link, the valid lifetime in those advertisements
> 
> MUST be no larger than the remaining valid lifetime
> 
> for the delegated prefix.  A client MAY use the preferred
> 
> lifetime as originally received in the IAPREFIX option, provided that
> whatever
> 
> value is used is less than or equal to the valid lifetime to be sent
> in the
> 
> router advertisement.
> 
> That text doesn’t by itself provide any good way to specify a shorter
>  preferred lifetime so that the prefix is marked deprecated before it
>  becomes invalid, but at least it assures that what is send for the 
> preferred and valid meets the basic requires: preferred <= valid in
> the RA, and the valid is <= what is specified in the IAPREFIX.
> 
> -Bernie
> 
> *From: *Timothy Winters <twinters@iol.unh.edu
> <mailto:twinters@iol.unh.edu>> *Date: *Monday, June 19, 2017 at 2:32
> PM *To: *Bernie Volz <volz@cisco.com <mailto:volz@cisco.com>> *Cc:
> *JINMEI Tatuya / 神明達哉<jinmei.tatuya@gmail.com 
> <mailto:jinmei.tatuya@gmail.com>>, "dhcwg@ietf.org 
> <mailto:dhcwg@ietf.org>" <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>,
> Ralph Droms <rdroms.ietf@gmail.com <mailto:rdroms.ietf@gmail.com>> 
> *Subject: *Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 -
> Respond by May 30th, 2017
> 
> Hi Bernie,
> 
> We have CE Routers that countdown from when the IA_PD is received,
> and others that always transmit the lifetime received in the IA_PD in
> RA (Always the same).   It's about 50/50 at the moment.   When we
> were working on testing for 6024/7084 this was a topic that was
> discussed but it wasn't clear answer on what to do with the
> lifetimes.
> 
> You are correct that when the prefix timeout from the IA_PD it will
> stop forwarding and transmit a Destination Unreachable message.
> 
> Regards,
> 
> Tim
> 
> On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <volz@cisco.com 
> <mailto:volz@cisco.com>> wrote:
> 
> I’ve added Tim Winters as perhaps he can shed some light on this in 
> terms of what is tested at the NH Interoperability Lab for PD /
> CPEs?
> 
> Even if a device doesn’t follow this (running down the lifetimes), 
> what’s likely to happen when the PD expires is that the traffic will 
> hopefully no longer be forwarded by the router (and with a ICMP 
> destination unreachable notification) and perhaps RAs will be sent 
> with 0 lifetimes to attempt to deprecate the prefix (and any assigned
> addresses) use as quickly as possible?
> 
> Ralph or Ole might also have a comment with respect to what they 
> expected a requesting router to do based on the original RFC 3633? I 
> don’t think this 3315bis document itself caused this potential 
> confusion to exist?
> 
> - Bernie
> 
> 
> On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <jinmei.tatuya@gmail.com
> <mailto:jinmei.tatuya@gmail.com>> wrote:
> 
> At Sat, 17 Jun 2017 02:27:39 +0000, "Bernie Volz (volz)"
> <volz@cisco.com <mailto:volz@cisco.com>> wrote:
> 
>> My reaction is you are wrong – the PIO would, whenever sent,
> be sent
>> with the preferred and valid lifetime REMAINING on the PD
> lease. So,
>> sure a PIO sent just after the PD lease started would have
> (close)
>> to the full values, but the values sent an hour later would be 1 
>> hour less than they were.
> 
> Actually I agreed.  I guess what we're different is the view on how 
> obvious it is.  I suspect this is not so obvious and there are 
> actually implementations that can cause the situation where 
> deprecated/invalidated addresses are used.  There may even be an 
> implementation that naively copies the lifetimes from PD to RA PIO.
> 
> I've monitored RAs advertised in my apartment room.  The ISP is 
> Comcast and the default router is Apple time capsule.  The lifetimes 
> advertised in RA PIO are constant and do not decrease as I monitored 
> it in multiple consecutive RAs.  Of course, it doesn't immediately 
> mean the time capsule device uses the 'naive' approach.  I actually 
> don't even know if PD is used or the time capsule is the PD client. 
> And the time capsule might actually have some safety buffer period
> and use a much lower lifetimes for PIO than those provided in PD. 
> Still, I think this can be a potential anecdote to suggest there
> might be a problematic implementation.
> 
> So I don't think it at least doesn't harm if we say that lifetimes
> of site addresses derived from the delegated prefix MUST NOT exceed
> the remaining time of the lifetimes in the last-received
> corresponding PD.  (I don't think we have to specify exactly how to
> implement this restriction).
> 
> -- JINMEI, Tatuya
> 
> 
> 
> --
> 
> Now offering testing for SDN applications and controllers in our SDN
>  switch test bed. Learn more today http://bit.ly/SDN_IOLPR
> 
> 
> 
> _______________________________________________ dhcwg mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>