IETF Logo Mail Archive

Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Ole Troan <otroan@employees.org> Tue, 26 November 2013 10:36 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC01ADFDA for <v6ops@ietfa.amsl.com>; Tue, 26 Nov 2013 02:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 Kr5wc45hwOaa for <v6ops@ietfa.amsl.com>; Tue, 26 Nov 2013 02:36:14 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 794E41ADFA0 for <v6ops@ietf.org>; Tue, 26 Nov 2013 02:36:14 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAFJ5lFKQ/khM/2dsb2JhbABZgwe9IYEqFnSCJQEBBAF5BQsLRlcGiA4GvzYXjnYHgyCBEwOQMZl0gyk7
X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="asc'?scan'208";a="643124"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 26 Nov 2013 10:36:13 +0000
Received: from dhcp-10-61-103-120.cisco.com (dhcp-10-61-103-120.cisco.com [10.61.103.120]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAQAa9xk021365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 10:36:10 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_49375346-9DFF-4A2D-B880-5A27243F124D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EF25E@MOPESMBX01.eu.thmulti.com>
Date: Tue, 26 Nov 2013 11:36:08 +0100
Message-Id: <BFF29ED1-5247-4521-A4FF-90245B3F6627@employees.org>
References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <CAJc3aaPmsxTewQFznXo1GMao_pEpGicqoGk6ijfBjHOW-6sovw@mail.gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <OF1909BE08.00E4773F-ON85257C2E.004E2BAB-85257C2E.004F6601@videotron.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <CAJc3aaPcfnsE0RgrZnxAh3U=iGRs4NCxsQr62r0EFiW53x0VOQ@mail.gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com> <5293A596.2000304@gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EF25E@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
X-Mailer: Apple Mail (2.1822)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2013 10:36:15 -0000

Carl,

> I Agree on the SHOULD statement, no issue of "not complying" with the RFC due to this.  However, as far as I know, SHOULD means "support it unless a good reason exists to not do this".  As you state below, the good reason is there "you don't know", but it's not a pleasant thing having to convince customers of this over and over.  As I've said: this part of that req has no added value at all, hence should not be present.

at some point in time you can detect when you've run out of prefixes to assign. be that to local interfaces or via a homenet control protocol.

is the confusion about timing? WPD-3 clearly allows the logging to happen at any point in time, independent of the prefix delegation state machine. there is no expectation that the CPE indicates this to the delegating router in anyhow.

cheers,
Ole

v2.23.0 | Report a Bug | By Email