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

From: jouni korhonen <[email-masked]>
Date: Wed, 9 Feb 2011 12:40:29 +0200

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.

   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. 

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.

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.

      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).

- Jouni

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 09 Feb 2011 17:42:16 -0800

Hi Jouni:

Thanks for the review. Response below.

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

> Hi,
> 
> In beijing meeting I volunteered to review
> draft-gundavelli-mext-dsmip-ipv4-overlap-01.
> 
> 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.

> 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.

> 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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: jouni korhonen <[email-masked]>
Date: Thu, 10 Feb 2011 09:48:58 +0200

Hi Sri,

> was published, I thought ? Sure, I can add.

Right ;) A reference to draft-korhonen-v6ops section 2.2 would probably do..

- JOuni