Subject: Re: [netlmm] Terminology confusion in draft-sgundave-mip6-proxymip6-01

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Jan 2007 12:48:19 -0800 (PST)

Hello Julien,

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]
Sent: Wednesday, January 17, 2007 2:55:37 AM
Subject: Re: [netlmm] Terminology confusion in draft-sgundave-mip6-proxymip6-01

Hi Vidya,

As I said earlier, I support using the NETLMM 
terminology we've been using since the WG started. I 
agree with you that re-use of MIP6 terminology is 
confusing (That was one reason why we defined LMA in 
the first place, to avoid confusion with the HMIPv6 
MAP entity.)

So LMA is not HA. I think this distinction is very important from PMIP point of view. The consensus in SD was to use MIP based solution reusing entities like HA. So I see no reason to remove HA from a PMIP protocol. HA is something we know, they are deployed, there are HA boxes, cards, etc. available.
Now, there is something called MAP as well, and it is not that we don't like it but it is a different issue, i.e. the consensus was not about P-HMIP in SD as far as I can tell.

Julien you should know how changing terms could affect things from your MN-AR draft?

Best,

--julien

On Tuesday 16 January 2007 23:15, Narayanan, Vidya 
wrote:
> All,
> Having followed all the discussion, I think there is
> some confusion due to the re-use of MIP6 terminology
> in this draft. I suggest that we really focus on the
> PMIP6 functionality and design, and use terminology
> that can clearly distinguish it from MIP6. So, I
> suggest the following terms:
>
> 1. PMA (Proxy Mobility Agent) or MAG (Mobility
> Access Gateway) 2. LMA (Local Mobility Agent)
> 3. PMIP IP Address (PIA) (Address assigned to the MN
> in the PMIP domain) 4. PMIP Tunnel Address (PTA)
> (Address of the PMA to which packets are to be sent)
>
> Particularly, since there are several possible
> realizations of MIP6 and PMIP6 feasible in a system,
> using the same terminology leads to confusion. As
> far as this protocol is concerned, it should have
> its own functional entities. Depending on
> architecture choices, the functional elements of
> MIP6 and PMIP6 may be collocated.
>
> Vidya
Regards,

--behcet

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Barnaba Barnowski" <[email-masked]>
Date: Wed, 17 Jan 2007 17:02:02 -0500

Hi:

The re-use of MIP6 terminology in the context of PMIP6 protocol
definition creates some confusion, especially when discussing
architecture in different SDOs.  Specifically it muddles the discussion
about PMIP6/MIP6 co-existence and interaction.  While I agree that in
the near term the focus should be on defining PMIP6 protocol, the issue
of PMIP6/MIP6 co-existence still needs to be addressed (and soon!).
Shared terminology will make this more difficult.  For instance in 3GPP2
the PMIP HA (p-HA, LMA) will not always be co-located with a client MIP
HA.   It is therefore much easier to discuss the PMIP6/MIP6 interaction
(or opaqueness) if one can refer to an HA and mean MIP6 and an LMA and
mean PMIP6.  The actual functionality of an HA and an LMA may still be
very similar, if not the same.

Cheers
Barney

---

From: Sebastian Thalanany <[email-masked]>
Date: Wed, 17 Jan 2007 17:59:34 -0600

Hi, Barney,
                          Thanks for your comments.

                           The PMIP function should be treated as a 
logical function, which may be co-located with a CMIP function, or may 
reside in hierarchically separate mobility anchors (HA or LMA). Perhaps, 
the location of the PMIP function could be inferred from the applicable 
mobility procedure, or explicitly qualified as you've suggested: PMIP-HA 
or PMIP-LMA.

Regards,
    Sebastian

---

From: Julien Laganier <[email-masked]>
Date: Thu, 18 Jan 2007 09:20:49 +0100

On Wednesday 17 January 2007 21:48, Behcet Sarikaya 
> Hello Julien,

Hi Behcet,

> > terminology we've been using since the WG started. 
> >
> > I agree with you that re-use of MIP6 terminology is
> > confusing (That was one reason why we defined LMA
> > in the first place, to avoid confusion with the
> > HMIPv6 MAP entity.)
>
> So LMA is not HA. I think this distinction is very
> important from PMIP point of view. The consensus in
> SD was to use MIP based solution reusing entities
> like HA. So I see no reason to remove HA from a PMIP
> protocol. HA is something we know, they are
> deployed, there are HA boxes, cards, etc. available.
> Now, there is something called MAP as well, and it
> is not that we don't like it but it is a different
> issue, i.e. the consensus was not about P-HMIP in SD
> as far as I can tell.

