Subject: [DMM] FPC - Topology

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Tue, 30 Jan 2018 14:58:38 +0000

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.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 30 Jan 2018 10:19:51 -0800

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-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Wed, 31 Jan 2018 00:42:15 +0000

Comments inline

From: Charlie Perkins [mailto:[email-masked]]
Sent: Tuesday, January 30, 2018 12:20 PM
To: Bertz, Lyle T [CTO] <[email-masked]>; [email-masked]
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.

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?

>> It is not a problem for a DPN but it would only be used for internal selection.

  *

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:

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:

- 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.

>> Me too but it will take a couple of iterations.

Regards,
Charlie P.

Lyle

dmm mailing list

[email-masked]<mailto:[email-masked]>

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>