Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation

From: Basavaraj Patil <[email-masked]>
Date: Wed, 12 Mar 2014 13:42:42 -0500

Hello,

This is the working group last call for I-D: Separation of Control and User
Plane for Proxy Mobile IPv6 <
draft-ietf-netext-pmip-cp-up-separation-02.txt>.

This I-D is intended to be progressed as a standards track document.
Please review and post your comments on the mailing list.
The last call will expire on March 27th, 14.

-Chairs

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 26 Mar 2014 17:23:37 +0900

Hi authors,

I think this is in good shape enough to go, but just one
clarification question:

In Section 6,

When this variable on the MAG is set to a value of (0), the MAG
must explicitly indicate its support-capability for this
feature by including the LMA User Plane Address mobility Option
in the Proxy Binding Acknowledgement. If the option is not
present in the Proxy Binding Update, the local mobility anchor
will not enable this feature for that mobility session.

How can MAG indicate its support by PBA? Is it PBU or LMA does it
by any chance?
The same question applies in the following paragraph in the
document.

Regards,

--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

(2014/03/13 3:42), Basavaraj Patil
wrote:

Hello,

This is the working group last call for I-D: Separation of
Control and User Plane for Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.

This I-D is intended to be progressed as a standards track
document.

-Chairs

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 22:31:54 +0000

Hi

I support this draft; it adresses valid architecture scenario with separated control and data plane entities.
However architecture in figure 1 should be updated to clearly show this separation. Fig 1 put both mag cp and mag up within the same box, which is a bit confusing regarding the scope of the document.

Although out of scope of the document, it would be worth to give indication on interface between mag cp and up (eg Capwap based) in order to have the full picture on how the solution can work.

Sent from my mobile

---- Hidetoshi Yokota <[email-masked]> wrote ----

Hi authors,

I think this is in good shape enough to go, but just one clarification question:

In Section 6,

How can MAG indicate its support by PBA? Is it PBU or LMA does it by any chance? The same question applies in the following paragraph in the document.

Regards,

--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]<mailto:e-mail:[email-masked]>

(2014/03/13 3:42), Basavaraj Patil wrote:
Hello,

This is the working group last call for I-D: Separation of Control and User Plane for Proxy Mobile IPv6 <draft-ietf-netext-pmip-cp-up-separation-02.txt>.

-Chairs

_______________________________________________
netext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netext

_________________________________________________________________________________________________________________________

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: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 26 Mar 2014 23:19:08 +0000

Hi Yokota-san,

Thanks for the review.

> How can MAG indicate its support by PBA?

Its a typo. Thanks for pointing to this. Will fix it.

Regards
Sri

From: Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 26, 2014 1:23 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation

Hi authors,

In Section 6,

Regards,

--
Hidetoshi Yokota

-Chairs

_______________________________________________
netext mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netext

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 26 Mar 2014 23:20:19 +0000

Hi Pierrick,

Thanks for the review.

> However architecture in figure 1 should be updated to clearly show this separation.

Ack. Will update the figure.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 26, 2014 3:31 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation

Hi

Sent from my mobile

---- Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>> wrote ----

Hi authors,

In Section 6,

Regards,

--
Hidetoshi Yokota

-Chairs

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 27 Mar 2014 11:04:41 +0900

Hi Pierrick

thanks for comments.

> However architecture in figure 1 should be updated to clearly show this separation. Fig 1 put both mag cp and mag up within the same box, which is a bit confusing regarding the scope of the documen…

We will fix this. 

> Although out of scope of the document, it would be worth to give indication on interface between mag cp and up (eg Capwap based) in order to have the full picture on how the solution can work.

We can clarify that this interface is out of scope. 
Do we need examples like capwap/forces/sdn in the document?

regards,
ryuji

>          in the 
> Proxy Binding Acknowledgement
> .  If the option is not

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 27 Mar 2014 11:05:14 +0900

Thanks Yokota-san for review! We will fix it.

ryuji

2014/03/27 午前8:19、Sri Gundavelli (sgundave) <[email-masked]> のメール：

> From: Hidetoshi Yokota <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>> [email-masked]://www.ietf.org/mailman/listinfo/netext
>

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 12:34:44 +0100

Dear all,
I also think that the draft is ready for RFC (from WG point of view).
Some more nits detected to be considered for next update:

p.5:
Generic Record Encapsulation => Generic Routing Encapsulation

p.8:
This variables indicates => This variable indicates

When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate 
=> shouldn't this be a normative MUST?

Finally might it be useful to include a reference to other C/U P separation work such as http://tools.ietf.org/html/draft-wakikawa-req-mobile-cp-separation-00 or http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-02 - what do you think?

Best regards 
Dirk

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 11:38:17 +0000

Hi all,

I have read the draft. I think that the draft is in a good shape and I think that we can proceed with the RFC publication process. However, I have some comments, which need some attention!

Comment_1: : In Section 3, the LMA user plane address mobility option is specified. Regarding the Length field the following is mentioned: "8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields." This is okay, but why is the Length field does not exclude in addition to the type and length fields, also the Reserved field. I think that this will make sense. You may change the description of the Length field to: "8-bit unsigned integer indicating the length of the option in octets, excluding the type, length and Reserved fields."

Comment_2: In Section 3, the LMA user plane address mobility option is specified. However, it is not clear what will be the format of this option when the LMA user plane address is an IPv4 address.
You could solve this by adding in the description of the LMA User Plane Address field what will be the value of the Length field when either an IPv4 is used or an IPv6 address is used. Note that this is partially done in Section 4. Note also that in the provided description of the Length field in Section 4, you already assume that the length of the option in octets, is already excluding the type, length and Reserved fields, while in Section 3, the Reserved field is not excluded.

