Subject: RE: [netlmm] PMIPv6 Next Steps

From: [email-masked]
Date: Fri, 6 Apr 2007 15:59:31 -0700

Vidya,

I believe base draft is already addressing IPv4 support. If there are
some fixes required (I did not see in your email if there are any issue
with supporting IPv4), this WG should be fixing it in the base draft.
Separating IPv4 support in a different document is going to delay
overall process. In my opinion, removing IPv4 support from the base
draft makes it very weak.

Regards
Lalit

Lalit Kotecha 
Verizon Wireless 
Advanced Technology Strategy 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 2:22 PM
To: [email-masked]
Subject: [netlmm] PMIPv6 Next Steps

All,
In the interest of meeting our goals in a timely manner, I propose that
the base protocol document be in accordance with our charter and other
things be written up separately. I have discussed this with our AD and
we are in agreement that this would allow us to make faster and better
progress. Some of this can proceed parallely and we can ensure timely
completion of those as well. This would also allow better work
distribution to allow parallel operation. 

Specifically, here are the next steps. 

Decided actions: 
----------------
* The protocol document will progress with the base PMIPv6 specification
(draft-ietf-netlmm-pmip6-00)

* IPv4 support to be specified in a companion document, which will
progress in parallel. We will add a separate goal to the charter to
ensure this gets done. Consensus for doing the IPv4 work has already
been established in the WG. 

* A discussion of the PMIP6-MIP6 interactions in Prague indicated
several points that need to be documented and some issues that need to
be flushed out. A separate document is needed to describe the details
clearly. The base document can proceed with an informative reference to
this document. We do need to make sure we are cognizant of the
interactions in the PMIP6 design. So, the hope is that we can flush out
the details more or less in parallel as well. 

To-be-decided based on WG consensus:
------------------------------------

* If there is WG consensus to standardize the anchoring approach, we
will work on a separate document that describes that. I will soon send
out an email asking for WG opinion on this. 

To-be-decided based on further investigation and interest:
----------------------------------------------------------

* In Prague, we decided that the base document will not support any
shared link behavior, including last-hop shared links for link-local
addresses, due to lingering questions on DNAv6 dependency and the
potential need for domain-wide uniqueness for link-local addresses. This
topic can continue to be flushed out by the WG and we will revisit it
when we have a better idea on how to add this support to the protocol. 

Thanks,
Vidya

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

The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Sun, 8 Apr 2007 01:57:39 -0400

Hi, Bechet, 
 
Please find inline. 
 
Regards,
Ajoy 

________________________________

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Saturday, April 07, 2007 3:11 PM
To: Narayanan, Vidya
Cc: [email-masked]
Subject: Re: [netlmm] PMIPv6 Next Steps

Hello all,
  Here are my views on these great issues:

-IPv4 support: don't have a strong opinion but keeping in the base
document sounds logical to me.

- the PMIP6-MIP6 interactions, I do not see a strong need for this but
an informational document would do. 
 
Ajoy-> Why don't you see strong need for this? IMHO,  it is extremely
important that we allow co-existence of Proxy MIPv6 and 
Client MIPv6 in a given deployment. Both are IETF solution and will be
implemented by various vendors. 
I can see that handsets will implement client MIP and infrastructure
will implement Proxy MIP and so there is a need to support 
both in a given deployment. How will this work if protocol is NOT
deigned is consider these use cases? 
IMHO, we must consider these in standard track document. However,  I do
agree with you that this 
can be specified in a companion  document.  

-Regarding the anchoring approach, the need for such an approach is
specific, and architectural. Maybe it is better done where it is needed,
i.e. WiMAX. 
 
Ajoy-> Why do you think anchoring is specific to WIMAX? IMO, anchoring
based approach enables 
PMIPv6 solution to re-use same model as MIPv6. Basically in MIPv6
association is maintained 
between mobile node and home agent and the association does not change
while mobile moves from 
one access network to other. Keeping fixed association between mobile
node (PMIP client) and home agent ensures that 
PMIPv6 solution does not break the fundamental assumption made by MIPv6
protocol and thereby 
simplifies PMIPv6 solution, enables better re-use and ensures easier
adoption of various MIPv6 specific extensions by 
MIPv6 protocol. 

-not supporting any shared link behavior is good.

I was expecting more in the list of extensions for which the drafts
already exit and some even presented:
-NEMO support,
-RO support,
-handover and context transfer extension
-others.

Should these extensions be considered in other WGs?

Thx.

--behcet

----- Original Message ----
From: "Narayanan, Vidya" <[email-masked]>
To: [email-masked]
Sent: Friday, April 6, 2007 4:21:54 PM
Subject: [netlmm] PMIPv6 Next Steps

All,

Decided actions: 
----------------

Thanks,
Vidya

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 9 Apr 2007 09:42:46 -0500

Vidya,

I believe we should keep the support of IPv4 included in the base
protocol. Taking it out will make the base protocol weak.

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 2:22 PM
To: [email-masked]
Subject: [netlmm] PMIPv6 Next Steps

All,

Decided actions: 
----------------

Thanks,
Vidya

The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work product
doctrine and thus protected from disclosure.  If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify me immediately by replying to this
message and deleting it and all copies and backups thereof.  Thank you.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2007 21:30:41 -0700 (PDT)

Hi Jari,
  Once these two documents are completed,  is netlmm WG going to come to a happy end maybe by IETF-69 time frame? Having lost two founding chairs, probably this is the best itinerary to take?

