RE: AW: draft-wbeebee-ipv6-cpe-router-04 comments

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Mark/Alan,

> -----Original Message-----
> From: Mark Smith
[mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]
> Sent: Monday, March 30, 2009 2:48 AM
> To: Alan Kavanagh
> Cc: Alastair Johnson; Mikael Abrahamsson; Olaf.Bonness@telekom.de;
v6ops@ops.ietf.org
> Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> 
> Hi Alan,
> 
> On Sun, 29 Mar 2009 21:09:37 -0400
> "Alan Kavanagh" <alan.kavanagh@ericsson.com> wrote:
> 
> > Correct, and this is why SP's are not too keen to have routing
localised
> > in the aggregation network before the BNG.
> >
> 
> I'd have thought they should be keen to avoid that, unless all of
their
> customers are all under or likely to all under surveilence at the same
> time!
> 
> The technical requirement of LI is that traffic has pass the
> interception point. As the majority of people are honest, it seems to
> me that optimising the topology to pass the interception point, rather
> than for best throughput and lower latency, is wasteful, and an unfair
> performance and ultimately a network capex and opex cost burden on
> those subscribers who aren't under surveilence, and may never be. Only
> traffic that is to be lawfully intercepted should be forced past this
> interception point, if it doesn't already naturally traverse it.

I don't mind keeping all flows from CPE_1 to CPE_2 going
through the provider's default router, and that is in fact
a perfectly legitimate deployment scenario for VET. But,
if we want CPE_1 to CPE_2 route optimization, there needs
to be some way for them to establish a trust basis. 
 
> Some topologies would inherently make the BNG the best traffic
> interception point e.g. wholesale broadband aggregation via L2TP.
> However, for other topologies (e.g. a single VLAN interconnecting
> customers' ADSL routers, and an upstream default router for access to
> the Internet/other services), traffic can travel direct between
> subscribers / their CPE, as the CPEs have an on-link peer
relationship.
> Should lawful interception be required, either that on-link path could
> be changed to traverse the interception point (e.g., by mechanisms
> such as forced forwarding), or better yet, the interception point be
the
> suspect subscriber's point of interconnection i.e. the specific ADSL
> service that they're using - as all their traffic is naturally going
to
> traverse that point.
> 
> If an SP wants to have a topology that has all traffic traversing the
> BNG, or is forced to because of a legal requirement, that's fine.
> My argument is that other SPs won't have this requirement so they
> shouldn't also be forced to adopt this LI optimal topology - they
> should have the freedom to implement a topology optimised for
> throughput and low latency.
> 
> So, getting back to the discussion point, I think there would be
> value in having a mechanism where downstream CPE can be informed of
> on-link peer-CPE's assigned prefixes, without the CPE themselves
having
> to trust each other's announcements. An idea I had a while back was a
> "prefix redirect", similar to an ND host redirect, issued by, and only
> accepted from, the upstream on-link default router. Not quite as
> optimal as the CPE themselves announcing their prefixes via a routing
> protocol, but it would be more scalable - the CPE would only be
> maintaining topological knowledge for destinations they're currently
> using, rather than for all the destinations they can reach via on-link
> peer CPE.

VET provides exactly such a mechanism. When CPE_1 gets
a redirect from the provider's default router, it can
send credentials (including proof of prefix ownership)
forward to CPE_2. In the reverse path, CPE_2 can send
its credentials to CPE_1. Sure, it's asymmetric - but
it gets the job done.

Fred
fred.l.templin@boeing.com
 
> Regards,
> Mark.
> 
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> > Behalf Of Alastair Johnson
> > Sent: March 28, 2009 1:41 PM
> > To: Mark Smith
> > Cc: Mikael Abrahamsson; Olaf.Bonness@telekom.de; v6ops@ops.ietf.org
> > Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> >
> > Mark Smith wrote:
> > > On Thu, 26 Mar 2009 17:53:05 +0100 (CET) Mikael Abrahamsson
> > > <swmike@swm.pp.se> wrote:
> > >
> > >> On Thu, 26 Mar 2009, Olaf.Bonness@telekom.de wrote:
> > >>
> > >>> Normally the customers are separated from each other by split
> > horizont mchanisms and MAC adress translation techniques.
> > >> Yes, but that defeats the whole purpose of the proposal from Mark
> > >> Smith if I correctly interpret the scenario he proposed.
> > >>
> > >
> > > Yes it would defeat it. The only reason I can think of to require
hair
> >
> > > pinning of traffic between downstream on-link peer CPE is if your
> > > default router is your traffic billing point, and you want to bill
> > > (count) the traffic between those CPE. Otherwise you're probably
> > > unnecessarily forcing a P2P model connectivity model (i.e.
> > > an ATM ADSL backhaul model) onto a multi-access technology (an
> > > Ethernet/ADSL backhaul model).
> >
> > Lawful Interception is another reason that a service provider may
want
> > all traffic from a subscriber aggregated to the default router.
There
> > may be no way around this, depending on the LI requirements that are
> > placed on the service provider, and where the logical interception
point
> > is (BNG vs. DSLAM).
> >
> > aj
> >
> >