[netext] Review of draft-ietf-netext-pmipv6-sipto-option-03

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 06 February 2012 07:58 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 54AA821F855F for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 23:58:21 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLkMJXBp4Jp for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 23:58:20 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 54F8921F8453 for <netext@ietf.org>; Sun, 5 Feb 2012 23:58:20 -0800 (PST)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4ABCC75ABE0 for <netext@ietf.org>; Mon, 6 Feb 2012 08:58:18 +0100 (CET)
Message-ID: <1328515089.3833.8.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: "netext@ietf.org" <netext@ietf.org>
Date: Mon, 06 Feb 2012 08:58:09 +0100
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tdjO8XF1+BtVDx3oC8zo"
X-Mailer: Evolution 3.2.2-1
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18692.003
Subject: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03
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: Mon, 06 Feb 2012 07:58:21 -0000

Hi,

Some additional comments after a quick review of the draft:

- Section 3.1: I think there is a problem with the references, because
it appears in thge text: "If the received Proxy Binding Update includes
the IP Traffic Offload Selector option Section 4". I guess it should
say: "If the received Proxy Binding Update includes the IP Traffic
Offload Selector option (Section 4)". There are more instances referring
to other sections.

- Section 4. The IPTS options has the field "TS Format", which resembles
the option defined in RFC 6089 for the traffic selector sub-option, and
in this way re-uses the binary TS defined for IPv4 in RFC 6088. However,
the draft defines a new IANA space for this "TS Format" field, which
might be a bit confusing. Can we just re-use RFC 6089 space (now it only
has three values reserved: "0" that should not be used, and "1" for
binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some
redundancy that might lead to confusion. If we do that, the draft would
probably need to define a flag or something to catch what it is now done
by putting a "TS Format" equal to "0".

- By doing offloading, there are issues associated to handovers (if the
mobile node moves, any traffic that was being offloaded would need to be
restarted). I guess some text on that would be helfpul.

Hope this helps,

Carlos

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