I think you are confusing things by equating the 
consensus we had to develop a NETLMM solution based on 
PMIP with both:

   1. NETLMM bits-on-the-wire based on MIP
      bits-on-the-wire, and

   2. NETLMM network entities are the same than MIP
      network entities

While I agree that the consensus we had implies 1, it 
certainly does not imply 2. 

MIP is a protocol, not a system architecture, so 
considerations on placement and collocation of 
MIP/PMIP network entities is out-of-scope of this WG, 
IMO.

> affect things from your MN-AR draft?

Changing terms does not affect protocol or system 
architecture. It does affect, however, the WG ability 
to have articulate discussions.

Best,

--julien

> > Having followed all the discussion, I think there
> > is some confusion due to the re-use of MIP6
> > terminology in this draft. I suggest that we
> > really focus on the PMIP6 functionality and
> > design, and use terminology that can clearly
> > distinguish it from MIP6. So, I suggest the
> > following terms:
> >
> > 3. PMIP IP Address (PIA) (Address assigned to the
> > MN in the PMIP domain) 4. PMIP Tunnel Address
> > (PTA) (Address of the PMA to which packets are to
> > be sent)
> >
> > realizations of MIP6 and PMIP6 feasible in a
> > system, using the same terminology leads to
> > confusion. As far as this protocol is concerned,
> > it should have its own functional entities.
> > Depending on architecture choices, the functional
> > elements of MIP6 and PMIP6 may be collocated.
> >
> > Vidya
>
> Regards,
>
> --behcet

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 18 Jan 2007 10:02:24 +0100

Hi Julien, hi Behcet,

I agree that "HA" as PMIPv6 anchor name may cause some confusion when
discussing interaction between PMIPv6 and MIPv6. However, IMHO it has
benefits if "HA" would still be part of the name, in order to express
the fact that a major part of the entity is equivalent to a HA (i.e., it
is an RFC3775 HA with some extensions/modifications). 

BTW, a NEMO-capable HA is also called HA (or a MONAMI6-capable HA, a
DSMIP-capable HA etc), even though the functionality of the entity is
not exactly the same than a RFC3775 HA.

So how about PMIPv6-capable HA, or short PMIP6-HA, or even shorter pHA? 

Regards,

Kilian

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Donnerstag, 18. Januar 2007 09:21
> To: Behcet Sarikaya
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 18 Jan 2007 10:48:27 +0100

> So how about PMIPv6-capable HA, or short PMIP6-HA, or even shorter pHA?
Imagine you call it PMIPv6-capable HA, then what should one understand?

    -supports both MIP6 and PMIPv6
    or
    -supports only PMIPv6

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 18 Jan 2007 11:05:21 +0100

>    -supports both MIP6 and PMIPv6

A PMIPv6-enabled HA would mean it supports PMIPv6 and it wouldn't
preclude support of MIPv6/NEMO (so, it's not "only" and it's not
necessarily "both").

The question is how much different is a PMIPv6-enabled HA and a
MIPv6-enabled HA. If there are about the same, it makes sense to call
it HA in both cases.

My 2 cents.
Thierry

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 18 Jan 2007 11:13:18 +0100

