Subject: [netlmm] Proposed text for multihoming

From: Basavaraj Patil <[email-masked]>
Date: Sat, 06 Oct 2007 23:33:10 -0500

Hello,

The issue about multihoming of hosts has caused significant discussion but
no real resolution yet. We still believe that capturing the issues w.r.t
PMIP6 for multihomes hosts and guidelines should be sufficient in the
context of the current draft. A complete solution to the multihoming issue
in the PMIP6 context should be done as a separate specification.

However in the interest of making progress, we are proposing the following
text below describing multihoming. We hope that the following text will be
sufficient for the base protocol specification and allow us to move forward.

-Basavaraj
==============================================

Terminology:

Multihomed MN      
           
      A mobile node (MN) which connects via multiple interfaces to
      access networks simultaneously and has a valid and routable
      IP address assigned to each of the interfaces is defined as
      a multihomed MN.

Sec X.Y Multihomed mobile nodes

  A mobile node with multiple interfaces may connect via these
  interfaces to the access networks  simultaneously. The access
  router to which the MN attaches via an interface may be a MAG in a
  PMIP domain. When the MN attaches to a MAG and completes access
  authentication, the MAG sends a Proxy Binding update (PBU) to the
  appropriate LMA. The LMA creates an entry in the binding cache upon
  successful processing of the PBU and sends a Proxy Binding
  Acknowledgment (PBAck) to the MAG. Several multihoming scenarios in
  the context of PMIP6 are considered below:

  Scenario 1:

  A Mobile Node (MN) with interfaces IFx and IFy attaches to a PMIP6
  domain via MAGx and MAGy. The MN-ID used to identify the MN on each
  of the interfaces is unique. The LMA assigned to the MN on
  interfaces IFx and IFy is the same. The LMA which receives a PBU
  from MAGx and MAGy with unique MN-IDs assigns a unique prefix to
  each of the interfaces and sends this in the PBAck to the respective
  MAGs. The LMA creates separate binding entries for each of the
  prefixes in the binding cache. The MN which receives the prefixes
  via an RA from MAGx and MAGy on interfaces IFx and IFy will configure
  a unique address for each interface and operate as a multihomed host.

  Scenario 2:
  
  A Mobile Node (MN) with interfaces IFx and IFy attaches to a PMIP6
  domain via MAGx and MAGy. The MN-ID used to identify the MN on each
  of these interfaces is the same. If the MN attaches to the network
  via IFx first, the LMA has an entry for the MN in the binding cache
  for MAGx. If the MN attaches via IFy to MAGy, it will send a PBu to
  the LMA. The LMA can determine if the PBU being received which has
  the same MN-ID is from a different interface of the MN via the
  Access network technology type option included in the PBU which is
  defined below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |   Length      |AccessTech Type|  Prefix Len   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                    Home Network Prefix                        +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Access Tech Type:
          0          Reserved
          1        802.3
          2          803.11
          3          802.16e
          4          PPP

    Values 1-127 will be allocated by IANA. Values 128-256 are reserved
    for private use.

   The Access technology type option in the PBU provides the LMA with
   additional information via which it can choose the prefix to be
   sent to the MN via the PBAck. The prefix that is sent to the MN is
   based on the LMA policy. If the LMA had assigned prefix Px to the
   MN via MAGx to interface IFx, it can assign the same prefix Px to
   the MN via MAGy to interface IFy when the MN attaches via IFy. The
   LMA can also assign a different prefix to each of the intefaces.
   The decision of which prefix to assign is a policy of the LMA. The
   LMA may take in to account information about the mobile node before
   making a decision.

   In the scenario where the LMA assigns the same prefix (as assigned
   to the MNs interface IFx via MAGx) to the MNs interface IFy via
   MAGy, the LMA will replace the binding cache entry from MAGx to
   MAGy. The address configured by the MN which receives the prefix is
   MN implementation specific. The MN is unaware of MAGx no longer
   being a valid downlink node. It may continue to use IFx for sending
   packets on the uplink. MAGx may forward the packets to the LMA. The
   behavior of the LMA in the case of receiving packets from an MN via
   MAGx which is no longer in the binding cache can vary:
   - It can drop the packets or
   - It can forward them for a brief duration of time (configurable
   value)
   Hence the multihomed MN may be able to send packets via either
   interface for a brief period of time. It is possible in the future
   that the LMA can send a binding revocation notification to MAGx
   when it successfully processes a PBU from MAGy and prior to
   swapping the BCE from MAGx to MAGy for MN which is identified by
   MN-ID. It is possible that an MN which connects via multiple
   interfaces to a PMIP6 domain may have only a single valid interface
   for the transmission of packets. Any ongoing IP session via a previous
   interface may be affected.

   In some scenarios, MAGx and MAGy may keep sending PBUs to the LMA
   as a result of which there is oscillation of the BCE in the LMA
   between the MAGs. In this case, the LMA, when it detects this
   oscillation, starts rejecting the Proxy Binding Updates from one
   of the MAGs.  The mobile node will have connectivity through only
   one MAG. This issue can be mitigated via the use of binding
   revocation mechanism [draft-muhanna], which would help in the LMA
   detecting the oscillation quickly.

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

---

From: "John.zhao" <[email-masked]>
Date: Mon, 08 Oct 2007 12:22:33 +0800

Hi,basavaraj and all

	I think the scenario 1 you mentioned is just the MHoA, on the
contrary the scenario 2 is the MCoA.That seems more direct and well-known
than the word of scenario number x. And we can discuss if there is any other
new scenario than these?
	Best Rgds,
Thanks,
John.zhao

> -----邮件原件-----
> 发件人: Basavaraj Patil [mailto:[email-masked]]
> 发送时间: 2007年10月7日 12:33
> 收件人: [email-masked]
> 主题: [netlmm] Proposed text for multihoming
> 
> 
> Hello,
>

---

From: "John.zhao" <[email-masked]>
Date: Mon, 08 Oct 2007 13:15:07 +0800

Sorry for some corrections by myself. That scenario 2 is also the
MHoA scenario. But since we are discussing about the multi-homing of PMIP,
thus the MCoA seems also need to be considered. In deed, the MCoA is also a
possible scenario to PMIP.
	Best Rgds,
Thanks,
John.zhao

---

From: Christian Vogt <[email-masked]>
Date: Mon, 08 Oct 2007 09:38:13 +0300

>                         We still believe that capturing the issues
> w.r.t PMIP6 for multihomes hosts and guidelines should be sufficient
> in the context of the current draft.

Raj,

I don't think the multi-homing issue can be solved by adding an extra
section to the P-MIPv6 specification.  It can be solved by a conceptual
move from the current per-mobile-host home prefix model to a
per-interface home prefix model.  This will require a revision of the
existing P-MIPv6 specification text, though.

Some folks believe that the per-interface home prefix model is more
restrictive than the per-mobile-host home prefix model.  This is a
misconception because the per-interface home prefix model does not
prevent the assignment of the same home prefix to different interfaces.
  On the contrary, by reducing the granularity of a home prefix, the
per-interface home prefix model increases deployment flexibility.

Support for the same home prefix on multiple interfaces can be provided
in two ways, independent of the per-interface home prefix model:

(1)  Support for the same home prefix on multiple interfaces

      This will make an IPv6 host believe that multiple of its interfaces
      attach to the same (home) link.  Standard IP address configuration
      mechanism will make the mobile host configure a unique home address
      on each interface.  This technique requires a departure from the
      point-to-point model, because the point-to-point model implies that
      each interface of a mobile host is on a different link, and the
      IPv6 addressing architecture disallows the use of the same prefix
      on different links.

(2)  Support for the same home address on multiple interfaces

      This requires interface virtualization because, in IP, an address
      can identify at most one interface.  The interface virtualization
      won't require changes to the P-MIPv6 specification.  A single,
      virtual interface will be presented to the mobile host's IP layer,
      and it will be identified in P-MIPv6 by a single interface ID.

I personally favor technique (1) because -- in contrast to the text you
have proposed in your previous email -- it enables simultaneous
*bidirectional* use of multiple interfaces:  A mobile host sends packets
from different interfaces using separate home addresses, and an LMA can
demultiplex packets for the mobile host, and route them to the right
interface, based on the home address to which the packets are destined.

Technique (2) makes it more challenging for an LMA to demultiplex
packets for a mobile host because all of the packets are destined to a
single home address.  Unless additional information such as a flow label
is used for demultiplexing the packets, the LMA will likely route all of
the packets to a single (physical) interface of the mobile host.

Neither of the two techniques should IMO be included in the P-MIPv6 base
specification, but should (if at all) be handled as an extension.  This 
will avoid additional delays in publishing the base specification.

Regards,
- Christian

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 8 Oct 2007 15:42:30 +0200

Hi Raj,

thanks for providing a new text to overcome the multihoming issue.
Please find two comments below... 

>   Access network technology type option included in the PBU which is

Do you assume that the "Access network technology type option" is always
included in the PBU?  According to the above description this option is
included only in scenario 2, but then how does the MAGy know, if the
MN-ID is unique per interface or not?  
I think the "Access network technology type option" shall be included in
each PBU (at leas in each first PBU sent by the MAG for a particular
MN), unless the MN-ID has a radio technology-specific format. 

