Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, May 05, 2015 2:59 PM > To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > On 5/5/2015 2:23 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> The better solution would be RFC 4821-style probing by the tunnel > >> ingress to the tunnel egress. > > > > As you know, I agree with this (per Section 3.13 of AERO) but it is not > > exactly like RFC4821. With RFC4821, since the source of the probes is > > also the original source of the data packets (and, since the probes are > > actually data packets themselves) the probes are guaranteed to travel > > the same network path as the data packets. > > That depends on how you implement the tunnels. You can easily use the > data packets as probes if you design a way for the egress to indicate > which probes get through. > > T> When the tunnel probes, however, it may be probing on behalf of many > > original sources and it becomes more difficult to ensure that the probes > > travel the same network path as the data packets. > > That's true only if the network looks into the tunnel packets and treats > them differently - which could have happened for any application packets > too.
No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to be maintained on a per-flow basis. When the source is the originator of the flows, it is easy to keep track of which MTUs are associated with which flows. When the source is a tunnel ingress, however, it may be required to send the data packets of many flows across the tunnel to the egress and, if the network can distinguish the different flows, the data packets and probe packets may take different paths. What this means is that, for tunnels over IPv6, the ingress would need to implement a discipline for setting the flow label in the encapsulation header so that the probes and data packets appear to be part of the same flow. One way is to simply set a constant value (e.g., 0), but then ECMP in the path between the ingress and egress would be disabled. A compromise would be to have the ingress set a finite number of flow label values (e.g., 4) selected, e.g., based on a hash of the payload packet headers. But then, each such flow label value would need to be probed separately. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
