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

From: "[email-masked]" <[email-masked]>
Date: Thu, 08 Dec 2011 20:13:59 +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; [email-masked]
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:[email-masked]] 
> Sent: Wednesday, December 07, 2011 1:59 AM
> Cc: Ray Hunter; Ted Lemon; Thomas Narten; [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 15:45:14 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 08, 2011 3:14 PM
To: Hemant Singh (shemant); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude

>Isn't this pretty extreme corner case? 

Absolutely not.  The cable access concentrator is a CMTS that supports from 20K to 100K clients on one network interface of the CMTS.  The RR clients are IPv6 CE routers behind bridged cable modems.  The network interface on the CMTS issues multicast RA to all nodes in the interface downstream.  I already gave such information in a prior email on this subject.  I also suggested to add an Appendix to the pd-exclude document and add the case and its solution to the document.  Cable broadband deployment is also pretty common in the U.S. and other places in the world. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 16:01:46 -0600

Teemu,

Just curious.  In the cellular case, is a multicast RA or unicast RA used?  How many cellular IPv6 PD clients does the DR used in cellular support?

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 08, 2011 3:14 PM
To: Hemant Singh (shemant); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude

Best regards,

Teemu

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 8 Dec 2011 23:15:29 +0100

Hemant,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant
> Singh (shemant)
> Sent: Thursday, December 08, 2011 11:02 PM
> To: [email-masked]; [email-masked]
> Just curious.  In the cellular case, is a multicast RA or unicast RA used?  

unicast is used as each subscriber has its own delegated prefix (e.g. /56) and the
/64 belongs to the delegated prefix.

Ales

> How many cellular IPv6 PD clients does the DR used in cellular support?
> 
> Hemant
> 
> 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
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 18:02:08 -0600

Ok, thanks.  Since the pd-exclude has a direct impact on rfc3633 where rfc3633 applies to all IPv6 nodes and thus pd-exlcude too, it would be very helpful to add an Appendix to the pd-exclude document.  The appendix would list the multicast RA use case and also if the current pd-exclude document does not mention the fact about the unicast RA used in cellular, the appendix should also mention the unicast RA fact.  As you guys can see the text for the Appendix is mostly there and the text gives great context to the reason of the document for subtle deployment issues. 

Hemant

-----Original Message-----
From: Vízdal Aleš [mailto:[email-masked]] 
Sent: Thursday, December 08, 2011 5:15 PM
To: Hemant Singh (shemant); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [v6ops] draft-ietf-dhc-pd-exclude

Hemant,

Ales

---

From: Teemu Savolainen <[email-masked]>
Date: Fri, 9 Dec 2011 07:52:35 +0200

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.

Teemu

2011/12/8 Hemant Singh (shemant) <[email-masked]>

> Absolutely not.  The cable access concentrator is a CMTS that supports
> from 20K to 100K clients on one network interface of the CMTS.  The RR
> clients are IPv6 CE routers behind bridged cable modems.  The network
> interface on the CMTS issues multicast RA to all nodes in the interface
> downstream.  I already gave such information in a prior email on this
> subject.  I also suggested to add an Appendix to the pd-exclude document
> and add the case and its solution to the document.  Cable broadband
> deployment is also pretty common in the U.S. and other places in the world.
>
> Hemant
>
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Dec 2011 08:05:25 +0100

> 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

---

From: jouni korhonen <[email-masked]>
Date: Fri, 9 Dec 2011 11:17:26 +0200

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

---

From: [email-masked]
Date: Fri, 9 Dec 2011 11:09:27 -0500

> 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?

AFAIK, PD-exclude is not used for cable deployments. The common link 
between the DRs (customer routers in this case) and RR (CMTS) uses a 
dedicated 
/64 independant of the PD space. I don't see a need to document this case. 

/JFT

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Dec 2011 10:25:03 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, December 09, 2011 11:09 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

dedicated 
>/64 independant of the PD space. I don't see a need to document this
case. 

How can pd-exclude been even use in cable until the document becomes an
RFC?  I am considering future use.  Anyway forget cable for a moment.
The pd-exclude document has focused on the unicast RA case for the
pd-exclude.  The document also needs to consider the multicast RA case
where only the first RR getting online with a DR has the DR use the RR's
excluded prefix on the link between the DR and the RR.  Thereafter, in
the multicast RA domain, other RR's do not need to be allocated excluded
prefixes.  Such details make sense to add to the document.  

Hemant

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Dec 2011 17:27:51 +0100

Hi,

> prefixes.  Such details make sense to add to the document.  

The deployment scenario where multiple CPEs share a link to the DR 
(aka "multicast RA") and this link has a pd-excluded prefix on it 
doesn't make sense.  Just allocate a non-conflicting /64 and be done.

Adding a non-useful scenario to documents just adds bloat and
needless complexity.

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Dec 2011 10:35:28 -0600

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Friday, December 09, 2011 11:28 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

>doesn't make sense.  Just allocate a non-conflicting /64 and be done.

Not so fast.  Then add specific text to the pd-exclude document that the
document is addressing the unicast RA deployment. The document does not
even mention the unicast RA.  Since RA is both multicast and unicast, it
does make sense to add at least a few sentences for the SP provisioning
system and the DR RA.  If one allocates a non-conflicting /64 to the DR,
then one has moved the network for RFC 3633 use.  So where is text in
the pd-exclude document that says, gee, the pd-exclude should not be
used in the multicast RA deployment? 

Hemant

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Dec 2011 17:39:35 +0100

Hi,

> used in the multicast RA deployment? 

"common sense"?

Gert Doering
        -- Operator

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Dec 2011 11:36:07 -0600

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Friday, December 09, 2011 11:40 AM
To: Hemant Singh (shemant)
Cc: Gert Doering; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

>"common sense"?

The pd-exclude document is updating rfc3633 and all IPv6 networks are
affected as Ole said in the email below to v6ops.  But when we discuss
more, we see the multicast RA is being recommended to go back to rfc3633
behavior.  See the inconsistency we have when we say all networks are
affected and the pd-exclude is solving the problem but the solution is
not recommended for use in the multicast RA. 

http://www.ietf.org/mail-archive/web/v6ops/current/msg11527.html

So let's tone down the pd-exclude text a bit.  The text has got to
mention the document is dealing with unicast RA.  Common sense is
debatable because either the multicast RA network goes back to rfc3633
behavior or the multicast RA network uses pd-exclude with only one RR
and the rest of the RR's are not supported for the pd-exclude option.
Which of the two choices should the multicast RA network go with? 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 10 Dec 2011 11:32:14 -0600

If the pd-exclude document adds something like the Applicability
statement below, then we can close this discussion.

Applicability

   This document is primarily intended for use in IPv6 cellular networks
that use DHCPv6 and unicast IPv6 ND RA.  

Please find the RFC of the unicast IPv6 ND RA and cite the RFC above and
also find any cellular document to reference, if you want to, and add
the reference.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Friday, December 09, 2011 12:36 PM
To: Gert Doering
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

-----Original Message-----

 

Hemant

v6ops mailing list

[email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 12 Dec 2011 15:21:26 -0800

> that use DHCPv6 and unicast IPv6 ND RA.

And what does that statement buy you? If people disagree with it, they can
use pd-exclude anyway. If people agree with it, it's useless. So why but it
in there at all?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 12 Dec 2011 17:47:07 -0600

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Monday, December 12, 2011 6:21 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [v6ops] draft-ietf-dhc-pd-exclude

>And what does that statement buy you?

So that the pd-exclude is NOT used in the multicast RA network because
the pd-exclude document is useless in the multicast network that has to
go back to RFC 3633 behavior.  One author said in an email related to
the pd-exclude that the pd-exclude problem applies to all networks.
But then the solution to the problem does not work in a multicast RA
network for PD acquisition.   The statement should be made so folks know
this document is unable to solve the problem in a multicast RA network.
I have gone hoarse trying to explain this issue.

Hemant

---

From: Sander Steffann <[email-masked]>
Date: Tue, 13 Dec 2011 10:34:32 +0100

Hi,

> So that the pd-exclude is NOT used in the multicast RA network because the pd-exclude document is useless in the multicast network that has to go back to RFC 3633 behavior.  One author said in an email related to the pd-exclude that the pd-exclude problem applies to all networks.   But then the solution to the problem does not work in a multicast RA network for PD acquisition.   The statement should be made so folks know this document is unable to solve the problem in a multicast RA network.  I have gone hoarse trying to explain this issue.

In that case the wording should be stronger. Instead of saying 'This document is primarily intended for use in IPv6 cellular networks' it should say 'The solution provided in this document is incompatible with multicast RA networks and therefore primarily intended for use in non-multicast networks like IPv6 cellular networks'.

Or something like that…
Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 13 Dec 2011 10:44:34 +0100

> In that case the wording should be stronger. Instead of saying 'This document is primarily intended for use in IPv6 cellular networks' it should say 'The solution provided in this document is incom…

Oops. Without the 'primarily' in the last sentence of course.

Met vriendelijke groet,
Sander Steffann

---

From: Jouni <[email-masked]>
Date: Tue, 13 Dec 2011 12:36:55 +0200

Hi,

I would not say "incompatible", since whether using something makes sense in certain deployment is different that incompatible. You don't turn on pd-exclude by accident like in broadcast access networks you do not turn on RFC6085 by accident (excluding misconfiguration). Also, I do not like pointing cellular networks here as the example case; pd-exclude applies to deployments where you have 1:1 pipes between RR and DR (e.g. VLANs, point to point links or other tweaks to mimic such behavior).  So, I would prefer wording like "The solution provided in this document is intended for use in networks with point to point semantics between the RR and the DR."

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Dec 2011 14:43:34 +0100

Sander,

> In that case the wording should be stronger. Instead of saying 'This document is primarily intended for use in IPv6 cellular networks' it should say 'The solution provided in this document is incom…

I have an issue with terminology used here, (even though I might guess at what you are trying to say.)
the RA sent on a cellular network or any other access technology may of course be a multicast packet, regardless of PD exclude or not.

the issue is _if_ one wants to use the excluded prefix on the link-net between the CE and the PE, then it would only make sense to do that in cases where you have L2 isolation between CEs. in cases where all the CEs sit in the same broadcast domain, that combination doesn't work well. 

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Tue, 13 Dec 2011 14:59:09 +0100

Hi Ole,

> I have an issue with terminology used here, (even though I might guess at what you are trying to say.)

I must admit that I exaggerated a bit :-)  I think that Jouni took my meaning and used better words for it..

Thanks,
Sander

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 13 Dec 2011 10:51:20 -0600

Jouni,

Removing "cellular" from the text is fine by me.  The text I prefer is
"The solution provided in this document is intended for use in networks
with point to point semantics between the RR and the DR including use of
the unicast RA." 

The semantics definitely include DHCPv6 and the pd-exclude option but it
may be mistaken that the new option is good for use both in the unicast
RA and the multicast RA network.  Thus it's best to preserve the keyword
of "unicast RA".  One document I can find on the unicast RA is rfc6085.

Thanks,

Hemant

-----Original Message-----
From: Jouni [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2011 5:37 AM
To: Sander Steffann
Cc: Hemant Singh (shemant); [email-masked]; [email-masked];
[email-masked]

Hi,

I would not say "incompatible", since whether using something makes
sense in certain deployment is different that incompatible. You don't
turn on pd-exclude by accident like in broadcast access networks you do
not turn on RFC6085 by accident (excluding misconfiguration). Also, I do
not like pointing cellular networks here as the example case; pd-exclude
applies to deployments where you have 1:1 pipes between RR and DR (e.g.
VLANs, point to point links or other tweaks to mimic such behavior).
So, I would prefer wording like "The solution provided in this document
is intended for use in networks with point to point semantics between
the RR and the DR."

- Jouni

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Dec 2011 19:43:38 -0800

> of "unicast RA".  One document I can find on the unicast RA is rfc6085.

Hemant, I think you're using the wrong terminology. As Ole says, where you
say "multicast RA" you should say "a deployment where multiple CEs are on a
shared layer 2 domain" (e.g., the N:1 model) and where you say "unicast RA"
you should instead say "with a deployment where each CEs is on its own
layer 2 domain".

---

From: jouni korhonen <[email-masked]>
Date: Wed, 14 Dec 2011 11:22:19 +0200

Using Lorenzo's proposed wording:

"The solution provided in this document is intended for use in networks where each RR is on its own layer 2 domain."

Any better?

- Jouni

On Dec 14, 2011, at 5:43 AM, Lorenzo Colitti wrote:

> On Tue, Dec 13, 2011 at 08:51, Hemant Singh (shemant) <[email-masked]> wrote:
> Hemant, I think you're using the wrong terminology. As Ole says, where you say "multicast RA" you should say "a deployment where multiple CEs are on a shared layer 2 domain" (e.g., the N:1 model) and where you say "unicast RA" you should instead say "with a deployment where each CEs is on its own layer 2 domain".

---

From: Sander Steffann <[email-masked]>
Date: Wed, 14 Dec 2011 12:27:35 +0100

Hi,

> "The solution provided in this document is intended for use in networks where each RR is on its own layer 2 domain."

Much better :-)
Sander

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Dec 2011 14:49:35 +0200

Right, I'll massage a new introduction text to pd-exclude based on the below sentence.

- Jouni