Further, the  described scenarios presume that a MAG serves a different
access technology. This may be the case for 3GPP deployments, but I'm
not sure if deployments exist where one MAG may serve different radio
technologies... In such case the MAG must be aware about the radio
technno used by the MN.

Genadi

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 8 Oct 2007 16:19:38 +0200

Hi Christian, 

> prevent the assignment of the same home prefix to different 

I don't see much difference between your text and Raj's text proposal
from a higher perspective. The per-interface HNP model presumes that a
unique HNP is assigned per interface. However, in your email you brake
this model and allow the LMA to assign the same HNP to multiple
interfaces. OTOH the current PMIPv6 draft specifies the per-MN HNP where
the same prefix is assigned to an MN. However, according to Raj's
proposal it is now allowed to assign a unique prefixes to each
interface. IMO, it is just conceptual difference. Am I missing
something?

> interface, based on the home address to which the packets are 

I think it is also possible to have bidirectional communication
according to the Raj's text proposal where the MN configures different
addresses (on the different interfaces) based on the same prefix. The
LMA can have different BCEs for each address. It is not described in the
proposed text, but it can be included.  The point is, whether the base
specification should allow multiple simultaneous BCEs in the LMA for one
MN?  Or should this feature be specified later? I think it should be
specified later when we address the multihoming support in PMIP.

Genadi

---

From: "Kalin Getov" <[email-masked]>
Date: Mon, 08 Oct 2007 16:59:38 +0200

Hi Genadi, Raj,

sorry for jumping in...see inline

> technologies... In such case the MAG must be aware about the radio

[KG] There was such proposal from Lucent within the ScaleNet project, the so called UR (unified router) should be able to serve different RATs. I don't really know exactly how far this proposal is gone...maybe its just on paper...

Regards,
Kalin

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 Oct 2007 08:39:02 -0700

> MN), unless the MN-ID has a radio technology-specific format. 

It is included in every Proxy BU.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 12:47:27 -0500

Hi Christian,

On 10/8/07 1:38 AM, "ext Christian Vogt" <[email-masked]>
wrote:

> section to the P-MIPv6 specification.

As I wrote earlier, a complete solution for multihoming in the PMIP6 context
should be specified separately. What the text we have proposed is "a"
solution that is not comprehensive but works.

> It can be solved by a conceptual

We do not want to mandate a per-interface prefix mode of operation. The
proposal allows the LMA to determine whether to allocate a unique prefix for
the MN or the same one.

> per-interface home prefix model increases deployment flexibility.

Not sure I understand your statement above. But anyway instead of stating
what folks believe in, it is better to comment on whether any flexibility is
diminished by the proposal.

>       and it will be identified in P-MIPv6 by a single interface ID.

Both of the above points have been discussed on the ML and we are aware of
this.

> the packets to a single (physical) interface of the mobile host.

Obviously there are several ways to solve the problem. We have proposed one
that IMO is sufficient in the scope of the base spec. Other solutions such
as simultaneous binding (based on MONAMI6 work) can be considered when this
issue is dealt with in a separate I-D.
I am not sure from your email if you have an issue with the proposed text
and solution.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 10:55:06 -0700

Christian,
I mostly concur with your notes below.  A few points inline. 

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Sunday, October 07, 2007 11:38 PM
> To: Basavaraj Patil
> Cc: NetLMM Mailing List
> Subject: Re: [netlmm] Proposed text for multihoming
> 
> I don't think the multi-homing issue can be solved by adding 
> an extra section to the P-MIPv6 specification.  It can be 
> solved by a conceptual move from the current per-mobile-host 
> home prefix model to a per-interface home prefix model.  This 
> will require a revision of the existing P-MIPv6 specification 
> text, though.
> 

Fully agree with the above. 

> Some folks believe that the per-interface home prefix model 
> is more restrictive than the per-mobile-host home prefix 
> model.  This is a misconception because the per-interface 
> home prefix model does not prevent the assignment of the same 
> home prefix to different interfaces.

I agree with the misconception part, although, coming at it from a
slightly different angle.  From all the emails, it appears that the
misconception relates to assuming that a per-interface prefix model
restricts the use of NETLMM for inter-technology handoffs, as envisioned
in some SDOs.  This isn't true.  Support for inter-technology handoffs
using NETLMM is going to require some changes to the end host,
regardless of the addressing model.  As has been pointed out in many
emails now, without changes to the host, this is not feasible.  Such
changes may well be in scope of other SDOs, even though it is not in
scope at the IETF. 

But, once the end host changes are a given, the per-interface prefix
model doesn't cause any restriction.  The changes to the end host will
ensure that the interface presented at the IP level looks like the same
one, hence, resulting in the same prefix.  

OTOH, the per-interface prefix model allows unmodified IP hosts to
function without issues, while the per-MN prefix model causes issues to
such hosts.  So, the former allows greater flexibility where it works
for unmodified hosts and takes nothing away from the support of
inter-technology handoffs. 

>   On the contrary, by reducing the granularity of a home 
> prefix, the per-interface home prefix model increases 
> deployment flexibility.
> 

Agreed, as I've also concluded above :) 

On the points you have below, I agree that this can be dealt with
outside the base spec, either in other SDOs as an enhancement for their
specific deployment or at the IETF as an extension.  Causing any
deviation from the point-to-point link model is likely to raise further
questions at this time.  

Vidya

> Support for the same home prefix on multiple interfaces can 
> be provided in two ways, independent of the per-interface 
> home prefix model:
> 
> I personally favor technique (1) because -- in contrast to 
> the text you have proposed in your previous email -- it 
> enables simultaneous
> *bidirectional* use of multiple interfaces:  A mobile host 
> sends packets from different interfaces using separate home 
> addresses, and an LMA can demultiplex packets for the mobile 
> host, and route them to the right interface, based on the 
> home address to which the packets are destined.
> 
> Technique (2) makes it more challenging for an LMA to 
> demultiplex packets for a mobile host because all of the 
> packets are destined to a single home address.  Unless 
> additional information such as a flow label is used for 
> demultiplexing the packets, the LMA will likely route all of 
> Neither of the two techniques should IMO be included in the 
> P-MIPv6 base specification, but should (if at all) be handled 
> as an extension.  This will avoid additional delays in 
> publishing the base specification.
> 
> Regards,
> - Christian
> 
> 
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 Oct 2007 10:58:42 -0700

> (2)  Support for the same home address on multiple interfaces

Is this for an inter-access technology handover or simultaneous use of 
multiple interfaces?

>      and it will be identified in P-MIPv6 by a single interface ID.

Note that for inter-access technology handover, you don't need to 
implement a virtual interface on the mobile node.

Vijay

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 8 Oct 2007 13:37:42 -0500

Hi Raj, I support scenario 2.

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Saturday, October 06, 2007 11:33 PM
To: [email-masked]
Subject: [netlmm] Proposed text for multihoming

Hello,

The issue about multihoming of hosts has caused significant discussion
but no real resolution yet. We still believe that capturing the issues
w.r.t PMIP6 for multihomes hosts and guidelines should be sufficient in
the context of the current draft. A complete solution to the multihoming
issue in the PMIP6 context should be done as a separate specification.

However in the interest of making progress, we are proposing the
following text below describing multihoming. We hope that the following
text will be sufficient for the base protocol specification and allow us
to move forward.

-Basavaraj

Terminology:

Multihomed MN      

  Scenario 1:

  Scenario 2:

    0                   1                   2                   3

    Access Tech Type:
          0          Reserved
          1        802.3
          2          803.11
          3          802.16e
          4          PPP

   for the transmission of packets. Any ongoing IP session via a
previous

---

From: Christian Vogt <[email-masked]>
Date: Mon, 08 Oct 2007 22:44:36 +0300

Raj,

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.

This holds independent of whether the point-to-point model is combined 
with the per-interface or the per-mobile-host home prefix model.

The issue with the point-to-point model is that multiple interface of a 
host are on separate links, in which case the IPv6 addressing 
architecture disallows the use of the same prefix on these interfaces.

Use of the same home prefix on multiple interfaces therefore requires 
departure from the point-to-point model.

All of the scenarios in your text are already based on the per-interface 
home prefix model.  And the one scenario that considers use of the same 
home prefix on multiple interfaces...

>    being a valid downlink node. [...]

...already departs from the point-to-point model.  In fact, your entire 
text is in-line with what I am saying.

However, the scenario cited above does not give an LMA functionality for 
handling multiple interfaces on a multi-homed  host.  This is why the 
scenario supports bidirectional operation of only a single interface of 
the host, the other interfaces being operated in unidirectional mode.  I 
don't think this is mature.  If we handle this as a P-MIPv6 extension 
rather than as part of the base specification, we will have time to 
develop something mature.

My suggestion:  Adopt the per-interface home prefix model, and for now 
assume that each interface gets a separate home prefix.  Once the base 
specification is out, we will develop a mature extension that enables 
the use of the same home prefix on different interfaces.

- Christian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 14:43:47 -0700

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

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 16:48:04 -0500

Christian,

> departure from the point-to-point model.

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.

> assume that each interface gets a separate home prefix.

Nope. I do not believe what we are suggesting is broken and we are not
changing the link model or impacting the IPv6 addressing architecture.

Suggestion would be to incorporate the text proposed as the guidelines for
dealing with multihoming in PMIP6. And work separately on a comprehensive
solution for multihoming in PMIP6.

