Hello Lyle,
I am sorry to say that I don't understand your explanation.
To start with, I didn't mean to have a direct mapping between Interface
Groups and 3GPP features. Instead, I would like to suggest that
Interface Groups are defined/configured/populated to make it easier to
support features as needed. If multiple Interface Groups are required
(say, because the feature is complicated, or multi-modal, or spans
multiple DPNs) that should be O.K. If necessary, we could create a new
kind of entity which collects together multiple Interface Groups which
are then configured together to support the complicated feature.
Hierarchically, you might say.
Questions below:
On 1/23/2018 5:25 AM, Bertz, Lyle T [CTO] wrote:
wrt
"What if we make that to be two different access-network features, and
enable selection of Interface Groups for each feature?"
> emergency calls when roaming are not treated the same when they are
domestic.
Doesn't this mean that they are handled using different DPNs, and thus
different Interface Groups?
this is especially true when it comes from an automobile.
I reckon that for vehicular mobility we will indeed see substantial
differences in many aspects of mobility management.
In fact, they are often set aside as different APNs.
Somehow this seems to motivate even more strongly the design advantage
of having the Interfaces of an Interface Group reside on a single DPN.
I'd like to be able to support the current DDDS implementations as
well as TS 29.303.
Agreed -- if we can't do that, something is likely to be wrong, or else
outside the jurisdiction of IETF.
Furthermore, such scenarios are indexed given their criticality;
Here I am at a loss. An indexed set provides entity handles for
reference in other structures. Do you have some additional mechanism in
mind? How does criticality affect the creation of the index?
requiring an index to be built from a feature scan or security
scenarios is not placing the operator in a comfortable situation.
And so I do not understand this either. An indexed set offers
references to a set of ("indexed") entities that share the same
information model definition. Can you say more about when and how a
feature scan might work? How would the indexed set be populated from
that? How would a security scenario impact the indexing of the Indexed
Set? If we don't provide an Information Model that enables the desired
security scenarios, then we didn't finish our job yet. Security could
well influence the configuration of appropriate Interfaces into an
Interface Group, but I don't see how it is related to the creation of an
index into a set of such Groups.
Thanks in advance for your consideration of my questions!
Regards,
Charlie P.
------------------------------------------------------------------------
*From:* Charlie Perkins <charles.perk...@earthlink.net>
*Sent:* Monday, January 22, 2018 7:10 PM
*To:* Bertz, Lyle T [CTO]
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
Hello Lyle,
Thanks for the detailed reply. It clears up a lot of questions in my
mind. To briefly reply:
- The reason I was asking about whether or not an Interface Group
lived on a DPN was to help me figure out how to structure the
Interface Group definition. It's already structured as an Indexed
Set, and so we will have an Interface-Group-Key. The DPN structure
will have a list of such keys, for each Interface Group that exists
and includes an Interface from the DPN. I think this is O.K. for your
scenario of different security zones. Notably, we do not provide that
as an attribute of an Interface, but then again I don't think we could
reasonably be expected to delineate all possible attributes of Interfaces.
An Interface Group will also have a DPN-Key, for the DPN that hosts
its interfaces.
Your example about having to select a DPN to handle emergency calls as
well as "normal" call processing is very interesting. What if we make
that to be two different access-network features, and enable selection
of Interface Groups for each feature? Then we are still O.K. with
having each Interface Group to be configured with only one DPN-Key.
Regards,
Charlie P.
On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:
Your scenarios are correct. I think we are in agreement but I want
to clarify a few things:
Wrt your statement “(b) it makes good sense for all the Interfaces of
an Interface Group to be hosted on the same DPN.”
Ack. I agree when the required interfaces within an Interface Group
can be hosted on the same DPN to service a request. However, we
leave DPN selection up to the implementations as they may have
proprietary or other perfectly good reasons not to do this. By the
above statement I have interpreted it as a recommendation and not a
mandate, i.e. it is not a requirement in FPC to do this. Is that
correct?
Wrt the statement “I just want all of the Interfaces of an Interface
Group to be on the same DPN”
I wish that was always the case but when the interface types are
different or have a different purpose, e.g. normal calls vs.
emergency calls, this is not the case in practice.
In the model then are you proposing the Interface Groups only reside
under the DPN structure? If so, then one must load all DPNs and index
them by Interface Groups Id to determine they are from the same
group. The purpose in pulling them out was to create a single Set
that could be used to house the typing and common configuration
information. DPN interfaces assigned to support an Interface Group
are then assigned to it. Thus, if a DPN had 2 interfaces which are
of the same type but in different security zones (or have different
routes/networks served) they may not be able to serve in the same group.
Lyle
*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Monday, January 22, 2018 3:25 PM
*To:* Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
Hello Lyle,
I agree that:
1. - Interface Groups are designed to be used to select DPN.
2. - Interface Groups may contain a number of different Interface Types
3. - There may be more than one Interface Group providing equivalent
service, at least for the purpose of selecting a DPN.
For (1) -- I imagine that the selection process would look to make
sure that the Interface Group has the proper interfaces that are
needed (say, by the FPC Client). Then, the FPC Client would select
the DPN hosting the Interface Group, set up connectivity with the
interfaces in the Peer Interface Group(s), and all is good.
For (2) -- this is really the motivation for the concept of Interface
Groups.
For (3) -- really a follow-on from (1): the FPC Client would then
look at the other properties of the DPN hosting the Interface Group,
to determine which was the least cost, or highest benefit, choice.
Or alternatively the FPC Client would look at the Settings on the
Interfaces of the Group, to see which Interfaces had the best fit for
the purposes of the FPC Client.
If I have these scenarios right, then (a) we don't need to introduce
any further virtual DPN definitions for proper operation and (b) it
makes good sense for all the Interfaces of an Interface Group to be
hosted on the same DPN.
The intent of the structure is for use during DPN selection. To
maintain it as a DPN means some DPNs are used during selection
but others are not.
I agree with this completely, if I understand it. After the
selection occurs based on the suitability of the Interface Group, its
function is done. I did not in any way mean to suggest that the
Interface Group was ever going to be a DPN or a virtual DPN.
I just want all of the Interfaces of an Interface Group to be on the
same DPN.
Regards,
Charlie P.
On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:
k. I think that we are crossing conversations now.
“An Interface Group on a DPN would also have have attributes for
Peer Interface Groups residing on other DPNs. ” < Did not see that.
Interface Groups (aka DPN Groups) can be used for DPN pool
selection (multiple options) with a different interface strategy.
Interface Groups (aka DPN Groups) may also contain hetergeneous
DPN-Type (interface types). In this case the totality of
services could be provided by more than one DPN.
If we say that this is ‘just a virtual DPN with a selection
strategy of multiple underlying DPNs” I feel that we are jamming
too many concepts into the DPN. Overloading is okay until one is
overloaded ;)
The intent of the structure is for use during DPN selection. To
maintain it as a DPN means some DPNs are used during selection
but others are not.
I would propose that we keep this concept separate for now, look
at proposed changes and then revisit this issue.
*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Monday, January 22, 2018 12:07 PM
*To:* Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
<mailto:lyle.t.be...@sprint.com>
*Cc:* dmm@ietf.org <mailto:dmm@ietf.org>
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
Hello Lyle,
An Interface Group on a DPN would also have have attributes for
Peer Interface Groups residing on other DPNs. So, the data plane
configuration can already exhibit the ("cross-DPN")
interconnection between Interface Groups even if the interfaces
of the Group all reside on the same DPN.
Could you give an example of an Interface Group that perforce
requires to reside on multiple DPNs? Is it a case that could be
handled better by defining a virtual DPN to host the Interface
Group? I understand the word "containment" but I'm not at all
clear about what sort of Group requires the extra complication to
expedite the stated purpose, which is DPN selection. If there are
other purposes, I would be inclined to define other structures
for them that do not have the effect of complicating the
Interface Group definition.
Regards,
Charlie P.
On 1/22/2018 5:11 AM, Bertz, Lyle T [CTO] wrote:
<adding mailing list>
No, I don’t think they should reside under a DPN. Groups
like these also span multiple DPNs which would make
containment graphs far too confusing.
*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Sunday, January 21, 2018 10:51 PM
*To:* Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
<mailto:lyle.t.be...@sprint.com>
*Cc:* Marco Liebsch <marco.lieb...@neclab.eu>
<mailto:marco.lieb...@neclab.eu>; Satoru Matsushima
<satoru.matsush...@gmail.com>
<mailto:satoru.matsush...@gmail.com>; Sri Gundavelli
(sgundave) <sgund...@cisco.com> <mailto:sgund...@cisco.com>;
Moses, Danny <danny.mo...@intel.com>
<mailto:danny.mo...@intel.com>; Weaver, Farni [CTO]
<farni.wea...@sprint.com> <mailto:farni.wea...@sprint.com>;
Matsushima Satoru <satoru.matsush...@g.softbank.co.jp>
<mailto:satoru.matsush...@g.softbank.co.jp>
*Subject:* Question about Interface Groups
Hello folks,
Can we have it so that all the Interfaces of an "Interface
Group" (formerly, "DPN Group") reside on the same DPN?
If so, I can make good sense out of the text in the document,
but otherwise I think there are big problems.
I have some other questions, but this is the main thing right
now. If the answer to my question is "Yes" I think I will
have a sensible revision tomorrow.
I have some more questions, not quite as important, which I
will put in separate emails.
Regards,
Charlie P.
On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:
Charlie,
Glad to hear things are going well. I’m looking forward
to your document update.
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
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
