Subject: RE: [netlmm] FW: comments to Sri's draft

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 15 Mar 2007 16:55:32 -0400

Hi, Sri, 

Thanks for responding. I would like to make it very clear that ideas
presented in draft-sgudnave and draft-singh are complementary and must
co-exist. I want that we should recognize this and consider ideas from
both drafts to define complete
PMIPv6 solution.  We should recognize each others viewpoint rather than
getting into endless debate. 
Also, please find inline comments. 

Regards,
Ajoy  

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]]
Sent: Thursday, March 15, 2007 2:47 PM
To: Singh Ajoy-ASINGH1; 'JinHyeock Choi'
Cc: 'Heejin Jang'; [email-masked]
Subject: FW: [netlmm] FW: comments to Sri's draft

Ajoy,

Please see inline ..

> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Thursday, March 15, 2007 11:44 AM
> To: Sri Gundavelli; JinHyeock Choi
> Cc: Heejin Jang; [email-masked]
> Subject: RE: [netlmm] FW: comments to Sri's draft
> 
> Sir,
> 
> Sorry for jumping in the middle of discussion. 

You are most welcome.

> Please find few inline comments. 
> 
> Regards,
> Ajoy
> 
> 
> MAG is a functional element. we did not state, how to break that 
> function, that is specific to the architecture. There is no single 
> requirement from all SDO's suggesting a specific model and so there is

> no single way to break that function and its better if the solution 
> from IETF stays generic and leaves that to the specific SDO's.
> This functional separation, has no bearing on the core Proxy Mobile
> IPv6 operation. In the simplest model, there could be a part of the 
> MAG function, a control element, that detects a mobile node on the 
> access link and sends a simple event to the MAG to perform the 
> registration and set up the data path. That's one way of functional 
> separation and where only part of the control function is on the 
> Access Router and the part of the function is outside the Access 
> Router. In another model, the using the Alt-CoA option, the tunnel can

> be terminated on a different entity, thus keeping the control and data

> paths separate and again this has no bearing on the Proxy Mobile IPv6 
> protocol, addressing model or the any of the core aspects of the 
> protocol. This is orthogonal to the base protocol.
> 
> 
> Ajoy-> There are implications on protocol behavior. If you allow PMIP
> anchoring we
> will see following modifications to protocol behavior: 
> (1) There will be NO NEED of BU timestamp extension

Well. I saw lot of comments from you against the usage of Timestamp
option.. I thought, now you wanted to use the same time stamp option,
for the issue Jin raised against your draft, for establishing ordering
of the TRIGGER messages from multiple MAGS. But, its a good decision. 

Ajoy-> There is a difference here. We are talking about using timestamp 
Ajoy-> or any other
field in a light-weight protocol that runs between MAG and PMIP client.
We are not proposing to modify the behavior of MIPv6 unlike
draft-sguadve. Since this a new protocol, not much re-use can be
achieved anyway. However, it is likely that SDOs will have their own
protocol / interface defined MAG and PMIP client entity so there won't
be any need to use this protocol.  

When multiple senders are involved, as we say in the draft, you need a
global scale and TimeStamp is the best option. I dont agree all your
arguments against the use of timestamp, we have been using it in Mobile
IPv4 and we adopted the same in Auth Option support (for replay
protection) and there is no deployment evidence that suggests that the
usage of timestamp is a bad idea. And certainly, we can avoid timestamps
and as Julien suggested, we can solve that, but it requires an extra
round trip.
And, we can also avoid time stamps, in the presence of the context
transfer procedures. In any case, this is a trivial issue and we will
allow more than one way.

Couple of points:

1. Mobile IPv4 uses Timestamp option and deployments do not suggest that
its a bad idea.

2. RFC-4285 uses the Timestamp option for replay protection.

3. We can avoid time stamp using other ways, LMA returning the suggested
timestamp..etc.

Ajoy-> Btw, my comment was mostly related with re-use aspect of
Home Agent which is important consideration for PMIPv6 solution. 

> (2) There will be no need for LMA to authorize MAG during every
> inter-MAG handoff.  

