Hello Lyle,
I have comments on the slides, and could benefit from larger discussion
on the mailing list.
On slide 3, the presentation indicates three Indexed Sets -- DPNs,
Domains, and Interface Groups. Reference to entities of those three
entity types is made available by Keys into the relevant Indexed Set.
An Interface, on the other hand, is not shown as referenced by a Key
into an Indexed Set. All of the relevant Interface information is
directly exhibited as attributes and sub-attributes of a DPN. I think
this is a consistent and somewhat understandable way of organizing the
entities and attributes in our Information Model.
On slide 4, there is the following:
Missing – protocol & settings required for selection
Should Reside in Group?
I think it is more natural for the protocols and settings for an
Interface to be shown as attributes for that Interface. The Interface
Group enables access to the list of Interfaces on the DPN. So,
selection of a DPN might proceed as follows:
- For each DPN, look at its Interface Groups
= For each Interface Group, look at the protocols and settings that
are supported.
If this isn't efficient, then we should reorganize the model. Continuing
to slide 5, there are three questions, which are relevant to this.
* How are Interfaces specifically mapped to a Group (DPN with 2
interfaces but only 1 is part of Group)?
Right now the Interface is a part of the DPN definition, and the
Interface Group was thought to be a way of collecting the information
about what kinds of interfaces are available. That is O.K. as far as
having the ability to partition the Interfaces of a DPN into
non-overlapping Groups, but there is no reverse structure for getting
the Interface details from the Interface Group. If the latter is
needed, then we should modify the definition of the Interface Group
appropriately. We might put an Interface-Key as an attribute of the
Interface-Group, but the Interface Group is in an Indexed Set and the
Interface-Key as currently (as an L-Key) defined only makes sense within
the context of a DPN.
Perhaps we first need to know the structure of the DPN-selection
Algorithm to know how best to organize Interfaces in the Information Model.
*
* What about Interfaces NOT in a group? What do we do with those
settings?
In the current DPN definition, this is not a problem... right?
*
* Relation be Roles & Interfaces is unclear
For a DPN to serve a particular role, it needs to have certain types of
Interfaces. A substantial part of the "type" of an interface is
determined by the set of Protocols that the Interface supports. Besides
that, the Interfaces will have certain Settings that further define
their usefulness.
Slide 6 encodes a great deal of information, some of which depends on an
understanding of DDDS. Maybe it is appropriate to include within the
FPC document an appendix recounting the salient details of DDDS, with
some emphasis on the DDDS view of Interface Groups and DPN selection.
If you are willing, I might suggest a reorganization of the graph as
follows:
- Move "Protocols" up vertically quite a bit
- Move "Features" to fit between "Protocols" and "Interfaces"
Then both instances of the "Features" block could be coalesced, and
maintain their pointers to "Selection Relevant" and "Other"
Somehow, the idea of a Selection Relevant "Setting" feature is easier to
grasp than a Selection Relevant "Protocol" feature. But I understand
that many protocols have so many features that one has to be careful to
ensure interoperability even between two conformant implementations of
the same Protocol. Can't boil the ocean here and so we just have to
accept that.
Regarding slide 7:
- (1) is agreeable to me. Let's try it.
- For (2), we could certainly allow a DPN to have more than one role.
However, for sanity, I hope we can make it so that the roles are
independent. Suppose a DPN could be either a MAG or an LMA. Now let's
say that it is chosen to be a MAG. Is it further disqualified from
being an LMA at the same time?
- (3) - I would be in favor of collapsing Features and Settings.
Regards,
Charlie P.
On 1/30/2018 6:58 AM, Bertz, Lyle T [CTO] wrote:
All,
I’ve put together a quick assessment on Topology (proposed for new
draft and v09).
We’ll briefly review it today as time permits.
Lyle
------------------------------------------------------------------------
This e-mail may contain Sprint proprietary information intended for
the sole use of the recipient(s). Any use by others is prohibited. If
you are not the intended recipient, please contact the sender and
delete all copies of the message.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
