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

Thanks for your comments, most have been incorporated.

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

I have no  problem with "BGP/MPLS L3 VPNs" as the  title, though I've tended
to use "2547-style VPNs" in  other documents.  Frankly, I never have thought
of a really catchy name. 

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

This seems like a deployment issue. 

Mark> I  think "support  LDP" is  not a  strong enough  requirement  here to
Mark> ensure interoperability.  If this requirement is to be retained at all
Mark> shouldn't  it also require  support for  some specific  combination of
Mark> DU/DOD, ordered/independent control, liberal/conservative retention? 

Don't you believe in section 5.2.3 of RFC 3031?