Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 28 Sep 2007 16:57:31 -0400

Dear All,

I don't think any of these options make sense. Requiring the MN to
associate different MN-IDs over different interfaces means we are
imposing new requirements on the MN which we tried to avoid, IMHO. Also,
we cannot prevent the MN to attempt network access over more than one
interface. 

I do not believe that there will be any issue if the MN attempts to use
more than one interface. In the particular example given before, if the
MN chooses to use interface 2, everything will be good. If the MN
chooses to use interface 1, there are ways to recover from a momentary
glitch. However, I think we should stay out of this level of detail to
describe an out-of-scope topic (multi-homing) in the base spec.

I like Behcet's proposal to state that: support for multi-homing is out
of scope of the document. This is simple and precise.

BR,
Kuntal

> -----Original Message-----
> From: Genadi Velev [mailto:[email-masked]]
> Sent: Friday, September 28, 2007 10:59 AM
> To: Sri Gundavelli
> Cc: ext Kilian Weniger; [email-masked]
> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs
> 
> Hi Sri,
> 
> it seems that we converge on this issue :-)
> 
> I was also agnostic on any of the initial options 1-4.  Of course the
> simplest way to go forward is to describe options 1 and 2. The
operator
> can choose between not allowing multiple interfaces to be
simultaneously
> attached (option 1) or to support multiple interfaces to be attached
but
> assuring that different MN-ID is assigned to each interface.
> 
> Option 3 still needs to be worked out in
> draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and
> Vijay. So, we can leave it out for the base PMIP specification.
> 
> Genadi
> 
> > -----Original Message-----
> > From: Sri Gundavelli [mailto:[email-masked]]
> > Sent: Friday, September 28, 2007 4:15 PM
> > To: Genadi Velev
> > Cc: Narayanan, Vidya; ext Kilian Weniger; [email-masked]
> > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs
> >
> > Hi Genadi,
> >
> > Please see inline.
> >
> >
> > On Fri, 28 Sep 2007, Genadi Velev wrote:
> >
> >
> > > I can think about several approaches to overcome this issue:
> > > 1) we can specify that the network operator shall take care of
> > > preventing that a MN attaches with 2 interfaces to a PMIP domain
(at
> > > least to the same LMA). For example, the operator doesn't allow
> > > attachment (i.e. authorization) of interface 2, since interface 1
is
> > > still attached.
> >
> >
> > > 2) we can write a short text in the draft that the network
operator
> > > shall take care about assignment of different MN-ID (NAI)
> > to different
> > > interfaces during attachment procedure.
> >
> > > 3) we can describe how the current protocol behaves when a
> > MN attempts
> > > to attach with two interfaces. Similar to what is explained
> > in Vijay's
> > > email:
> > > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html
> >
> > I'm ok with any of the above three options. We can certainly
document
> > the scenario and close the issue. I do no think, we should try to
> > solve this problem here or use this issue to explicitly add text to
> > block the inter-access handoff, we did not do any thing to
> > support that
> > scenario. When the charter says, its out of scope, we dont
> > need to solve
> > all the issues, when the scenario is enabled. Operators can solve
this
> > issue, these are managed deployments. Its not a like a
> > consumer buying a
> > device and turning it on at home. So, I agree with your above three
> > suggested options.
> >
> > Regards
> > Sri
> >
> >
> >
> >
> 
> 
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Sep 2007 14:38:41 -0700 (PDT)

Hi Kuntal,

> of scope of the document. This is simple and precise.

I agree and I've been saying this is out-of-scope. I do not want
this argument to lead to a solution with some explicit restrictions
on inter-access handoffs (which comes naturally with the current
spec). If the text suggested by Genadi leads to any such restrictions,
which I did not analyze in detail, I'll not be in favour of this. My
point is, we dont go into the details for some thing that is out of
scope. Just have a note that there may be glitch, when multiple
interfaces are active in a single domain and leave it there.

If every one agrees on this, we can suggest some text on this and
close this issue.

Sri

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Sat, 29 Sep 2007 01:35:07 -0400

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Friday, September 28, 2007 6:23 PM
> To: Chowdhury, Kuntal; Sri Gundavelli
> Cc: ext Kilian Weniger; [email-masked]; Genadi Velev
> Folks,
> It is not helping to keep insisting that stating multi-homing is out
of
> scope is sufficient.  The situation at hand is really the following
and
> let's own up to it:
> 
> "This protocol, as currently specified, may result in unpredictable,
> intermittent or no IP connectivity to a device that is multihomed,
over
> any of its interfaces."
> 
> This doesn't just mean multi-homing is not supported; it means that a
> unmodified multi-homed IP device can't have stable IP access.
> 
[KC>] Well, how can you be so certain w/o getting into MN implementation
discussion? Didn't we decide to stay away from discussing MN
implementation? There are known ways to address the issue of IP address
collision over different interfaces on a host or a router. But, let's
not get into that discussion here.

BTW, why this is a PMIP6 specific issue? What happens in case of MIP6
when CoAs are non-unique over two interfaces of the MN?

