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

Thanks Eric, see below...

At 12:51 PM 5/16/2003 -0400, Eric Rosen wrote:
>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.

Whatever.  I don't have anything catchy to suggest.  Clearly this is not of 
great importance.

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

That was the answer I expected :-)
But I'm not sure I agree that it's only a deployment issue, or that if it 
is it is out of the scope of the doc.  Does the scheme work if routes to 
the same subnet are advertised from VRFs in 2 PEs, using different RDs?  I 
don't think the current memo says for this case how the PE learning these 
routes should decide which to install.  I don't know if that constitutes a 
problem or not.  If no one else is concerned by this then fine.

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

I don't know if 5.2.3 implies that an LSR must support all these schemes to 
"comply with the MPLS architecture", or whether it implies that they have 
to behave as stated in 5.2.3 or else give up.  Isn't an LSR allowed to 
support only DU?  And its neighbor only DOD? For the case where LDP is used 
for label distribution, we could presumably look for guidance in rfc 
3036.  In sect 3.5.3 if the adjacent LSRs cannot agree on a common mode it 
says:
          If the label advertisement discipline determined in this way is
          unacceptable to an LSR, it must send a Session
          Rejected/Parameters Advertisement Mode Notification message in
          response to the Initialization message and not establish the
          session.
There is similar text in 2.5.3 also.