LMA can download the policy and once, that states what MAG's are
authorized to send PBU's. Its a basic roaming policy check, I dont
understand what is the issue. The IPSec session between the LMA and
the MAG's need to be established once, why does it need to do for
each mobile node's handoff ? When a PBU comes from a MAG, the LMA
checks, if the MAG is allowed to that operation. Its a simple ACL
check. Today, we do that in Mobile IPv4. The home agent checks the
what all foreign agents are allowed to send RRQ's and here we check,
what all MAG's are allowed to send the PBU's.

Ajoy-> I am not sure this works though. It is impossible for any LMA to
know 
all the MAGs from where mobile node can try to get PMIP service without
going through 
AAA interaction. How will LMA know what are the potential MAGS in all
the access networks from 
where mobile will try to access service? You have rightly suggested in
draft that AAA interaction will 
be required for authorization of MAG. My concern is that it will be very
expensive handoff signaling 
if we have to do AAA interaction during handoff.  

How does your PMIP client authorize the MAGs ? Instead of the LMA,
your PMIP client need to authorise the MAG's each time the mobile
moves. You just defer the problem to PMIP client and also that can
be the single point of failure. 

Ajoy-> PMIP client will be co-located on the node that will have
wireless specific functionality (e.g., MME) as well. 
So, PMIP client will have link layer authorization already in place for
link layer processing so there will no need 
to perform extra authorization for PMIP specific operation.  Although we
have 
not defined in draft-singh framework, it is possible that PMIP client
will initiate tunnel procedure after 
receiving radio signaling messages (e.g., l2 trigger) thereby not even
requiring any explicit signaling from MAG.  
Please note that I do see place for both drafts: draft-sgudave is useful
when we have to relocate PMIP client 
whereas draft-singh is useful where PMIP client anchoring can be
achieved.  

> (3) Most of PMIPv6 specific changes proposed to MIPv6 HA will be
> eliminated thereby 
>  hugely simplify PMIP protocol design. This is so because standalone
> PMIP client makes 
>  PMIPv6 protocol semantically similar to client MIPv6 protocol. 
> 

Its not the WG's charter, not to change the Home Agent implementation.
For supporting Proxy Model, there will be changes in the Home Agent,
that's the stated assumption and its inline with the WG charter. Check
what was said by Jari in the SD meeting. Even though the changes are
minimal, I'll not argue with you on that. There will be changes for
supporting this solution and AFAIK, no customer is intending to deploy
PMIP from off the shelf components. 

Ajoy-> HA re-use was one of the reasons why PMIP was preferred over
NETLMM DT draft. 
So, maximizing reuse is a good thing not a bad thing. I am quoting you
something from 
SD meeting that you might find relevant here: 
http://www3.ietf.org/proceedings/06nov/slides/netlmm-0/netlmm-0.ppt#277,
6,3GPP2 

> IMO, this is a key concept and should not be left to SDOs. 
> 

All thought we managed to get some attention from some, its orthogonal
to the problem we are solving. How I break the PMA/MAG is specific to
an architecture and draft-sgundave do not disallow that. The draft
stays neutral and keeps the flexibility to be adopted to multiple
architectures and that's our design goal.

Ajoy-> It is very important to keep open mind and hear about others'
view point
as well.  

Thanks for your comments
Sri

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 15:09:37 -0700

Hi Ajoy,

Thanks for your message. Let me respond to your comment
just once and hope this helps. 

The drafts are not complementary, there is a clear overlap
and with one minor deviation of functional split of the MAG
and that we do not want to specify and the messaging for the
same functional split in draft-singh evolved very recently,
after some one pointed that out. We did not want to specify
the same functional split for the following reasons:

- Introduces a single point of failure
- Restricts the protocol to a specific SDO architecture
- Removes the generality from the protocol, that IETF strives
  for in its protocol designs
- Does not belong to the base spec

And, draft-sgundave does allow the functional split, we
envision the split in more than one way and if we need be,
we will specify that in extension docs, specific to each
SDO architecture.

- A simple trigger from a control element after detecting
  mobile node on the access link.
- Use of Alt-CoA option for terminating the data path
  on a different entity
- Other ways, including signaling between the split entities

The key difference is the amount of finer details that are
present in draft-sgundave, the amount of review and scrutiny,
many mailing list discussions, most importantly a working
implementation. We think, its a fairly complete document
and can form the basis and can be improved to meet the WG
consensus. Any case, let the WG decide the single document
for adoption.

