Subject: Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access

From: Salman Asadullah <[email-masked]>
Date: Mon, 22 Nov 2004 13:19:12 -0800

Hello Pekka,

Please see in line ...

>>Date: Fri, 5 Nov 2004 08:42:14 +0200 (EET)
>>From: pekka savola <[email-masked]>
>>To: Ciprian Popoviciu <[email-masked]>
>>cc: [email-masked], Salman Asadullah <[email-masked]>,
>>        adeel Ahmed <[email-masked]>
>>Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
>>X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
>>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
>>        version=2.64
>>Sender: [email-masked]
>>X-PMX-Version: 4.7.0.111621
>>X-from-outside-Cisco: 128.107.234.206
>>
>>Hi,
>>
>>There's one thing that came across when doing the operator poll on v6 
>>deployment which might warrant more discussion in the document...
>>
>>On Thu, 21 Oct 2004, Ciprian Popoviciu wrote:
>>>We integrated the feedback received on the first version of the "ISP 
>>>IPv6 Deployment Scenarios in Broadband Access" draft and posted the 
>>>updated document. You can also find it at:
>>>
>>>[...]draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
>>>
>>>We would like to thank Brian Carpenter, Patrick Grossetete, Benoit 
>>>Lourdelet, Tschofenig Hannes, Gert Doering, Alexander Koch for their 
>>>feedback and particularly Pekka for all his help along with his feedback.
>>
>>An operator which has deployed bridged-mode DSL ('RBE') said that the 
>>only solution for providing bulk v6 access at the moment is requiring the 
>>use of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for 
>>v4, the vendors seem to have implemented the same kind of snooping for v6 
>>w/ DHCPv6).
>>
>>Needless to say that that sounds like a very big problem. Requiring 
>>DHCPv6 for address assignment for something like this seems ludicrous at 
>>least :-).

Why do you see DHCPv6 as a problem ?

>>Alternatives seem to be:
>>  1) defining each /64 prefix to advertise for each customer manually, 
>> not using bulk methods: this does not scale, so it's not an option.
>>  2) checking whether providing a single, shared /64 for all the 
>> customers would work (what if there are address conflicts? what about 
>> communication inside the prefix? does this work?)
>>  3) implementing a mechanism which would allow for direct mapping of 
>> VLAN or VC information to the advertised v6 prefix. For example, so that 
>> for VLAN=100 you could just configure a bulk command 
>> 'map-vlan-to-v6-prefix 2001:db8:1::/48', and it would hand out e.g. 
>> '2001:db8:1:64::/64' to the customer -- or something like that, allowing 
>> bulk configuration
>>  4) putting all the customers' v6 prefix information in a RADIUS or 
>> similar database, so that the advertisement information could be digged 
>> up from there. A lot of work, and does not work automatically. This 
>> would also need some glue between bulk config and RADIUS.
>>
>>All of this except 2) seems to be in the realm of implementations, not 
>>requiring IETF protocol modifications, but to get these features 
>>discussed and on the table, maybe such requirements and possible 
>>solutions should be described in the document.
>>
>>Could someone check whether 2) is possible or not, and if yes, which kind 
>>of support it requires in the equipment ?

Option 2 works well and we have also explained it in the PPP section of our 
draft.

You might have see Gert Doering's email on this that option 2 works well.

Regards,
Salman

>>--
>>Pekka Savola                "You each name yourselves king, yet the
>>Netcore Oy                   kingdom bleeds."
>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Nov 2004 11:58:13 +0200 (EET)

On Mon, 22 Nov 2004, Salman Asadullah wrote:
>>> An operator which has deployed bridged-mode DSL ('RBE') said that the only 
>>> solution for providing bulk v6 access at the moment is requiring the use 
>>> of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for v4, 
>>> the vendors seem to have implemented the same kind of snooping for v6 w/ 
>>> DHCPv6).
>>> 
>>> Needless to say that that sounds like a very big problem. Requiring DHCPv6 
>>> for address assignment for something like this seems ludicrous at least 
>>> :-).
>

Because DHCPv6 -- for address assignment -- is only rarely 
implemented, and many vendors seem to have specifically chosen not to 
implement it.

We should not be requiring for the hosts to run DHCPv6 to get a single 
IPv6 address from their ISP.

(DHCPv6 for prefix delegation is different.)

>>> Alternatives seem to be:
>>>  1) defining each /64 prefix to advertise for each customer manually, not 
>>> using bulk methods: this does not scale, so it's not an option.
>>>  2) checking whether providing a single, shared /64 for all the customers 
>>> would work (what if there are address conflicts? what about communication 
>>> inside the prefix? does this work?)
>>>  3) implementing a mechanism which would allow for direct mapping of VLAN 
>>> or VC information to the advertised v6 prefix. For example, so that for 
>>> VLAN=100 you could just configure a bulk command 'map-vlan-to-v6-prefix 
>>> 2001:db8:1::/48', and it would hand out e.g. '2001:db8:1:64::/64' to the 
>>> customer -- or something like that, allowing bulk configuration
>>> similar database, so that the advertisement information could be digged up 
>>> from there. A lot of work, and does not work automatically. This would 
>>> also need some glue between bulk config and RADIUS.
>>> 
>>> requiring IETF protocol modifications, but to get these features discussed 
>>> and on the table, maybe such requirements and possible solutions should be 
>>> described in the document.
>>> 