-Raj

> Once the base

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 16:55:15 -0500

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

"

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 17:07:01 -0500

Hi John,

Not sure I understand your comment about the scenario numbering or MHoA and
MCoA. Basically the text shows the possibilities w.r.t multihoming.
I think these are the basic scenarios to consider for the base protocol. We
could delive into more if and when work on multihoming is undertaken by the
WG.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 17:10:35 -0500

Hi Genadi,

> MN), unless the MN-ID has a radio technology-specific format.

I guess Vijay already clarified that the option is included in every PBU.

> technologies... In such case the MAG must be aware about the radio

In the case where you have a single MAG serving multiple access types, the
MAG would still be aware over which interface the MN is attaching. The MAG
would be configured with the access type associated with an interface.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 15:22:40 -0700

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

> 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.
> 
> We recognize the link model in use for PMIP6 and do not 
> believe that we are breaking it. And here is why:
> 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 
> 
> 
> >> 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.
> >

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 17:36:11 -0500

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 15:42:00 -0700

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 

> Sent: Monday, October 08, 2007 3:36 PM
> 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
> 
> > 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
> > 
> >> 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
> with prefix 
> >> lifetime=0). Of course revocation is planned to be 
> specified in the 
> >> future.
> >>

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 18:00:08 -0500

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?
- 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 18:02:27 -0700

Hi Raj,

> Sent: Monday, October 08, 2007 4:00 PM
> 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.
> 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
> 
> 
> > 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.
> > 
> >> 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).
> lifetime=0 
> >> is one way. Details as you mention need to be worked out 
> separately.
> >> 
> >> protocol. I think you do recognize that the issue needs to 
> be worked 
> >> on separately for a more complete solution.
> >> 
> >> -Raj
> >> 
> >>>> When the LMA assigns the same prefix to MAG2, it deletes 
> the entry 
> >>>> for MAG1.

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Oct 2007 21:42:04 -0500

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.

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 21:06:06 -0700

Hi Raj,
I think the difference here is that you are suggesting that an option to
assign a unique prefix per interface is good enough to support
unmodified hosts, while I think this needs to be conceptually adopted in
the protocol design and not an option for sake of interoperability and
supporting a mix of modified and unmodified hosts in a PMIP domain. 

If it is not about inter-technology handoffs and the idea is to define a
protocol for unmodified hosts, could you please outline the restrictions
you see with the per-interface prefix model?  I understood the concern
as being about inter-technology handoffs.  Sorry if I missed other
concerns already stated. 

Thanks,
Vidya 

> Sent: Monday, October 08, 2007 7:42 PM
> 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.
> 
> 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 
> 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
> 
> 
> >> Indeed, I guess we differ on how much (additional) functionality 
> >> needs to be in the base spec to handle the unmodified multihomed 
> >> host.
> >> 
> > 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.
> > 
> > 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.
> > 
> > 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.
> >> accomplished. The concern was about handling a multihomed host and 
> >> the text provides a mechanism for that.
> >> 
> >> -Raj
> >> 
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 8 Oct 2007 22:10:46 -0700 (PDT)

Vidya,

I dont see this thread going anywhere. I think, you have some architecture
in mind and you are not able to see beyond that. Fair enough.

IMO, we have made best efforts to close this issue in the right way. I
already stated my opinion about multi-homing and the requirements for
supporting multi-homing. The text that Raj proposed is many steps forward
in efforts to closing this issue. We dont believe any one will deploy
multi-homing as you are thinking. We really dont need to bring unique
prefix allocation for adressing this issue. We can simply switch the
logic on the LMA, by letting it accept the PBU for a NAI that has a
BCE, only after receiving a dereg message for the same NAI from the
prev MAG. That will fix the issue, it just allows only one interface
to be active. But, we dont believe to get into solution space as any
solution can be pulled into endless discussions.

I believe Jari is monitoring this thread and Jonne as well. Number of
people have expressed their opinions on this topic and we all know the
what the WG thinks. I hope Jonne will go for the consensus call soon
and put a closure to this.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 23:07:04 -0700

Sri,
I see a number of people supporting the idea about just adding a section
with some text in it and moving on, but, I'm yet to see a clear
description of the issues with the proposed solution for actually
addressing the problem.  All descriptions pointed to concerns related to
inter-technology handoffs, except, the email from Raj below indicates
that it is not about that.  I'm perplexed to see this widespread
dismissal of the problem.  The per-interface prefix model has now been
proposed by at least a few people on this list and also by Erik, as part
of the outside review of the problem.   

And, when you write things like "We dont believe any one will
deploy...", it would be good to clarify who all you are speaking for. 

