Subject: [netext] Review of I-D: draft-ietf-netext-redirect-10

From: <[email-masked]>
Date: Fri, 9 Sep 2011 22:24:50 +0000

My WGLC review comments on Rev 10 of the I-D: draft-ietf-netext-redirect

1. Abstract can be improved. Rather than just mentioning the scope you
   could describe briefly the feature specified in this I-D.

2. Would be useful to describe in the introduction how runtime LMA
   assignment is different from the normal mode as specified in
   RFC5213 (which you do in Sec 5.2 1st paragraph)

3. s/assumed to have required Security Associations (SA)already set up
   in advance./assumed to have the required Security Associations (SA)
   pre-established.

4. In Section 4, it would be useful to explain (in brief) what is the
   functionality of a specific option. For example the
   'Redirect-Capability Mobility Option': The text has no explanation
   what this option is supposed to do in a message. You could add at
   least one sentence saying that it is used to indicate the redirect
   capability supported by the MAG, LMA entitied.

5. Missing the direction of the signaling flow message no 1 in fig 1.

6. s/There is no need to resend a PBU to the r2LMA after a successful
   runtime assignment./The MAG is not required to send a fresh PBU to
   the r2LMA after a successful runtime assignment.

7. s/The MAG MUST send subsequent binding refreshing PBUs and user
   traffic to the new r2LMA address./
   The MAG MUST send all user traffic to the r2LMA address. The MAG MUST
   send subsequent binding refresh PBUs to the r2LMA address.

-Raj

---

From: jouni korhonen <[email-masked]>
Date: Mon, 12 Sep 2011 14:10:28 +0300

Raj,

Thanks for the review. See my comments inline.

>   could describe briefly the feature specified in this I-D.

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6. The runtime Local Mobility Anchor assignment takes place during
   a Proxy Binding Update and a Proxy Binding Acknowledgement message
   exchange between a Mobile Access Gateway and a Local Mobility Anchor.
   The runtime Local Mobility Anchor assignment functionality defined in
   this specification can be used, for example, for load balancing purposes.

>   RFC5213 (which you do in Sec 5.2 1st paragraph)

Hmm.. I think there is no reason to repeat that technical stuff in Introduction.

>   in advance./assumed to have the required Security Associations (SA)

Ack.

>   capability supported by the MAG, LMA entitied.

I see your point. However, these texts were removed by discuss comments in IESG.

> 5. Missing the direction of the signaling flow message no 1 in fig 1.

Ack.

>   the r2LMA after a successful runtime assignment.

Ack.

>   send subsequent binding refresh PBUs to the r2LMA address.

Ack.

And thanks,
	Jouni

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

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 13:29:02 +0000

Hi Jouni,

>I see your point. However, these texts were removed by discuss comments in IESG.

I disagree. I think that text explaining the decription of the option is useful and helps readability.
If you see Secs 6.2.4, .5 etc in RFC3775 as an example, these are also options for MIP6 and they
do provide a brief explanation. Having such text IMO would be useful in this I-D.

Thx.
-Raj

________________________________________
From: ext jouni korhonen [[email-masked]]
Sent: Monday, September 12, 2011 6:10 AM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-10

Raj,

Ack.

Ack.

Ack.

Ack.

And thanks,
        Jouni

---

From: jouni korhonen <[email-masked]>
Date: Fri, 16 Sep 2011 14:16:45 +0300

Raj,

> do provide a brief explanation. Having such text IMO would be useful in this I-D.

Fair enough. How about:

4.1.  Redirect-Capability Mobility Option

   ...
   o  Reserved: This field is reserved for future use.  MUST be set to
      zero by the sender and ignored by the receiver.

   The Redirect-Capability option is used by the MAG to inform the LMA
   that is implements and has enabled the runtime LMA assignment 
   functionality.

4.2.  Redirect Mobility Option

   ...
   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present when the corresponding PBU was sourced from an
      IPv4 address (for IPv4 transport, see [RFC5844]).

   The Redirect option is used by the LMA to inform the MAG that the
   runtime LMA assignment took place and the MAG has to update its
   Binding Update List Entry (BULE) for the mobility session.

I suppose I need to submit a new revision asap..?

- Jouni

- Jouni

---

From: <[email-masked]>
Date: Fri, 16 Sep 2011 11:40:49 +0000

Thanks Jouni. Your proposed edits look good. Please go ahead and submit a revise version. 
WGLC closed yesterday and I have not seen any other comments. I will forward the I-D back to the IESG as soon as you publish a new rev of the I-D.

-Raj
Sent: Friday, September 16, 2011 6:16 AM

Raj,

Fair enough. How about:

   ...

   ...

- Jouni

- Jouni