> preclude support of MIPv6/NEMO (so, it's not "only" and it's not

Yes, this was also my thinking. I'm not sure if it is really important
for the MIPv6/PMIPv6 interaction discussion to distinguish between both
cases. If it is important in a specific context, one can still say
"PMIPv6-only HA".

> MIPv6-enabled HA. If there are about the same, it makes sense to call

I agree. I assume that the difference is small enough. At least many
people claimed this as an advantage of the PMIPv6 approach. 

Regards,

Kilian

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 18 Jan 2007 03:15:58 -0800

Hi Kilian,

I fully agree with you. The whole point of basing this work on PMIP is
to base the protocol on MIP i.e., PMIP should be a delta on MIP, not an
entirely different protocol. 

If PMIP becomes an entirely different protocol then how do we expect
PMIP to utilize already defined MIP extension for things like support
for Dual Stack, NEMO and others??

George

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 4:02 AM
> To: [email-masked]
> Subject: RE: [netlmm] Terminology confusion in draft-sgundave-mip6-
> proxymip6-01
> 
> Hi Julien, hi Behcet,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 12:40:56 +0100

Behcet can you please ask Vidya whether html posting is allowed or not. 
  I have the feeling many people prefer text and I do too.

Just wanted to mention this.  It seems recommendations do work.

Alex

Behcet Sarikaya wrote:
> So LMA is not HA. I think this distinction is very important from PMIP 
> point of view. The consensus in SD was to use MIP based solution reusing 
> entities like HA. So I see no reason to remove HA from a PMIP protocol. 
> HA is something we know, they are deployed, there are HA boxes, cards, 
> etc. available.
> Now, there is something called MAP as well, and it is not that we don't 
> like it but it is a different issue, i.e. the consensus was not about 
> P-HMIP in SD as far as I can tell.
>  
> ------------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 12:44:59 +0100

Barnaba Barnowski wrote:
> architecture in different SDOs.  Specifically it muddles the 
> discussion about PMIP6/MIP6 co-existence and interaction.

I agree, and not only confusion in SDO discussion but any other non-SDO
and non-IETF discussion is completely muddled when discussing both MIP6
and PMIP6.  As a side note, the confusion happens to a lesser extent
when discussion netlmmDT +MIP6.

> Specifically it muddles the discussion about PMIP6/MIP6 co-existence 
> and interaction.  While I agree that in the near term the focus 
> should be on defining PMIP6 protocol, the issue of PMIP6/MIP6 
> co-existence still needs to be addressed (and soon!). Shared 
> terminology will make this more difficult.  For instance in 3GPP2 the
>  PMIP HA (p-HA, LMA) will not always be co-located with a client MIP
>  HA.

Aha, so SDO doesn't necessarily require LMA co-located with client MIP
HA.  There's a draft addressing this separation.

> It is therefore much easier to discuss the PMIP6/MIP6 interaction (or
> opaqueness) if one can refer to an HA and mean MIP6 and an LMA and
> mean PMIP6.  The actual functionality of an HA and an LMA may still
> be very similar, if not the same.

I agree,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 13:45:41 +0100

Kilian Weniger wrote:
>>> -supports both MIP6 and PMIPv6 or -supports only PMIPv6
> Yes, this was also my thinking. I'm not sure if it is really
> important for the MIPv6/PMIPv6 interaction discussion to distinguish
> between both cases. If it is important in a specific context, one can
> still say "PMIPv6-only HA".
> 
>> MIPv6-enabled HA. If there are about the same, it makes sense to
>> call it HA in both cases.
> 

I've never claimed such.  PMIPv6 vs MIPv6 is huge difference.  People in
SDO may see it very similar.  If I were to work for developping an SDO
solution - yes - I wouldn't see much difference between MIPv6 and MIPv6.
  I'd recommend too to re-use MIP6 and have a local solution that works
quickly, local to that SDO, on that SDO's wireless link, and only on that.

Alex

---

From: Andy Huang <[email-masked]>
Date: Thu, 18 Jan 2007 21:11:27 +0800

Hi, all

I also think HA used in PMIP may cause the confusion, but if we don't plan 
to discuss the interaction between MIP and PMIP, HA is still ok for PMIP, 
after all, HA in PMIP has similar function to HA in MIP as far as I am 
concered.

Best regards
Zhigang Huang

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "Kilian Weniger" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 18, 2007 7:15 PM
Subject: RE: [netlmm] Terminology confusion in 
draft-sgundave-mip6-proxymip6-01

Hi Kilian,

George

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 18 Jan 2007 09:03:09 -0500

I also agree that it will make sense to figure out the delta between 
PMIP-HA and MIPv6-HA. How much of change is required to upgrade/modify 
an existing MIPv6-HA so that it can behave as PMIP-HA as well. From the 
deployment perspective it is very important.

If the folks who already have MIPv6 deployment would like to support 
PMIP, it would be helpful to know what changes they will need to make in 
their infrastructure besides  installing PMAs in their access networks.

Thanks
Ashutosh

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 18 Jan 2007 09:25:37 -0600

All,

Following this discussion and whatever discussion lead to PMIP adoption
as a protocol in NetLMM WG, I believe that we have two valid High level
requirements:

The first one is the fact that one of the very major requirements which
drove the adoption of PMIP as a protocol in the NetLMM WG was "the
re-use of existing MIPv6 protocol and entities, especially the HA." what
this means is that any PMIPv6-capable-HA should already support MIPv6.

The second, as Vidya pointed out, that whatever protocol NetLMM WG will
adopt must follow/address/satisfy draft-ietf-netlmm-nohost-req and
draft-ietf-netlmm-threats.

However, IMO at the end, we need a terminology that is not ambiguous,
help advance the discussion and at the same time satisfy both of the
above requirements. 

I believe that PMIPv6-capable-HA (in short PMIPv6-HA), as Kilian
suggested, should satisfy both of these requirements:
1. It still refers to the new entity as a HA. 
2. Since LMA is a functional entity, a PMIPv6-HA clearly indicates the
support for that functionality.

I hope this will help advancing the discussion forward.

Regards,
Ahmad

> Sent: Thursday, January 18, 2007 3:02 AM
> To: [email-masked]
> I agree that "HA" as PMIPv6 anchor name may cause some 
> confusion when discussing interaction between PMIPv6 and 
> MIPv6. However, IMHO it has benefits if "HA" would still be 
> part of the name, in order to express the fact that a major 
> part of the entity is equivalent to a HA (i.e., it is an 
> RFC3775 HA with some extensions/modifications). 
> 
> BTW, a NEMO-capable HA is also called HA (or a 
> MONAMI6-capable HA, a DSMIP-capable HA etc), even though the 
> functionality of the entity is not exactly the same than a RFC3775 HA.
> 
> > > > As I said earlier, I support using the NETLMM terminology we've 
> > > > been using since the WG started.
> > > >
> > > > I agree with you that re-use of MIP6 terminology is confusing 
> > > > (That was one reason why we defined LMA in the first place, to 
> > > > avoid confusion with the
> > > > HMIPv6 MAP entity.)
> > >
> > > So LMA is not HA. I think this distinction is very important from 
> > > PMIP point of view. The consensus in SD was to use MIP based 
> > > solution reusing entities like HA. So I see no reason to 
> remove HA 
> > > from a PMIP protocol. HA is something we know, they are deployed, 
> > > there are HA boxes, cards, etc. available.
> > > Now, there is something called MAP as well, and it is not that we 
> > > don't like it but it is a different issue, i.e. the consensus was 
> > > not about P-HMIP in SD as far as I can tell.
> > 
> > I think you are confusing things by equating the consensus 
> we had to 
> > develop a NETLMM solution based on PMIP with both:
> > 
> > MIP is a protocol, not a system architecture, so considerations on 
> > placement and collocation of MIP/PMIP network entities is 
> out-of-scope 
> > of this WG, IMO.
> > 
> > > Julien you should know how changing terms could affect 
> things from 
> > > your MN-AR draft?
> > 
> > Changing terms does not affect protocol or system architecture. It 
> > does affect, however, the WG ability to have articulate discussions.
> > 
> > Best,
> > 
> > --julien
> > 
> > >
> > > Best,
> > >
> > > --julien
> > >
> > > > Having followed all the discussion, I think there is some 
> > > > confusion due to the re-use of MIP6 terminology in this 
> draft. I 
> > > > suggest that we really focus on the PMIP6 functionality and 
> distinguish it from 
> > > > MIP6. So, I suggest the following terms:
> > > >
> > > > 1. PMA (Proxy Mobility Agent) or MAG (Mobility Access 
> Gateway) 2. 
> > > > LMA (Local Mobility Agent) 3. PMIP IP Address (PIA) (Address 
> > > > assigned to the MN in the PMIP domain) 4. PMIP Tunnel Address
> > > > (PTA) (Address of the PMA to which packets are to be sent)
> > > >
> > > > Particularly, since there are several possible realizations of 
> > > > MIP6 and PMIP6 feasible in a system, using the same terminology 
> > > > leads to confusion. As far as this protocol is concerned, it 
> > > > should have its own functional entities.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Jan 2007 08:27:45 -0800 (PST)

Yes. I agree with Kilian as well.

There are lot of questions about the impact on the home
agent for supporting Proxy Mobile IP. Couple of points:

1. PMIP support on the home agent is a simple feature
extension and is not a rewrite of the home agent.

2. One of the design goal is to ensure, the same home agent
can support both registrations from the 3775 Mobile Nodes
and from Proxy Mobile Agents.

3. Changes required on the home agent for supporting this
feature is in the order of a featurette. I'd say, around
the size of supporting NEMO on the home agent.

Following are the summary of changes on the home agent
for supporting this feature

- Introducing certain fields to the BCE structure (Sec 5.1)
- Associating a tunnel interface for multiple mobile flows
- Decoupling the tunnel life timer from the binding life timer
   and keeping a user count
- Logic change in processing Proxy Binding Updates, relaxing
   the presence of Destination Option. Using time stamp option
   relaxing the seq number and removing TYpe-II routing header
   in the Binding Ack.
- IPv4 HoA Support. Some IPv4 packet forwarding logic, for
   handling the packets received from the HA-PMA tunnel.
- Minor other checks for Proxy Updates

>From our implementation experience, we did not see much changes
on the home agent. I'd think any of the open source home agent
implementations would need the same amount of changes as well.

Regards
Sri

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 18 Jan 2007 12:02:51 -0500

George / Kilan, 

I also fully agree with you. We should not re-invent entirely new
protocol in the name of 
PMIPv6.  IMHO, the success of PMIPv6 will depend how much HA re-use we
have achieved.. 
Probably we should only focus on support of IPv6 traffic in base draft. 

Regards,
Ajoy 

-----Original Message-----
From: Tsirtsis, George [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 5:16 AM
To: Kilian Weniger; [email-masked]
Subject: RE: [netlmm] Terminology confusion in

Hi Kilian,

George

> > > solution reusing entities like HA. So I see no reason to remove HA

> > I think you are confusing things by equating the consensus we had to

> > While I agree that the consensus we had implies 1, it certainly does

> > not imply 2.
> > out-of-scope of this WG, IMO.
> >
> > > Julien you should know how changing terms could affect things from

> > > > confusion due to the re-use of MIP6 terminology in this draft. I

> > > > design, and use terminology that can clearly distinguish it from

> > > > 1. PMA (Proxy Mobility Agent) or MAG (Mobility Access Gateway) 
> > > > 2. LMA (Local Mobility Agent) 3. PMIP IP Address (PIA) (Address 
> > > > Depending on architecture choices, the functional elements of

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 18 Jan 2007 11:01:01 -0800

Using unambiguous terminology does not in any way imply that we are
re-inventing the whole protocol. I think it is important to distinguish
between the two. The relation between PMIP6 and MIP6 is not exactly like
NEMO and MIP6 - NEMO is an extension of MIP6, which cannot exist without
MIP6 (so, a NEMO HA automatically implies support for MIP6). PMIP6,
OTOH, may actually be used in a system with no MIP6 or vice-versa. Also,
PMIP6 and MIP6 may be architecturally combined in a few different ways.
Let's take one example. These protocols may be deployed to provide a
two-level mobility management for a given MN, where the MIP6 CoA
mobility within a PMIP domain is handled by PMIP6 and the HoA is handled
by MIP6 - by re-using MIP6 terminology in PMIP6, the CoA in MIP6 will
become the HoA in PMIP6 and that would be very confusing.

This is not much unlike HMIP6 and MIP6 - HMIP6 is an incremental change
to MIP6, but, can be used with or without MIP6. If the MIP6 terminology
was re-used exactly in HMIP6 (without using RCoA/LCoA/MAP terminology),
it would have caused a lot of confusion, just like what seems to be the
case here. 

This is especially problematic for end users of this protocol, who are
trying to fit PMIP6 and MIP6 together in the same network. As a
protocol, PMIP6 shouldn't assume the existence or non-existence of MIP6
and it is better we have terminology that can identify whether the
specific entity/attribute is a PMIP6 one or MIP6 one. 

Again, I stress that this DOES NOT mean we are re-inventing the
protocol. It just helps with discussions and adds clarity to the
document. 

Vidya

> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
> Sent: Thursday, January 18, 2007 9:03 AM
> To: Tsirtsis, George; Kilian Weniger; [email-masked]
> I also fully agree with you. We should not re-invent entirely 
> new protocol in the name of PMIPv6.  IMHO, the success of 
> PMIPv6 will depend how much HA re-use we have achieved.. 
> I fully agree with you. The whole point of basing this work 
> on PMIP is to base the protocol on MIP i.e., PMIP should be a 
> delta on MIP, not an entirely different protocol. 
> 
> If PMIP becomes an entirely different protocol then how do we 
> expect PMIP to utilize already defined MIP extension for 
> things like support for Dual Stack, NEMO and others??
> 
> George
> 
> confusion when 
> > the fact that a major part of the entity is equivalent to a 
> HA (i.e.,
> it
> MONAMI6-capable HA, a 
> important from 
> consensus we had to
> certainly does
> considerations on 
> architecture. It 
> Gateway)

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 18 Jan 2007 15:05:55 -0500

Hi, Vidya, 

I am fine with using different terminology. However, my comment was
mostly related to maximizing the 
re-use of MIPv6 HA and allowing the support of MIPv6 and P-MIPv6
functionality by a single HA. This is 
important because of business reasons. If we can ensure that same HA can
be deployed as global as well 
as local mobility anchor then it will reduce the overall production cost
of PMIP and CMIP based mobility 
anchor and enhance deployment of MIPv6 / PMIPv6 based solution. IMHO,
this is important irrespective of 
deployment scenarios that we can envisage.    

Regards,
Ajoy  

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 1:01 PM
To: Singh Ajoy-ASINGH1; Tsirtsis, George; Kilian Weniger;
[email-masked]

Vidya

> protocol in the name of PMIPv6.  IMHO, the success of

> to base the protocol on MIP i.e., PMIP should be a delta on MIP, not 
> an entirely different protocol.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Jan 2007 13:49:29 -0800 (PST)

> become the HoA in PMIP6 and that would be very confusing.

You raise a good point about the CoA mobility with in a domain and
a need for a different term. That's one deployment model and another
is the HoA mobility with in the entire domain. So, probably its ok
to use a different term for the address that is obtained in the Proxy
Mobile Domain, as you suggest. That will remove the ambiguity and
support both the models.

PMIP6 support is an incremental change on the home agent. The same
home agent should be able to support both PMIP and CMIP nodes. That
is one design goal. A deployed PMIP-capable home agent in a local
domain can be a global home agent for some other nodes. So, its
not a mutually exclusive scenario. I'm least bothered about the
terminology, but the assumption cannot be that, both are different
protocols. Its the same MIPv6 protocol that support mobile nodes
that participate in mobility related signaling and the mobile noded
that do not participate in any mobility related signaling. Its the
same home agent that can potentially host both the types of nodes.
I like Kilian's suggestions on the terms, such as "PMIP-Capable
Home Agent", or "Local Home Agent" ... In any case, we should
converge on this faster.

Regards
Sri

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 19 Jan 2007 03:17:20 +0100

>MIP6 (so, a NEMO HA automatically implies support for MIP6). 

That's not true. NEMO is a protocol that re-use the same concept of
two-tier addressing and the same type of message exchange, but it's a
different protocol, and implementors don't have to support MIP6 in
order to support NEMO. There are 2 different protocols, and nothing in
the spec impose both MIP6 and NEMO functionalities.

> PMIP6,

>it would have caused a lot of confusion, just like what seems to be the

I don't see the problem, thinking about HMIPv6, they introduced the
RCoA and the LCoA, but those are still CoAs. You might simply need a
PCoA and PHoA ;-)

>protocol. It just helps with discussions and adds clarity to the

What would be helpful (more than helpful: should be mandated) is
inter-operability between PMIPv6 and MIP6/NEMO/HMIPv6/FMIPv6. I think
this is neeed, and for such reason a base common terminology would make
sense to me.

Thierry.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 18 Jan 2007 23:40:06 -0800

> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Thursday, January 18, 2007 6:17 PM
> To: Narayanan, Vidya
> Cc: [email-masked]; Tsirtsis, George; 
> [email-masked]; [email-masked]
> >between the two. The relation between PMIP6 and MIP6 is not exactly 
> >like NEMO and MIP6 - NEMO is an extension of MIP6, which 
> cannot exist 
> >without
> That's not true. NEMO is a protocol that re-use the same 
> concept of two-tier addressing and the same type of message 
> exchange, but it's a different protocol, and implementors 
> don't have to support MIP6 in order to support NEMO. There 
> are 2 different protocols, and nothing in the spec impose 
> both MIP6 and NEMO functionalities.
> 

I don't understand what you mean. You cannot register a prefix in
accordance with NEMO without also registering a home address. Also, in
accordance with RFC3963, "The protocol is an extension of Mobile IPv6" -
RFC3963 relaxes the requirement that the HoA must be on the home link of
the HA and says a HoA that is on any prefix served by the HA is
acceptable. Other than that, the MIP6 functionality must be supported in
a NEMO HA. 

This is not the same as PMIP6 at several levels. For one, the signaling
endpoints are different in the MIP6 and PMIP6 cases. When NEMO and MIP6
are used, the MN and HA are always the two signaling endpoints - not the
case when MIP6 and PMIP6 are used together. Secondly, it is feasible for
the MIP6 HoA or the MIP6 CoA to be served by PMIP6, transparent to the
MN. And depending on which address is served by PMIP6, the LMA (PMIP HA
as the draft calls it) may or may not be the same entity as the MIP6 HA.

> >mobility within a PMIP domain is handled by PMIP6 and the HoA is 
> >handled by MIP6 - by re-using MIP6 terminology in PMIP6, the CoA in 
> >MIP6 will become the HoA in PMIP6 and that would be very confusing.
> 
> 
> I don't see the problem, thinking about HMIPv6, they 
> introduced the RCoA and the LCoA, but those are still CoAs. 
> You might simply need a PCoA and PHoA ;-)
> 

A given MN only has one address in the context of PMIP6, unlike in
MIP6/NEMO/HMIP6 case. 

> What would be helpful (more than helpful: should be mandated) 
> is inter-operability between PMIPv6 and 
> MIP6/NEMO/HMIPv6/FMIPv6. I think this is neeed, and for such 
> reason a base common terminology would make sense to me.
> 

Agree with the interoperability need. More importantly, I would say that
PMIP6 MUST NOT disallow the use of MIP6/HMIP6/NEMO/FMIP6 in any manner
in a given network. However, MIP6, HMIP6 and FMIP6 all use different
terminology. I simply fail to see how using MIP6 terminology for PMIP6
is of any use, other than creating confusion. We really need to stop
interpreting terminology clarity to mean a totally different protocol. 

Vidya

> >> I fully agree with you. The whole point of basing this 
> work on PMIP 
> >> is to base the protocol on MIP i.e., PMIP should be a 
> delta on MIP, 
> >> > So how about PMIPv6-capable HA, or short PMIP6-HA, or 
> even shorter
> >> pHA?
> >> > 
> >> > Regards,
> >> > 
> >> > Kilian
> >> > 
> realizations 
> >> > > > > of

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 19 Jan 2007 10:05:29 +0100

>acceptable. Other than that, the MIP6 functionality must be supported in

There are still independent protocols. MCoA is an extension of MIPv6
and NEMO, you cannot implement MCoA if MIPv6 or NEMO is not
implemented. But you can implement NEMO without implementing MIPv6
(nevermind the word "extension" in RFC 3963, they are separate
protocols using the same base signaling).

>as the draft calls it) may or may not be the same entity as the MIP6 HA.

