Subject: [netlmm] Proposed Milestones Revision

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Apr 2007 17:18:09 -0700

All,
A number of you have expressed concerns on having IPv4 support being
specified in a separate, companion document, instead of being part of
the base document. I appreciate the concerns on possible delay being
introduced due to having separate documents and have set up milestones
that are aligned together for both documents. All the objectives that
Jari has sent in his email still hold - as both our emails have
indicated, the modularity of documents is meant to facilitate
parallelism and focused reviews.  

Here are the proposed milestones: 

Apr 2007	  	Initial version of the Protocol draft submitted
Apr 2007		Initial version of the IPv4 support document
Apr 2007		Initial version of the PMIP6-MIP6 Interactions
document
May 2007	  	Working Group Last Call on Mobile Node to Access
Router document
May 2007	  	Working Group Last Call on the Protocol document
May 2007	  	Working Group Last Call on the IPv4 support
document
Jun 2007		Working Group Last Call on the PMIP6-MIP6
Interactions document
Jun 2007	  	Submit Protocol, IPv4 support and Mobile Node to
Access Router documents for AD review
Jul 2007		Submit PMIP6-MIP6 Interactions document for AD
review

I request everyone to contribute to making technical progress and
meeting the milestones, instead of debating the document organization
further. 

Thanks,
Vidya

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 11 Apr 2007 19:32:58 -0500

Hi Vidya,

I assume that the scope of the IPv4 support draft is what already
covered and captured in the current draft (Sri, et. al). Is that
assumption a correct one?

Thanks.

Regards,
Ahmad

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 7:18 PM
> To: [email-masked]
> Subject: [netlmm] Proposed Milestones Revision
> 
> All,
> A number of you have expressed concerns on having IPv4 
> support being specified in a separate, companion document, 
> instead of being part of the base document. I appreciate the 
> concerns on possible delay being introduced due to having 
> separate documents and have set up milestones that are 
> aligned together for both documents. All the objectives that 
> Jari has sent in his email still hold - as both our emails 
> have indicated, the modularity of documents is meant to 
> facilitate parallelism and focused reviews.  
> 
> I request everyone to contribute to making technical progress 
> and meeting the milestones, instead of debating the document 
> organization further. 
> 
> Thanks,
> Vidya
>

---

From: "Narvaez, Paolo \(Paolo\)" <[email-masked]>
Date: Wed, 11 Apr 2007 20:16:07 -0500

If there is consensus that PMIP6 and IPv4 support are equally important
and they now have identical timelines, it is hard to understand the
reason why they need to be separated and modularized. Modular documents
are useful when moving in parallel at different speeds or when one
module can be used in different combinations with other documents. Since
neither is the case here (the IPv4 support document applies only to the
base document), it would be simpler, safer, and less confusing to
everyone to keep these two modules into a single document. 

Paolo 