Vidya

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Monday, October 08, 2007 10:11 PM
> To: Narayanan, Vidya
> Cc: Basavaraj Patil; Christian Vogt; NetLMM Mailing List
> Subject: RE: Link and Addressing Models (RE: [netlmm] 
> I dont see this thread going anywhere. I think, you have some 
> architecture in mind and you are not able to see beyond that. 
> Fair enough.
> 
> IMO, we have made best efforts to close this issue in the 
> right way. I already stated my opinion about multi-homing and 
> the requirements for supporting multi-homing. The text that 
> Raj proposed is many steps forward in efforts to closing this 
> issue. We dont believe any one will deploy multi-homing as 
> you are thinking. We really dont need to bring unique prefix 
> allocation for adressing this issue. We can simply switch the 
> logic on the LMA, by letting it accept the PBU for a NAI that 
> has a BCE, only after receiving a dereg message for the same 
> NAI from the prev MAG. That will fix the issue, it just 
> allows only one interface to be active. But, we dont believe 
> to get into solution space as any solution can be pulled into 
> endless discussions.
> 
> I believe Jari is monitoring this thread and Jonne as well. 
> Number of people have expressed their opinions on this topic 
> and we all know the what the WG thinks. I hope Jonne will go 
> for the consensus call soon and put a closure to this.
> 
> 
> Sri
> 
> 
> 
> 
> 
> > I think the difference here is that you are suggesting that 
> an option 
> > to assign a unique prefix per interface is good enough to support 
> > unmodified hosts, while I think this needs to be 
> conceptually adopted 
> > in the protocol design and not an option for sake of 
> interoperability 
> > and supporting a mix of modified and unmodified hosts in a 
> PMIP domain.
> >
> > If it is not about inter-technology handoffs and the idea 
> is to define 
> > a protocol for unmodified hosts, could you please outline the 
> > restrictions you see with the per-interface prefix model?  I 
> > understood the concern as being about inter-technology handoffs.  
> > Sorry if I missed other concerns already stated.
> >
> > Thanks,
> > Vidya
> >
> 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.
> >>
> interface 
> >> active. This is a limitation that I think is acceptable in the 
> >> context of this I-D.
> >>
> >> We do not propose to change the charter or the scope of 
> the current 
> >> charter.
> 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
> >>
> >>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 9 Oct 2007 01:58:12 -0700

Raj,

There seems to be an assumption by some that as soon as revocation is
defined for PMIP, the problem with unmodified multihoming hosts is
solved. As I believe it has been explained a few times already, this is
simply not true.

It is not true because PMIP revocation can not *instantaneously* result
in removal of an allocated IP address from an interface in the mobile.
Moreover, there is no way to even know at what point the IP address is
removed from an Interface. More specifically:

	- For IPv4 addresses, e.g., allocated via DHCPv4, there is no
way to revoke an address prior to the Lifetime provided to the mobile at
the time the address was allocated. So, in that case, as far as I can
tell, PMIP revocation does not help at all.

	- For IPv6 with DHCPv6 based address allocation, this is again a
problem. According to PMIPv6 draft, the MAGs are DHCP Relay agents which
means that they can not even send a reconfigure command to the mobiles.
Given that, PMIP revocation does not help at all in this case either.

	- For IPv6 with stateless autoconfig, an RA with Prefix Valid
lifetime=0 can indeed revoke a prefix. This, however, is NOT
instantaneous and there is no way for the MAG or the LMA to know when
the mobile receives and processes the RA message. So an unmodified host
can still end up with the same address on two different interfaces, even
for short time...triggering the error case we have been trying to avoid.

*NOTE: How big an issue this is and exactly what happens after the error
takes place should be the subject for further study, but they are not
really relevant in this discussion since revocation does not work for
DHCPv4/DHCPv6 which are also supposed to be supported by PMIPv6.
 
So the bottom line is that the PMIP revocation mechanism, while helpful
in some cases, is not a panacea and is likely to provide variable
performance depending on the exact deployment scenario and combination
of protocols.

In contrast, the per Interface model, works equally well for both IPv4
and IPv6 and does not depend on variables that are external to PMIP,
like address allocation protocol and transmission delays of particular
access links.

Regards
George
-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 7:36 AM
To: Narayanan, Vidya; Christian Vogt
Cc: NetLMM Mailing List
Subject: Re: Link and Addressing Models (RE: [netlmm] Proposed text
formultihoming)

Hi Vidya,

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 9 Oct 2007 21:48:22 +1100

> for short time...

=> Actually, it might keep it for a long time, until the prefix lifetime
expires. It just won't start new connections using the deprecated address.
So, you were being conservative with the problem, it's even larger than what
you describe for stateless. 

Hesham

triggering the error case we have been 
 > trying to avoid.
 > an MN when it
 > lifetime=0 is
 > protocol. I
 > > This doesn't take care of the fact that from the MN's 
 > point of view,
 > the

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 09 Oct 2007 07:00:48 -0500

Hi Vidya,

> supporting a mix of modified and unmodified hosts in a PMIP domain.

Yes. The solution that we have proposed basically provides deployments the
ability to choose the type of prefix to be assigned to an MN. If the MN-ID
is different on each interface (access type), the prefix assigned is unique.
If the MN-ID is the same, the the prefix assigned is a policy decision of
the LMA. The policy by which an LMA decides to allocate either the same
prefix or a unique prefix is out-of-scope (it may have out of band
mechanisms such as additional information from the AAA as an example). The
option which indicates the access technology type in the PBU provides the
LMA additional information about the interface via which an MN is attaching
to the network. We are also mitigating the issue of the MN being in a
confused state (when the same prefix is assigned to IF2) by rescinding the
preface assigned to the previous interface (IF1). Hence I believe this is an
acceptable solution.

> as being about inter-technology handoffs.

Inter-technology discussion in the context of this thread is really
orthogonal. The issue that you raised is one about multinterface hosts which
attach to the a PMIP6 domain via more than one interface. I don't believe we
are really trying to address the inter-technology handover issue at all. An
MN attaching via a second interface to a PMIP6 domain may be as a result of
a handover or simply attaching to the network via a secondary interface.
This is of no consequence w.r.t the issue raised and as you have stated we
are not chartered to discuss inter-technology handovers. So I see no reason
to discuss what are the limitations of pre-interface prefix or otherwise.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Oct 2007 14:12:39 +0200

>  support *unmodified* multihomed hosts for PMIP6?

I see it here.

> feature that is essential?

PMIP6 should work as much and even better than MIP6 works, right?  We
don't want a protocol out that people will say it's not as good as MIP6,
right?

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

So you attach a NAI to a interface?  I don't see how otherwise MN could
have two NAIs?

I think MAG should also support a MN with two interfaces of the same
type attached to two of MAGs base stations.  PMIPv6 shouldn't prohibit
this.  Because MIP6 can do this.  If PMIP6 prohibits this then MIP6 is
better than it.

Alex

> 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 
> further specification work. But it provides sufficient guidelines to 
> implementers and deployments.
> 
>> 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] 
>>> 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.
>>> 
>>> lifetime=0 is one way. Details as you mention need to be worked 
>>> out separately.
>>> 
>>>> 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 Subject: Re: Link and Addressing Models (RE: 
>>>>> [netlmm]
>>> Proposed text
>>>>> for multihoming)
>>>>> 
>>>>> 
>>>>> Hi Vidya,
>>>>> 
>>>>>  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
>>>>> revocation. The LMA can send a revocation to MAG1 and MAG1 
>>>>> could revoke the prefix assigned to IF1 (RA
>>> with prefix
>>>>>  IPv6 addressing architecture. "
>>>>> 
>>>>> -Raj
>>>>> 
>>>>> 
>>>>>>> of the same home prefix on different interfaces of a 
>>> combination with
>>>>>> 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
>>>>>> 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
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Oct 2007 14:16:54 +0200

Basavaraj Patil wrote:
[...]
> IETF and lets not get hung up about it.

(?)

I think - and in no way am I trying to ofence anyone - a relatively 
important number of active people here, including active voters, are 
also active in SDO.  So what those people are doing here at IETF will 
also do in SDO.  One can't use left brain for IETF and right brain for 
SDO, neither viceversa.

I think we're already hung up about it.

Alex

>>>>>>> we are breaking it. And here is why:
>>> multi-homed

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 9 Oct 2007 06:56:55 -0700

Hi Raj,

> 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

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
 
> require any host modification or place a requirement on a host. It
allows
> an
> on this topic. You can go ahead and do a consensus call and move
forward
> and
the
> > And, on your notes below, I think I have made my take sufficiently
clear

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Oct 2007 17:25:12 +0300

Let me state some requirements from an AD perspective.

There is absolutely no requirement for you to solve all problems
in the base document. However, generally speaking we try
to avoid specifications that cause problems for existing
nodes, even if those problems appear only in some configuration.
I do worry about the case where I insert two wireless cards in
my laptop, both of them happen to connect to the same Netlmm
domain, and the laptop becoming confused about which
interface is really operational. As a result, I would recommend
having the base spec avoid that problem. But I would also
strongly recommend against trying to do too much; you
don't have to solve the full multihoming problem in the general
case, only problems related to hosts that are completely unaware
of Netlmm in the background.

Another requirement is that we should follow the truth-in-advertising
principle. The document needs to be accurate in its characterization
of what it can do and what it cannot do.

Finally, given my read of the issue, Erik's response, and a chat
with some other experts, I would suggest resolving this issue
rather than merely voting on it. Fortunately, I don't
think a resolution is that hard to come by or hard to
adopt.

Some additional personal observations follow.

Lots of discussion on this, but it seems to me that the opinions
are not that far apart. Both you Basavaraj and Christian explained
how things can work when the identifiers associated with the
netlmm attachments to two different interfaces are different.

Christian proposed a conceptual change where prefixes are
per interface; Basavaraj proposed essentially the same
thing but left to the policy of the network and only considered
interface type, not instance.

I think its obvious by now that the network needs to know about
the interfaces; without that information we'll be in trouble from
day one as well as when we try to make future enhancements.

But lets not be confused about terminology. By "interface" above
I mean interface as seen from IP; you could still share one such
interface among multiple access technologies.

I wonder if there's a solution somewhere between what Basavaraj
and Christian suggested:

- conceptual model is changed to per-interface prefix
- pmip exchanges carry not just the MNID but also an abstract interface
identifier (e.g., MAC + NAI)
- the rest is up for future work and implementations

If this is in the base, it causes no problems for existing hosts,
while still allowing at least some ways of implementing even
cross-technology handovers and multihoming from Sri's list.

And the additional information would allow us to create whatever
extensions with even nicer properties in the future, as extensions
to the base RFC (e.g., monami6, relaxations of the point to point model,
etc).

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2007 08:31:13 -0700

Jari,

There are some practical issues here.

> interface among multiple access technologies.

For inter-access technology handovers, I don't think you need to
implement a "virtual interface". All you need is the ability to move
the IP address from one interface to another during the handover.
Similar to how a typical Mobile IPv6 mobile node implementation moves
the IP address from the Mobile IP virtual interface to the physical
interface when it attaches to the home link and moves the IP address
back the virtual interfaces when it moves away from the home.

So when you per-interface prefix assignment and no virtual interface,
I don't see how PMIPv6 will work for inter-access technology handovers
within the same PMIPv6 domain.

Note that both the virtual interface and moving the address across
interfaces involves changes to the host.

> identifier (e.g., MAC + NAI)

There are links that don't have an interface identifier. In this case
the MAG needs to generate the interface identifier. If the interface
identifier is generated, how do we make sure they are unique across
MAGs?

Sending the access technology type OTOH, does indicate to the LMA
that it is a different interface. No need to generate an interface
identifier.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 09 Oct 2007 11:23:00 -0500

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???

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 09 Oct 2007 11:33:05 -0500

Hi Alex,

>>  support *unmodified* multihomed hosts for PMIP6?

Where??? In France or you meant something else???

> PMIP6 should work as much and even better than MIP6 works, right?

No. Different deployments have different requirements and hence it is not
the question of whether one is better vs the other.

> We

We are developing a protocol that addresses a need.

> So you attach a NAI to a interface?  I don't see how otherwise MN could

It is possible that an MN may be identified by different NAIs on different
access types.

> type attached to two of MAGs base stations.

I don't see this as being a practical scenario.

> PMIPv6 shouldn't prohibit

There is no competition between PMIP6 vs MIP6 in terms of which one is
better :)

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 09 Oct 2007 12:14:37 -0500

Hi George,

> solved. As I believe it has been explained a few times already, this is

We are not saying that revocation is the silver bullet here. It is just a
solution to mitigate the problem.

> removed from an Interface.

True. 

> More specifically:

The current proposal basically says that a unique prefix is assigned to an
interface. We are in no way stating that the same prefix be assigned to more
than on interface. Basically the prefix assigned to IF1 has to be rescinded
prior to the interface being assigned to IF2.
Of course the LMA also has the ability to assign a different prefix to IF2
(from IF1) as well. This is a decision made by the LMA and the access
technology type information in the PBU assists the LMA in it. It could also
rely on other sources such as AAA to make the decision about the prefix to
be assigned to the MN.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Oct 2007 20:53:49 +0300

Basavaraj,

> prior to the interface being assigned to IF2.

Right.

But the problem lies in whether you can be certain that the host
knows about this. If you look at the issue from the point of view
of an operator and/or handset manufacturer, there is no issue
because obviously you deployed everything so that you wanted
this stuff to happen correctly. However, you do not have control
over what individual hosts do. There are non-handset hosts,
laptops with 3G cards, you might turn Netlmm on in a WLAN
that hosts think is just a regular LAN etc.

However, you *can* do this if the host actually informed the
network that its capable of doing this.

I forget Christian's exact words, but obviously its not prefix per mn or
per interface, its prefix per interface *at a time*. As long as you
maintain that, you're fine -- but maintaining it may require you
to know (perhaps at layer 2) that the host agrees to let the
network cut the previous interface when a new one is established.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2007 11:10:12 -0700

