The problem is that the juxtaposition of the two paragraphs implies that the term 'virtual router' has some meaning in the context of RFC 4364 and it doesn't.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, July 10, 2012 11:02 AM To: [email protected]; [email protected] Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem-statement-02.txt And I made a paragraph count mistake (mea culpa, sorry), as I confused this w/a private draft that had split the first paragraph into two. The second paragraph in this thread is clearly about BGP/MPLS VPNs, and has no need to use the VRF acronym. "virtual router" is still the correct term for the first paragraph to refer to multiple instances of routing functionality in a single IP router (e.g., one box). If introducing the word "label" will clarify the BGP/MPLS VPN paragraph, that works for me. Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of [email protected] > Sent: Tuesday, July 10, 2012 11:45 AM > To: [email protected] > Subject: Re: [nvo3] VRF text (take 3) in > draft-narten-nvo3-overlay-problem- > statement-02.txt > > Hi David, Luyuan, Thomas, > > [email protected] : > >> - "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? > > I think citing RFC5798 may increase confusion. > As Benson noted, "virtual router" is a term that was (also) used in > RFC4110; this approach (where a full router is virtualized) was not > actively pursued, and instead RFC2547 BGP/MPLS where actively worked > on (where only the routing and forwarding tables are virtualized, but > not the other parts of the router, namely not the routing protocols, > nor the "configuration, operation, accounting, and maintenance" parts > (or at least not all of them). Some confusion comes from considering > that an entity is a router as soon as it forwards IP packets, or > considering that the entity has to run its own *routing* protocols to be a > router... > > In the context of the first paragraph, which really talks about > separate routing instances (also called "VRF lite"), saying "virtual > router" does not look problematic to me. > It would be problematic in the context of the second paragraph which > is about BGP/MPLS. > > >> 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 ;-). > > If I may attempt at a pacifying interpretation (;-): Luyuan sees a > possible source of confusion in calling the inner label an > "encapsulation", since, in the context of NVO3, it plays the role of > the overlay header rather than the role of the IP encapsulation. If my > interpretation is correct, then maybe saying... > > With BGP/MPLS VPNs, an MPLS ***label*** is used to provide > tenant separation > across the transport "underlay" network between PEs. > > ...would resolve the issue. > > -Thomas > > > > > > >> -----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 > > ______________________________________________________________________ > ________ ___________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > 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
