Re: [netlmm] [MEXT] Fwd: I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt

["George Tsirtsis" <[e-mail]>]

Hi Kilian,

I appreciate you reading the draft so quickly, see below some comments.

On Tue, Mar 25, 2008 at 4:04 PM, Kilian Weniger
<[e-mail]> wrote:
> Hi George,
>
>  I have some clarifying questions regarding section 4.1.1 of your draft, which argues why sharing a single BCE between MIPv6 and PMIPv6 is supposed to be wrong in draft-giaretta-netlmm-mip-interactions-02. All three arguments mentioned in the draft are about scenarios where the MN has multiple active network interfaces (with or without MIPv6 multihoming). However, I don't really understand the logic of these arguments and why they apply, maybe you can elaborate.
>
>   1) "Directing traffic between foreign links: If an MN can maintain two
>       links at the same time, it can direct traffic to one or the other
>       link by simply sending a BU to its HA, registering the CoA
>       corresponding to one or the other link."
>
>  Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure MIPv6 scenario not related to the discussion of shared vs. separate BCEs for PMIPv6 and MIPv6, right?
>

GT> This scenario does not present a problem for PMIP-MIP
interactions. It is presented in the draft since for some people
thinking about alternating between CoAs of two foreign links while
both of the foreign links are up sounds natural. In the draft I am
simply arguing that the same should be possible between a home and a
foreign link.

>
>   2) "Directing traffic between home and foreign link: If one of the
>       links maintained is the home link, the MN can direct traffic to it
>       by sending a deregistration MIPv6 BU to the HA over the home link,
>       while it can also direct traffic to the foreign link by sending a
>       MIPv6 BU to the HA directing traffic to the CoA of the foreign
>       link."
>
>  If I understand the scenario correctly, the MN has one active interface connected to the home link and another active interface connected to a foreign link and wants to switch dynamically between both without moving. Since we are not talking about HAs extended by MIPv6 multihoming/monami6 extensions here, is this special scenario even supported by RFC3775? I think it is not, since both the MN and the HA would defend the HA on the home link.
>

GT> Kilian, please reconsider your thinking on this. RFC3775 fully
supports this scenario. There is a parallel thread in MEXT where this
is being discussed. RFC3775 does not say anything about how many IP
interfaces the MN has. The only think RFC3775 says is that only one
CoA is registered at any one time. An MN can obviously have two (or
more) IP links e.g., one over 3G and another over WLAN. These IP
interfaces have their own addresses, which are potential care-of
address in MIPv6. RFC3775 defines that only one of them can be
registered at any one time. MCoA extensions allow more than one to be
registered at the same time.

GT> The above should be blindingly obvious to anyone who has ever
implemented Mobile IP for inter-technology handoffs. People who doubt
this, should check any one the many Mobile IP based WLAN to 3G handoff
implementations. Most companies in the wireless space have tried this
at least internally over the last several years. I know for a fact
that the implementation I was involved with did exactly that and I bet
most others do the same. This is obvious since different airlink
technologies tend to overlap in coverage causing the MN to be
connecting to both of them at the same time. at least for a time (...a
long time of the MN stays in the overlap zone). By registering either
one CoA or the other the MN switches between the two available links
based on SNR ot policy parameters..

>   3) "Directing traffic between Multiple links: MEXT WG is also working
>       on [I-D.ietf-monami6-multiplecoa] and
>       [I-D.soliman-monami6-flow-binding] specifications allowing an MN
>       to register multiple links (multiple CoAs and the home link) to
>       its HA at the same time and even direct different flows to
>       different links."
>
>       It should be clear that none of this can be possible if every time
>       the MN connects to its home link, the corresponding PMIPv6 BCE
>       overwrites the HA BCEs for the same mobile or every time the MN sends
>       a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA
>       BCE entry for the same MN."
>
>  This argument only applies to monami6 HAs. However, monami6 is out of the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-mip-interactions-02 says
>

GT> The MCoA considerations in this draft are there to remind people
what else is possible given features we are developing in MEXT and the
fact that implementing BCEs in the wrong day today, may affect
features tomorrow. It would be rather shortsighted to ignore what we
know is coming. In any case, as you see above the issue exists even
without considering MCoA.



>   "Note that the issues are described based on current
>    specification and does not assume any optimized solution for any
>    scenario.  The specifications considered as a baseline for the
>    analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]."
>
>  Thanks,
>
>  Kilian
>
>
>
>  > -----Original Message-----
>  > From: [e-mail] [mailto:[e-mail]] On
>  > Behalf Of George Tsirtsis
>  > Sent: Dienstag, 25. März 2008 11:49
>  > To: Netlmm
>  > Cc: [e-mail]
>  > Subject: [MEXT] Fwd:
>  > I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt
>  >
>  > Hi all,
>  >
>  > Krishnan and I put together a draft describing what the expected
>  > behavior of a combined LMA/HA implementation should be. This should
>  > help the discussions around the so called scenario C of the PMIP-MIPv6
>  > interactions draft (draft-giaretta-netlmm-mip-interactions).
>  >
>  > I hope you find the discussion in this draft useful.
>  > Please let us know if you have any comments/questions.
>  >
>  > Regards
>  > George
>  >
>  >
>  > ---------- Forwarded message ----------
>  > From:  <[e-mail]>
>  > Date: 2008/3/25
>  > Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt
>  > To: [e-mail]
>  >
>  >
>  > A New Internet-Draft is available from the on-line
>  > Internet-Drafts directories.
>  >
>  >         Title           : Behavior of Collocated HA/LMA
>  >         Author(s)       : G. Tsirtsis, S. Krishnan
>  >         Filename        :
>  > draft-tsirtsis-logically-separate-lmaha-00.txt
>  >         Pages           : 9
>  >         Date            : 2008-03-25
>  >
>  >  In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario
>  >  C describes the case of collocation of LMA and HA function.  In this
>  >  case a PMIP network emulates the "home link" for MNs using MIPv6.
>  >  This document argues that even when LMA and HA functions are
>  >  Collocated they MUST be treated as logically separate entities.  In
>  >  particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6
>  >  BCEs and vice versa.
>  >
>  >  A URL for this Internet-Draft is:
>  >
>  > http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-s
>  > eparate-lmaha-00.txt
>  >
>  >  Internet-Drafts are also available by anonymous FTP at:
>  >  ftp://ftp.ietf.org/internet-drafts/
>  >
>  >  Below is the data which will enable a MIME compliant mail reader
>  >  implementation to automatically retrieve the ASCII version of the
>  >  Internet-Draft.
>  >
>  >
>  > _______________________________________________
>  >  I-D-Announce mailing list
>  >  [e-mail]
>  >  https://www.ietf.org/mailman/listinfo/i-d-announce
>  >  Internet-Draft directories: http://www.ietf.org/shadow.html
>  >  or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  > _______________________________________________
>  > MEXT mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/mext
>  >
>  >
>
>
>  Panasonic R&D Center Germany GmbH
>  63225 Langen, Hessen, Germany
>  Reg: AG Offenbach (Hessen) HRB 33974
>  Managing Director: Thomas Micke
>
>
>
_______________________________________________
netlmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netlmm