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

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

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.

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.

> (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.

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. 

> (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.

> 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.

Thanks for your comments
Sri

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 15 Mar 2007 16:53:50 -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. 

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.

> 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 
> 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 is a difference here. We are talking about using timestamp
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:

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

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.  

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.  

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 

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

Thanks for your comments
Sri