> -----邮件原件-----
> 发件人: nvo3 [mailto:[email protected]] 代表 Dino Farinacci
> 发送时间: 2013年11月27日 5:45
> 收件人: Thomas Narten
> 抄送: [email protected]
> 主题: Re: [nvo3] TTL handling in an L3 service
>
> > Hi Dino.
> >
> > I'm not really asking about TTL processing for tunnels in general...
> > I'm asking specifically in the context of virtual network service,
> > where tenants are connecting to virtual networks expecting either L2
> > or L3 service. What expectations to the TSes have when it comes to
> > TTL modification?
>
> I think it is exactly the same case.
>
> > In the L2 case, tenatnts expect to be given service equivalent to an
> > L2 broadcast domain. I.e., nodes can talk directly to each other at
> > the L2 level using unicast/multicast. This is what we usually think of
> > as being attached to a shared "link".
>
> Right - but for a L2 service there is no TTL to decrement in the NVE since it
> forwards a packet based on a MAC header.
>
> > But what if the service being provided is L3? In this case TSes are
> > only sending IP packets, but all TSes are directly reachable (i.e.,
> > without leaving the VN). What expectation do TSes in this type of
> > situation expect of the TTL processing?
>
> "Directly" needs to be defined above. If the two TSes are in the same subnet
> then it would behave as it does today (when 2 hosts are connected to hub - I
> don't say switch because I don't want to complicate the discussion).
>
> > Do they even care?
> If I am 10.0.0.1 in CA on subnet 10.0.0.0/8 and you are 10.0.0.2 in NY on
> subnet
> 10.0.0.0/8 and we are reachable via the overlay, I expect one line if output
> from
> traceroute. If you are 11.0.0.1 I expect at least 2 lines of output.
Thomas has asked a very worthwhile question: Do they even care?
According to the TTL handling requirement for L3 VNI as specified in the NVo3
DP Requirement doc (see below), if you do a trace route for 11.0.0.1, the trace
route output would be exactly the same as your expectation since L3 NVEs are
usually acting as default GWs. That's to say, you can't see any difference when
you do a trace route for an IP address outside your subnet. If you do a trace
route for 10.0.0.2, the trace route output may list one or two more hops (i.e.,
the ingress and/or the egress NVE) than your above expectation. However, do you
really care about the trace route output for an IP address which is within the
same subnet as yours? What's your special purpose for doing a trace route,
rather than a PING for an IP address which belongs to the same subnet as yours?
To some extent, the L3 forwarding for intra-subnet traffic is just a special
use case of the Proxy ARP mechanism [RFC1027]. That's to say, the traffic from
10.0.0.1 to 10.0.0.2 is intra-subnet traffic from the host's POV while it is
also inter-subnet traffic from the router's POV. Therefore, the above
"unexpected" trace route output demonstrates exactly the router hops that the
intra-subnet traffic (from the tenant host POV) would traverse on the overlay
path.
*******************************
3.2.2. L3 VNI
L3 VNIs MUST provide virtualized IP routing and forwarding. L3 VNIs
MUST support per-tenant forwarding instance with IP addressing
isolation and L3 tunneling for interconnecting instances of the same
VNI on NVEs.
In the case of L3 VNI, the inner TTL field MUST be decremented by
(at least) 1 as if the NVO3 egress NVE was one (or more) hop(s)
away. The TTL field in the outer IP header MUST be set to a value
Lasserre, et al. Expires May 12, 2014 [Page 6]
Internet-Draft NVO3 Data Plane Requirements November 2013
appropriate for delivery of the encapsulated frame to the tunnel
exit point. Thus, the default behavior MUST be the TTL pipe model
where the overlay network looks like one hop to the sending NVE.
Configuration of a "uniform" TTL model where the outer tunnel TTL is
set equal to the inner TTL on ingress NVE and the inner TTL is set
to the outer TTL value on egress MAY be supported.
********************************
Best regards,
Xiaohu
> Dino
>
> >
> > 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