> Internet being able to use both interfaces simultaneously???

They don't today. Only one interface is used.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 09 Oct 2007 14:28:31 -0500

Hi Jari,

> network that its capable of doing this.

Yes... We did think about this and are aware that capability exchange does
happen in certain networks. However we did not see this as being practical
in an IETF specification. Since we have the current limitation of not
expecting any MN changes, we have to address it by means other than
expecting the host to indicate its capability.

> per interface, its prefix per interface *at a time*.

And I believe we are doing that.. I.e a unique prefix for an interface at a
time.

> As long as you

It is possible to expect L2 indications in many networks. But then there are
others in which you may not receive an explicit L2 indication that the MN is
no longer attached via that link.

But I think we are trying to solve a problem that multi-interface hosts run
into today and recover only via user intervention. Example scenario:

If you are attached via 802.3 (IF1) and 802.11 (IF2) via your laptop via
different networks, the host uses only one of the interfaces (lets say IF1)
to send/receive packets even though both have valid addresses and have
connectivity.
Now if for some reason the network at the back end associated with the 802.3
interface (IF1) loses connectivity, the host does not automatically switch
to using the 802.11 IF. The address on IF1 is still valid and unless the
user switches off the 802.3 link the applications have no connectivity.

So you could potentially say that the same applies to the current PMIP6
scenario where the MAG has revoked the prefix from one of the interfaces of
the MN. The MN if it does not revoke the prefix from the associated
interface would be in a similar situation as above.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Oct 2007 23:58:55 +0200

Vijay Devarapalli wrote:
>> But lets not be confused about terminology. By "interface" above I 
>> mean interface as seen from IP; you could still share one such 

Sorry, but the implementation of MIP6 MN I'm aware of does not do
virtual interfaces and does not 'move' addresses from one interface to
another.  I'm not sure how you're so sure it should be done that way,
and move addresses from being assigned from one iface to another?

The MN without virtual interfaces has a permanent Home Address on each
real interface and acquires temporary CoAs on each of those interfaces.
  A CoA valid on one interface can never be assigned to another interface
simply because the IID is different (derived from its MAC address).
>  I don't see how PMIPv6 will work for inter-access technology 
> handovers within the same PMIPv6 domain.
> 

Which is not a good thing.  And I don't think anybody is ready to engage
on modifying the mobile, not here not in this group.

> 
>> I wonder if there's a solution somewhere between what Basavaraj and
>>  Christian suggested:
>> 
>> - conceptual model is changed to per-interface prefix - pmip 
>> exchanges carry not just the MNID but also an abstract interface 
> There are links that don't have an interface identifier.

Can you name one?  I can't.

ppp negotiates unique IIDs.  80216 has MAC addresses.

> In this case the MAG needs to generate the interface identifier. If 
> the interface identifier is generated, how do we make sure they are 
> unique across MAGs?

No need of that, because MAGs have different prefixes.

> that it is a different interface. No need to generate an interface 

Myself is completely lost on this and, besides intruding a conversation,
I'm completely lost.  You want to send a parameter called 'access
technology type' as a field in a message?  802.21-like?

Alex
>>  to the base RFC (e.g., monami6, relaxations of the point to point 
>> model, etc).
>> 
>> Jari
>> 
>> 
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 00:01:03 +0200

> Internet being able to use both interfaces simultaneously???

YEs, I do.  I think this has important applications in multi-pipe file 
transfer - the downloads happens faster.  A user of a mobile phone can 
download a short movie faster than using a single interface.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 00:12:19 +0200

> Where??? In France or you meant something else???

Here on my table.

Sorry for being purposefully vague, but haven't we seen here claims that 
Korea deployments need some feature absolutely and now, without any 
technical requirement?

> We are developing a protocol that addresses a need.

Where?  In Korea?

> It is possible that an MN may be identified by different NAIs on different

I guess, yes, it may be possible.  But it sounds as a far fetched idea 
to me.  I mean how could we specify that a certain NAI is attached to a 
different interface, or to a different access type?  Would the NAI 
syntax become "user@realm:iface" or something like that?

> I don't see this as being a practical scenario.

I see it, need to download a video file faster than with a single 
interface.  This does not need to modify the mobile, just use an 
application that can open a pipe to a different address through a 
different routing table entry.

> There is no competition between PMIP6 vs MIP6 in terms of which one is

:-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 00:27:29 +0200

Vijay Devarapalli wrote:
> 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???
>> 
>> 
> 

What do you mean by "they don't today"?  Who's "they"?

I've seen not only once a multi-homed PC doing simultaneous stuff on two
interfaces, just turn the forwarding to off.

My own Windows PC is so hell of multihomed, and doing simultaneous stuff
simultaneously on: the VPN interface, the PDA's usb interface, the
bluetooth kbd interface, the proprietary wireless 2.4GHz mouse
interface, the wifi interface, the ethernet iface.  Four of these are
IP, sometimes the bluetooth is IP too, when I dare.  All this without
forwarding, just care about addressing proper and some dns.

What about your PC?

Alex

