On 5/5/2015 3:15 PM, Templin, Fred L wrote: > 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,
Then the tunnel is the source of the flows. Full stop. Any association between the tunnel flows and the flows arriving at the tunnel ingress is the responsibility of the tunnel to maintain. > 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, Then what you're saying is that the tunnel ingress - as an app - has flows that are distinguishable by the net. That can happen with any application. > the data packets > and probe packets may take different paths. That can happen with any application. > 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. The probe packets can be the data packets. The egress can simply send information back about what data packets succeed. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
