Subject: Re: Concluding this thread (RE: [netlmm] MN-Id overspecification)

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Oct 2007 19:27:33 +0300

FWIW, I also did not see very convincing reasons why there
would be a need to avoid having the identity in every signaling
message. Or vice versa. But in general, you SHOULD attempt to
identify the parties involved in the transactions as uniquely and
consistently as possible. And simplicity is a good thing, so I
don't see the identifiers appearing in every message as a bad
thing. Please pay attention to what implementations have to do
to locate cache entries based on multiple identifiers, that various
nodes may reboot and lose state, etc.

However, the discussion also prompted me to think about
feature interactions and the way that you use existing
options. When the NETLMM specification uses option X
for some purpose, you need to be careful about not
breaking some other feature that uses X. Case in point,
RFC 4283 identifier options. Please consider using
a new option or at least a distinct subtype if there's
a danger that RFC 4285 implementations would mis-interprete
the NETLMM use of these options in some manner.

Jari

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 3 Oct 2007 10:10:20 -0700 (PDT)

Hi Jari,

> the NETLMM use of these options in some manner.

Ok. We will try to define a new identifier sub-type for a
proxy entity (MAG). This should help Alper's goal as well.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 3 Oct 2007 10:13:46 -0700 (PDT)

> proxy entity (MAG). This should help Alper's goal as well.

Typo ..

I meant, they can try to define a new identifier subtype .. the
identifier we carry is still MN's identifier and not the MAG
identifier. When used with 4285, the id has to be the MAG's id.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Oct 2007 20:37:28 +0300

> identifier. When used with 4285, the id has to be the MAG's id.

Right. But all I'm saying is that you have to think about this.
The above is a fine plan, but note that the new ID type would
probably then be in a new RFC, not the base. If you decide to
use a new option for the client identifier instead, then that
would be in the base. In either case, I'd like to know what
the plan is so that we know there is no harmful interaction.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 3 Oct 2007 10:47:35 -0700 (PDT)

> the plan is so that we know there is no harmful interaction.

We can define a new type, but the problem we see is that, the
4283 defines a identifier of a MN and that's exactly what we
are using for. If we have to define a new type, its still a
MN identifier, but used by a MAG. This is looking bit odd. But,
we can do this as well.

I think, the other question that needs clarification is, can
PMIP6 messages carry any option that is defined for MIP6 and
with out any text that guides the usage in the PMIP6 context.
Ex: NEMO MNP, Auth Option ...etc. I'd think, we may to have
requalify each option for use in PMIP6 and that applies to
Auth Option as well. But, if the idea is that we dont need
further guidance on usage of MIP6 options in PMIP6 context,
then we need to make sure, we are not breaking other protocols.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Oct 2007 11:17:49 -0700

> identifier. When used with 4285, the id has to be the MAG's id.

We are not going to define a MAG identifier in the base PMIPv6 
specification. For using IKEv2 and IPsec between the MAG and the LMA, 
the MAG identity is exchanged as part of the IKEv2 exchange. After that 
the LMA only needs the IP address of the MAG.

As I understand it, the MAG identifier is needed when RFC 4285 is used 
between the MAG and the LMA. That needs to be defined in a separate 
document.

Vijay

---

From: "Muhanna, Ahmad (RICH1:2H10)" <[email-masked]>
Date: Wed, 3 Oct 2007 14:30:08 -0500

> We are not going to define a MAG identifier in the base 
> PMIPv6 specification. For using IKEv2 and IPsec between the 
> MAG and the LMA, the MAG identity is exchanged as part of the 
> IKEv2 exchange. After that the LMA only needs the IP address 
> of the MAG.
> 
> As I understand it, the MAG identifier is needed when RFC 
> 4285 is used between the MAG and the LMA. That needs to be 
> defined in a separate document.

[Ahmad]
Yes. I agree.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 3 Oct 2007 12:56:45 -0700

Hi Jari,
While we can certainly define a new option, I'm not sure I see the need
for it.  There is no restriction in RFC4283 that it is meant to be used
only for RFC4285, as far as I can tell.  I would think that the point of
defining that in a separate RFC is so that multiple uses can be made for
that defined mobility option.  It seems odd that we'll define a new
option that carries the same kind of data for NETLMM use.  

OTOH, I also don't see it stepping on the boundaries of RFC4285 usage.
I'd think if RFC4285 were to be applied for PMIP, we'd have to define a
MAG-ID subtype for RFC4283 to carry that, no? 

Thanks,
Vidya 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 9:28 AM
> To: Alper Yegin; Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: Concluding this thread (RE: [netlmm] MN-Id 
> overspecification)
> 
> 
> would be a need to avoid having the identity in every 
> signaling message. Or vice versa. But in general, you SHOULD 
> attempt to identify the parties involved in the transactions 
> as uniquely and consistently as possible. And simplicity is a 
> good thing, so I don't see the identifiers appearing in every 
> message as a bad thing. Please pay attention to what 
> implementations have to do to locate cache entries based on 
> multiple identifiers, that various nodes may reboot and lose 
> state, etc.
> 
> options. When the NETLMM specification uses option X for some 
> purpose, you need to be careful about not breaking some other 
> feature that uses X. Case in point, RFC 4283 identifier 
> options. Please consider using a new option or at least a 
> distinct subtype if there's a danger that RFC 4285 
> implementations would mis-interprete the NETLMM use of these 
> options in some manner.
> 
> Jari
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Oct 2007 18:54:04 -0700

Narayanan, Vidya wrote:
> only for RFC4285, as far as I can tell.  

True, there is no such restriction. In fact 4283 is a Proposed Standard.

Vijay

I would think that the point of

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 4 Oct 2007 10:08:05 +0300

Jari,

> nodes may reboot and lose state, etc.

Actually I'm fine with carrying NAI in all messages.

The issue is with the bits we stuff in that NAI.

If we don't always require the bits to represent the physical MN that
attaches to the MAG, that solves the problem.
As we understand, that requirement is necessary/useful only when we are
attempting to assign HNP in-band with PBU.

So, if a deployment wants to carry some identifier of the MN in the NAI,
that's fine. And if another deployment wants to carry some other identifier
(e.g., that of MAG as it is the proxy-MN) that should be fine too.

My recommendation is for the spec to not get into the specifics of what
value is carried inside that NAI. Actually the spec is failing to do a
proper job on NAI specifics, but it is giving hints that are causing
trouble. 

Only in the context of HNP assignment the spec should be talking about how
the bits in the NAI may have to be correlated to the identity of the MN by
the policy profile.

> the NETLMM use of these options in some manner.

I think that'd do as well. PMIP6 should click-in with the rest of MIP6
family protocols. We shouldn't have to go back and start writing new RFCs
and updating existing ones with the introduction of PMIP6, unless absolutely
necessary. I think handling the issue within PMIP6 "I-D" is the right way.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Oct 2007 14:14:25 +0300

> that defined mobility option. 

Yes, but realistically, the only current use of RFC 4283 is in the
context of RFC 4285 implementations, no? Whether or not the
RFCs are separate, I think there's a potential problem for
RFC 4285.

>  It seems odd that we'll define a new

I think so.

All I'm asking is that you have a plan about
this. I don't want you to design how RFC 4285 works
in NETLMM in the base spec.

But similarly for every other feature that you might have
interaction with -- make sure we understand the
implications and have a plan about what to do about
it.

In any case, everyone seems to agree that we need
a new identifier type for MAG, and that can be done
in a new RFC, later. Lets move forward with that.

Jari