Subject: Re: [DMM] regarding the re-chartering..

From: Alper Yegin <[email-masked]>
Date: Mon, 1 Sep 2014 10:13:27 +0300

> Okay, we are not going to define how the existing 3FPP system works - that knowledge is assumed. What I thought goes into the document, for example, in the case of 3GPP system would be identifying the architecture changes or modifications needed. If the deployment model assumes all network functions are virtualized, the document states that and lays out the architecture based on that. Satoru's & Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of what could be documented. The similar applies for other system architectures such as SP Wi-Fi etc.
> 

Jouni,

The "architecture changes" would be based on the a "specific solution". So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about "deployment models and scenarios" before we agree on the solutions.

Alper

>>>>>     o Enhanced mobility anchoring: define protocol solutions for a
>>>>>       gateway and mobility anchor assignment and mid-session mobility
>>>>>       anchor switching that go beyond what has been specified, for
>>>>>       example, in RFC 6097, 6463, and 5142. Traffic steering
>>>>>       associated with the anchor switch is also in-scope if deemed
>>>>>       appropriate.
>>>>> 
>>>>>     o Forwarding path and signaling management: the function
>>>>>       that handles mobility management signaling interacts with the
>>>>>       DMM network elements for managing the forwarding state
>>>>>       associated with a mobile node's IP traffic. These two functions
>>>>>       may or may not be collocated. Furthermore, the forwarding state
>>>>>       may also be distributed into multiple network elements instead
>>>>>       of a single network element (e.g., anchor). Protocol extensions
>>>>>       or new protocols will be specified to allow the above mentioned
>>>>>       forwarding path and signalling management.
>>>>> 
>>>> 
>>>> I cannot separate "mobility anchoring" from "fwding path and
>>>> signaling management".
>>>> Wherever you want to set your anchor or move your anchor to, you'd
>>>> need signaling
>>> > and setting up data path. The two are inseparable.
>>>> Having said that, I'm OK to keep the current work item descriptions
>>>> and finalize
>>> > rechartering. Once we have detailed discussions about the breakdown
>>> of the work, we
>>> > can come back and refine the goals and milestones (as already stated
>>> below [*]).
>>> 
>>> The enhanced mobility anchoring above is/was rather MIP type solutions
>>> influenced with "anchors" like we understand today, while the
>>> "forwarding path and signaling management" was meant for more future
>>> oriented solutions where the forwarding path does not necessarily have
>>> anything mobility specific etc.
>>> 
>> 
>> (Just FYI: It's not possible to gather what you are saying from reading
>> the charter. Different people reading the charter may not have the same
>> understanding. But like I said, this is just FYI, I can live with this
>> text until we come back and refine it later).
> 
> Ok. I'll try to clarify the point the text tries to make.
> 
> - Jouni
> 
>> 
>> Thanks.
>> 
>> Alper
>> 
>> 
>> 
>> 
>>> Any other opinions on collapsing these two?
>>> 
>>> - Jouni
>>> 
>>>>>     o Exposing mobility state to mobile nodes and network nodes:
>>>>>       define solutions that allow, for example, mobile nodes to select
>>>>>       either a care-of address or a home address depending on an
>>>>>       application' mobility needs. In order to enable this
>>>>>       functionality, the network-side control functions and other
>>>>>       networking nodes must also be able to exchange appropriate
>>>>>       control information, as well as to the mobile nodes and their
>>>>>       applications.
>>>>> 
>>>>> The working group may decide to extend the current milestones based on
>>>>> the new information and knowledge gained during working on other
>>>>> documents listed in the initial milestones. [*]
>>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Alper
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Possible new documents and
>>>>> milestones must still fit into the overall DMM charter scope as outlined
>>>>> above.
>>>>> 
>>>>> Goals and Milestones:
>>>>> 
>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a working
>>>>>            group document(s). To be Informational RFC.
>>>>> 
>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
>>>>>            document. To be Proposed Standard.
>>>>> 
>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a
>>>>>            working group document. To be Proposed Standard.
>>>>> 
>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and network
>>>>>            nodes' as a working group document(s). To be Proposed
>>>>>            Standard.
>>>>> 
>>>>> 
>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted to
>>>>>            the IESG. To be Informational RFC.
>>>>> 
>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG.
>>>>>            To be Proposed Standard.
>>>>> 
>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' submitted
>>>>>            to the IESG. To be Proposed Standard.
>>>>> 
>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and network
>>>>>            nodes' submitted to the IESG. To be Proposed Standard.
>>>>> 
>>>>> 
>>>>> 
>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti:
>>>>>> The webex sessions have been cancelled in accordance of better IETF
>>>>>> process compliancy. New dates will be announced rougghly two weeks
>>>>>> ahead
>>>>>> of tomorrow.
>>>>>> 
>>>>>> You can (and should) still actively send edits to the list and I'll
>>>>>> update the text accordingly. Maybe we manage to get ready even
>>>>>> without a
>>>>>> call!
>>>>>> 
>>>>>> - Jouni & Dapeng
>>>>>> 
>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti:
>>>>>>> Folks,
>>>>>>> 
>>>>>>> The latest charter draft can be found here:
>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt
>>>>>>> 
>>>>>>> 
>>>>>>> The deadline for the text chnges are 31st July. I'll setup a call for
>>>>>>> next week so that those who want to dial in and have verbal commenting
>>>>>>> can do that. In a meanwhile, email works as usual for updates and
>>>>>>> comments on the text. The actual milestone dates are to be done
>>>>>>> last but
>>>>>>> suggestions are more than welcome.
>>>>>>> 
>>>>>>> - Jouni & Dapeng
>>>>> 
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>> 
>>

---

From: Jouni <[email-masked]>
Date: Mon, 1 Sep 2014 11:25:07 +0300

Alper,

I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The ""deployment models and scenarios" are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents.

Makes sense?

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Sep 2014 10:43:02 -0500

> I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The ""deployment models and scenarios" are the stage-2 descriptions and then we also need the protocol…

Thanks Alper for raising this issue.

3GPP Stage 2 like in SA2 documents are architecture documents.
I don't understand what is going on here.

I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses.

Yes, this document talks about deployment in just a few places, here
is one occurrence: on page 64, PCC deployment options
on page 94, PMIP based S5/S8 deployments, etc.

So in all cases the protocol, i.e. PCC or PMIP is known.

Regards,