> Sent: Wednesday, April 11, 2007 8:18 PM
> To: [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 11 Apr 2007 20:23:44 -0500

This is an excellent point.

Regards,
Ahmad

> From: Narvaez, Paolo (Paolo) [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 8:16 PM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] Proposed Milestones Revision
> 
> 
> If there is consensus that PMIP6 and IPv4 support are equally 
> important and they now have identical timelines, it is hard 
> to understand the reason why they need to be separated and 
> modularized. Modular documents are useful when moving in 
> parallel at different speeds or when one module can be used 
> in different combinations with other documents. Since neither 
> is the case here (the IPv4 support document applies only to 
> the base document), it would be simpler, safer, and less 
> confusing to everyone to keep these two modules into a single 
> document. 
> 
> Paolo 
> 
> support being

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Apr 2007 18:44:18 -0700

Hi Ahmad,
Yes, there is no change in the scope of the work. 

Vidya 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 5:33 PM
> I assume that the scope of the IPv4 support draft is what 
> already covered and captured in the current draft (Sri, et. 
> al). Is that assumption a correct one?
> 
> Thanks.
> 
> Regards,
> Ahmad
>  
>

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Thu, 12 Apr 2007 11:00:28 +0900

Hi Vidya,

I think there are still several issues for PMIP extension like NEMO support.
Don't you have any plan to handle these issues in future?

J.Lee

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Joo-Chul Kevin Lee (ETRI)
Electronics and Telecommunications Research Institute.
161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA
E-mail : [email-masked]/[email-masked] Tel : +82-042-860-1021
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 11 Apr 2007 22:36:25 -0400

I also agree that it maybe a good to have other extensions of PMIP as 
part of future (mid-long term) milestones. I realize the current 
milestones need immediate attention so that the the base protocol can be 
developed.

Thanks
Ashutosh

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Apr 2007 19:50:10 -0700

Addition of any other work needs rechartering. Once we meet the current
milestones (or at least when the documents are in last call stage), we
can discuss additional work. I hope that we are in a state to discuss
that by the next meeting in Chicago. 

Thanks,
Vidya

> From: Ashutosh Dutta [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 7:36 PM
> To: Joo-Chul Kevin Lee
> Cc: Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] Proposed Milestones Revision
> 
> I also agree that it maybe a good to have other extensions of 
> PMIP as part of future (mid-long term) milestones. I realize 
> the current milestones need immediate attention so that the 
> the base protocol can be developed.
> 
> Thanks
> Ashutosh
> 
> >> introduced due to having separate documents and have set up 
> >> milestones that are aligned together for both documents. All the 
> >> objectives that Jari has sent in his email still hold - as 
> both our 
> >> emails have indicated, the modularity of documents is meant to

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 12 Apr 2007 00:31:21 -0700

Attached is the first approved -00 version of the 
Proxy Mobile IPv6 protocol WG document.

We will be publishing the companion document that has
the IPv4 support in a week to two week time frame. The
scope of IPv4 support in the Proxy Mobile IPv6 protocol
is very much limited to what was defined in the draft,
draft-sgundave-mip6-pmip-02.txt. The document structure,
and the text will be from the original document and will
be improved as needed.

We will attempt to ensure both the documents will hit
the May last call time lines.

Thanks
Sri

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 5:18 PM
To: [email-masked]
Subject: [netlmm] Proposed Milestones Revision

All,

Thanks,
Vidya

---

From: qinxia <[email-masked]>
Date: Fri, 13 Apr 2007 10:34:42 +0800

Hello Vidya and all folks, 

              Besides NEMO support, RO support  should be discussed. Before we meet
in Chicago, discussion may start over email.

Best regards
Alice.

> Sent: Thursday, April 12, 2007 10:50 AM
> To: Ashutosh Dutta; Joo-Chul Kevin Lee
> Cc: [email-masked]
> Addition of any other work needs rechartering. Once we meet 
> the current milestones (or at least when the documents are in 
> last call stage), we can discuss additional work. I hope that 
> we are in a state to discuss that by the next meeting in Chicago. 
> 
> Thanks,
> Vidya
> 
> > milestones need immediate attention so that the the base 
> protocol can 
> > be developed.
> > 
> > Thanks
> > Ashutosh
> > 
> > > I think there are still several issues for PMIP extension 
> like NEMO 
> > > support.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Apr 2007 12:39:34 +0300

Please complete current work first. We're not done
until the base protocol (including v4 parts) are
past WGLC and shipped to the IESG. At that point
everyone has more cycles to think about new stuff.
The best way to get to that point, is to invest
your cycles to complete the current WG items.

Jari

qinxia kirjoitti:
>>> I also agree that it maybe a good to have other extensions 
>>>       
>> of PMIP as 
>>     
>>>>> specified in a separate, companion document, instead of
>>>>>           
>>> being part of
>>>       
>>>>> the base document. I appreciate the concerns on possible
>>>>>           
>>> delay being
>>>       
>>>>> Apr 2007                Initial version of the Protocol 
>>>>>           
>>> draft submitted
>>>       
>>>>> Apr 2007                Initial version of the IPv4 
>>>>>           
>>> support document
>>>       
>>>>> Apr 2007                Initial version of the PMIP6-MIP6 
>>>>>           
>>> Interactions
>>>       
>>>>> document
>>>>> May 2007                Working Group Last Call on Mobile 
>>>>>           
>>> Node to Access
>>>       
>>>>> Router document
>>>>> May 2007                Working Group Last Call on the 
>>>>>           
>>> Protocol document
>>>       
>>>>> May 2007                Working Group Last Call on the 
>>>>>           
>> IPv4 support
>>     
>>>>> document
>>>>> Jun 2007                Submit Protocol, IPv4 support and 
>>>>>           
>>> Mobile Node to
>>>       
>>>>> Jul 2007                Submit PMIP6-MIP6 Interactions 
>>>>>           
>>> document for AD
>>>       
>>>>> review
>>>>>
>>>>> I request everyone to contribute to making technical 
>>>>>           
>> progress and 
>>     
>>>>> meeting the milestones, instead of debating the document
>>>>>           
>>> organization
>>>       
>>>>> further.
>>>>>
>>>>> Thanks,
>>>>> Vidya
>>>>>

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 13 Apr 2007 22:33:38 -0400

Hi, Sri, 

Thanks for publishing 00 version of the WG draft. I just started to
review the draft.
The draft looks good! As far as de-coupling of IPv4 from IPv6 is
concerned, 
looks like additional clean-ups will be required to completely de-couple
IPv4 from IPv6 part. 
Here are few examples with suggested modifications that I noticed in
terminology section itself. 
I will send remaining comments (technical and editorial) after I
complete my review.  

Mobile Node (MN)

Through out this document, the term mobile node is used to refer
to an IP node whose mobility is provided by the network.  The
mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/
IPv6 dual mode.  The mobile node is not required to participate in
any mobility related signaling for achieving mobility for an IP
address that is obtained in that local domain.  This document
further uses explicit text when referring to a mobile node that is
involved in mobility related signaling as per Mobile IPv6
specification [RFC-3775].  The mobile node's capability or its
involvement in any mobility related signaling for obtaining
mobility for an address that is obtained outside the current proxy
mobile IPv6 domain, is not relevant in the context of this
document and this definition of the Mobile Node shall survive.

Modified MN definition: 

Through out this document, the term mobile node is used to refer
to an IP node whose mobility is provided by the network.   
The mobile node is not required to participate in
any mobility related signaling for achieving mobility for an IP
address that is obtained in that local domain.  This document
further uses explicit text when referring to a mobile node that is
involved in mobility related signaling as per Mobile IPv6
specification [RFC-3775].  The mobile node's capability or its
involvement in any mobility related signaling for obtaining
mobility for an address that is obtained outside the current proxy
mobile IPv6 domain, is not relevant in the context of this
document and this definition of the Mobile Node shall survive.

Original definition: 

Mobile Node's Home Address (MN-HoA)

MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6
domain.  It is an address obtained by the mobile node in that
domain.  The mobile node can continue to use this address as long
as it is attached to the network that is in the scope of that
Proxy Mobile IPv6 domain.  When supporting IPv4 address mobility
for a mobile node, the term, IPv4 MN-HoA is used to refer to the
IPv4 address of the mobile node.

Modified definition: 

Mobile Node's Home Address (MN-HoA)

MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6
domain.  It is an address obtained by the mobile node in that
domain.  The mobile node can continue to use this address as long
as it is attached to the network that is in the scope of that
Proxy Mobile IPv6 domain.  

Original definition: 

Proxy Care-of Address (Proxy-CoA)

Proxy-CoA is the address configured on the interface of the mobile
access gateway and is the transport endpoint of the tunnel between
the local mobility anchor and the mobile access gateway.  The
local mobility anchor views this address as the Care-of Address of
the mobile node and registers it in the Binding Cache entry for
that mobile node.  When the transport network between the mobile
access gateway and the local mobility anchor is an IPv4 network
and if the care-of address that is registered at the local
mobility anchor is an IPv4 address, the term, IPv4 Proxy-CoA is
used.

Modified definition: 

Proxy Care-of Address (Proxy-CoA)

Proxy-CoA is the address configured on the interface of the mobile
access gateway and is the transport endpoint of the tunnel between
the local mobility anchor and the mobile access gateway.  The
local mobility anchor views this address as the Care-of Address of
the mobile node and registers it in the Binding Cache entry for
that mobile node.  

.................

I think there are several places in document that will require such
medifications. 

Regards,
Ajoy 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 2:31 AM
To: [email-masked]
Subject: [netlmm] Proxy Mobile IPv6 Protocol Document
-draft-ietf-netlmm-pmip6-00.txt

Attached is the first approved -00 version of the Proxy Mobile IPv6
protocol WG document.

We will be publishing the companion document that has the IPv4 support
in a week to two week time frame. The scope of IPv4 support in the Proxy
Mobile IPv6 protocol is very much limited to what was defined in the
draft, draft-sgundave-mip6-pmip-02.txt. The document structure, and the
text will be from the original document and will be improved as needed.

We will attempt to ensure both the documents will hit the May last call
time lines.

Thanks
Sri

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]]
Sent: Wednesday, April 11, 2007 5:18 PM
To: [email-masked]
Subject: [netlmm] Proposed Milestones Revision

