RE: [EFM-P2MP] new opcode for DISCOVERY GATE - an open TR from last meeting
Ariel,
I believe your logic does not hold because we are talking about a GATE
process and a DISCOVERY process. They have different roles, and
different information to convey. This is clear from our most basic
functional block in 64-4, where we divide GATE, REPORT and DISCOVERY
functional blocks. A DISCOVERY GATE is mixing oil and water, and, for
example, forces us to list OLT parameters in the GATE message - which is
used to assign grants.
A clean protocol would have GATE and REPORT messages used for normal
operation, and nothing to do with discovery, registration,
de-registration, OLT parameter setting, LLID assignment, etc.
> We are beyond the deadline to introduce new features.
This is not a new feature. It simplifies our block and state diagrams.
Reviewing the Comments on D1.414, I see the state diagrams are still
being tweaked, so this in fact would be the time to do this. Like
Elvis says, it's now or never.
Gerry
> -----Original Message-----
> From: Ariel Maislos [mailto:ariel.maislos@passave.com]
> Sent: Thursday, May 01, 2003 7:43 PM
> To: 'Glen Kramer'; stds-802-3-efm-p2mp@ieee.org
> Cc: Gerry Pesavento; Howard Frazier (Howard Frazier); Wael William
Diab; Ben
> Brown; Yukihiro Fujimoto
> Subject: RE: [EFM-P2MP] new opcode for DISCOVERY GATE - an open TR
from last
> meeting
>
> Glen,
>
> The proposal you have made is attempting to fix a cosmetic problem in
Draft
> 1.3 that no longer exists in Draft 1.414.
> As a result the last couple of slides in your presentation are not
correct.
>
> What I do see in the proposal is a solution looking for a problem.
> For every flag we have defined in our protocol we can always define a
> separate message:
> 1) Why not make a separate message for Deregister?
> 2) Why not make a separate message for Force Report?
> 3) Why not make a separate message for Keep-Alive?
> 4) Why not make a separate message for Broadcast OLT Capabilities?
> This is an endless debate.
>
> Creating a new message for Discovery Gate adds no new functionality,
and
> fixes no bug in the draft.
> It is a change for the sake of change.
> At the stage the standard has reached I expect stability.
>
> We are beyond the deadline to introduce new features.
> Change for the sake of change is much worse.
> Especially when it is a large change as is introduced in this
proposal.
>
> Let's work together to complete the standard by converging on
stability, and
> not introducing changes at every opportunity.
>
>
> Ariel Maislos
> Editor, P2MP
>
> -----Original Message-----
> From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
Glen
> Kramer
> Sent: Thursday, May 01, 2003 4:45 PM
> To: stds-802-3-efm-p2mp@ieee.org
>
> All,
>
> Currently, we have GATE opcode used for normal GATE messages
> as well as for DISCOVERY GATE messages. To distinguish the
> two, we have to use an additional Flag = {Normal|Discovery}.
>
>
> We have one open TR left from the last meeting that suggests
> making DISCOVERY_GATE a separate message from the normal
> GATE by adding a new opcode. Attached presentation explains
> the reasons and benefits of doing this.
>
> Please, let me know if you agree that this is a small but
> useful modification, and whether you support the idea.
>
> Thanks,
> Glen
>
>