Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Thursday, April 23, 2015 9:35 AM > To: Templin, Fred L; [email protected] > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > Fred, > > The following are failure modes for a GRE tunnel that includes ECMP/LAG: > > - one ECMP/LAG member is dropping 100% of traffic, regardless of packet size > - one ECMP/LAG member is dropping all packets with MTU > N > > Why is a probing mechanism OK to detect the first and not the second?
These are two very different conditions. In the first case, if one or more paths are dropping all packets, then any communications will black hole and not just GRE tunneling. The network operations staff needs to do something to ensure that all paths are working. In the second case, it could black hole even when all paths are working and using standards-compliant MTUs on all links. AFAICT, when there may be ECMP or LAG on the path (which the ingress has no way of knowing) about all you can tell from probing is whether the egress is alive - probing can't be relied on to tell you anything about the path(s). Again , this does not make me happy but AFAICT it is the reality we need to deal with. Thanks - Fred [email protected] > Ron > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Thursday, April 23, 2015 11:59 AM > > To: Ronald Bonica; [email protected] > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:[email protected]] > > > Sent: Thursday, April 23, 2015 8:18 AM > > > To: Templin, Fred L; [email protected] > > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > > Fred, > > > > > > If we can't probe a tunnel, we can't do GRE at all. Ever. Not with IPv4, > > > not > > with IPv6, not with anything. > > > > > > MTU issues aside, before activating a tunnel, we must be certain that the > > tunnel can carry a 1-byte packet from GRE ingress to egress. > > > If we don't do that, we risk black-holing traffic. This is why nearly > > > all GRE implementations have some type of proprietary probing > > mechanism. > > > > I said earlier that I am fine with going ahead and probe with a small > > packet (I > > said 100 bytes, but 1 byte would be fine too) to see if the GRE ingress is > > alive. > > But, that probe does nothing to test for a particular MTU. > > > > > Beyond suggesting that the probing mechanism use a 1280-byte payload, > > > we have put the details of that probing mechanism out of scope for this > > document. > > > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > > encapsulation) succeeds along one path of a multipath, but would have failed > > along another path, then there is possibility for black holing. And, there > > is no > > way for the ingress to know that there may be ECMP or LAG on the path to > > the egress. Hence, having the ingress probe for the purpose of minimum > > MTU detection is problematic if there may be some kind of multipath. > > > > Thanks - Fred > > [email protected] > > > > > > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:[email protected]] > > > > Sent: Wednesday, April 22, 2015 6:32 PM > > > > To: Ronald Bonica; [email protected] > > > > Subject: RE: [Int-area] I-D Action: > > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > Hi Ron, > > > > > > > > So, this gives way to the following, which may be the best we can do > > > > if we can't probe: > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
