RE: Link and Addressing Models (RE:[netlmm]Proposedtextformultihoming)

["Ahmad Muhanna" <[e-mail]>]

Hi Gerardo,

Many thanks for your patience. I understand sometimes keeping up with
Kuntal is tiring:-) I hope he wont shoot me the first time I see him!
:-)

Below is the goal you referred to in your email in RFC4831. I consider
myself a detailed person and I read every single word before replying
back, but could you please point me to the text which talks about Mobile
Router in the below goal. AT least so far that the only scenario that
people has identified. If you have any other real scenario, please let
me know of it.

Many thanks in advance and appreciate your patience once again and I
hope that we close on this issue very soon.

Best Regards,
Ahmad

++++++++++++++++++++++++++++++++++++++

3.7.  Goal 7: Support for Unmodified Mobile Nodes

   In the WLAN switching market, no modification of the software on the
   mobile node is required to achieve localized mobility management.
   Being able to accommodate unmodified mobile nodes enables a service
   provider to offer service to as many customers as possible, the only
   constraint being that the customer is authorized for network access.

   Another advantage of minimizing mobile node software for localized
   mobility management is that multiple global mobility management
   protocols can be supported.  There are a variety of global mobility
   management protocols that might also need support, including
   proprietary or link technology-specific protocols needing support for
   backward compatibility reasons.  Within the Internet, both Host
   Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming
   (MOBIKE) [6] are likely to need support in addition to Mobile IPv6
   [9], and Mobile IPv4 [12] support may also be necessary.

   Note that this goal does NOT mean that the mobile node has no
   software at all associated with mobility.  The mobile node must have
   some kind of global mobility protocol if it is to move from one
   domain of edge mobility support to another and maintain session
   continuity, although no global mobility protocol is required if the
   mobile node only moves within the coverage area of the localized
   mobility management protocol or no session continuity is required
   during global movement.  Also, if the last-hop link is a wireless
   link, every wireless link protocol requires handover support on the
   mobile node in the physical and medium access control layers,
   typically in the wireless interface driver.  Information passed from
   the medium access control layer to the IP layer on the mobile node
   may be necessary to trigger IP signaling for IP handover.  Such
   movement detection support at the IP level may be required in order
   to determine whether the mobile node's default router is still
   reachable after the move to a new access point has occurred at the
   medium access control layer.  Whether or not such support is required
   depends on whether the medium access control layer can completely
   hide link movement from the IP layer.  For cellular type wireless
   link protocols, the mobile node and network undergo an extensive
   negotiation at the medium access control layer prior to handover, so
   it may be possible to trigger a routing update without any IP
   protocol involvement.  However, for a wireless link protocol such as
   IEEE 802.11 [7] in which the decision for handover is entirely in the
   hands of the mobile node, IP-layer movement detection signaling from
   the mobile node may be required to trigger a routing update.

   The goal is that the localized mobility management solution should be
   able to support any mobile node that joins the link and that has an
   interface that can communicate with the network, without requiring
   localized mobility management software on the mobile node.

