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

This is fine with me. And I also agree that this is a corner case of already a corner case. The reason why I was slightly in favor of adding some text around this is to avoid repeated discussion that pd-exclude in N:1/broadcast style links would automatically break something..

- Jouni

On Dec 9, 2011, at 9:05 AM, Ole Troan wrote:

>> I meant isn't it corner case that in such deployment the CMTS would have to take /64 out of a /56 that will be delegated to some single poor RR. Couldn't the CMTS easily afford using /64 from some block that is not going to be delegated to any RR? I.e. why would anyone use PD exclude at all in that can of deployment scenario?
>> 
>> Because for me it sounds so weird to use PD exclude in such deployment, I'm not sure we need to add this case to PD exclude draft (even as at appendix). And even less so as it should work out anyway just fine.
> 
> agree. you can't use a per client mechanism like PD exclude and expect that a broadcast mechanism like RA can be used to give per-client prefix information.
> 
> in a 3GPP deployment there is a separate link to each CE. I would suggest we say nothing in this draft about N:1 style links, or other broadcast access network types, where all kinds of "layer violating hacks" are required to create isolation between customers.
> 
> cheers,
> Ole
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops