[netext] FW: End Marker enhancements for PMIP Update Notification

["Sri Gundavelli (sgundave)" <[e-mail]>]

FYI. Discussion with 3GPP SA2/CT4 members on adding a new status code value to the Update Notification draft.

This draft has just finished WG LC call, but we plan to make this change (adding a Reason Code) and keep the semantics clean.

Comments welcome.

Regards
Sri





From: Itsuma TANAKA <[e-mail]<mailto:[e-mail]>>
Date: Monday, June 10, 2013 1:12 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'BERRY, Nigel (Nigel)'" <[e-mail]<mailto:[e-mail]>>, "'Wild, Peter Alexander, Vodafone DE'" <[e-mail]<mailto:[e-mail]>>, 'Frank Yong Yang' <[e-mail]<mailto:[e-mail]>>, "'Shishufeng (Susan)'" <[e-mail]<mailto:[e-mail]>>, 'Shahab Lavasani' <[e-mail]<mailto:[e-mail]>>, "'Milton, Lew (NSN - US/Arlington Heights)'" <[e-mail]<mailto:[e-mail]>>, "'LANDAIS, BRUNO (BRUNO)'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Nirav Salot (nsalot)" <[e-mail]<mailto:[e-mail]>>, 'Rahul Suhas Vaidya' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Jesus De Gregorio' <[e-mail]<mailto:[e-mail]>>, 'Peter Schmitt' <[e-mail]<mailto:[e-mail]>>, 'Hidetoshi Yokota' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Basavaraj Patil (basavpat)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Atsushi Minokuchi' <[e-mail]<mailto:[e-mail]>>, 'Zhen Miao' <[e-mail]<mailto:[e-mail]>>
Subject: RE: End Marker enhancements for PMIP Update Notification

Dear Sri, all,

Many thanks…
First of all we’re NOT thinking about introducing a new Reason value specific to “end marker”.
And we’re ok to re-use the existing Reason value (i.e. “UPDATE-SESSION-PARAMETERS”) if everybody is happy with it.
And I also fully agree with your statement that “the option/use-case should be broadly applicable beyond 3GPP system”

>if this does not sound like a clean approach, we can certainly define a new Status Code, which is "Vendor-Specific Reason (3)".   The peer can handle the UPN message based on that vendor-specific option. Is this what you are thinking ?

But actually I like your idea of adding a generic new value (“Vendor-Specific Reason (3)”), because I sense there’s a possibility that:

1.      CT4 argues re-using existing one is not clean

2.     There may be new enhancements in the future which might require addition of new cause value
So if we could have something generic in the I-D, I think this makes it pretty much future proof.
If we could do that addition now, then I think it’s also good from IETF procedure point of view (I mean less delay in the process…as we don’t need to wait for CT4 discussion)

What do you think? I’d like to also invite comments from other companies…

Regards,
Itsuma

--------------------------------------------------------
Itsuma TANAKA (田中威津馬)
GSMA IREG Vice Chair / IREG Packet Chair

NTT DOCOMO, Inc.
--------------------------------------------------------


From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
Sent: Monday, June 10, 2013 4:31 PM
To: Itsuma TANAKA; [e-mail]<mailto:[e-mail]>; 'BERRY, Nigel (Nigel)'; 'Wild, Peter Alexander, Vodafone DE'; 'Frank Yong Yang'; 'Shishufeng (Susan)'; 'Shahab Lavasani'; 'Milton, Lew (NSN - US/Arlington Heights)'; 'LANDAIS, BRUNO (BRUNO)'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nirav Salot (nsalot); 'Rahul Suhas Vaidya'; [e-mail]<mailto:[e-mail]>; 'Jesus De Gregorio'; 'Peter Schmitt'; 'Hidetoshi Yokota'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Basavaraj Patil (basavpat)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 'Atsushi Minokuchi'; 'Zhen Miao'
Subject: Re: End Marker enhancements for PMIP Update Notification

Hi Itsuma-san,

Thanks for your response.

> So is it correct understanding that 3GPP can define their own “Notification Reason”?

