Re: WG LAST CALL on draft-ietf-ppvpn-rfc2547bis-03.txt

Hi, here are some last call comments on draft-ietf-ppvpn-rfc2547bis-03.txt.

The title is currently "BGP/MPLS VPNs".  Since this work originated there 
are now other, completely different VPN approaches that also use BGP and 
MPLS.  For this reason perhaps, many people refer to VPNs of this type as 
"2547 VPNs".  That may become awkward as this draft becomes an RFC, or if 
there are future revisions.  Perhaps a more specific name should be 
applied.  "BGP-MPLS L3 VPNs" perhaps?
--------

Sect 4.1(?)  There have been some inconclusive discussions on the list as 
to whether it is advisable to use the same RD or different RDs for VRFs in 
a given VPN that are in different PEs.  The question seems especially 
important in the case where a site is multihomed to 2 different PEs.  If a 
route from the CE is advertised by both PEs with the same RD, BGP path 
selection on the VPN-IPv4 routes can be used.  If a route from the CE is 
advertised by both PEs with different RDs, then the conflict needs to be 
resolved in another way at remote PEs when the RDs are stripped and the 2 
IPv4 routes for the same prefix would be placed in a VRF.  It would be good 
if the draft gave guidance on this issue.
--------

In the last paragraph of 4.3 (p. 17) there are 4 uses of the term "VPN-IP" 
route and "VPN-IP" address prefix.  Are these supposed to be 
"VPN-IPv4"?  If not, the VPN-IP concept needs to be explained.
--------

Sect 4.3.2 p. 20 (and a similar statement in sect. 5 p. 25) says the 
following about the outer tunnel:

                                   To ensure interoperability among
    systems which implement this VPN architecture using MPLS label
    switched paths as the tunneling technology, all such systems MUST
    support LDP [MPLS-LDP].

I think "support LDP" is not a strong enough requirement here to ensure 
interoperability.  If this requirement is to be retained at all shouldn't 
it also require support for some specific combination of DU/DOD, 
ordered/independent control, liberal/conservative retention?  (I am not up 
on all the subtleties of which mode combinations can work with each other 
but I suppose it is at least necessary that participating equipment use 
compatible DU/DOD modes.)
--------

Sect. 4.3.4 says to encode VPN-IPv4 NLRI with AFI=1 and SAFI=128.  RFC 2858 
section 8 says "SAFI values 128 through 255 are for "private use", and 
values in this range are not to be assigned by IANA."  Why does the draft 
specify 128?  Shouldn't the value be in 5-127?
--------

In sect. 5 p. 26 there is a list item "- Otherwise" and the 3rd item in the 
sub-list below that says:
          * Otherwise, the IGP Next Hop will have assigned a label for
            the route which best matches the address of the BGP Next Hop.
            Call this the "tunnel label".  The tunnel label gets pushed
            on as the packet's top label.  The packet is then forwarded
            to the IGP next hop.

I see this says to use an outer LSP for a FEC that *best matches* the BGP 
Next Hop.  I had always been under the impression that it was necessary to 
select an outer LSP for a /32 FEC exactly matching the BGP NH (as the first 
item in the outer list here describes).  An LSP for a FEC shorter than a 
/32 would seem almost guaranteed to terminate before reaching the BGP NH 
system where the inner label is meaningful.  No?
--------

In sect. 7 item 4a re using BGP as the PE-CE protocol:
             a) Unlike the IGP alternatives, this does not require the PE
                to run multiple routing algorithm instances in order to
                talk to multiple CEs

Wouldn't multiple instance of BGP be needed in the general case where the 
CEs are in VPNs with overlapping address spaces?
--------

A few typos & nits
Sect. 1.6  s/determine that whether/determine whether/
Sect 1.6  [MPLS/BGP-IPsec] is not in the refs.  Presume this should refer 
to draft-ietf-ppvpn-ipsec-2547-03.
Sect 4.1  s/VPN-IPv4 addresses are IPv4/VPN-IPv4 addresses and IPv4/
Sect. 4.3.1  s/to be installed those/to be installed in those/
p. 20  s/than a label switched/that a label switched/

Sect. 7 p.28:  s/In the case where the CE device is a host or a switch/In 
the case where the CE device is a host/   (Sect 1.2 on p.7 has defined the 
CE device NOT to be a L2 device.)


Thanks,
Mark