Subject: RE: L3vpn Digest, Vol 19, Issue 5

From: Libin <[email-masked]>
Date: Mon, 21 Nov 2005 17:30:48 -0600

Benson & Mark,
I'm appreciated that you read my ipv6-vpn draft and give some advice. Maybe
I organized it not very well. I must explain the motivation that I issue
this draft.
1) IPv6-vpn has all advantages of BGP IP-tunnel VPN for ipv6. These
IP-tunnels include GRE, IPinIP, IPSec and L2TPv3. This allows we construct a
VPN over a pure IP network, no MPLS signaling and forwarding. I believe it's
an original motivation to use IP tunnel replace MPLS tunnel in BGP/MPLS VPN.
In addition, if we use IP rather than MPLS, it's easy to construct inter-as
VPNs. MPLS VPN has 3 options here. Recently someone issue a draft about 4th
option. I believe it's too puzzled for carriers. Which option should be
chose? In fact, few carriers can deliver inter-as VPN service. In contrast,
it's very easy to across multiple AS if you use IPv6 VPN as long as IPv6
routes distribute among them. 
2) If we translate local ipv6 address (VPN-local address) to global ipv6
address (VPN-global address) at site edge router, we can save encapsulating
cost from IP tunnel or MPLS tunnel. There are enough bits at IPv6 header.
Why should we waste them?
3) Draft-ietf-l3vpn-bgp-ipv6 didn't solve multicast problem. My draft has a
good suggestion about it. Because we reserve local group address and append
a global group address at IPv6 header, It's flexible to manipulate IPv6
multicast packet in backbone. For example, you can route it by global group
address only, if you don't want optimize traffic for individual user's
group, which is same as local group. Otherwise, you can route it by <global
group address, local group address> duplet. In this condition, we can
establish individual multicast tree for each user's group if we want. This
manner is very similar as longest match routing arithmetic of unicast. So we
call it multicast longest match routing.
4) If we assign same routing prefix to a site for both of internet and VPN
access, but only assign different leader character, 001 or 010. The global
routing table of backbone router can be reused as VPN routing table. In
other words, VPN unicast routing is free in backbone.
5) By translate ipv4 address to ipv4-embedded ipv6 address, IPv6 VPN can act
as a migration tool from IPv4 network to IPv6 network. I think carrier's
network is easy to migrate to ipv6, but customer's network won't do it very
quickly.

In summary, BGP/MPLS VPN extension for ipv6 can work, but I think it should
be simplified and optimized, because we can utilize the advantage of ipv6.
Why do we must transplant from ipv4 VPN without any change?

Regards,

Bin Lee

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, November 12, 2005 11:09 AM
To: [email-masked]
Subject: L3vpn Digest, Vol 19, Issue 5

Send L3vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/l3vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of L3vpn digest..."

Today's Topics:

   1. RE: An observation (Schliesser, Benson)
   2. Re: An observation (Marshall Eubanks)

----------------------------------------------------------------------

Message: 1
Date: Fri, 11 Nov 2005 14:12:59 -0600
From: "Schliesser, Benson" <[email-masked]>
Subject: RE: An observation
To: <[email-masked]>
Message-ID:
	
<[email-masked]
t>
	
Content-Type: text/plain;	charset="us-ascii"

Mark-
 
> - InterAS: We have documented 10a, 10b, and 10c, it seems to be well 
> understood, but perhaps we want a 10d as well.

My perspective as a provider is that a, b, and c are a poor set of options
to choose from. I find each option to be some combination of
difficult-to-manage and over-exposing. However the "option d" described by
draft-kulmala-l3vpn-interas-option-d appears to be a good model that I would
like to see progress on.

> - Multicast: We have a documented solution, but perhaps we want to do 
> something different with BGP or PWs instead.

I am in process of reading through the new drafts (which is more painful
than it ought to be), so I can't comment very specifically yet. But in
general, I can say a couple things.

The previously documented solution is incomplete and/or sub-optimal. I would
like to see a better solution and I believe the presence of this discussion
in the WG is evidence that I am not alone in this thinking. I believe it
would benefit everybody if we continued progress in this topic.

However I find the new proposals suffering in several ways, especially from
complexity, and it is possible that not all of them can count as "progress".
I applaud and encourage more work on the underlying/fundamental issues,
problem analysis, requirements, etc. More of this should be done before we
try to shoe-horn new solutions--perhaps a bit of perspective would be
valuable to the authors of these new drafts.