We were not thinking of defining a Reason Code for this outside the Vendor-Specific option.

The Reason Code in the UPN message when this Vendor-specific option is included can be "UPDATE-SESSION-PARAMETERS", which does not require the peer to send a new PBU, but instead requires it to update the session state. That update and the associated action is what the Vendor-Specific option defines (when present).

The presence of the Vendor-Specific option hints the peer to conform to a specific behavior and that behavior is what CT4 defines. If there are multiple Actions associated with this Vendor-specific option, the option itself can define a vendor specific Action/Reason Code.

But, if this does not sound like a clean approach, we can certainly define a new Status Code, which is "Vendor-Specific Reason (3)".   The peer can handle the UPN message based on that vendor-specific option. Is this what you are thinking ?

But, if the Reason Code needs to hint specifically to "End Marker" use-case, then IMO, the option/use-case should be broadly applicable beyond 3GPP system. Easier approach is to contain the usecase/behavior/action to the vendor-specific option and keep this to 3GPP.


> The next 3GPP CT4 meeting will be in August 2013 – so isn’t it a bit too late when some changes/clarification are needed in IETF?

We can delay the process and keep the draft in the working group for some more time. The other approach is to get more inputs from all the interested companies and find a closure.



Regards
Sri




From: Itsuma TANAKA <[e-mail]<mailto:[e-mail]>>
Date: Sunday, June 9, 2013 11:12 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'BERRY, Nigel (Nigel)'" <[e-mail]<mailto:[e-mail]>>, "'Wild, Peter Alexander, Vodafone DE'" <[e-mail]<mailto:[e-mail]>>, 'Frank Yong Yang' <[e-mail]<mailto:[e-mail]>>, "'Shishufeng (Susan)'" <[e-mail]<mailto:[e-mail]>>, 'Shahab Lavasani' <[e-mail]<mailto:[e-mail]>>, "'Milton, Lew (NSN - US/Arlington Heights)'" <[e-mail]<mailto:[e-mail]>>, "'LANDAIS, BRUNO (BRUNO)'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Nirav Salot (nsalot)" <[e-mail]<mailto:[e-mail]>>, 'Rahul Suhas Vaidya' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Jesus De Gregorio' <[e-mail]<mailto:[e-mail]>>, 'Peter Schmitt' <[e-mail]<mailto:[e-mail]>>, 'Hidetoshi Yokota' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Basavaraj Patil (basavpat)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Atsushi Minokuchi' <[e-mail]<mailto:[e-mail]>>, 'Zhen Miao' <[e-mail]<mailto:[e-mail]>>
Subject: RE: End Marker enhancements for PMIP Update Notification

Dear Sri,

Thanks for the prompt feedback here.
So is it correct understanding that 3GPP can define their own “Notification Reason”?
Then it’s a good news for me, as we don’t possibly need to take any action in IETF.


  *   The Reason Code that we have currently allows the LMA to request the MAG to re-register (this implicitly includes de-register), or just update the session parameters.
The “End Marker” indication added in 3GPP is not to re/de-register or to update the session parameter, but to let MAG to behave in a certain way (e.g. generate “end marker” packet towards the radio access).  Can the current I-D cover such scenario as well?

>Its not too late, we can certainly make changes/add clarification notes before it hits IESG in the coming weeks.

The next 3GPP CT4 meeting will be in August 2013 – so isn’t it a bit too late when some changes/clarification are needed in IETF?

Regards,
Itsuma

--------------------------------------------------------
Itsuma TANAKA (田中威津馬)
GSMA IREG Vice Chair / IREG Packet Chair

NTT DOCOMO, Inc.
--------------------------------------------------------


From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
Sent: Monday, June 10, 2013 3:02 PM
To: Itsuma TANAKA; [e-mail]<mailto:[e-mail]>; 'BERRY, Nigel (Nigel)'; 'Wild, Peter Alexander, Vodafone DE'; 'Frank Yong Yang'; 'Shishufeng (Susan)'; 'Shahab Lavasani'; 'Milton, Lew (NSN - US/Arlington Heights)'; LANDAIS, BRUNO (BRUNO); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nirav Salot (nsalot); 'Rahul Suhas Vaidya'; [e-mail]<mailto:[e-mail]>; 'Jesus De Gregorio'; 'Peter Schmitt'; 'Hidetoshi Yokota'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Basavaraj Patil (basavpat)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 'Atsushi Minokuchi'; Zhen Miao
Subject: Re: End Marker enhancements for PMIP Update Notification

