Subject: RE: Link and Addressing Models (RE: [netlmm] Proposedtext formultihoming)

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Oct 2007 22:22:43 -0400

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:[email-masked]]
> Sent: Thursday, October 11, 2007 8:41 AM
> To: Vijay Devarapalli; Basavaraj Patil
> Cc: Christian Vogt; NetLMM Mailing List
> Subject: RE: Link and Addressing Models (RE: [netlmm] Proposedtext
> formultihoming)
> 
> Hi Vijay and Raj,
> 
> I really think you are missing something here. Stefano and Alex
already
> pointed out the existence of many multi-interface hosts that may have
> interfaces up at the same time.
> 
[KC>] If such hosts want to keep multiple interfaces active at the same
time, they need to configure different IP addresses on those interfaces
(possible using the same HNP). If the hosts want to configure the same
IP address on those interfaces, they need additional capabilities over
and above the "unmodified IP host" basic capability.

I don't see any issue here.

> This was also one of the motivations to charter monami6 for mip6
capable
> hosts. And I don't see reasons why only mip6 capable hosts can be
> multihomed.
> 
> Gerardo
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Tuesday, October 09, 2007 8:10 PM
> > To: Basavaraj Patil
> > Cc: Giaretta, Gerardo; Narayanan, Vidya; Christian Vogt; NetLMM
> Mailing
> > List
> > Subject: Re: Link and Addressing Models (RE: [netlmm] Proposed text
> > formultihoming)
> >
> > Basavaraj Patil wrote:
> > > Hi Gerardo,
> > >
> > > We are not limiting the assignment of a unique prefix to each
> interface.
> > > What we are saying is that the choice of the prefix to be assigned
> > should be
> > > made by the LMA (and this will vary depending on deployment
> > environments).
> > >
> > > The limitation that we mention about the MN having service over
only
> one
> > > interface is in the scenario where the LMA assigns the same prefix
> to
> > the
> > > second interface. I think this is an acceptable solution within
the
> > scope of
> > > the base specification. Future work can allow simultaneous
bindings
> or
> > other
> > > capabilities that would ensure unmodified hosts to work on both
> > interfaces.
> > >
> > > In terms of a reality check, do you see hosts (current generation
of
> > > unmodified hosts) which are connected via different interfaces to
> the
> > > Internet being able to use both interfaces simultaneously???
> >
> > They don't today. Only one interface is used.
> >
> > Vijay
> >
> > >
> > > -Raj
> > >
> > >
> > > On 10/9/07 8:56 AM, "ext Giaretta, Gerardo"
<[email-masked]>
> > wrote:
> > >
> > >> Hi Raj,
> > >>
> > >>>
> > >>> Hi Vidya,
> > >>>
> > >>> I don't know why you perceived that my comments were suggesting
> that
> > >> we
> > >>> change the charter to allow modification of hosts. I did not say
> that.
> > >>> Your
> > >>> interpretation of my comment surprises me :)
> > >>>
> > >>> What I said was that the text that we have proposed allows the
> > >> protocol to
> > >>> deal with hosts which have the ability to attach via multiple
> > >> interfaces
> > >>> to
> > >>> access networks which may be part of the same PMIP6 domain.
> > >>>
> > >>> There are limitations with PMIP6 in terms of multihoming. A
> multihomed
> > >>> host
> > >>> in a PMIP6 domain will have only a single interface active. This
> is a
> > >>> limitation that I think is acceptable in the context of this
I-D.
> > >>>
> > >> Why should we artificially introduce this limitation???
> > >>
> > >> If the prefix is assigned per interface and the ID used for
binding
> > >> processing is per interface, we will not have such a limitation.
> Thus I
> > >> see the solution provided by Christian a better way to solve the
> > >> multihoming issue.
> > >>
> > >> Note that an unmodified multihomed node will not know that PMIPv6
> is
> > >> used; therefore it does not expect that it can use only one
active
> > >> interface when in a no-PMIP network it could use two or more
active
> > >> interfaces. Which is the technical motivation why we should
include
> > such
> > >> a strong limitation and provide to the user a worse user
> experience?
> > >>
> > >> I still don't see any technical issue with the solution suggested
> by
> > >> Christian. Can you please explain why we should not adopt it and
> live
> > >> with this limitation?
> > >>
> > >> Gerardo
> > >>
> > >>> So let me state it clearly again:
> > >>> We do not propose to change the charter or the scope of the
> current
> > >>> charter.
> > >>> The current I-D as specified with the proposed text to be added
> does
> > >> not
> > >>> require any host modification or place a requirement on a host.
It
> > >> allows
> > >>> an
> > >>> unmodified multiinterface host to operate in a PMIP6 domain. I
am
> not
> > >> even
> > >>> suggesting publishing any SDO specific document here. The intent
> is to
> > >>> standardize a protocol for supporting IP mobility for unmodified
> IP
> > >> hosts.
> > >>> What some SDO does with the protocol or an MN is beyond the
> control of
> > >> the
> > >>> IETF and lets not get hung up about it.
> > >>>
> > >>> I don't know what solution you are expecting to be specified to
> solve
> > >> the
> > >>> multihoming problem. We have specified a solution that IMO
> addresses
> > >> the
> > >>> concern that was raised w.r.t multihomed hosts. And I think
there
> is
> > >>> consensus that a comprehensive solution to the problem needs to
be
> > >>> specified
> > >>> separately. I don't see any way that we are going to converge on
a
> > >>> solution
> > >>> on this topic. You can go ahead and do a consensus call and move
> > >> forward
> > >>> and
> > >>> note your concern in the IESG writeup. Or you can ask the AD to
> > >> intervene
> > >>> and provide his views on this issue and next steps.
> > >>>
> > >>> -Raj
> > >>>
> > >>>
> > >>> On 10/8/07 8:02 PM, "ext Narayanan, Vidya" <[email-masked]>
> > >> wrote:
> > >>>> Hi Raj,
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Basavaraj Patil [mailto:[email-masked]]
> > >>>>> Sent: Monday, October 08, 2007 4:00 PM
> > >>>>> To: Narayanan, Vidya; Christian Vogt
> > >>>>> Cc: NetLMM Mailing List
> > >>>>> Subject: Re: Link and Addressing Models (RE: [netlmm]
> > >>>>> Proposed text for multihoming)
> > >>>>>
> > >>>>>
> > >>>>> Hi Vidya,
> > >>>>>
> > >>>>> Indeed, I guess we differ on how much (additional)
> > >>>>> functionality needs to be in the base spec to handle the
> > >>>>> unmodified multihomed host.
> > >>>>>
> > >>>>> - Where do you see from a practical deployment viewpoint the
> > >>>>> need to support *unmodified* multihomed hosts for PMIP6?
> > >>>> I'm sorry, but, I beg to differ on this take.  As you very well
> > >> know, at
> > >>>> the IETF, we build Proposed Standards not just for today's
> immediate
> > >> use
> > >>>> cases that we may be seeing, but, something that will support a
> > >> bigger
> > >>>> goal and will be useful for future use cases.  Our charter has
> been
> > >>>> built with the goal of working with unmodified hosts (and
> multihomed
> > >>>> hosts are not special or rare in today's world, as many have
> said).
> > >> So,
> > >>>> unless we are saying that the charter is now invalid and we
need
> a
> > >>>> protocol where the hosts can be modified rather than not, this
is
> a
> > >> big
> > >>>> deviation from what we need to accomplish.
> > >>>>
> > >>>> At the time of chartering this effort, a lot of value was seen
to
> be
> > >>>> coming from having a mobility solution without any involvement
> from
> > >> the
> > >>>> host side.  I don't think that value has now diminished, just
> based
> > >> on
> > >>>> the fact that some SDOs may be considering changes to the host
> for
> > >>>> whatever reason.
> > >>>>
> > >>>> If we want to publish an SDO-specific document as
Informational,
> the
> > >>>> take here would probably be different.
> > >>>>
> > >>>> And, on your notes below, I think I have made my take
> sufficiently
> > >> clear
> > >>>> that it is not about a "feature" or about "multihoming support"
-
> > >>>> rather, just about IP connectivity to multihomed, unmodified
> hosts.
> > >>>>
> > >>>> Vidya
> > >>>>
> > >>>>> - Why do you believe the protocol has to have a solution for
> > >>>>> every feature that is essential? We could say that binding
> > >>>>> revocation is even more critical than the need to support
> > >>>>> multihomed hosts. Yet we seem to say that it can be specified
> > >>>>> subsequently. Why is the multihoming support any different?
> > >>>>>
> > >>>>> We believe that we are providing a solution and guidelines
> > >>>>> for providing stable IP connectivity to unmodified hosts as
> well.
> > >>>>> As the text says, the LMA can/may assign a unique prefix to
> > >>>>> each interface of the host based on the fact that it is aware
> > >>>>> of the MN attaching to the network via a different access
type.
> > >>>>> In the case where the LMA assigns the same prefix, we are
> > >>>>> stating that the LMA would have to revoke the binding from
> > >>>>> the previous MAG which in turn would revoke the prefix
> > >>>>> assigned to the interface via which the MN was attached to
> > >>>>> the MAG. Obviously this depends on further specification work.
> > >>>>> But it provides sufficient guidelines to implementers and
> > >> deployments.
> > >>>>> We are not discussing inter-technology handovers and how this
> > >>>>> is accomplished. The concern was about handling a multihomed
> > >>>>> host and the text provides a mechanism for that.
> > >>>>>
> > >>>>> -Raj
> > >>>>>
> > >>>>>
> > >>>>> On 10/8/07 5:42 PM, "ext Narayanan, Vidya"
> > >>>>> <[email-masked]> wrote:
> > >>>>>
> > >>>>>> Hi Raj,
> > >>>>>> Unfortunately, I think we differ in what we believe needs
> > >>>>> to be worked
> > >>>>>> out later.  I believe providing stable IP connectivity for
> > >>>>> unmodified
> > >>>>>> hosts is a responsibility of the base protocol.  Enabling
> > >>>>>> inter-technology handoffs using this protocol is not a goal
for
> > >> the
> > >>>>>> base spec - I recognize that it is needed for other SDOs
> > >>>>> and it can be
> > >>>>>> done by extending the MN in one or more ways in other SDOs.
> > >>>>>  If this
> > >>>>>> needs to happen at the IETF, it can be handled after the
> > >>>>> base spec is done.
> > >>>>>> But, I can't see how we can claim that it is outside the
> > >>>>> scope of the
> > >>>>>> base spec to handle unmodified IP devices.
> > >>>>>>
> > >>>>>> Vidya
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Basavaraj Patil [mailto:[email-masked]]
> > >>>>>>> Sent: Monday, October 08, 2007 3:36 PM
> > >>>>>>> To: Narayanan, Vidya; Christian Vogt
> > >>>>>>> Cc: NetLMM Mailing List
> > >>>>>>> Subject: Re: Link and Addressing Models (RE: [netlmm]
> > >>>>> Proposed text
> > >>>>>>> for multihoming)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Hi Vidya,
> > >>>>>>>
> > >>>>>>> The MAG is revoking the prefix from the interface (IF1) of
> > >>>>> an MN when
> > >>>>>>> it attaches via another interface (IF2) (as a result of
> > >>>>> revocation).
> > >>>>>>> So in the context of PMIP6, a multinterface host would be
> > >>>>> active on
> > >>>>>>> only one link at any given time.
> > >>>>>>>
> > >>>>>>> Binding revocation and the MAG sending an RA with prefix
> > >>>>> lifetime=0
> > >>>>>>> is one way. Details as you mention need to be worked out
> > >>>>> separately.
> > >>>>>>> I see the current text as a reasonable solution for the base
> > >>>>>>> protocol. I think you do recognize that the issue needs to
> > >>>>> be worked
> > >>>>>>> on separately for a more complete solution.
> > >>>>>>>
> > >>>>>>> -Raj
> > >>>>>>>
> > >>>>>>> On 10/8/07 5:22 PM, "ext Narayanan, Vidya"
> > >>>>>>> <[email-masked]> wrote:
> > >>>>>>>
> > >>>>>>>> Hi Raj,
> > >>>>>>>> This doesn't take care of the fact that from the MN's point
> > >>>>>>> of view,
> > >>>>>>>> the same prefix is assigned to multiple interfaces.
> > >>>>>>> Revocation may or
> > >>>>>>>> may not solve this, as we discussed briefly when Vijay
> > >>>>>>> proposed that -
> > >>>>>>>> we'd have to discuss that in more detail when we deal with
> > >>>>>>> revocation.
> > >>>>>>>> Vidya
> > >>>>>>>>
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: Basavaraj Patil [mailto:[email-masked]]
> > >>>>>>>>> Sent: Monday, October 08, 2007 2:55 PM
> > >>>>>>>>> To: Narayanan, Vidya; Christian Vogt
> > >>>>>>>>> Cc: NetLMM Mailing List
> > >>>>>>>>> Subject: Re: Link and Addressing Models (RE: [netlmm]
> > >>>>>>> Proposed text
> > >>>>>>>>> for multihoming)
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Hi Vidya,
> > >>>>>>>>>
> > >>>>>>>>> We are not modifying the PtP link model or breaking the
IPv6
> > >>>>>>>>> addressing architecture.
> > >>>>>>>>> This is a non-issue.
> > >>>>>>>>>
> > >>>>>>>>> Repeating what I wrote in my previous note to Christian:
> > >>>>>>>>> "
> > >>>>>>>>> We recognize the link model in use for PMIP6 and do not
> > >>>>>>> believe that
> > >>>>>>>>> we are breaking it. And here is why:
> > >>>>>>>>> When the LMA assigns the same prefix to MAG2, it deletes
> > >>>>> the entry
> > >>>>>>>>> for MAG1.
> > >>>>>>>>> Hence from the PMIP6 perspective, there is only one PtP
> link.
> > >>>>>>>>> And that is between the MN and MAG2 (in this case).
> > >>>>>>>>> As we mentioned in the text the mitigation for the MN
> > >>>>>>> which believes
> > >>>>>>>>> that it is connected via IF1 to MAG1 and IF2 to MAG2 is
> > >>>>>>> via binding
> > >>>>>>>>> revocation. The LMA can send a revocation to
> > >>>>>>>>> MAG1 and MAG1 could revoke the prefix assigned to IF1 (RA
> > >>>>>>> with prefix
> > >>>>>>>>> lifetime=0). Of course revocation is planned to be
> > >>>>>>> specified in the
> > >>>>>>>>> future.
> > >>>>>>>>>
> > >>>>>>>>> Hence we are not diverging from the PtP model or breaking
> the
> > >>>>>>>>> IPv6 addressing architecture.
> > >>>>>>>>> "
> > >>>>>>>>>
> > >>>>>>>>> -Raj
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 10/8/07 4:43 PM, "ext Narayanan, Vidya"
> > >>>>>>>>> <[email-masked]> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> All,
> > >>>>>>>>>>
> > >>>>>>>>>>> again, the per-interface home prefix model does not
> > >>>>>>>>> prevent the use
> > >>>>>>>>>>> of the same home prefix on different interfaces of a
> > >>>>> multi-homed
> > >>>>>>>>>>> host.  It is the current point-to-point model, in
> > >>>>>>> combination with
> > >>>>>>>>>>> the IPv6 addressing architecture, that does.
> > >>>>>>>>>>>
> > >>>>>>>>>> I think the above point is quite important and this is
> > >>>>>>> what some of
> > >>>>>>>>>> the other emails also have been getting to.  Basically,
if
> > >>>>>>>>> we followed
> > >>>>>>>>>> the
> > >>>>>>>>>> IPv6 architecture where a prefix is link-specific and
> > >>>>> the agreed
> > >>>>>>>>>> NETLMM model of point-to-point links, given that a
> > >>>>>>>>> point-to-point link
> > >>>>>>>>>> has exactly two endpoints (interfaces), one of which is
the
> > >>>>>>>>> MAG, the
> > >>>>>>>>>> prefix per interface model for the MN automatically
> follows.
> > >>>>>>>>>>
> > >>>>>>>>>> This should have been caught during the days of link
model
> > >>>>>>>>> discussion
> > >>>>>>>>>> itself, but, unfortunately, we didn't.
> > >>>>>>>>>>
> > >>>>>>>>>> Given where we are with the link model, I don't think
> > >>>>> we can make
> > >>>>>>>>>> exceptions to it now in the base spec, even if it is for
> > >>>>>>>>> the same MN
> > >>>>>>>>>> case.
> > >>>>>>>>>>
> > >>>>>>>>>> Vidya
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Oct 2007 11:04:07 +0200