>>>> 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 :)
>>>> 
>>>> to access networks which may be part of the same PMIP6 domain.
>>>> 
>>> 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
>>>> 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.
>>>> control of
>>>> 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
>>>> On 10/8/07 8:02 PM, "ext Narayanan, Vidya" 
>>>> <[email-masked]>
>>> wrote:
>>>>> Hi Raj,
>>>>> 
>>>>> 
>>>>>> 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,
>>>>>> 
>>>>>> - Where do you see from a practical deployment viewpoint 
>>>>>> the need to support *unmodified* multihomed hosts for 
>>>>>> PMIP6?
>>>>> 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
>>>>> 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 
>>>>> If we want to publish an SDO-specific document as 
>>>>> Informational, the take here would probably be different.
>>>>> 
>>>>> 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?
>>>>>> 
>>>>>>  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
>>>>>> 
>>>>>> 
>>>>>> to be worked
>>>>>>> out later.  I believe providing stable IP connectivity 
>>>>>>> for
>>>>>> unmodified
>>>>>>>  inter-technology handoffs using this protocol is not a 
>>>>>>> goal for
>>> the
>>>>>>>> [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,
>>>>>>>>>> [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
>>>>>>>>>> revocation. The LMA can send a revocation to MAG1 
>>>>>>>>>> and MAG1 could revoke the prefix assigned to IF1 
>>>>>>>>>> (RA
>>>>>>>> with prefix
>>>>>>>>>> Hence we are not diverging from the PtP model or 
>>>>>>>>>> breaking the IPv6 addressing architecture. "
>>>>>>>>>> 
>>>>>>>>>> -Raj
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> host.  It is the current point-to-point model, 
>>>>>>>>>>>> in
>>>>>>>> combination with
>>>>>>>>>>> I think the above point is quite important and 
>>>>>>>>>>> this is
>>>>>>>> what some of
>>>>>> the agreed
>>>>>>>>>>> This should have been caught during the days of 
>>>>>>>>>>> link model
>>>>>>>>>> discussion
>>>>>>>>>>> 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]

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 10 Oct 2007 11:00:29 +1100

Jari, 

 > to know (perhaps at layer 2) 

=> I don't think letting the network know, at layer 2, is a workable
solution. It violates unmodified hosts just as much as the current solution.
The only way this would work gracefully is if you assume an integrated host
where L3 knows what L2 does, which is not a general assumption that we can
make here (I hope we don't). Some L2 implementations may have adaptation
layers (L2.5) that makes the whole thing look like ethernet to L3. So the
"host" in this case knows nothing about what went on on L2.

Hesham

that the host agrees to let the

---

From: "stefano faccin" <[email-masked]>
Date: Tue, 9 Oct 2007 23:20:12 -0700

Sorry guys, I can't resisting jumping in on this. We need to think in detail
what a host belonging to the "current generation of unmodified hosts"
actually is. I do not see current PC OSs changing much in the near future,
unless somebody has some aces up their sleeves. So, I believe that e.g.
laptops where you have WLAN built-in and you add another wireless interface
card (e.g. PCMCIA) and may access to both simultaneously may actually be a
reality for a while. As for the argument on how to access security
credential and the fact that such software will have to anyway dig deep into
e.g. the PCMCIA where a potential SIM card is located, I would turn that
around and suggest to think about the case where the credentials are
provided as software (e.g. soft-SIM), i.e. a case that is going to be quite
real for several operators. So, in conclusion, IMO the answer to Raj's
question is yes, we do see such hosts.
Cheers,
Stefano

-- 
Stefano M. Faccin
==================
May the Force be with you
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Oct 2007 07:22:29 -0500

Hi Raj,

I am sorry if I am making this comment late. I am on the road and did
not have email access for the last 3 days.

I like the proposed new HNP option format!

However, Is there any specific reason for suggesting the use of
different MN-ID per Interface? 
In other words, Are you suggesting the use of different MN-ID portion
because of it is absolutely necessity or for the lack of a mechanism to
allow multihoming with a single MN-ID?

Many thanks in advance.

Regards,
Ahmad

> Sent: Sunday, October 07, 2007 6:33 AM
> To: [email-masked]
> The issue about multihoming of hosts has caused significant 
> discussion but no real resolution yet. We still believe that 
> capturing the issues w.r.t
> PMIP6 for multihomes hosts and guidelines should be 
> sufficient in the context of the current draft. A complete 
> solution to the multihoming issue in the PMIP6 context should 
> be done as a separate specification.
> 
> However in the interest of making progress, we are proposing 
> the following text below describing multihoming. We hope that 
> the following text will be sufficient for the base protocol 
> specification and allow us to move forward.
> 
> -Basavaraj

---

From: Thomas Narten <[email-masked]>
Date: Wed, 10 Oct 2007 09:22:40 -0400

> to send/receive packets even though both have valid addresses and have

I think you are making a number of (unstated to me) assumptions
here. Please clarify: Are you talking about both interfaces being
assigned the same address?

In general, if there are two interfaces, both get used, and the above
statement is simply not true.

What assumptions are you making above?

Thomas

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Oct 2007 10:47:18 -0500

Hi Stefano,

On 10/10/07 1:20 AM, "ext stefano faccin" <[email-masked]> wrote:

> what a host belonging to the "current generation of unmodified hosts" actually
> is. I do not see current PC OSs changing much in the near future, unless
> somebody has some aces up their sleeves. So, I believe that e.g. laptops where
> you have WLAN built-in and you add another wireless interface card (e.g.
> PCMCIA) and may access to both simultaneously may actually be a reality for a
> while. As for the argument on how to access security credential and the fact
> that such software will have to anyway dig deep into e.g. the PCMCIA where a
> potential SIM card is located, I would turn that around and suggest to think
> about the case where the credentials are provided as software (e.g. soft-SIM),
> i.e. a case that is going to be quite real for several operators. So, in
> conclusion, IMO the answer to Raj's question is yes, we do see such hosts.
> 
> Raj> Yes, we do have such hosts today. But the point was do your applications
> use the multiple interfaces at the same time?
> 
> 
> Cheers,
> Stefano
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Oct 2007 08:58:38 -0700

stefano faccin wrote:
> Sorry guys, I can't resisting jumping in on this. We need to think in 
> detail what a host belonging to the "current generation of unmodified 
> hosts" actually is. I do not see current PC OSs changing much in the 
> near future, unless somebody has some aces up their sleeves. So, I 
> believe that e.g. laptops where you have WLAN built-in and you add 
> another wireless interface card (e.g. PCMCIA) and may access to both 
> simultaneously may actually be a reality for a while. As for the 
> argument on how to access security credential and the fact that such 
> software will have to anyway dig deep into e.g. the PCMCIA where a 
> potential SIM card is located, I would turn that around and suggest to 
> think about the case where the credentials are provided as software 
> (e.g. soft-SIM), i.e. a case that is going to be quite real for several 
> operators. 

In this case there is some software installed by the mobile operator
on the laptop. So we are no longer talking about unmodified laptops
which have two wireless interfaces both wanting to connect to the
mobile operator network.

Vijay

So, in conclusion, IMO the answer to Raj's question is yes,
> we do see such hosts.
> Cheers,
> Stefano
> 
> On 10/9/07, *Vijay Devarapalli* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Basavaraj Patil wrote:
>      > Hi Gerardo,
>      >
>     interface.
>     only one
>      > On 10/9/07 8:56 AM, "ext Giaretta, Gerardo" <
>     [email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >> Hi Raj,
>      >>
>      >>>
>      >>> Hi Vidya,
>      >>>
>     say that.
>      >>> Your
>     multihomed
>      >>> host
>      >>> The current I-D as specified with the proposed text to be added
>     does
>      >> not
>      >>> unmodified multiinterface host to operate in a PMIP6 domain. I
>     am not
>      >> even
>     intent is to
>     there is
>      >>> On 10/8/07 8:02 PM, "ext Narayanan, Vidya" <
>     [email-masked] <mailto:[email-masked]>>
>      >> wrote:
>      >>>> Hi Raj,
>      >>>>
>      >>>>
>      >>>>> From: Basavaraj Patil [mailto: [email-masked]
>     <mailto:[email-masked]>]
>      >>>> hosts are not special or rare in today's world, as many have
>     said).
>      >> So,
>      >>>> protocol where the hosts can be modified rather than not, this
>     is a
>      >> big
>      >>>>> On 10/8/07 5:42 PM, "ext Narayanan, Vidya"
>      >>>>> < [email-masked] <mailto:[email-masked]>> wrote:
>      >>>>>
>      >>>>>> Hi Raj,
>      >>>>>>> From: Basavaraj Patil [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>>>>>> On 10/8/07 5:22 PM, "ext Narayanan, Vidya"
>      >>>>>>> < [email-masked] <mailto:[email-masked]>> wrote:
>      >>>>>>>
>      >>>>>>>> Hi Raj,
>      >>>>>>>>> From: Basavaraj Patil [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>>>>>>>> On 10/8/07 4:43 PM, "ext Narayanan, Vidya"
>      >>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>>>>>>>
>      >>>>>>>>>> All,
>      >>>>>>>>>>
>      >>> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 10 Oct 2007 09:16:25 -0700 (PDT)

Hi Stefano,

Please see inline.

> reality for a while. As for the argument on how to access security

Sure. There are hosts with multiple interfaces. No one is disputing
that. But, when you connect that device to PMIP network, there would
be some expectations:

- Choice of Source Address Selection
- Application traffic load balancing
- Roaming priorities
- Session persistence

You do want your SIP call go over an access network outside
the PMIP domain, while you are in inside the domain. So, the
device requires some software, typically some think like
connection manager. This is not a new requirement, you need
that today as well. In the absence of that software, NETLMM
cannot guarantee the basic mobility. So, what we are discussing
is not a NETLMM issue. If you give a single prefix to each
interface or same prefix to a NAI, NETLMM cannot guarantee the
basic feature of session persistence, as the host may trigger
sessions through any of its interfaces.

Regards
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Oct 2007 11:38:16 -0500

> assigned the same address?

I am talking about the everyday scenario when you have two interfaces
attached to different networks and getting unique IP addresses on both of
them. This is in the context of IPv4 though.

> statement is simply not true.

*Generally*, applications on a host will use a single interface even if
multiple interfaces were active and had valid connections. I believe only
SCTP has the ability to really use multiple interfaces which are active
simultaneously.

> 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

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 10 Oct 2007 11:23:52 -0700

> 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 :) 

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 :) 

Vidya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 20:30:58 +0200

> until memory leaks or something else forces me to do so :) 

I agree with this.

To name two of them, skype.com and gpsgate.com, both have this 
capability of dynamically changing the iface.  LArge user base in the 
order of 10s of miilions, on PCs, PDAs and phones, and interfaces also 
high number.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Oct 2007 14:47:58 -0500

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

> days I first did socket programming - so, we are talking over a decade

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.

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 10 Oct 2007 16:11:00 -0400

Alexandru Petrescu wrote:
>>> 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 think it depends upon the types of applications and how these are 
written. I have dealt with both kinds of applications.

Some of the arcane applications such as ftp, telnet, including old video 
tools such as "vic" break when the interface  changes even if the 
packets arrive on the new interface. We needed to change "vic"'s source 
code to make it work for a client with dual interface during experiment 
involving mobility.

As an example this was how the old vic code was dependent on interface eth0

> int IPNetwork::isLocalAddrChanged()
> {
>        struct ifreq ifr;
> 
> 
>        memset(&ifr, 0, sizeof(ifr));
>        strncpy( ifr.ifr_name, "eth0", strlen("eth0"));
> 
>        struct sockaddr_in *p;
>        p = (sockaddr_in *)(&ifr.ifr_addr);
> 
>        p->sin_family = AF_INET;

On the other hand, newer versions of ftp applications such as "bullet 
proof ftp" can probably tolerate the change in interface, and so as some 
of the old applications such as RAT (Robust Audio Tool) does not mind if 
the interface changes. It is usually not a good idea for the application 
developer to bind to a specific interface.

In some cases we have also tried applications (e.g.,VLC) with both the 
interfaces up with valid addresses assigned to each of those interfaces 
and send/receive packets via both the interfaces with different 
percentage (e.g., 30% on if1 and 70% on if2) for load balancing and take 
advantage of multihoming (typically useuful in MANET type networks), but 
we need to write apps on the top of VLC to split the packets on either 
interface based on our choice, which packets go via which interface.

Getting the incoming packets delivered to the client's second interface 
(e.g.,If2) when the primary interface (e.g.,If1) goes away is not host's 
or application's problem and could be dealt with in a number of mobility 
protocols including PMIP.

When both the interfaces (if1 and if2) are up with valid addresses, 
making sure the client receives packet in one specific interface (if1) 
and sends packet via one specific interface (if1) could be dealt with by 
using proper routing table on the host and other routing entries in the 
network. But making sure part of the packets go via one interface and 
part go via another interface involve additional apps on the top of 
client application that is being used (e.g. vlc).

Thanks
Ashutosh

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 10 Oct 2007 13:14:53 -0700

> Sent: Wednesday, October 10, 2007 12:48 PM
> To: Narayanan, Vidya; Thomas Narten
> Cc: Christian Vogt; NetLMM Mailing List
> Proposed textformultihoming)
> 
> 
> 
> 
> starting 
> > 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. 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 10 Oct 2007 13:29:55 -0700

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 

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, October 10, 2007 1:15 PM
> To: Basavaraj Patil; Thomas Narten
> Proposedtextformultihoming)
> 
>  
> 
> > Subject: Re: Link and Addressing Models (RE: [netlmm] Proposed 
> > textformultihoming)
> > 
> > 
> > 
> > 
> > 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. 
> 
> > > 
> host is the 
> > issue here. We can do many things with additional SW on the host.
> > 
> 
> 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
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Oct 2007 15:38:47 -0500

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 10 Oct 2007 13:52:14 -0700

Raj, Yes. That works.

Hi Everyone,

Please see the new proposal for solving the multi-homing issue.
For the last few days, we brought this multi-homing issue and
managed to argue stating we are violating link model, impacting
host connectivity ...etc ..etc....etc and so we should allocate
a unique prefix for each link. Even though, every one knows 
there needs to be additional software on the host for using
all the links and the issues with a multi-homing host and that
has nothing to do with NETLMM.

If *really* multi-homing was the concern, this should fix it
100%. I challenge the folks to beat this solution on the
grounds of merit and not with the intent of blocking interaccess
handoffs.  Please review and comment.

LMA Logic:
==========

- The LMA, on receiving a PBU from a MAG for a NAI, must check
  if there is a BCE for that mobile node (NAI).
- If there exists a BCE and if the access technology field in
  the BCE matches what is the PBU, it accepts the PBU and updates
  the binding.
- If the access technology field in the BCE does not match what
  is in the PBU, the LMA MUST wait till the MAG listed in the
  BCE sends the DeReg, before it accepts the PBU. In other words,
  the LMA will prevent the prefix oscillation by ensuring its
  not accepting binding over a different interface. 

Implies:
========
a.) The IPv6 prefix is still on a single link, at any point
    of time.
