Subject: re: About gap analysis on L3VPN [RFC4365]

From: Xuxiaohu <[email-masked]>
Date: Thu, 1 Aug 2013 08:47:59 +0000

Hi all,

I'm glad to see that this issue is mentioned in the NVo3 chairs' slides as well (i.e., some references to L3VPN technology-based DC VPN approaches are useful).  Unfortunately, this issue is not discussed further after the survey of adoption of NVGRE and VXLAN drafts. My doubt is in which WG the L3VPN technology-based DC VPN drafts should be pursued (L3VPN WG or NVo3 WG?).

Best regards,
Xiaohu

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Xuxiaohu [[email-masked]]
发送时间: 2013年7月31日 22:43
到: [email-masked]; [email-masked]
主题: About gap analysis on L3VPN [RFC4365]

Hi all,

I noticed that L3VPN [RFC4365] is listed as one of the candidata technologies in the NVo3 gap analysis doc. However, IMHO, the current mechanism defined in RFC4365 alone couldn't support VM mobility which is one of the basic requirements of DC VPN. Hence, I believe it's much worthwhile to have an informational draft describing how to reuse the L3VPN mechanism for DC VPN before performing gap analysis on the L3VPN technology.

Best regards,
Xiaohu

---

From: Eric Gray <[email-masked]>
Date: Tue, 27 Aug 2013 19:23:20 +0000

Xiaohu,

	You're getting ahead of things, a bit.

	It is not the purpose of the Gap Analysis to determine how to fix the gaps.
The purpose of the Gap Analysis is to compare existing candidate approaches to the
requirements being defined in the NVO3 working group - to determine where the
existing candidate technologies/approaches may fall short.

	It is after this analysis is done that we - as a working group - would then be
in a position to make some decisions as to what work may need to be done for each
candidate in order to meet the requirements we've determined.

	Once we've done that, then we can look at farming the specific work out to
other working groups, or re-chartering NVO3 to include fixing what's missing.

	If you are aware of specific gaps in L3VPN technologies - against specific
requirements that have been agreed on by the working group - then please let us
know what those gaps are and we will evaluate including them in the gap analysis 
draft.

	An information draft of the type you describe is not currently in scope for
NVO3, as it would be essentially a "solution" draft for using L3VPN.  We can't stop
you (or anyone else) from writing such a draft, of course.

	I think you (or whoever) should be careful, however, to ensure that this 
draft is aligned with requirements being developed and agreed to in NVO3, or it 
is very likely that any such draft will simply add to the noise at the moment.

	Also, any such draft could not be adopted by the NVO3 working group until
after it is re-chartered to work on solutions, recommended practice or applicability 
work.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, August 01, 2013 4:48 AM
To: [email-masked]; [email-masked]
Subject: Re: [nvo3] About gap analysis on L3VPN [RFC4365]

Hi all,

Best regards,
Xiaohu

Hi all,

Best regards,
Xiaohu
_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 28 Aug 2013 03:29:59 +0000

Hi Eric,

Thanks for your comments, and please see my response inline.

> -----邮件原件-----
> 发件人: Eric Gray [mailto:[email-masked]]
> 发送时间: 2013年8月28日 3:23
> 收件人: Xuxiaohu; [email-masked]; [email-masked]
> 主题: RE: About gap analysis on L3VPN [RFC4365]
> 
> Xiaohu,
> 

Agree. However, the L3VPN technology ALONE as described in [RFC4364] is unsuitable to be listed as a candidate approach since it alone couldn't allow VM migration without IP renumbering, which has been recognized as one of the fundamental requirements of DC VPN. Instead, the combination of existing L3VPN and ARP proxy technologies deserves to be considered as an existing candidate approach. Therefore, we may need an informational draft which describes how to combine the L3VPN and ARP proxy technologies for subnet extension as a reference for the gap analysis. In this way, it would be more helpful for us to find what's still missing in this candidate approach.

> is very likely that any such draft will simply add to the noise at the moment.

Sure, the informational draft that I mentioned above needs to be aligned with the requirements being developed and agreed to in NVO3.  Hence it's better to adopt this draft by the L3VPN WG with the review of NVO3 WG, IMHO. 

Best regards,
Xiaohu

> I'm glad to see that this issue is mentioned in the NVo3 chairs' slides as well (i.e.,
> some references to L3VPN technology-based DC VPN approaches are useful).
> Unfortunately, this issue is not discussed further after the survey of adoption of
> NVGRE and VXLAN drafts. My doubt is in which WG the L3VPN
> technology-based DC VPN drafts should be pursued (L3VPN WG or NVo3 WG?).
> 
> Best regards,
> Xiaohu
> 
> I noticed that L3VPN [RFC4365] is listed as one of the candidata technologies in
> the NVo3 gap analysis doc. However, IMHO, the current mechanism defined in
> RFC4365 alone couldn't support VM mobility which is one of the basic
> requirements of DC VPN. Hence, I believe it's much worthwhile to have an
> informational draft describing how to reuse the L3VPN mechanism for DC VPN
> before performing gap analysis on the L3VPN technology.
> 
> Best regards,
> Xiaohu

---

From: Eric Gray <[email-masked]>
Date: Thu, 29 Aug 2013 22:33:53 +0000

Xiaohu,

	I think I see what you are getting at.

	The way I had anticipated doing this is to incorporate a lot more of the
text from draft-bitar-nvo3-vpn-applicability in the GA draft.  If you read that
draft, you will find that it has a lot of text effectively analyzing limitations of 
various candidate approaches - including L3VPN (using BGP/MPLS IPVPNs).

	Section 7 is essentially all about that.  Moreover, the text in that draft
