Luyuan, > - "virtual routers" <> multiple VRFs on a router ... Could you > help us with the IETF reference if you think your "virtual router" > definition is correct?
Sure, "virtual router" is the correct term, a "virtual router" is definitely not a VRF for a BGP/MPLS VPN and the term "virtual router" has been in use in the IETF for well over a decade. The two paragraphs in question were always intended to refer to the concept of a "virtual router" as that term is used with VRRP, see RFC 5798, and the use of "virtual router" dates back to at least the first version of VRRP, RFC 2338 (1998). In 20/20 hindsight, the use of the VRF acronym in those two paragraphs was a mistake that we are now correcting - that mistake is at the root of this confusion (mea culpa, as I'm a co-author of that original text). Do we need to cite RFC 5798 to make this clearer? > Say MPLS label encap to separate tenant is not accurate enough at > least IMHO. I'm sorry, but not only did Thomas not use the word "label", but the words that he did use are consistent with the second paragraph of Section 1 of RFC 4364 where both labels are referred to as MPLS labels and both are described as being used for encapsulation. I do hope that settles this issue ;-). Thanks, --David > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:[email protected]] > Sent: Thursday, July 05, 2012 10:53 PM > To: Black, David; [email protected] > Subject: RE: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem- > statement-02.txt > > - "virtual routers" <> multiple VRFs on a router. When SPs request "virtual > router" capability of an equipment, they are not asking about VPN. Could you > help us with the IETF reference if you think your "virtual router" definition > is correct? > > - "The combination of virtual router functionality and data plane separation > provides address and traffic isolation for individual tenants." > now you are saying Thomas switched out from talking VPN, even though that > paragraph was talking VPN, and the paragraph after, and the subject... > Regardless, let's assume so, my point still stands that there is no traffic > separation within the DC network infrastructure other than the last hop > distribution. You can share with us what technology you are using to separate > the tenant traffic through the network infra if this is not true. > > - On the MPLS label, good point, agree that VPN label is part of MPLS label > stack. But there is big difference between the VPN label which is the inner > label, and MPLS label for forwarding (LDP, RSVP...) which is the outer label. > Now this helps me to understand why people thought that MPLS VPN approach was > not an overlay, it was hop by hop, network infra aware, etc., more likely it > causes confusion when using the general term of mpls label. We have done many > years of VPN design/deployment work in SP, we generally call it VPN label > explicitly to distinguish from MPLS labels which are used for forwarding > purpose. Say MPLS label encap to separate tenant is not accurate enough at > least IMHO. > > Luyuan > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Thursday, July 05, 2012 9:06 PM > > To: Luyuan Fang (lufang); [email protected] > > Subject: RE: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay- > > problem-statement-02.txt > > > > Luyuan, > > > > I'm sorry but you're seriously misreading Thomas's new text ... > > > > > > "... a single router supports multiple "virtual routers", each > > using its own > > > forwarding table, i.e., one tied to a specific tenant or VPN." > > > - No. VPN with multiple VRFs on a PE does not imply "virtual router" > > > > That statement is correct as written, because it describes widely > > available > > functionality on L2/L3 (Ethernet/IP) data center switches. The > > assumption > > that the statement is about "VRFs" and "PE" in BFGP/MPLS VPNS is > > incorrect. > > > > > > "The combination of virtual router functionality and data plane > > separation > > > provides address and traffic isolation for individual tenants." > > > - No, VPN does not provide traffic separation within the network > > (besides > > > forwarding to the right CE/tenant), it only provides route isolation. > > > > That's likewise incorrect; the VPN acronym was deliberately not used in > > this new text because it concerns data center network switches > > (routers), > > not VPNs. > > > > > > "With BGP/MPLS VPNs, MPLS encapsulation is used to provide tenant > > separation > > > across the transport "underlay" network between PEs." > > > - No. VPN label (inner label) is used for VPN/tenant separation, not > > the MPLS > > > encap (outer label). > > > > That "VPN label" is part of the MPLS label stack, unless I've seriously > > missed > > something. > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Luyuan > > > Fang (lufang) > > > Sent: Thursday, July 05, 2012 6:49 PM > > > To: Thomas Narten; [email protected] > > > Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay- > > problem- > > > statement-02.txt > > > > > > Thomas, > > > > > > It is still not correct, sorry have to say it again. > > > > > > > "... a single router supports multiple "virtual routers", each > > using its own > > > forwarding table, i.e., one tied to a specific tenant or VPN." > > > - No. VPN with multiple VRFs on a PE does not imply "virtual router" > > > implementation. "virtual router" means different kind of partition. > > VRFs are > > > not required to be on separate virtual routers. > > > > > > > "The combination of virtual router functionality and data plane > > separation > > > provides address and traffic isolation for individual tenants." > > > - No, VPN does not provide traffic separation within the network > > (besides > > > forwarding to the right CE/tenant), it only provides route isolation. > > > > > > > "With BGP/MPLS VPNs, MPLS encapsulation is used to provide tenant > > separation > > > across the transport "underlay" network between PEs." > > > - No. VPN label (inner label) is used for VPN/tenant separation, not > > the MPLS > > > encap (outer label). > > > > > > I think we need to discuss if we should keep separate docs., we can > > take care > > > this topic; or merge if WG thinks better that way. > > > Really appreciate your effort in trying... But we need to get it > > right, in a > > > more efficient way. > > > > > > Luyuan > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] On > > Behalf Of > > > > Thomas Narten > > > > Sent: Thursday, July 05, 2012 4:23 PM > > > > To: [email protected] > > > > Subject: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay- > > problem- > > > > statement-02.txt > > > > > > > > Here is another cut at the VRF text. Thanks to both the on-list and > > > > off-list comments/discussion. Hopefully third time's the charm! :-) > > > > > > > > <t> > > > > In the case of IP networks, many routers provide a virtual > > > > routing and forwarding capability whereby a single > > > > router supports multiple "virtual routers", each using > > its > > > > own forwarding table, i.e., one tied to a specific tenant > > or > > > > VPN. Each forwarding table instance is populated > > separately > > > > via routing protocols, and adjacent routers encapsulate > > > > traffic in such a way that the data plane identifies the > > > > tenant or VPN that traffic belongs to. The combination of > > > > virtual router functionality and data plane separation > > > > provides address and traffic isolation for individual > > > > tenants. > > > > </t> > > > > > > > > <t> > > > > Virtual routing and forwarding is also used on PEs as part > > > > of providing BGP/MPLS VPN > > > > service <xref target="RFC4364"></xref>. With BGP/MPLS VPNs, > > > > MPLS encapsulation is used to provide tenant separation > > > > across the transport "underlay" network between PEs. When > > > > PEs are connected by MPLS paths, control plane protocols > > > > (e.g., LDP <xref target="RFC5036"></xref>) are used to set > > > > up the data path between PEs. Whether native MPLS paths or > > > > MPLs over GRE encapsulation is > > > > used <xref target="RFC4023"></xref>, BGP distributes the > > > > necessary labels among PEs for tenant separation. > > > > </t> > > > > > > > > Thomas > > > > > > > > _______________________________________________ > > > > nvo3 mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > > > nvo3 mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
