Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc

From: <[email-masked]>
Date: Thu, 8 Oct 2009 14:35:58 +0200

Hello,

One of the Netext WG milestones is:
Sep 2009                Initial WG draft on LMA Redirection

At IETF75, I-D draft-korhonen-netext-redirect was accepted as the
baseline to be adopted as the doc. Process requires that we also run
the consensus call on the WG ML.

The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6,
draft-korhonen-netext-redirect-04.txt has now been posted and this is
a consensus call for its adoption as WG doc.
http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt

Please respond by Oct 15th, 09.

-Chairs

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 12 Oct 2009 18:02:38 +0300

Hi,

I support this draft. I think it is a good starting point, going to the
right direction to fulfill the WG milestone.

Cheers,

Jonne.

On 10/8/09 3:35 PM, "Basavaraj Patil" <[email-masked]> wrote:

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

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Mon, 12 Oct 2009 22:55:30 +0200

Hi,

I support the adoption of this ID. I wonder however if the mid-session redirection described in section 5.5.2 brings more advantages than complexity. The authors may want to comment on this.

Thanks,

Telemaco 

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 8 octobre 2009 14:36
À : [email-masked]
Objet : [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc

Hello,

-Chairs

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 13 Oct 2009 14:04:41 +0800

Hi,
 
I support to adopt it to WG doc. It is appropriate time to go forward. Thank
you~!

BR
Jinwei

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, October 08, 2009 8:36 PM
To: [email-masked]
Subject: [netext] Consensus call to adopt I-D:
draft-korhonen-netext-redirect as WG doc

Hello,

 
 <http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt>

-Chairs

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 13 Oct 2009 08:20:24 +0200

Hi,

I also support the adoption of the draft as WG document.

Carlos

On Tue, 2009-10-13 at 14:04 +0800, Jinwei Xia wrote:
> Hi,
>  
> I support to adopt it to WG doc. It is appropriate time to go forward.
> Thank you~!
>  
>  
> BR
> Jinwei
> 
> 
>         
>         ______________________________________________________________
>         From: [email-masked] [mailto:[email-masked]]
>         On Behalf Of [email-masked]
-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: <[email-masked]>
Date: Wed, 14 Oct 2009 08:47:32 -0300

Hi all,

I support the adoption of this draft as a WG document.

Fuad Abinader

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext [email-masked]
	Sent: quinta-feira, 8 de outubro de 2009 08:36
	To: [email-masked]
	Subject: [netext] Consensus call to adopt I-D:
draft-korhonen-netext-redirect as WG doc

	Hello,

	At IETF75, I-D draft-korhonen-netext-redirect was accepted as
the
	baseline to be adopted as the doc. Process requires that we also
run
	the consensus call on the WG ML.
	 
	draft-korhonen-netext-redirect-04.txt has now been posted and
this is

	-Chairs

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 14 Oct 2009 09:15:36 -0500

Hi,
 
I read the draft and I believe, conceptually, the draft can work as a
base to fulfill the LMA redirection WG item. However, I see few things
in the draft that are beyond the scope of this WG charter "LMA
Redirection" item:

1.	
	Allowing redirection during re-registration does not make sense.
It is not within the scope of load balancing nor, after some short
discussion with the authors, there is a strong usecase for it to be
included.
2.	
	The draft demotes the use of IKEv2 for establishing the IPsec
between the MAG and LMA from "SHOULD" to "MAY". I also, believe that
this is not appropriate for the support of this functionality to
override RFC5213 requirements. It seems that there is some concern about
IPSec failing after the BCE has been created in the r2LMA but that
concern can be addressed without the proposed demotion/change.
3.	
	The draft proposes a new error code to basically indicate to the
MAG to use redirection functionality. Since, the LMA sends the new error
code without a previous knowledge of whether the MAG is a legacy one or
not, this cause value is NOT backward compatible. A proposal to use one
of the error codes in RFC5213, should address this concern and be
acceptable.

Regards, 
Ahmad

	Sent: Thursday, October 08, 2009 7:36 AM

	 
	Hello,

	 

	-Chairs

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 14 Oct 2009 17:31:06 +0300

Hi Ahmad,

Do I read you mail correctly that you do support the draft to become WG item
and thus, the basis for the work?

As accepting a draft as WG item is the start of the WG work, I guess your
concerns are basis of normal discussion for the WG to proceed when the draft
is accepted.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 14 Oct 2009 09:32:56 -0500

Hi Jonne,
Agreed!

Regards,
Ahmad

> -----Original Message-----
> From: Soininen, Jonne (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: Wednesday, October 14, 2009 9:31 AM
> To: Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil; [email-masked]
> Subject: Re: [netext] Consensus call to adopt I-D: 
> Do I read you mail correctly that you do support the draft to 
> become WG item and thus, the basis for the work?
> 
> As accepting a draft as WG item is the start of the WG work, 
> I guess your concerns are basis of normal discussion for the 
> WG to proceed when the draft is accepted.
> 
> Cheers,
> 
> Jonne.
> 
> > The draft demotes the use of IKEv2 for establishing the 
> IPsec between 
> > the MAG and LMA from "SHOULD" to "MAY". I also, believe 
> that this is 
> > not appropriate for the support of this functionality to override 
> > RFC5213 requirements. It seems that there is some concern 
> about IPSec 
> > failing after the BCE has been created in the r2LMA but 
> that concern 
> > can be addressed without the proposed demotion/change.
> > 3. 
> > The draft proposes a new error code to basically indicate 
> to the MAG 
> > to use redirection functionality. Since, the LMA sends the 
> new error 
> > code without a previous knowledge of whether the MAG is a 
> legacy one 
> > or not, this cause value is NOT backward compatible. A 
> proposal to use 
> > one of the error codes in RFC5213, should address this 
> concern and be 
> > acceptable.
> > 
> > Regards,
> > Ahmad
> > 
> > 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 14 Oct 2009 14:33:01 -0400

Hi Chairs,
   I support the adoption of this draft as a wg item.

Cheers
Suresh

On 09-10-08 08:35 AM, [email-masked] wrote:
> _http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt_
>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 15 Oct 2009 08:22:54 +0800

Hi all,

I support the adoption of this draft as a WG draft.

BR,
Mohana

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 08, 2009 8:36 PM
To: [email-masked]
Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc

Hello,

 

-Chairs

---

From: <[email-masked]>
Date: Thu, 15 Oct 2009 09:53:09 +0200

Hi all,

 BR,
 Pierrick

---

From: Jinwei Xia <[email-masked]>
Date: Fri, 16 Oct 2009 16:36:01 +0800

Hi Telemaco,
 
I think mid-session redirection scenario makes some sense and should be
taken into account. Some reasons have been given in section 4.2 of
"draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, abrupt
change of load condition etc). There is some other mid-redirection scenario,
for example, the failure of path between MAG and rfLMA can result in all
mobility sessions of the MNs attached on the MAG corrupt. These sessions
should be correctly redirected to r2LMA to mitigate avalanche.

BR
Jinwei

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
MELIA TELEMACO
Sent: Tuesday, October 13, 2009 4:56 AM
To: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt
I-D:draft-korhonen-netext-redirect as WG doc

Hi,

I support the adoption of this ID. I wonder however if the mid-session
redirection described in section 5.5.2 brings more advantages than
complexity. The authors may want to comment on this.

Thanks,

Telemaco 

  _____  

De : [email-masked] [mailto:[email-masked]] De la part de
[email-masked]
Envoyé : jeudi 8 octobre 2009 14:36
À : [email-masked]
Objet : [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect
as WG doc

Hello,

-Chairs

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 16 Oct 2009 08:41:36 -0500

Hi,
 
Well, which operational maintenance you have in mind which wait for the per-mobility session re-registration to come by to announce that hey.. we are having maintenance here, please go somewhere else? Also, how long that maintenance operation will last?
 
May be you can clarify that one, first.
 
Thanks.

Regards, 
Ahmad 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Jinwei Xia
	Sent: Friday, October 16, 2009 3:36 AM
	To: 'MELIA TELEMACO'; [email-masked]; [email-masked]
	Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc

	Hi Telemaco,
	 
	I think mid-session redirection scenario makes some sense and should be taken into account. Some reasons have been given in section 4.2 of "draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, abrupt change of load condition etc). There is some other mid-redirection scenario, for example, the failure of path between MAG and rfLMA can result in all mobility sessions of the MNs attached on the MAG corrupt. These sessions should be correctly redirected to r2LMA to mitigate avalanche.

	BR
	Jinwei

		From: [email-masked] [mailto:[email-masked]] On Behalf Of MELIA TELEMACO
		Sent: Tuesday, October 13, 2009 4:56 AM
		To: [email-masked]; [email-masked]
		Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc

		Hi,

		Thanks,

		Telemaco 

		 

		Hello,

		-Chairs

---

From: xiajinwei 65217 <[email-masked]>
Date: Sat, 17 Oct 2009 10:36:04 +0800

Hi

Sure, I know your question. In my mind, we can use this mid-session redirection associated with bulk-re-registration. 
Therefore, the LMA can perform redirection per MAG. In such case, the operation time will be short. 
In addtion, LMA can notify MAG the maintenance operation by out-of-band means. 

The path failure is another scenario describe how to redirect mobility sessions.

Maybe somebody has different thought on mid-session redireciton scenario. 

BR
Jinwei

> Hi,
> 
> Well, which operational maintenance you have in mind which wait 
> for the per-mobility session re-registration to come by to 
> announce that hey.. we are having maintenance here, please go 
> somewhere else? Also, how long that maintenance operation will last?
> 
> Behalf Of Jinwei Xia
> 	I think mid-session redirection scenario makes some sense and 
> should be taken into account. Some reasons have been given in 
> section 4.2 of "draft-korhonen-netext-redirect-ps-00" (e.g. 
> maintenance operation, abrupt change of load condition etc). There 
> is some other mid-redirection scenario, for example, the failure 
> of path between MAG and rfLMA can result in all mobility sessions 
> of the MNs attached on the MAG corrupt. These sessions should be 
> correctly redirected to r2LMA to mitigate avalanche.
>         
>         
> 	BR
> 	Jinwei
> 	
> 	
> 
>        	From: [email-masked] [mailto:netext-
> [email-masked]] On Behalf Of MELIA TELEMACO
>        	I support the adoption of this ID. I wonder however if 
> the mid-session redirection described in section 5.5.2 brings more 
> advantages than complexity. The authors may want to comment on this.
> 
>                 
> 
>        	Thanks,
> 
>        	Telemaco 
> 
>                 
> 
>        	
>        	De : [email-masked] [mailto:netext-
> [email-masked]] De la part de [email-masked]
>        	? : [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 16 Oct 2009 22:49:28 -0500

Hi,
Please see inline.

Regards,
Ahmad
> From: xiajinwei 65217 [mailto:[email-masked]] 
> Sent: Friday, October 16, 2009 9:36 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: MELIA TELEMACO; [email-masked]; [email-masked]
> Subject: 回复:RE: [netext] Consensus call to adopt 
> Sure, I know your question. In my mind, we can use this 
> mid-session redirection associated with bulk-re-registration. 
[Ahmad]
Well, that still does not solve the issue of making administrative maintenance which does not depend on this protocol to rely on sort of a random time of when the mobility session lifetime expires. Imagine having a 500,000 session on the LMA which spread across few MAGs, it is a nightmare!

> Therefore, the LMA can perform redirection per MAG. 
[Ahmad]
WOW!

You think that the BULK registration is for re-registering all the mobile node sessions on the MAG?
I better check that draft?

> In such 
> case, the operation time will be short. 
[Ahmad]
That is a very GOOD idea. Then this feature is NOT needed.
If the LMA is GOING to provide this information out-of-band, then the LMA can provide the MAG with the new LMA IP address? Right?
Mission Accomplished.

> The path failure is another scenario describe how to redirect 
[Ahmad]
Let us address one usecase at a time.

> > Well, which operational maintenance you have in mind which wait for 
> > the per-mobility session re-registration to come by to 
> announce that 
> > hey.. we are having maintenance here, please go somewhere 
> else? Also, 
> > how long that maintenance operation will last?
> > 
> > 	I think mid-session redirection scenario makes some 
> sense and should 
> > be taken into account. Some reasons have been given in 
> section 4.2 of 
> > "draft-korhonen-netext-redirect-ps-00" (e.g.
> > maintenance operation, abrupt change of load condition 
> etc). There is 
> > some other mid-redirection scenario, for example, the 
> failure of path 
> > between MAG and rfLMA can result in all mobility sessions 
> of the MNs 
> > attached on the MAG corrupt. These sessions should be correctly 
> > redirected to r2LMA to mitigate avalanche.
> >         
> >         
> > 	BR
> > 	Jinwei
> > 	
> > 	
> > 
> >        	I support the adoption of this ID. I wonder 
> however if the 
> > mid-session redirection described in section 5.5.2 brings more 
> >        	baseline to be adopted as the doc. Process 
> requires that we 
> > also run
> >

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 19 Oct 2009 12:12:29 +0800

Hi,

Please see inline

> > 
> > Sure, I know your question. In my mind, we can use this mid-session 
> > redirection associated with bulk-re-registration.
> [Ahmad]
> Well, that still does not solve the issue of making 
> administrative maintenance which does not depend on this 
> protocol to rely on sort of a random time of when the 
> mobility session lifetime expires. Imagine having a 500,000 
> session on the LMA which spread across few MAGs, it is a nightmare!

Right, bulk-re-registration method is only auxiliary method to mitigate the
network overhead, but which is unavoidable when a large amount of mobility
sessions expire during a short period. Especially in the case that rfLMA
suddenly crashes or the path between rfLMA and MAG fails, all related
mobility sessions will be redirected to a new LMA even if this scenario
belongs to LMA reliability other than load balance.  

> I better check that draft?

It is still bulk re-registration but not bulk registration, rfLMA must share
all mobility sessions of the MAG with r2LMA before taking administrative
maintenance. the sharing depends on possible context transfer and other
coordination management between the rfLMA and the r2LMA. 

> If the LMA is GOING to provide this information out-of-band, 
> then the LMA can provide the MAG with the new LMA IP address? Right?
> Mission Accomplished.

Sure, but out-of-band mean is another vague method and out of scope.

> 
> > 
> > The path failure is another scenario describe how to 
> redirect mobility 
> > sessions.
> [Ahmad]

"draft-wakikawa-netext-lma-reliability" is one case. 

BR
Jinwei

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 21 Oct 2009 02:15:54 -0500

Hi,

> > If the LMA is GOING to provide this information out-of-band, then
the 
> > LMA can provide the MAG with the new LMA IP address? Right?
> > Mission Accomplished.
> 
[Ahmad] 
Almost forgot about this ......

How the MAG would know when to send the re-registration for a chance
load balancing? By out-of-band signaling.
Why Not using the same out-of-band to communicate the LMA address?
Out-of-band signaling is vague and out of scope?

Interesting logic.

Regards,
Ahmad

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 21 Oct 2009 15:45:32 +0800

Hi,

> How the MAG would know when to send the re-registration for a 
> chance load balancing? By out-of-band signaling.

hmm~ this is not my meaning. EITHER sending redirection indiction OR
providing r2LMA address to MAG is out-of-band signaling, which can be
regarded as another method to solve maintenance operation. But this method
is out of scope in this draft. 

BR
Jinwei

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 21 Oct 2009 09:12:43 -0500

Hi,

> hmm~ this is not my meaning. EITHER sending redirection 
> indiction OR providing r2LMA address to MAG is out-of-band 
> signaling, which can be regarded as another method to solve 
> maintenance operation. But this method is out of scope in this draft. 
[Ahmad]
It seems we are going in a circle!

You mentioned that this feature is needed for maintenance event and load
balancing. NO? 

The argument, how this load balancing/maintenance feature relies on a
re-registration which is by nature has nothing to do with maintenance
and load balancing.

You said, to inform the MAG that a re-registration is NEEDED you use an
out-of-band signaling. see below from your earlier reply.

"
In addtion, LMA can notify MAG the maintenance operation by out-of-band
means. 
"

The question is: if in order to enable this feature you need an
out-of-band signaling ANYWAY! Why NOT include the LMA address in the
out-of-band signaling? You said because this out-of-band signaling is
VAGUE and out-of-scope.

Is that clear to you? 
My point is: this is a very interesting logic!

Regards,
Ahmad