RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and <draft-ietf-l3v pn-as-vr-01.txt>

["Paul Knight" <[e-mail]>]

Hi Mark,

This helps a lot. See inline below...

> -----Original Message-----
> From: Mark Duffy [mailto:[e-mail]] 
> Sent: Friday, April 02, 2004 10:33 AM
> To: Knight, Paul [BL60:1A14:EXCH]; Mark Duffy; Ross Callon; 
> [e-mail]
> Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and 
> <draft-ietf-l3v pn-as-vr-01.txt>
> 
> 
> Paul, this is coming along.  But I don't think it is quite there 
> yet.  Comments below...
> 
> 
> At 02:11 PM 4/1/2004 -0500, Paul Knight wrote:
> >10. Carrier's Carrier Case
> >
> >In some cases, the customer of a VPN is a service provider or carrier
> >offering VPN services for its own customers.  We can 
> describe this as a 
> >VPN hierarchy, with the "carrier's carrier" providing 
> backbone services to 
> >a "sub-carrier." The VR model provides several approaches to 
> implement 
> >this VPN hierarchy.
> >
> >In one approach, tunnels are built from the VRs of the carrier's 
> >carrier
> >to the CEs of the customers of the sub-carrier ("remote 
> CEs"). In this 
> >case, the VRs of the carrier's carrier provide VPN service 
> to the remote CEs.
> 
> nit: I'd suggest adding '("remote CEs")' as I have done in 
> your text just 
> above, in order to establish the meaning of that term.

[pk]Good!
> 
> >The sub-carrier provides transport but does not participate 
> in the VPN
> >services. This can be particularly useful in cases where the 
> sub-carrier's 
> >PE or P devices (which appear as CE devices to the carrier's carrier)
> 
> It doesn't seem accurate in this case to say that the sub-carriers's 
> devices appear as CE devices to the carrier's carrier.  I 
> think the "remote 
> CEs" are the ones that appear as CE devices to the C's C.  The 
> sub-carrier's devices are just part of an IP access network 
> connecting C's 
> C and the remote CEs, no?  Perhaps just omit the whole phrase 
> in parentheses?

[pk]Yes, you're right, they are transparent to the C's C... I'll omit it.
> 
> >  are themselves VRs (which may be instantiated within the 
> same device 
> > as
> > the VRs of the carrier's carrier) and where the sub-carrier is 
> > outsourcing the management of its customers' VPN services.
> 
> I'm not sure what value these intermediate VRs (the ones that 
> are "owned" 
> by the sub-carrier) provide in this case.  If you have 
> anything to add 
> about that it might help.

[pk] These VRs provide a point of control and aggregation for the
sub-carrier, just like a separate router providing transport service.  For
example, the sub-carrier may be able to define its customer-facing circuits
(usually VCs) on these VRs.

I propose expanding the parenthetical expression, like:
(which may be instantiated within the same device as the VRs of the
carrier's carrier, aggregating the connections from the remote CEs)

Does this help?
> 
> >  From the carrier's carrier perspective, this is sometimes 
> called "VPN
> > wholesaling."  The carrier's carrier may support multiple 
> sub-carriers 
> > within a single PE device, through this approach using VRs.
> 
> I think these 2 sentences apply to C's C in general (all 3 
> approaches) so 
> you might want to move these statements to the top or bottom 
> of the section.

[pk] Yes, I'll do that.
> 
> 
> >Another approach is where the sub-carrier's VPN services are 
> completely
> >transparent to the VRs of the carrier's carrier. This is the 
> default case. 
> >It is up to the sub-carrier's VPN service to distribute VPN 
> reachability 
> >among the CEs of its customers.
> >

[pk] Unless I get any objections from the other authors, I think it will be
best to simply remove the third case discussed in section 10 (and below),
since it is not clearly distinguished from the default case, and does not
appear to provide any clear advantages to it.

> >Another approach is for the sub-carrier's VPN service to 
> implement the 
> >VR
> >architecture, using backbone VRs as described in section 
> 5.3. In this 
> >approach, the backbone VRs of the sub-carrier can establish 
> tunnels to 
> >backbone VRs of the carrier's carrier.
> 
> Do you really mean that?  I would expect that in this case 
> the backbone VRs 
> of the sub-carrier would appear to the C's C as CE's, and this would 
> connect to "regular" (customer-facing) VRs operated by the 
> C's C (and not 
> to backbone VRs of the C's C which would face towards the C's C 
> backbone).  And in this case tunnels would not usually be 
> used because the 
> sub-carrier's backbone VR and the C's C VR would usually be directly 
> adjacent.  I.e. I am thinking that this case is just the 
> "default" case but 
> in which the sub-carrier happens to be using backbone VRs 
> (which would 
> actually be transparent to the C's C).  If you have something 
> else in mind 
> maybe it needs a bit more explanation.
> 
> >  Compared to the first approach, this can reduce the number of VRs 
> > needed
> > on the carrier's carrier devices, since the backbone VRs 
> can multiplex 
> > different VPNs.
> 
> Doesn't the C's C need one VR per sub-carrier per POP, regardless?
[pk] Yes, one per "POP" (although that's not really a term defined in this
context, we'd probably have to say "PE of the sub-carrier").  I think the
third case can provide a reduction in VRs compared to the first case, where
it needs one VR per VPN customer of the sub-carrier at best, or one VR per
remote CE at worst... But I really think it's not a clear value compared to
the second case, so I propose to omit this third case unless another author
wants to clarify it.

Thanks and regards,
Paul
> 
> 
> Thanks, Mark
> 
>