is not solution specific at the level of detail that you're suggesting.  Instead, it
lists the "gaps" (listing Dynamic Provisioning and VM Mobility, for instance) -
which is what we need to do in the GA draft (but not for every approach we
are currently considering).

	But there is a lot of work required to incorporate relevant text from 
draft-bitar-nvo3-vpn-applicability & draft-hy-nvo3-vpn-protocol-gap-analysis 
into the GA draft:

    o	draft-bitar-... uses the framework draft for the basis of its analysis;
	this needs to be broken down into sections based on requirements
	drafts, thus allowing us to refer to the appropriate sections in the
	GA tables.
    o	we need to determine if there are alternative L3VPN approaches
	(other than BGP/MPLS IPVPNs) and possibly converge on a single
	term to represent the approach.
    o	some of the text needs to be cleaned up (references to 802.1Q
	need to be updated and/or sanitized, for instance).
    o	we need to get convergence in the WG on what set of approaches
	we're going to analyze, and to what extent we are going to analyze
	each approach
	o	draft-bitar-... includes a number of VPN/related technologies
		(IP VPN, VPLS, VPWS, PBB-VPLS, E-VPN, PBB-EVPN, L2VPN,
		VxLAN - to name the ones I saw in a brief scan of the draft)
	o	draft-bitar-... does not include NVGRE and mentions VxLAN
		only once (in passing).
	o	draft-hy-... seems restricted to a smaller set of technologies
		(L3VPN, VPLS/EVPN) and does not include VxLAN or NVGRE.
	o	draft-hy-... is focused on control plane analysis.
    o	we then need to do the analysis consistently across all approaches
	the WG has agreed to (or converged on).

	As much as it would be convenient to have an informational draft 
that talks about the set of enhancements to L3VPN that are needed for a
quick reference point in the GA draft, it would not be suffficient.

	However, if you wanted to pursue this in parallel - in the L3VPN WG
for instance - that would be fine with me.

--
Eric

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2013 11:30 PM
To: Eric Gray; [email-masked]; [email-masked]
Subject: re: About gap analysis on L3VPN [RFC4364]
Importance: High

Hi Eric,

> The purpose of the Gap Analysis is to compare existing candidate 
> approaches to the requirements being defined in the NVO3 working group 
> - to determine where the existing candidate technologies/approaches 
> may fall short.

> 	It is after this analysis is done that we - as a working group - 
> would then be in a position to make some decisions as to what work may 
> need to be done for each candidate in order to meet the requirements 
> we've determined.
> 
> 	Once we've done that, then we can look at farming the specific work 
> out to other working groups, or re-chartering NVO3 to include fixing what's missing.
> 
> 	If you are aware of specific gaps in L3VPN technologies - against 
> specific requirements that have been agreed on by the working group - 
> then please let us know what those gaps are and we will evaluate 
> including them in the gap analysis draft.
> 
> 	An information draft of the type you describe is not currently in 
> scope for NVO3, as it would be essentially a "solution" draft for 
> using L3VPN.  We can't stop you (or anyone else) from writing such a 
> draft, of course.
> 
> 	I think you (or whoever) should be careful, however, to ensure that 
> this draft is aligned with requirements being developed and agreed to 
> in NVO3, or it is very likely that any such draft will simply add to the noise at the moment.

Best regards,
Xiaohu

> 	Also, any such draft could not be adopted by the NVO3 working group 
> until after it is re-chartered to work on solutions, recommended 
> practice or applicability work.
> 
> --
> Eric
> 
> I'm glad to see that this issue is mentioned in the NVo3 chairs' 
> slides as well (i.e., some references to L3VPN technology-based DC VPN approaches are useful).
> Unfortunately, this issue is not discussed further after the survey of 
> adoption of NVGRE and VXLAN drafts. My doubt is in which WG the L3VPN 
> I noticed that L3VPN [RFC4365] is listed as one of the candidata 
> technologies in the NVo3 gap analysis doc. However, IMHO, the current 
> mechanism defined in
> requirements of DC VPN. Hence, I believe it's much worthwhile to have 
> an informational draft describing how to reuse the L3VPN mechanism for 
> DC VPN before performing gap analysis on the L3VPN technology.
> 
> Best regards,
> Xiaohu

---

From: Truman Boyes <[email-masked]>
Date: Thu, 29 Aug 2013 16:53:26 -0400

Xiaohu,

You raise a good point. The keyword is *ALONE*; without the additional
functionality added to L3VPN, it would not be a suitable candidate for DC
VPN. Items to discuss would be host-routing(ie. /32, /128), arp proxy, and
arp localisation.

Truman

On Tue, Aug 27, 2013 at 11:29 PM, Xuxiaohu <[email-masked]> wrote:

> approaches to
> > the
> Agree. However, the L3VPN technology ALONE as described in [RFC4364] is
> unsuitable to be listed as a candidate approach since it alone couldn't
> allow VM migration without IP renumbering, which has been recognized as one
> of the fundamental requirements of DC VPN. Instead, the combination of
> existing L3VPN and ARP proxy technologies deserves to be considered as an
> existing candidate approach. Therefore, we may need an informational draft
> which describes how to combine the L3VPN and ARP proxy technologies for
> subnet extension as a reference for the gap analysis. In this way, it would
> be more helpful for us to find what's still missing in this candidate
> approach.
>
> would then be
> > in a position to make some decisions as to what work may need to be done
> for
> > each
> specific
> > requirements that have been agreed on by the working group - then please
> let
> > us
> scope for
> > NVO3, as it would be essentially a "solution" draft for using L3VPN.  We
> can't
> > stop
> Sure, the informational draft that I mentioned above needs to be aligned
> with the requirements being developed and agreed to in NVO3.  Hence it's
> better to adopt this draft by the L3VPN WG with the review of NVO3 WG, IMHO.
>
> Best regards,
> Xiaohu
>
> adoption of
> technologies in