David, I would be happy to help. As the text of the two paragraphs has been in flux, would you please send me what you consider to be the latest text?
Thanks, John Sent from my iPhone > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, July 10, 2012 2:46 PM > To: John E Drake; [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. > > 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
