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 fea
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.
> this is especially true when it comes from an automobile.In fact, they
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 a
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
hoste
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) --
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 interf
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
