Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_DMLT] Relationship diagram for MAC Merge Management



OK, that makes sense and I apologize for having missed that.

 

Marek

 

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Sent: August 14, 2014 6:02 PM
To: Marek Hajduczenia; Howard Frazier
Cc: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: RE: Relationship diagram for MAC Merge Management

 

Hi Marek,

 

Please look at the existing 30-3 drawing.  The one to many relationship of MAC to PHY comes from the existing relationships. My recollection is that, for management purposes, multi-speed phys are modeled as multiple PHYs attached to the same MAC only one of which can be enabled  at a time (for transmit and active operation – during auto-neg multiple receivers can be active for parallel detect). 

 

If you don’t think that is right, it would be a maintenance issue – not 802.3BR.

 

I agree with the rest of your comments except that I’m leaning toward the second version of the drawing where the second oMACEntity is contained in the other oMACEntity and we don’t need to show a 2 to one relationship. It also has the advantage of not needing any extra elements beyond the containment relationship to show that the two MACs are a pair.

 

Regards,

Pat

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Thursday, August 14, 2014 2:48 PM
To: Pat Thaler; Howard Frazier
Cc: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: RE: Relationship diagram for MAC Merge Management

 

Hi Pat,

 

I have one comment on the proposed drawing: it seems that a single oMACMergeEntity maps into two oPHYEntity instances – as far as I understand, we have two MAC with MAC merge layer, but not two PHYs. I think it should be a 1:1 relationship between oMACMergeEntity and oPHYEntity.

 

Some more answers inline

 

Regards

Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669

 

From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx]
Sent: August 13, 2014 9:18 PM
To: marek.hajduczenia@xxxxxxxxx; Howard Frazier
Cc: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx
Subject: Relationship diagram for MAC Merge Management

 

Here is my initial try on a relationship diagram for MAC Merge. I haven’t done one of these before.

 

For now this is a diagram that applies only when MAC Merge is present. If adding MAC Merge to Figure 30-3 is done similar to this diagram, then I think this could be merged into Figure 30-3 in a way similar to what was done with MAC Control. I.e. Add a one to many relationship between oMACEntity back and oPHYEntity in and in the description of oPHYEntity state that it is contained in oMACMerge when oMACMerge is present and otherwise it is contained in oMACEntity.

 

I also considered having oPHYEntity always contained by oMACEntity as it currently is, but then which MACEntity of a MACMerge sublayer own it. We don’t have any many to many or two to many relationships defined. Also, this is more similar to the way MAC Control was added.

 

I have a number of questions about this drawing:

There are a number of questions about this diagram:

Should the deprecated objects be removed since it is a new diagram?

 

[mh0814] I suggest to submit a comment against 802.3REV and remove deprecated elements – that is not within the charter of IET to fix that.

 

Should a new symbol be added to indicate a two to one relationship instead of using the many to one relationship?

 

[mh0814] It would not hurt to extend the current drawing model, where we add a number next to the arrow to indicate the number of instances: (2), (1), or (n)

 

Should this relationship be shown in some other way?]

 

[mh0814] I believe it is correct as it is shown right now.

 

Should oResourceTypeID stay where it is or should it be contained by oMACMergeEntity? If it stays where it is, there may be one for the eMAC and one for the pMAC.  Note that oResourceTypeID is specified in 802.1F, a withdrawn standard. Because of that, I lean toward leaving it where it is.

 

[mh0814] again – not a problem we need to fix under IET …