> 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.
We agree on this, please suggest specific text changes to correct what you believe is wrong. Thanks, --David > -----Original Message----- > From: John E Drake [mailto:[email protected]] > Sent: Tuesday, July 10, 2012 5:23 PM > To: Black, David; [email protected]; [email protected] > Subject: RE: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem- > statement-02.txt > > 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
