Lucy,
> > But they have differences too. First, an NVE supports this feature in
> > term of multi-tenancy environment, while a route does it in a single
> > tenancy case (in one address space only).
>
> I firmly disagree. VLANs can be used for multi-tenancy, with the result that
> there can be multiple instances of the router function in the same physical
> network node in multiple IP address spaces.
--
> I firmly disagree. VLANs can be used for multi-tenancy, with the result that
> there can be multiple instances of the router function in the same physical
> network node in multiple IP address spaces.
--
> [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we talk
> about a router device with bridge capability (i.e. IRB), Isn't such device
> operated under one L3 address space, including physical network address space
> and source/destination address space?
No, we aren't talking about a single "router device" - when I wrote "multiple
instances of the router function", I meant a device that can operate multiple
instances of the router function that can be in separate source/destination
address spaces (e.g., I expect to see multiple independent instances of the
10.0.0.0/8 address block in a multi-tenant data center). In addition, an
NVE has to deal with the underlay address space.
I view that underlay address space as secondary - the routing function makes
an IP routing decision about where to forward a packet. That decision is about
what "logical port" to emit the packet on ("logical interface" is a better
term in this context) - the encapsulation and the underlay address are
functional
consequences of that forwarding decision.
> [Lucy] I may over-simplify the router to focus on this case only. My point is
> that the router device in this case typically handles one L3 address space and
> one MAC address space in the reality.
See above on "multiple instances" of the "router".
Thanks,
--David
> -----Original Message-----
> From: Lucy yong [mailto:[email protected]]
> Sent: Monday, November 25, 2013 11:12 AM
> To: Black, David
> Cc: [email protected]
> Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service
>
> Hi David,
>
> Please see inline.
>
> -----Original Message-----
> From: Black, David [mailto:[email protected]]
> Sent: Monday, November 25, 2013 8:36 AM
> To: Lucy yong
> Cc: [email protected]
> Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service
>
> Lucy,
>
> > Here is my 2cent whether combined L2/L3 service is architecturally
> > same or different from the non-overlay IRB case used today.
> >
> > They are the same in term of the function feature, i.e. a router can
> > provide bridging capability for intra VLAN traffic, and bridging
> > capability for inter VLANs traffic via routing.
> >
> > But they have differences too. First, an NVE supports this feature in
> > term of multi-tenancy environment, while a route does it in a single
> > tenancy case (in one address space only).
>
> I firmly disagree. VLANs can be used for multi-tenancy, with the result that
> there can be multiple instances of the router function in the same physical
> network node in multiple IP address spaces.
> [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we talk
> about a router device with bridge capability (i.e. IRB), Isn't such device
> operated under one L3 address space, including physical network address space
> and source/destination address space? In other words, endpoint and physical
> network are on the same address space. In traditional DC environment, even
> VLAN can provide virtual networks, MAC address is uniquely assigned to
> physical device, so it is effectively only one MAC address space regardless
> whether VLAN is used or not. VLAN provides a virtual private network, it was
> not originally intended to provide independent address spaces.
>
> > Second, an NVE has both VAP interfaces and overlay tunnel interfaces
> > plus internal gw interface. A router only has ports or L2 interfaces,
> > which are equivalent to the VAPs on NVE case. (you point out this)
>
> I think this is over-simplified. A router has interfaces that correspond to
> both overlay tunnel interfaces and its internal gateway (not sure whether this
> was intended to be the gateway facing end systems, or the interface that
> "default"
> is pointed at, if applicable, but the analogy holds for both). For a non-
> overlay environment, these interfaces are not encapsulated, but in general, a
> router has L2/link connectivity to other routers, not just end systems.
> [Lucy] I may over-simplify the router to focus on this case only. My point is
> that the router device in this case typically handles one L3 address space and
> one MAC address space in the reality.
>
> Lucy
>
> > In a multi-tenancy environment, an NVE may be the member for multiple VNs.
>
> And a physical routing implementation may provide logically distinct routing
> for multiple VLANs.
>
> > Some VN may have independent address spaces, some may share the same
> > address space. An NVE needs to have a VN interconnection policy table
> > which indicates which VNs can communicate and which VNs can't
>
> Likewise for routing and VLANs.
>
> > Furthermore the policy may have
> > finer granularity to a level. For example, between L2VNx and L2VNy,
> > the policy
> > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a
> > firewall; for multicast traffic, L2VNx<->L2VNy not permit.
> >
> > IMO: the inter-VN policy should be controlled at the VN level, not to
> > the particular address (ACL level) or particular application (TCP,
> > HTTP level) in the VNs. The latter belongs to the firewall function.
>
> And also likewise for routing and VLANs.
>
> Thanks,
> --David
>
>
> > -----Original Message-----
> > From: Lucy yong [mailto:[email protected]]
> > Sent: Sunday, November 24, 2013 7:50 PM
> > To: Black, David; Erik Nordmark
> > Cc: [email protected]
> > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3
> > Service
> >
> > Here is my 2cent whether combined L2/L3 service is architecturally
> > same or different from the non-overlay IRB case used today.
> >
> > They are the same in term of the function feature, i.e. a router can
> > provide bridging capability for intra VLAN traffic, and bridging
> > capability for inter VLANs traffic via routing.
> >
> > But they have differences too. First, an NVE supports this feature in
> > term of multi-tenancy environment, while a route does it in a single
> > tenancy case (in one address space only). Second, an NVE has both VAP
> > interfaces and overlay tunnel interfaces plus internal gw interface.
> > A router only has ports or L2 interfaces, which are equivalent to the
> > VAPs on NVE case. (you point out this)
> >
> > In a multi-tenancy environment, an NVE may be the member for multiple VNs.
> > Some VN may have independent address spaces, some may share the same
> > address space. An NVE needs to have a VN interconnection policy table
> > which indicates which VNs can communicate and which VNs can't.
> > Furthermore the policy may have finer granularity to a level. For
> > example, between L2VNx and L2VNy, the policy
> > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a
> > firewall; for multicast traffic, L2VNx<->L2VNy not permit.
> >
> > IMO: the inter-VN policy should be controlled at the VN level, not to
> > the particular address (ACL level) or particular application (TCP,
> > HTTP level) in the VNs. The latter belongs to the firewall function.
> >
> > Lucy
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: nvo3 [mailto:[email protected]] On Behalf Of Black, David
> > Sent: Friday, November 22, 2013 6:40 PM
> > To: Erik Nordmark
> > Cc: [email protected]
> > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3
> > Service
> >
> > Writing as an individual, not co-author of draft-narten-nvo3-arch:
> >
> > > What is missing for me is a higher-level statement whether or not we
> > > see an NVE providing combined L2 and L3 service as being
> > > architecturally different that the non-overlay case of a
> > > bridge+router that provides combined service L2 and L3 today.
> > >
> > > If we think it is just the same architecturally, then it would make
> > > sense to state that. If we think it is different, then I think we
> > > need more details that Thomas' text above.
> >
> > IMHO, it should be architecturally the same, and we should say so.
> > The quoted text was intended to head in that direction, so an explicit
> statement
> > seems like a fine idea. I think the touchstone for how L3 service is
> > provided
> > in an L2/L3 service combination should be: "what would happen if there
> > was no network virtualization?"
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: nvo3 [mailto:[email protected]] On Behalf Of Erik Nordmark
> > > Sent: Friday, November 22, 2013 2:12 PM
> > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;
> > > Thomas Narten
> > > Cc: [email protected]; Linda Dunbar
> > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3
> > > Service
> > >
> > > On 11/20/13 12:07 AM, Pankaj Garg wrote:
> > > > Wouldn't the decision to do L2 or L3 service be based on the inner
> > > > frame
> > > fields i.e. destination MAC/IP in the inner frame? Similar to how
> > > switches/routers process packets i.e. based on frame's destination
> > > MAC and destination IP address (if present)?
> > > >
> > > > IMHO, Thomas's original text (pasted below) describes this quite
> > > > well and
> > > concisely.
> > > >
> > > >>> <t>
> > > >>> A virtual network can also provide a combined L2 and L3
> > > >>> service to tenants. In such cases, a tenant sends and
> > > >>> receives both L2 and L3 packets. An NVE recieving packets
> > > >>> from a TS determines the type of service to be applied to
> > > >>> the packet on a per-packet basis as indicated by the
> > > >>> packet's destination MAC address as provided by the TS.
> If
> > > >>> the MAC address corresponds to that of an L3 router (as
> > > >>> determined by the NVE), traffic is given L3
> > > >>> semantics. Otherwise, the packet is given L2 service
> > > >>> semantics. A combined L2/L3 service presents no special
> > > >>> considerations for NVO3, other than packets received from
> a
> > > >>> tenant must be classified as to what type of service they
> > > >>> are to be given before they can be processed.
> > > >>> </t>
> > >
> > > What is missing for me is a higher-level statement whether or not we
> > > see an NVE providing combined L2 and L3 service as being
> > > architecturally different that the non-overlay case of a
> > > bridge+router that provides combined service L2 and L3 today.
> > >
> > > If we think it is just the same architecturally, then it would make
> > > sense to state that. If we think it is different, then I think we
> > > need more details that Thomas' text above.
> > >
> > > FWIW the existing bridge+routers handle multicast conceptually as
> > > bridge-route-bridge. A received multicast packet might need to be
> > > bridged out other L2 ports in the same bridge domain. Then one copy
> > > of packet is passed to the L3 function, which does L3 multicast
> > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given
> > > L3 oIF might correspond to a bridge domain i.e., multiple packets
> > > might need to be sent out different L2 ports for each oIF.
> > >
> > > While that is a bit complex, it is a lot better if the NVO3
> > > architecture is the same as existing combined bridge+router boxes.
> > >
> > > And note that an existing combined bridge+router is architecturally
> > > consistent with separate bridges and a router where the bridges only
> > > do
> > > L2 and the router only does L3.
> > >
> > > Erik
> > >
> > >
> > > _______________________________________________
> > > 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