All,

Thanks,
Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:35:43 -0700

Hi Ajoy,

Thanks for the comment. Yes, we have quickly seperated the
doc and there is some work to properly structure the text,
Its known. Sure, send your other comments, we will review
them and fix it.

Thanks
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 7:34 PM
To: Sri Gundavelli; [email-masked]
Subject: RE: [netlmm] Proxy Mobile IPv6 Protocol Document

Hi, Sri, 

Mobile Node (MN)

Modified MN definition: 

Original definition: 

Modified definition: 

Original definition: 

Modified definition: 

.................

Regards,
Ajoy 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 2:31 AM
To: [email-masked]
Subject: [netlmm] Proxy Mobile IPv6 Protocol Document

Thanks
Sri

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]]
Sent: Wednesday, April 11, 2007 5:18 PM
To: [email-masked]
Subject: [netlmm] Proposed Milestones Revision

All,

Thanks,
Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:35:43 -0700

Hi Ajoy,

Thanks
Sri

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 7:34 PM
To: Sri Gundavelli; [email-masked]
Subject: RE: [netlmm] Proxy Mobile IPv6 Protocol Document

Hi, Sri, 

Mobile Node (MN)

Modified MN definition: 

Original definition: 

Modified definition: 

Original definition: 

Modified definition: 

.................