Regards
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 1:56 PM
To: Singh Ajoy-ASINGH1; Sri Gundavelli; JinHyeock Choi
Cc: Heejin Jang; [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

Hi, Sri, 

Regards,
Ajoy  

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]]
Sent: Thursday, March 15, 2007 2:47 PM
To: Singh Ajoy-ASINGH1; 'JinHyeock Choi'
Cc: 'Heejin Jang'; [email-masked]
Subject: FW: [netlmm] FW: comments to Sri's draft

Ajoy,

Please see inline ..

You are most welcome.

Couple of points:

Thanks for your comments
Sri

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 15 Mar 2007 19:00:48 -0400

Hi, Sri, 

Please find inline replies.  

Regards,
Ajoy  

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 5:10 PM
To: Singh Ajoy-ASINGH1; 'JinHyeock Choi'
Cc: 'Heejin Jang'; [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

Hi Ajoy,

Thanks for your message. Let me respond to your comment just once and
hope this helps. 

Ajoy-> OK 

The drafts are not complementary, there is a clear overlap and with one
minor deviation of functional split of the MAG and that we do not want
to specify and the 
messaging for the same functional split in draft-singh evolved very
recently, after some one pointed that out. 

Ajoy-> Please refer to the draft that we had submitted prior to Dallas
IETF meeting: 
http://tools.ietf.org/wg/netlmm/draft-raman-netlmm-protocol-00.txt. 
This draft defines functional split between MAG (AR) and PMIP 
client.  Perhaps you do not remember now, we had informal discussion
about this during 
Dallas IETF meeting. 

We did not want to specify the same functional split for the following
reasons:

Ajoy-> Let us not get into single point of failure argument. Note that
PMIP client anchoring only means that PMIP client is 
anchored for the duration of the data session. This does not mean there
will have only one PMIP client in access network. 
This function can be co-located on MAG and the first MAG where MN
attaches can become the PMIP anchor for 
mobile node. So, I do not see single point of failure is a problem here.
Also, even in the scenario where 
PMIP client is anchored on a centralized node, we are NOT suggesting any
new boxes for this feature. 
PMIP client will be implemented on an existing box of radio access
network that supports high availability.   
  
 Restricts the protocol to a specific SDO architecture
- Removes the generality from the protocol, that IETF strives
  for in its protocol designs
- Does not belong to the base spec

Ajoy-> I am not sure adding this functionality to PMIP protocol will
limit its applicability to any 
SDO. The concept of data plane and control plane separation is being
discussed in every SDOs that I am aware of.  
We just need to socialize the idea to various SDOs to make sure that
benefits of this idea is obvious from PMIP perspective. 
Unless this is done, it is very tempting to consider an use case that
requires relocation of PMIP client. 

And, draft-sgundave does allow the functional split, we envision the
split in more than one way and if we need be, we will specify that in
extension docs, specific to each SDO architecture.

Ajoy-> It is good to hear that you are recognizing the benefit of
functional split. I will like to have face to face meeting with you and
other co-authors
of your draft to discuss this idea in some detail in Prague meeting.
Hopefully we can discuss this before NETLMM meeting. 

The key difference is the amount of finer details that are present in
draft-sgundave, the amount of review and scrutiny, many mailing list
discussions, most importantly a working implementation. We think, its a
fairly complete document and can form the basis and can be improved to
meet the WG consensus. Any case, let the WG decide the single document
for adoption.

Regards
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 15, 2007 1:56 PM
To: Singh Ajoy-ASINGH1; Sri Gundavelli; JinHyeock Choi
Cc: Heejin Jang; [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

Hi, Sri, 

Regards,
Ajoy  

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]]
Sent: Thursday, March 15, 2007 2:47 PM
To: Singh Ajoy-ASINGH1; 'JinHyeock Choi'
Cc: 'Heejin Jang'; [email-masked]
Subject: FW: [netlmm] FW: comments to Sri's draft

Ajoy,

Please see inline ..

You are most welcome.

Couple of points:

