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

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

Kuntal, 

Please find inline. 

Regards,
Ajoy 

> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Friday, March 16, 2007 11:42 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: RE: [netlmm] FW: comments to Sri's draft
> 
> 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. 

[KC>] reuse != 100% reuse. It means reuse whatever makes sense.
Draft-sgundave does exactly that.
 
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 the camp of 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? 

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

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.
 
> 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
> 
> 
> 
> > -----Original Message-----
> > From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> > Sent: Thursday, March 15, 2007 11:57 PM
> > To: Chowdhury, Kuntal; Sri Gundavelli; JinHyeock Choi
> > Cc: Heejin Jang; [email-masked]
> > Subject: RE: [netlmm] FW: comments to Sri's draft
> >
> > 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.
> 
> [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.
> 
> 
> > 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.
> >
> 
> [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.
> 
> > 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,
> >
> > 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
> >
> >
> > > -----Original Message-----
> > > From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> > > Sent: Thursday, March 15, 2007 6:01 PM
> > > To: Sri Gundavelli; JinHyeock Choi
> > > Cc: Heejin Jang; [email-masked]
> > > Subject: RE: [netlmm] FW: comments to Sri's draft
> > >
> > > 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:
> > >
> > > - Introduces a single point of failure
> > >
> > > 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.
> > >
> > > - 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
> > >
> > > 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,
> > >
> > > 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
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

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

---

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

Ajoy,

Please see inline...

-Kuntal

> Sent: Friday, March 16, 2007 12:57 PM
> To: Singh Ajoy-ASINGH1; Chowdhury, Kuntal
> Cc: [email-masked]
[KC>] I have always supported reuse and I continue to do so. That's the
main reason I supported PMIP6 for network based mobility management.
While reuse is the noble goal, we should also be pragmatic about it.
Some amount of delta is fine as long as it makes sense. Yes, I will be
Prague and we can chat about it more in person if you like. 

> QoS, header compression (?) etc.
[KC>] In the per-node SA model, there is no need to transfer security
context between the MAGs. Other context transfers like the one you cited
are possible and they are good to have, but we should not mandate
anything like that in the PMIP6 base protocol.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2007 21:28:08 +0100

Chowdhury, Kuntal wrote:
[...]
[...]
>  context between the MAGs.

Right.  It's re-authentication all the way to HA (and eventually AAA 
Server) upon each handover.  There may be an RO problem statement.

> Other context transfers like the one you cited are possible and they
> are good to have, but we should not mandate anything like that in the
> PMIP6 base protocol.

No CT between MAGs for the moment - I agree.

But an entity closer to MAGs, closer than HA, such that no long 
exchanges during handover are needed.  Could be beneficial, what do you 
think.

Alex

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Sun, 18 Mar 2007 05:03:57 -0400

Kuntal, 

Sorry for delay. I was traveling so did not have email access. 
See inline. 

Regards,
Ajoy

> 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 

Ajoy-> I think we started the discussion from the point that in
draft-sgudave framework, 
LMA needs to authorize MAG during every handoff and then we got 
side tracked in context transfer discussion. So, I would summarize our
discussion as follows: 

(1) In draft-sgundave framework, LMA is required to authorize MAG (PMIP
client) during critical path of handoff. 
This is so because PMIP client moves with MN from one MAG to other. This
will have implication on handoff performance, and will increase AAA load
etc. 

(2) In draft-singh framework, LMA is NOT required to authorize MAG (PMIP
client) during every handoff. This is so because PMIP client 
does not move with MN from one MAG to author, hence LMA only needs to
authorize MAG (PMIP client) during initial attachment. This means MAG
(PMIP client) authorization is removed from critical path of handoff. 

Please let me know if I missed anything. 

> > > > Also, even in the scenario where PMIP client is anchored on a 
> > > > centralized node, we are NOT
> suggesting
> > > any