Linda,
Linda Dunbar <[email protected]> writes:
> I posted those comments and suggested text changes during the WG
> Adoption process. Since I havenât heard any replies from the
> authors, I am re-posting my suggested addition and change of text
> to draft-narten-nvo3-arch-01 plus a few more suggestions to clear
> out issues being discussed on the mailing list.
Apologies for not getting back sooner. These had not been forgotten,
but they also require more involved response.
> Issues with the current writing of Distributed Gateway (Section 5.4):
>
> As described in Section 5.3, a Gateway does many things. However, I
> donât think that a NVE, if taking on the responsibility of a
> distributed Gateway, will do all the things that a conventional
> Gateway does (or the list of items mentioned in the Section 5.3).
To be clear, Section 5.4 "Distribute Gateways" was really about
Inter-VN gateways. The heading could have been clearer.
> First, it might be too much to ask a NVE based gateway (especially
> Hypervisor based NVE) to
>
> · relay traffic off the virtual networks, i.e. perform gateway
> function to reach destinations outside the local VNs,
> · serve as IPSec gateway to external (i.e. out of Virtual Networks),
> · perform NAT on the source virtual addresses, or
> · relay traffic to a VN that doesnât have any hosts attached to the
> NVE (it is debatable if a NVE based distributed Gateway should take this
> responsibility)
>
> The meaningful functions performed by NVE, if designated as
> âdistributed gatewayâ, are more like Inter-VN relay (instead of full
> blown Gateway function).
Mostly agree. However, the purpose of the architecture is not to say
what implementations MUST do, it's about what the architecture must
allow, in order for implementations (and solutions) have the option of
implementing something. So at this point, we shouldn't get too caught
up in exact details of what would and would not make sense to
distribute.
> Second, when host âaâ in VN-1 sends traffic to âbâ in VN-2, the data
> packetâs Ethernet header has âMAC-DA = Gateway-MAC & MAC-SA= a-MAC &
> VLAN= VN-1â. Most implementations (Microsoft Window 8 and VM NSX)
> allocate a âfake MACâ for all the NVE based distributed gateways to
> share, so that host âaâ can use the same Gateway-MAC when moved to
> another NVE. This again is different from the conventional
> gateways.
Sure.
> Third, the issue of conventional gateway (i.e. a->b traffic to be
> routed at gateway even if âaâ & âbâ are attached to the same NVE)
> is traffic âhairpinningâ, instead of triangular routing.
Sure. It's a special case of triangular routing.
> Therefore, I suggest rewriting Section 5.4 as below:
I took some of your text, but think it would be better to pull out the
policy stuff into its own section.
Here is proposed text:
<section title="Distributed Inter-VN Gateways">
<t>
The relaying of traffic from one VN to another deserves
special consideration. Whether traffic is permitted to flow
from one VN to another is a matter of policy, and would not
(by default) be allowed unless explicitely enabled. In
addition, NVAs are the logical place to maintain policy
information about allowed inter-VN communication. Policy
enforcement for inter-VN communication can be handled in (at
least) two different ways. Explicit gateways could be the
central point for such enforcement, with all inter-VN
traffic forwarded to such gateways for
processing. Alternatively, the NVA can provide such
information directly to NVEs, by either providing a mapping
for a target TS on another VN, or indicating that such
communication is disallowed by policy.
</t>
above is new text.
<t>
When inter-VN gateways are centralized, traffic between TSes
on different VNs can take suboptimal paths, i.e., triangular
routing results in paths that always traverse the
gateway. In the worst case, traffic between two TSes
connected to the same NVE can be hairpinned through an
external gateway. As an optimization, individual NVEs can be
part of a distributed gateway that performs such relaying,
reducing or completely eliminating triangular routing. In a
distributed gateway, each ingress NVE can perform such
relaying activity directly, so long as it has access to the
policy information needed to determine whether cross-VN
communication is allowed. Having individual NVEs be part of
a distributed gateway allows them to tunnel traffic directly
to the destination NVE without the need to take suboptimal
paths.
</t>
Mostly same as in existing doc, just added "hairpinning" text.
<t>
The NVO3 architecture must support distributed gateways for
the case of inter-VN communication. Such support requires
that NVO3 control protocols include mechanisms for the
maintenance and distribution of policy information about
what type of cross-VN communication is allowed so that NVEs
acting as distributed gateways can tunnel traffic from one
VN to another as appropriate.
</t>
Cleaned up and just said "must"
<t>
Distributed gateways could also be used to to distribute
other traditional router services to individual NVEs. The
NVO3 architecture does not preclude such implementations,
but does not define or require them as they are outside the
scope of NVO3.
</t>
Above is to basically say distributed functionality that is non-NVO3
related is out of scope for NVO3 to have an opinion on. It means
implementations can do more or less what they want, NVO3 doesn't
really need to take a postion.
I'll respond to your other points in a subsequent message.
Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