Behcet
> [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 01 Sep 2014 21:34:37 +0300

Behcet,

Obviously that protocols are known that the intended deployment is going 
to use. The details what goes inside that protocol are not. This holds 
for my example case 3GPP as well.

We do not need to into same level of detail that e.g. 3GPP stage-2 has 
detailing all signaling flows and so on. I believe we as a WG are 
competent enough to make a fine division what level of detail is left 
for the "deployment models and scenarios" and what goes into protocol 
solutions.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Sep 2014 15:39:17 -0500

On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen <[email-masked]> wrote:
> Behcet,
>
> Obviously that protocols are known that the intended deployment is going to
> use. The details what goes inside that protocol are not. This holds for my
> example case 3GPP as well.
>
> detailing all signaling flows and so on. I believe we as a WG are competent
> enough to make a fine division what level of detail is left for the
> "deployment models and scenarios" and what goes into protocol solutions.
>

I hope you read previous mails on this issue.

I think it clear that 3GPP agrees with IETF on the interpretation of
deployment. How can we close our eyes on this and try to put the horse
before the cart?

Why not simply remove it?

Regards,
Behcet

>>> I hear your concern. Anyway, the division here is similar to (3GPP)
>>> stage-2 and stage-3 work. The ""deployment models and scenarios" are the
>>> stage-2 descriptions and then we also need the protocol level solutions that
>>> are in separate documents.
>>>
>>
>>>>> Okay, we are not going to define how the existing 3FPP system works -
>>>>> that knowledge is assumed. What I thought goes into the document, for
>>>>> example, in the case of 3GPP system would be identifying the architecture
>>>>> changes or modifications needed. If the deployment model assumes all network
>>>>> functions are virtualized, the document states that and lays out the
>>>>> architecture based on that. Satoru's & Ryuji's vEPC deployment model (based
>>>>> on their solution) is IMHO a good example of what could be documented. The
>>>>> similar applies for other system architectures such as SP Wi-Fi etc.
>>>>>
>>>>
>>>> Jouni,
>>>>
>>>> The "architecture changes" would be based on the a "specific solution".
>>>> So, as part of describing a solution one can be talking about what you are
>>>> suggesting above. But I don't understand how we can be talking about
>>>> "deployment models and scenarios" before we agree on the solutions.
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 03 Sep 2014 08:07:27 +0300

We were on this in yesterday's interim call. We have a proposal text 
now. You were also on the call but I did not record you commenting 
anything during the discussion we had on this particular topic. Are you 
now saying the resolution we have now in the charter text is not adequate?

- JOuni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Sep 2014 11:22:46 -0500

On Wed, Sep 3, 2014 at 12:07 AM, Jouni Korhonen <[email-masked]> wrote:
> We were on this in yesterday's interim call. We have a proposal text now.
> You were also on the call but I did not record you commenting anything
> during the discussion we had on this particular topic.

I had leave early due to doctor's appointment.

> Are you now saying
> the resolution we have now in the charter text is not adequate?
>

Distributed mobility management deployment models and scenarios:
describe the target high-level network architectures and
deployment models where distributed mobility management
protocol solutions would apply.

Behcet: the above text does not reflect my comments.
I am against any deployment work before we decide on a solution (and
there is currently no draft on this).
This is strongly supported by IETF work on deployment as well as 3GPP.

I am also concerned on the time DMM is taking on dressing up the
charter text. I remind you on what Jari Arkko who is founding AD for
DMM said in Toronto admin plenary:
WGs should have  solution work from day 1.

He also emphasized importance of running code.

It is not that we don't have solutions and it is claimed that two of
them have been implemented.

Regards,

behcet

>>> to
>>> competent
>>>>>>>>>>> The working group may decide to extend the current milestones
>>>>>>>>>>> based
>>>>>>>>>>> on
>>>>>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a
>>>>>>>>>>>>> call
>>>>>>>>>>>>> for

---

From: Brian Haberman <[email-masked]>
Date: Wed, 03 Sep 2014 12:30:39 -0400

Just for clarification...

> WGs should have  solution work from day 1.

Not "should", but rather "could".  Not all WGs need to have
requirements, frameworks, architecture, etc. That is why this type of
discussion during charter development is important.

> He also emphasized importance of running code.

Running code is good thing.  So is an understanding of customer needs
(in this case, other SDOs).

Regards,
Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Sep 2014 11:50:38 -0500

Hi Brian,

> discussion during charter development is important.

Here is the quote:
WGs should have solution work from day 1

from page 22 of Jari's slides at:

http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf

BTW we already did the requirements and gap analysis, etc. The
architecture in our case is defined elsewhere, like 3GPP and everybody
in this group is familiar with 3GPP architecture.

> (in this case, other SDOs).

Absolutely.

Regards,

Behcet

---

From: Brian Haberman <[email-masked]>
Date: Wed, 03 Sep 2014 13:19:39 -0400

> http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf

Yes, that is what the slide says.  The IESG discussed the contents of
this presentation and the overwhelming consensus (and what was
verbalized in the plenary) is that WGs should not be formed where the
*only* output is architecture, frameworks, and/or requirements
documents.  The charter should have protocol/solution work on the
charter from day one.  It does not mean that non-solution documents
should be skipped if they are needed or provide useful background.

The charter text that Jouni sent to the mailing has four (4) work items.
 By my read, three (3) of them are solutions to identified problem
areas.  So, I believe the charter is following the spirit of Jari's
plenary slides.

Your only complaint is about the first work item.  I have seen people
asking about clarifications on that work item, but you are the only one
who wants it removed.  I believe others are in favor of providing a
document of the high-level models being targeted for the solutions work.

At this point, the WG chairs need to determine if there is consensus for
the latest charter text.

Regards,
Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Sep 2014 13:33:22 -0500

> document of the high-level models being targeted for the solutions work.

You don't seem to understand my points.
Anyway, it is better for me to stop this discussion.

Regards,

Behcet

---

From: Brian Haberman <[email-masked]>
Date: Wed, 03 Sep 2014 14:53:20 -0400

Behcet,

> You don't seem to understand my points.

That is quite possible.  Your comment on the list was "I am against any
deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work item on
the agenda.  Please do tell me what I am missing.

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 3 Sep 2014 19:52:31 +0000

I don't follow this objection either. This discussion just derails
established consensus after months of discussions.

We design protocols to enable deployment/solutions/architectures. Those
solutions/architectures are not unique to a specific SDO or unique to a
specific access. Its a broader framework.

The agreements here are based on IETF WG consensus and not strictly based
on one specific SDO's requirement.

This type of out of context references to historical material does not
help these discussions.

Sri

On 9/2/14 10:07 PM, "Jouni Korhonen" <[email-masked]> wrote:

>>>>>>>>>>>        may or may not be collocated. Furthermore, the
>>>>>>>>>>>forwarding
>>>>>>>>>>> state
>>>>>>>>>>>        define solutions that allow, for example, mobile nodes
>>>>>>>>>>>to
>>>>>>>>>>> select
>>>>>>>>>>> May 2015 - Submit 'The deployment models and scenarios'
>>>>>>>>>>>submitted
>>>>>>>>>>> to
>>>>>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to
>>>>>>>>>>>the
>>>>>>>>>>> IESG.
>>>>>>>>>>>             To be Proposed Standard.
>>>>>>>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Sep 2014 12:14:04 +0200

> the agenda.  Please do tell me what I am missing.

Hi,

I am following the discussion and me too I do not quite understand what 
is the complain.

I am happy to learn that a if a WG is to be formed then it would be 
around a solution rather than just requirements or architecture.

That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted 
disconnect between the product developped - (P)Mobile IP - and the 
deployments.  We know for a fact that 3GPP deployments (2G/3G/4G) do not 
use (P)Mobile IP.  We also know that 3GPP specs do mention Mobile IP. 
To such a point that I wonder whether 3GPP has not the same disconnect 
as here.

On another hand, we do have indications of where (P)Mobile IP is used - 
the trials, the projects, the kernel code, and not least the slideware 
attracting real customers.

The worry: develop DMM protocol while continuing the disconnect.

Alex

---

From: Jouni <[email-masked]>
Date: Thu, 4 Sep 2014 13:31:29 +0300

Alex,

On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:

> I am following the discussion and me too I do not quite understand what is the complain.
> 
> I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture.

We have already done the requirements part. One source of the fuzz has been that we got no definitive "DMM architecture" so far.. but IETF is not supposed to work on architectures per se but on protocols.

> In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments.  We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here.

There are LTE deployments using PMIP. Nation wide even. While not hugely popular, there are still serious commercial deployments.

> On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers.
> 

DMM solutions are not predefined to be a (P)MIP extensions.

- Jouni

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 04 Sep 2014 03:31:54 -0700

Hello folks,

I have asked this same question many times, in different words...

Namely, if we design a solution that fits the requirements, and bridges
the gaps as analyzed in the gap analysis document, have we succeeded?

Or, is there a requirement for the work to be adopted by 3GPP?

What if we design for IEEE 802 Wireless, which is currently carrying the
preponderance of the world's wireless data, and will almost assuredly
continue to carry a greater proportion?

Regards
Charlie P.

On 9/4/2014 3:14 AM, Alexandru Petrescu wrote:
>
> Hi,
>
> ....
>
> In DMM, precedents and the keen NETEXT, there seems to be a
> hard-rooted disconnect between the product developped - (P)Mobile IP -
> and the deployments.  We know for a fact that 3GPP deployments
> (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do
> mention Mobile IP. To such a point that I wonder whether 3GPP has not
> the same disconnect as here.
>
> On another hand, we do have indications of where (P)Mobile IP is used
> - the trials, the projects, the kernel code, and not least the
> slideware attracting real customers.
>

-- 
Regards,
Charlie P.

---

From: Jouni <[email-masked]>
Date: Thu, 4 Sep 2014 13:35:41 +0300

> Or, is there a requirement for the work to be adopted by 3GPP?

It would be cool but not required.

> continue to carry a greater proportion?

..and if the solution were adopted that would count as a major success.

- JOuni

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Sep 2014 13:07:31 +0200

Le 04/09/2014 12:31, Jouni a écrit :
[...]
>> hard-rooted disconnect between the product developped - (P)Mobile
>> IP - and the deployments.  We know for a fact that 3GPP deployments
>> (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs
>> do mention Mobile IP. To such a point that I wonder whether 3GPP
>> has not the same disconnect as here.
>
> There are LTE deployments using PMIP. Nation wide even. While not
> hugely popular, there are still serious commercial deployments.

Jouni, I would truly appreciate to stand corrected because it would be a 
good example to tell other customers about the technology.

But I am afraid that what you are saying is part of: the trials, the 
projects, the kernel code and not least the slideware attracting real 
customers.

The nation-wide LTE IPv6 trial I am familiar with does not use PMIPv6.

Alex

>
>> On another hand, we do have indications of where (P)Mobile IP is
>> used - the trials, the projects, the kernel code, and not least the
>>> _______________________________________________ dmm mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Sep 2014 13:36:52 +0200

> the gaps as analyzed in the gap analysis document, have we succeeded?

My answer is no.  As of now it may look as a homework - yes it solves 
the problem statement, yes it gets a high grade, yes it can.  But what 
if no, deployments wouldn't need it.

> Or, is there a requirement for the work to be adopted by 3GPP?

Even then - even if there were a req from 3GPP  (a row in an excel 
sheet, an "IPv6" mentioned in a 3GPP doc) - one would rather need a 
commitment of deployment from 3GPP.

> continue to carry a greater proportion?

Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) 
one of the strong selling points of Mobile IP is the ability to offer 
session continuity when handover cellular/802-Wireless - the 
heterogeneity to some extent.

Additionally, there are many possibilities of doing Mobile IP in a 
802-Wireless only environment: large indoor hotspot areas, long 
11p-covered roads, etc.  These are exhibited in trials.

But, sorry for saying again, one couldn't stop wondering whether these 
are to be embraced by deployments.

Why is the 'tethering' application on operator's smartphones preferring 
to use a form of IPv6 prefix sharing rather than Mobile IP/NEMO?

Why there is no session continuity app in these smartphones?

Why one has to always click on some icon on their smartphones to (1) 
switch on/off 'mobile data', (2) turn on/off WiFi?

Given these behaviours one may wonder how much the session continuity 
aspect is need by end users.

There are some answers I heard about this... for example when one needs 
a session to be stable one by instinct will try to not move.  Hardly can 
one walk and talk: two things at a time.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Sep 2014 12:00:14 -0500

Hi Charlie,

Check this out:

http://tools.ietf.org/id/draft-sarikaya-dmm-for-wifi-00.txt

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Sep 2014 12:10:14 -0500

Hi Alex,

On Thu, Sep 4, 2014 at 6:36 AM, Alexandru Petrescu
<[email-masked]> wrote:
> My answer is no.  As of now it may look as a homework - yes it solves the
> problem statement, yes it gets a high grade, yes it can.  But what if no,
> deployments wouldn't need it.
>
>
> Even then - even if there were a req from 3GPP  (a row in an excel sheet, an
> "IPv6" mentioned in a 3GPP doc) - one would rather need a commitment of
> deployment from 3GPP.
>
>
> Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one of
> the strong selling points of Mobile IP is the ability to offer session
> continuity when handover cellular/802-Wireless - the heterogeneity to some
> extent.
>
> 802-Wireless only environment: large indoor hotspot areas, long 11p-covered
> roads, etc.  These are exhibited in trials.
>
> But, sorry for saying again, one couldn't stop wondering whether these are
> to be embraced by deployments.
>
> Why is the 'tethering' application on operator's smartphones preferring to
> use a form of IPv6 prefix sharing rather than Mobile IP/NEMO?
>
> Why one has to always click on some icon on their smartphones to (1) switch
> on/off 'mobile data', (2) turn on/off WiFi?
>

Good questions.

I think that 3GPP SA1 work reported by Alper is addressing this issue
in terms of classifying the flows. They identify certain class of
flows like interactive calls where you would definitely need session
continuity. 3GPP thinks that in most other cases like Web browsing you
don't.

So in dmm we can say that the protocol dmm is going to develop could
be a candidate solution for those flows that you need session
continuity.

I don't think IETF can do more.

Regards,

Behcet
> Given these behaviours one may wonder how much the session continuity aspect
> is need by end users.
>
> There are some answers I heard about this... for example when one needs a
> session to be stable one by instinct will try to not move.  Hardly can one
> walk and talk: two things at a time.
>
> Alex
>
>
>>
>> Regards
>> Charlie P.
>>
>>
>>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 4 Sep 2014 13:42:45 -0400

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Jouni
> Sent: Thursday, September 04, 2014 6:36 AM
> To: Charles E. Perkins
> Cc: [email-masked]
> Subject: Re: [DMM] regarding the re-chartering..
> 
> 
> > Namely, if we design a solution that fits the requirements, and
> > bridges the gaps as analyzed in the gap analysis document, have we
> succeeded?
> >
> > What if we design for IEEE 802 Wireless, which is currently carrying
> > the preponderance of the world's wireless data, and will almost
> > assuredly continue to carry a greater proportion?
> 

[JCZ] While I don't have a crystal ball to predict success of a
technology (to respond to other people's concerns), I would strongly
support addressing IEEE 802 Wireless technologies. Chances are that if
3GPP likes the solution, they will add some bits, change the name, and
will adopt it as a non-IETF solution.

Jc

> >> hard-rooted disconnect between the product developped - (P)Mobile
IP
> >> - and the deployments.  We know for a fact that 3GPP deployments
do
> >> On another hand, we do have indications of where (P)Mobile IP is
used

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Sep 2014 11:44:28 +0300

Hi Charlie,

Success is when we see the protocols we design are deployed and used.
Whether it's over 3GPP, WiFi, or something else.
The more the merrier.

I don't think anyone is preventing use of DMM over WiFi.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Sep 2014 11:48:53 +0300

Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work with GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Sep 2014 11:59:58 +0300

From meeting minutes:

(Jouni) "I suggest that we left the bullet as a work item and we do not have explicit milestone
for it. we can add this milestone when we actually see that there is something meaningful
forming for that document. "

The decision at the meeting was to leave the work item in the charter, but not to associate a specific milestone with it until the WG sees what goes into that document. It was not fully clear what would be in that document, and it's a concern that the rest of the WG documents would be gated by such a document. 
Jouni's above suggestion is a good way forward IMO.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Sep 2014 14:32:04 +0200

> Or, conveying the mobility characteristic of a prefix to the UE.

Alper - thanks for the reply.

Identifying the mobility needs of flows assumes that IP flows _can_ be 
characterized, and then distinguished as mobile - or non-mobile.  I 
think this is very hard to do, given the difficulty to write good 
firewall rules, and the difficulty of analyzing traffic dumps.

For example, Netalyzr was written to tell whether or not one's computer 
is connected to the Internet.  That report page has so many lines that 
it is hard to tell which part of it really means 'connected to the 
Internet'.

The same problem may arise when trying to identify a particular 'flow'.

Alex

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Sep 2014 15:45:50 +0300

Hi Alex,

On Sep 5, 2014, at 3:32 PM, Alexandru Petrescu wrote:

> Identifying the mobility needs of flows assumes that IP flows _can_ be characterized, and then distinguished as mobile - or non-mobile.  I think this is very hard to do, given the difficulty to write good firewall rules, and the difficulty of analyzing traffic dumps.
> 
> For example, Netalyzr was written to tell whether or not one's computer is connected to the Internet.  That report page has so many lines that it is hard to tell which part of it really means 'connected to the Internet'.
> 

The most robust way is to let the application tell the IP stack.

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Sep 2014 16:24:02 +0200

Le 05/09/2014 14:45, Alper Yegin a écrit :
>>> DMM is not meant to be only about a bunch of MIP-based
>>> solutions. There are various components in DMM solution space
>>> that'd also work with GTP-based architectures. For example,
>>> identifying the mobility needs of flows. Or, conveying the
>>> mobility characteristic of a prefix to the UE.
>>
>> Identifying the mobility needs of flows assumes that IP flows _can_
>> be characterized, and then distinguished as mobile - or non-mobile.
>> I think this is very hard to do, given the difficulty to write good
>> For example, Netalyzr was written to tell whether or not one's
>> computer is connected to the Internet.  That report page has so
>> many lines that it is hard to tell which part of it really means
>> 'connected to the Internet'.
>>

Sounds reasonable.

A complimentary means is to look at this as a source address selection 
problem: given two addresses configured on an interface (an IP address, 
and an IP address designated as CoA), the application selects the src 
address as the IP address if its flows are brief query/response (http), 
or it selects the src address as the CoA if its flows are longer timed 
(request of UDP stream, or TCP download).

This would need a means to designate to the stack an IP address as to be 
a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by 
deduction any address differing be the CoA.

Alex

>>>>> That is quite possible.  Your comment on the list was "I am
>>>>> against any deployment work before we decide on a
>>>>> solution..."
>>>>>
>>>>> I read that as an objection to having the deployment models
>>>>> work item on the agenda.  Please do tell me what I am
>>>>> missing.
>>>>>
>>>>> Regards, Brian
>>>>
>>>> Hi,
>>>>
>>>> I am happy to learn that a if a WG is to be formed then it
>>>> would be around a solution rather than just requirements or
>>>> architecture.
>>>>
>>>> hard-rooted disconnect between the product developped -
>>>> (P)Mobile IP - and the deployments.  We know for a fact that
>>>> 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP.  We also
>>>> know that 3GPP specs do mention Mobile IP. To such a point that
>>>> I wonder whether 3GPP has not the same disconnect as here.
>>>>
>>>> On another hand, we do have indications of where (P)Mobile IP
>>>> is used - the trials, the projects, the kernel code, and not
>>>> least the slideware attracting real customers.
>>>>
>>>>> _______________________________________________ dmm mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>>>
>>>> _______________________________________________ dmm mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>>
>>
>>
>
>
>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 05 Sep 2014 10:10:50 -0700

Hello folks,

I have made various presentations at IETF, some from many years
ago, proposing that Mobile IP enable use of GTP as a tunneling
option.  I still think that would be a good idea.  Should I re-re-revive
a draft stating this in more detail?

Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 6 Sep 2014 13:04:05 +0300

Alex,

> A complimentary means is to look at this as a source address selection problem: given two addresses configured on an interface (an IP address, and an IP address designated as CoA), the application selects the src address as the IP address if its flows are brief query/response (http), or it selects the src address as the CoA if its flows are longer timed (request of UDP stream, or TCP download).
> 

That's exactly the intention and the approach. 

> This would need a means to designate to the stack an IP address as to be a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by deduction any address differing be the CoA.
> 

At a high-level, yes. If you've read the draft you'll see there are some details and extensions on top of that (such as it's not a simply matter of CoA vs HoA, but there are in fact 3 types of IP addresses, and also a required type IP address can be configured on-demand when needed).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 6 Sep 2014 13:06:29 +0300

Hi Charlie,

GTP has its data-plane (GTP-U) and control-plane (GTP-C).
I think you are talking about using Mobile IP signaling in-place of GTP-C to enable GTP-U.
If so, I think it'd technically work. But, for adoption by 3GPP standards and deployments, we'd need to make a case for using Mobile IP instead of GTP-C. 

Alper

---

From: Jouni <[email-masked]>
Date: Sat, 6 Sep 2014 13:15:52 +0300

Just to point out that GTP-U also carries control information, which none of the existing *MIP user plane tunnels do not do today.

Regarding GTP-C part, 3GPP TS29.275 has done pretty thorough job already mapping GTPv2-C to PMIP signaling, so using GTP-U instead of GRE or IPIP should be rather straightforward if someone were to do it.

- Jouni

---

From: "MONGAZON-CAZAVET, BRUNO (BRUNO)" <[email-masked]>
Date: Mon, 8 Sep 2014 08:57:43 +0200

> a draft stating this in more detail?

I would be interested to look at this draft.
Thanks.
Bruno

>>> hard-rooted disconnect between the product developped - (P)Mobile IP 
>>> mention Mobile IP. To such a point that I wonder whether 3GPP has 
>>> not the same disconnect as here.
>>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 14:28:44 +0000

Hi Alper, Charlie,

> From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
> Sent: Saturday, September 06, 2014 3:06 AM
> To: Charlie Perkins
> Cc: [email-masked]
> Subject: [DMM] MIP and GTP (was Re: regarding the re-chartering..)
> 
> Hi Charlie,
> 
> If so, I think it'd technically work. But, for adoption by 3GPP standards and deployments, we'd need
> to make a case for using Mobile IP instead of GTP-C.

At the risk of saying "me too", AERO would work fine with GTP as
well, using AERO control plane signaling. AERO works over any
tunnel type that supports IP-in-*-in-IP encapsulation.

Thanks - Fred
[email-masked]
 
> >>> In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the
> product developped - (P)Mobile IP - and the deployments.  We know for a fact that 3GPP deployments
> (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do mention Mobile IP. To such a
> point that I wonder whether 3GPP has not the same disconnect as here.
> >>>
> >>> On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects,
> the kernel code, and not least the slideware attracting real customers.
> >>>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 10:50:04 -0700

Hello folks,

I'll go look for the link(s).  But in the meantime, as part of the ongoing
maintenance work, I'd be happy to see the following:

- Additional tunnel types (including GTP)
- Additional mobile node identifier types (including IMSI, MAC, ...)
- Additional security mechanisms

If there is a sliver of a chance that we could go down any one or more
of these paths, I will resurrect the old Internet drafts as well. If people
are interested, I will re-submit them for the November meeting.

There are two or three other things that Mobile IP needs also,
that take more words to express, but not necessarily directly
related to distributed mobility management.  Much of my development
had to do with trying to provide an easier / incremental path for the
deployment of Mobile IP by SDO partners in 3GPP, which would
necessitate inclusion in their standards, which (for instance) seems
to necessitate GTP as a tunneling protocol, etc.

Regards,
Charlie P.

On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote:
>>>>> against any

---

From: <[email-masked]>
Date: Tue, 9 Sep 2014 09:04:45 +0000

Hi,

I second Charlie on this proposal, especially on the need for additional MNID and tunnel types. Another example for the latter is: using GRE with MIP/NEMO.

BR,
Pierrick

>-----Message d'origine-----
>De : dmm [mailto:[email-masked]] De la part de Charlie Perkins
>Envoyé : lundi 8 septembre 2014 19:50
>À : MONGAZON-CAZAVET, BRUNO (BRUNO); [email-masked]
>Objet : Re: [DMM] regarding the re-chartering..
>
>
>Hello folks,
>
>If there is a sliver of a chance that we could go down any one or more of these
>paths, I will resurrect the old Internet drafts as well. If people are interested, I
>will re-submit them for the November meeting.
>
>There are two or three other things that Mobile IP needs also, that take more
>words to express, but not necessarily directly related to distributed mobility
>management.  Much of my development had to do with trying to provide an
>easier / incremental path for the deployment of Mobile IP by SDO partners in
>3GPP, which would necessitate inclusion in their standards, which (for
>instance) seems to necessitate GTP as a tunneling protocol, etc.
>
>Regards,
>Charlie P.
>
>
>
>>> I have made various presentations at IETF, some from many years ago,
>>> proposing that Mobile IP enable use of GTP as a tunneling option.  I
>>> still think that would be a good idea.  Should I re-re-revive a draft
>>> stating this in more detail?
>>
>>>>>> against any deployment work before we decide on a solution..."
>>>>>>
>>>>>> I read that as an objection to having the deployment models work
>>>>>> item on the agenda.  Please do tell me what I am missing.
>>>>>>
>>>>>> Regards,
>>>>>> Brian
>>>>> Hi,
>>>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 14:06:02 +0000

I support the extension to MN Id type. I talked to few people (Yokota-san, Jouni ..)  on this in the past and below is the explanation. Currently, the NAI that is carried in the PBU does not distinguish a IMSI based NAI, generic-NAI and a MAc-based NAI. Email below.

Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. If the tunnel type is GTP-U, there is no reason for the SDO to use a different signaling protocol, it can be GTP-C. That battle is over, I'd rather focus on pushing SDN approaches than trying to supporting GTP-U types in IETF mobility protocols. But, if some one wants to do this, I'll not argue against this.

Sri

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 28, 2013 11:57 AM
To: Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>
Subject: NAI Support over Gx

Hi Yokota-san:

We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-NAI. Can we define new sub-types to Mobile Node Identifier option ?

Value [http://www.iana.org/assignments/_support/sort_none.gif]  Description [http://www.iana.org/assignments/_support/sort_none.gif]    Reference [http://www.iana.org/assignments/_support/sort_none.gif]
1       NAI     [RFC4283<http://www.iana.org/go/rfc4283>]
               2            USER-NAI (user@realm, should not be used for IMSI-NAI)
               3            MAC-48

Goal is to address the issue below.

Any comments ?

---

1. If MAG sends a PBU which includes IMSI:

MN NAI Mobility Option Follows:
                Type: 0x08
              Length: 0x36
            Sub Type: 0x01
                 NAI: [email-masked]<mailto:[email-masked]>

The LMA will trigger the PCRF using the following AVP in the Gx CCR-I:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_IMSI (1)
          [M] Subscription-Id-Data: 724052800014033

2. If MAG sends a PBU which includes MSISDN:

Vendor Specific Mobility Option Follows:
                Type: 0x13
              Length: 0x0C
           Vendor ID: 0x000028AF
            Sub Type: 0x0C (MSISDN)
   Fragment (M) Flag: 0x00
              MSISDN: <552176297602>

Then, the LMA will trigger the PCRF using the following AVP in the Gx CCR-I:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_E164 (0)
          [M] Subscription-Id-Data: 552176297602

3. If the MAG sends a PBU with Username:

MN NAI Mobility Option Follows:
                Type: 0x08
              Length: 0x2C
            Sub Type: 0x01
                 NAI: [email-masked]<mailto:[email-masked]>

Then, How can LMA trigger the PCRF with this following AVP ?:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_NAI (3)
          [M] Subscription-Id-Data: [email-masked]<mailto:[email-masked]>

On 9/9/14 2:04 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

BR,
Pierrick

-----Message d'origine-----
De : dmm [mailto:[email-masked]] De la part de Charlie Perkins
Envoyé : lundi 8 septembre 2014 19:50
À : MONGAZON-CAZAVET, BRUNO (BRUNO); [email-masked]<mailto:[email-masked]>
Objet : Re: [DMM] regarding the re-chartering..

Hello folks,

Regards,
Charlie P.

Hello folks,

Regards,
Charlie P.

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work
with GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper

Regards,
Brian
Hi,

I am following the discussion and me too I do not quite understand
what is the complain.

Alex

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 14:11:36 +0000

This is bit strange. Some thing changed in the IANA Mobile Node Identifier pages.  I assumed the MN Id was defined in RFC4283. How come I see a definition in 5271 as well.

Confused. Jouni / Brian – Any ideas ? Unless, I've been smoking …

http://tools.ietf.org/html/rfc4283#page-3

http://tools.ietf.org/html/rfc5271#page-16

I remember this in the IANA pages. Unless, I edited this when I copied this into a mail in Feb 2013.

Now I see the following:

Option-Code for Mobile Node Identifier Option (Type 30)

Registration Procedure(s)

Standards Action or IESG Approval

Reference
[RFC5271<http://www.iana.org/go/rfc5271>]
Available Formats
[http://www.iana.org/_img/icons/text-csv.png]
CSV<http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters-9.csv>
Value [http://www.iana.org/assignments/_support/sort_none.gif]  Description [http://www.iana.org/assignments/_support/sort_none.gif]    Reference [http://www.iana.org/assignments/_support/sort_none.gif]
0       Reserved        [RFC5271<http://www.iana.org/go/rfc5271>]
1       NAI     [RFC5271<http://www.iana.org/go/rfc5271>]
2       IMSI    [RFC5271<http://www.iana.org/go/rfc5271>]
3-255   Unassigned

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 9, 2014 7:06 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charlie Perkins <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] regarding the re-chartering..

Sri

Hi Yokota-san:

Any comments ?

---

        [M] Subscription-Id:

        [M] Subscription-Id:

        [M] Subscription-Id:

Hi,

BR,
Pierrick

-----Message d'origine-----
De : dmm [mailto:[email-masked]] De la part de Charlie Perkins
Envoyé : lundi 8 septembre 2014 19:50
À : MONGAZON-CAZAVET, BRUNO (BRUNO); [email-masked]<mailto:[email-masked]>
Objet : Re: [DMM] regarding the re-chartering..

Hello folks,

Regards,
Charlie P.

Hello folks,

Regards,
Charlie P.

Alper

Regards,
Brian
Hi,

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Sep 2014 13:39:53 -0400

Hi Sri,

On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote:
> This is bit strange. Some thing changed in the IANA Mobile Node
> Identifier pages.  I assumed the MN Id was defined in RFC4283. How come
> I see a definition in 5271 as well.
>
>

No comments on that one :-). There are indeed two definitions of the 
MNID types.

The one you originally saw is for the mobility option and is available 
in the mobility parameters registry

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-5

The second one you saw is for the *ND option* to carry MNID from the 
ICMPv6 parameters registry

http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Sep 2014 13:41:13 -0400

On 09/09/2014 10:06 AM, Sri Gundavelli (sgundave) wrote:
> I support the extension to MN Id type. I talked to few people
> (Yokota-san, Jouni ..)  on this in the past and below is the
> explanation. Currently, the NAI that is carried in the PBU does not
> distinguish a IMSI based NAI, generic-NAI and a MAc-based NAI. Email below.

+1 for this.

Thanks
Suresh

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 18:09:46 +0000

Hi Suresh,

Thanks. That makes sense. Now, I remember that spec/update.

The option name conflict and my search not finding 4283 references threw
me off. Thanks.

> No comments on that one :-)

:)

Regards
Sri

On 9/9/14 10:39 AM, "Suresh Krishnan" <[email-masked]> wrote:

>> Confused. Jouni / Brian  Any ideas ? Unless, I've been smoking Š
>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 09 Sep 2014 14:48:33 -0400

Sri,

> The option name conflict and my search not finding 4283 references threw

If this is *really* confusing, it may be worth updating the name of one
of them.

Not sure if it is or not...

Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 18:56:58 +0000

Hi Brian,

It might worth adding a note in the IANA page. I will send a request to
IANA.

We refer to the "Mobile Node Identifier option" in all MIP/PMIP specs and
the search from IANA page ends in the Mobile Node Identifier option
defined for ICMP. 

Regards
Sri

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 09 Sep 2014 13:28:10 -0700

Hello folks,

Here's the last Internet Draft that we did, long ago expired:
http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 21:20:37 +0000

Hi Charlie,

This is good. Thanks.

1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2
address, why do we need to two sub-types ? Why not have just one sub-type
for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this
? Are these CGA-based IPv6 addresses ?

                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               |                 |                        |
               | IMSI            | 3                      |
               |                 |                        |
               | P-TMSI          | 4                      |
               |                 |                        |
               | EUI-48 address  | 5                      |
               |                 |                        |
               | EUI-64 address  | 6                      |
               |                 |                        |
               | GUTI            | 7                      |
               +-----------------+------------------------+

Regards
Sri
PS: Good to see Vijay back

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Sep 2014 21:30:28 +0000

Two more comments.

4.) I'd also use sub-type value of (2) for IMSI. Just to align with the
sub-types defined for MN Id defined for ICMP. I suspect there are some
implementations already using sub-type (2). Please see the other thread.

5.) For each of the sub-types, we need text including examples and some
explanation on how they are used.

Sri

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 10 Sep 2014 13:29:34 +0000

It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types of node-specific IDs. 

marco

>From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Dienstag, 9. September 2014 23:30
>To: Sri Gundavelli (sgundave); Charlie Perkins; [email-masked]
>Cc: Vijay Devarapalli
>4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types
>defined for MN Id defined for ICMP. I suspect there are some implementations
>already using sub-type (2). Please see the other thread.
>
>
>>address, why do we need to two sub-types ? Why not have just one
>>sub-type for mac based identifiers ?
>>
>>3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is
>>this ? Are these CGA-based IPv6 addresses ?
>>
>>
>>
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 10 Sep 2014 15:11:50 +0000

Yes. Currently, the MNID is if the nai format and is overloaded. The MNID
in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then carry
IMSI-NAI as the MN-ID.

So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri

On 9/10/14 6:29 AM, "Marco Liebsch" <[email-masked]> wrote:

>It seems the MNID is somehow overloaded to carry both, node-specific IDs,
>e.g. MAC, as well as subscriber IDs, which is the IMSI.
>>sub-types

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 10 Sep 2014 15:21:38 -0700

Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical identifier
or a physical identifier.  If the former, then somewhere (perhaps below
the network layer) the logical identifier has been bound to something
in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty,
so I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 10 Sep 2014 22:41:44 +0000

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not require the identifier to be bound to a physical device or a
interface identity. But, we have clearly seen requirements where the need
is for generating identifiers based on some physical identifiers. Those
physical identifiers include IMSI, MSISDN, IMEI, MAC ..etc. If we can
define a type for each of the source and the rules for generating MN-ID
based using those sources, the sender and receiver will have clear
guidance on how to use the spec. Some pointers, explanation and examples
for each of those identifiers will greatly help avoid inter-op issues.

Regards
Sri

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 11 Sep 2014 09:03:57 +0000

No issue with logical vs. physical ID. But I am wondering about two things:

Operation is clear to me in case a single MNID is present in a message and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup.. No big problem to solve, but
to be considered in implementations. 

If the reason for multiple present MNIDs with different sub-types is to do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would not be more appropriate
to go for a different container option to carry such information. Something like a complementary
identifier option.

marco

>From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
>Sent: Donnerstag, 11. September 2014 00:42
>To: Charlie Perkins; Marco Liebsch; [email-masked]
>Cc: Vijay Devarapalli
>Agree with that. MN-Id as its defined today is a logical identifier. It does not
>require the identifier to be bound to a physical device or a interface identity.
>But, we have clearly seen requirements where the need is for generating
>identifiers based on some physical identifiers. Those physical identifiers include
>IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the source
>and the rules for generating MN-ID based using those sources, the sender and
>receiver will have clear guidance on how to use the spec. Some pointers,
>explanation and examples for each of those identifiers will greatly help avoid
>inter-op issues.
>
>
>Regards
>Sri
>
>
>
>
>
>
>
>>identifiers, and not worry too much about whether it's a logical
>>identifier or a physical identifier.  If the former, then somewhere
>>(perhaps below the network layer) the logical identifier has been bound
>>to something in the physical interface, but that's not our problem.
>>
>>The number space for types of MNIDs is likely to stay pretty empty, so
>>I'd say we could add as many types as would be convenient for the
>>> Yes. Currently, the MNID is if the nai format and is overloaded. The
>>>MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>>>IMSI. Ex:
>>> We also have approaches to transform MAC to Pseudo IMSI, and then
>>> carry IMSI-NAI as the MN-ID.
>>>
>>>
>>>> It seems the MNID is somehow overloaded to carry both, node-specific
>>>>IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>>>>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>>>>>the  sub-types  defined for MN Id defined for ICMP. I suspect there
>>>>>are some  implementations  already using sub-type (2). Please see
>>>>>the other thread.
>>>>>
>>>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 13:58:09 +0000

I do not see a reason why multiple MN-Id instances need to be present in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more error
cases. Is that really needed ?

> I am wondering if it would not be more appropriate to go for a different
>container option to carry such information. Something like a
>complementary identifier option.

Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for a
Mac based identifiers, what will be there in the current MN-Id option ? We
still need to have identifier there ?

Sri

On 9/11/14 2:03 AM, "Marco Liebsch" <[email-masked]> wrote:

>>does not
>>>>>>> On 9/9/14 1:28 PM, "Charlie Perkins"
>>>>>>><[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello folks,
>>>>>>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 14:21:47 +0000

<Changing the subject line to reflect the MNId discussion>

Marco,

Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 11 Sep 2014 16:16:28 +0000

Hi Sri, please see inline.

>Sent: Donnerstag, 11. September 2014 15:58
>To: Marco Liebsch; Charlie Perkins; [email-masked]
>Cc: Vijay Devarapalli
>single message ? In my experience, this is strictly a deployment consideration,
>when to use what type of identifiers.

Then there is no issue and it's the cleanest approach. Multiple IDs possible,
deployment determines which type to use, single MNID present. Done.

>
>Assuming the backend system can tie all the MN-Id's to a single subscription, any
>presented identifier can be sufficient for the gateway to do the BCE lookup.
>

Not necessarily for the lookup. 
Only if multiple IDs should be conveyed to do more than a lookup..
Example: Use the TAC of an IMEI to tailor QoS on the LMA for a certain device type ;-)
Probably that goes beyond what has been proposed in this thread.

>
>
>> I am wondering if it would not be more appropriate to go for a
>>different container option to carry such information. Something like a
>Sounds interesting. Are you suggesting we leave the current MN-ID as it is, but
>use a new complementary option ? But, if the requirement is for a Mac based
>identifiers, what will be there in the current MN-Id option ? We still need to
>have identifier there ?

I proposed this only for IDs, which are conveyed to complement the one in the
MNID and are being used for other things than a BC lookup.

marco

>>Operation is clear to me in case a single MNID is present in a message
>>and I see the value in being flexible to choose from different
>>sub-types. If multiple MNIDs with different sub-types are present in a
>>single message, which one should e.g. the LMA take for the BC lookup..
>>No big problem to solve, but
>>If the reason for multiple present MNIDs with different sub-types is to
>>do other things than identifying the node or using the ID as key for a
>>lookup, I am wondering if it would not be more appropriate to go for a
>>different container option to carry such information.
>>Something like a complementary
>>identifier option.
>>
>>marco
>>
>>>Agree with that. MN-Id as its defined today is a logical identifier.
>>>It does not require the identifier to be bound to a physical device or
>>>a interface identity.
>>>But, we have clearly seen requirements where the need is for
>>>generating identifiers based on some physical identifiers. Those
>>>define a type for each of the source and the rules for generating
>>>MN-ID based using those sources, the sender and receiver will have
>>>clear guidance on how to use the spec. Some pointers, explanation and
>>>examples for each of those identifiers will greatly help avoid
>>>inter-op issues.
>>>
>>>
>>>Regards
>>>Sri
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>(perhaps below the network layer) the logical identifier has been
>>>>bound to something in the physical interface, but that's not our problem.
>>>>
>>>>> Yes. Currently, the MNID is if the nai format and is overloaded.
>>>>>The MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on
>>>>>the IMSI. Ex:
>>>>>> It seems the MNID is somehow overloaded to carry both,
>>>>>>node-specific IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>>>>>>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align
>>>>>>>with the  sub-types  defined for MN Id defined for ICMP. I suspect
>>>>>>>there are some  implementations  already using sub-type (2).
>>>>>>>Please see the other thread.
>>>>>>>
>>>>>>>
>>>>>>> 5.) For each of the sub-types, we need text including examples
>>>>>>>and some  explanation on how they are used.
>>>>>>>
>>>>>>>
>>>>>>> Sri
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Charlie,
>>>>>>>>
>>>>>>>> This is good. Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2.) Sub type value (1) is currently used. Its currently
>>>>>>>>overloaded for  IMSI-NAI (3GPP specs) and generic NAI based
>>>>>>>>identifiers. Given the  definition of new sub-types, we need some
>>>>>>>>text explaining the  motivation
>>>>>>>>
>>>>>>>> 3.) Proposed Sub-type value of (2) for IPv6 address. What
>>>>>>>>exactly is  this ? Are these CGA-based IPv6 addresses ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 17:12:15 +0000

Hi Marco,

>deployment determines which type to use, single MNID present. Done.

Ack. That will have least impact on the existing specs.

Regards
Sri

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 11 Sep 2014 14:46:29 -0700

Hello folks,

I propose to submit the ....-00.txt document as it is to the Internet
Drafts directory, and then to go about making updates according to
the discussion on this list. Do you think this is reasonable?

Regards,
Charlie P.

On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>>> and I see the value in being
>>> do other things than identifying

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 21:57:11 +0000

Hi Charlie,

Few more reviews/discussions and capturing the consensus in the base version will help. But, I'm ok either way …

Regards
Sri

From: Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 11, 2014 2:46 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hello folks,

Regards,
Charlie P.

Marco,

Sri

On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <[email-masked]><mailto:[email-masked]> wrote:

Sri

On 9/11/14 2:03 AM, "Marco Liebsch" <[email-masked]><mailto:[email-masked]> wrote:

No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not
require the identifier to be bound to a physical device or a interface
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical
identifiers include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
source
and the rules for generating MN-ID based using those sources, the sender
and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help
avoid
inter-op issues.

Regards
Sri

On 9/10/14 3:21 PM, "Charlie Perkins" <[email-masked]><mailto:[email-masked]>
wrote:

Hello folks,

Regards,
Charlie P.

Sri

On 9/10/14 6:29 AM, "Marco Liebsch" <[email-masked]><mailto:[email-masked]> wrote:

It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

marco

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.

5.) For each of the sub-types, we need text including examples and
some
explanation on how they are used.

Sri

On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <[email-masked]><mailto:[email-masked]>
wrote:

Hi Charlie,

This is good. Thanks.

1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded
for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
is
this ? Are these CGA-based IPv6 addresses ?

Regards
Sri

On 9/9/14 1:28 PM, "Charlie Perkins"
<[email-masked]><mailto:[email-masked]>
wrote:

Hello folks,

Regards,
Charlie P.

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 21 Sep 2014 16:59:38 +0000

Hi Hakima,

That is a good idea. We should register a type for the Dod-96 identifier as well.

Regards
Sri

From: Hakima Chaouchi <[email-masked]<mailto:[email-masked]>>
Date: Sunday, September 21, 2014 8:11 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Charlie Perkins <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hello Folks,

Do you think that considering specific but needed technologies for moving objects in  Internet of Things  such as RFID (Radio Frequency Identifier) with 96 bits identifiers will be also relevent to Charlie's current draft and the efforts related to MNID?

Regards,

Hakima

________________________________
De: "Sri Gundavelli (sgundave)" <[email-masked]<mailto:[email-masked]>>
À: "Charlie Perkins" <[email-masked]<mailto:[email-masked]>>, "Marco Liebsch" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, "Vijay Devarapalli" <[email-masked]<mailto:[email-masked]>>
Envoyé: Jeudi 11 Septembre 2014 23:57:11
Objet: Re: [DMM] MNID Types

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

Sri

Sri

marco

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Sri

marco

-----Original Message-----

Two more comments.

Sri

Hi Charlie,

This is good. Thanks.

Regards
Sri

Hello folks,

Regards,
Charlie P.

--
---------------------------------
Hakima Chaouchi
Professor
Telecom Sud Paris
Institut Mines Telecom
9 rue Charles Fourier
91011 Evry
0160764443

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 25 Sep 2014 13:38:42 -0700

Hello Hakima,

I'm putting in the RFID as a selection in the draft.  I have two
questions:

- Do we need to include various types of RFIDs?
- Can you send good citations for the Normative References?

I have 
http://www.acq.osd.mil/log/sci/ait/DoD_Suppliers_Passive_RFID_Info_Guide_v15update.pdf 
but I am not sure if that's the correct normative reference.

Regards,
Charlie P.

On 9/21/2014 8:11 AM, Hakima Chaouchi wrote:
> Hello Folks,
>
> Do you think that considering specific but needed technologies for 
> moving objects in  Internet of Things  such as RFID (Radio Frequency 
> Identifier) with 96 bits identifiers will be also relevent to 
> Charlie's current draft and the efforts related to MNID?
>
> Regards,
>
> Hakima
>
>
> ------------------------------------------------------------------------
> *De: *"Sri Gundavelli (sgundave)" <[email-masked]>
> *À: *"Charlie Perkins" <[email-masked]>, "Marco 
> Liebsch" <[email-masked]>, [email-masked], "Vijay Devarapalli" 
> <[email-masked]>
> *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
> *Objet: *Re: [DMM] MNID Types
>
> Hi Charlie,
>
> Few more reviews/discussions and capturing the consensus in the base 
> version will help. But, I'm ok either way …
>
>
> Regards
> Sri
>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>, 
> Marco Liebsch <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Vijay 
> Devarapalli <[email-masked] <mailto:[email-masked]>>
>     On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"<[email-masked]>  wrote:
>
>         On 9/11/14 2:03 AM, "Marco Liebsch"<[email-masked]>  wrote:
>
>                 To: Charlie Perkins; Marco Liebsch;[email-masked]
>                 Cc: Vijay Devarapalli
>                 On 9/10/14 3:21 PM, "Charlie Perkins"<[email-masked]>
>                 wrote:
>
>                     Hello folks,
>
>                         On 9/10/14 6:29 AM, "Marco Liebsch"<[email-masked]>  wrote:
>
>                                 To: Sri Gundavelli (sgundave); Charlie Perkins;[email-masked]
>                                 Cc: Vijay Devarapalli
>                                 On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"<[email-masked]>
>                                 wrote:
>
>                                     Hi Charlie,
>
>                                     This is good. Thanks.
>
>
>                                     [email-masked]://www.ietf.org/mailman/listinfo/dmm
>
>                                 [email-masked]://www.ietf.org/mailman/listinfo/dmm
>
>         [email-masked]://www.ietf.org/mailman/listinfo/dmm
>
>     [email-masked]://www.ietf.org/mailman/listinfo/dmm
>
>
>
> Email secured by Check Point
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Sep 2014 13:42:36 -0700

Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.

On 9/21/2014 9:59 AM, Sri Gundavelli (sgundave) wrote:
> From: Hakima Chaouchi <[email-masked] 
> <mailto:[email-masked]>>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> Cc: Charlie Perkins <[email-masked] 
> <mailto:[email-masked]>>, Marco Liebsch 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Vijay Devarapalli <[email-masked] 
> <mailto:[email-masked]>>
> *De: *"Sri Gundavelli (sgundave)" <[email-masked] 
> <mailto:[email-masked]>>
> *À: *"Charlie Perkins" <[email-masked] 
> <mailto:[email-masked]>>, "Marco Liebsch" 
> <[email-masked] <mailto:[email-masked]>>, 
> [email-masked] <mailto:[email-masked]>, "Vijay Devarapalli" 
> <[email-masked] <mailto:[email-masked]>>

-- 
Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Sep 2014 21:00:05 +0000

Hi Charlie,

I am interested in node IDs that can be represented in a DHCPv6 DUID. There is
RFC6355 which encodes a node ID based on DUID-UUID (Universally Unique
IDentifier). AFAICT, the UUID is a 128-bit container formatted per RFC4122
specifications that includes a time portion and a node ID portion. Any chance
this would satisfy what you are looking for?

Thanks - Fred

From: dmm [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: Thursday, September 25, 2014 1:43 PM
To: Sri Gundavelli (sgundave)
Cc: Vijay Devarapalli; [email-masked]
Subject: Re: [DMM] MNID Types

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

carrying the Mac address

Sri

to do the BCE lookup.

Sri

things:

not be more appropriate

identifier option.

marco

-----Original Message-----

Cc: Vijay Devarapalli

Hello Charlie,

does not

identity.

identifiers include

source

and

avoid

inter-op issues.

Regards

Sri

wrote:

Hello folks,

FQDNs).

Regards,

Charlie P.

IMSI. Ex:

Sri

of  node-specific IDs.

marco

-----Original Message-----

(sgundave)

Cc: Vijay Devarapalli

Two more comments.

the other thread.

some

Sri

wrote:

Hi Charlie,

This is good. Thanks.

802.2

for

motivation

is

               | IPv6 Address    | 2                      |

               |                 |                        |

               | IMSI            | 3                      |

               |                 |                        |

               | P-TMSI          | 4                      |

               |                 |                        |

               | EUI-48 address  | 5                      |

               |                 |                        |

               | EUI-64 address  | 6                      |

               |                 |                        |

               | GUTI            | 7                      |

Regards

Sri

wrote:

Hello folks,

Regards,

Charlie P.

dmm mailing list

dmm mailing list

dmm mailing list

dmm mailing list

--

Regards,

Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Sep 2014 14:08:28 -0700

Hello Fred,

I can include DUID-UUID as an identifier type, and cite RFC 4122. Is this
sufficient, or do I need to also do something related to DHCPv6 DUID?

I did not see any specific connection between this type of identifier and
the RFID discussion.  Is there something that relates the two types?

Regards,
Charlie P.

On 9/25/2014 2:00 PM, Templin, Fred L wrote:
> *From:*dmm [mailto:[email-masked]] *On Behalf Of *Charles E. Perkins
> *Sent:* Thursday, September 25, 2014 1:43 PM
> *To:* Sri Gundavelli (sgundave)
> *Cc:* Vijay Devarapalli; [email-masked]
> *Subject:* Re: [DMM] MNID Types
>
>
> Hello Sri,
>
>     *From: *Hakima Chaouchi <[email-masked]
>     *Date: *Sunday, September 21, 2014 8:11 AM
>     *To: *Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Charlie Perkins <[email-masked]
>     *Subject: *Re: [DMM] MNID Types
>
>     Hello Folks,
>
>     moving objects in  Internet of Things  such as RFID (Radio
>     Frequency Identifier) with 96 bits identifiers will be also
>     relevent to Charlie's current draft and the efforts related to MNID?
>
>     Regards,
>
>     Hakima
>
>     Few more reviews/discussions and capturing the consensus in the
>     base version will help. But, I'm ok either way …
>
>     Regards
>
>     Sri
>
>     *From: *Charlie Perkins <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Thursday, September 11, 2014 2:46 PM
>     *To: *Sri Gundavelli <[email-masked]
>     <mailto:[email-masked]>>, Marco Liebsch
>     *Subject: *Re: [DMM] MNID Types
>
>
>     Hello folks,
>
>         On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>             On 9/11/14 2:03 AM, "Marco Liebsch"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>               
>
>                     To: Charlie Perkins; Marco Liebsch;[email-masked]  <mailto:[email-masked]>
>
>                     Cc: Vijay Devarapalli
>
>                     On 9/10/14 3:21 PM, "Charlie Perkins"<[email-masked]>  <mailto:[email-masked]>
>
>                     wrote:
>
>                       
>
>                         Hello folks,
>
>                           
>
>                             On 9/10/14 6:29 AM, "Marco Liebsch"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>                               
>
>                                     To: Sri Gundavelli (sgundave); Charlie Perkins;[email-masked]  <mailto:[email-masked]>
>
>                                     Cc: Vijay Devarapalli
>
>                                     On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"<[email-masked]>  <mailto:[email-masked]>
>
>                                     wrote:
>
>                                       
>
>                                         Hi Charlie,
>
>                                           
>
>                                         This is good. Thanks.
>
>                                           
>
>                                           
>
>                                         <[email-masked]>  <mailto:[email-masked]>
>
>                                         wrote:
>
>                                           
>
>                                             Hello folks,
>
>                                               
>
>                                         [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm
>
>                                     [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm
>
>             [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm
>
>         [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/dmm
>
>

-- 
Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Sep 2014 21:13:03 +0000

Hi Charlie,

I guess I have to say “I don’t know” to both questions. MNIDs are a fairly new subject
for me, and I think others would be better qualified to answer. Just thought I would
offer what I do know in case it might be of some help.

Thanks - Fred

From: Charles E. Perkins [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 2:08 PM
To: Templin, Fred L; Sri Gundavelli (sgundave)
Cc: Vijay Devarapalli; [email-masked]
Subject: Re: [DMM] MNID Types

Hello Fred,

Regards,
Charlie P.

Thanks - Fred

Cc: Vijay Devarapalli; [email-masked]<mailto:[email-masked]>

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

carrying the Mac address

Sri

to do the BCE lookup.

Sri

things:

not be more appropriate

identifier option.

marco

-----Original Message-----

Cc: Vijay Devarapalli

Hello Charlie,

does not

identity.

identifiers include

source

and

avoid

inter-op issues.

Regards

Sri

wrote:

Hello folks,

FQDNs).

Regards,

Charlie P.

IMSI. Ex:

Sri

of  node-specific IDs.

marco

-----Original Message-----

(sgundave)

Cc: Vijay Devarapalli

Two more comments.

the other thread.

some

Sri

wrote:

Hi Charlie,

This is good. Thanks.

802.2

for

motivation

is

               | IPv6 Address    | 2                      |

               |                 |                        |

               | IMSI            | 3                      |

               |                 |                        |

               | P-TMSI          | 4                      |

               |                 |                        |

               | EUI-48 address  | 5                      |

               |                 |                        |

               | EUI-64 address  | 6                      |

               |                 |                        |

               | GUTI            | 7                      |

Regards

Sri

wrote:

Hello folks,

Regards,

Charlie P.

dmm mailing list

dmm mailing list

dmm mailing list

dmm mailing list

--

Regards,

Charlie P.

--

Regards,

Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Sep 2014 01:36:01 +0000

Hi Charlie,

> Is the DoD-96 identifier for a special kind of RFID, or is it valid for all the RFID devices that would be of interest?

I do not know the answer for this question. I assumed DOD-96 is a mandated standard for RFID encoding, but looks like there are other formats like GID-96 ..etc. May be this may end up needing subtypes. We can defer this question to Hakima and learn some details on this, she seems to have written many books on RFID.

Regards
Sri

From: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>
Organization: Blue Skies
Date: Thursday, September 25, 2014 1:42 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

Sri

Sri

marco

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Sri

marco

-----Original Message-----

Two more comments.

Sri

Hi Charlie,

This is good. Thanks.

Regards
Sri

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Sep 2014 02:01:32 +0000

I assumed DHCP-UUID is only one of the subtypes (type 4) of DUID definition specified in RFC3315.Defining one type value in MN-NAI for DUID should cover DUI-LLT, DUID-EN ..DUI-UUID ..etc…

It may appear we are boiling the ocean here, but defining a type value for all common identifiers will help.

Regards
Sri

From: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>
Organization: Blue Skies
Date: Thursday, September 25, 2014 2:08 PM
To: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hello Fred,

Regards,
Charlie P.

Thanks - Fred

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

carrying the Mac address

Sri

to do the BCE lookup.

Sri

things:

not be more appropriate

identifier option.

marco

-----Original Message-----

Cc: Vijay Devarapalli

Hello Charlie,

does not

identity.

identifiers include

source

and

avoid

inter-op issues.

Regards

Sri

wrote:

Hello folks,

FQDNs).

Regards,

Charlie P.

IMSI. Ex:

Sri

of  node-specific IDs.

marco

-----Original Message-----

(sgundave)

Cc: Vijay Devarapalli

Two more comments.

the other thread.

some

Sri

wrote:

Hi Charlie,

This is good. Thanks.

802.2

for

motivation

is

               | IPv6 Address    | 2                      |

               |                 |                        |

               | IMSI            | 3                      |

               |                 |                        |

               | P-TMSI          | 4                      |

               |                 |                        |

               | EUI-48 address  | 5                      |

               |                 |                        |

               | EUI-64 address  | 6                      |

               |                 |                        |

               | GUTI            | 7                      |

Regards

Sri

wrote:

Hello folks,

Regards,

Charlie P.

dmm mailing list

dmm mailing list

dmm mailing list

dmm mailing list

--

Regards,

Charlie P.

--
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Sep 2014 22:46:21 -0700

Hello folks,

Now we have two kinds of identifiers that could reasonably be
grouped as a type plus subtypes.  I could specify this by writing
another section of the new draft that lays out another subtype
field after the MNID subtype field from 4283.  I guess it would
be a "subsubtype" field if we are following the nomenclature for
the fields as shown in RFC 4283.

Or, alternatively, I could specify that for some types (e.g., DUID
and RFID), the first eight bits of the identifier is the a field that
we might call the "identifier subtype".  Maybe that is cleaner.

A third option would be to update RFC 4283, but that seems to
be a bit heavy-handed.

Comments?  Or other options?

Regards,
Charlie P.

On 9/25/2014 9:31 PM, Hakima Chaouchi wrote:
> Hi,
>
> For RFID we refer to the EPC standards.
>
> "The /Electronic Product Code/ (EPC) is an identification scheme for 
> universally identifying physical objects by using Radio Frequency 
> Identification (RFID) tags.
> The standardized EPC tag encoding consists of an EPC Identifier that 
> uniquely identifies an individual object, and may also include a 
> filter value if the filter is needed to enable effective and efficient 
> reading of the EPC tags. The EPC Identifier is a meta-coding scheme 
> designed to support the needs of various industries by accommodating 
> existing coding schemes where possible and by defining new schemes 
> where necessary."
>
> "EPC supports several encoding systems or schemes including GID 
> (Global Identifier), SGTIN (Serialized Global Trade Item Number), SSCC 
> (Serial Shipping Container), GLN (Global Location Number), GRAI 
> (Global Returnable Asset Identifier), DOD (Department of Defense) and 
> GIAI (Global Individual Asset Identifier).
>
> For each scheme except GID, there are two variations—a 64-bit scheme 
> (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a 
> 96-bit scheme.
>
> Within each scheme, an EPC identifier can be represented in a binary 
> form or other forms such as URI ..etc".
>
> May be we need some subtyping.
>
> Cheers,
>
> Hakima
>
>
> *À: *"Charles E. Perkins" <[email-masked]>
> *Cc: *"Vijay Devarapalli" <[email-masked]>, [email-masked]
> *Envoyé: *Vendredi 26 Septembre 2014 03:36:01
> > Is the DoD-96 identifier for a special kind of RFID, or is it valid 
> for all the RFID devices that would be of interest?
>
> I do not know the answer for this question. I assumed DOD-96 is a 
> mandated standard for RFID encoding, but looks like there are other 
> formats like GID-96 ..etc. May be this may end up needing subtypes. We 
> can defer this question to Hakima and learn some details on this, she 
> seems to have written many books on RFID.
>
>
> Regards
> Sri
>
>
>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>     To: Sri Gundavelli <[email-masked]

-- 
Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Sep 2014 05:54:53 +0000

Thanks.

Thinking about this further, having the RFID subtype  is probably going to be extremely useful for IOT applications. A MAG/MR can potentially register devices identified with RFID as the NAI; Also, there seems to be some mapping between 64-bit EPC and IPv6 Identifier, allowing device addressability over IPv6 and that makes this interesting and enable some new use-cases.

Regards
Sri

From: Hakima Chaouchi <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 25, 2014 9:31 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>, Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hi,

"The Electronic Product Code (EPC) is an identification scheme for universally identifying physical objects by using Radio Frequency Identification (RFID) tags.
The standardized EPC tag encoding consists of an EPC Identifier that uniquely identifies an individual object, and may also include a filter value if the filter is needed to enable effective and efficient reading of the EPC tags. The EPC Identifier is a meta-coding scheme designed to support the needs of various industries by accommodating existing coding schemes where possible and by defining new schemes where necessary."

"EPC supports several encoding systems or schemes including GID (Global Identifier), SGTIN (Serialized Global Trade Item Number), SSCC (Serial Shipping Container), GLN (Global Location Number), GRAI (Global Returnable Asset Identifier), DOD (Department of Defense) and GIAI (Global Individual Asset Identifier).

For each scheme except GID, there are two variations—a 64-bit scheme (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a 96-bit scheme.

Within each scheme, an EPC identifier can be represented in a binary form or other forms such as URI ..etc".

Cheers,

Hakima

________________________________
De: "Sri Gundavelli (sgundave)" <[email-masked]<mailto:[email-masked]>>
À: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>
Cc: "Vijay Devarapalli" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Envoyé: Vendredi 26 Septembre 2014 03:36:01
Objet: Re: [DMM] MNID Types

Hi Charlie,

Regards
Sri

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

Sri

Sri

marco

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Sri

marco

-----Original Message-----

Two more comments.

Sri

Hi Charlie,

This is good. Thanks.

Regards
Sri

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Sep 2014 06:07:30 +0000

I think updating RFC4283 is probably not an option. That will impact lot of existing specs.

My preference is for  defining explicit type value in MN-ID for different RFID types and DHCP DUID types; Still keep the RFC4283 option format.

Ex:
Subtype 4: DUID-LLT
Subtype 5: DUID-UUID
Subtype 6: RFID-GLN-66 …

…

Regards
Sri

From: "Charles E. Perkins" <[email-masked]<mailto:[email-masked]>>
Organization: Blue Skies
Date: Thursday, September 25, 2014 10:46 PM
To: Hakima Chaouchi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] MNID Types

Hello folks,

Regards,
Charlie P.

Cheers,

Hakima

________________________________
De: "Sri Gundavelli (sgundave)" <[email-masked]><mailto:[email-masked]>
À: "Charles E. Perkins" <[email-masked]><mailto:[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Envoyé: Vendredi 26 Septembre 2014 03:36:01
Objet: Re: [DMM] MNID Types

Hi Charlie,

Regards
Sri

Hello Sri,

Regards,
Charlie P.

Regards
Sri

Hello Folks,

Regards,

Hakima

Hi Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Marco,

Sri

Sri

marco

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; [email-masked]<mailto:[email-masked]>
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Regards
Sri

Hello folks,

Regards,
Charlie P.

Sri

marco

-----Original Message-----

Two more comments.

Sri

Hi Charlie,

This is good. Thanks.

Regards
Sri

Hello folks,

Regards,
Charlie P.

--
Regards,
Charlie P.

--
Regards,
Charlie P.