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 protected]]
Sent: Tuesday, August 27, 2013 11:30 PM
To: Eric Gray; [email protected]; [email protected]
Subject: re: About gap analysis on L3VPN [RFC4364]
Importance: High
Hi Eric,
Thanks for your comments, and please see my response inline.
> -----邮件原件-----
> 发件人: Eric Gray [mailto:[email protected]]
> 发送时间: 2013年8月28日 3:23
> 收件人: Xuxiaohu; [email protected]; [email protected]
> 主题: RE: About gap analysis on L3VPN [RFC4365]
>
> 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.
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.
> 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.
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
> 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 protected] [mailto:[email protected]] On Behalf
> Of Xuxiaohu
> Sent: Thursday, August 01, 2013 4:48 AM
> To: [email protected]; [email protected]
> Subject: Re: [nvo3] About gap analysis on L3VPN [RFC4365]
>
> 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 protected] [[email protected]] 代表 Xuxiaohu
> [[email protected]]
> 发送时间: 2013年7月31日 22:43
> 到: [email protected]; [email protected]
> 主题: 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
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
