Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)

"Sri Gundavelli (sgundave)" <> Tue, 24 September 2013 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 964BD11E811F; Tue, 24 Sep 2013 05:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zvaTZ5+nwDsS; Tue, 24 Sep 2013 05:53:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9883B11E8120; Tue, 24 Sep 2013 05:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3132; q=dns/txt; s=iport; t=1380027188; x=1381236788; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kawV55WWh0n+EhsO8coSqYzHfHNPDLD+mIV8Pl3J1Xs=; b=fPs21/v8hGvMSLvYDhB/+XFUbBbdKh4eoLAy4HZfo7b7p4yq7eh/ld6v MGOKESBjGSK8rKIDhTxmQebKkJ821rjxzB7xI1Ac+V/N6RupZOH+7ve6j YkrXWtj1hmUdELJGdn11Ijbqa9oMfLjtYpT2szzrwSqLW1F7MU0HOaUlx c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.90,970,1371081600"; d="scan'208";a="263788651"
Received: from ([]) by with ESMTP; 24 Sep 2013 12:53:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8OCr79S001092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 12:53:07 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 07:53:07 -0500
From: "Sri Gundavelli (sgundave)" <>
To: Stephen Farrell <>, The IESG <>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)
Thread-Index: AQHOuSUD72u2CSfM6UK8YmdDgylKOA==
Date: Tue, 24 Sep 2013 12:53:06 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 12:53:13 -0000

Hi Stephen,

Thanks for the reviews.

> 5.2: What happens if the IPsec SA is re-negotiated

Renegotiation of IPSec SA should result in updated SPD and PAD entries at
both the peers. Wondering, if MAG/LMA entities need to be aware of this,
or assume IKEv2/IPsec layer is handling that. SA Renegotiation could
potentially occur in the base protocol without this extension as well. I'm
thinking, as long as the SPD entries cover the new MH type, the
handling/validation is happening at the correct layers and no new checks
are needed. 

> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons
>need an explanation and/or (forward) reference.

This is a request for updated Access Network Identifier parameters.
Section 6.1 has some text for each of the NR codes.

*  If the Notification Reason is set to a value of (4) "ANI-
         PARAMS-REQUESTED", then the mobile access gateway MUST send a
         Proxy Binding Update message to the local mobility anchor with
         the Access Network Identifier Option [RFC6757
<>].  The Access
         Network Identifier option MUST reflect the current access
         network parameters for that mobility session as known to the
         mobile access gateway at the time of sending the Proxy Binding
         Update message.


On 9/24/13 3:38 AM, "Stephen Farrell" <> wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-netext-update-notifications-08: Discuss
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>Please refer to
>for more information about IESG DISCUSS and COMMENT positions.
>The document, along with other ballot positions, can be found here:
>5.2: What happens if the IPsec SA is re-negotiated
>automatically? Isn't there a potential layering/sync problem
>so that these notifications couldn't ever be verified since a
>new SA would be in use? I think you just need to say the same
>or an automatically renegotiated SA (not sure what's the
>right terminology, sorry). I think 6.1 has the same issue and
>maybe other bits too. That kind of check also seems to
>imply that the interface between the MAG or LMA and the
>IPsec code needs to know that the right SA is being used
>which could be tricky. What's really done here?
>- 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all
>these reasons need an explanation and/or (forward) reference.