Subject: Re: [Isis-wg] IS-IS based VPLS for cloud data center networks

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 Jan 2011 11:20:29 +0800

Hi Vishwas,

> If I understand you right, you are talking about a way to use changes
> to IS-IS to do Inter Data Center address exchange.

No. I proposed to distribute VPN membership information, rather than CE MAC
reachability information, across PE routers by using IS-IS TLV extension. In
addition, the PE routers mentioned here could be the edge devices of a
single data center network. What you were talking about is what OTV does.

> There is something called Overlay Transport Virtualization (OTV),
> which seems to do what you are suggesting. That said I know there were

OTV distributes CE MAC reachability information across OTV edge routers by
using IS-IS messages, which in turn are conveyed in a provider multicast
distribution tree between OTV edge routers. By the way, OTV uses the VLAN
tag to identify difference VPN instances.

Best wishes,
Xiaohu

> attempts to send addresses instead of doing L2 learning for VPLS,
> quite a while back.
> 
> Thanks,
> Vishwas
> 
> On Fri, Jan 7, 2011 at 1:26 AM, Xu Xiaohu <[email-masked]> wrote:
> > Hi all,
> >
> > Cloud data centers require large L2 network which should not only be
able
> to
> > support shortest path forwarding and ECMP for maximizing the bandwidth
> > capacity between servers, but also be able to provide a huge amount of
VPN
> > instances for isolating hundreds of thousands of tenement within the
data
> > centers. VPLS seems as a good option for this requirement. However, BGP
> and
> > LDP based VPLS solutions seem a bit heavy-weight and hence not much
> > acceptable for some cloud data center providers.
> >
> > So I wonder whether it is reasonable to develop IS-IS based VPLS for
those
> > special cloud data center providers. For example, IS-IS is run between P
> and
> > PE routers, and an extended IS-IS TLV is used by PE routers to
distribute
> > their own VPN membership information (e.g., attached VPN instances and
> > associated VPN labels) among each other. The VPN label will be carried
in
> > the inner MPLS header of L2VPN data packets (e.g., MAC-in-MPLS-in-IP).
> Note
> > that the VPN label here now is just used to identify a particular VPN
> > instance, but not to identify both a particular VPN instance and a
> > particular ingress PE router as the PW label does. The egress PE router
> now
> > could use the source IP address of the outer IP tunnel header in the
> > received L2VPN data packet to identify the ingress PE router.
> >
> > Any comment?
> >
> > Best wishes,
> > Xiaohu
> >
> >
> > _______________________________________________
> > Isis-wg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/isis-wg
> >
>