b.) The host will never see the same prefix on more than one
    interface.
c.) Host will never configure an address from the same prefix
    on more than one interface (This was never the case, anyways)
d.) Host will not network disruption at any point of time
e.) Host can do inter-access handoffs in all possible ways.
    Network can support modified and unmodified hosts for inter
    access handoffs.

Scenarios:
==========
Case-1: Host with Single Interface
a.) Handoff from pMAG to nMAG

Case-2: Host with multiple interfaces, single access
a.) Handoff from pMAG/Interface-1 to nMAG/Interface-2
b.) Handoff from pMAG/Interface-1 to nMAG/Interface-1

Case-3: Host with multiple interfaces, Multiple access
a.) Attachment to the network over a second interface

Sri

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 10 Oct 2007 16:40:28 -0500

one modification see bellow

Hi Everyone,

Please see the new proposal for solving the multi-homing issue. For the
last few days, we brought this multi-homing issue and managed to argue
stating we are violating link model, impacting host connectivity ...etc
..etc....etc and so we should allocate a unique prefix for each link.
Even though, every one knows 
there needs to be additional software on the host for using
all the links and the issues with a multi-homing host and that has
nothing to do with NETLMM.

If *really* multi-homing was the concern, this should fix it 100%. I
challenge the folks to beat this solution on the grounds of merit and
not with the intent of blocking interaccess handoffs.  Please review and
comment.

LMA Logic:
==========

  BCE sends the DeReg,
Mohamed >> or the LMA sends a revocation to the MAG
 before it accepts the PBU. In other words,

Implies:
========

Scenarios:
==========

Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 10 Oct 2007 16:40:57 -0700

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. 

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

> 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
interface.
> > interface is in the scenario where the LMA assigns the same prefix
to
> > the base specification. Future work can allow simultaneous bindings
or
> other
that
> >> we
> >>> change the charter to allow modification of hosts. I did not say
that.
multihomed
> >> Note that an unmodified multihomed node will not know that PMIPv6
is
> >> I still don't see any technical issue with the solution suggested
by
> >>> We do not propose to change the charter or the scope of the
current
does
> >>> unmodified multiinterface host to operate in a PMIP6 domain. I am
not
> >>> standardize a protocol for supporting IP mobility for unmodified
IP
control of
solve
addresses
immediate
said).
> >>>> protocol where the hosts can be modified rather than not, this is
a
based
> >>>>> <[email-masked]> wrote:
> >>>>>
> >>>>>> Hi Raj,
> >>>>>>> <[email-masked]> wrote:
> >>>>>>>
> >>>>>>>> Hi Raj,
> >>>>>>>>> <[email-masked]> wrote:
> >>>>>>>>>
> >>>>>>>>>> All,
> >>>>>>>>>>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 10 Oct 2007 16:43:11 -0700

Hi Raj,

> solution to mitigate the problem.

The point is that there is an alternative solution, provided by
Christian, which solves the problem. Why should we just mitigate it?

Gerardo
 
> interface. We are in no way stating that the same prefix be assigned
to
> more
when it
protocol. I
> >> This doesn't take care of the fact that from the MN's point of
view,

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 10 Oct 2007 21:25:38 -0700

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

> Sent: Wednesday, October 10, 2007 10:39 PM
> Subject: Re: Link and Addressing Models (RE:
> [netlmm]Proposedtextformultihoming)
> 
> 
> Hi Vidya,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Oct 2007 23:41:36 -0500

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

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Oct 2007 21:48:02 -0700

Hi Gerardo,

> know that PMIP6 is deployed!)

You have to decide what your problem statement is. Is to support
multi-homing or is it to avoid confusing a mobile node with two
interfaces? If it is the later, what Raj has written below is
sufficient.

> any reason for this restriction in the scope of NETLMM WG. 

This is the fifth time you have written the above in an email.
It is getting a bit tiring. Instead it would be great if you can
address the issues I brought up regarding generating the interface
identifier.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 10 Oct 2007 21:49:50 -0700 (PDT)

Hi Gerardo,

Over the last few weeks, number of comments were raised for the
scenario,a multi-homed host (unmodified and with no additional
software) connecting to the PMIP6 domain through multiple
interfaces and simultaneously. The unproven concerns include,
broken IPv6 link model, host configuring same address on multiple
interfaces, unstable host connectivity ...etc.

To address those concerns, we proposed a solution. With this
proposal, none of the above concerns should be valid any more.
Please review and provide some objective feedback. Please state
and prove, what protocols or specs, this document proposal
violates.

Regards
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 11 Oct 2007 16:26:31 +1100

> hosts. And I don't see reasons why only mip6 capable hosts can be

=> It's not the case of course, any IPv6 host can be multihomed. monami6
just enhances mip6 to optimise the handling of multihomingfor mobile nodes.
Multihoming is a fundamental capability in an IPv6 stack. I think the WG
should not spend anytime discussing whether an IPv6 host can handle two
different interfaces up at the same time, if it can't then it's buggy! How
applications choose interfaces ....etc is something done outside the IP
stack. 

Hesham

 > > > What we are saying is that the choice of the prefix to 
 > be assigned
 > > should be
 > > > The limitation that we mention about the MN having 
 > service over only
 > one
 > > > second interface. I think this is an acceptable solution 
 > within the
 > > scope of
 > > > On 10/9/07 8:56 AM, "ext Giaretta, Gerardo" 
 > <[email-masked]>
 > > wrote:
 > > >
 > > >> Hi Raj,
 > > >>
 > > >>>
 > > >>> Hi Vidya,
 > > >>>
 > > >>> in a PMIP6 domain will have only a single interface 
 > active. This
 > is a
 > > >> interfaces. Which is the technical motivation why we 
 > should include
 > > such
 > > >>> suggesting publishing any SDO specific document here. 
 > The intent
 > is to
 > > >>> 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
 > > >>>> I'm sorry, but, I beg to differ on this take.  As you 
 > very well
 > > >> know, at
 > > >>>> cases that we may be seeing, but, something that will 
 > support a
 > > >> bigger
 > > >>>> unless we are saying that the charter is now invalid 
 > and we need
 > a
 > > >>>> At the time of chartering this effort, a lot of value 
 > was seen to
 > be
 > Informational,
 > > >>>>>> inter-technology handoffs using this protocol is 
 > not a goal for
 > > >> the

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 11 Oct 2007 16:29:51 +1100

> interfaces and simultaneously. The unproven concerns include,

=> What do you mean by "unproven concerns"? You mean that it's not proven
that an IPv6 link is required to be allocated a unique prefix? May be it's
time to read some IPv6 specs.....sigh

 > >> 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
 > >> This would ensure that the MN is connected via only one 
 > interface at
 > > any
 > >>> active interfaces today.  That bare minimum is what we 
 > are putting
 > > in
 > >>> Supporting the use of multiple interfaces simultaneously 
 > comes later
 > > -
 > >>> while that is also feasible on hosts with unmodified IP 
 > hosts today,
 > > our

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 10 Oct 2007 22:37:45 -0700 (PDT)

> time to read some IPv6 specs.....sigh

Hi Hesham,

There is a difference, when a prefix is hosted on two links
for a transient period of time, vs, allocating the same
prefix for two links. Any case, please comment, if this issue
is still seen in the new text. Surely, I will read some IPv6
specs ...

Thanks
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 11 Oct 2007 17:32:39 +1100

> prefix for two links. 

