Hi Raj:
Thanks for your comments.
On 12/13/11 2:01 PM, "basavaraj.pa...@nokia.com"
wrote:
>
> Hi Sri,
>
> On 12/13/11 3:29 PM, "ext Sri Gundavelli" wrote:
>
>> Hi Raj:
>>
>> Please see inline.
>>
>>
>> On 12/13/1
Hi Raj:
Please see inline.
On 12/13/11 1:12 PM, "basavaraj.pa...@nokia.com"
wrote:
>
> A few clarifying questions:
>
> 1. Would all the MAGs across different PMIP6 domains be required to use
> the same LLA and IID?
> As per the proposal a single LLA and IID are being reserved for use by
> PM
Hi Suresh,
On 9/21/11 3:32 PM, "Suresh Krishnan" wrote:
> Hi Sri,
>
> On 11-09-19 01:29 PM, Sri Gundavelli wrote:
>> Hi Jari:
>>
>> In case of PMIPv6, we need the interface ID allocation for PMIv6
>> domain-wide usage. We may not be able tie this
Hi Jari:
In case of PMIPv6, we need the interface ID allocation for PMIv6
domain-wide usage. We may not be able tie this to a specific EUI-64
identifier derived from a MAC identifier of any individual MAG hosting this
configuration.
But, if your recommendation is to tie the IPv6 interface identi
perience", type coloring.
Regards
Sri
On Aug 20, 2010, at 11:47 AM, Thomas Narten wrote:
> Sri Gundavelli writes:
>
>> Couple of comments on Section 9.0 (Mobility):
>> draft-ietf-6man-node-req-bis-05
>
>> 1.) When Mobile IPv6 was designed, one impo
Couple of comments on Section 9.0 (Mobility): draft-ietf-6man-node-req-bis-05
1.) When Mobile IPv6 was designed, one important feature that made into the
protocol is the support for Route Optimization. The ability for a mobile node
to provide the information on the direct (non-anchor or non-tria
I support the adoption of this document as a WG document.
Sri
>
>
>
> - Original Message
>> From: Brian Haberman
>> To: IPv6 WG Mailing List
>> Sent: Tue, August 10, 2010 1:08:26 PM
>> Subject: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt
>>
>> 6MAN WG,
>> T
On Aug 13, 2010, at 1:13 PM, Suresh Krishnan wrote:
> Hi Hemant,
> Thanks for the comments. Please see responses inline
>
> On 10-08-13 01:44 PM, Hemant Singh (shemant) wrote:
>> Right. I proposed to encapsulate the return RA message since the
>> document proposes encapsulating the RS.
>
>