> - IPv6: We have documented IPv6 L3VPNs, but perhaps we want to
translate
> addresses at the edge rather than encapsulate in tunnels.

I have to agree with your questioning of this topic. I tend to believe that
the mechanisms of a L3 VPN should apply equally (generically even?) to IPv4
and IPv6 and perhaps other L3 protocols, and I think our current model is a
good foundation for this. Of course, it might be nice if we had some open
discussion about the applicability of L3VPN to IPv6 in the first place.
(i.e., Do the motivators for a VPN in IPv4 still exist in IPv6? If so what
are they?)

> Are we solving significant problems, or making work for ourselves?
>
> Comments appreciated.

I appreciate your questions; thank you for posting them to the list. I hope
others will chime in with their comments, contradictions, etc.

Cheers,
-Benson

------------------------------

Message: 2
Date: Sat, 12 Nov 2005 09:46:55 -0500
From: Marshall Eubanks <[email-masked]>
Subject: Re: An observation
To: "Schliesser, Benson" <[email-masked]>
Cc: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Hello;

On 11/11/05, Schliesser, Benson <[email-masked]> wrote:
>
> Mark-
>
> > - InterAS: We have documented 10a, 10b, and 10c, it seems to be well 
> > understood, but perhaps we want a 10d as well.
>
> My perspective as a provider is that a, b, and c are a poor set of 
> options to choose from. I find each option to be some combination of 
> difficult-to-manage and over-exposing. However the "option d" 
> described by draft-kulmala-l3vpn-interas-option-d appears to be a good 
> model that I would like to see progress on.
>
> > - Multicast: We have a documented solution, but perhaps we want to 
> > do something different with BGP or PWs instead.
>
> I am in process of reading through the new drafts (which is more 
> painful than it ought to be), so I can't comment very specifically 
> yet. But in general, I can say a couple things.
>
> The previously documented solution is incomplete and/or sub-optimal. I 
> would like to see a better solution and I believe the presence of this 
> discussion in the WG is evidence that I am not alone in this thinking. 
> I believe it would benefit everybody if we continued progress in this 
> topic.
>
> However I find the new proposals suffering in several ways, especially 
> from complexity, and it is possible that not all of them can count as 
> "progress". I applaud and encourage more work on the 
> underlying/fundamental issues, problem analysis, requirements, etc. 
> More of this should be done before we try to shoe-horn new 
> solutions--perhaps a bit of perspective would be valuable to the 
> authors of these new drafts.
>

As Nidhi Bhaskar said after the PIM WG  meeting, multicast is complicated,
L3VPN is complicated, Multicast-L3VPN's are going to be very complicated.

I think, with the cross-fertilization at the recent IETF, that the multicast
community has woken up to the challenge of L3VPNs, and I hope that there may
be some rapid progress in this area. I think that changes are needed in PIM
to support this, and I believe that there is now buy-in from the PIM-WG for
doing these changes in a rapid manner (i.e., via L3VPN extensions to PIMv2,
instead of creating PIMv.3).

I do not want there to be a fork in multicast development, with two separate
communities of developers. I do not see that this is in anyone's benefit.

Regards
Marshall Eubanks

> > - IPv6: We have documented IPv6 L3VPNs, but perhaps we want to
> translate
> > addresses at the edge rather than encapsulate in tunnels.
>
> I have to agree with your questioning of this topic. I tend to believe 
> that the mechanisms of a L3 VPN should apply equally (generically 
> even?) to IPv4 and IPv6 and perhaps other L3 protocols, and I think 
> our current model is a good foundation for this. Of course, it might 
> be nice if we had some open discussion about the applicability of 
> L3VPN to IPv6 in the first place. (i.e., Do the motivators for a VPN 
> in IPv4 still exist in IPv6? If so what are they?)
>
> > Are we solving significant problems, or making work for ourselves?
> >
> > Comments appreciated.
>
> I appreciate your questions; thank you for posting them to the list. I 
> hope others will chime in with their comments, contradictions, etc.
>
> Cheers,
> -Benson
>
>

------------------------------

_______________________________________________
L3vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l3vpn

End of L3vpn Digest, Vol 19, Issue 5
************************************