Comment_3: In Section 3, the definition of the LMA User Plane Address field, you probably need to include the term LMA user plane, instead of LMA. This the description of this field can become: "Contains either the 32-bit IPv4 address of the LMA user plane, when the value of the Length field is set to 4, or the 128-bit IPV6 of the LMA user plane, when the value of the Length field is set to 16.

Comment_4: Regarding Figure 1, you might need to use different boxes for MAG CP and MAG-UP.

Comment_5: The IANA section might need more details, regarding what you are requesting!

Comment_6: typo, in Section 6, use Proxy Binding Update instead of Proxy Binding Acknowledgement .
Please change from:
When this variable on the MAG is set to a value of (0), the MAG must explicitly indicate its support-capability for this feature by including the LMA User Plane Address mobility Option in the Proxy Binding Acknowledgement.

INTO:
When this variable on the MAG is set to a value of (0), the MAG must explicitly indicate its support-capability for this feature by including the LMA User Plane Address mobility Option in the Proxy Binding Update.

Best regards,
Georgios

From: netext [mailto:[email-masked]] On Behalf Of Basavaraj Patil
Sent: woensdag 12 maart 2014 19:43
To: [email-masked]
Cc: [email-masked]
Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation

Hello,

-Chairs

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 27 Mar 2014 21:42:23 +0000

I think the draft addresses all relevant aspects and specifies the required option to
enable C/U-Plane separation on the LMA. The document is pretty concise, I'd say.
A few notes below for co-authors' consideration:

"1. Introduction: Widely deployed mobility management systems for wireless
communications require isolation between the path for forwarding data
packets (the user plane) and the control plane signaling..."

[marco] How can deployed systems require this? I thing deployed systems
utilize such split to gain advantage from it, e.g. more flexible
deployment. You may change the text to motivate a C-/U-Plane split
on the LMA 'to be more flexible in the deployment and placement of Control- and User-Plane
Functions' and that 'deployed systems for mobile communication utilize such
split already'.

"..require isolation between the path for forwarding data

   packets (the user plane) and the control plane signaling for mobility

   management."

[marco] 'isolation between paths' may not be clear. What about 'separation of IP-endpoints for PMIP signaling
and forwarding tunnel' ?

[marco] Text has no reference to Figure 1 and should be added, e.g. in the last paragraph of Section 1.

Section 6. Protocol Configuration Variables

[marco] Let me confirm the use of the configuration variable Domain-wide-LMA-UPA-Support:

If set, no explicit capability discovery is required and a MAG or LMA can
include the LMA UPA option if they want to use C/U-Plane separation, or
omit it.

If cleared, it means some components (MAGs and LMAs) may support the
feature, some others may not. So, if a MAG supports it MUST include the
option with a value of ALL_ZERO for the address field or omit the address field.

If not included, the LMA keeps record of MAGs which do not support the feature.
So, the configuration variable, if set, solely helps to reduce signaling message
size by omitting the option. Correct?

[marco] Check some editorial nits, e.g. Sect. 2 Terms:
MAG User Plane Address (MAG-UP):

The IP address on the MAG that is supports user plane tunnels with the LMA.

--> The IP address on the MAG that supports user plane tunnels with the LMA.

Section 4.

The MAG when including the LMA User Plane Address mobility option

in the Proxy Binding Update has to the apply the following

considerations:

--> The MAG when including the LMA User Plane Address mobility option

in the Proxy Binding Update has to apply the following

considerations:

and..

'apply the following considerations' --> 'apply the following rules' (?)

Hope that helps.

Best regards,

marco

From: netext [mailto:[email-masked]] On Behalf Of Basavaraj Patil
Sent: Mittwoch, 12. März 2014 19:43
To: [email-masked]
Cc: [email-masked]
Subject: [netext] WG last call: draft-ietf-netext-pmip-cp-up-separation

Hello,

-Chairs

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 31 Mar 2014 10:39:05 +0900

Hi Marco

Thanks for your review and the comments.

On 2014/03/28, at 午前6:42, Marco Liebsch <[email-masked]> wrote:

> enable C/U-Plane separation on the LMA. The document is pretty concise, I’d say.
> A few notes below for co-authors’ consideration:
>  
> “1. Introduction: Widely deployed mobility management systems for wireless
> packets (the user plane) and the control plane signaling…”
>  
> on the LMA ‘to be more flexible in the deployment and placement of Control- and User-Plane
> Functions’ and that ‘deployed systems for mobile communication utilize such
> split already’.
>  
>  
> “..require isolation between the path for forwarding data
>    management.”
> [marco] ‘isolation between paths’ may not be clear. What about ‘separation of IP-endpoints for PMIP signaling
> and forwarding tunnel’ ?

How about this?

Widely deployed mobility management systems for wireless
communications require separation of IP end points for fowarding data
packets (the user plane) and the mobility signaling (the control
plane). This separation brings more flexible deployment and
management of LMA and MAG(s) of Proxy Mobile IP.

> [marco] Text has no reference to Figure 1 and should be added, e.g. in the last paragraph of Section 1.

we will add reference.
> size by omitting the option. Correct? 

Yes, since PMIP is run in the managed domain, the operator should use this parameter as you explained above. 

> à The IP address on the MAG that supports user plane tunnels with the LMA.
>  
> Section 4.
> à The MAG when including the LMA User Plane Address mobility option
> ‘apply the following considerations’ à ‘apply the following rules’ (?)

Thanks for finding these errors!  really help!

regards,
ryuji