+1
I have to add I'm now quite confused why we are even having these motivation
discussions, as the charter was already agreed quite some time ago. We are
actually even late:
--
Jun 2011 - Submit DHCPv6 routing configuration option to IESG for publication
as a Proposed Standard RFC
--
We should focus on technical issues to complete the spec, like the semantics.
Not to spend time repeating old discussions.
Best regards,
Teemu
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of ext
> Maglione Roberta
> Sent: 16. marraskuuta 2011 09:00
> To: mif
> Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option
>
> Hello,
> during the meeting the chairs and many people asked about use cases and
> motivations for this work:
> as I quickly mentioned at the mic there is a draft in v6ops (draft-ietf-v6ops-
> ipv6-multihoming-without-ipv6nat) that clearly explains the use cases and the
> requirements, coming from a Service Provider, for this work.
> In Broadband network environment where the CPE is multi-homed to two
> upstream edge routers and each router provides connectivity for different
> types of services for example internet access and Video on Demand (restricted
> inside a walled garden,) and the Service Provide would like to avoid routing
> on the CPE, there is a need to provision static route entries on RGs/CPEs.
>
> As a Service Provider we believe DHCPv6 is the right tool to that because we
> need a centralized control/management point for storing the customer's
> related info (ipv6 prefix, ipv6 routes, ...) and DHCPv6 is a good place for
> that.
> Using RA's would require to manually provision the edge router and this
> operation is not always possible, for example when router is operated by 3rd
> party.
>
> Regarding the issues raised about the potential need for VRRP on the CPE to
> protect against failure, in my opinion in the scenario described above VRRP is
> not needed because if the connection to the edge router providing internet
> service is down I don't want the user traffic using the other link because the
> other edge router only provides limited connectivity to a restricted walled
> garden. As far as DHCPv6 failure, as many of you know there is ongoing work
> on dhc WG in order to provide DHCPv6 redundancy.
>
> I really would like to see this work progressing because it is needed as many
> Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-without-
> ipv6nat, but also in Broadband Forum documents, if you take a look at WT-
> 124i3 you can find requirements calling exactly for this draft to solve the
> problem described above, this means a community of Service Providers'
> recognized the need for this work.
>
> Thanks
> Regards,
> Roberta
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone
> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
> conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>
> _______________________________________________
> mif mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mif