Hi Itsuma-san,

+ Basavaraj

I had a chat with Yokota-san on this and here is my view on this requirement.

  *   Update Notification (UPN) provides the basic semantics for LMA initiated notification messages
  *   Any of the Mobility Header options defined for PMIPv6 signaling messages can be carried in the UPN/UPNA message, including RFC5094 VSE
  *   CT4 can define a new 3GPP VSE based on RFC5094 for supporting End Marker enhancement. This being very 3GPP specific, it makes sense not to define a generic IETF MH option for this
  *   The Reason Code that we have currently allows the LMA to request the MAG to re-register (this implicitly includes de-register), or just update the session parameters.
  *   The 3GPP VSE when carried with one of the above two Reason Codes, should be sufficient for the MAG to handle this correctly. But, if are expecting some new behavior, we can certainly define a new Reason Code and specify that Action.

Its not too late, we can certainly make changes/add clarification notes before it hits IESG in the coming weeks.  But, what we have may be sufficient.


Regards
Sri



From: Itsuma TANAKA <[e-mail]<mailto:[e-mail]>>
Date: Sunday, June 9, 2013 10:23 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'BERRY, Nigel (Nigel)'" <[e-mail]<mailto:[e-mail]>>, "'Wild, Peter Alexander, Vodafone DE'" <[e-mail]<mailto:[e-mail]>>, 'Frank Yong Yang' <[e-mail]<mailto:[e-mail]>>, "'Shishufeng (Susan)'" <[e-mail]<mailto:[e-mail]>>, 'Shahab Lavasani' <[e-mail]<mailto:[e-mail]>>, "'Milton, Lew (NSN - US/Arlington Heights)'" <[e-mail]<mailto:[e-mail]>>, "LANDAIS, BRUNO (BRUNO)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Nirav Salot (nsalot)" <[e-mail]<mailto:[e-mail]>>, 'Rahul Suhas Vaidya' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Jesus De Gregorio' <[e-mail]<mailto:[e-mail]>>, 'Peter Schmitt' <[e-mail]<mailto:[e-mail]>>, 'Hidetoshi Yokota' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Atsushi Minokuchi' <[e-mail]<mailto:[e-mail]>>, Zhen Miao <[e-mail]<mailto:[e-mail]>>
Subject: End Marker enhancements for PMIP Update Notification

Dear PMIP Experts in CT4 and the Editors of PMIP Update Notification I-D.

I’d like to draw your attention on the attached Rel-12 CRs to 3GPP TS23.401 and TS23.402, which were agreed in SA2#97 a couple weeks ago. These CRs enhances GTP/PMIP protocols to add the support of “end marker”, and since I’m particularly concerned about how to progress the PMIP Stage 3, I appreciate your views here.

We (DOCOMO) believe that this enhancement can be done using PMIP Update Notification.  My understanding is that WG Last Call for this I-D is in progress in IETF, and I’m of the opinion that coordination between 3GPP and IETF might be necessary.

So I’d like to kindly ask your views on:

-       Whether these additions can be realized without impacting IETF Update Notification I-D?

-       If IETF impact is inevitable, can we raise this directly in IETF and stop the process until CT4 agrees on the way forward?

For the first question, the only impact on the I-D I’m seeing here is adding a new “Notification Reason” value.
I’d like to know if any addition on “Notification Reason” header needs any IETF work.
Or can this be specified in 3GPP (and subsequent IANA registration) only?

Best Regards,
Itsuma

--------------------------------------------------------
Itsuma TANAKA (田中威津馬)
GSMA IREG Vice Chair / IREG Packet Chair

NTT DOCOMO, Inc.
--------------------------------------------------------