Hi Luyuan.
> 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.
I don't understand the issue here. "virtual router" is a fairly
general term that has long been in use to describe the case where you
have a single router device that actualy has multiple separate
"virtual" instances that individually behave like separate
routers. E.g., see RFC 2917.
To make this more clear, I'd be happy to add the word "conceptually"
to the sentence as the intent is to describe the conceptual
functionality, not a specific implementation. E.g.:
In the case of IP networks, many routers provide a virtual
routing and forwarding capability whereby a single router
conceptually supports multiple "virtual routers", each using its
own forwarding table, i.e., one tied to a specific tenant or
VPN.
> > "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.
Are we having a terminology issue? I.e, is the issue here the word
"traffic separation"? The term as used here (and in other places in
the document) is for the purpose of logically separating traffic of
different tenants and to keep one tenant from having access to another
tenant's traffic. i.e., "tenant separation".
Are you using the term in the sense of traffic needing be kept on
separate links as opposed to allowing traffic from different VPNs to
traverse over shared links?
> > "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).
So thanks to some offline discussion, I have a much better
understanding of this point now. But it seems to me to be a bit of
splitting hairs.
With BGP/MPLS VPNs, tenant separation is achieved by having an MPLS
label that has significance to the ingress and egress PE. The egress
PE picks the label it wants to use for a given Route Target/Route
Distinguisher. BGP distributes this info back to the ingress PE, which
then knows how to encap VPN traffic for a specific VPN to the egress
PE. If there is an MPLS path as well, the VPN label is stacked, so the
the VPN label is independent of whether an actual MPLS LSR path is
used or whether MPLSoGRE is used.
Now, I think you are arguing that the VPN label is not MPLS. Well,
IMO, that is splitting hairs. It has the syntax of an MPLS label, and
is encoded on the data plane in an MPLSoGRE packet. I would agree that
this is not normal MPLS because in essence, the label is just a
demultiplexor that the ingress/egress PE have agreed to use to denote
a particular VPN. But given that the label is used with MPLS encoding
on the data plane, I think the quoted text is correct and it's a bit
misleading to argue that this is not MPLS...
Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
