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

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

Killian, let's stop cross posting to MEXT and continue this discussion
in NETLMM list ONLY!
This should be the last e-mail to MEXT on this topic.

Thanks for your help
George

On Tue, Mar 25, 2008 at 4:37 PM, George Tsirtsis
<[e-mail]> wrote:
> 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
>  >
>  >
>  >
>
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext