Robert, We are talking about L3VPN and E-VPN over an IP infrastructure so there is no LDP or RSVP-TE. Rather, the only label is the service label which is distributed via BGP or XMPP.
Irrespectively Yours, John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Robert Raszuk > Sent: Sunday, December 09, 2012 11:06 AM > To: Aldrin Isaac > Cc: Melinda Shore; [email protected] > Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > Aldirn, > > > Now with support for MPLS in merchant silicon, I don't see any good > > reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held > > back > > For service demux I see no issue as well > > For transport I see two major issues: > > - MPLS requires new signalling protocol ... DC fabric and hosts which > do act as PEs should be as simple as possible, but not simpler hence > introduction of LDP or worse RSVP-TE to signal the labels seems not > helpful. > > - MPLS FECs can not be summarized. With IP we just need information how > to reach subnet X ... with MPLS (even if one would provide the relaxed > match) FECs are still /32s That's a lot of them in large data centers. > > Cheers, > R. > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
