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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 11 Oct 2007 05:49:16 -0400

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:[email-masked]]
> Sent: Thursday, October 11, 2007 4:56 PM
> To: Basavaraj Patil; Narayanan, Vidya; Thomas Narten
> Cc: Christian Vogt; NetLMM Mailing List
> Subject: RE: Link and Addressing Models
> (RE:[netlmm]Proposedtextformultihoming)
> 
> 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... 

> 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

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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 11 Oct 2007 20:42:18 -0700

Hi Kuntal,

> 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

> "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."

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 12 Oct 2007 00:43:44 -0400

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

> Sent: Friday, October 12, 2007 12:42 PM
> To: Chowdhury, Kuntal; Basavaraj Patil; Narayanan, Vidya; Thomas
Narten
> > > > The MN may attach via a second interface to a network which is
in
> a
> > > > assigned an LMA which is different as well in which case there
is
> no

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 12 Oct 2007 01:56:15 -0400

Hi Gerardo,

Please see inline....

BR,
Kuntal

> Sent: Friday, October 12, 2007 2:17 PM
> To: Chowdhury, Kuntal
> Cc: NetLMM Mailing List
> 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" :-)
> 
[KC>] The issue is getting mixed up with many arguments around
multi-homing which is not really "inter-access technology handover".
There are also references to the MN accessing the same PMIP6 domain with
two interfaces which is not really inter-access handover. So, it is
necessary to know what exactly you have in mind. Sorry for being
pedantic here.

> 
> 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.
> 
[KC>] Sorry for missing that and thanks for re-clarifying the
description of the issue for us. Hope this will stick for a while. 

So, it is really multi-homing then. Therefore, let's keep inter-access
technology handover out of the picture.

> 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.
> 
[KC>] Let me ask you: how does an unmodified UE (MN in IETF terms) knows
that it wants to do multi-homing? What does it do to convey that
intention to the network?

> 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.
> 
[KC>] Yes...what else will the MN do? In DHCP it includes a different
client identifier option w/ appropriate DUID to obtain addresses and
config parameters over its interfaces.

> 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.
> 
[KC>] Agreed... Nobody said it otherwise. The proposed text from Raj and
Sri clarifies how that goal is achieved.

> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Friday, October 12, 2007 6:44 AM
> > To: Giaretta, Gerardo
> > Cc: NetLMM Mailing List
> > have two interfaces up while load balancing between the interfaces
or
> > > > > > 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
> > > > > I think the proposal is going into the right direction. I
think
> it
> > > > > 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
> > > > [KC>] if the MN wants to be multi-homed, it will use different
NAI
> > > without knowledge of PMIPv6 would not behave in this way. Sorry
but
> > > > > 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
> > > > access-technology indication that is different than the one in
BCE
> > > will
> > > > > > different PMIP6 domain in which case the LMA is different
and
> > > hence
> > > > > > 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
> > > > > 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
> > > > [KC>] This is a very impractical scenario, IMHO. Even in this
kind
> > of
> > > > impractical scenario, the LMA has the option of rejecting the
PBU
> > > > > > 2 is the same. If the LMA policy is to assign the same
prefix
> > > > > As said, it is not clear to me from where this LMA policy
comes
> > > > > > saying that multioming is not supported. And we believe that
> it
> > is
> > > > > > This can be solved eventually when we have simultaneous
> binding
> > > type
> > > > > > of capability and a more comprehensive solution to
multihoming
> > > > > > is the only solution is puzzling. And we are actually
allowing
> > > > > > > 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
> > > > > > > Based on a per-interface prefix model, this restriction
> would
> > > not
> > > > > occur.
> > > > > > > The question is: which is the rationale of this
restriction?
> I
> > > > > > >> - Disallow the LMA from creating the BCE for an MN
> attaching
> > > via
> > > > > > > another
> > > > > > >> interface (access tech type) until it has received a
dereg
> > > > > > >>>>>>> 1. IPv4 networks with the host attaching via IF1
first
> > > > > > >>>>>> WLAN until memory leaks or something else forces me
to
> do
> > > so
> > > > > > >>>> 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
> > > > >
> > > > > > >>>>>> 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,
> > > > >
> > > > > > >>>>> issue here. We can do many things with additional SW
on
> > > > > > >>>> interfaces has nothing to do with modifications of the
IP
> > > stack
> > > > > > >>>> itself.  With absolutely no changes to IP stacks, hosts
> can
> > > use
> > > > Starent Networks, Corp. The information transmitted may not be
> used
> > to

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 11 Oct 2007 23:03:58 -0700

