Re: [v6ops] draft-ietf-dhc-pd-exclude

"tsavo.stds@gmail.com" <tsavo.stds@gmail.com> Thu, 08 December 2011 20:14 UTC

Return-Path: <tsavo.stds@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53AA21F8B08 for <v6ops@ietfa.amsl.com>; Thu, 8 Dec 2011 12:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEb5QAbqofX7 for <v6ops@ietfa.amsl.com>; Thu, 8 Dec 2011 12:14:03 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2218A21F8770 for <v6ops@ietf.org>; Thu, 8 Dec 2011 12:14:03 -0800 (PST)
Received: by yenm7 with SMTP id m7so2037324yen.31 for <v6ops@ietf.org>; Thu, 08 Dec 2011 12:14:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:mime-version:date:subject:from:reply-to:to:cc :content-type:content-transfer-encoding; bh=5LkXZLsHuYByr+FGO2MeveKWLb7QCcVkVDcUnKf1cqQ=; b=IhPrqVl25vxl9AhQT1kLX20NqqPaopm/x14XQxCPmz3Aru9IxGjB04SQuA1fBduxxW L3ORU2X1u44s6VhMBnrSFHP+vnRvgk5lOuLPxnSux2s9DUbaRIZh+hbGyRnpGID1Ppc/ NslaRt2ufKAP37uRTzo2LVQ+ubRgV9m976554=
Received: by 10.236.189.6 with SMTP id b6mr7442584yhn.72.1323375241664; Thu, 08 Dec 2011 12:14:01 -0800 (PST)
Received: from nokia.com ([64.57.242.92]) by mx.google.com with ESMTPS id l31sm10747817yhj.22.2011.12.08.12.13.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 12:13:59 -0800 (PST)
Message-ID: <4ee11a87.ab8fec0a.2359.1401@mx.google.com>
MIME-Version: 1.0
Date: Thu, 08 Dec 2011 20:13:59 +0000
From: "tsavo.stds@gmail.com" <tsavo.stds@gmail.com>
To: "shemant@cisco.com" <shemant@cisco.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>
Content-Type: TEXT/PLAIN; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "narten@us.ibm.com" <narten@us.ibm.com>, "v6ops@globis.net" <v6ops@globis.net>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "tsavo.stds@gmail.com" <tsavo.stds@gmail.com>
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: Thu, 08 Dec 2011 20:14:03 -0000

Isn't this pretty extreme corner case? I mean if a DR has 20k RRs in a multicast link, couldn't DR afford to "waste" one /56 and use one /64 out of that /56 for multicast RA, and then not to use exclude option with any RR (i.e. not to delegate anyone the /56 prefix out of which one /64 was taken)? I.e. while this might be interesting to explain, for me this does not sound like a very good reason to delay exclude draft's progress.

Best regards,

Teemu

Sent from my Nokia phone
-----Original Message-----
From: jouni korhonen
Sent:  08/12/2011, 21:32 
To: Hemant Singh
Cc: Thomas Narten; Ray Hunter; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude


Hemant,

On Dec 7, 2011, at 3:40 PM, Hemant Singh (shemant) wrote:

> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Wednesday, December 07, 2011 1:59 AM
> Cc: Ray Hunter; Ted Lemon; Thomas Narten; v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude
>  
>  
> > setup on the DR that is sending an RA with one exclude prefix if the DR has 20K different IPV6 CE routers  as RR’s?  The RA >is multicast and, say, reaches 40K CE routers.   How is the exclude prefix working with the multicast RA?

This would work assuming you then include the pd-exclude only to that single IA_PD that is aggregate of the prefix on the link. The rest of the 19999 RRs' IA_PDs do not need pd-exclude for the prefix.

I setup my home network to mimic a deployment like this just to verify it worked.. i.e. my 'DR' had a Pref::/56 route to 'CE' A. The link where the rest of the routers B etc were, all configure their 'WAN' using SLAAC from Pref::/64 (the excluded prefix).

I think it could be useful to explain this case in pd-exclude draft how and why it actually works according to the conceptual sending algorithm in RFC4861.

- JOuni

>  
> >Is this a real deployment scenario you are designing or already having where you intend to use pd-exclude? My question >regarding this specific example is why you would use RAs & SLAAC to configure 40K CE routers' WAN links attached to a single >link (with one prefix) and then try to apply pd-exclude in the first place?
>  
> I do have a cable deployment where I can have the access concentrator serving 100K PD clients.  The network would like to use the pd-exclude.  The reason I asked my question because one person already said, the DR can use the RA so that the DR can address it’s interface with SLAAC.  There are two choices for such a deployment and that is why I asked the question.  Either the same exclude /64 is given to each of the 100K clients or the network uses unicast RA.  Some IETF document has already defined a unicast.
>  
> Hemant
>  

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops