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

[Behcet Sarikaya <[e-mail]>]

Hi Pierrick,


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

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

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


>  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.
>
>