Take the case of a laptop with WiFi and RJ-45 Ethernet port (pretty
common laptop configuration). What happens when both the interfaces are
active and both the interfaces configure the same IP address (possible
because WiFi and LANs mostly use private address pools)? 

> If all this protocol is doing is providing IP connectivity over only
one
> interface of a multi-homed device, we won't be having this
conversation.
[KC>] I think you have a very specific MN implementation in mind. Note,
if the MN has uncoordinated interfaces and if the MN lacks the
capability of hiding the interfaces from the IP stack, only then it will
be forced to use only one interface.

> 
> I don't believe we can call this document done given the situation at
> hand.  So, please work towards solving the issue, rather than
repeatedly
> claiming it is out of scope.
> 
[KC>] Well, this issue is out-of-scope since it pertains to MN
implementation. As I have mentioned in my examples above, this issue may
arise in many situations regardless of the use of PMIP6.

> Thanks,
> Vidya
> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Friday, September 28, 2007 3:12 PM
> > To: Sri Gundavelli
> > Cc: ext Kilian Weniger; [email-masked]; Genadi Velev
> > Sri,
> > If we just add a note to say that: support for multi-homing
> > is out of scope of the document, it should suffice.
> >
> > This topic is out of scope, and we should close this thread
> > and move on.
> >
> > BR,
> > Kuntal
> >
> >
> > > Sent: Friday, September 28, 2007 4:39 PM
> > > To: Chowdhury, Kuntal
> > > Cc: Genadi Velev; [email-masked]; ext Kilian Weniger
> > > > imposing new requirements on the MN which we tried to avoid,
IMHO.
> > Also,
> > > > we cannot prevent the MN to attempt network access over more
than
> > one
> > > > interface.
> > > >
> > > > I do not believe that there will be any issue if the MN
> > attempts to
> > use
> > > > more than one interface. In the particular example given
> > before, if
> > the
> > > > glitch. However, I think we should stay out of this level
> > of detail
> > to
> > > > I like Behcet's proposal to state that: support for
> > multi-homing is
> > out
> > > I agree and I've been saying this is out-of-scope. I do not
> > want this
> > > argument to lead to a solution with some explicit restrictions on
> > > inter-access handoffs (which comes naturally with the
> > current spec).
> > > If the text suggested by Genadi leads to any such
> > restrictions, which
> > > I did not analyze in detail, I'll not be in favour of this.
> > My point
> > > is, we dont go into the details for some thing that is out
> > of scope.
> > > Just have a note that there may be glitch, when multiple
interfaces
> > > are active in a single domain and leave it there.
> > >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 23:46:46 -0700

Hi Kuntal,
I'm not referring to any implementation specific details.  Please see my
response to Raj - per the text quoted from RFC2462 by Raj, the MN won't
configure a duplicate address on its interface and hence this problem
exists.  

Also, it is not similar to duplicate addresses in other situations -
typically, if the MN is doing DHCP, it is either an error on the part of
the MN (e.g., using the same client ID for two interfaces) or on the
part of the DHCP server that it ends up with a duplicate address.  Or,
while using stateless autoconfiguration, the MN must violate RFC2462 to
end up with duplicate addresses being assigned to multiple interfaces.
The difference here is that it is neither an error from the MN
perspective nor an error from a PMIP perspective and hence, the problem.

Regards,
Vidya

> Sent: Friday, September 28, 2007 10:35 PM
> To: Narayanan, Vidya
> Cc: ext Kilian Weniger; [email-masked]; Genadi Velev; Sri Gundavelli
> [KC>] Well, how can you be so certain w/o getting into MN 
> implementation discussion? Didn't we decide to stay away from 
> discussing MN implementation? There are known ways to address 
> the issue of IP address collision over different interfaces 
> on a host or a router. But, let's not get into that discussion here.
> 
> BTW, why this is a PMIP6 specific issue? What happens in case 
> of MIP6 when CoAs are non-unique over two interfaces of the MN?
> 
> Take the case of a laptop with WiFi and RJ-45 Ethernet port 
> (pretty common laptop configuration). What happens when both 
> the interfaces are active and both the interfaces configure 
> the same IP address (possible because WiFi and LANs mostly 
> use private address pools)? 
> 
> [KC>] I think you have a very specific MN implementation in 
> mind. Note, if the MN has uncoordinated interfaces and if the 
> MN lacks the capability of hiding the interfaces from the IP 
> stack, only then it will be forced to use only one interface.
> 
> > 
> [KC>] Well, this issue is out-of-scope since it pertains to 
> MN implementation. As I have mentioned in my examples above, 
> this issue may arise in many situations regardless of the use 
> of PMIP6.
> 
> 
> > Thanks,
> > Vidya
> > 
> > > If we just add a note to say that: support for 
> multi-homing is out 
> > > of scope of the document, it should suffice.
> > >
> > > This topic is out of scope, and we should close this 
> thread and move 
> > > on.
> > >
> > > BR,
> > > Kuntal
> > >
> > >
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>