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

From: Mark Duffy <[email-masked]>
Date: Thu, 15 May 2003 18:13:19 -0400

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

---

From: [email-masked]
Date: Fri, 16 May 2003 10:21:03 +0200

hi all,

another last call comment on the 2547bis draft:

the RFC should state clearly if the following situation is the normal 
situation:

 > In a situation where site A belongs to VPN1, site B to VPN2 and site C
 > to VPN1 and VPN2; then sites A,B,C map to 3 different VRFs, and the
 > VRF for C will contain the union of the routings tables of VPN1 and
 > VPN2.

I found some kind of inconsistency (at least unclear) between the 2 
paragraphs quoted below:

[section 3.1. "VRFs and Attachment Circuits"]
    "We allow the case in which a single attachment circuit is associated
    with a set of VRFs, rather than with a single VRF. This can be
    useful if it is desired to divide a single VPN into several "sub-
    VPNs", each with different connectivity restrictions, where some
    characteristic of the customer packets is used to select from among
    the sub-VPNs.  For simplicity though, we will usually speak of an
    attachment circuit as being associated with a single VRF."

[section 3.2. "Associating IP packets with VRF"]:
    "If an attachment circuit leads to a site which is in multiple VPNs,
    the attachment circuit may still associated with a single VRF, in
    which case the VRF will contain routes from the full set of VPNs of
    which the site is a member."

thanks,
yacine

---

From: Eric Rosen <[email-masked]>
Date: Fri, 16 May 2003 12:51:48 -0400

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?

---

From: Mark Duffy <[email-masked]>
Date: Sat, 17 May 2003 00:23:51 -0400

Thanks Eric, see below...

>to use "2547-style VPNs" in  other documents.  Frankly, I never have thought

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

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

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

---

From: Dan Tappan <[email-masked]>
Date: Sat, 17 May 2003 08:04:48 -0400

At 12:23 AM 5/17/2003 -0400, Mark Duffy wrote:
>the same subnet are advertised from VRFs in 2 PEs, using different RDs?

It is certainly (empirically) possible for an implementation to handle that 
case.

I'd have said that it was an implementation issue, and therefore beyond the 
scope of the document.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 19 May 2003 13:21:57 -0400

Mark> Perhaps a  more specific name  should be applied.  "BGP-MPLS  L3 VPNs"
Mark> perhaps? 

I'll probably go  with "BGP/MPLS IP VPNs", to head  off questions like "does
it work with IPX and Appletalk". 

Mark> Does the scheme work if routes  to the same subnet are advertised from
Mark> VRFs in 2 PEs, using different RDs? 

Yes.  Obviously  though only one  of those routes  will be installed  in the
VRF. 

Mark> I don't think the current memo  says for this case how the PE learning
Mark> these routes should decide which to install. 

Correct, it does not.  This question comes up regularly.  One could specify,
for example,  that the one  (or more, if  load balancing is  being provided)
installed should be the one that BGP would have chosen if the two routes had
had the same RD.  Or one could  specify that the one installed should be the
one  whose  BGP  next  hop  is   the  closest.   There  may  also  be  other
possibilities.  However,  leaving it as an implementation  decision does not
seem to cause any loops or interoperability problems, so it is probably best
to leave it unspecified. 

Mark> Isn't an LSR allowed to support only DU?  And its neighbor only DOD? 

Good catch, so  per section 3.5.3 of RFC 3036 we  should really require that
DU be supported on non-LC-ATM interfaces, and DoD on LC-ATM interfaces.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 19 May 2003 14:54:00 -0400

>it work with IPX and Appletalk".

sounds fine to me

>seem to cause any loops or interoperability problems, so it is probably best

I would be more comfortable with that if the document at least mentioned 
that this case exists and needs to be dealt with.  It is a bit subtle and 
it is not unlikely that people might build implementations that do not 
address it.

>DU be supported on non-LC-ATM interfaces, and DoD on LC-ATM interfaces.

fine by me.
probably the text should also mention LC-FR, in the DoD camp.