Ummm.. As far as I saw from Gert's mail, he was doing 4) (or possibly 
something something close to 1), not 2) ?

---

From: Gert Doering <[email-masked]>
Date: Tue, 23 Nov 2004 11:17:36 +0100

Hi,

> >>> not using bulk methods: this does not scale, so it's not an option.

This is what we do on leased line customers (or ATM point-to-point PVC DSL 
access).

> >>>would also need some glue between bulk config and RADIUS.

This is what we do for "bulk" DSL access, which is presented to us as
L2TP connections, so RADIUS is the "natural" way to do it.

[..]
> something something close to 1), not 2) ?

Yes, there must have been some misunderstanding.

Option 2) is something we can't easily test, as we only have a handful
of DSL lines with bridged ethernet available, and on those, our equipment
can't do IPv6 RBE (Cisco 12.3, not 12.3T).  Doing it with a bridge-group
might work, but definitely doesn't scale.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  66629  (65398)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Ciprian Popoviciu <[email-masked]>
Date: Tue, 23 Nov 2004 11:41:36 -0500

Hi Gert,

Few comments in line (marked @@) ...

>L2TP connections, so RADIUS is the "natural" way to do it.

@@
Yes, this the way to do it for a scalable deployment. One way to look at 
the option mentioned by Pekka:

" 2) checking whether providing a single, shared /64 for all the customers 
would work (what if there are address conflicts?  what about communication 
inside the prefix?  does this work?)"

is  to see it as a NBMA network made of multiple PPPoE sessions terminated 
on the same edge router where the initiators of the sessions are assigned 
addresses from the same /64 i.e. similar to IPv4. If the users are 
authenticated locally and provided addresses from the pools defined on the 
router then the RADIUS is not needed and for this reason we mentioned it 
here and not under option 4). This option is simply for the sake of 
discussing the perspective without bringing in the RADIUS but for a 
production deployments, RADIUS is the natural way to do it as you mentioned.

Pekka, did you have something else in mind with option 2), something for 
which the PPP NBMA model discussed in the draft is not representative? 
Something more down the lines of IPv4 RBE like environment?
@@

>might work, but definitely doesn't scale.

@@
One option would be to try IRB but that definitely is not a solution for a 
deployment. As far as IPv6 RBE is concerned, I would like to point out that 
IPv6 RBE is conceptually different then IPv4 RBE. While in the case of IPv4 
the PVCs belong to the same NBMA, same IPv4 subnet, in the case of IPv6 RBE 
each PVC has its own prefix and the traffic is routed between the PVCs.
@@

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Nov 2004 16:58:27 +0200 (EET)

On Tue, 23 Nov 2004, Ciprian Popoviciu wrote:
> @@
> Yes, this the way to do it for a scalable deployment. One way to look at the 
> option mentioned by Pekka:
>
> is  to see it as a NBMA network made of multiple PPPoE sessions terminated on 
> the same edge router where the initiators of the sessions are assigned 
> router then the RADIUS is not needed and for this reason we mentioned it here 
> and not under option 4). This option is simply for the sake of discussing the 
> perspective without bringing in the RADIUS but for a production deployments, 
> RADIUS is the natural way to do it as you mentioned.
>

Yes, I was referring to IPv4 RBE-like environment, where PPP(oE) is 
not used.

---

From: Salman Asadullah <[email-masked]>
Date: Tue, 30 Nov 2004 15:47:38 -0800

Hello All,

We would like to take a quick poll from the group regarding structure of 
our following draft, ISP IPv6 Deployment Scenarios in Broadband Access 
Networks:

http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt

Currently this draft is ~ 60 pages long, we would like to know if we should 
keep it the way it is or split it into 4 different drafts (~15-20 pages 
each) based on technology (DSL, Cable, ETTH, Wireless).

We are hearing two opinions:

1.  We should keep it the way it is, its long but complete and acts as a 
"one stop shop".   Reader can choose the section of interest easily.

2.  We should split the draft, it would result in a smaller technology 
specific draft and eventually more hits.  If we split the draft, there 
could be two options of doing it.

Option 2A: Section 1,2,3,4,5 (these are general section and pretty much 
applies to every BB technology) will be replicated in all 4 drafts. So, we 
will have 4 drafts in total.

Option 2B: Section 1,2,3,4,5 is part of a "general draft" followed by one 
paragraph for each technology where we refer the reader to the new 
technology specific draft.  So, we will have 5 drafts in total (1 general + 
4 technology specific).

Please let us know your thoughts, which route we should take.

Thank you all.

Regards,
Salman