Subject: RE: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt

From: Shahram Davari <[email-masked]>
Date: Sat, 2 Nov 2002 02:42:37 -0800

- The proposal seems to be  restricted to backbones that support IPv6.
This
  limits  its  utility rather  severely.   (Well,  one  could use  a
6-in-4
  encapsulation around  the RFC 2473  encapsulation, but that seems
kind of
  silly.)

SD => Any proposal has a scope. The scope of this proposal is IPV6 networks.
Having a scope should not prevent a draft from being advanced in IETF.

- The  proposal requires  that  the ingress  VFI  map a  VPN IP
destination
  address  to an  IPv6 address  which uniquely  identifies a  VFI.   It
then
  assumes that somehow each PE belonging  to a particular VPN knows the
IPv6
  addresses of all the remote VFIs  in that VPN.  It's not worth
considering
  the  case in  which  every VFI  in every  PE  is provisioned  with the
v6
  addresses of  every remote  VFI in  the same VPN;  that would  subvert
the
  manageability/scalability claims that are  being made.

SD=> The scalability is no worst than 2547, which requires that every every PE belonging to a VPN should know the IPV4 address of all other PEs connected to the same VPN and the MPLS label for each of the VFIs.

  So we must
suppose
  that there  is some sort  of discovery scheme  which passes around
the v6
  addresses dynamically.

  Given this sort of discovery scheme, my observation is that it could
just
  as easily pass, for each VFI, the IP address of a PE, along with a
32-bit
  (or 20-bit) label  value that selects a particular VFI  in that PE.
This
  could then be carried as part of  a GRE encaps (or as part of an
MPLS-in-
  IP-or-GRE encaps). 

SD=> I am glad that you brought this up. But my recall is that last time(when I proposed to use IP tunneling for PPVPN) you said it is stupid to tunnel MPLS through IP, because MPLS networks push/pop labels and having IP in some of the tunneling levels makes it very complicated.

  I think the  authors need to make a  case as to why using a  v6
address to
  identify a VFI is better than any of the existing schemes.

SD=> Because it is much simpler and more efficient in IPV6 networks. Why
should you use an extra MPLS label and do an extra lookup in IPV6 networks, when it is not necessary. Besides it wont have the problems
that you have mentioned before regarding mixing up IP and MPLS tunnels.

-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Mon, 04 Nov 2002 11:06:21 -0500

Shahram> Any  proposal has  a  scope. The  scope  of this  proposal is  IPV6
Shahram> networks.  Having  a scope  should not prevent  a draft  from being
Shahram> advanced in IETF. 

Well, I don't think I said that  the draft should be rejected because it has
a  scope.   However,  a proposal  with  a  small  scope would  generally  be
considered to be  at a disadvantage when compared to  a proposal with larger
scope, other things being equal of course. 

Eric> Given this sort  of discovery scheme, my observation  is that it could
Eric> just as easily pass, for each VFI,  the IP address of a PE, along with
Eric> a 32-bit (or 20-bit) label value that selects a particular VFI in that
Eric> PE. This could then be carried as  part of a GRE encaps (or as part of
Eric> an MPLS-in-IP-or-GRE encaps).

Shahram> But my recall is that last time(when I proposed to use IP tunneling
Shahram> for PPVPN) you said it is stupid to tunnel MPLS through IP, because
Shahram> MPLS  networks  push/pop  labels  and  having IP  in  some  of  the
Shahram> tunneling levels makes it very complicated.

Yes, I do  think it gets very  complicated if you have IP  tunnels nested in
MPLS  tunnels  nested  in  IP  tunnels,  nested in  MPLS  tunnels,  etc.   I
definitely think it is best to use MPLS tunnels if it is at all feasible.

However, in  the context of the  draft being discussed, only  IP tunnels are
being used, so that  point is irrelevant.  The issue at hand  is how best to
determine what to do with a  particular IP packet once it reaches the tunnel
endpoint.  This  is most  commonly done  with a demux  field rather  than by
inferring it from the IP destination  address.  I simply pointed out that by
using a  dynamically assigned demux field,  you could increase  the scope of
the proposal, as well as reduce the management burden (and hence improve the
scalability).  And  if you are trying  to integrate with a  VPN scheme which
already distributes MPLS labels as  the demux field, then it is advantageous
to be able to continue to use them.

Your  point to  the contrary  is that  if you  use a  unique  IP destination
address  for each  tunnel, there  is no  need  at the  egress to  look up  a
separate  demux field.  In  effect, the  high order  portion of  the address
identifies the  egress PE uniquely, and  the low order  portion identifies a
VFI relative to a PE.  This suggests to me that the low order portion should
be dynamically assigned  rather than provisioned.  Then, if  a particular PE
was the endpoint  of some IPv4 tunnels and some IPv6  tunnels, it could even
use the same demux value for both  kinds of tunnels, though the IPv4 and the
IPv6 encaps would carry the demux  value in different places.  A proposal of
that sort might be worth considering.  

However, if one assumes that a given  PE might have to terminate both v4 and
v6 tunnels,  I'm not sure whether having  different encapsulation procedures
for each  kind of tunnel (label-after-IP-header  for v4, label-in-IP-address
for v6) works out to be more  or less efficient than having a single kind of
encapsulation (label-after-IP-header)  for both IP  protocols.  Certainly it
makes the control procedures more complicated.