Re: [netext] draft-ietf-netext-pmipv6-flowmob-08

<pierrick.seite@orange.com> Fri, 14 February 2014 09:13 UTC

Return-Path: <pierrick.seite@orange.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8D1A01EC for <netext@ietfa.amsl.com>; Fri, 14 Feb 2014 01:13:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpffIbEVQObv for <netext@ietfa.amsl.com>; Fri, 14 Feb 2014 01:13:41 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA31A0173 for <netext@ietf.org>; Fri, 14 Feb 2014 01:13:29 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E289C2DC1AF; Fri, 14 Feb 2014 10:13:27 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C38892380B8; Fri, 14 Feb 2014 10:13:27 +0100 (CET)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 10:13:27 +0100
From: pierrick.seite@orange.com
To: "sarikaya@ieee.org" <sarikaya@ieee.org>, "netext@ietf.org" <netext@ietf.org>
Thread-Topic: [netext] draft-ietf-netext-pmipv6-flowmob-08
Thread-Index: AQHPKOCNwuZkYpgeWUG/Yczry8Xe1pq0c/2w
Date: Fri, 14 Feb 2014 09:13:26 +0000
Message-ID: <28165_1392369207_52FDDE37_28165_1198_2_81C77F07008CA24F9783A98CFD706F71141F4AB7@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <CAC8QAccTVgFqKmJJwpR334k+dq=cAPvF=59zQztBrNSQN0mABA@mail.gmail.com>
In-Reply-To: <CAC8QAccTVgFqKmJJwpR334k+dq=cAPvF=59zQztBrNSQN0mABA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71141F4AB7PEXCVZYM12corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/7I45dGnBj2gBhfR0Pe4J2lWVQag
Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-08
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 09:13:46 -0000

Hi Behcet,


De : netext [mailto:netext-bounces@ietf.org] De la part de Behcet Sarikaya
Envoyé : jeudi 13 février 2014 18:25
À : netext@ietf.org
Objet : [netext] draft-ietf-netext-pmipv6-flowmob-08

Hi all,
I was reading this document once more and this point somehow sticks so I thought I should share with the WG:
Section 3.2.1 presents a solution with LMA assigning the same prefix to different interfaces of MN.
So the draft can easily say that this is the solution to flow mobility in PMIP, PMIP is extended to adopt this prefix-assignment policy and here is the solution.
Why continue and present another solution in Section 3.2.2?
>> I remember long an impassioned discussion regarding this point; the WG has finally decided to keep the solution to maintain compatibility with regular RFC5213 operation. I think it can be acceptable; however I'm still doubtful about combination of the two prefix management models (section 3.2.1 and 3.2.2) , and I'd rewove  section 3.2.3 and corresponding text in section 3.1. However, I'll follow the group consensus if any.

BR,
Pierrick

Another comment on Section 3.1.
Why are these three the only use cases?
I served in the editorial team initially and the main use cases were MAG-initiated flow mobility and LMA-initiated flow mobility and actually there were many solution drafts proposing solution for each and those drafts were taken as input by the editorial team.
What happened to that in Section 3.1?
Regards,
Behcet

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.