Regards,
Ajoy 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 2:31 AM
To: [email-masked]
Subject: [netlmm] Proxy Mobile IPv6 Protocol Document

Thanks
Sri

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]]
Sent: Wednesday, April 11, 2007 5:18 PM
To: [email-masked]
Subject: [netlmm] Proposed Milestones Revision

All,

Thanks,
Vidya

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Apr 2007 12:53:19 -0500

Hi Sri,

I disagree on removing any of these texts. There has to be a link
between this document and the IPv4 support document for the solution to
make sense. IPv4 support will reference this document too. IMO, since
this document already documented under section 1.0 that the details of
IPv4 support are covered by the IPv4 support companion document, I find
all references to IPv4 are appropriate EXCEPT the below example.

Under section 6.1, the last two sentences of the first paragraph, IMO,
is out of the scope of this document.

"
   .............................. For IPv4 home address configuration,
   the mobile node can obtain the address configuration using DHCP or
   optionally by using IPCP.  In addition to this, Other address
   configuration mechanisms specific to the access link between the
   mobile node and the mobile access gateway may also be used by the
   mobile node.
"

Here is the text under section 1.0: Introduction:

"
   The specific details related to enabling IPv4 home address mobility
   for the mobile node and the details related to supporting IPv4
   transport network are covered in the companion document.
"

Regards,
Ahmad