LMA can download the policy and once, that states what MAG's are
authorized to send PBU's. Its a basic roaming policy check, I dont
understand what is the issue. The IPSec session between the LMA and the
MAG's need to be established once, why does it need to do for each
mobile node's handoff ? When a PBU comes from a MAG, the LMA checks, if
the MAG is allowed to that operation. Its a simple ACL check. Today, we
do that in Mobile IPv4. The home agent checks the what all foreign
agents are allowed to send RRQ's and here we check, what all MAG's are
allowed to send the PBU's.

Ajoy-> I am not sure this works though. It is impossible for any LMA to
know
all the MAGs from where mobile node can try to get PMIP service without
going through AAA interaction. How will LMA know what are the potential
MAGS in all the access networks from where mobile will try to access
service? You have rightly suggested in draft that AAA interaction will
be required for authorization of MAG. My concern is that it will be very
expensive handoff signaling if we have to do AAA interaction during
handoff.  

How does your PMIP client authorize the MAGs ? Instead of the LMA, your
PMIP client need to authorise the MAG's each time the mobile moves. You
just defer the problem to PMIP client and also that can be the single
point of failure. 

Ajoy-> PMIP client will be co-located on the node that will have
wireless specific functionality (e.g., MME) as well. 
So, PMIP client will have link layer authorization already in place for
link layer processing so there will no need to perform extra
authorization for PMIP specific operation.  Although we have not defined
in draft-singh framework, it is possible that PMIP client will initiate
tunnel procedure after receiving radio signaling messages (e.g., l2
trigger) thereby not even requiring any explicit signaling from MAG.  
Please note that I do see place for both drafts: draft-sgudave is useful
when we have to relocate PMIP client whereas draft-singh is useful where
PMIP client anchoring can be achieved.  

> eliminated thereby  hugely simplify PMIP protocol design. This is so 
> because standalone PMIP client makes

Ajoy-> HA re-use was one of the reasons why PMIP was preferred over
NETLMM DT draft. 
So, maximizing reuse is a good thing not a bad thing. I am quoting you
something from SD meeting that you might find relevant here: 
http://www3.ietf.org/proceedings/06nov/slides/netlmm-0/netlmm-0.ppt#277,
6,3GPP2 

Thanks for your comments
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2007 00:06:53 +0100

Hi Sri, let me offer a viewpoint here, if you wish to read it, thanks.

Sri Gundavelli wrote:
> The drafts are not complementary, there is a clear overlap and with 
> one minor deviation of functional split of the MAG and that we do not
>  want to specify and the messaging for the same functional split in 
> draft-singh evolved very recently, after some one pointed that out. 
> We did not want to specify the same functional split for the 
> following reasons:
> 

Yes, looks so.  A PMIP Client that is separated from all  other MAGs
looks indeed as a single point of failure.  We must take care not making 
it so.

