Adee,
Unfortunately, I find there is no bounds to the confusion regarding ILT.
Jeff
------------------------------------
Pronouns: he/him/his
Distinguished Engineer II
Juniper Networks
Juniper Business Use Only
From: Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 14, 2025 11:17 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Proposed Liaison Response
As individuals many of us are aware of the projects that OIF is working on that may be affected by ILT…
But just the same, individuals in OIF (often the same ones) are aware of the fact that 802.3dj added ILT and what it means… and there is already activity in OIF
related to that (224G PAM4 Protocol Agnostic Link Training for Electrical Interfaces).
If we assume this individual knowledge, it would make the liaison unnecessary.
The way I see it, this liaison is just formalizing what people know already. For this purpose, just informing OIF of the new feature is sufficient. Going into
more details would like open a can of worms because different people have different knowledge/assumptions on what is important.
Jeff,
I was thinking about this further, and I wonder is your concern really that Ethernet will be implementing ILT and OIF needs to consider the interaction of their specifications with future Ethernet systems
(based on 200 Gb/s signaling) where it is implemented? That is how I interpreted what Matt Brown said yesterday, when he said just inform them that we are doing this.
I am not sure we communicated this point in the liaison.
John
Gary,
We didn’t go into any detail in the liaison draft. The point was to recognize the draft speaks to interfaces with and without ILT and that we recommended that ILT be defined for OIF interfaces.
Jeff
------------------------------------
Pronouns: he/him/his
Distinguished Engineer II
Juniper Networks
Juniper Business Use Only
[External Email. Be cautious of content]
Jeff,
I think the point made during the discussion yesterday is that it is not necessary to go into this level of detail in the liaison letter to the OIF. We just need to draw OIF’s attention to the fact that in
802.3dj we have introduced a significant new feature called ILT.
Gary
Juniper Business Use Only
Dear P802.3dj Task Force Members,
Please read our own draft. We speak towards whether an optical or electrical interface does or does not support training.
178B.5.1 Interface behavior
ILT on each interface includes some independent functions on each lane.
If training is available on the interface the behavior is as follows:
— Local variables are sent to the peer interface via the training frames. Remote variables are received
from the peer interface.
— When both local_rts and remote_rts are 1, after a specified delay (propagation_timer, see
Figure 178B–8), the device switches to its normal functionality (tx_mode = data, see 178B.14.3.1),
forwarding data between its interfaces in both directions. The condition is shared by all lanes within
an ISL, and therefore the switching of all lanes occurs in a period within the limits of
propagation_timer (see 178B.14.3.3).
— There is no specified timeout when waiting for either rx_ready or remote_rts to change to the value
1.
— While waiting for rx_ready and remote_rts, losing frame lock and not recovering it after a specified
recovery time (recovery_timer, see Figure 178B–8) or losing frame lock a configured number of
times (recovery_event_count, see Figure 178B–8), would cause training to fail and squelch. Training
may be restarted by management after an unspecified time.
— Management may access devices and restart training on a specific ISL if desired.
— The SIGNAL_OK status variable of the interface is OK if local_rts and remote_rts are both 1.
If training is not available on an interface (disabled or not defined for the interface type) the behavior is as
follows:
— local_rx_ready is generated on each lane based on internal criteria, similar to the signal indication
logic (SIL) in existing AUI components or PMDs.
— remote_rx_ready is set to 1 (there is no way to get it from the peer interface).
— local_rts is independent of local_rx_ready and is generated only from the variables of the other
interface of the device. It is communicated to the peer interface by squelching (local_rts = 0) or
unsquelching (local_rts = 1) the output.
— remote_rts is set to 1 (there is no way to get it from the peer interface).
— The variables local_tf_lock and remote_tf_lock are undefined and not used.
— The SIGNAL_OK status variable of the interface is OK if local_rts and remote_rts are both 1.
Jeffery Maki
Distinguished Engineer II
Juniper Networks
Juniper Business Use Only
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1