> Sent: Monday, April 16, 2007 12:36 PM
> To: 'Singh Ajoy-ASINGH1'; [email-masked]
> Thanks for publishing 00 version of the WG draft. I just 
> started to review the draft.
> The draft looks good! As far as de-coupling of IPv4 from IPv6 
> is concerned, looks like additional clean-ups will be 
> required to completely de-couple
> IPv4 from IPv6 part. 
> Here are few examples with suggested modifications that I 
> noticed in terminology section itself. 
> I will send remaining comments (technical and editorial) 
> after I complete my review.  
> 
> Mobile Node (MN)
> 
> Through out this document, the term mobile node is used to 
> refer to an IP node whose mobility is provided by the 
> network.  The mobile node may be operating in IPv6 mode, IPv4 
> mode or in IPv4/
> IPv6 dual mode.  The mobile node is not required to 
> participate in any mobility related signaling for achieving 
> mobility for an IP address that is obtained in that local 
> domain.  This document further uses explicit text when 
> referring to a mobile node that is involved in mobility 
> related signaling as per Mobile IPv6 specification 
> [RFC-3775].  The mobile node's capability or its involvement 
> in any mobility related signaling for obtaining mobility for 
> an address that is obtained outside the current proxy mobile 
> IPv6 domain, is not relevant in the context of this document 
> and this definition of the Mobile Node shall survive.
> 
> Modified MN definition: 
> 
> The mobile node is not required to participate in any 
> mobility related signaling for achieving mobility for an IP 
> further uses explicit text when referring to a mobile node 
> that is involved in mobility related signaling as per Mobile 
> IPv6 specification [RFC-3775].  The mobile node's capability 
> or its involvement in any mobility related signaling for 
> obtaining mobility for an address that is obtained outside 
> the current proxy mobile IPv6 domain, is not relevant in the 
> context of this document and this definition of the Mobile 
> Node shall survive.
> 
> Original definition: 
> 
> MN-HoA is the home address of a mobile node in a Proxy Mobile 
> IPv6 domain.  It is an address obtained by the mobile node in 
> that domain.  The mobile node can continue to use this 
> address as long as it is attached to the network that is in 
> the scope of that Proxy Mobile IPv6 domain.  When supporting 
> IPv4 address mobility for a mobile node, the term, IPv4 
> MN-HoA is used to refer to the
> MN-HoA is the home address of a mobile node in a Proxy Mobile 
> IPv6 domain.  It is an address obtained by the mobile node in 
> that domain.  The mobile node can continue to use this 
> address as long as it is attached to the network that is in 
> the scope of that Proxy Mobile IPv6 domain.  
> 
> Original definition: 
> 
> Proxy-CoA is the address configured on the interface of the 
> mobile access gateway and is the transport endpoint of the 
> tunnel between the local mobility anchor and the mobile 
> access gateway.  The local mobility anchor views this address 
> as the Care-of Address of the mobile node and registers it in 
> the Binding Cache entry for that mobile node.  When the 
> transport network between the mobile access gateway and the 
> local mobility anchor is an IPv4 network and if the care-of 
> address that is registered at the local mobility anchor is an 
> IPv4 address, the term, IPv4 Proxy-CoA is used.
> 
> Modified definition: 
> 
> Proxy-CoA is the address configured on the interface of the 
> mobile access gateway and is the transport endpoint of the 
> tunnel between the local mobility anchor and the mobile 
> access gateway.  The local mobility anchor views this address 
> as the Care-of Address of the mobile node and registers it in 
> the Binding Cache entry for that mobile node.  
> 
> .................
> 
> I think there are several places in document that will 
> require such medifications. 
> 
> Regards,
> Ajoy 
>  
> 
> Attached is the first approved -00 version of the Proxy 
> Mobile IPv6 protocol WG document.
> 
> We will be publishing the companion document that has the 
> IPv4 support in a week to two week time frame. The scope of 
> IPv4 support in the Proxy Mobile IPv6 protocol is very much 
> limited to what was defined in the draft, 
> draft-sgundave-mip6-pmip-02.txt. The document structure, and 
> the text will be from the original document and will be 
> improved as needed.
> 
> We will attempt to ensure both the documents will hit the May 
> last call time lines.
> 
> Thanks
> Sri
> 
> 
> 
>  
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Apr 2007 11:00:02 -0700

Hello,

I think some of the places where IPv4 is mentioned is
required. For example if we write a sentence in the base
spec that says "Proxy Mobile IPv6 supports IPv6-only,
dual stack and IPv4-only mobile nodes", mentioning IPv4
is ok here. We shouldn't scrub the document and remove
all instances of "IPv4".

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 11:09:54 -0700

Hi Ahmad,

Actually, I did not say that I will delete the IPv4 term
where ever its there. The document needs to be structured
properly, that's the note.

The terminal's capability needs to be mentioned in the base
doc. Except the protoocol operation, carrying of the IPv4
options and the related semantics will be in a different doc.
Also, the IPv6/IPv6 tunneling mode can be used for carrying
all the payload types and that will be there in this doc.

Thanks for clarifying. I wanted to avoid the debate now
till both the docs are out.

Sri

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 10:53 AM
To: Sri Gundavelli; Singh Ajoy-ASINGH1; [email-masked]
Subject: RE: [netlmm] Proxy Mobile IPv6 Protocol
Document-draft-ietf-netlmm-pmip6-00.txt

Hi Sri,

"

"

Regards,
Ahmad

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Mon, 16 Apr 2007 14:33:32 -0400

Sri, 

Let us publish both documents and then I will comment about this aspect.

It will be hard to comment unless other document is published. 

