To:
Gilles Joncour, Rapporteur ITU-T Q.5/13 (gilles.joncour@orange-ftgroup.com)
Ghani Abbas, Rapporteur ITU-T Q.9/15 (Ghani.Abbas@marconi.com)

From:
Tony Jeffree, 802.1 Chair.

Date: November xx, 2006
Subject: Linktrace in P802.1ag Draft 7.1 and Y.1731

We have discussed at our IEEE 802 plenary meeting in Dallas, Texas, this week, the apparent and real remaining differences between the operation of Linktrace in IEEE P802.1ag and ITU-T Y.1731.  We believe that all issues can be resolved without undue difficulty.  The issues are the required TLVs in P802.1ag LTM and LTR PDUs, the TLV Type values for several TLVs, and the TTL values in LTRs and in forwarded LTMs.

In P802.1ag Draft 7.1, there is one required TLV in the LTM (LTM Egress Identifier TLV) and two required TLVs in the LTR (LTR Egress Identifier TLV, Reply Ingress TLV) that are not specified in Y.1731.  The reason that these TLVs were added to P802.1ag is that the Linktrace mechanism can, in certain cases, generate a tree of responses, rather than a linear path.  In the normal case, the MEP generating an LTM can order the LTRs returned in response by their Reply TTL fields in order to recreate the path of the LTM through the MIPs in the network.  But if, for example, multiple Bridges are connected to the same shared medium, and if the MEP CCM Database is used to resolve the paths, then a single LTM could return two different sequences of LTRs.  Then, the Reply TTL fields in the returned LTRs provide insufficient information for the MEP to recreate the multiple paths.

In practice, if a network had some devices built to P802.1ag/D7.1 and some built to Y.1731, there would be no serious interoperability problem.  The P802.1ag devices are required to generate the extra TLVs, which would be ignored by the Y.1731 devices.  The P802.1ag devices will still accept LTMs and LTRs that do not have these TLVs, and ignore TLVs not defined in P802.1ag.  Of course, if the ambiguous path case described, above, occurred, then the presence of Y.1731 devices could make it impossible to create the path tree.  Also, see below for the means by which G.8021 and Y.1731 rev 2 can fix the problem.

The differing TLV Type values in P802.1ag and Y.1731 will be changed, in P802.1ag Draft 7.2, to match the corresponding TLV Type values in Y.1731.  This change between Draft 7 and Draft 7.1 was inadvertant.

If a Bridge has MIPs on two different ports, and if an LTM traces a path that passes through both of those ports, then a Y.1731 device will decrement the TTL twice, and may generate one or two LTRs.  A P802.1ag device will decrement the TTL only once, and generate a single LTR.  Furthermore, a Y.1731 device returns the decremented TTL in the LTR (the TTL value in the forwarded LTM), while a P802.1ag device returns in the LTR the same TTL that was received in the incoming LTM.  A P802.1ag device will be required to return a single LTR, with the TTL decremented only once.  However, if a Y.1731 device decrements the TTL twice, there will be no interoperability problem, as long as an LTR is generated each time that the TTL is decremented, so that there are no gaps in the sequence of TTL values returned to the originating MEP.  Finally, an LTM with a TTL value of 0 is answered, but not forwarded.

In discussions with a number of regular ITU-T attendees, we have come to the conclusion that the differences regarding the required TLVs and the use of the TTL fields can best be resolved if Q.9/15 writes G.8021 using the P802.1ag semantics for these items.  Q.5/13 can revise Y.1731 to be compatible with G.8021.  In the meantime, it is easy to create an implementation of P802.1ag that can accept LTMs and LTRs from Y.1731 implementations, and Y.1731 implementations will have no trouble handling P802.1ag LTMs and LTRs.

I remain, sir,
Your obd't servant,
etc.