Re: [netext] WG LC: draft-ietf-netext-pmip-lr

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sun, 12 June 2011 11:00 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581DC11E808F for <netext@ietfa.amsl.com>; Sun, 12 Jun 2011 04:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWHkuXkdhaRd for <netext@ietfa.amsl.com>; Sun, 12 Jun 2011 04:00:01 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B811E8085 for <netext@ietf.org>; Sun, 12 Jun 2011 04:00:00 -0700 (PDT)
X-uc3m-safe: yes
Received: from [192.168.1.3] (82.159.31.107.dyn.user.ono.com [82.159.31.107]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 5A308712D70; Sun, 12 Jun 2011 12:59:59 +0200 (CEST)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
In-Reply-To: <4DF29B57.5080104@ericsson.com>
References: <C9D30585.133B8%basavaraj.patil@nokia.com> <1304101629.2499.54.camel@acorde.it.uc3m.es> <4DE965B4.8090201@ericsson.com> <1307343107.4029.7.camel@acorde.it.uc3m.es> <4DF29B57.5080104@ericsson.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zbtCA2u6vdmPEGF27GIU"
Organization: Universidad Carlos III de Madrid
Date: Sun, 12 Jun 2011 12:59:59 +0200
Message-ID: <1307876399.7775.32.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18194.006
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] WG LC: draft-ietf-netext-pmip-lr
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jun 2011 11:00:02 -0000

Hi Suresh,

On Fri, 2011-06-10 at 18:31 -0400, Suresh Krishnan wrote:
> Hi Carlos,
>    Addressing the 4 open issues from the last mail.
> 
> On 11-06-06 02:51 AM, Carlos Jesús Bernardos Cano wrote:
> >>> - Using LRI in both MAG-to-LMA and LMA-to-MAG makes the protocol a bit
> >>> complex, because they are not used exactly for the same thing (they are
> >>> more than just initiators, as I understand them).
> 
> Yes. There is complexity involved here, but not because of the messages 
> being bidirectional. The root of the complexity is that the MAG and the 
> LMA can both be initiators. We tried a lot to come up with a 

Right.

> deterministic model where one entity can always be the initiator and we 
> could not do so.

But couldn't different messages be used? I think it makes the state
machine more complex to use the same message type as initiator in
different directions. Anyway, this is an implementation related comment,
and I'm not that experienced in implementing stuff...

> 
> >>> - Section 7. Why cannot just the MAG stop performing LR when detects
> >>> that one of the MNs is no longer attached/delivery to one of the MNs
> >>> fails?
> 
> This is exactly how it is done. In A12 (before it turns into A22) the 
> MAG is the initiator and the text says that the initiator should tear 
> down the session.

OK, maybe I missed that.

> 
> >>> - Section 8. Isn't in the scope the case the MAG has an IPv4-only
> >>> address? I guess for that case it is needed to define also a MAG IPv4
> >>> address, right?
> 
> We left it out of scope since an IPv4-only MAG is explicitly ruled out 
> by RFC5844

In any case, if the MAG and LMA are separated by an IPv4 network (as
explained in RFC5844), don't we need an MAG IPv4 address option as we do
for the case of the MAG IPv6 address? I'm missing why if IPv4 transport
between MAG and LMA is supported by RFC5844, we are ruling out that in
the LR spec.

> 
> "Both the mobility entities, the local mobility anchor and the
>   mobile access gateway are dual-stack (IPv4/IPv6) enabled.
>   Irrespective of the type of transport network (IPv4 or IPv6)
>   separating these two entities, the mobility signaling is always
>   based on Proxy Mobile IPv6 protocol."

One thing is the signaling being based on PMIPv6, and another is that
packets are transported in IPv6 or IPv4 packets. If transport is
IPv4-based, then the LMA needs to know the IPv4 address of the MAG,
right?

> 
> >>> - Section 9.1 (page 17). In the LRI message, couldn't a lifetime value
> >>> set to 0 used instead of the S=1 flag?
> 
> Yes. This is possible, but is there any benefit to changing this?

Well, if there is a simpler way of doing something (without defining new
fields), the fair question would be IMHO, is there any benefit in
defining the S flag?

Carlos

> 
> Thanks
> Suresh
> 

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67