OK, but in same case it's the same entity, so it's a HA whatever the
protocol used.

>interpreting terminology clarity to mean a totally different protocol. 

OK, at least we do agree on interoperability.

(but I still like PMIPv6-enabled HA better than a new term, even tough
the protocols and the signaling are different they conceptually provide
for the same, no ?)

Thierry.

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 19 Jan 2007 11:59:37 +0100

Hi Vidya,

> become the HoA in PMIP6 and that would be very confusing.

ok, nested scenarios may cause confusion. But please note that such
multi-level mobility management scenarios are also possible with MIPv6
alone: A MN can be registered at two HAs (say HA1 and HA2) and it can
register HoA1 (associated with HA1) as CoA at HA2. HA1 could, e.g., be a
local HA. So I guess the same confusion can be caused even without PMIP.
In the context of localized MM and a nested case, the terms "local HA"
and "local HoA" may be less confusing. 

If PMIPv6 is used for localized MM, the corresponding terms could be
called "PMIPv6-HA" and "PMIPv6-HoA" (local can be omitted, since PMIPv6
is only defined for localized MM). Do you think these terms are still
ambiguous?

A potential drawback of introducing completely new terms for PMIPv6 is
IMHO that confusion may be created in the context of applying existing
MIPv6 extensions (using MIPv6 terminology) to PMIPv6 (using PMIPv6
terminology).

Regards,

Kilian