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 and all,

I have a complete (I hope) Section 10 below, along with some responses
marked [pk].

> -----Original Message-----
> From: Mark Duffy [mailto:[e-mail]] 
> Sent: Thursday, April 01, 2004 12:23 PM
> To: Knight, Paul [BL60:1A14:EXCH]; Ross Callon; [e-mail]
> Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and 
> <draft-ietf-l3v pn-as-vr-01.txt>
> 
> 
> At 07:06 PM 3/31/2004 -0500, Paul Knight wrote:
> ...
> >[pk] Yes, it does need to be clarified... New text:
> >The backbone VR is a mechanism to enhance scalability.  The use of
> >backbone VRs is OPTIONAL in VR-based VPNs. When backbone VRs 
> are used, 
> >they SHOULD be configured on all PEs which participate in 
> VPNs carried 
> >over the backbone VRs.
> 
> That seems fine to me.  It doesn't explicitly address the 
> point Ross made 
> that the backbone VR at any given point could be replaced by 
> an actual 
> router adjacent to the PE.  But I think that is an arcane 
> enough point that 
> it can be left to the reader to deduce :-)
> 
[pk]Yes, Ross's point is exactly right, that an actual adjacent router could
provide the same functionality as a VR.  However, the recommended approach
is to configure backbone VRs instead of sticking another box into the
network!
> 
>   ...
> >[pk] Is this more clear?
> 
> Somewhat.  But maybe not enough on the first approach described...
> 
> >New text:
> >
> >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.
> 
> I'm assuming this use of tunnels is in the same sense that 
> they may be used 
> in the non-carriers-carrier case, as described in sect. 3:   
> "CE devices 
> can be attached to VRs over any type of access link (e.g. 
> ATM, frame relay, 
> ethernet, PPP or IP tunneling mechanism such as IPSec, L2TP 
> or GRE tunnels)."
> 
> But if those "access link" tunnels go from the carriers' 
> carrier VRs to the 
> end-user CEs, as I believe you are describing, that would 
> seem to largely 
> bypass the sub-carrier.  The sub-carrier could fill a purely 
> business role 
> as a reseller (which is out of scope of this draft).  The sub 
> carrier could 
> also provide IP connectivity between the end-customer CEs and 
> the carriers' 
> carrier PEs.  But this IP connectivity would not be 
> VPN-aware!  It makes 
> the sub-carrier more like an ISP.  Is this what you have in 
> mind?  If so it 
> could use more description.
[pk] Yes, the sub-carrier is acting as an ISP, providing connectivity but
not a VPN-aware service.
> 
> 
> >   In this case, the VRs of the carrier's carrier provide 
> VPN service 
> > to
> > the remote CEs. This can be particularly useful in cases 
> where the CEs of 
> > the sub-carrier are themselves VRs

[pk] Sorry, the text is not precise enough.  "CEs of the sub-carrier" means
the sub-carrier's devices which look like CEs to the carrier's carrier (the
sub-carrier's P or PE devices), while "remote CEs"="CEs of the customers of
the sub-carrier".

[pk] So (referring to your comment now far below) I'm not *TRYING* to
describe a three-level hierarchy!  I'll try to clarify the text again.

[pk] Also, I managed to sort through the final approach described in section
10, and rewrite it in terms of carrier's carrier and sub-carrier.  By the
way, can you think of better terminology?

So: Section 10 in its entirety:

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. In this case, the VRs of the
carrier's carrier provide VPN service to the remote CEs. 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) 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. 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.

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.

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. 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. 

> 
> Hmm.  This sounds to me like you are now describing a *three* level 
> hierarchy of providers.  We have carriers' carrier (company 
> A), sub-carrier 
> (company B), and sub-carrier's customer (company C) at whose 
> site the CE 
> sits.  But when you make that CE into a VR you make company C a 
> sub-sub-carrier, no?
> 
> 
> >(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.
> 
> So now the CEs belonging to company C are actually VRs 
> belonging to company 
> C.  And these VRs "belonging" to company C are in the same PE devices 
> (owned by company A) as the VRs operated by company A, and 
> connected to 
> them by IP tunnels within the PE?  I can see how the 
> protocols could do 
> that but I am at a loss to understand the business model.  
> And what does 
> company B provide in this case?
> 
> I can only guess that my interpretation is not what you have in mind.
[pk]  Yes, two levels is enough to attempt to describe!
> 
> 
> >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.
> 
> Now that I understand.  :-)
> 
> --Mark
> 
Regards,
Paul
> 
>