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

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 11 Oct 2007 22:16:54 -0700

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:[email-masked]]
> 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:[email-masked]]
> > 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"
> > > <[email-masked]>
> > > > > 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:[email-masked]]
> > > > > >> 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"
> > <[email-masked]>
> > > > > > 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:[email-masked]]
> > > > > >>>> 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:[email-masked]]
> > > > > >>>>> 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"
> > > > > >>>>> <[email-masked]> 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
> > > > > >>>> [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
> > >
> > >
> > > "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."

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Oct 2007 06:56:56 -0500

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

> Sent: Friday, October 12, 2007 7:17 AM
> To: Chowdhury, Kuntal
> Cc: NetLMM Mailing List
> 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
> 
> 
> > > > > > Only in such a scenario are we saying that 
> multioming is not 
> > > > > > supported. And we believe that
> it
> > is

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Oct 2007 07:09:25 -0500

Hi Gerardo,

I may add that my text is related to the sticky issue of multiple
interfaces for the same access type. I should have made that clear to
avoid confusion. My apologies.

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Friday, October 12, 2007 1:57 PM
> To: Giaretta, Gerardo; Chowdhury, Kuntal
> Cc: NetLMM Mailing List
> 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
> 
> > 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" :-)
> > 
> >