[EFM] forwarded from Jonathan Thatcher
The filters strike again!
Howard
-------- Original Message --------
From: "Jonathan Thatcher"
Frank,
I cannot understand your position here.
Perhaps it is I that is not being clear. Let me try again.
1. Are there any, existing EFM P2MP parts that comply with the standard? =
No. There cannot be. There is no standard.
2. Can there be a question about interoperability with EFM P2MP parts? =
No. Again, there are no standard-based parts to interoperate with.
3. Is there a requirement that EFM P2MP interoperate with EFM P2P or any =
other 802.3 port? No. That is not in the objectives.
4. Therefore, what exactly does FEC have to show in order to demonstrate =
that it does not break the 802.3 architecture? It has to show that the =
new protocol can interoperate with standard compliant 802.3z hardware.
5. Has it done so? Yes. It has shown that it can interoperate with =
standard compliant versions of 802.3z.
6. Has it worked with all implementations of 802.3z? No, it does not =
work with parts that are not standard compliant.
7. Could it be modified to work with both compliant, and non-compliant =
implementations? TBD. Being looked at.
8. If it can't be modified to work with both compliant and non-compliant =
implementations, does this affect its applicability for EFM P2MP? No. =
Since there are no implementations of EFM P2MP that are compliant to the =
EFM standard (since said standard doesn't exist), there can be no =
implementations that are non-compliant. Someone wishing to build an EFM =
implementation will simply have to avoid doing those things that make it =
non-compliant. This is advisable and good.
Now, what is the change in position? What is the change in C36 that is =
required? And, even if a C36 change was required (the clause is open for =
changes required by OAM anyway), why would that be outside the scope and =
authority of EFM to do so for P2MP?
I believe that Pat's comments were related to the use of FEC with =
existing P2P solutions. I know of no one that is pushing for FEC for =
P2P. So, this point (while valid at the time) is moot.
Therefore, what is the problem you are describing? Where is the bait and =
switch?
jonathan
| -----Original Message-----
| From: FEffenberger@xxxxxxxxxxxxxxxxx
| [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| Sent: Wednesday, October 30, 2002 6:07 PM
| To: Jonathan Thatcher; FEffenberger@xxxxxxxxxxxxxxxxx;
| Larry.Rennie@xxxxxxx; elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx;
| piers_dawe@xxxxxxxxxxx; ariel.maislos@xxxxxxxxxxxxxxxx;
| lior.khermosh@xxxxxxxxxxx; Vipul_Bhatt@xxxxxxxx;=20
| pat_thaler@xxxxxxxxxxx;
| ajay@xxxxxxxxxxxx; limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx;
| Ali@xxxxxxxxxxxxxx
| Cc: Jim.Wieser@nsc.com; stds-802-3-efm@ieee.org
| Subject: RE: Minutes of 10/30 FEC Conference Call
|=20
|=20
| Jonathan,
|=20
| What you say is a major shift from the Frame-FEC position. =20
| That was not what was adddvertised by the proponents of frame-FEC.
|=20
| Besides, who says that clause 36 stuff is going to be=20
| different for P2MP?=20
| Layering, sir. Layering. Clause 36 was going to stay the=20
| same, according=20
| to frame-FEC folks. This also was not adddvertised. This is a bait and
| switch.
|=20
| The issue that UNH has turned up is exactly the thing that Pat Thaler=20
| had warned about - intentional errors may not be handled correctly by=20
| every implementation, simply because errors are not=20
| effectively tested,=20
| and their treatment is irregular. =20
|=20
| I'm done.
| Frank
|=20
|=20
|=20
|=20
|=20
| -----Original Message-----
| From: Jonathan Thatcher=20
| [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
| Sent: Wednesday, October 30, 2002 8:25 PM
| To: FEffenberger@xxxxxxxxxxxxxxxxx; Larry.Rennie@xxxxxxx;
| elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx; piers_dawe@xxxxxxxxxxx;
| ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
| Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
| limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
| Cc: Jim.Wieser@xxxxxxx
| Subject: RE: Minutes of 10/30 FEC Conference Call
|=20
|=20
| Frank,
|=20
| There are no old P2MP parts. It is not possible to have=20
| interoperability
| with existing parts. If it is not possible to have=20
| interoperability with
| existing P2MP parts, it is not possible to fail to operate=20
| with existing
| P2MP parts. There is no requirement for FEC based P2MP parts=20
| to interoperate
| with P2P parts.=20
|=20
| Therefore, 25% failure is not a failure at all. It clearly=20
| demonstrates that
| it is possible to create a MAC that can interoperate with both FEC and
| non-FEC hardware.
|=20
| Besides, according to plan, Eric intends to look for a bit=20
| sequence that
| will allow for all existing MACs to work. To me, this is overkill.
|=20
| jonathan
|=20
| | -----Original Message-----
| | From: FEffenberger@xxxxxxxxxxxxxxxxx
| | [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| | Sent: Wednesday, October 30, 2002 4:01 PM
| | To: Jonathan Thatcher; FEffenberger@xxxxxxxxxxxxxxxxx;
| | Larry.Rennie@xxxxxxx; elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx;
| | piers_dawe@xxxxxxxxxxx; ariel.maislos@xxxxxxxxxxxxxxxx;
| | lior.khermosh@xxxxxxxxxxx; Vipul_Bhatt@xxxxxxxx;=20
| | pat_thaler@xxxxxxxxxxx;
| | ajay@xxxxxxxxxxxx; limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx;
| | Ali@xxxxxxxxxxxxxx
| | Cc: Jim.Wieser@xxxxxxx
| | Subject: RE: Minutes of 10/30 FEC Conference Call
| |=20
| |=20
| | Interoperability means working with old parts.=20
| | 25% failure rate is a failure. =20
| | Until it hits 100%, you can't claim backward compatability,=20
| | in my opinion.
| | Frank.
| |=20
| | -----Original Message-----
| | From: Jonathan Thatcher=20
| | [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
| | Sent: Wednesday, October 30, 2002 6:05 PM
| | To: FEffenberger@xxxxxxxxxxxxxxxxx; Larry.Rennie@xxxxxxx;
| | elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx; piers_dawe@xxxxxxxxxxx;
| | ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
| | Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
| | limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
| | Cc: Jim.Wieser@xxxxxxx
| | Subject: RE: Minutes of 10/30 FEC Conference Call
| |=20
| |=20
| | The minutes were not clear. This does not mean 75% of frames.=20
| | It means 75%
| | of the 802.3z implementations passed frames without difficulty.
| |=20
| | Interpretation: it is not just possible, but likely that a=20
| | MAC designed for
| | P2MP can work with FEC or not without difficulty. The 25%=20
| | proves that it is
| | also possible to design a MAC for P2MP that will not work=20
| | with FEC. But, why
| | would one do that?
| |=20
| | jonathan
| |=20
| | | -----Original Message-----
| | | From: FEffenberger@xxxxxxxxxxxxxxxxx
| | | [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| | | Sent: Wednesday, October 30, 2002 2:12 PM
| | | To: Larry.Rennie@xxxxxxx; elynskey@xxxxxxxxxxxxxx; Meir@xxxxxxxx;
| | | Jonathan Thatcher; piers_dawe@xxxxxxxxxxx;
| | | ariel.maislos@xxxxxxxxxxxxxxxx; lior.khermosh@xxxxxxxxxxx;
| | | Vipul_Bhatt@xxxxxxxx; pat_thaler@xxxxxxxxxxx; ajay@xxxxxxxxxxxx;
| | | limb@xxxxxxxxxxxx; masoud@xxxxxxxxxxxxxx;
| | | FEffenberger@xxxxxxxxxxxxxxxxx; Ali@xxxxxxxxxxxxxx
| | | Cc: Jim.Wieser@xxxxxxx
| | | Subject: RE: Minutes of 10/30 FEC Conference Call
| | |=20
| | |=20
| | | Larry,=20
| | |=20
| | | Quick question: How does a 75% success rate justify the claim of
| | | interoperability?=20
| | |=20
| | | Frank.
| | |=20
| | |=20
| | | -----Original Message-----
| | | From: larry rennie [mailto:Larry.Rennie@xxxxxxx]
| | | Sent: Wednesday, October 30, 2002 5:07 PM
| | | To: Eric Lynskey; Meir Bartur; Jonathan Thatcher; Piers=20
| Dawe; Ariel
| | | Maislos; lior khermosh; Vipul Bhatt; pat thaler; Ajay=20
| Gummalla; john
| | | limb; Masoud Khansari; frank effenberger; Ali Abaye
| | | Cc: jim
| | | Subject: Minutes of 10/30 FEC Conference Call
| | |=20
| | |=20
| | | FEC Conference Call
| | | Wed Oct 30, 2002, 10-11:30AM PST
| | |=20
| | | Attendees
| | |=20
| | | Eric Lynsky, UNH
| | | Meir Bartur, Zonu
| | | Jonathan Thatcher, Worldwide Packets
| | | Piers Dawe, Agilent
| | | Ariel Maislos, Passave
| | | Dora Zanaceen, Lucent
| | | Larry Rennie (Chair) , National Semiconductor
| | |=20
| | | 1. CDR Testing. Eric's test show a CDR lock time of about=20
| | | 800 bits for
| | | the high BER (10E-4) condition versus about 100 bits for=20
| the no BER
| | | condition. Agreed that the cause of the noise (attenuation=20
| | | or MPN) did
| | | not matter for a first order look at lock time. It was=20
| | | pointed out that
| | | even at 1000 bits, this is still a very small overhead on a=20
| | | 250K bit or
| | | so size burst. Still would be desirable to do the testing=20
| | | with different
| | | manufacturers components. If there is a spec on lock time,=20
| | | how to do the
| | | testing would be an issue.
| | |=20
| | | 2. MPN testing. Results from Zonu next week.
| | |=20
| | | 3. Legacy Testing. UNH working with Passave has done some legacy
| | | testing to see if legacy nodes would receive an FEC=20
| | formatted packet.
| | | 75% success rate! Eric felt a change to the special FEC=20
| | framing header
| | | might fix the problem with the 25% that did fail. =20
| | | Nevertheless, the 75%
| | | success rate should be acceptable to satisfy=20
| interoperability claim.
| | | Failure was the result of getting stuck in a false carrier state.
| | |=20
| | | 4. Where to put FEC in the standard was discussed. It would=20
| | | be cleaner
| | | to have a new Clause but another possibility is an=20
| | addition to Clause
| | | 36, but only if that Clause needs to changed anyway. Another=20
| | | determining
| | | factor is: does TF wants FEC to apply to P2P? This needs further
| | | discussion and if it does then a new Clause for FEC is needed.
| | |=20
| | | 5. We need to put together a comprehensive FEC baseline for=20
| | | the TF vote
| | | in November. Latency time of FEC needs to be included.
| | |=20
| | | Action Items:
| | |=20
| | | 1. Eric to document CDR test methodology and test results for the
| | | November meeting.
| | | 2. Eric to document legacy test methodology and test results for
| | | November meeting.
| | | 3. Meir/Larry to document MPN test methodology and test=20
| results for
| | | November meeting
| | | 3. Ariel/Larry to do the FEC baseline presentation for=20
| | | November meeting.
| | | Note, this would be an updated version of previously=20
| | presented frame
| | | FEC presentations.
| | | 4. Larry to do an FEC status report for November meeting.
| | | 5. Larry to coordinate with Howard on where to add FEC.
| | |=20
| | | NOTE: Presentation submittal deadline is November 4, 2002.
| | |=20
| | | Larry
| | |=20
| | |=20
| |=20
|=20