Regards,
Ajoy 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 1:10 PM
To: 'Ahmad Muhanna'; Singh Ajoy-ASINGH1; [email-masked]
Subject: RE: [netlmm] Proxy Mobile IPv6
ProtocolDocument-draft-ietf-netlmm-pmip6-00.txt

Hi Ahmad,

Actually, I did not say that I will delete the IPv4 term where ever its
there. The document needs to be structured properly, that's the note.

The terminal's capability needs to be mentioned in the base doc. Except
the protoocol operation, carrying of the IPv4 options and the related
semantics will be in a different doc.
Also, the IPv6/IPv6 tunneling mode can be used for carrying all the
payload types and that will be there in this doc.

Thanks for clarifying. I wanted to avoid the debate now till both the
docs are out.

Sri

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]]
Sent: Monday, April 16, 2007 10:53 AM
To: Sri Gundavelli; Singh Ajoy-ASINGH1; [email-masked]
Subject: RE: [netlmm] Proxy Mobile IPv6 Protocol

Hi Sri,

"

"

Regards,
Ahmad

> Thanks for the comment. Yes, we have quickly seperated the doc and 
> there is some work to properly structure the text, Its known. Sure, 
> send your other comments, we will review them and fix it.
> 
> Thanks
> Sri
>  
> 
> concerned, looks like additional clean-ups will be required to 
> completely de-couple
> IPv4 from IPv6 part. 
> Through out this document, the term mobile node is used to refer to an

> IP node whose mobility is provided by the network.  The mobile node 
> may be operating in IPv6 mode, IPv4 mode or in IPv4/
> IPv6 dual mode.  The mobile node is not required to participate in any

> mobility related signaling for achieving mobility for an IP address 
> that is obtained in that local domain.  This document further uses 
> explicit text when referring to a mobile node that is involved in 
> mobility related signaling as per Mobile IPv6 specification 
> [RFC-3775].  The mobile node's capability or its involvement in any 
> mobility related signaling for obtaining mobility for an address that 
> is obtained outside the current proxy mobile
> IPv6 domain, is not relevant in the context of this document and this 
> definition of the Mobile Node shall survive.
> 
> Modified MN definition: 
> 
> The mobile node is not required to participate in any mobility related

> signaling for achieving mobility for an IP address that is obtained in

> that local domain.  This document further uses explicit text when 
> referring to a mobile node that is involved in mobility related 
> signaling as per Mobile
> IPv6 specification [RFC-3775].  The mobile node's capability or its 
> involvement in any mobility related signaling for obtaining mobility 
> for an address that is obtained outside the current proxy mobile IPv6 
> domain, is not relevant in the context of this document and this 
> definition of the Mobile Node shall survive.
> 
> Original definition: 
> 
> IPv6 domain.  It is an address obtained by the mobile node in that 
> domain.  The mobile node can continue to use this address as long as 
> it is attached to the network that is in the scope of that Proxy 
> Mobile IPv6 domain.  When supporting
> IPv4 address mobility for a mobile node, the term, IPv4 MN-HoA is used

> to refer to the
> IPv6 domain.  It is an address obtained by the mobile node in that 
> domain.  The mobile node can continue to use this address as long as 
> it is attached to the network that is in the scope of that Proxy 
> Mobile IPv6 domain.
> 
> Original definition: 
> 
> access gateway and is the transport endpoint of the tunnel between the

> local mobility anchor and the mobile access gateway.  The local 
> mobility anchor views this address as the Care-of Address of the 
> mobile node and registers it in the Binding Cache entry for that 
> mobile node.  When the transport network between the mobile access 
> gateway and the local mobility anchor is an IPv4 network and if the 
> care-of address that is registered at the local mobility anchor is an
> access gateway and is the transport endpoint of the tunnel between the

> local mobility anchor and the mobile access gateway.  The local 
> mobility anchor views this address as the Care-of Address of the 
> mobile node and registers it in the Binding Cache entry for that 
> mobile node.
> 
> .................
> 
> IPv4 support in the Proxy Mobile IPv6 protocol is very much limited to

> what was defined in the draft, draft-sgundave-mip6-pmip-02.txt. The 
> document structure, and the text will be from the original document 
> and will be improved as needed.
> 
> We will attempt to ensure both the documents will hit the May last 
> call time lines.
> 
> Thanks
> Sri
> 
> 
> 
>  
>