Subject: 2447bis and related documents

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Jan 2004 12:02:09 -0500

I've spent some time recently reviewing some related documents:

  draft-ietf-l3vpn-rfc2547bis-01.txt
  draft-ietf-l3vpn-as2547-03.txt
  draft-ietf-l3vpn-as-vr-00.txt
  draft-ietf-l3vpn-applicability-guidelines-00.txt

I have some general questions that may develop into concerns, but for
now may just stem from a lack of understanding and history.

I started with draft-ietf-l3vpn-as2547-03.txt, and must say I didn't
really find the document that illuminating. What I would have expected
from an applicability statement is a "here is where you use this
stuff, and here is where you don't" (perhaps with a "why and why not"
to go along with the statements). Also, given that there are at least
two competing solutions, I'd expect an attempt at making it clear
where one would be used vs. the other, so an operator could easily
understand why there are two approaches and  what the percieved major
differences are.

What I found instead was more of a general overview of the protocol
and mechanisms. A fair amount of the discussion in as2547 is in the
2547bis itself (which doesn't seem like what the goal should be).

Also what, could have been more clear is just what the  assumptions
were for this technology. E.g.:

 From a customer perspective:
 
  - customer must run an IGP or BGP with SP (in order to inject/receive routes)
  - customer wants SP to handle the routing across backbone, and just
    wants to treat the backbone as an opaque cloud of sorts, where the
    details of how routing is done is handled by the SP.
  - customer doesn't want to deal with setting up tunnels between CEs
    and managing the logicahl interconnects
  - how the SP actually provides the service is something the customer
    doesn't care about (which is I think a true statement in general)

Is there more to the this than the above? Am I missing something
pretty basic?

From an ISP perspective, I wasn't immediately sure why one would
start with BGP, other than perhaps because they already are using it
and understand it well, _and_ that they have MPLS.

Indeed, I'm a bit confused about the way the documents try to say one
doesn't have to run MPLS (citing draft-ietf-mpls-in-ip-or-gre-03.txt)
as if it was NOT MPLS. How can this be? One absolutely must support
the MPLS labeling scheme, or this stuff just doesn't work. That is,
MPLS in IP is still MPLS. Right? (What am I missing here.)

Looking further, I then see that the AS is modeled after: 
      draft-ietf-l3vpn-as-vr-00.txt

which contains a number of questions to answer about a proposed
solutions. Both AS documents do this, but they tend to say hand-wavy
things like "you can run IPsec here" or this or that, as a way to
mitigate.

Have others read the AS and are you happy with what it says?

Thomas

_______________________________________________
Vpn-dir mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vpn-dir

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Jan 2004 21:49:30 -0500

>MPLS in IP is still MPLS. Right? (What am I missing here.)

The answer to this question is a bit less controversial and more 
straightforward than the answers to the rest of your message, so
I figured I would start with this part. 

Basically the answer depends upon what you mean by "MPLS",
and in which of your routers you are willing to run it. 

In terms of encapsulation, for each packet which is transmitted "in 
the VPN" (ie, each packet which is from a VPN site, to a VPN site, 
and is being transported across the service provider), the BGP/MPLS 
VPN solution requires that (i) the packet be encapsulated in an 
MPLS header; (ii) *some* additional encapsulation (MPLS or IPsec
or MPLS-in-GRE-in-IP or MPLS-in-IP) be used to get the VPN packet, 
encapsulated in the MPLS header, to the appropriate PE router. 

Thus in the most basic form some use of MPLS is needed. However,
strictly speaking this is only *required* in the PE routers, and only in
those specific PE routers which are directly implementing BGP/MPLS
VPNs. Also, all of the signalling regarding which labels to use for this
particular "PE only" MPLS headers is done with BGP, so that no
additional MPLS signaling protocol is required. 

If a second MPLS header is used for transmitting the packets across
the provider backbone, then (i) The provider core routers need to also
implement MPLS; and (ii) An additional MPLS signaling protocol 
(either LDP or RSVP, or both) needs to be run across the network,
from PE router to P router to P router to PE router. This requires more
configuration, and in many cases implies that routers from multiple 
companies interoperate (there are many multi-vendor deployments of 
MPLS, but this doesn't necessarily mean that every service provider 
feels comfortable with the interoperability of every combination of 
vendors that they might have deployed in their network). 

In the past I have talked to a small number of service providers (but 
not necessarily small service providers) who were reluctant to turn 
on MPLS signaling on all of their P and PE routers, and who were
therefore at least pondering the possibility of running 2547 using the 
"private packet over MPLS over GRE over IP" encapsulation. I am
under the impression that there are some deployments of this,
including multi-vendor deployments, although I don't know how much. 

Ross

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Jan 2004 21:46:25 -0500

>Have others read the AS and are you happy with what it says?

The questions are actually taken from the VPN security framework.
The applicability statement for BGP/MPLS L3 VPNs was done before
the AS for VRs. Thus it is natural that the authors of the VR AS may 
have taken a look at the other document before they wrote their AS. 

I think that the correct answer to a lot of these questions is that the
way to secure VPNs in various ways involves use of other protocols
or products or product features. Thus referring to other protocols 
which can be used in conjunction with BGP/MPLS VPNs seems
straightforward to me. 

Ross