Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, April 23, 2015 11:18 AM > To: Templin, Fred L; Ronald Bonica; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > On 4/23/2015 11:04 AM, Templin, Fred L wrote: > > Hi Joe, > ... > >> There's nothing that requires that any network path "test all paths" in > >> a multipath system. > > > > You are missing the point. With ECMP or LAG, a middlebox in the path > > from the ingress to the egress selects a path for the tunneled packet > > by examining information in the headers such as the flow label. > ... > > >> If the loss starts depending on the contents of the packets, > > I.e., "the point". > > >> then we'd > >> need a new mechanism to provide feedback on existing packets as if they > >> were all probes. > > I.e., out of scope. > > > The data packets themselves as probes is the only way to test the paths > > that the data packets take. The probe reply is a Packet Too Big message. > > But, if you get a PTB for a data packet that is smaller than 1280 you are > > back to fragmentation. > > Or you don't support the necessary fragmentation and the link is > declared down.
So, if the tunnel is working but you all of a sudden get a PTB that reports a size that would be too small to accommodate a 1280 byte payload packet, shut the tunnel down? You had better be able to trust that the source of the PTB is trustworthy and not sending bogus PTBs. This sounds like a condition that can only hold when the tunnel ingress, egress and all routers in the path between are under the same administrative control. > Or you don't get the PTB (ICMP blocking), you're back to a black hole. Right, which as we know can happen when the ingress, egress and all routers in between are not under the same administrative control. This strongly suggests that operational considerations are extremely important to the way the ingress must conduct its business. We have 1) the path from the original source to the tunnel ingress, and 2) the path from the tunnel ingress to the tunnel egress. If path 1) is susceptible to either lost or bogus PTBs, then the tunnel ingress must ensure that packets as large as 1500 bytes get through even if some fragmentation is needed. If 1) is OK, but 2) allows for lost or bogus PTBs, then the tunnel ingress must ensure that packets as large as 1280 get through. > Again, we'd need new mechanism and that's out of scope. The mechanism is fragmentation; that is not new. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
