Roberta Maglione <[email protected]> wrote: > Thank you for the write up. > It's clear that there is a gap, which TR-187 has filled. > http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf
> RFC4241 is Informational... why didn't TR-187 come to the IETF to
> standardize
> 4241?
rm> [RM] Well, basically there were no new protocol extensions to be
standardized
rm> in order to cover this scenario; the missing piece was a document where
rm> to glue together all the different pieces and specify requirements for
CPE and
rm> BNG, that's why we (speaking as one of the co-editors of TR-187) did
this work
rm> at the BBF/
The issue is whether the Broadband forum does not have the same trade-agreement
status that the IETF has an SDO. This matters to many utilities that are
constrained by trade agreements to procure on via "performance
specifications".
The other issue is whether everyone knows to look towards the Broadband forum
to find the document. I am very glad to find it :-)
> all customers will have to be provisioned.... while IPv6 space is very
> large,
> bigger allocations cost ISPs more money, and so this still seems silly.
rm> [RM] Why do you think it is silly? The ISPs have to make a-priori
decision
rm> about the provisioning model in order to provision the customers with
the right
rm> service profile.
rm> This is not different with what it happens today for IPv4: let's say
you are a
rm> customer that subscribes both Internet and IPTV service, while I'm a
customer
rm> that only subscribes the internet service: my "user profile" on RADIUS
server
rm> will be different from yours.
The ISP is forced to provision IPv6 to *all* customers in an area, regardless
of what the customer actually asks for, or whether they are ready to do
IPv6.
In IPv4 speak, this is like provisioning IPv4 space (and a /29 at that) to
every person in your service area, on the chance that they might use it.
> [RM] I'm not familiar with security, I cannot comment on firewall, but I
> can add some more details on the prefix to be used for the WAN link.
> Actually using a /64 taken from the prefix delegated via DHCP-PD to
number the
> WAN link at the time we wrote the first version of TR-187 was not allowed
by
> RFC3633 because the WAN is the link from where the prefix was received.
> More recently RFC 6603 about Prefix exclude was published so today you
could
> theoretically do that if you use prefix exclude option, but I'm not sure
how
> much this model has been adopted. It is referenced in
draft-ietf-v6ops-6204bis
> WPD-8.
Thanks also for this.
TR187 does not mention 6603...
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
pgp8ZkJydmo9l.pgp
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
