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

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?

  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.

  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 

  "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: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On 
> Behalf Of George Tsirtsis
> Sent: Dienstag, 25. März 2008 11:49
> To: Netlmm
> Cc: mext@ietf.org
> 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:  <Internet-Drafts@ietf.org>
> Date: 2008/3/25
> Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt
> To: i-d-announce@ietf.org
> 
> 
> 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
>  I-D-Announce@ietf.org
>  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
> MEXT@ietf.org
> 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
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext