Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

From: Lou Berger <[email-masked]>
Date: Tue, 04 Dec 2012 12:20:25 -0500

Hi Vishwas,
	Was it your intent to  fully incorporated the changes we discussed into
the -01 rev?   If so, I think some were missed (and I can send which in
a separate message.)

Thanks,
Lou

On 11/24/2012 12:21 PM, Vishwas Manral wrote:
> Hi WG-participants,
>  
> As its been a week and I have not heard any objections, I will update
> this requirement and post the draft across.
>  
> Thanks,
> Vishwas
> On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Thanks Lou,
> 
>     Let me heard back from the WG on this, if they have any opinion. If
>     not we can go ahead with your suggestion.
> 
>     -Vishwas
> 
> 
>     On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Vishwas,
> 
>         On 11/16/2012 1:48 PM, Vishwas Manral wrote:
>         > Hi Lou,
>         >
>         > Got it. Can you suggest some text for this? I will try to
>         incorporate
>         > the same into the document.
> 
>         Assuming you don't like my prior attempt:
>         X.  The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].
> 
>         How about something like:
>         X. The solution MUST support Provider Edge (PE) based VPNs.
> 
>         Note that this phrasing doesn't indicate a specific solutions
>         which is
>         why I now suggest "MUST" vs "SHOULD".
> 
>         Lou
> 
>         >
>         > Thanks,
>         > Vishwas
>         >
>         > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <[email-masked]
>         <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>         >
>         >     Vishwas,
>         >             Sure, but it's the BGP information that indicates
>         what IPsec
>         >     tunnels
>         >     are needed / when the SAs get established...
>         >
>         >     Again, I just asking for language that points to this use
>         case, not
>         >     implementation details.
>         >
>         >     Thanks,
>         >     Lou
>         >
>         >     On 11/16/2012 1:34 PM, Vishwas Manral wrote:
>         >     > Hi Lou,
>         >     >
>         >     >> I'm not sure I agree with this statement.  Let's say
>         you have
>         >     >> a BGP VPN that uses IPsec tunnels between the PEs (which
>         >     >> was described in a couple of expired drafts and can be
>         supported
>         >     >> using RFC5566), and then wants to be able to use dynamic PE
>         >     >> to PE IPsec tunnels.  Does this fit your "2 different
>         layer"
>         >     >> perspective?
>         >     > IPsec with ADVPN secures the tunnel and creates the mesh
>         underlay on
>         >     > need basis/ or automatically. L3VPN creates the overlay,
>         >     identifies the
>         >     > tenant/ customer a packet belongs to and passes the
>         packet on.
>         >     >
>         >     > Where do we see the need for tighter integration here?
>         Is it allowing
>         >     > the ability to create groups of ADVPN instances?
>         >     >
>         >     > Thanks,
>         >     > Vishwas
>         >     >
>         >     > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger
>         <[email-masked] <mailto:[email-masked]>
>         >     <mailto:[email-masked] <mailto:[email-masked]>>
>         >     > <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>         >     >
>         >     >     Vishwas,
>         >     >
>         >     >     Please see below.
>         >     >
>         >     >     On 11/16/2012 12:49 PM, Vishwas Manral wrote:
>         >     >     > Hi Lou,
>         >     >     >
>         >     >     > Thanks for the quick reply. Just a few comments
>         prefixed
>         >     with a "VM>":
>         >     >     >
>         >     >     >     >
>         >     >     >     > We can add something in the lines of
>         additional protocols
>         >     >     are run over
>         >     >     >     > the IPsec tunnels and the solution should
>         make an
>         >     effort to
>         >     >     allow for
>         >     >     >     > additional protocols like OSPF to be run
>         optimally without
>         >     >     too many
>         >     >     >     > changes in configuration.
>         >     >     >     >
>         >     >     >     > Infact we have a requirement to the effect
>         in section 4.1
>         >     >     >
>         >     >     >     yes, this is what I referred to as 4.2 below, and
>         >     suggested some
>         >     >     >     replacement text...
>         >     >     >
>         >     >     > OK got it.
>         >     >     >
>         >     >     >     >
>         >     >     >     >     Gateways MUST allow tunnel binding, such
>         that
>         >     >     applications like
>         >     >     >     >    Routing using the tunnels can work seamlessly
>         >     without any
>         >     >     >     updates to
>         >     >     >     >    the higher level application
>         configuration i.e.  OSPF
>         >     >     >     configuration.
>         >     >     >     >
>         >     >     >     >     - In section 4.2, how about:
>         >     >     >     >        (replacement text)
>         >     >     >     >        3.  Gateways MUST allow for the
>         operation of
>         >     >     tunneling and
>         >     >     >     >        routing protocols operating over
>         spoke-to-spoke
>         >     IPsec
>         >     >     Tunnels
>         >     >     >     >        with minimal, or no, configuration
>         impact.
>         >     >     >
>         >     >     > VM> Ok will specifically specify tunnels and
>         routing protocols.
>         >     >     >
>         >     >
>         >     >     Great.
>         >     >
>         >     >     >
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >        X.  The solution SHOULD support
>         BGP/MPLS IP
>         >     VPNs, see
>         >     >     >     [RFC4364].
>         >     >     >     >
>         >     >     >     >     If you want, you can make the "SHOULD" a
>         "MUST", and
>         >     >     "support"
>         >     >     >     could be
>         >     >     >     >     "be compatible with".
>         >     >     >     >
>         >     >     >     > I do not want to go ahead into details of
>         what other
>         >     routing
>         >     >     solutions
>         >     >     >     > it should support.
>         >     >     >     >
>         >     >     >     > With that said I am not sure what you mean
>         by having BGP
>         >     >     MPLS VPN
>         >     >     >     in an
>         >     >     >     > ADVPN scenario. BGP MPLS VPN is a provider
>         provisioned VPN
>         >     >     solution,
>         >     >     >     > this is a customer provisioned one.
>         >     >     >
>         >     >     >     Ahh, interesting point.  When I read the
>         document I was
>         >     >     looking to see
>         >     >     >     if it was scoped purely to CE/customer based
>         solutions.
>         >     >      Reading section
>         >     >     >     2 (intro) and 2.2, I saw no such restriction.
>          So I think
>         >     >     section 2.2
>         >     >     >     should be explicit on this point either way.
>         Which is why I
>         >     >     proposed the
>         >     >     >     text "There is also the case when L3VPNs
>         operate over IPsec
>         >     >     Tunnels."
>         >     >     >     (To explicitly include this case.)  If the WG
>         wants this
>         >     case
>         >     >     excluded,
>         >     >     >     that's fine too.
>         >     >     >
>         >     >     > VM> It is not scoped purely as a CE device
>         scenario, and
>         >     after seeing
>         >     >     > your comment I see no reason to leave that out of
>         scope
>         >     (though if I
>         >     >     > understand your concern better I may feel
>         otherwise). L3VPN
>         >     can work
>         >     >     > over GRE tunnels/ L2TP tunnels, which can
>         themselves use IPsec.
>         >     >     Again in
>         >     >     > my view the L3VPN and the IPsec VPN are 2
>         different layers
>         >     in the
>         >     >     stack
>         >     >     > if they run on the same device.
>         >     >
>         >     >     I'm not sure I agree with this statement.  Let's say
>         you have
>         >     a BGP VPN
>         >     >     that uses IPsec tunnels between the PEs (which was
>         described
>         >     in a couple
>         >     >     of expired drafts and can be supported using
>         RFC5566), and
>         >     then wants to
>         >     >     be able to use dynamic PE to PE IPsec tunnels.  Does
>         this fit
>         >     your "2
>         >     >     different layer" perspective?
>         >     >
>         >     >     Either way, I think such usage should be explicitly
>         in scope
>         >     as it is a
>         >     >     very different model / use case from CE-based IPsec
>         VPNs.
>         >     >
>         >     >     > Do you see a reason to explicitly
>         >     >     > mention L3VPN in this case?
>         >     >
>         >     >     I'm open to different ways to cover the above.
>         >     >
>         >     >     Much thanks,
>         >     >     Lou
>         >     >     >
>         >     >     > Thanks,
>         >     >     > Vishwas
>         >     >     >
>         >     >     >
>         >     >     >
>         >     >     >     > I see the 2 working in different
>         >     >     >     > layers, and interacting only in edge
>         gateways where both
>         >     >     solutions
>         >     >     >     have
>         >     >     >     > an edge.
>         >     >     >
>         >     >     >     Sure, but the problem exists for both.
>         >     >     >
>         >     >     >     Thanks,
>         >     >     >     Lou
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >     I also have a few more minor comments:
>         >     >     >     >
>         >     >     >     > I am ok with the minor suggestions you have.
>         >     >     >     >
>         >     >     >     > Thanks,
>         >     >     >     > Vishwas
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >     - In section 2.1, you introduce the term
>         "NAT
>         >     gateway" and
>         >     >     >     then later
>         >     >     >     >     use just "gateway" when I suspect you
>         mean "NAT
>         >     gateway".  I
>         >     >     >     suggest
>         >     >     >     >     using the term "NAT" and thereby not
>         introduce
>         >     possible
>         >     >     confusion
>         >     >     >     >     between the gateway term defined in
>         section 1.1
>         >     and "NAT
>         >     >     >     gateways".
>         >     >     >     >
>         >     >     >     >     - In section 2.2, s/occupies/requires
>         >     >     >     >
>         >     >     >     >     - In sections 2.2, and Section 3.2 you
>         say dynamic
>         >     >     addresses makes
>         >     >     >     >     static configuration impossible.  This
>         doesn't reflect
>         >     >     the use of
>         >     >     >     >     dynamic dns to handle this issues (and
>         is currently
>         >     >     supported
>         >     >     >     by some
>         >     >     >     >     vendors.)
>         >     >     >     >
>         >     >     >     >     Let me know what you think,
>         >     >     >     >     Lou
>         >     >     >     >    
>         _______________________________________________
>         >     >     >     >     IPsec mailing list
>         >     >     >     >     [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         >     >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>         >     >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         >     >     >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>>
>         >     >     >     >     https://www.ietf.org/mailman/listinfo/ipsec
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >
>         >     >     >
>         >     >     >
>         >     >
>         >     >
>         >
>         >
> 
> 
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 4 Dec 2012 09:54:12 -0800

Hi Lou,

Yes that's the intent. Please let me know what is it that we agreed to,
that is not there in the draft.

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Tue, 04 Dec 2012 14:09:20 -0500

Vishwas

> that is not there in the draft.

Here's what I think has been missed (plus one new comment):

On 11/15/2012 7:14 PM, Vishwas Manral wrote:
>     - In section 2.2, I think mentioning something about the routing
>     implications is worthwhile. How about at the end of the section adding
>     something along the lines of :
>
>         Additionally, the routing implications of gateway-to-gateway
>         communication must be addressed.  In the simple case,
>         selectors provide sufficient information for a gateway to
>         forward traffic appropriately.  In other cases, additional
>         tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are
>         run over IPsec tunnels, and the configuration impact on those
>         protocols must be considered.  There is also the case when
>         L3VPNs operate over IPsec Tunnels.
>
> We can add something in the lines of additional protocols are run over
> the IPsec tunnels and the solution should make an effort to allow for
> additional protocols like OSPF to

Also in section 2.2, the text now says:

   The solution should work in cases where the endpoints are
   administrated by separate management domains, albeit, ones that have
   an existing trust relationship (for example two organisations who are
   collaborating on a project, they may wish to join their networks,
   whilst retaining independent control over configuration)It is for
   this purpose spoke-to-spoke tunnels are dynamically created and torn-
   down.  It is highly desirable that the solution works for the star,
   full mesh as well as dynamic full mesh topology.

This revision now reads that the primary reason for dynamic
spoke-to-spoke tunnels is separate management domains.  I somehow don't
think this was the intent.

In section 4.1 we had discussed replacement text for 3:
On 11/16/2012 12:49 PM, Vishwas Manral wrote:
>>On 11/15/2012 5:44 PM, Lou Berger wrote:
>>        3.  Gateways MUST allow for the operation of tunneling and
>>        routing protocols operating over spoke-to-spoke IPsec Tunnels
>>        with minimal, or no, configuration impact.
>
>VM> Ok will specifically specify tunnels and routing protocols.

You have the following alternate / revised text:
   3.  In many cases additional tunneling protocols (i.e.  GRE) or
   Routing protocols (i.e.  OSPF) are run over the IPsec tunnels.
   Gateways MUST allow for the operation of tunneling and Routing
   protocols operating over spoke-to-spoke IPsec Tunnels with minimal or
   no, configuration impact.  Routing using the tunnels can work
   seamlessly without any updates to the higher level application
   configuration i.e.  OSPF configuration, when the tunnel parameter
   changes.

I think this text is closer, but I think a few additional changes are
needed:
 - GRE and OSPF are examples, so "i.e." should be replaced with "e.g."
 - I think the final sentence is likely to be incorrect in many / most
   real world cases, so would drop the sentence (from "Routing using
   the tunnels can work...")

You also said you'd address the minor comments:
On 11/15/2012 5:44 PM, Lou Berger wrote:
> - In section 2.1, you introduce the term "NAT gateway" and then later
> use just "gateway" when I suspect you mean "NAT gateway".  I suggest
> using the term "NAT" and thereby not introduce possible confusion
> between the gateway term defined in section 1.1 and "NAT gateways".

and

> - In sections 2.2, and Section 3.2 you say dynamic addresses makes
> static configuration impossible.  This doesn't reflect the use of
> dynamic dns to handle this issues (and is currently supported by some
> vendors.)

That's it.  Let me know what you think.

Much thanks,
Lou

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 5 Dec 2012 09:54:11 -0800

Hi Lou,

Thanks for your close reading of the document. I am attaching the changed
document. Please let me know if it looks good.

> think this was the intent.

I have reordered the sentences.

>    the tunnels can work...")
I changed the "can" to a SHOULD for the second part. The idea is no changes
should happen in configuration and our current solution allows that for
most cases (hence SHOULD).

> Updated it. I agree we can separate out the terms NAT gateway/ Gateway,
though for most parts it may be the same device. Prepend NAT to change it
to NAT gateway, as just replacing it with NAT made the sentence out of
place.

> Do you have any reference and suggested text for this? I have not seen the
same in our customer cases.

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Dec 2012 14:47:12 -0500

Hi Vishwas,
	see below for response.

On 12/5/2012 12:54 PM, Vishwas Manral wrote:
> Hi Lou,
> 
> Thanks for your close reading of the document. I am attaching the
> changed document. Please let me know if it looks good.
> 
>     > additional protocols like OSPF to be run optimally without too many 

I don't see any changes in 2.2 related to this (old) comment on routing
implications, am I missing something?

> I have reordered the sentences.

I think that works.

> I changed the "can" to a SHOULD for the second part. The idea is no
> changes should happen in configuration and our current solution allows
> that for most cases (hence SHOULD).

I think this is worse.  Now you're placing requirements on routing
protocols which IMO should not care if (or be aware of when) the tunnel
they are running on is IPsec or carried via IPsec.

What additional point are you trying to make in the following sentence?
   Routing using the tunnels SHOULD work
   seamlessly without any updates to the higher level application
   configuration i.e.  OSPF configuration, when the tunnel parameter
   changes.

Can the sentence just be dropped?

> though for most parts it may be the same device. Prepend NAT to change
> it to NAT gateway, as just replacing it with NAT made the sentence out
> of place.

okay.  I probably just would had stayed with "NAT" and dropped
"gateway", but that's your call.

> Do you have any reference and suggested text for this? I have not seen
> the same in our customer cases.

I've seen this supported on some firewall products in conjunction with
dynamic DNS.  I used one for a couple of years (the spoke used a dynamic
address + DDNS.)  I certainly deffer to the WG on if such usage should
be referenced in this document.  You are, after all, the experts on this
and I'm just an occasional user...

some possible text for section 2.2. could be:
OLD
   The gateways can themselves come up and down, getting different IP
   addresses in the process, making static configuration impossible.
NEW
   The solution should also address the case where gateways use dynamic
   IP addresses.

and section 3.2, perhaps something like:
OLD
   This solution however does not work when the spokes get dynamic IP
   address which the "hub gateways" cannot be configured with.
NEW
   This solution however is complicated by the case when the spokes
   use dynamic IP addresses and DNS with dynamic updates must be used.

Thanks,
Lou

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 5 Dec 2012 12:06:43 -0800

Hi Lou,

> I am a bit confused here.

You said
" I think this text is closer, but I think a few additional changes are
needed:
 - GRE and OSPF are examples, so "i.e." should be replaced with "e.g."
 - I think the final sentence is likely to be incorrect in many / most
   real world cases, so would drop the sentence (from "Routing using
   the tunnels can work...")"

I performed the changes you asked for. For the second part I have told you
the reason below. What am I missing?

> VM> I think this is an important requirement. A tunnel should be able to
provide an interface by which when tunnel IP parameters change we do not
have to change any configuration for higher application like Routing. I had
earlier mentioned in more generic terms earlier but changed to the terms
provided based on feedback from the list.

The entire idea is the with scale configuration needs to be reduced and
that needs to happen across layers, so every layer needs to provide the
service. Let me know what it is I am unable to convey.

>    The solution should also address the case where gateways use dynamic
I am not sure how to 2 sentences mean the same thing, with DDNS inputs you
have given. Are you saying keep the old text as well as add the new text.

>  Same comment as above.

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Dec 2012 17:28:42 -0500

Vishwas,
See below.

On 12/5/2012 3:06 PM, Vishwas Manral wrote:
> I performed the changes you asked for. For the second part I have told
> you the reason below. What am I missing?

I think we're getting changes in section 2 and 4 mixed up.  Let me try
again.  WRT the new section *2.2* I think mentioning something about the
routing implications is worthwhile. How about before the last paragraph
of the section adding something along the lines of :

> have to change any configuration for higher application like Routing. I
> had earlier mentioned in more generic terms earlier but changed to the
> terms provided based on feedback from the list.

What higher level protocols like most routing protocols that use the
tunnel interface IP addresses in operation?

> service. Let me know what it is I am unable to convey.

sure, but I think you're placing new requirements on the routing &
tunneling protocols.

> I am not sure how to 2 sentences mean the same thing, with DDNS inputs
> you have given. Are you saying keep the old text as well as add the new
> text.

Nope.  I was trying to capture the use case in a way that avoided the
problematic text.  Does the latter cover your use case?  If not, we can
go into what I see as problematic with the old text.

>        use dynamic IP addresses and DNS with dynamic updates must be used.

Well these sentences are much closer.  The latter implies that the hubs
are configured with the spokes FQDNs.  We can add something to that
effect if you think it helps.

Thanks,
Lou

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 6 Dec 2012 10:55:46 -0800

Hi Lou,

I have included the other comments. The last one remaining is:

> VM> There are no restrictions on an application protocol like Routing. The
idea is that the lower needs to provide a functionality, so that if
required a higher layer can use it. There is no restriction at all on the
higher layer. Do let me know if that is clearer?

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Thu, 06 Dec 2012 14:15:53 -0500

Vishwas,

I think I see where you're headed.

The text under discussion is:

I read this a requirement being placed on the higher level protocol, but
I believe your intent was on the solution.  How about rephrasing along
the lines of a requirement on the ADVPN solution? Perhaps something like:

   The ADVPN solution SHOULD NOT increase the amount of information
   required to configure protocols running over IPsec tunnels.

Lou

On 12/6/2012 1:55 PM, Vishwas Manral wrote:
> VM> There are no restrictions on an application protocol like Routing.
> The idea is that the lower needs to provide a functionality, so that if
> required a higher layer can use it. There is no restriction at all on
> the higher layer. Do let me know if that is clearer?
> 
> Thanks,
> Vishwas
> 
>

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 6 Dec 2012 15:51:57 -0800

Hi Lou,

Here is the latest draft, with all your comments incorporated.

I will post the draft soon.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 6 Dec 2012 15:52:26 -0800

Sorry. Here it is with the right file.

-Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 6 Dec 2012 15:53:06 -0800

Here finally!!! Sorry about the duplicate mails.

-Vishwas

---

From: Lou Berger <[email-masked]>
Date: Fri, 07 Dec 2012 09:20:05 -0500

Vishwas,
	Much thanks!  I think we're almost there.  The sole remaining item is
the last sentence of 4.1 requirement 3:

Per my previous message, I read this as a requirement being placed on
the higher level protocol, but I believe your intent was on the
solution.  How about rephrasing along the lines of a requirement on the
ADVPN solution? Perhaps something like:

Lou

On 12/6/2012 6:53 PM, Vishwas Manral wrote:
> On Thu, Dec 6, 2012 at 3:52 PM, Vishwas Manral <[email-masked]
>     On Thu, Dec 6, 2012 at 3:51 PM, Vishwas Manral
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Lou,
> 
>         On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger <[email-masked]
>             >     > VM> I think this is an important requirement. A
>             tunnel should be
>             >     able to
>             >     > provide an interface by which when tunnel IP
>             parameters change we
>             >     do not
>             >     > have to change any configuration for higher
>             application like
>             >     Routing. I
>             >     > The entire idea is the with scale configuration
>             needs to be
>             >     reduced and
>             >     > that needs to happen across layers, so every layer
>             needs to
>             >     provide the

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 7 Dec 2012 09:51:01 -0800

Updated. Will post the document across.

-Vishwas

---

From: Lou Berger <[email-masked]>
Date: Fri, 07 Dec 2012 13:57:01 -0500

Excellent & thank you!

Lou

On 12/7/2012 12:51 PM, Vishwas Manral wrote:
> On Fri, Dec 7, 2012 at 6:20 AM, Lou Berger <[email-masked]