Chowdhury, Kuntal wrote:
> 
>> -----Original Message----- From: Giaretta, Gerardo
>> [mailto:[email-masked]] Sent: Thursday, October 11, 2007
>> 8:41 AM To: Vijay Devarapalli; Basavaraj Patil Cc: Christian Vogt;
>> NetLMM Mailing List Subject: RE: Link and Addressing Models (RE:
>> [netlmm] Proposedtext formultihoming)
>> 
>> Hi Vijay and Raj,
>> 
>> pointed out the existence of many multi-interface hosts that may
>> have interfaces up at the same time.
>> 
> [KC>] If such hosts want to keep multiple interfaces active at the
> same time, they need to configure different IP addresses on those
> interfaces (possible using the same HNP).

Sounds logic probably yes, but since the MN's decision to forward a 
packet is based on the dst address, not on the source address, the 
important thing is to have a distinguishment in MN's routing table, and 
probably in the DNS, but not a distinguishment on the address assigned 
on an interface.

It's also important that the routing infrastructure makes sure packets 
are delivered consistently to one, or another, or both interfaces of MN 
having the same address.  And this is PMIP6' decision.

> If the hosts want to configure the same IP address on those
> interfaces, they need additional capabilities over and above the
> "unmodified IP host" basic capability.

I think this may appear logic to many people (sometimes myself too) for 
global addresses; but how about link-local addresses?

