Document: draft-ietf-l3vpn-rfc2547bis-01
Reviewer: Lucy Lynch
Date: June 8, 2004

draft-ietf-l3vpn-rfc2547bis-01.txt
BGP/MPLS IP VPNs (Proposed Standard)
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rfc2547bis-01.txt

"Is this document a reasonable basis on which to build the salient part of
the Internet infrastructure? If not, what changes would make it so?"

This document needs additional work. The structure defers key points to
late in the document, security issues and RCF 2119 considerations need to
be addressed, and ascii art for some senarios would be helpful. An early
section on relationships, (Customer, Service Provider, Carriers Carrier,
etc.), assets (addresses, devices. ASNs) & protocols/policies
(MPLS/extended communnities/BGP/IBGP/EBGP etc.) under senarios including
intranet/extranet/single-provider/multi-provider etc. would also be
helpful. There also seem to be some cases that require very specific
handling which need to be clearly flagged.

That said, this seems really complicated (or flexable depending on your
view point)and sometimes vulnerable to human intervention - not a
great combination if you want this to scale.

Additional Notes:

idnits-v1.31 results:
  Checking conformance with RFC 2026 boilerplate...
  Warnings:
    The document has an RFC 2026 Section 10.4(D) IPR Notice
  Summary: 1 nits

Missing RCF 2119 text -

1.1. Virtual Private Networks
   "We also restrict our discussion to the case in which the backbone
   provides an IP service to the customer, rather than, e.g,  a Frame
   Relay, ATM, ethernet, HDLC, PPP, etc., service.  The customer may
   attach to the backbone via one of these (or other) layer 2 services,
   but the layer 2 service is terminated at the "edge" of the backbone,
   where the customer's IP datagrams are removed from any layer 2
   encapsulation."

-  Does this mean that there is never any customer based tunneled/overlay
   traffic?

3.2. Associating IP Packets with VRFs
   "In some cases, a particular site may be divided by the customer into
   several "virtual sites".  The SP may designate a particular set of
   VRFs to be used for routing packets from that site, and may allow the
   customer to set some characteristic of the packet which is then used
   for choosing a particular VRF from the set.

   For example, each virtual site might be realized as a VLAN.  The SP
   and the customer could agree that on packets arriving from a
   particular CE, certain VLAN values would be used to identify certain
   VRFs.  Of course, packets from that CE would be discarded by the PE
   if they carry VLAN tag values that are not in the agreed upon set."
AND
   "If it is desired to have a particular host be in multiple virtual
   sites, then that host must determine, for each packet, which virtual
   site the packet is associated with.  It can do this, e.g., by sending
   packets from different virtual sites on different VLANs, or out
   different network interfaces."

- This seems to drive a lot of complex decision making to the customer
  edges, which may make customer site to site debugging hairy. Can remote
  customer sites "see" the VRF's for other CE devices?

3.3. Populating the VRFs
   "When we speak of a PE "learning" routes from a CE, we are not
   presupposing any particular learning technique.  The PE may learn
   routes by means of a dynamic routing algorithm, but it may also
   "learn" routes by having those routes configured (i.e., static
   routing).  (In this case, to say that the PE "learned" the routes
   from the CE is perhaps to exercise a bit of poetic license.)"

-  Hand Configured?

   "Note that if two attachment circuits are associated with the same
   VRF, then packets which the PE receives over one of them will be able
   to reach exactly the same set of destinations as packets which the PE
   receives over the other.  So two attachment circuits cannot be
   associated with the same VRF unless each CE is in the exact same set
   of VPNs as is the other."

-  per CE?

4.1. The VPN-IPv4 Address Family
   "The RDs are structured so that every service provider can administer
   its own "numbering space" (i.e., can make its own assignments of
   RDs), without conflicting with the RD assignments made by any other
   service provider.  An RD consists of three fields: a two-byte type
   field, an administrator field, and an assigned number field."

-  OK, at least half of this section is a hack to get around NAT, yes?
   What happens with v6? If you're asking customers to manage really
   complex policies, why not just use v6 instead of NAT? This still leaves
   the provider dealing with the "multiple routes to a site"  problem,
   however:

   "RDs are given this structure in order to enled VPN-IPv4 NLRI, they
   must use BGP Capabilities Advertisement to ensure that they both are
   capable of properly processing such NLRI."

-  Captial M MUST ?


5. Forwarding
   "If the backbone does not support MPLS, the MPLS packet carrying only
   the VPN route label may be tunneled to the BGP Next Hop using the
   techniques of [MPLS-in-IP-or-GRE].  When the packet emerges from the
   tunnel, it will be at the BGP Next Hop, where the VPN route label
   will be examined.

   At the BGP Next Hop, the treatment of the packet depends on the VPN
   route label (see section 4.3.2). In many cases, the PE will be able
   to determine, from this label, the attachment circuit over which the
   packet should be transmitted (to a CE device), as well as the proper
   data link layer header for that interface.  In other cases, the PE
   may only be able to determine that the packet's destination address
   needs to be looked up in a particular VRF before being forwarded to a
   CE device.  There are also intermediate cases in which the VPN route
   label may determine the packet's egress attachment circuit, but a
   lookup (e.g., ARP) still needs to be done in order to determine the
   packet's data link header on that attachment circuit."

-  does this mean per hop look-ups may be required?

6. Maintaining Proper Isolation of VPNs

- I think the answer to my section one question is "no customer tunnels".

7. How PEs Learn Routes from CEs

      "4. The PE and CE routers may be BGP peers, and the CE router may
         use BGP (in particular, EBGP to tell the PE router the set of
         address prefixes which are at the CE router's site. (This
         technique can be used in stub VPNs or transit VPNs.)

            c) If the site contains "BGP backdoors", i.e., routers with
               BGP connections to routers other than PE routers, this
               procedure will work correctly in all circumstances.  The
               other procedures may or may not work, depending on the
               precise circumstances."

-  This condition may need a security flag, or more explanation.

         "On the other hand, using BGP may be something new for the CE
         administrators."

-  Piece of cake compared to some of this stuff...

         "If a site is not in a transit VPN, note that it need not have a
         unique Autonomous System Number (ASN).  Every CE whose site is
         not in a transit VPN can use the same ASN.  This can be chosen
         from the private ASN space, and it will be stripped out by the
         PE.  Routing loops are prevented by use of the Site of Origin
         Attribute (see below)."

-   assigned by the customer?

         "What if a set of sites constitute a transit VPN?  This will
         generally be the case only if the VPN is itself an ISP's
         network, where the ISP is itself buying backbone services from
         another SP.  The latter SP may be called a "Carrier's Carrier".
         In this case, the best way to provide the VPN is to have the CE
         routers support MPLS, and to use the technique described in
         section 9."

-   Is this a SHOULD?

9. Carriers' Carriers
   "Sometimes a VPN may actually be the network of an ISP, with its own
   peering and routing policies.  Sometimes a VPN may be the network of
   an SP which is offering VPN services in turn to its own customers.
   VPNs like these can also obtain backbone service from another SP, the
   "carrier's carrier", using essentially the same methods described in
   this document.  However, it is necessary in these cases that the CE
                                  ^^^^^^^^^
   routers support MPLS."

-  Yeah, it is a SHOULD or a REQUIRED.

10. Multi-AS Backbones
   "What if two sites of a VPN are connected to different Autonomous
   Systems (e.g., because the sites are connected to different SPs)?
   The PE routers attached to that VPN will then not be able to maintain
   IBGP connections with each other, or with a common route reflector.
   Rather, there needs to be some way to use EBGP to distribute