Re: [MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01

Hi Jouni:

Thanks for the review. Response below.




On 2/9/11 2:40 AM, "jouni korhonen" <[email protected]> wrote:

> Hi,
> 
> In beijing meeting I volunteered to review
> draft-gundavelli-mext-dsmip-ipv4-overlap-01.
> 
> Some content concerning comments follow.
> 
>       address is not uniquely assigned to a single mobile node.  The
>       home agent MUST make the forwarding decision based on the context
>       identifier that is associated with the received packet and the
>       context identifier in the Binding Cache entry.
> 
> This is an implementation issue.. entirely. It can be a context identifier
> (any kind that suffices for the purpose) or the whole HA instance can be
> running in a separate routing context.
>

Ok. Can be reworded.

 
>    o  In deployments where the home agent is supporting hosted home
>       agent service model, the context identifier field of the Binding
>       Cache entry MUST be set to the identifier of the tunnel
>       established between the home agent and the enterprise gateway.
> 
> Implementation issue again. I do not see why the HA or binding cache internal
> implementation is enforced here using RFC2119 language.
> 

We need additional parameters in the BCE state. BCE is a conceptual entry,
an implementation may choose to build it differently. Fine. Will reword it
to reflect general guidance.


> Actually most material in Section 4.1.2. Signaling Considerations are purely
> internal to HA implementation. I do not really see a compelling reason why to
> document these. In past when we standardized GRE encap for PMIP6 that had
> similar concerns regarding the LMA. However, that was a different case as we
> got an impact also on wire and specification of new signaling.
> 

There is some behavior expected from the home agent. We need to specify how
to implement the feature and this needed, IMO.



> In Section 4.2.  Mobile Node Considerations it is stated:
> 
>    This specification does not introduce any new considerations for the
>    mobile node implementation.  The IPv4 private address assigned from
> 
> If this document has no on wire protocol implications, then there is no
> interoperability issues from the protocol point of view. The HA product either
> supports overlapping private addresses or does not. Therefore, I cannot really
> see why the document aims to be a Proposed Standard? It could be Informational
> if these points of the HA internal workings has to be documented. So, I would
> say that Informational without any RFC2119 language is OK.
> 

Fair Point. We can have that discussion.



>       However, the assigned addresses MUST be unique within the 3GPP APN
>       scope (Ex: @internetsvcs.cisco.com).  The default value for this
> 
> I would give a reference to APN and a short description of it as APN is such
> an alien concept within IETF. Also the example "@internetsvcs.cisco.com" is
> incorrect if it attempts to give an example of an APN (there is no '@' in
> APN).
> 

Not after Service Selection Option was standardized and draft-korhonen-v6ops
was published, I thought ? Sure, I can add.

Thanks again for the review.

Regards
Sri


> 
> - Jouni
> _______________________________________________
> MEXT mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mext