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