Configuring the same link-local address on two interfaces of same 
machine is not beyond the unmodified IP host capability.  True for IPv4 
(169.254), true for IPv6 (fe80).  Assigning fe80::1 on two interfaces of 
same MN and then using ping6 -I as application works.  It's not 
incorrect either, because link-local addresses are valid only on a link.

I'm not sure what you mean that this is beyond unmodified hosts?

Alex

>>> -----Original Message----- From: Vijay Devarapalli
>>> [mailto:[email-masked]] Sent: Tuesday, October
>>> 09, 2007 8:10 PM To: Basavaraj Patil Cc: Giaretta, Gerardo;
>>> Narayanan, Vidya; Christian Vogt; NetLMM
>> Mailing
>>> List Subject: Re: Link and Addressing Models (RE: [netlmm]
>>> Proposed text formultihoming)
>>> 
>>> Basavaraj Patil wrote:
>>>> Hi Gerardo,
>>>> 
>>>>>> Your interpretation of my comment surprises me :)
>>>>>> 
>>>>>> to access networks which may be part of the same PMIP6
>>>>>> domain.
>>>>>> 
>>>>>> host in a PMIP6 domain will have only a single interface
>>>>>> active. This
>> is a
>>>>> see the solution provided by Christian a better way to solve
>>>>> the multihoming issue.
>>>>> 
>>>>>> So let me state it clearly again: We do not propose to
>>>>>> change the charter or the scope of the
>> current
>>>>>> charter. The current I-D as specified with the proposed
>>>>>> text to be added
>> does
>>>>> not
>>>>>> an unmodified multiinterface host to operate in a PMIP6
>>>>>> domain. I
> am
>> not
>>>>> even
>>>>>> specified separately. I don't see any way that we are going
>>>>>> to converge on
> a
>>>>>> solution on this topic. You can go ahead and do a consensus
>>>>>> call and move
>>>>> forward
>>>>>> and note your concern in the IESG writeup. Or you can ask
>>>>>> the AD to
>>>>> intervene
>>>>>>>> -----Original Message----- From: Basavaraj Patil
>>>>>>>> [mailto:[email-masked]] Sent: Monday, October
>>>>>>>> 08, 2007 4:00 PM To: Narayanan, Vidya; Christian Vogt 
>>>>>>>> Cc: NetLMM Mailing List Subject: Re: Link and
>>>>>>>> Addressing Models (RE: [netlmm] Proposed text for
>>>>>>>> multihoming)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Vidya,
>>>>>>>> 
>>>>>>>> functionality needs to be in the base spec to handle
>>>>>>>> the unmodified multihomed host.
>>>>>>>> 
>>>>>>>> - Where do you see from a practical deployment
>>>>>>>> viewpoint the need to support *unmodified* multihomed
>>>>>>>> hosts for PMIP6?
>>>>>>>> - Why do you believe the protocol has to have a
>>>>>>>> solution for every feature that is essential? We could
>>>>>>>> say that binding revocation is even more critical than
>>>>>>>> the need to support multihomed hosts. Yet we seem to
>>>>>>>> say that it can be specified subsequently. Why is the
>>>>>>>> multihoming support any different?
>>>>>>>> 
>>>>>>>> We believe that we are providing a solution and
>>>>>>>> guidelines for providing stable IP connectivity to
>>>>>>>> unmodified hosts as
>> well.
>>>>>>>> As the text says, the LMA can/may assign a unique
>>>>>>>> prefix to each interface of the host based on the fact
>>>>>>>> that it is aware of the MN attaching to the network via
>>>>>>>> a different access
> type.
>>>>>>>> In the case where the LMA assigns the same prefix, we
>>>>>>>> are stating that the LMA would have to revoke the
>>>>>>>> binding from the previous MAG which in turn would
>>>>>>>> revoke the prefix assigned to the interface via which
>>>>>>>> the MN was attached to the MAG. Obviously this depends
>>>>>>>> on further specification work. But it provides
>>>>>>>> sufficient guidelines to implementers and
>>>>> deployments.
>>>>>>>> We are not discussing inter-technology handovers and
>>>>>>>> how this is accomplished. The concern was about
>>>>>>>> handling a multihomed host and the text provides a
>>>>>>>> mechanism for that.
>>>>>>>> 
>>>>>>>> -Raj
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Hi Raj, Unfortunately, I think we differ in what we
>>>>>>>>> believe needs
>>>>>>>> to be worked
>>>>>>>>> hosts is a responsibility of the base protocol.
>>>>>>>>> Enabling inter-technology handoffs using this
>>>>>>>>> protocol is not a goal
> for
>>>>> the
>>>>>>>>>> -----Original Message----- From: Basavaraj Patil
>>>>>>>>>> [mailto:[email-masked]] Sent: Monday,
>>>>>>>>>> October 08, 2007 3:36 PM To: Narayanan, Vidya;
>>>>>>>>>> Christian Vogt Cc: NetLMM Mailing List Subject: Re:
>>>>>>>>>> Link and Addressing Models (RE: [netlmm]
>>>>>>>> Proposed text
>>>>>>>>>> for multihoming)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Vidya,
>>>>>>>>>> 
>>>>>>>>>> I see the current text as a reasonable solution for
>>>>>>>>>> the base protocol. I think you do recognize that
>>>>>>>>>> the issue needs to
>>>>>>>> be worked
>>>>>>>>>>> Hi Raj, This doesn't take care of the fact that
>>>>>>>>>>> from the MN's point
>>>>>>>>>> of view,
>>>>>>>>>>>> -----Original Message----- From: Basavaraj
>>>>>>>>>>>> Patil [mailto:[email-masked]] Sent:
>>>>>>>>>>>> Monday, October 08, 2007 2:55 PM To: Narayanan,
>>>>>>>>>>>> Vidya; Christian Vogt Cc: NetLMM Mailing List 
>>>>>>>>>>>> addressing architecture. This is a non-issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> Repeating what I wrote in my previous note to
>>>>>>>>>>>> Christian: " We recognize the link model in use
>>>>>>>>>>>> for PMIP6 and do not
>>>>>>>>>> believe that
>>>>>>>>>>>> we are breaking it. And here is why: When the
>>>>>>>>>>>> LMA assigns the same prefix to MAG2, it deletes
>>>>>>>>>>>> 
>>>>>>>> the entry
>>>>>>>>>>>> for MAG1. Hence from the PMIP6 perspective,
>>>>>>>>>>>> there is only one PtP
>> link.
>>>>>>>>>>>> And that is between the MN and MAG2 (in this
>>>>>>>>>>>> case). As we mentioned in the text the
>>>>>>>>>>>> mitigation for the MN
>>>>>>>>>> which believes
>>>>>>>>>>>> IPv6 addressing architecture. "
>>>>>>>>>>>> 
>>>>>>>>>>>> -Raj
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> the IPv6 architecture where a prefix is
>>>>>>>>>>>>> link-specific and
>>>>>>>> the agreed
>>>>>> _______________________________________________ netlmm
>>>>>> mailing list [email-masked] 
>>>> _______________________________________________ netlmm mailing
>>>> list [email-masked] 
>> _______________________________________________ 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 has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________