Subject: Re: [netlmm] FW: comments to Sri's draft (& advantage of draft-singh)

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

Hi Kuntal,

Chowdhury, Kuntal wrote:
> 
>> -----Original Message-----
>> 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)
>>
>> 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.
>>
> [KC>] I don't think this is a major/key advantage. The SA requirement
> for MIP6 and PMIP6 are clearly different. 

There are different ways to provide PMIP6 function, one is with
draft-singh and the other is draft-sgundave. Both have different
_constraints_ in term of SA requirement.

If implementing PMIP6/netlmm function without touching RFC3775 is seen
as a valuable feature (which I beleive), then one reauirment for PMIP6
design is then to comply to the per-MN SA model, no choice.

It is a matter of where we palce the requirement. To me it makes little
sense to place it on the SA type, better on the usability of the netlmm
protocol.

>> I see this as a key advantage for easing deployment, especially in
>> 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.

Right, draft-sgundave could probably do that, but this would be far less
efficient than draft-singh (while still requiring RFC3775) due to the
relocation of the entity (i;e. MAG) sending the BU on behalf of MN. The
PMIP Client is fixed in draft-singh.

Christophe

>> Christophe
>>
>> Singh Ajoy-ASINGH1 wrote:
>>> 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,
>>>
>>> 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
> 
> 
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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