[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Posted a new copy of CPE Rtr draft
Fred,
Thanks for this response. I agree with it, completely.
Barbara
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Fred Baker
> Sent: Monday, July 20, 2009 2:34 PM
> To: james woodyatt
> Cc: IPv6 Operations
> Subject: Re: Posted a new copy of CPE Rtr draft
>
>
> On Jul 20, 2009, at 11:20 AM, Fred Baker wrote:
>
> >
> > On Jul 20, 2009, at 10:34 AM, james woodyatt wrote:
> >
> >> On Jul 20, 2009, at 09:07, Iljitsch van Beijnum wrote:
> >>>
> >>> Most important issue:
> >>>
> >>> "The CPE Router may also support prefix sub-delegation."
> >>>
> >>> We should make this a MUST. I don't want to end up in the
> >>> situation where I get a crappy DSL IPv6 CPE from my ISP and I
> >>> can't use my own CPE because there is no subdelegation.
> >>
> >> Careful with that axe... if we're going to require prefix sub-
> >> delegation in best-practice CPE routers, then I contend we
> >> absolutely need to specify how that's done with zero
> >> configuration. Are we ready to do that yet? I don't believe we
> >> are. Very happy to be proven wrong about that.
> >
> > Personally, I am uncomfortable with the topic's treatment in this
> > document.
> >
> > draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt and draft-ietf-
> > v6ops-ipv6-cpe-router-00.txt both comment on sub-delegation; the
> > latter tries to specify an algorithm for it. In a document of this
> > type, to my mind, the question is "what RFC MUST/SHOULD/MAY a CPE
> > Router implement", not "what algorithm...". That also reflects the
> > discussion at IETF 74, which recommended dividing the CPE Router
> > Recommendations document into a "2009 recommendations" that would be
> > a working group document and listed RFCs, and a "2010
> > recommendations" that was an individual submission and requested
> > RFCs on various topics to use in future recommendations. I would be
> > far happier with specifying that
>
> reword...
>
> > a) a CPE router with one external and multiple internal interfaces
> > that is delegated a prefix shorter than /64 from its upstream SHOULD
> > assign specific /64s from that to its non-upstream interfaces by an
> > algorithm internal to itself, and
>
> > b) It would be Really Nice if the 6man working group designed a
> > multi-router sub-delegation algorithm for cases in which a small
> > network with multiple routers needs to do so within itself.
>
> By the way, there are many words of caution that apply to auto-sub-
> delegation of prefixes. In general, one wants them to aggregate in a
> nice way without all the issues of renumbering. That means in part
> that there must be some way to recognize when it is inappropriate to
> use the algorithm, such as saying that it is appropriate to networks
> using PA prefixes and in which internal aggregation is not in use. If
> my upstream gives me a /60, there isn't a lot to discuss. If the
> upstream gives a /56 or a /48 and the site in question has multiple
> campuses, auto-sub-delegation is probably pretty difficult to get
> right.
>
> > To me, anything beyond that is not a document making appropriate
> > "recommendations" to vendors regarding their products, or to the
> > likes of CableLabs or BBF regarding the products they deploy.
> >
> > I don't see an RFC or Internet Draft in any working group that tries
> > to specify sub-delegation for SOHO/SMB networks. Fred Templin has
> > three documents that look at the topic, but to my knowledge they
> > have not been picked up by any working group.
> >
>
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625