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

Raj,

On Sep 12, 2011, at 4:29 PM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:

> 
> Hi Jouni,
> 
> Just one issue that still bothers me:
> 
>>> 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.
> 
>> 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.

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

> 
> Thx.
> -Raj
> 
> ________________________________________
> From: ext jouni korhonen [jouni.nospam@gmail.com]
> Sent: Monday, September 12, 2011 6:10 AM
> To: Patil Basavaraj (Nokia-CIC/Dallas)
> Cc: netext@ietf.org; draft-ietf-netext-redirect@tools.ietf.org
> Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-10
> 
> Raj,
> 
> Thanks for the review. See my comments inline.
> 
> On Sep 10, 2011, at 1:24 AM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:
> 
>> 
>> 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.
> 
>   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.
> 
>> 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)
> 
> Hmm.. I think there is no reason to repeat that technical stuff in Introduction.
> 
>> 3. s/assumed to have required Security Associations (SA)already set up
>>  in advance./assumed to have the required Security Associations (SA)
>>  pre-established.
> 
> Ack.
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> Ack.
> 
> 
>> 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.
> 
> Ack.
> 
> And thanks,
>        Jouni
> 
> 
>> 
>> -Raj
>> 
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
> 