Regards,

Behcet

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: [email-masked]
Sent: Tuesday, April 10, 2007 4:15:57 PM
Subject: Re: [netlmm] PMIPv6 Next Steps

On the topic of IPv4:

I hear the concerns people have raised about this. I wanted to share
what I think. But let me start by listing some things that we have
an agreement on:

o  IPv4 support is essential for the success of NETLMM.
o  IPv4 support needs to be published timely, at the same time as
    the rest of the protocol.
o  The WG should decide whether IPv4 feature (or any other
    feature for that matter) is a mandatory-to-implement part
    of the specification.
o  We should not develop a lot of new technology to support
    IPv4, pointing to DSMIP is the right approach.
o  The current text we have is a good start -- needs some adjustment
    but is not fundamentally broken.
o  The current starting point text from draft-sgundave has
    WG backing to go into WG draft(s) as soon as it can be
    submitted.

No one is suggesting we compromise on any of these, so lets take
those worries off the table from the start.

Then to my opinion.

What Vidya is suggesting is not a change to to the above, but only
a document organization matter. Namely whether we have a single
document or the base plus another one to explain the IPv4 aspects.
Generally speaking its the chairs' job in a WG to worry about the
project management. This includes things like breaking tasks into
smaller ones, picking people who are responsible for the tasks,
thinking how to serialize/parallelize  tasks, managing risks of what
happens when there's a problem in a task, etc. I would suggest the
WG concentrates on the substance of what should go into the
documents, reviewing and improving the specifications, and
lets the chairs do the project management part. We have already
spent the last months in debating which one of the very similar
drafts we pick for going forward -- lets not spend the next months
by arguing what the documentation structure should be. No matter
what the structure is, revving the current IPv4 text to whatever
shape is going to take less time than we have already spent
on this thread.

Clearly you can handle this feature either within the base or in
another document. The world is not going to end either way.
But I do see some advantages in separate modular drafts, and
I support the plan. The advantages include some parallelization
of editor efforts (based on my review at least some editing will
be needed), smaller documents for reviewers, possibly some
advantages with normative reference delays if something like that
would happen, etc.

So, given the list from the top of my e-mail and a plan to take
these two parts to the WG draft, WGLC, IESG etc. at the same
time -- do people still see problems?

Jari

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Apr 2007 10:01:22 -0700 (PDT)

Hi Kuntal,

If AD and the chairs see such a need, we should grant it, create one and post it quickly and move on.
That is my real point.

Behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Mohamed Khalil <[email-masked]>; Jari Arkko <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, April 11, 2007 11:50:13 AM
Subject: RE: [netlmm] PMIPv6 Next Steps

Hi Behcet,
 
The question is not how to create a separate document. It is more about the need to create a separate document. That’s the real point of debate.
 
Regards,
Kuntal

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 10:47 AM
To: Mohamed Khalil; Jari Arkko
Cc: [email-masked]
Subject: Re: [netlmm] PMIPv6 Next Steps
 
I just don't understand this discussion.
 
What is the big deal in making a separate document?
If Sri sends me the xml file I can make the IPv4 support draft shortly.
 
--behcet
----- Original Message ----
From: Mohamed Khalil <[email-masked]>
To: Jari Arkko <[email-masked]>; [email-masked]
Sent: Wednesday, April 11, 2007 9:42:43 AM
Subject: RE: [netlmm] PMIPv6 Next Steps
Hi Jari,

Thank you very much for your feedback. I disagree with you that
splitting the document into two documents is a management issue but it
is in my opinion is a technical issue. The management aspect is to put a
deadline to when this work should be concluded and proceed to be
standard. I believe we should leave the technical part to the consensus
of the members of this group, and the management part to the co-chairs. 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2007 4:16 PM
To: [email-masked]
Subject: Re: [netlmm] PMIPv6 Next Steps

On the topic of IPv4:

I hear the concerns people have raised about this. I wanted to share
what I think. But let me start by listing some things that we have an
agreement on:

No one is suggesting we compromise on any of these, so lets take those
worries off the table from the start.

Then to my opinion.

What Vidya is suggesting is not a change to to the above, but only a
document organization matter. Namely whether we have a single document
or the base plus another one to explain the IPv4 aspects. Generally
speaking its the chairs' job in a WG to worry about the project
management. This includes things like breaking tasks into smaller ones,
picking people who are responsible for the tasks, thinking how to
serialize/parallelize  tasks, managing risks of what happens when
there's a problem in a task, etc. I would suggest the WG concentrates on
the substance of what should go into the documents, reviewing and
improving the specifications, and lets the chairs do the project
management part. We have already spent the last months in debating which
one of the very similar drafts we pick for going forward -- lets not
spend the next months by arguing what the documentation structure should
be. No matter what the structure is, revving the current IPv4 text to
whatever shape is going to take less time than we have already spent on
this thread.

Clearly you can handle this feature either within the base or in another
document. The world is not going to end either way. But I do see some
advantages in separate modular drafts, and I support the plan. The
advantages include some parallelization of editor efforts (based on my
review at least some editing will be needed), smaller documents for
reviewers, possibly some advantages with normative reference delays if
something like that would happen, etc.

So, given the list from the top of my e-mail and a plan to take these
two parts to the WG draft, WGLC, IESG etc. at the same time -- do people
still see problems?

Jari

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