At the same time, I think there already is a single point of failure in
draft-sgundave.  I think draft-sgundave only allows for one MAG for a
stationary MN (but please correct me if I'm wrong).

> - Restricts the protocol to a specific SDO architecture

Isn't all this SDO?

> - Removes the generality from the protocol, that IETF strives for in
>  its protocol designs

General protocol, yes.  But a big document can't be as general as a
small one, I think you agree.

> - Does not belong to the base spec

Questionable.

>  split in more than one way and if we need be, we will specify that
> in extension docs, specific to each SDO architecture.
> 
> - A simple trigger from a control element after detecting mobile node
>  on the access link. - Use of Alt-CoA option for terminating the data
>  path on a different entity - Other ways, including signaling between
>  the split entities

I think I agree with you that _some_ features from draft-singh are
indeed needed, but I see problems if we consider them as extensions.

For example, if draft-singh requires TRIGGER message to be a
SCTP-transported signal, but your base sgundave only does Mobility
Header then there's a big problem.  There's no longer this
base-extension relationship, it's Mars and Venus.

And arguments on SCTP or MH being better than other aren't that clear
either.  If the  base left place for signalling with something else than
MH, then it could go, IMHO.  But you seem keen on keeping every other
feature that is in draft-sgundave, MH included.

>  draft-sgundave,

Yes, I completely agree, the draft is very detailed.  I went through it
searching for semantics related to PMIP Client Relocation.

However, sometimes:
-the draft reads as duplicating its own text from other section.
-sometimes uses 'tunnel identifiers' and 'fat tunnels' at the same
  time.
-sometimes relies on NTP working ok.
-assumes that a 'user-profile' contains the home prefix.  Without it the
  protocol doesn't work.  AFAIK there's no precise definition of the
  user-profile, no RFC; some of the 'user-profiles' I play with don't
  use prefixes, but full addresses.

With these features, that are indeed there in draft-sgundave, one can
indeed claim that the protocol has indeed a large amount of finer
details.  But not all these details are needed in a base, IMHO.

IMHO, this is a large departure than what Mobile IPv6 is.  If you wish I
can try to find out in draft-sgundave which are the precise features
that are not in MIPv6, and features in MIPv6 that are not in P-MIPv6.

I think a firm base should have much less features than draft-sgundave.
  But you'll disagree, I know.

> the amount of review and scrutiny, many mailing list discussions, 
> most importantly a working implementation.

I think this is a document very difficult to read for an implementer, IMHO.

> We think, its a fairly complete document and can form the basis and 
> can be improved to meet the WG consensus. Any case, let the WG decide
>  the single document for adoption.

Sri, I agree with you on WG deciding the single document for adoption.
But that's pretty clear already, isn't it.

Sorry, I won't insist.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 16:22:11 -0700

> We just need to socialize the idea to various SDOs to 
> make sure that benefits of this idea is obvious from PMIP
> perspective. 

Hi Alex and Ajoy,

I respect your view points. Its my word against your word
and dont see any signs of convergence. I dont believe in
going to SDO's to socialize our draft ideas. Like I said,
nothing stops an SDO to take this spec and split the
functionality the way they wanted, but we dont believe in
dictating a specific method of functional split. Any case,
let the WG decide on the doc and the approach, and can move
forward.

Also, Alex, I know you have lot of comments on the draft
and probably not Ok with any part of it. But, that's the
best we could do and we will try to improve it, after the
document adoption, if its chosen, to adopt the WG decisions
as per the consensus.

See you guys in Prague.

Best Regards
Sri

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 4:07 PM
To: Sri Gundavelli
Cc: 'Singh Ajoy-ASINGH1'; 'JinHyeock Choi'; 'Heejin Jang'; [email-masked]
Subject: Re: [netlmm] FW: comments to Sri's draft

Isn't all this SDO?

Questionable.

However, sometimes:

Sorry, I won't insist.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2007 00:37:44 +0100

Sri Gundavelli wrote:
> 
>> We just need to socialize the idea to various SDOs to make sure 
>> that benefits of this idea is obvious from PMIP perspective.
> 
> 
> Hi Alex and Ajoy,
> 
> I respect your view points. Its my word against your word and dont 
> see any signs of convergence.

Sri, I think I'm doing my best to find points of covergence, and I will
continue to do so.  But please be open to those convergence questions,
please.

If I'm saying that draft-sgundave assumes a profile to contain the home
network _prefix_, not address, could you please comment on this
particular thing.  What's the implementation guidance to have such a
profile.

> I dont believe in going to SDO's to socialize our draft ideas. Like I
>  said, nothing stops an SDO to take this spec and split the 
> functionality the way they wanted,

If we try to split it here and we can't, it means SDO won't be able either.

> but we dont believe in dictating a specific method of functional 
> split.

Ok.  We're not dictating separation based on forward/control split.
That's for network processors and we don't build distributed network
processors here.

But it looks as a good idea, to at least one SDO, to have that PMIP
Client on a separate machine than the AR.  And I think you agree, but
don't seem willing to agree.

I think to you it looks also as a good idea.  Because draft-sgundave 
mentions in only one place 'data path'.  Not sure who wrote that, but 
that co-author thought in terms of forwarding/control split.

> Any case, let the WG decide on the doc and the approach, and can move
> forward.

Yes, let's convince the WG.  I'm open to discuss any remark from the WG, 
on this PMIP Client separation.

> Also, Alex, I know you have lot of comments on the draft and probably
>  not Ok with any part of it. But, that's the best we could do and we
>  will try to improve it, after the document adoption, if its chosen,
>  to adopt the WG decisions as per the consensus.

Sri, as I said earlier.  I'm very happy with the way you managed to 
integrate comments, at least from myself - thanks.  I noticed in detail 
that fine grain detail of the draft that you mention.  I have a list of 
improvement comments, typos, small incoherencies, etc.  I know you did 
your best.  Can you then find points of convergence?

Alex

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 16 Mar 2007 00:33:04 -0400

Ajoy,

I have seen your comments on having a separate entity (aka PMIP Client)
outside the AR that controls the PMIP process. It seems to be the only
salient feature in draft-singh.

AFAIK, there need to be some events and triggers in the network which
need to be propagated to this PMIP Client. The triggers like: RS, DHCP,
IPv6CP are received at the AR. Hence, these triggers need to be
propagated to the PMIP Client outside the AR to initiate the PMIP6
process. This seems to be a convoluted way to do PMIP. 

If there is no PMIP Client, the MAG in the AR could send PBU w/o having
to propagate the triggers to a third party. 

-Kuntal

> Sent: Thursday, March 15, 2007 6:01 PM
one
> understand what is the issue. The IPSec session between the LMA and
the
> How does your PMIP client authorize the MAGs ? Instead of the LMA,
your

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 16 Mar 2007 00:57:08 -0400

Kuntal, 

Please read the draft and various discussion that have taken place on
the list so far. 
Standalone PMIP client is ONE of the features of draft-singh. You do not
need to propagate 
any of these messages (RS, DHCP, IPv6CP) to PMIP client. Rather
draft-singh defines
a light weight protocol (TRIGGER and NOTIFICATION) message between MAG
and PMIP client that can used for this purpose. 
You can also use SDO specific protocol if you like. Also, see the
benefits that standalone client provides over client relocation. 
Sri and I had extensive discussion on the list that you can follow. 

Regards,
Ajoy  

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 11:33 PM
To: Singh Ajoy-ASINGH1; Sri Gundavelli; JinHyeock Choi
Cc: Heejin Jang; [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

Ajoy,

-Kuntal

one

> to specify and the messaging for the same functional split in 
> This draft defines functional split between MAG (AR) and PMIP client.

> Perhaps you do not remember now, we had informal discussion about this

> during Dallas IETF meeting.
> 
> PMIP client anchoring only means that PMIP client is anchored for the 
> duration of the data session. This does not mean
there
> attaches can become the PMIP anchor for mobile node. So, I do not see 
> single point of failure is a problem
here.

the

your

---

From: Christophe Janneteau <[email-masked]>
Date: Fri, 16 Mar 2007 10:04:25 +0100

Kuntal,

If I may had an additional point to Ajoy's comment below:

One key advantage of the AR-PMIP Client lightweight protocol defined in
draft-singh is that it allows implementing the overall netlmm function
without requiring any modification to standard MIPv6 signaling and HA.
This lightweight protocol is used to trigger the PMIP Client (running
standard RFC3775 MN function) for sending BU to the LMA/HA.

I see this as a key advantage for easing deployment, especially in
network that already run a MIPv6 service.

This is not offered by draft-sgundave IMHO.

Christophe

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 16 Mar 2007 12:27:47 -0400

> Sent: Thursday, March 15, 2007 11:57 PM
> To: Chowdhury, Kuntal; Sri Gundavelli; JinHyeock Choi

[KC>] That's exactly what I am pointing out. In your call flows, you
show that the MN is performing various IP address config procedures
(RS/RA, DHCP) all of which are passing through the MAG. Even though, the
MAG is aware of the pHoA assignment, it has to outsource the PMIP
operation (PBU) using additional/new messages (trigger) to a third party
called PMIP Client. This is what I am referring to as convoluted way to
do PMIP.

> Sri and I had extensive discussion on the list that you can follow.

[KC>] Well, we need to first be convinced why PMIP client is absolutely
needed in the base PMIP protocol operation before we can talk about
which protocol(s) should be used to propagate triggers from network
nodes to the PMIP Client.
 
> > This draft defines functional split between MAG (AR) and PMIP
client.
> > We did not want to specify the same functional split for the
following
> > split in more than one way and if we need be, we will specify that
in
> > discussions, most importantly a working implementation. We think,
its
> a
> > > requirement from all SDO's suggesting a specific model and so
there
> is

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 16 Mar 2007 12:42:00 -0400

Well, I think there were enough arguments made to justify why standalone
PMIP client is a better idea. 
I can list few for your benefits in case you missed these discussion.
Simply from re-use point of view it provides you better re-use of 
MIPv6 HA functionality. It also eliminates the 
need for AAA based MAG authorization during inter-MAG handoff which is
important for seamless handoff. You can not expect to 
do all these signaling in critical path of handoff and still achieve
seamless handoff for real time session. 
I believe handoff delay is one the key requirements of NETLMM WG.  

Regards,
Ajoy    

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 11:28 AM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

> draft-singh defines a light weight protocol (TRIGGER and NOTIFICATION)

> message between MAG and PMIP client that can used for this purpose.

 

client.
following

in

its

there

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 16 Mar 2007 12:50:44 -0400

> From: Christophe Janneteau [mailto:[email-masked]]
> Sent: Friday, March 16, 2007 4:04 AM
> To: Singh Ajoy-ASINGH1
> Cc: Chowdhury, Kuntal; Sri Gundavelli; JinHyeock Choi; Heejin Jang;
> [email-masked]
> Subject: Re: [netlmm] FW: comments to Sri's draft (& advantage of
draft-
> singh)
[KC>] I don't think this is a major/key advantage. The SA requirement
for MIP6 and PMIP6 are clearly different. 

> network that already run a MIPv6 service.
[KC>] I am not aware of any large scale deployment of MIP6.

> This is not offered by draft-sgundave IMHO.
[KC>] I think you are talking about per MN SA as per RFC 3775. I don't
think it is impossible to run per MN SA (IKEv2/IPsec SA per MN) between
MAG and the LMA, but it makes little sense, IMHO.

client.
following
> >> PMIP client is anchored on a centralized node, we are NOT
suggesting
> > any
that
in
its
there
> >> mobile node's handoff ? When a PBU comes from a MAG, the LMA
checks,
> > if
> >> the MAG is allowed to that operation. Its a simple ACL check.
Today,
> > we
> >> Ajoy-> I am not sure this works though. It is impossible for any
LMA
> > to

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 16 Mar 2007 13:25:53 -0400

> Sent: Friday, March 16, 2007 11:42 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> MIPv6 HA functionality. 

[KC>] reuse != 100% reuse. It means reuse whatever makes sense.
Draft-sgundave does exactly that.

> It also eliminates the
[KC>] seamless (inter AR/MAG) handover using context transfer was
discussed in San Diego. Based on the comments in that meeting, it was
the assumption that context transfer should be taken up outside of the
base protocol. There are already some I-Ds posted to do that.

suggesting
that
> > > functional split. I will like to have face to face meeting with
you
> > and
> > > fairly complete document and can form the basis and can be
improved
> > > > Router. In another model, the using the Alt-CoA option, the
tunnel
> > can
> > >
> > > > be terminated on a different entity, thus keeping the control
and
> > data
> > > When multiple senders are involved, as we say in the draft, you
need
> > > 1. Mobile IPv4 uses Timestamp option and deployments do not
suggest
checks,
Today,
LMA
> > > be required for authorization of MAG. My concern is that it will
be
> > very
> > > PMIP client need to authorise the MAG's each time the mobile
moves.
> > You
> > > So, PMIP client will have link layer authorization already in
place
> > for
> > > > eliminated thereby  hugely simplify PMIP protocol design. This
is
> so

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 16 Mar 2007 13:52:59 -0400

Kuntal, 

Please find inline. 

Regards,
Ajoy 

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 12:26 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

 
Ajoy-> When re-use is a consideration more and more re-use is better. 
I am surprised to see that you are changing your gear. I thought 
you belonged to per MN-security SA and complete re-use of MIPv6 HA
functionality. 
I think we should definitely discuss this in person in Prague. When are
you 
planning to be in Prague? 

> important for seamless handoff.  You can not expect to do all these 
> signaling in critical path of handoff and still achieve seamless 
> handoff for real time session.

Ajoy-> Security context transfer is last thing you want to do. Security
context transfer has been previously discussed in 
IETF and  discarded. I am not sure if it is still being discussed in
some WG in IETF though. IMO, folks are talking about other context
transfer such as 
QoS, header compression (?) etc.
 
suggesting

that
you
improved

tunnel
and

need

suggest

checks,
Today,

LMA
be
moves.
place

is