| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hesham: Good point. Any change of MPCP should keep EPOC MAC chip remaining in the EPON MAC chip ecology zone. Eugene Dai PhD From: Hesham ElBakoury [mailto:Hesham.ElBakoury@xxxxxxxxxx] Dai, Can we also add that allowed changes to MPCP should not require hardware changes to existing OLTs in the field ? Hesham From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx] The phrase “minimum Augmentation” was a political compromise at the time; when dust is clear it should means: 1. Make no changes to MPCP if possible; 2. If changes to MPCP have to be made, it should preserve the backward interoperability with EPON ONU. Eugene From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx] Thanks Marek. While I have to say that your response does not make me feel any better about this potential problem (the lack of specificity, I mean), I certainly understand your points. Most of all, I understand why we have "minimal augmentation" in the objectives, and why we agreed to put it there in the first place. No argument about that. Nevertheless, if anyone would be willing to talk about this further, either in the reflector or one-on-one, I would appreciate the discussion. Thanks! Jorge From: Marek Hajduczenia <marek.hajduczenia@xxxxxx> Jorge, Defining something through positive or negative examples brings the same kind of problem – we are trying to look at the control channel without knowing the details of the physical medium and the channel that will eventually carry bits. Personally, I’m not convinced we need to change anything in MPCP and I would work under the assumption that nothing needs to be changed unless it is explicitly demonstrated that it is broken and can’t work in coax media. We are however months away from this stage and I would not spend time now worrying about that one. We will cross that bridge when the time comes. And yes, this objective is subject to interpretation, but 75%+ of the future Task Force members will have to agree with the justification for the given MPCP change to push it forward. This is the ultimate test for what the “minimum augmentation” is. Marek From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx] I agree with everyone's comments below. Trying to define what "minimal augmentation" is will be difficult to agree. And, since we are in this subject, I will take the opportunity to say that I've been worried precisely about the lack of specificity of this objective. I'm not advocating that we change it, but it seems to me that this requirement is purely a matter of personal interpretation (e.g.,someone might argue that "this XYZ change to MPCP IS a minimal change" while someone else might say "this XYZ change IS NOT a minimal change". And, quite frankly, what specifically worries me is that this lack of specificity might open up the opportunity for someone to leverage it as a reason for not accepting a proposal. (I know… who would do that! ;-/) I know that all of the above expresses my opinion but does not help the discussion one iota, but I wonder if I could hear opinions as to what would be considered to NOT be "minimal augmentation". Could someone volunteer examples of changes to MPCP that would NOT be "minimal augmentation"? Jorge From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> My 0.02 eurocents are quite similar – we will only be able to see what augmentation is needed when we see detailed proposals for the PHY, operation of individual layers and EPoC as a whole. Trying to nail it down right now is hardly a good use of everybody’s time. I’d have this discussion once (1) we know how PHY operates to meet the objectives and (2) when and if we are certain that existing MPCP does not work properly for this PHY. Marek From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx] Matt, I like your interpretation. This was my understanding as well. Only make the minimal necessary changes required to meet the objectives. Thanks Avi From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx] Hesham, My personal opinion is that we're unlikely to come up with any sort of definition in advance that we can all agree on, particularly when it is a theoretical exercise. Rather, I suspect that what will ultimately happen is that we'll need to look at specific individual cases and then decide as a group whether or not we feel a particular change meets that definition. Put another way, I don't know that we can or should try to decide a strict definition now, but rather that we should wait until we have specific proposals and evaluate them with this in mind. Additionally, I have always looked at that statement as "the minimal necessary" augmentation to achieve our objectives. Admittedly that's not precisely what it says, but that's how I've viewed that statement, and one way in which I believe you could interpret it. Because in the end I think that's exactly what we need to do: make those changes that are necessary to enable our objectives, while showing restraint so that we don't make changes that are absolutely necessary. My $0.02 worth – I will be interested in hearing others' thoughts. Thanks. Matt From:Hesham ElBakoury <Hesham.ElBakoury@xxxxxxxxxx> Through the discussions we had so far I do not see a common agreement on the definition of “minimal augmentation” to MPCP. For example which one of the following MPCP changes are considered “Minimal” augmentation to MPCP and why: 1. Defining a new MPCP message. 2. Adding a new field to an existing MPCP message. 3. Change the interpretation/definition of existing field(s) in MPCP message. 4. Using reserved/unused fields in existing messages. 5. …. Comments are welcome. Thanks Hesham <="" p=""> <="" p=""> <="" p=""> <="" p="">
|