Hi Kuntal,

> technology handover out of the picture.

The inter-technology handover was brought into the picture by Raj and
Sri in their solution description. They mentioned that the same prefix
can be used for two different interfaces in order to enable
inter-technology handovers.

> intention to the network?

It does not need to do anything. It just attaches to the network with
two interfaces and gets two different IP addresses and it is
multi-homed!

This is how current nodes work when you plug in a new interface. This is
why the per-interface prefix model keeps the same model and solves the
issue.

Gerardo

> > > inter-technology handover or support for unmodified hosts that
want
> > > > > > wants to be multi-homed and to use two different interfaces
or
> > > wants
> > > > > 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
> > > > > internet type of application as well. The PBU with the same
NAI
> > with
> > > > > > > The MN may attach via a second interface to a network
which
> > > > > > > interfaces to the same PMIP6 domain and the LMA assigned
to
> > > serve
> > > > > > > > see any reason for this restriction in the scope of
NETLMM
> > WG.
> > > > > > > >>> devices have stable IP connectivity via at least one
of
> > > > > > > >>> Supporting the use of multiple interfaces
simultaneously
> > > comes
> > > > > > > >>> later
> > > > > > > > -
> > > > > > > >>> while that is also feasible on hosts with unmodified
IP
> > > > > > > >>>>> Subject: Re: Link and Addressing Models (RE:
[netlmm]
> > > > > > > >>>>>>> applications 2. Second interface comes up and has
a
> > > > > > > >>>>> But only when one of the interfaces is switched
off...
> > Not
> > > > > > > >>>> Absolutely not! At the moment I have two interfaces
up
> > with
> > > > > > > >>>> interfaces loses connectivity even - that is
definitely
> > > > > > > >>>> I think we have a big misunderstanding here about
what
> > > > > > > >>>>  In the context of relevance here, we are referring
to
> > > > > > > >>>> If you have been taking unmodified hosts to imply
that
> > they
> > > > > don't
> > > > > >
> > > > > > > >>>> even have application software on them, I think we
have
> > > > > entities other than the intended recipient is prohibited. If
you
> > are
> > > > not
> > > > > the intended recipient, please notify the sender immediately
--
> by

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 12 Oct 2007 03:11:36 -0400

> Sent: Friday, October 12, 2007 3:04 PM
> To: Chowdhury, Kuntal
> Cc: NetLMM Mailing List
> > > to read or understand. Quoting Vijay, I think this is the fifth
time
> inter-technology handovers.
[KC>] What has been proposed by Raj/Sri works. They covered your
scenario too, right?

> why the per-interface prefix model keeps the same model and solves the
[KC>] OK, now what makes you think that it would be any different if
PMIP6 is used? Note that the MN needs to provide some credential(s) to
attach to the "network" (wild imaginations aside....). Whatever
credential(s) used by the MN to attach to the "network" will be used by
the LMA or DHCP server to assign address (es)/prefix (es) to the MN.
Note, I am strictly talking about multi-homing here.

> > > > Please tell us clearly what the problem scenario is?
Multi-homing
> > > > > > > It is not clear to me how the LMA could decide to assign
the
> > > > > > > perform a handover? I don't see any way here for the user
to
> > > > convey
> > > > > > provide ample clue to the LMA regarding what the MN intends
to
> > do.
> > > > > > > > The insistence by several folks that
per-interface-prefix
> > > > > assignment
> > > > > > > > > Based on your proposal, a host cannot be multi-homed
in
> > > > > > > > >> - MAG1 would send the dereg only when it has
confirmed
> > (via
> > > > > > > > >> This would ensure that the MN is connected via only
one
> > > > > interface
> > > > > > > > >>> active interfaces today.  That bare minimum is what
we
> > > > > > > > >>>>>> I'm not sure what type of applications you have
in
> > > mind.
> > > > > > > > >>>> Writing applications that bind to specific
addresses
> > > > > > Any review, retransmission, dissemination or other use of,
or
> > > taking
> > > > > of
> > > > > > any action in reliance upon this e-mail and its attachments
by
> > > > persons