Comments inline From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: Tuesday, January 30, 2018 12:20 PM To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org Subject: Re: [DMM] FPC - Topology
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. >> It requires a scan of all DPNs each time. In v09 we put the groups as a >> separate structure (peer of the DPN) so that all DPNs that could meet the >> Roles of a Group were sufficient. However, this did not help all cases. I >> have seen 3 cases: 1. A specific group was named in the selection (this is what DDS does as you need a domain to start the search). 2. A role was needed (this is the academic option as in I see it in specs but not in practice). It does exist as an internal selection mechanism, e.g. load balancing. However, this a special case where we can designate it as a collection of homogenous groups. In our model the driver may be that we are looking for any Role in the tenant. The takeaway is DPN selection starts with a named group in *current* standards and could be role based in customarily invisible methods. * 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. >> An interface can appear in multiple groups. For example, if an operator >> used for peering with partners A & B we would see the same interface in a >> groups set aside for each partner. A reverse structure is needed though as >> this is used for load balancing or just trying to figure out if the group is >> suitable for the request. Perhaps we first need to know the structure of the DPN-selection Algorithm to know how best to organize Interfaces in the Information Model. >> We cannot specify a specific DPN selection model; rather an algorithm that >> selects candidates that can meet the request needs. There will always be >> other considerations such as network state, performance info from say an >> ALTO etc. that will drive the specific DPN selection. * * 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? >> It is not a problem for a DPN but it would only be used for internal >> selection. * * 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" >> Done. Update included. 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. >> I know. Let's iterate here. If we are eventually okay with treating >> feature as a special kind of setting/property then it may work. However, we >> need a bit more analysis. 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? >> Roles have to stay independent because they are actually endpoints of the >> Reference Point (RP). RP is actually a link but it is an old term that is >> quite prevalent. If network element acts as a LMA/MAG for some >> connections and a LMA on a home network for roaming devices you MUST keep >> them separate. If a the Role is combined, e.g. LMA/MAG only the MAG is >> defined and there is no need to find a Reference Point for a MAG. - (3) - I would be in favor of collapsing Features and Settings. >> Me too but it will take a couple of iterations. 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 dmm@ietf.org<mailto:dmm@ietf.org> https://www.ietf.org/mailman/listinfo/dmm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7CLyle.T.Bertz%40sprint.com%7C2adf6d435cd64becfce308d5680e1104%7C2b25568eb4c84e84b192aa42a3a6d243%7C0%7C1%7C636529331979484003&sdata=y3kZTNcBxkvwYao3wUQ5r59oqELI9mSNSnzQDcdR50Y%3D&reserved=0>
FPC Working Session - Topology Session 2.pptx
Description: FPC Working Session - Topology Session 2.pptx
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
