Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

Ole Troan <otroan@employees.org> Thu, 28 October 2010 09:43 UTC

Return-Path: <ichiroumakino@gmail.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D223A6879 for <ipv6@core3.amsl.com>; Thu, 28 Oct 2010 02:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Level:
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsGE6HL6P6id for <ipv6@core3.amsl.com>; Thu, 28 Oct 2010 02:43:53 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 905D03A686D for <ipv6@ietf.org>; Thu, 28 Oct 2010 02:43:53 -0700 (PDT)
Received: by eyd10 with SMTP id 10so980436eyd.31 for <ipv6@ietf.org>; Thu, 28 Oct 2010 02:45:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=pf+AZOV3MXxfOrd1uERX4JwuGYbWfE+CPe/BKwPu7b4=; b=tOcclPjCx8PZyxlOn1FN86svASuEopE175mRHlfwaJiL9KJcwYar7YUdOK4pG1JZMw etlPM4uClsG/xLdqNniHmXQ/hXaKVehmWnN42q7P8PbOOsauV4f1GWvd/fNh7FY152/8 pP6oS/rIfo43R37N8cgMaWH2NTfIfki4Q28t4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AEejLZMlchhpejZQgJY5qEsiv8XzDw1zLOS37T8qOjIGRHgYhL616jaJAeOK6tEsdX IjX0tVicmBWDj3WcTHOMYyBNCA1n7hjNhwD5TKwFKuR9uZfNJoeIEcZuqJuUCCRxr8kL ebZSCV2Q+ikb4krQfZQnwwA0GJ6LGuAPk6mZM=
Received: by 10.14.45.65 with SMTP id o41mr8561869eeb.23.1288259144688; Thu, 28 Oct 2010 02:45:44 -0700 (PDT)
Received: from dhcp-10-61-98-204.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b52sm632121eei.19.2010.10.28.02.45.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 02:45:43 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Subject: Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <3F7E0126-76FB-43BA-B25F-1EE226FA73AA@gmail.com>
Date: Thu, 28 Oct 2010 11:45:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCEDE07D-AA1E-477F-A014-0CDDB46873F5@employees.org>
References: <3F7E0126-76FB-43BA-B25F-1EE226FA73AA@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: Brian Haberman <brian@innovationslab.net>, IPv6 WG Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 09:43:54 -0000

Comments/Questions:

1) N:1 deployment model. reference 5517, 3069, 4562 perhaps
2) I don't think the deployment model, i.e where you are using a single link that you are trying to create some level
   of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a middlebox, is restricted to DSL. generalise
   the Introduction?
3) define how the tunneling works, which source / destination addresses are used. are there other existing signaling mechanisms that be used instead of 'piggybacking' on user traffic to signal to the network.

4) the proposal is to tunnel ND packets between the AN and the edge router. are you certain that in this model there aren't other IPv6 protocols that also have to be tunneled? which would call for a slightly more general approach?

5) does the AN have to do any other action based on the fact that it is receiving an RS? I'm specifically thinking of state required for SAVI for example. DHCPv6 is stateful and even though DHCPv6 snooping isn't architecturally very clean, it is technically a more sound design than trying to achieve the same with ND. if the answer is no, then please ignore. ;-)

6) in section 5.3 you state that the AN MAY retransmit RSs. is how this is done going to be implementation dependent?
continue forever as in DHCP or timeout after 3 tries as in ND?
if ANCP is available as the section says, is it then specifies how the signaling would be done? or would that require additional standardisation? I guess the question is, is this a problem statement, a requirements document or a solution?

7) why does section 6.2 say that the edge router mustn't decrement the hop limit of the RA message?

8) in section 6.3. are you stating that you require something like ANCMP to be able to clean up state at the edge router?

9) section 7. LineIDlen is not in the figure. could you just encode the Remote-ID dhcp option instead? (RFC4649) 

<soapbox statement>: I'm biased against this subnet model (N:1)... recreating PPP functionality over Ethernet, trying to create user isolation on a shared IPv6 link, which after all IPv6 protocols are not designed for.

what are the options?
- tell BBF not to use DHCPv6?
- go somewhere else? ANCP? BBF?
- adopt in 6man... 

I'm not sure if 6man has the required expertise for this work.

cheers,
Ole