=> But there were several points raised and, as far as I've kept up with
emials, remain unanswered. First, the idea that an address is immediately
removed isn't true according to the several points that George made. Second,
the idea that it will be a switch from one interface to another is an
unrealistic restriction for hosts that can and want to use two interfaces.
So, independently of what the suggested text says, unless we at least
acknowledge that these are real problems, this WG will keep going around in
circles until everyone gets dizzy. 

   Any case, please comment, if this issue
 > is still seen in the new text. Surely, I will read some IPv6

=> I think you've already read those specs, which is why I find it
frustrating that you don't acknowledge a problem that you should know very
well exists. Personally, I've already commented on this problem and raised
it in Chicago, I see no benefit for anyone in trying to convince people that
a fact is a fact. If this is not going to be acknowledged then the WG can
proceed with the doc to the IESG, which IMO is a DoS attack on the IESG. 

Hesham

Hesham

 > > > >> - Disallow the LMA from creating the BCE for an MN 
 > attaching via
 > > > > another
 > > > >> - MAG1 would send the dereg only when it has 
 > confirmed (via either
 > > > > L1/2/3)
 > > > >> On 10/10/07 3:29 PM, "ext Narayanan, Vidya" 
 > <[email-masked]>
 > > > > wrote:
 > > > >>
 > [netlmm] Proposed

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 11 Oct 2007 00:55:46 -0700

Hi Raj,

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

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

> 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?

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

Cheers
Gerardo

> Only in such a scenario are we
> 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
> 
> 

> > 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!)
> >
> > 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
> >
> >> 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
> >> This would ensure that the MN is connected via only one interface 
> >> at
> > any
> >>> 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
> >>> Supporting the use of multiple interfaces simultaneously comes 
> >>> later
> > -
> >>> while that is also feasible on hosts with unmodified IP hosts 
> >>> today,
> > our
> >>>> 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
> >>>>>> 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 :)
> >>>>>
> >>>> 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.
> >>>> 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
> >>>>
> >>>>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 11 Oct 2007 19:04:22 -0700

Hi Hesham,

To close this discussion ...

> frustrating that you don't acknowledge a problem that you 

I never said, the issue of two MAG's contending for the same
prefix did not exist. You can see all my emails. I questioned the
validity of multi-homing deployment, with no additional software
on the host. I also said, operators have the ability to ensure
a device connects to PMIP6 domain over a single interface and
also the issues related to multi-homing on the host stack and
the need for additional software. We kept saying multi-homing is
an advanced feature and should not be considered in the base doc.
But, you guys won and now  we are discussing about solutions. 
Other than this restriction of unique prefix per interface, you
got what you wanted. 

We all know, no operator will do PMIP deployment, support
inter access handoff, do multi-homing for hosts that have just a
base kernel loaded with 2461 IPv6 stack. The host cant event
leverage the basic session persistence feature. Host does not
even know if its SIP call is going thru a PMIP access network
or some out side access network. But, when we talk about impact
to host operation ..etc, unfortunately that gets the attention,
right or wrong. We talk about IID generation and state SDO's can
deal with it, but we are reluctant to agree that SDO's can deal
with multi-homing problem. The power of argument !

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 12 Oct 2007 23:43:40 +1000

> with multi-homing problem. The power of argument !

=> That's because you're confusing the term "unmodified host". They will
absolutely get a standard IPv6 implementation based on RFCs 2460 onwards.
The difference is, they can add applications that make multihoming more
optimally supported. That's not a "modified" host, unless you assume that an
unmodified host is one that comes with windows and explorer only. We're
talking about not modifying anything below the socket API here... Do you
think operators will modify a windows IP stack? good luck. 

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 11 Oct 2007 19:58:38 -0700 (PDT)

> optimally supported. That's not a "modified" host, unless you assume that an

That is the absolute required application for supporting terminals
with multiple interfaces, in a PMIP domain.

The same application will also have the ability to avoid multi-homing.
It will have the ability to choose the roaming interface, select one
interface out from many and perform source address selection. In
the presence of such ability for the device, the issue that was raised
can be avoided and we really did not have to deal with that problem in
the base spec. Its still an *un-modified* host, in combination with
that application, where is the multi-homing problem ?

Sri

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Oct 2007 18:40:52 +0300

Basavaraj,

> SCTP has the ability to really use multiple interfaces which are active
This isn't quite true, particularly if you consider IPv6.
Again, there's missing pieces in multihoming support.
But if you have two interfaces, the stack would automatically
choose the right one for any on-link destination on those
links. In addition, even if you use just one interface,
is it the right one, if the network disables one of the
interfaces?

> 3. Network serving IF1 goes down... Apps don't switch to using IF2

In many cases the applications would switch automatically
to IF2. Server applications might bind to a particular
interface/address, but client applications use whatever is
available.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Oct 2007 18:50:35 +0300

Vijay,

> implement a "virtual interface". 

There are other options, yes.

> All you need is the ability to move
And if you had two cards of the same type?

Anyway, I didn't mean to imply that you should always employ
the virtual link concept. A link layer handoff scheme that can
ensure only one link in the host is active at any one time would
not have any problem with Netlmm: Only one interface name is
associated with the prefix P at any one time, even over time
we use different interface names.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 12 Oct 2007 08:59:52 -0700 (PDT)

Hi Jari,

> is it the right one, if the network disables one of the

For IPv6, true the sending rules or the SAS rules are
different. But, for non local destinations and typically
for a host, the route to that destination is equal in
metric through any of its interfaces. So, most likely
the first interface gets selected. So, a multi-homed
host has no control to ensure the applications will use
a local address from the PMIP domain and not an address
from the access network outside the domain.

> interface/address, but client applications use whatever is

Applications that have mobility builtin, such as SIP (using ReInvite)
or Skype as Alex pointed out, will survive. But, all TCP sessions
will die.

Sri

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Oct 2007 19:29:35 +0300

Sri,

> or Skype as Alex pointed out, will survive. But, all TCP sessions

Ah, we are not communicating clearly. I fully understand
the need to keep your IP address across such moves.
But I don't think its a problem to achieve this. If you know
that (a) this is the same node by looking at the NAI,
(b) this is a move to a different interface based on interface
id and type, and (c) we are shutting down the previous
interface, then there is no problem, as you can assign
the same prefix.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 12 Oct 2007 09:37:03 -0700 (PDT)

Hi Jari,

> interface, then there is no problem, as you can assign

Sure. I agree.

Thanks
Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 12 Oct 2007 19:06:30 -0700

Hi Jari,

Could you please clarify what you mean by "(b) this is a move to a
different interface based on interface id and type"? 
Specifically, I assume by "type" you mean access technology i.e., WLAN,
WiMax etc. What do you mean by Interface ID, though? the MAC address of
the physical interface or something else?

I am asking you to clarify this because in an e-mail to Vijay you talked
about, instead of using the virtual interface concept, to just make sure
that only one interface is active at any one time, and to move the
address between them. I am not then sure if you think this fits under
the "per Interface" model or whether you are proposing something
different.

A host that is able to move an IP address instantaneously between two
physical interfaces while keeping only one up at any one time, is of
course not "unmodified". This requires, as you said, that there must be
something at L2 that ensures that only one interface is up at the time,
as well as a driver of some form that makes this transparent to the
higher layers. 

I guess the question is then, what is the protocol abstraction that PMIP
needs to use to figure out whether such capability exists in the mobile
or not. IMO, if moving IP addresses between interfaces without a VI is
indeed possible, then it is also possible for the same implementation to
use a "group Interface Id" to identify all the physical interfaces
between which an IP address can be moved using PMIP....thus it fits fine
under the per interface prefix model. BTW, in this model the IID is
enough for the protocol to operate correctly and the access technology
type is not necessary...although of course not harmful to know either.

Thoughts?

Regards
George

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, October 13, 2007 1:30 AM
To: Sri Gundavelli
Cc: Christian Vogt; NetLMM Mailing List
Subject: Re: Link and Addressing Models (RE: [netlmm] Proposed
textformultihoming)

Sri,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Oct 2007 05:15:54 +0300

George,

> the physical interface or something else?

A MAC address would be one example of this identifier.
Fundamentally, the question is whether the new attachment
is for the same or different interface as seen by IP on the
mobile host.

> the "per Interface" model or whether you are proposing something

Yes.

> or not.

Yes.

> IMO, if moving IP addresses between interfaces without a VI is
Right. I think some people are concerned that for some
access technologies the IID isn't easily available, and that's
why interface type may be used in its place if nothing else
is available.

Jari

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 15 Oct 2007 04:17:02 -0700

Hi Jari,

Thanks. Could you, or someone, indicate which technologies do not have
easy access to the IID?

It seems to me that the issue here is having access to the Virtual-IID,
and not to the physical IID. While this is indeed an issue to be solved,
I do not see how this is harder than solving the issue of having
"policy" in the LMA indicating whether allocating the same prefix to two
different IIDs or interface types is possible. Could you give us your
thoughts on whether you consider one harder than the other and why?

Finally, by allowing interface type to be used instead of IID, I am sure
you understand that you open the possibility of creating an error case
for unmodified hosts with two interfaces of the same type attached to
the same PMIP domain. Do you think that such an eventuality is
acceptable and why?

Regards
George

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, October 13, 2007 3:16 AM
To: Tsirtsis, George
Cc: Sri Gundavelli; Christian Vogt; NetLMM Mailing List
Subject: Re: Link and Addressing Models (RE: [netlmm] Proposed
textformultihoming)

George,

Yes.

Yes.

Jari