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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Feb 2014 11:25:05 -0600

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?

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

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 09:13:26 +0000

Hi Behcet,

De : netext [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : jeudi 13 février 2014 18:25
À : [email-masked]
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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Feb 2014 16:30:38 -0600

Hi Pierrick,

On Fri, Feb 14, 2014 at 3:13 AM, <[email-masked]> wrote:

>  Hi Behcet,
>
>
>
>
>
> *De :* netext [mailto:[email-masked]] *De la part de* Behcet
> Sarikaya
> *Envoyé :* jeudi 13 février 2014 18:25
> *À :* [email-masked]
> *Objet :* [netext] draft-ietf-netext-pmipv6-flowmob-08
>
>
>
> Hi all,
>
> >> 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.
>
>
>

I would remove the whole 3.1 because I don't see why the prefix management
so-called models are called flow mobility protocol use cases?
Different ways of managing prefixes are not specific to flow mobility.

Regards,

Behcet