Regards,
Ahmad
 

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:[e-mail]] 
> Sent: Friday, October 12, 2007 7:17 AM
> To: Chowdhury, Kuntal
> Cc: NetLMM Mailing List
> Subject: RE: Link and Addressing Models 
> (RE:[netlmm]Proposedtextformultihoming)
> 
> Kuntal,
> 
> I keep trying to describe the scenario but it seems you guys 
> don't want to read or understand. Quoting Vijay, I think this 
> is the fifth time I try to explain and "it is getting a bit 
> tiring" :-)
> 
> 
> Anyway, in the email you replied to there was a clear 
> description of the scenario. The scenario is a multi-homed 
> node that attaches to the PMIP6 domain and should behave 
> exactly in the same way it behaves in a non-PMIP network.
> 
> Raj mentioned that the LMA may assign or not the same prefix, 
> enabling multi-homing or inter-tech handover. I asked how the 
> network can know if the UE wants to be multi-homed or not. 
> 
> You replied that it sends different NAIs based on the 
> intention. I think this brings awareness to the MN of the 
> existence of something strange like PMIP6 in the network as 
> otherwise the MN would not behave like that. 
> 
> I hope this clarifies. 
> 
> By the way, note that support for unmodified hosts is not 
> "my" scenario but one of the main goals of NETLMM protocol as 
> specified in RFC 4831.
> 
> Thanks
> Gerardo
> 
> 
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:[e-mail]]
> > Sent: Friday, October 12, 2007 6:44 AM
> > To: Giaretta, Gerardo
> > Cc: NetLMM Mailing List
> > Subject: RE: Link and Addressing Models
> > (RE:[netlmm]Proposedtextformultihoming)
> > 
> > Gerardo,
> > 
> > Please tell us clearly what the problem scenario is? 
> Multi-homing or 
> > inter-technology handover or support for unmodified hosts 
> that want to 
> > have two interfaces up while load balancing between the 
> interfaces or
> a
> > high speed train or an airplane or something else?
> > 
> > I do not believe that the MN has to behave in a certain way 
> to support
> > PMIP6 in the network.
> > 
> > BR,
> > Kuntal
> > 
> > 
> > > -----Original Message-----
> > > From: Giaretta, Gerardo [mailto:[e-mail]]
> > > Sent: Friday, October 12, 2007 12:42 PM
> > > To: Chowdhury, Kuntal; Basavaraj Patil; Narayanan, Vidya; Thomas
> > Narten
> > > Cc: Christian Vogt; NetLMM Mailing List
> > > Subject: RE: Link and Addressing Models
> > > (RE:[netlmm]Proposedtextformultihoming)
> > >
> > > Hi Kuntal,
> > >
> > > > > Hi Raj,
> > > > >
> > > > > >
> > > > > > Hi Gerardo,
> > > > > >
> > > > > > I believe your statement is incorrect.
> > > > > >
> > > > > > With the proposal that we have made, an MN can be 
> multihomed.
> We
> > > are
> > > > > > not preventing it.
> > > > > > As we have stated the LMA can assign a unique prefix to the
> MN.
> > > This
> > > > > > is a policy decision of the LMA.
> > > > >
> > > > > I think the proposal is going into the right 
> direction. I think
> it
> > > is
> > > > > incomplete, though.
> > > > >
> > > > > It is not clear to me how the LMA could decide to assign the
> same
> > > > prefix
> > > > > or not. The intention of the user should be taken into account
> in
> > > this
> > > > > decision: for example how the LMA knows if in a given 
> moment the
> > > user
> > > > > wants to be multi-homed and to use two different interfaces or
> > wants
> > > > to
> > > > > perform a handover? I don't see any way here for the user to
> > convey
> > > > this
> > > > > information.
> > > > >
> > > > [KC>] if the MN wants to be multi-homed, it will use 
> different NAI
> > to
> > > > attach to MAG2. The LMA will provide different HNP to the MN in
> that
> > > > case. OTOH, if the MN wasn't to handover to MAG2 and maintain IP
> > > session
> > > > continuity, it will use the same NAI it used to attach 
> to MAG1...
> > > >
> > >
> > > You are putting PMIP-specific functionality on the MN 
> here. A host 
> > > without knowledge of PMIPv6 would not behave in this way. 
> Sorry but
> > this
> > > would be against RFC 4831.
> > >
> > > Gerardo
> > >
> > > >
> > > > > Basically your final proposal is based on the assumption that
> the
> > > LMA
> > > > > decides if the user will be multi-homed or not. I think this
> model
> > > is
> > > > > not generally acceptable for the Internet (even 
> though it might
> > for
> > > > some
> > > > > specific scenarios).
> > > > >
> > > > >
> > > > [KC>] The LMA has sufficient information to decide that 
> in general 
> > > > internet type of application as well. The PBU with the same NAI
> with
> > > > access-technology indication that is different than the 
> one in BCE
> > > will
> > > > provide ample clue to the LMA regarding what the MN 
> intends to do.
> > > >
> > > >
> > > > > > The MN may attach via a second interface to a 
> network which is
> > in
> > > a
> > > > > > different PMIP6 domain in which case the LMA is 
> different and
> > > hence
> > > > > > the MN can be multihomed.
> > > > >
> > > > > Agree.
> > > > >
> > > > > > An MN attaching via a second interface to a PMIP6 
> domain which
> > is
> > > > the
> > > > > > same as the one via which a previous interface is 
> attached may
> > be
> > > > > > assigned an LMA which is different as well in which 
> case there
> > is
> > > no
> > > > > > issue about the MN being multihomed.
> > > > > >
> > > > >
> > > > > I have a question here. In the text provided by Sri and you,
> there
> > > is
> > > > an
> > > > > access technology field. The intention is to let the 
> LMA know if
> > the
> > > > > interface is the same or not. What about if the host has two
> > > > interfaces
> > > > > of the same technology? How do you support this scenario?
> > > > >
> > > > [KC>] This is a very impractical scenario, IMHO. Even 
> in this kind
> > of
> > > > impractical scenario, the LMA has the option of 
> rejecting the PBU
> > from
> > > > MAG2 if the intent of the MN is unrealistic or ambiguous.
> > > >
> > > > > > The restriction is only in the case when the MN attaches via
> > > > multiple
> > > > > > interfaces to the same PMIP6 domain and the LMA assigned to
> > serve
> > > > MAGs
> > > > >
> > > > > > 1 and
> > > > > > 2 is the same. If the LMA policy is to assign the 
> same prefix
> to
> > > the
> > > > > > MN, then the LMA has to wait for the dereg.
> > > > >
> > > > > As said, it is not clear to me from where this LMA 
> policy comes
> > from
> > > > and
> > > > > how the LMA decides if the UE is multi-homed or a handover
> occurs.
> > > > >
> > > > [KC>] Hint: see my comment above...
> > > >
> > > > > Cheers
> > > > > Gerardo
> > > > >
> > > > > > Only in such a scenario are we saying that 
> multioming is not 
> > > > > > supported. And we believe that
> it
> > is
> > > > > > acceptable in the scope of the base spec to have such a
> > > limitation.
> > > > > > This can be solved eventually when we have simultaneous
> binding
> > > type
> > > > > > of capability and a more comprehensive solution to 
> multihoming
> > is
> > > > > > worked on.
> > > > > >
> > > > > > The insistence by several folks that per-interface-prefix
> > > assignment
> > > > > > is the only solution is puzzling. And we are 
> actually allowing
> > the
> > > > > > assignment of a unique prefix by the LMA. But this 
> is a policy 
> > > > > > decision of the LMA and not the only option.
> > > > > >
> > > > > > Cheers,
> > > > > > -Raj
> > > > > >
> > > > > >
> > > > > > On 10/10/07 11:25 PM, "ext Giaretta, Gerardo"
> > > > <[e-mail]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Raj,
> > > > > > >
> > > > > > > I'm still not sure I understand the rationale here.
> > > > > > >
> > > > > > > Based on your proposal, a host cannot be multi-homed in
> PMIP6
> > > > domain
> > > > >
> > > > > > > even though it would be capable of being multi-homed. That
> is,
> > > if
> > > > > > > PMIP6 is used, based on your proposal, a host 
> cannot use at
> > the
> > > > same
> > > > >
> > > > > > > time two different network interfaces even though it would
> be
> > > able
> > > > > > > to do that, just because PMIP6 is deployed (and note that
> the
> > > host
> > > > > > > even does not know that PMIP6 is deployed!)
> > > > > > >
> > > > > > > Based on a per-interface prefix model, this restriction
> would
> > > not
> > > > > occur.
> > > > > > > The binding cache entries in the LMA for 
> different network 
> > > > > > > interfaces would be different and the host could use both
> > > > interfaces
> > > > >
> > > > > > > as in a simple IP network.
> > > > > > >
> > > > > > > The question is: which is the rationale of this 
> restriction?
> I
> > > > don't
> > > > >
> > > > > > > see any reason for this restriction in the scope of NETLMM
> WG.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Gerardo
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: Basavaraj Patil [mailto:[e-mail]]
> > > > > > >> Sent: Wednesday, October 10, 2007 10:39 PM
> > > > > > >> To: Narayanan, Vidya; Thomas Narten
> > > > > > >> Cc: Christian Vogt; NetLMM Mailing List
> > > > > > >> Subject: Re: Link and Addressing Models (RE:
> > > > > > >> [netlmm]Proposedtextformultihoming)
> > > > > > >>
> > > > > > >>
> > > > > > >> Hi Vidya,
> > > > > > >>
> > > > > > >> To address the bare minimum issue we could:
> > > > > > >>
> > > > > > >> - Disallow the LMA from creating the BCE for an MN
> attaching
> > > via
> > > > > > > another
> > > > > > >> interface (access tech type) until it has 
> received a dereg
> > from
> > > > the
> > > > >
> > > > > > >> previous MAG. This would basically not activate 
> the second 
> > > > > > >> interface of the MN
> > > > > > > and
> > > > > > >> hence it would not be in the confused state
> > > > > > >>
> > > > > > >> - MAG1 would send the dereg only when it has 
> confirmed (via
> > > > either
> > > > > > > L1/2/3)
> > > > > > >> that the MN has disconnected from IF1
> > > > > > >>
> > > > > > >> This would ensure that the MN is connected via only one
> > > interface
> > > > > > >> at
> > > > > > > any
> > > > > > >> given time to a PMIP6 domain.
> > > > > > >>
> > > > > > >> -Raj
> > > > > > >>
> > > > > > >>
> > > > > > >> On 10/10/07 3:29 PM, "ext Narayanan, Vidya"
> > > <[e-mail]>
> > > > > > > wrote:
> > > > > > >>
> > > > > > >>> I also want to add one other thing here - at a bare
> minimum,
> > > > > > >>> devices have stable IP connectivity via at least one of
> > > multiple
> > > > > > > simultaneously
> > > > > > >>> active interfaces today.  That bare minimum is 
> what we are
> > > > putting
> > > > > > > in
> > > > > > >>> jeopardy with PMIP, as currently written.
> > > > > > >>>
> > > > > > >>> Supporting the use of multiple interfaces simultaneously
> > comes
> > > > > > >>> later
> > > > > > > -
> > > > > > >>> while that is also feasible on hosts with unmodified IP
> > hosts
> > > > > > >>> today,
> > > > > > > our
> > > > > > >>> aim at the moment is to get the bare minimum fixed.
> > > > > > >>>
> > > > > > >>> Vidya
> > > > > > >>>
> > > > > > >>>> -----Original Message-----
> > > > > > >>>> From: Narayanan, Vidya [mailto:[e-mail]]
> > > > > > >>>> Sent: Wednesday, October 10, 2007 1:15 PM
> > > > > > >>>> To: Basavaraj Patil; Thomas Narten
> > > > > > >>>> Cc: Christian Vogt; NetLMM Mailing List
> > > > > > >>>> Subject: RE: Link and Addressing Models (RE: [netlmm]
> > > > > > >>>> Proposedtextformultihoming)
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: Basavaraj Patil [mailto:[e-mail]]
> > > > > > >>>>> Sent: Wednesday, October 10, 2007 12:48 PM
> > > > > > >>>>> To: Narayanan, Vidya; Thomas Narten
> > > > > > >>>>> Cc: Christian Vogt; NetLMM Mailing List
> > > > > > >>>>> Subject: Re: Link and Addressing Models (RE: [netlmm]
> > > Proposed
> > > > > > >>>>> textformultihoming)
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> On 10/10/07 1:23 PM, "ext Narayanan, Vidya"
> > > > > > >>>>> <[e-mail]> wrote:
> > > > > > >>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> What assumptions are you making above?
> > > > > > >>>>>>> Asumptions:
> > > > > > >>>>>>> 1. IPv4 networks with the host attaching 
> via IF1 first
> > and
> > > > > > >>>>> starting
> > > > > > >>>>>>> applications 2. Second interface comes up and has a
> > valid
> > > > > > >>>>> address and
> > > > > > >>>>>>> connectivity 3. Network serving IF1 goes 
> down... Apps
> > > > > > >>>>> don't switch to
> > > > > > >>>>>>> using IF2 automatically
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> I'm not sure what type of applications you have in
> mind.
> > > > > > >>>>> Some of the
> > > > > > >>>>>> most basic applications that I run everyday on my
> laptop
> > > > > > >>>>> are capable
> > > > > > >>>>>> of switching to the next available interface
> > automatically.
> > > > > > >>>>>  I go for
> > > > > > >>>>>> days without restarting anything on my 
> machine between
> > > > > > >>>> Ethernet and
> > > > > > >>>>>> WLAN until memory leaks or something else 
> forces me to
> do
> > > so
> > > > :)
> > > > > > >>>>>
> > > > > > >>>>> But only when one of the interfaces is switched off...
> Not
> > > > > > >>>> in the case
> > > > > > >>>>> where you have both interfaces connected with valid
> > > > > > >>>> addresses at the
> > > > > > >>>>> same time.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> Absolutely not! At the moment I have two interfaces up
> with
> > > > valid
> > > > >
> > > > > > >>>> IP addresses on my laptop.  Also, in the text 
> above, your
> > > step
> > > > 3
> > > > > > >>>> says apps don't switch to using another interface when
> one
> > of
> > > > the
> > > > >
> > > > > > >>>> interfaces loses connectivity even - that is definitely
> not
> > > > true.
> > > > > > >>>>
> > > > > > >>>>>>
> > > > > > >>>>>> In fact, sockets APIs have provisions for 
> applications
> to
> > > > bind
> > > > > > >>>>>> to specific interfaces and IP addresses - 
> so, there is
> no
> > > > > > >>>>> limitation on
> > > > > > >>>>>> even using multiple interfaces 
> simultaneously, provided
> > the
> > > > > > >>>>>> applications wish to be smart about it.  This
> capability
> > > has
> > > > > > >>>>>> been around since the days I first did socket
> programming
> > -
> > > > so,
> > > > >
> > > > > > >>>>>> we are talking over a decade now at a minimum :)
> > > > > > >>>>>
> > > > > > >>>>> What you can do and what is the behavior of an
> unmodified
> > > > > > >>>> host is the
> > > > > > >>>>> issue here. We can do many things with 
> additional SW on
> > the
> > > > > host.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> I think we have a big misunderstanding here 
> about what an
> > > > > > > "unmodified"
> > > > > > >>>> host is, for the context we are talking about.
> Unmodified
> > > > hosts
> > > > > > >>>> don't imply that new applications aren't written on it.
> > > > > > >>>>  In the context of relevance here, we are referring to
> > hosts
> > > > that
> > > > >
> > > > > > >>>> don't have their IP stacks modified to do anything
> > different
> > > > from
> > > > >
> > > > > > >>>> IETF standards compliant behavior.
> > > > > > >>>>
> > > > > > >>>> If you have been taking unmodified hosts to imply that
> they
> > > > don't
> > > > >
> > > > > > >>>> even have application software on them, I think we have
> to
> > > > start
> > > > > > >>>> over here.
> > > > > > >>>> Writing applications that bind to specific 
> addresses or 
> > > > > > >>>> interfaces has nothing to do with 
> modifications of the IP
> > > stack
> > > > > > >>>> itself.  With absolutely no changes to IP stacks, hosts
> can
> > > use
> > > > > > >>>> multiple interfaces simultaneously today.
> > > > > > >>>>
> > > > > > >>>> Vidya
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> _______________________________________________
> > > > > > >>>> netlmm mailing list
> > > > > > >>>> [e-mail]
> > > > > > >>>> https://www1.ietf.org/mailman/listinfo/netlmm
> > > > > > >>>>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> netlmm mailing list
> > > > > > >> [e-mail]
> > > > > > >> https://www1.ietf.org/mailman/listinfo/netlmm
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > netlmm mailing list
> > > > > [e-mail]
> > > > > 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 
> > > > [e-mail] -- and destroy all copies of this
> > > message
> > > > and any attachments without reading or disclosing their 
> contents.
> > > Thank
> > > > you."
> 
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 


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