My review of this I-D.

<= /div>

-Raj

Comments:

---------

In order to ensure interoperability, the I-D should sta= te that if an

LMA sends an Update notification to a MAG and does not receive an Ack,=

then the MAG may not support the ability to update sessions.=A0<= /div>

The I-D should specify a backoff mechanism in terms of retransmit= ting

an update message from the LMA and stop after X number of messages

with no response.=A0

The update notificatio= n message could be abused by the introduction of

a vendor specifi= c notification reason. The specification should

mandate the registration of all notification reasons in IANA and not

allow any vendor specific types.

Editorial:

s/ These update n= otifications are exchanged using a Mobility

=A0 =A0Header message type specifically designed for this purpose./The= se

=A0 =A0update notifications are exchanged using a new Mobility= =A0

=A0 =A0Header message type specifically designed for this pur= pose.

Comment:

The Introduction star= ts off as : "In some situations, there is a need

for the loc= al mobility anchor ..."=A0

This is pretty ambiguous. Please = rephrase.

s/The base Proxy

=A0 =A0Mobile IPv6 specifica= tion does not have a provision for this./ The

=A0 =A0base Proxy M= obile IPv6 specification does not have a provision for

=A0 =A0sen= ding unsolicited informational messages from the LMA to the

=A0 =A0MAG.=A0

s/participation from the mobil= e node/participation by the mobile node=A0

s/for t= he mobile node in Mobile IPv6 [RFC6275]/for the mobile node as

sp= ecified in Mobile IPv6 [RFC6275]

Q: ID states:

"One such scenario where s= uch a mechanism is needed is when the local

=A0 =A0mobility ancho= r wants to inform the mobile access gateway that it

=A0 =A0needs = to re-register mobility session for a mobile node."

In what scenario would the LMA want to inform the MAG t= hat an MN needs

to be re-registered?

s/a= nd so it can obtain the updated policy/in order to update the

policies associated with the mobility session of an MN.

s/or and updated IPv4/or an updated IPv4

--
Basavaraj Patil

--089e0141a5e4308e3b04dc3bebb5-- From internet-drafts@ietf.org Thu May 9 09:03:59 2013 Return-Path: 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 3001221F94B1; Thu, 9 May 2013 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 CJZRi63tWQPi; Thu, 9 May 2013 09:03:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A652921F9418; Thu, 9 May 2013 09:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509160358.13475.2166.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 09:03:58 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-04.txt X-BeenThere: netext@ietf.org 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: Thu, 09 May 2013 16:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-04.txt Pages : 17 Date : 2013-05-09 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bpatil1@gmail.com Mon May 13 12:19:36 2013 Return-Path: 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 412E521F896B for ; Mon, 13 May 2013 12:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, NO_RELAYS=-0.001] 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 6dHJXsaxkeFu for ; Mon, 13 May 2013 12:19:35 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4672321F8956 for ; Mon, 13 May 2013 12:19:35 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id vb8so1119278obc.28 for ; Mon, 13 May 2013 12:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=nxFrMKpKv5VvOFrDPSeMAUsrZqmb3UgxbR6UAiiy/nQ=; b=SNNje6FTfilNeIpiR2W3zVxsFFb9p3Vl0h6GWcm8b9FpHSRukMOZ1839DXQjU5KPl5 AuE9HljO23qVtXklt2ZOEC4rhPjsEGvjU/q3+H0h2HEVGMrmRT7VQxTL8KMmi5vWIkUs cKt0naAw++k9jbCSyjgGXi3y8tVtHRARVBRWTBkxamV86eXKCC3fLBVFH+B2QBOjncLh VcrRiHjrlDUX65W3Dc+/kR2m7kCPUaVfqqw41gUYP9YnacFZNtnbKOtqTYu1hN3dQcUC OUM+/jqYbTuMZCRn6YwAd/3fa+jn94aHYKcnEj2eGhOEMi5XOk7gGg1ASJz8/rT7WNon lTMw== MIME-Version: 1.0 X-Received: by 10.60.96.35 with SMTP id dp3mr14357672oeb.21.1368472774803; Mon, 13 May 2013 12:19:34 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Mon, 13 May 2013 12:19:34 -0700 (PDT) Date: Mon, 13 May 2013 14:19:34 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e011775a7a0884704dc9e652a Subject: [netext] Review of I-D: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org 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: Mon, 13 May 2013 19:19:36 -0000 --089e011775a7a0884704dc9e652a Content-Type: text/plain; charset=ISO-8859-1 Below are my review comments for the I-D:draft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6) Questions/Comments: 1. "Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values." QoS for a session or subscriber or group of sessions? Not clear from this statement. 2. "This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway." So is the objective primarily to enable QoS on the MAG<->LMA path? Or is the intent to deliver QoS information to the MAG for use on the access link? Or both? 3. "Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway." Would this mapping be defined elsewhere? As an example how would you translate the QoS parameters defined between the MAG<->LMA for use on an 802.11 air interface? Who would define this mapping (if it needs to be specified). 4. "Current standardization effort considers strong QoS classification and enforcement for cellular radio access technologies." What standardization effort is being referred to here? 5. "QoS policies are typically controlled by a policy control function, ...." The I-D assumes a very specific network architecture (in this case 3GPP EPS). It would be better to indicate the applicability or assumptions. 6. "Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques." Not sure how this is relevant in the scope of this I-D. 7. "... alternative radio access technologies, such as IEEE802.16 " Would be good to include EV-DO, SCDMA as other technologies as well... 8. " whereas inter-working with the cellular architecture to establish QoS policies in alternative access networks has not been focussed on so far." The WG is better off defining a mechanism that is not specific to the current version of 3GPP standards or access technologies being considered. 9. "...has been identified as promising alternative technology to complement cellular radio access." It already complements cellular access.. Why is it considered promising? 10. " This specification does not depend on the approach how the cellular specific QoS policies have been configured on the LMA. " Is there not a need to have QoS for flows between a MAG and LMA given that an MN may have multiple flows between a MAG<->LMA pair? 11. "The MN is first connected to the LTE network and having a multimedia session such as a video call with appropriate QoS parameters set by the policy control function. " What QoS policies are configured at the MAG/LMA for such a flow by the PCF? And how are these applied? 12. "The MN is first attaching to the Wi-Fi network. During attachment process, the LMA, which may be in communication with Policy Control Function (this step of the process is out of the scope of this document), provides the QoS parameters to the MAG piggy-backing the PMIP signaling (i.e. PBA)." Several assumptions being made here. It could also be the case that when the MN attaches to a WiFI AP which has QoS support, it could request specific QoS already for a session. That is not considered here. 13. Sec 3.5 describes QCI, ARP, AMBR, GBR etc. which are all 3GPP specific for QoS. It is not clear how these are incorporated into the signaling between PMIP6 nodes and how they are mapped/applied. 3GPP has specified all these QoS types. If the PMIP6 elements, MAG/LMA, do not support QoS signaling does it imply that 3GPP networks will be unable to use QoS if PMIP6 is used as the mobility protocol? 14. The I-D specifies various QoS options defined in 3GPP such as AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or deprecate these options. Why not simply follow the 3GPP defined QoS parameters and allocate a generic 3GPP option instead of assigning a type value to each one of these by IANA? 15. The I-D makes assumptions about interacting with a policy controller for obtaining the QoS parameters. What happens in the absence of such a PCF element? Can the LMA itself be configured to allocate QoS to a session? 16. And lastly why not simply specify DSCP and the QoS for the traffic between the MAG and LMA instead of worrying about the mapping to access technology types and interaction with different elements in the access. -Raj --089e011775a7a0884704dc9e652a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Below are my review comments for the I-D:dr= aft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6)

Questions/Comments:

1. "Using = the QoS option, the local mobility anchor and the

=A0 =A0mobile a= ccess gateway can exchange available QoS attributes and

=A0 =A0as= sociated values."

QoS for a session or subscriber or group of sessions? N= ot clear from

this statement.

2. "T= his enables QoS policing and labeling of packets

=A0 =A0to enforc= e QoS differentiation on the path between the local mobility

=A0 =A0anchor and the mobile access gateway."

So is the objective primarily to enable QoS on the MAG<->LMA pa= th? Or

is the intent to deliver QoS information to the MAG for us= e on the

access link? Or both?

3. "Furthermore, m= aking QoS

=A0 =A0parameters available on the MAG enables mapping = these parameters to

=A0 =A0QoS rules being specific to the access= technology which operates

=A0 =A0below the mobile access gateway."

Would this mapping be defined elsewhere? As an example how would you

translate the QoS parameters defined between the MAG<->LMA for u= se on

an 802.11 air interface? Who would define this mapping (if it needs to=

be specified).

4. "Current

=A0 =A0standardization effort considers strong QoS classification and

=A0 =A0enforcement for cellular radio access technologies."

What standardization effort is being referred to here?= =A0

5. "QoS policies are

=A0 =A0typ= ically controlled by a policy control function, ...."

The I-D assumes a very specific network architecture (i= n this case

3GPP EPS). It would be better to indicate the applica= bility or

assumptions.=A0

6. "Polic= y control and QoS differentiation for access to the mobile

=A0 =A0operator network through alternative non-cellular access techno= logies

=A0 =A0is not yet considered, even though some of these ac= cess technologies

=A0 =A0are able to support QoS by appropriate t= raffic prioritization

=A0 =A0techniques."

Not sure how this is= relevant in the scope of this I-D.

7. "... a= lternative

=A0 =A0radio access technologies, such as IEEE802.16 &= quot;

Would be good to include EV-DO, SCDMA as other technolo= gies as well...

8. " whereas inter-working wi= th the cellular

=A0 =A0architecture to establish QoS policies in = alternative access networks

=A0 =A0has not been focussed on so far."

The WG is better off defining a mechanism that is not specific to the

current version of 3GPP standards or access technologies being

<= div> considered.

9. "...has been identified as

=A0 =A0promising alternative technology to complement cellular radio=

=A0 =A0access."

It already complem= ents cellular access.. Why is it considered

promising?

10. " This specification

=A0 =A0does not depend on the approach how the cellular specific QoS<= /div>

=A0 =A0policies have been configured on the LMA. "

Is there not a need to have QoS for flows between a MAG and LMA = given

that an MN may have multiple flows between a MAG<->LM= A pair?

11. "The MN is first connected to the= LTE network and having a multimedia

=A0 =A0session such as a video call with appropriate QoS parameters se= t by

=A0 =A0the policy control function. "

What QoS policies are configured at the MAG/LMA for such a flow by = the

PCF? And how are these applied?

12. "The= MN is first attaching to

=A0 =A0the Wi-Fi network. =A0During att= achment process, the LMA, which may be

=A0 =A0in communication wi= th Policy Control Function (this step of the

=A0 =A0process is out of the scope of this document), provides the QoS=

=A0 =A0parameters to the MAG piggy-backing the PMIP signaling (i= .e.

=A0 =A0PBA)."

Several assumptio= ns being made here. It could also be the case that

when the MN attaches to a WiFI AP which has QoS support, it could

request specific QoS already for a session. That is not considered

here.

13. Sec 3.5 describes QCI, ARP, AMBR= , GBR etc. which are all 3GPP

specific for QoS. It is not clear how these are incorporated into the<= /div>

signaling between PMIP6 nodes and how they are mapped/applied.

3GPP has specified all these QoS types. If the PMIP6= elements,

MAG/LMA, do not support QoS signaling does it imply that 3GPP networks=

will be unable to use QoS if PMIP6 is used as the mobility proto= col?

14. The I-D specifies various QoS options def= ined in 3GPP such as

AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or

<= div>deprecate these options. Why not simply follow the 3GPP defined QoS

parameters and allocate a generic 3GPP option instead of assigning a=

type value to each one of these by IANA?

15. = The I-D makes assumptions about interacting with a policy

control= ler for obtaining the QoS parameters. What happens in the

absence= of such a PCF element? Can the LMA itself be configured to

allocate QoS to a session?

16. And lastly why= not simply specify DSCP and the QoS for the traffic

between the = MAG and LMA instead of worrying about the mapping to

access techn= ology types and interaction with different elements in the

access.

-Raj

--089e011775a7a0884704dc9e652a-- From bpatil1@gmail.com Tue May 14 14:37:01 2013 Return-Path: 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 BA2EE21F8B18 for ; Tue, 14 May 2013 14:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 bX8AADRkDZEH for ; Tue, 14 May 2013 14:37:01 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2597E21F85C7 for ; Tue, 14 May 2013 14:37:00 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so1197507obc.12 for ; Tue, 14 May 2013 14:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=Y/qy/+B2RChMVU/9bn/8Ahf3RZdvH7PhnM1ZLqyp0Os=; b=Rj0qPH5FIwm52AXG24Rsl7fakiJRf55aP2J1mL2Angk5QrRTe/2P1epHKbq6sKyFQl JoxBtYbfHZkgvzD/sAhFwfRfS/xF8DOSQr4CyUbyyPySvyxRdee3Ec3Vve4OkGN9g4iq AeRCwKjh7E1JHjxGTTt/h0fu2EQFlZo5wPQ6mLMpm7sMCbNFjbGnRc2WVb5Hww/r+zT2 QWlxZN6ZGncpoUvsQrBqtwzFfZ9Z6Be2M9Di6cwy0/8TrmMfcuFG5OXNkTHJHdYIWlGR Gk0RYvYq7s1ueaB1DnHCpVkqN3swLNhYADAi4whYxHjNAacqROl94MjFtmXQUSgPzele nHfA== MIME-Version: 1.0 X-Received: by 10.60.33.202 with SMTP id t10mr6370736oei.2.1368567419645; Tue, 14 May 2013 14:36:59 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Tue, 14 May 2013 14:36:59 -0700 (PDT) Date: Tue, 14 May 2013 16:36:59 -0500 Message-ID: From: Basavaraj Patil To: Ahmad Muhanna Content-Type: multipart/alternative; boundary=089e013c66b4e63c7104dcb46eff Cc: "netext@ietf.org" Subject: [netext] Request for review of I-D: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org 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, 14 May 2013 21:37:01 -0000 --089e013c66b4e63c7104dcb46eff Content-Type: text/plain; charset=ISO-8859-1 Hi Ahmad, We would appreciate it if you can review the I-D: uality of Service Option for Proxy Mobile IPv6 . Please post your review comments directly to the list. If you can complete the review within the next 2 weeks, that would be much appreciated. Thank you. -Chairs -- Basavaraj Patil --089e013c66b4e63c7104dcb46eff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Ahmad,

We would appre= ciate it if you can review the I-D:=A0uality of Service Option for Proxy Mobile IPv6= <draft-ietf-netext-pmip6-qos-02.txt>.

Please post your review comments directly to the list. If you can= complete the review within the next 2 weeks, that would be much appreciate= d.

Thank you.

-Chairs

--
Basavaraj Patil

--089e013c66b4e63c7104dcb46eff-- From bpatil1@gmail.com Tue May 14 14:45:35 2013 Return-Path: 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 40D6F21F8E84 for ; Tue, 14 May 2013 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 r2zH1ZAF-lrm for ; Tue, 14 May 2013 14:45:30 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id DEA1021F8E49 for ; Tue, 14 May 2013 14:45:29 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id o6so1324107oag.2 for ; Tue, 14 May 2013 14:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cQAgLjvS2temQWtbenCgI5xj/DYyr9tkMOyxMjYJsgs=; b=AEt0lLiHaZpwxc93yRImKMeUOzfJ8Rwm+JqZDaQTwApcgbPvH0xx22sepGs/ROj6t1 FAR9Tbep/N8bGU/aeA0mTz2VjXhPyEzCF3d9jpGoSY+laTbyFwWpGXXdQZeGn0pww5xY rMFHCIDFKqQGFngDuV8KNiWpSUIJ8C/kI6Ul01M5Z51qBf5iaq1Sllb60Lpy/lrPn9h/ Fa8V7XtPeJofpEtOYxYLMNc8UIG4jZvVChGPiNcH+XktIwe17Nk3ErhrU4bbJBwo9A5Y VTPkPyxccDFYpsv3Je0aK7Y9U8YwUMNYJJRfE3RAPYgL3A69GNsjFzGTpEaASSVwiimu yv4Q== MIME-Version: 1.0 X-Received: by 10.182.40.202 with SMTP id z10mr15631310obk.74.1368567929415; Tue, 14 May 2013 14:45:29 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Tue, 14 May 2013 14:45:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 May 2013 16:45:29 -0500 Message-ID: From: Basavaraj Patil To: sdas@appcomsci.com Content-Type: multipart/alternative; boundary=001a11c32db648af0f04dcb48d65 Cc: "netext@ietf.org" Subject: [netext] Fwd: Request for review of I-D: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org 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, 14 May 2013 21:45:35 -0000 --001a11c32db648af0f04dcb48d65 Content-Type: text/plain; charset=ISO-8859-1 Hi Subir, We would appreciate it if you can review the I-D: Quality of Service Option for Proxy Mobile IPv6 . Please post your review comments directly to the list. If you can complete the review within the next 2 weeks, that would be much appreciated. Thank you. -Chairs -- Basavaraj Patil -- Basavaraj Patil --001a11c32db648af0f04dcb48d65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Subir,

We would appreciate it if= you can review the I-D: Q= uality of Service Option for Proxy Mobile IPv6 <draft-ietf-netext-pmip6-qos-02.txt>.

Please post your review comments directly to the list. If you can= complete the review within the next 2 weeks, that would be much appreciate= d.

Thank you.

-Chairs

--
Basavaraj Patil

--001a11c32db648af0f04dcb48d65-- From bpatil1@gmail.com Tue May 14 14:54:37 2013 Return-Path: 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 4A2BE21F8FED for ; Tue, 14 May 2013 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 EW322hp2UleF for ; Tue, 14 May 2013 14:54:36 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE0221F8F43 for ; Tue, 14 May 2013 14:54:36 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id ef5so1203526obb.16 for ; Tue, 14 May 2013 14:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=w/31+u3r1qJIhyohmzDfLIQbVXR1y2eyru/CuNIfTtA=; b=L3ClN5FAWt84p3/x+FUEz0W20dLF+Cx7xGcJRAavtFGlP/5NQWdZ3MwPRFUBOPUz+m 0U92ChZi2BVFnsO5yOFBSgyP59vv58a2/dK7Zgut2pJzAGXc4QPFgFdkO0n1+NSWn8gF AIn+xq++KMrXE5X4kjG3FWbLOrj+zSc4nvLLxv+2iJjfludp99/+g0imZMpzX2zI0fae /SgtexdSVP30ZkSYFO/UvKvJQBMcD1ScwZM6VjuTWgAlwDH3n0nul5HC/Bhp16b3uhXz FfB8emAHoBBJeeHH9JqHkWijns9sXRqSgfzkpCogcW5Dmy+fgwF/6mkyifoZwkMo2eRV gFhQ== MIME-Version: 1.0 X-Received: by 10.182.33.40 with SMTP id o8mr15484902obi.39.1368568475427; Tue, 14 May 2013 14:54:35 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Tue, 14 May 2013 14:54:35 -0700 (PDT) Date: Tue, 14 May 2013 16:54:35 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e01161b5cd427e804dcb4ad01 Subject: [netext] Review of I-D: QoS for PMIPv6 X-BeenThere: netext@ietf.org 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, 14 May 2013 21:54:37 -0000 --089e01161b5cd427e804dcb4ad01 Content-Type: text/plain; charset=ISO-8859-1 Also Charlie Perkins has agreed to review the I-D: Quality of Service Option for Proxy Mobile IPv6 . Thanks Charlie. -- Basavaraj Patil --089e01161b5cd427e804dcb4ad01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Also Charlie Perkins has agreed to review t= he I-D:=A0=A0Q<= /span>uality of Service Option for Proxy Mobile IPv6 <draft= -ietf-netext-pmip6-qos-02.txt>.

Thanks Charlie.

--
= Basavaraj Patil

--089e01161b5cd427e804dcb4ad01-- From internet-drafts@ietf.org Thu May 16 16:44:54 2013 Return-Path: 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 4123D11E8110; Thu, 16 May 2013 16:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 OOfohS9VDeLf; Thu, 16 May 2013 16:44:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D528211E80CC; Thu, 16 May 2013 16:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130516234453.8739.38652.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 16:44:53 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-07.txt X-BeenThere: netext@ietf.org 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: Thu, 16 May 2013 23:44:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-07.txt Pages : 24 Date : 2013-05-16 Abstract: Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies extensions to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From suresh.krishnan@ericsson.com Thu May 16 21:29:12 2013 Return-Path: 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 233D221F8A6B for ; Thu, 16 May 2013 21:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 0yjfym-mY865 for ; Thu, 16 May 2013 21:29:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2721F89FD for ; Thu, 16 May 2013 21:29:05 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-cc-5195b21057a1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DA.93.06724.012B5915; Fri, 17 May 2013 06:29:04 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 17 May 2013 00:29:04 -0400 From: Suresh Krishnan To: Basavaraj Patil Thread-Topic: [netext] Review of I-D: draft-ietf-netext-update-notifications-03 Thread-Index: AQHOTDYVRUI6Mx8dXEmv1CB+aWXd+5kI1bMG Date: Fri, 17 May 2013 04:29:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_lgaqln5hv9ey0vyp4c48dvjx1368764941954emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPn67ApqmBBpNPW1nM2T6BxeLaz6fs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG2sPrmQoOWFY8XjKJvYHxgn4XIyeHhICJ xLbbzSwQtpjEhXvr2boYuTiEBI4yStx78okdwlnOKLG44xUrSBUbUMeGnZ+ZQGwRAXWJIzv2 s4PYzED2rflnwSYJCwRIHHp8lxGiJlBi54rpLBC2kcSTqdPA6lkEVCWmzzzJDGLzCrhJ7N61 BqxGCKj35rULQL0cHJxAvVdbpEDCjEDHfT+1hglilbjErSfzmSCOFpBYsuc8M4QtKvHy8T9W iJociYenD7JDjBeUODnzCcsERpFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dY kMUXMLKvYuQoLU4ty003MtzECIyeYxJsjjsYF3yyPMQozcGiJM7brT01UEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjrdv0Zxrlx1zY7OdvSghfcebWhYl3ej4f5Dq94KOGzin2QFEFEft/ L2OPtM7n25Kz+/b22FVft5osln726eGkRQEKZ1tiXf5E9JySe62UabTWyWHK6edreLy2fksM cFCRdd75wfhleEJ51j7OnV9c+rT/a1xKuaQiM8Hq/OFXHXq1vIJst6ZGKLEUZyQaajEXFScC AEkg85ZsAgAA Cc: "netext@ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-03 X-BeenThere: netext@ietf.org 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: Fri, 17 May 2013 04:29:12 -0000 --_000_lgaqln5hv9ey0vyp4c48dvjx1368764941954emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Raj, Thanks for your detailed review. We have submitted a new version of the dra= ft to address your comments. Specifically we have added a new configuration= value for limiting the number of retransmissions and fixed all the editori= al issues. I did not understand the issue about the vendor specific reason. We require= IANA registration of all reasons with the policy "specification required".= Did you want us to change this? Once we agree on a resolution to this issu= e, the draft will be ready for WGLC. Thanks Suresh ----- Original Message ----- From: Basavaraj Patil To: "netext@ietf.org" Sent: 5/8/2013 5:50 PM Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-03 My review of this I-D. -Raj Comments: --------- In order to ensure interoperability, the I-D should state that if an LMA sends an Update notification to a MAG and does not receive an Ack, then the MAG may not support the ability to update sessions. The I-D should specify a backoff mechanism in terms of retransmitting an update message from the LMA and stop after X number of messages with no response. The update notification message could be abused by the introduction of a vendor specific notification reason. The specification should mandate the registration of all notification reasons in IANA and not allow any vendor specific types. Editorial: s/ These update notifications are exchanged using a Mobility Header message type specifically designed for this purpose./These update notifications are exchanged using a new Mobility Header message type specifically designed for this purpose. Comment: The Introduction starts off as : "In some situations, there is a need for the local mobility anchor ..." This is pretty ambiguous. Please rephrase. s/The base Proxy Mobile IPv6 specification does not have a provision for this./ The base Proxy Mobile IPv6 specification does not have a provision for sending unsolicited informational messages from the LMA to the MAG. s/participation from the mobile node/participation by the mobile node s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as specified in Mobile IPv6 [RFC6275] Q: ID states: "One such scenario where such a mechanism is needed is when the local mobility anchor wants to inform the mobile access gateway that it needs to re-register mobility session for a mobile node." In what scenario would the LMA want to inform the MAG that an MN needs to be re-registered? s/and so it can obtain the updated policy/in order to update the policies associated with the mobility session of an MN. s/or and updated IPv4/or an updated IPv4 -- Basavaraj Patil --_000_lgaqln5hv9ey0vyp4c48dvjx1368764941954emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Raj, =0A=
Thanks for your detailed review. We have submitted a new version of the dra=
ft to address your comments. Specifically we have added a new configuration=
 value for limiting the number of retransmissions and fixed all the editori=
al issues. =0A=
=0A=
I did not understand the issue about the vendor specific reason. We require=
 IANA registration of all reasons with the policy "specification requi=
red". Did you want us to change this? Once we agree on a resolution to=
 this issue, the draft will be ready for WGLC. =0A=
=0A=
Thanks=0A=
Suresh =0A=
=0A=
=0A=
----- Original Message -----=0A=
From: Basavaraj Patil <bpatil1@gmail.com>=0A=
To: "netext@ietf.org" <netext@ietf.org>=0A=
Sent: 5/8/2013 5:50 PM=0A=
Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-03=
=0A=
=0A=
=0A=

My review of this I-D.

-Raj

Comments:

---------

In order to ensure interoperability, the I-D should state that if an

LMA sends an Update notification to a MAG and does not receive an Ack,=

then the MAG may not support the ability to update sessions.

The I-D should specify a backoff mechanism in terms of retransmitting<= /div>

an update message from the LMA and stop after X number of messages

with no response.

The update notification message could be abused by the introduction of=

a vendor specific notification reason. The specification should

mandate the registration of all notification reasons in IANA and not

allow any vendor specific types.

Editorial:

s/ These update notifications are exchanged using a Mobility

Header message type specifically designed for this purpos= e./These

update notifications are exchanged using a new Mobility&n= bsp;

Header message type specifically designed for this purpos= e.

Comment:

The Introduction starts off as : "In some situations, there is a = need

for the local mobility anchor ..."

This is pretty ambiguous. Please rephrase.

s/The base Proxy

Mobile IPv6 specification does not have a provision for t= his./ The

base Proxy Mobile IPv6 specification does not have a prov= ision for

sending unsolicited informational messages from the LMA t= o the

MAG.

s/participation from the mobile node/participation by the mobile node&= nbsp;

s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as<= /div>

specified in Mobile IPv6 [RFC6275]

Q: ID states:

"One such scenario where such a mechanism is needed is when the l= ocal

mobility anchor wants to inform the mobile access gateway= that it

needs to re-register mobility session for a mobile node.&= quot;

In what scenario would the LMA want to inform the MAG that an MN needs=

to be re-registered?

s/and so it can obtain the updated policy/in order to update the

policies associated with the mobility session of an MN.

s/or and updated IPv4/or an updated IPv4

--
Basavaraj Patil

--_000_lgaqln5hv9ey0vyp4c48dvjx1368764941954emailandroidcom_-- From bpatil1@gmail.com Fri May 17 09:44:24 2013 Return-Path: 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 0F19921F9729 for ; Fri, 17 May 2013 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Vsp+PukZQQyq for ; Fri, 17 May 2013 09:44:19 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3227121F9733 for ; Fri, 17 May 2013 09:44:18 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so5484965oag.34 for ; Fri, 17 May 2013 09:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ysgl3PMtINVzltiqnqWcDZzV9K4ueWqifCBXKAfBDeo=; b=swflPQ1K8h7MKmA/utEbJNE2tBI6QDA0wAOXmm9DLayDVmZrc03mhwQfm97gXNPe8c CrHDyoAJA1tk5ipM8npHFZ6vQh4xZMbZ4WPYb9PQTfCavNW1gcqj7ftYyEywlrIy/pbJ x7XSpIlyqL3fwn3eWpam8dyYQUgZSLaT0aa1WqkRM9qkWkRDuHFB8ncfRKAb3epk47d2 qBV3P9qCBOQQ4nOrVfR5z1j/nbosg7DcYFR+iCfyxfgruJjOdcWUjfvbw34I7fFxToHz R1zp+0979nndlRYGfbOfGaVLHTQM+IEBQp4raAda9xrZukYQ8VlQPO7rkdogcAas2D6C v/sA== MIME-Version: 1.0 X-Received: by 10.182.237.77 with SMTP id va13mr22250268obc.65.1368809057761; Fri, 17 May 2013 09:44:17 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Fri, 17 May 2013 09:44:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 May 2013 11:44:17 -0500 Message-ID: From: Basavaraj Patil To: Suresh Krishnan Content-Type: multipart/alternative; boundary=e89a8ff1cdcca7910d04dcecb14f Cc: "netext@ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-03 X-BeenThere: netext@ietf.org 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: Fri, 17 May 2013 16:44:24 -0000 --e89a8ff1cdcca7910d04dcecb14f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Suresh, I just wanted to make sure that we are requiring IANA registration for all reasons that get specified subsequently. Since that is required and clearly mentioned in the IANA considerations section of the I-D I am fine with it. Will go ahead and submit a WG LC request. -Raj On Thu, May 16, 2013 at 11:29 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Raj, > Thanks for your detailed review. We have submitted a new version of the d= raft to address your comments. Specifically we have added a new configurati= on value for limiting the number of retransmissions and fixed all the edito= rial issues. > > I did not understand the issue about the vendor specific reason. We requi= re IANA registration of all reasons with the policy "specification required= ". Did you want us to change this? Once we agree on a resolution to this is= sue, the draft will be ready for WGLC. > > Thanks > Suresh > > > ----- Original Message ----- > From: Basavaraj Patil > To: "netext@ietf.org" > Sent: 5/8/2013 5:50 PM > Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-0= 3 > > > > > My review of this I-D. > > -Raj > > Comments: > --------- > > In order to ensure interoperability, the I-D should state that if an > LMA sends an Update notification to a MAG and does not receive an Ack, > then the MAG may not support the ability to update sessions. > The I-D should specify a backoff mechanism in terms of retransmitting > an update message from the LMA and stop after X number of messages > with no response. > > The update notification message could be abused by the introduction of > a vendor specific notification reason. The specification should > mandate the registration of all notification reasons in IANA and not > allow any vendor specific types. > > > > Editorial: > > s/ These update notifications are exchanged using a Mobility > Header message type specifically designed for this purpose./These > update notifications are exchanged using a new Mobility > Header message type specifically designed for this purpose. > > Comment: > > The Introduction starts off as : "In some situations, there is a need > for the local mobility anchor ..." > This is pretty ambiguous. Please rephrase. > > s/The base Proxy > Mobile IPv6 specification does not have a provision for this./ The > base Proxy Mobile IPv6 specification does not have a provision for > sending unsolicited informational messages from the LMA to the > MAG. > > s/participation from the mobile node/participation by the mobile node > > s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as > specified in Mobile IPv6 [RFC6275] > > Q: ID states: > "One such scenario where such a mechanism is needed is when the local > mobility anchor wants to inform the mobile access gateway that it > needs to re-register mobility session for a mobile node." > > In what scenario would the LMA want to inform the MAG that an MN needs > to be re-registered? > > s/and so it can obtain the updated policy/in order to update the > policies associated with the mobility session of an MN. > > s/or and updated IPv4/or an updated IPv4 > > > -- > Basavaraj Patil > --=20 Basavaraj Patil --e89a8ff1cdcca7910d04dcecb14f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Suresh,

I just wanted to make sure that we are requiring IANA registration for= all reasons that get specified subsequently. Since that is required and cl= early mentioned in the IANA considerations section of the I-D I am fine wit= h it.=A0

Will go ahead and submit a WG LC request.

-Raj

On Thu, May 16, 2013 at 11:29 PM, Su= resh Krishnan <suresh.krishnan@ericsson.com> wrot= e:

Hi =
Raj,=20
Thanks for your detailed review. We have submitted a new version of the dra=
ft to address your comments. Specifically we have added a new configuration=
 value for limiting the number of retransmissions and fixed all the editori=
al issues.=20

I did not understand the issue about the vendor specific reason. We require=
 IANA registration of all reasons with the policy "specification requi=
red". Did you want us to change this? Once we agree on a resolution to=
 this issue, the draft will be ready for WGLC.=20

Thanks
Suresh=20


----- Original Message -----
From: Basavaraj Patil <bpatil1@gmail.com>
To: "netext@ietf.=
org" <nete=
xt@ietf.org>
Sent: 5/8/2013 5:50 PM
Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-03
My review of this I-D.

-Raj

Comments:

---------

In order to ensure interoperability, the I-D should state that if an
LMA sends an Update notification to a MAG and does not receive an Ack,=

then the MAG may not support the ability to update sessions.=A0

The I-D should specify a backoff mechanism in terms of retransmitting<= /div>
an update message from the LMA and stop after X number of messages
with no response.=A0

The update notification message could be abused by the introduction of=

a vendor specific notification reason. The specification should

mandate the registration of all notification reasons in IANA and not
allow any vendor specific types.

Editorial:

s/ These update notifications are exchanged using a Mobility

=A0 =A0Header message type specifically designed for this purpose./The= se

=A0 =A0update notifications are exchanged using a new Mobility=A0
=A0 =A0Header message type specifically designed for this purpose.

Comment:

The Introduction starts off as : "In some situations, there is a = need

for the local mobility anchor ..."=A0

This is pretty ambiguous. Please rephrase.

s/The base Proxy

=A0 =A0Mobile IPv6 specification does not have a provision for this./ = The

=A0 =A0base Proxy Mobile IPv6 specification does not have a provision = for

=A0 =A0sending unsolicited informational messages from the LMA to the<= /div>
=A0 =A0MAG.=A0

s/participation from the mobile node/participation by the mobile node= =A0

s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as<= /div>
specified in Mobile IPv6 [RFC6275]

Q: ID states:

"One such scenario where such a mechanism is needed is when the l= ocal

=A0 =A0mobility anchor wants to inform the mobile access gateway that = it

=A0 =A0needs to re-register mobility session for a mobile node."<= /div>

In what scenario would the LMA want to inform the MAG that an MN needs=

to be re-registered?

s/and so it can obtain the updated policy/in order to update the

policies associated with the mobility session of an MN.

s/or and updated IPv4/or an updated IPv4

--
Basavaraj Patil

--
Basavaraj Pa= til

--e89a8ff1cdcca7910d04dcecb14f-- From bpatil1@gmail.com Fri May 17 09:49:17 2013 Return-Path: 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 3561B21F965C for ; Fri, 17 May 2013 09:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 KNXEptDVeabV for ; Fri, 17 May 2013 09:49:16 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9243221F9616 for ; Fri, 17 May 2013 09:49:16 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so4854429obc.40 for ; Fri, 17 May 2013 09:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wnvVTjd5XbA2AOHD28LfslVBigmIlqmWrtHoC492Ggo=; b=XniN4h73xA7KPtGIbaTuUhOMA9ZOcCG1nlLU2s2Vu226eubHvlqgR0mRYqIpxhet6V vD2U5NsFzxt0HTNPydo8ilP2Jcy3HppVhGz6v0vcKhQihjaZh5t1pHyJVlcAgESawPvA JyaObWIR+UWSrrZvbyQVyj/DDJTzmLbRNuZiVNEfcbYJSqH2ZEiMu/l9pLrxCpTSIWco MtNMZxwkyKeOm/vQ7xrZ4o5KT1b3VMwmu1E4vXSk9wMhsk3xKefhLFplZj3wd1gntk7i 2nT5OBt7iKWANVyv6Hj74artbW8q80qy0eVlhl8TdhFF1PC0u4UfZktxtoX21CJIirvX xAzg== MIME-Version: 1.0 X-Received: by 10.60.34.135 with SMTP id z7mr24192846oei.68.1368809356109; Fri, 17 May 2013 09:49:16 -0700 (PDT) Received: by 10.76.180.165 with HTTP; Fri, 17 May 2013 09:49:16 -0700 (PDT) Date: Fri, 17 May 2013 11:49:16 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e0122acb46faef104dcecc350 Subject: [netext] WGLC: I-D draft-ietf-netext-update-notifications X-BeenThere: netext@ietf.org 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: Fri, 17 May 2013 16:49:17 -0000 --089e0122acb46faef104dcecc350 Content-Type: text/plain; charset=ISO-8859-1 The Netext working group I-D: Update Notifications for Proxy Mobile IPv6 has been revised following the chair review. This note is the start of the working group last call for the Update Notifications for PMIPv6 I-D. Please review and post your comments to the list. The working group last call will end on June 1st, 2013. I-D URL: http://www.ietf.org/id/draft-ietf-netext-update-notifications-04.txt -Chairs --089e0122acb46faef104dcecc350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The Netext working group I-D: Update N= otifications for Proxy Mobile

IPv6 <draft-ietf-netext-update-n= otifications-04> has been revised

following the chair review.= =A0

This note is the start of the working group last call f= or the Update

Notifications for PMIPv6 I-D. Please review and pos= t your comments to

the list.

The working= group last call will end on June 1st, 2013.=A0

I-D URL:

http://www.ietf.org/id/draft-i= etf-netext-update-notifications-04.txt

-Chairs=

--089e0122acb46faef104dcecc350-- From internet-drafts@ietf.org Sun May 19 23:34:57 2013 Return-Path: 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 8E09721F8FFA; Sun, 19 May 2013 23:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 pWWPNlO9Frby; Sun, 19 May 2013 23:34:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C675F21F8FE5; Sun, 19 May 2013 23:34:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130520063456.15932.16932.idtracker@ietfa.amsl.com> Date: Sun, 19 May 2013 23:34:56 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-08.txt X-BeenThere: netext@ietf.org 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: Mon, 20 May 2013 06:34:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-08.txt Pages : 26 Date : 2013-05-19 Abstract: This specification defines extensions to Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain delegated IP prefixes for its attached mobile networks. The mobility entities in the network will provide network-based mobility management support for those delegated IP prefixes just as how IP mobility support is provided for the mobile node's home address. Even as the mobile router performs an handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhou.xingyue@zte.com.cn Mon May 20 02:39:44 2013 Return-Path: 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 5235421F8EA6; Mon, 20 May 2013 02:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.795 X-Spam-Level: X-Spam-Status: No, score=-95.795 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] 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 X1tJjiRVbg1L; Mon, 20 May 2013 02:39:40 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20F21F8D94; Mon, 20 May 2013 02:39:39 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id BB9B9B18AC; Mon, 20 May 2013 17:39:04 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 4397A71C78C; Mon, 20 May 2013 17:39:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r4K9cvlc070581; Mon, 20 May 2013 17:38:57 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: Basavaraj Patil MIME-Version: 1.0 X-KeepSent: 0B4B4ADC:0FE7B8A3-48257B71:0032E28E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Mon, 20 May 2013 17:38:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-05-20 17:38:57, Serialize complete at 2013-05-20 17:38:57 Content-Type: multipart/alternative; boundary="=_alternative 0035066648257B71_=" X-MAIL: mse01.zte.com.cn r4K9cvlc070581 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" , netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Mon, 20 May 2013 09:39:44 -0000 This is a multipart message in MIME format. --=_alternative 0035066648257B71_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8gUmFqLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpBIG5ldyB2ZXJzaW9uICgt MDgpIG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0ZWQuIFlvdXIgY29tbWVudHMgYmVsb3cg DQphcmUgYWRkcmVzc2VkIGluIHRoaXMgdmVyc2lvbi4NCg0KVGhlIGRyYWZ0IGlzIHJlYWR5IGZv ciBXR0xDIG5vdy4gVGhhbmtzLg0KDQoNCkJlc3QgUmVnYXJkcywNCkpveQ0KDQoNCg0KQmFzYXZh cmFqIFBhdGlsIDxicGF0aWwxQGdtYWlsLmNvbT4gDQq3orz+yMs6ICBuZXRleHQtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMy0wNC0wNCAwMTo1OQ0KDQrK1bz+yMsNCiJuZXRleHRAaWV0Zi5vcmciIDxu ZXRleHRAaWV0Zi5vcmc+DQqzrcvNDQoiZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcEB0b29scy5p ZXRmLm9yZyIgDQo8ZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcEB0b29scy5pZXRmLm9yZz4NCtb3 zOINCltuZXRleHRdIFJldmlldyBvZiBJLUQ6IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXA2LTA2 DQoNCg0KDQoNCg0KDQoNCg0KUXVlc3Rpb25zOg0KDQoxLiBJbiB0aGUgdGVybWlub2xvZ3kgc2Vj dGlvbjoNCiAgICJUaGUgRE1OUCBpcyBhbiBJUHY0IG9yIGFuIElQdjYgcHJlZml4IGRlbGVnYXRl ZCB0byBhIG1vYmlsZSByb3V0ZXINCiAgICAgIGFuZCBhZHZlcnRpc2VkIGluIHRoZSBtb2JpbGUg bmV0d29yay4iDQoNCiAgICAgIFdoYXQgaXMgdGhlIG1vYmlsZSBuZXR3b3JrIGJlaW5nIHJlZmVy ZWQgdG8gaW4gdGhpcyBzdGF0ZW1lbnQ/DQogICAgICBJcyBpdCB0aGUgUE1JUDYgZG9tYWluIGl0 c2VsZj8gT3IgaXMgaXQgdGhlIG5ldHdvcmsgdGhhdCB0aGUNCiAgICAgIG1vYmlsZSByb3V0ZXIg aXMgaG9zdGluZz8NCg0KMi4gSW4gU2VjIDQuMy4xOg0KICAgIkl0IGlzIHBvc3NpYmxlIHRoYXQg dGhlIGRlbGVnYXRlZCBwcmVmaXgoZXMpIG1heQ0KICAgICAgIGhhdmUgYmVlbiBhc3NpZ25lZCB0 byB0aGUgTUFHIGJ5IHRoZSBMTUEgZHVyaW5nIHRoaXMgcHJvY2VkdXJlIG9mDQogICAgICAgUE1J UHY2IHR1bm5lbCBlc3RhYmxpc2htZW50LiAgVGhhdCBpcyB0aGUgTUFHIG1heSBpbmNsdWRlIG9u ZSAob3INCiAgICAgICBtb3JlKSBEZWxlZ2F0ZWQgTW9iaWxlIE5ldHdvcmsgUHJlZml4IChETU5Q KSBtb2JpbGl0eSBvcHRpb25zDQogICAgICAgd2hpY2ggTVVTVCBiZSBzZXQgdG8gdGhlIHVuc3Bl Y2lmaWVkIElQdjYgYWRkcmVzcyAiOjoiIGluIHRoZSBQQlUNCiAgICAgICB0byByZXF1ZXN0IHRo ZSBkZWxlZ2F0ZWQgcHJlZml4KGVzKS4gIFRoZSBMTUEgYXNzaWducyBhIG5ldyBzZXQNCiAgICAg ICBvZiBETU5QKHMpIGluIFBCQSBtZXNzYWdlLiINCg0KICAgICAgIE5vdCBzdXJlIHdoYXQgeW91 ciBhc3N1bXB0aW9ucyBhcmUgaGVyZS4gV2h5IGRvZXMgdGhlIExNQQ0KICAgICAgIGFzc2lnbiBk ZWxlZ2F0ZWQgcHJlZml4KGVzKSBkdXJpbmcgbm9ybWFsIFJGQzUyMTMgUE1JUDYgdHVubmVsDQog ICAgICAgZXN0YWJsaXNobWVudCBwcm9jZWR1cmVzPw0KICAgICAgIFdoYXQgd291bGQgY2F1c2Ug dGhlIE1BRyB0byBpbmNsdWRlIHRoZSBETU5QIG9wdGlvbiBpbiB0aGUgUEJVDQogICAgICAgYXQg dGhpcyBzdGFnZSAoU3RlcCAyKSBvZiB0aGUgc2Vzc2lvbj8NCg0KMy4gSW4gU2VjIDQuMy4xOg0K ICAgIiBUaGUgbW9iaWxlIHJvdXRlciwgYWN0aW5nIGFzIGEgIlJlcXVlc3RpbmcgUm91dGVyIiBh cyBkZXNjcmliZWQNCiAgICAgICBpbiBbUkZDMzYzM10sIHNlbmRzIGEgREhDUHY2IFNPTElDSVQg bWVzc2FnZSBpbmNsdWRpbmcgb25lIG9yDQogICAgICAgbW9yZSBJQV9QRCBvcHRpb24ocykgdG8g dGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSAod2hpY2ggaGFzIGENCiAgICAgICAiREhDUHY2IFNl cnZlciIgZnVuY3Rpb24pIHRvIGFjcXVpcmUgdGhlIGRlbGVnYXRlZCBwcmVmaXgoZXMpLiINCg0K ICAgICAgIElzIHRoZXJlIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUgTUFHIGlzIGFsc28gdGhlIERI Q1B2NiBzZXJ2ZXI/DQogICAgICAgVGhlIE1BRyBjb3VsZCBiZSBhIERIQ1AgcmVsYXkgYXMgd2Vs bCwgcmlnaHQ/DQoNCjQuIEluIFNlYyA0LjMuMSwgc3RlcCA1Og0KICAgIlRoZSBMTUEgbXVzdCBz ZXQNCiAgICAgICB1cCBmb3J3YXJkaW5nIGZvciB0aGUgZGVsZWdhdGVkIHByZWZpeGVzIGFzIHJl YWNoYWJsZSB0aHJvdWdoIHRoZQ0KICAgICAgIFBNSVB2NiB0dW5uZWwuIg0KDQogICAgICAgVGhl IExNQSBtYXkgb3IgbWF5IG5vdCBhc3NpZ24gdGhlc2UgZGVsZWdhdGVkIHByZWZpeGVzLiBUaGUg TUFHDQogICAgICAgY291bGQgYmUgdGhlIG9uZSBhc3NpZ25pbmcgdGhlIGRlbGVnYXRlZCBwcmVm aXhlcyBhcyBwZXIgdGhlDQogICAgICAgZGVzY3JpcHRpb24uIEFyZSB0aG9zZSBwcmVmaXhlcyBy b3V0YWJsZSBieSB0aGUgTE1BPw0KDQo1LiBJbiBTZWMgNC40LjEsIHN0ZXAgNDoNCiAgICJJZiB0 aGUgbW9iaWxlIGFjY2Vzcw0KICAgICAgICBnYXRld2F5IGRvZXMgbm90IGtub3cgdGhlIGRlbGVn YXRlZCBwcmVmaXgoZXMpLCB0aGVuIHRoZQ0KICAgICAgICBkZWxlZ2F0ZWQgbW9iaWxlIG5ldHdv cmsgcHJlZml4IGluIHRoZSBETU5QIG9wdGlvbihzKSBNVVNUIGJlDQogICAgICAgIHNldCB0byB0 aGUgdW5zcGVjaWZpZWQgSVB2NiBhZGRyZXNzICI6OiIsICINCg0KSG93IHdvdWxkIHRoZSBNQUcg a25vdyB0aGUgZGVsZWdhdGVkIHByZWZpeChlcyk/IFVubGVzcyBpdCBpcw0KanVzdCByZW5ld2lu ZyB0aGUgYXNzaWduZWQgcHJlZml4KGVzKT8NCg0KNi4gSXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUgREhDUCBzZXJ2ZXIgZnVuY3Rpb25hbGl0eSByZXNpZGVzIGVpdGhlcg0KICAgYXQgdGhlIE1B RyBvciB0aGUgTE1BIGluIHRoaXMgSS1EPw0KDQo3LiBJbiBTZWMgNi4yIHlvdSBzdGF0ZToNCiAg ICJJbiBvcmRlciB0byByZWNlaXZlIHRoZXNlIHBhY2tldHMsIHRoZQ0KICAgICAgbG9jYWwgbW9i aWxpdHkgYW5jaG9yIE1VU1QgYmUgdGhlIHRvcG9sb2dpY2FsIGFuY2hvciBvZiB0aGUgTVIncw0K ICAgICAgZGVsZWdhdGVkIG1vYmlsZSBuZXR3b3JrIHByZWZpeChlcykuIg0KDQogICAgICBUaGlz IHNob3VsZCBiZSBtYWRlIGNsZWFyIHVwIGZyb250IGluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lv bg0KICAgICAgYWJvdXQgaG93IGZvcndhcmRpbmcgaXMgYWNjb21wbGlzaGVkLg0KDQoNCg0KRWRp dG9yaWFsOg0KDQpzL1Byb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9yIGEg aG9zdCB3aXRob3V0IHJlcXVpcmluZw0KICAgaXRzIHBhcnRpY2lwYXRpb24gaW4gYW55IG1vYmls aXR5IHNpZ25hbGluZywgYmVpbmcgdGhlIG5ldHdvcmsNCiAgIHJlc3BvbnNpYmxlIGZvciBtYW5h Z2luZyBJUCBtb2JpbGl0eSBvbiBiZWhhbGYgb2YgdGhlIGhvc3QuLyBQcm94eQ0KICAgTW9iaWxl IElQdjYgZW5hYmxlcyBJUCBtb2JpbGl0eSBmb3IgYSBob3N0IHdpdGhvdXQgcmVxdWlyaW5nIA0K ICAgaXRzIHBhcnRpY2lwYXRpb24gaW4gYW55IG1vYmlsaXR5IHNpZ25hbGluZy4gTW9iaWxpdHkg ZWxlbWVudHMgaW4NCiAgIHRoZSBuZXR3b3JrIGFyZSByZXNwb25zaWJsZSBmb3IgbWFuYWdpbmcg SVAgbW9iaWxpdHkgb24gYmVoYWxmIG9mDQogICB0aGUgaG9zdC4gDQoNCnMvSG93ZXZlciwNCiAg IFByb3h5IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEgcHJlZml4IHRv IGEgcm91dGVyIGFuZA0KICAgbWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5Li9Ib3dldmVyLCBQcm94 eSBNb2JpbGUgSVB2NiBsYWNrcyB0aGUNCiAgIGFiaWxpdHkgdG8gYXNzaWduIGEgcHJlZml4IHRv IGEgcm91dGVyIGFuZCAgbWFuYWdlIGl0cyBJUA0KICAgbW9iaWxpdHkuIA0KDQpzL2FuZCBiZSBh YmxlIHRvIG9idGFpbiBJUCBtb2JpbGl0eSBzdXBwb3J0IGZvciB0aG9zZSBJUCBhZGRyZXNzZXMu Lw0KICAgYW5kIGVuYWJsZSBJUCBtb2JpbGl0eSBzdXBwb3J0IGZvciB0aGUgYXNzaWduZWQgSVAg YWRkcmVzcyBvcg0KICAgcHJlZml4ZXMuIA0KDQpzL0hvd2V2ZXIsDQogICB0aGlzIG5ldHdvcmst YmFzZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBzdXBwb3J0IGlzIHNwZWNpZmljIHRvIGFuIElQDQog ICBob3N0IGFuZCBjdXJyZW50bHkgdGhlcmUgaXMgbm8gc3VjaCBuZXR3b3JrLWJhc2VkIG1vYmls aXR5IG1hbmFnZW1lbnQNCiAgIHN1cHBvcnQgZm9yIGEgbW9iaWxlIHJvdXRlciB3aXRoIGEgY2x1 c3RlciBvZiBJUCBob3N0cyBiZWhpbmQgDQppdC4vSG93ZXZlciwNCiAgIHRoZSBQcm94eSBNb2Jp bGUgSVB2NiBiYXNlZCBzb2x1dGlvbiBmb3IgIG5ldHdvcmstYmFzZWQgbW9iaWxpdHkNCiAgIG1h bmFnZW1lbnQgaXMgc3BlY2lmaWMgdG8gSVAgaG9zdHMgYW5kIGRvZXMgbm90IHByb3ZpZGUgc2lt aWxhcg0KICAgZnVuY3Rpb25hbGl0eSBmb3IgYSBtb2JpbGUgcm91dGVyIHdpdGggYSBjbHVzdGVy IG9mIElQIGhvc3RzIGJlaGluZA0KICAgaXQuIA0KDQotUmFqDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0 QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0K DQoNCg== --=_alternative 0035066648257B71_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIFJhaiw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBy ZXZpZXcuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5B IG5ldyB2ZXJzaW9uICgtMDgpIG9mIHRoZSBkcmFmdCBoYXMNCmJlZW4gc3VibWl0dGVkLiBZb3Vy IGNvbW1lbnRzIGJlbG93IGFyZSBhZGRyZXNzZWQgaW4gdGhpcyB2ZXJzaW9uLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGRyYWZ0IGlzIHJlYWR5 IGZvciBXR0xDIG5vdy4gVGhhbmtzLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Sm95PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPkJhc2F2YXJhaiBQYXRpbCAmbHQ7YnBhdGlsMUBnbWFpbC5j b20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO25ldGV4dC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTMtMDQtMDQgMDE6NTk8L2ZvbnQ+DQo8dGQgd2lkdGg9 NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bmV0ZXh0QGlldGYu b3JnJnF1b3Q7ICZsdDtuZXRleHRAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtkcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwQHRvb2xzLmlldGYub3JnJnF1b3Q7DQombHQ7ZHJh ZnQtaWV0Zi1uZXRleHQtcGQtcG1pcEB0b29scy5pZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPltuZXRleHRdIFJldmlldyBvZiBJLUQ6IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXA2LTA2 PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPlF1ZXN0aW9uczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjEuIElu IHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7 ICZuYnNwOyZxdW90O1RoZSBETU5QIGlzIGFuIElQdjQgb3IgYW4gSVB2NiBwcmVmaXgNCmRlbGVn YXRlZCB0byBhIG1vYmlsZSByb3V0ZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAm bmJzcDsgJm5ic3A7IGFuZCBhZHZlcnRpc2VkIGluIHRoZSBtb2JpbGUgbmV0d29yay4mcXVvdDs8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFdoYXQg aXMgdGhlIG1vYmlsZSBuZXR3b3JrIGJlaW5nDQpyZWZlcmVkIHRvIGluIHRoaXMgc3RhdGVtZW50 PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSXMgaXQgdGhl IFBNSVA2IGRvbWFpbiBpdHNlbGY/IE9yDQppcyBpdCB0aGUgbmV0d29yayB0aGF0IHRoZTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9iaWxlIHJvdXRlciBp cyBob3N0aW5nPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+Mi4gSW4gU2VjIDQuMy4x OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyZxdW90O0l0IGlzIHBvc3Np YmxlIHRoYXQgdGhlIGRlbGVnYXRlZCBwcmVmaXgoZXMpDQptYXk8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hhdmUgYmVlbiBhc3NpZ25lZCB0byB0 aGUgTUFHDQpieSB0aGUgTE1BIGR1cmluZyB0aGlzIHByb2NlZHVyZSBvZjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UE1JUHY2IHR1bm5lbCBlc3Rh Ymxpc2htZW50Lg0KJm5ic3A7VGhhdCBpcyB0aGUgTUFHIG1heSBpbmNsdWRlIG9uZSAob3I8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21vcmUpIERl bGVnYXRlZCBNb2JpbGUgTmV0d29yaw0KUHJlZml4IChETU5QKSBtb2JpbGl0eSBvcHRpb25zPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGljaCBN VVNUIGJlIHNldCB0byB0aGUgdW5zcGVjaWZpZWQNCklQdjYgYWRkcmVzcyAmcXVvdDs6OiZxdW90 OyBpbiB0aGUgUEJVPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt0byByZXF1ZXN0IHRoZSBkZWxlZ2F0ZWQgcHJlZml4KGVzKS4NCiZuYnNwO1RoZSBM TUEgYXNzaWducyBhIG5ldyBzZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO29mIERNTlAocykgaW4gUEJBIG1lc3NhZ2UuJnF1b3Q7PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOb3Qgc3Vy ZSB3aGF0IHlvdXIgYXNzdW1wdGlvbnMNCmFyZSBoZXJlLiBXaHkgZG9lcyB0aGUgTE1BPC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthc3NpZ24gZGVs ZWdhdGVkIHByZWZpeChlcykNCmR1cmluZyBub3JtYWwgUkZDNTIxMyBQTUlQNiB0dW5uZWw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VzdGFibGlz aG1lbnQgcHJvY2VkdXJlcz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1doYXQgd291bGQgY2F1c2UgdGhlIE1BRyB0bw0KaW5jbHVkZSB0aGUgRE1O UCBvcHRpb24gaW4gdGhlIFBCVTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YXQgdGhpcyBzdGFnZSAoU3RlcCAyKSBvZiB0aGUNCnNlc3Npb24/PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz4zLiBJbiBTZWMgNC4zLjE6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7JnF1b3Q7IFRoZSBtb2JpbGUgcm91dGVyLCBhY3Rp bmcgYXMgYSAmcXVvdDtSZXF1ZXN0aW5nDQpSb3V0ZXImcXVvdDsgYXMgZGVzY3JpYmVkPC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbiBbUkZDMzYz M10sIHNlbmRzIGEgREhDUHY2DQpTT0xJQ0lUIG1lc3NhZ2UgaW5jbHVkaW5nIG9uZSBvcjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9yZSBJQV9Q RCBvcHRpb24ocykgdG8gdGhlDQptb2JpbGUgYWNjZXNzIGdhdGV3YXkgKHdoaWNoIGhhcyBhPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtE SENQdjYgU2VydmVyJnF1b3Q7IGZ1bmN0aW9uKQ0KdG8gYWNxdWlyZSB0aGUgZGVsZWdhdGVkIHBy ZWZpeChlcykuJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRoYXQNCnRoZSBNQUcgaXMg YWxzbyB0aGUgREhDUHY2IHNlcnZlcj88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBNQUcgY291bGQgYmUgYSBESENQIHJlbGF5DQphcyB3ZWxs LCByaWdodD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjQuIEluIFNlYyA0LjMuMSwg c3RlcCA1OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyZxdW90O1RoZSBM TUEgbXVzdCBzZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3VwIGZvcndhcmRpbmcgZm9yIHRoZSBkZWxlZ2F0ZWQNCnByZWZpeGVzIGFzIHJlYWNo YWJsZSB0aHJvdWdoIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7UE1JUHY2IHR1bm5lbC4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBMTUEgbWF5IG9yIG1heSBub3Qg YXNzaWduDQp0aGVzZSBkZWxlZ2F0ZWQgcHJlZml4ZXMuIFRoZSBNQUc8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvdWxkIGJlIHRoZSBvbmUgYXNz aWduaW5nDQp0aGUgZGVsZWdhdGVkIHByZWZpeGVzIGFzIHBlciB0aGU8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9uLiBBcmUgdGhv c2UgcHJlZml4ZXMNCnJvdXRhYmxlIGJ5IHRoZSBMTUE/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz41LiBJbiBTZWMgNC40LjEsIHN0ZXAgNDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOyAmbmJzcDsmcXVvdDtJZiB0aGUgbW9iaWxlIGFjY2VzczwvZm9udD4NCjxicj48Zm9u dCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGdhdGV3YXkgZG9lcyBub3Qga25v dyB0aGUNCmRlbGVnYXRlZCBwcmVmaXgoZXMpLCB0aGVuIHRoZTwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlbGVnYXRlZCBtb2JpbGUgbmV0d29y ayBwcmVmaXgNCmluIHRoZSBETU5QIG9wdGlvbihzKSBNVVNUIGJlPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2V0IHRvIHRoZSB1bnNwZWNpZmll ZCBJUHY2DQphZGRyZXNzICZxdW90Ozo6JnF1b3Q7LCAmcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPkhvdyB3b3VsZCB0aGUgTUFHIGtub3cgdGhlIGRlbGVnYXRlZCBwcmVmaXgo ZXMpPyBVbmxlc3MNCml0IGlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5qdXN0IHJlbmV3aW5n IHRoZSBhc3NpZ25lZCBwcmVmaXgoZXMpPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ Ni4gSXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgREhDUCBzZXJ2ZXIgZnVuY3Rpb25hbGl0eQ0K cmVzaWRlcyBlaXRoZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDthdCB0 aGUgTUFHIG9yIHRoZSBMTUEgaW4gdGhpcyBJLUQ/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9Mz43LiBJbiBTZWMgNi4yIHlvdSBzdGF0ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZu YnNwOyAmbmJzcDsmcXVvdDtJbiBvcmRlciB0byByZWNlaXZlIHRoZXNlIHBhY2tldHMsDQp0aGU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGxvY2FsIG1vYmls aXR5IGFuY2hvciBNVVNUIGJlIHRoZQ0KdG9wb2xvZ2ljYWwgYW5jaG9yIG9mIHRoZSBNUidzPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWxlZ2F0ZWQgbW9i aWxlIG5ldHdvcmsgcHJlZml4KGVzKS4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgc2hvdWxkIGJlIG1hZGUgY2xlYXIgdXAgZnJv bnQNCmluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYWJvdXQgaG93IGZvcndhcmRpbmcgaXMgYWNjb21wbGlzaGVk LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+RWRpdG9yaWFsOjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+cy9Qcm94eSBNb2JpbGUgSVB2NiBlbmFibGVz IElQIG1vYmlsaXR5IGZvciBhIGhvc3Qgd2l0aG91dA0KcmVxdWlyaW5nPC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz4mbmJzcDsgJm5ic3A7aXRzIHBhcnRpY2lwYXRpb24gaW4gYW55IG1vYmlsaXR5 IHNpZ25hbGluZywNCmJlaW5nIHRoZSBuZXR3b3JrPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDsgJm5ic3A7cmVzcG9uc2libGUgZm9yIG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFs Zg0Kb2YgdGhlIGhvc3QuLyBQcm94eTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZu YnNwO01vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9yIGEgaG9zdA0Kd2l0aG91dCBy ZXF1aXJpbmcmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDtpdHMg cGFydGljaXBhdGlvbiBpbiBhbnkgbW9iaWxpdHkgc2lnbmFsaW5nLg0KTW9iaWxpdHkgZWxlbWVu dHMgaW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDt0aGUgbmV0d29yayBh cmUgcmVzcG9uc2libGUgZm9yIG1hbmFnaW5nDQpJUCBtb2JpbGl0eSBvbiBiZWhhbGYgb2Y8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDt0aGUgaG9zdC4mbmJzcDs8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPnMvSG93ZXZlciw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPiZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUgSVB2NiBkb2VzIG5vdCBzdXBwb3J0IGFzc2ln bmluZw0KYSBwcmVmaXggdG8gYSByb3V0ZXIgYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDsgJm5ic3A7bWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5Li9Ib3dldmVyLCBQcm94eQ0KTW9i aWxlIElQdjYgbGFja3MgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7 YWJpbGl0eSB0byBhc3NpZ24gYSBwcmVmaXggdG8gYSByb3V0ZXIgYW5kDQombmJzcDttYW5hZ2Ug aXRzIElQPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7bW9iaWxpdHkuJm5i c3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5zL2FuZCBiZSBhYmxlIHRvIG9idGFp biBJUCBtb2JpbGl0eSBzdXBwb3J0IGZvciB0aG9zZQ0KSVAgYWRkcmVzc2VzLi88L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDthbmQgZW5hYmxlIElQIG1vYmlsaXR5IHN1cHBv cnQgZm9yIHRoZSBhc3NpZ25lZA0KSVAgYWRkcmVzcyBvcjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7ICZuYnNwO3ByZWZpeGVzLiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+cy9Ib3dldmVyLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwO3Ro aXMgbmV0d29yay1iYXNlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IHN1cHBvcnQNCmlzIHNwZWNpZmlj IHRvIGFuIElQPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7aG9zdCBhbmQg Y3VycmVudGx5IHRoZXJlIGlzIG5vIHN1Y2ggbmV0d29yay1iYXNlZA0KbW9iaWxpdHkgbWFuYWdl bWVudDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwO3N1cHBvcnQgZm9yIGEg bW9iaWxlIHJvdXRlciB3aXRoIGEgY2x1c3Rlcg0Kb2YgSVAgaG9zdHMgYmVoaW5kIGl0Li9Ib3dl dmVyLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwO3RoZSBQcm94eSBNb2Jp bGUgSVB2NiBiYXNlZCBzb2x1dGlvbiBmb3INCiZuYnNwO25ldHdvcmstYmFzZWQgbW9iaWxpdHk8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDttYW5hZ2VtZW50IGlzIHNwZWNp ZmljIHRvIElQIGhvc3RzIGFuZCBkb2VzDQpub3QgcHJvdmlkZSBzaW1pbGFyPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ZnVuY3Rpb25hbGl0eSBmb3IgYSBtb2JpbGUgcm91 dGVyIHdpdGggYQ0KY2x1c3RlciBvZiBJUCBob3N0cyBiZWhpbmQ8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zPiZuYnNwOyAmbmJzcDtpdC4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPi1SYWo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+ DQpuZXRleHRAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGV4dDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0035066648257B71_=-- From cjbc@it.uc3m.es Mon May 20 08:04:29 2013 Return-Path: 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 ED91621F8C38 for ; Mon, 20 May 2013 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eSClE3hFA6Jv for ; Mon, 20 May 2013 08:04:25 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E486C21F933B for ; Mon, 20 May 2013 08:04:24 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CFC321183F9A; Mon, 20 May 2013 17:04:23 +0200 (CEST) X-uc3m-safe: yes 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) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id B9BBA9D360B; Mon, 20 May 2013 17:04:23 +0200 (CEST) Message-ID: <1369062263.4503.40.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj Patil Date: Mon, 20 May 2013 17:04:23 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19880.007 X-TM-AS-Result: No--22.436-7.0-31-1 X-imss-scan-details: No--22.436-7.0-31-1 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:04:30 -0000 Hi Raj, Some additional responses inline below (as Joy mentioned, we believe that everything is clearer in the new version, but just in case). On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote: > > > > > Questions: > > > 1. In the terminology section: > "The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router > and advertised in the mobile network." > > > What is the mobile network being refered to in this statement? > Is it the PMIP6 domain itself? Or is it the network that the > mobile router is hosting? [Carlos] It is the network that the mobile router is hosting. > > > 2. In Sec 4.3.1: > "It is possible that the delegated prefix(es) may > have been assigned to the MAG by the LMA during this procedure > of > PMIPv6 tunnel establishment. That is the MAG may include one > (or > more) Delegated Mobile Network Prefix (DMNP) mobility options > which MUST be set to the unspecified IPv6 address "::" in the > PBU > to request the delegated prefix(es). The LMA assigns a new set > of DMNP(s) in PBA message." > > > Not sure what your assumptions are here. Why does the LMA > assign delegated prefix(es) during normal RFC5213 PMIP6 tunnel > establishment procedures? > What would cause the MAG to include the DMNP option in the PBU > at this stage (Step 2) of the session? [Carlos] We have clarified this in the new version. > > > 3. In Sec 4.3.1: > " The mobile router, acting as a "Requesting Router" as described > in [RFC3633], sends a DHCPv6 SOLICIT message including one or > more IA_PD option(s) to the mobile access gateway (which has a > "DHCPv6 Server" function) to acquire the delegated prefix(es)." > > > Is there an assumption that the MAG is also the DHCPv6 server? > The MAG could be a DHCP relay as well, right? [Carlos] Right, two deployment models are considered: one in which the MAG acts a DHCPv6 Delegating Router (i.e., server) and another in which the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating Router. This has been further clarified in the new version. > > > 4. In Sec 4.3.1, step 5: > "The LMA must set > up forwarding for the delegated prefixes as reachable through > the > PMIPv6 tunnel." > > > The LMA may or may not assign these delegated prefixes. The MAG > could be the one assigning the delegated prefixes as per the > description. Are those prefixes routable by the LMA? [Carlos] Yes, the prefixes are routable by the LMA. > > > 5. In Sec 4.4.1, step 4: > "If the mobile access > gateway does not know the delegated prefix(es), then the > delegated mobile network prefix in the DMNP option(s) MUST be > set to the unspecified IPv6 address "::", " > > > How would the MAG know the delegated prefix(es)? Unless it is > just renewing the assigned prefix(es)? [Carlos] This has been further revised and clarified in the new version. > > > 6. Is the assumption that the DHCP server functionality resides either > at the MAG or the LMA in this I-D? [Carlos] Yes. It should be now clearer with the updates we have done in the text. > > > 7. In Sec 6.2 you state: > "In order to receive these packets, the > local mobility anchor MUST be the topological anchor of the MR's > delegated mobile network prefix(es)." > > > This should be made clear up front in order to avoid confusion > about how forwarding is accomplished. > > [Carlos] This should be now clear. > Thanks for your comments! Carlos > > > Editorial: > > > s/Proxy Mobile IPv6 enables IP mobility for a host without requiring > its participation in any mobility signaling, being the network > responsible for managing IP mobility on behalf of the host./ Proxy > Mobile IPv6 enables IP mobility for a host without requiring > its participation in any mobility signaling. Mobility elements in > the network are responsible for managing IP mobility on behalf of > the host. > > > s/However, > Proxy Mobile IPv6 does not support assigning a prefix to a router > and > managing its IP mobility./However, Proxy Mobile IPv6 lacks the > ability to assign a prefix to a router and manage its IP > mobility. > > > s/and be able to obtain IP mobility support for those IP addresses./ > and enable IP mobility support for the assigned IP address or > prefixes. > > > s/However, > this network-based mobility management support is specific to an IP > host and currently there is no such network-based mobility > management > support for a mobile router with a cluster of IP hosts behind > it./However, > the Proxy Mobile IPv6 based solution for network-based mobility > management is specific to IP hosts and does not provide similar > functionality for a mobile router with a cluster of IP hosts behind > it. > > > -Raj > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon May 20 08:26:26 2013 Return-Path: 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 F110F21F93BC for ; Mon, 20 May 2013 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0s2bt6sItnHM for ; Mon, 20 May 2013 08:26:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E7AAA21F93BD for ; Mon, 20 May 2013 08:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6665; q=dns/txt; s=iport; t=1369063581; x=1370273181; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SLmQ2EzgsnOIqhLgEDPWmuFiR7E5l+PyD5Kn+O04U00=; b=IISNboYk3g5jp3YXF1SWpAvJ6j7i/Yp8iQYVRlezVY8TWyLp4ccYp+kD PpUNOPC3gY+EXhC8Qzd4LBRPjFzQkB4jLNw8fj+DmWShS8Z2edXSAP7fs r8AO/eJDWiImeGetESSwuWtPilG6b0Ca5SsDt/01X/2miWqqQrtXAF45T E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAFAJ8/mlGtJV2Z/2dsb2JhbABagwgwwT+BABZ0gh8BAQEEAQEBZAcGBRIBCBgKSwslAgQBDQUIE4dyDLtSBI5uAjEHgnNhA4hniwCVEYMPgiY X-IronPort-AV: E=Sophos;i="4.87,707,1363132800"; d="scan'208";a="212667657" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 20 May 2013 15:26:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4KFQKkP016333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 May 2013 15:26:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 20 May 2013 10:26:20 -0500 From: "Sri Gundavelli (sgundave)" To: "cjbc@it.uc3m.es" , Basavaraj Patil Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 Thread-Index: AQHOVWtVRsvRLCtAEUCu95E5Obm4XJkODlwA Date: Mon, 20 May 2013 15:26:19 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102A40D0@xmb-aln-x03.cisco.com> In-Reply-To: <1369062263.4503.40.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Mon, 20 May 2013 15:26:26 -0000 Hi Raj, Adding to what carlos said. Just one clarification. On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" wrote= : >Hi Raj, > >Some additional responses inline below (as Joy mentioned, we believe >that everything is clearer in the new version, but just in case). > >On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote: >>=20 >>=20 >>=20 >>=20 >> Questions: >>=20 >>=20 >> 1. In the terminology section: >> "The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router >> and advertised in the mobile network." >>=20 >>=20 >> What is the mobile network being refered to in this statement? >> Is it the PMIP6 domain itself? Or is it the network that the >> mobile router is hosting? > >[Carlos] It is the network that the mobile router is hosting. >>=20 >>=20 >> 2. In Sec 4.3.1: >> "It is possible that the delegated prefix(es) may >> have been assigned to the MAG by the LMA during this procedure >> of >> PMIPv6 tunnel establishment. That is the MAG may include one >> (or >> more) Delegated Mobile Network Prefix (DMNP) mobility options >> which MUST be set to the unspecified IPv6 address "::" in the >> PBU >> to request the delegated prefix(es). The LMA assigns a new set >> of DMNP(s) in PBA message." >>=20 >>=20 >> Not sure what your assumptions are here. Why does the LMA >> assign delegated prefix(es) during normal RFC5213 PMIP6 tunnel >> establishment procedures? >> What would cause the MAG to include the DMNP option in the PBU >> at this stage (Step 2) of the session? > >[Carlos] We have clarified this in the new version. >>=20 >>=20 >> 3. In Sec 4.3.1: >> " The mobile router, acting as a "Requesting Router" as described >> in [RFC3633], sends a DHCPv6 SOLICIT message including one or >> more IA_PD option(s) to the mobile access gateway (which has a >> "DHCPv6 Server" function) to acquire the delegated prefix(es)." >>=20 >>=20 >> Is there an assumption that the MAG is also the DHCPv6 server? >> The MAG could be a DHCP relay as well, right? > >[Carlos] Right, two deployment models are considered: one in which the >MAG acts a DHCPv6 Delegating Router (i.e., server) and another in which >the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating Router. >This has been further clarified in the new version. >>=20 >>=20 >> 4. In Sec 4.3.1, step 5: >> "The LMA must set >> up forwarding for the delegated prefixes as reachable through >> the >> PMIPv6 tunnel." >>=20 >>=20 >> The LMA may or may not assign these delegated prefixes. The MAG >> could be the one assigning the delegated prefixes as per the >> description. Are those prefixes routable by the LMA? > >[Carlos] Yes, the prefixes are routable by the LMA. >>=20 >>=20 >> 5. In Sec 4.4.1, step 4: >> "If the mobile access >> gateway does not know the delegated prefix(es), then the >> delegated mobile network prefix in the DMNP option(s) MUST be >> set to the unspecified IPv6 address "::", " >>=20 >>=20 >> How would the MAG know the delegated prefix(es)? Unless it is >> just renewing the assigned prefix(es)? The prefixes can be statically configured in the policy profile. Typically mobile networks are statically configured (but registered with the LMA) as we don't want the prefixes to disappear if the egress link goes down and that will result in local communication between the hosts to break. So, the prefixes are statically provisioned in the mobile network. But, mobility support comes up only when there is active session with LMA enabling the forwarding. If the MAG knows the prefixes, it can indicate them in the DMNP option. If the MAG does not know the prefixes, it will carry a NULL value. LMA assigns them based on what is in the BCE state. This is consistent with how the home address (IPv4 HoA, HNP) options are carried in PMIP signaling messages. Regards Sri > >[Carlos] This has been further revised and clarified in the new version. >>=20 >>=20 >> 6. Is the assumption that the DHCP server functionality resides either >> at the MAG or the LMA in this I-D? > >[Carlos] Yes. It should be now clearer with the updates we have done in >the text. >>=20 >>=20 >> 7. In Sec 6.2 you state: >> "In order to receive these packets, the >> local mobility anchor MUST be the topological anchor of the MR's >> delegated mobile network prefix(es)." >>=20 >>=20 >> This should be made clear up front in order to avoid confusion >> about how forwarding is accomplished. >>=20 >>=20 >[Carlos] This should be now clear. >>=20 >Thanks for your comments! > >Carlos >>=20 >>=20 >> Editorial: >>=20 >>=20 >> s/Proxy Mobile IPv6 enables IP mobility for a host without requiring >> its participation in any mobility signaling, being the network >> responsible for managing IP mobility on behalf of the host./ Proxy >> Mobile IPv6 enables IP mobility for a host without requiring >> its participation in any mobility signaling. Mobility elements in >> the network are responsible for managing IP mobility on behalf of >> the host.=20 >>=20 >>=20 >> s/However, >> Proxy Mobile IPv6 does not support assigning a prefix to a router >> and >> managing its IP mobility./However, Proxy Mobile IPv6 lacks the >> ability to assign a prefix to a router and manage its IP >> mobility.=20 >>=20 >>=20 >> s/and be able to obtain IP mobility support for those IP addresses./ >> and enable IP mobility support for the assigned IP address or >> prefixes.=20 >>=20 >>=20 >> s/However, >> this network-based mobility management support is specific to an IP >> host and currently there is no such network-based mobility >> management >> support for a mobile router with a cluster of IP hosts behind >> it./However, >> the Proxy Mobile IPv6 based solution for network-based mobility >> management is specific to IP hosts and does not provide similar >> functionality for a mobile router with a cluster of IP hosts behind >> it.=20 >>=20 >>=20 >> -Raj >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From bpatil1@gmail.com Wed May 22 12:40:43 2013 Return-Path: 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 6503511E815F for ; Wed, 22 May 2013 12:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 dKfT9u9fIWFK for ; Wed, 22 May 2013 12:40:39 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1525811E815C for ; Wed, 22 May 2013 12:40:36 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id f4so3312005oah.10 for ; Wed, 22 May 2013 12:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7fWRK37+IYB3zdle+EeYxUo37pdkHYsYf+ws2TsHkJ8=; b=pWzUQcyquOXXumZhZQ0vp4+hYwhK6BIyjzdg8Ks2zYpCrLgeI5JiC3HTNW9c6PnJMJ yHucg6UnHb6Zfvptr0qtTDwkN5ZmHAcZhwTaITebv2/TlJItyBpJe0GnIG8VLSkKIP8H tx/V3tQkf4dYkKqilzxbWCcYSo7Ce0mXfo8dUzRlkTqnQriWtVurqkoY5W/rBHXOX/gL 3eUkat1hxhRYN0gkFXZ+j/VLMAQ2OT2vIhYsBuKX0daNN3kt9Ojt9l2dhvIwUSn9XOzP Shxqvce9orKlOL9CK9R+kQ0WdgTW71bIOO01xkMzqhf6huIHMSB3L8XLDrpekTvWDDUt j8mg== MIME-Version: 1.0 X-Received: by 10.60.60.10 with SMTP id d10mr6059829oer.6.1369251635531; Wed, 22 May 2013 12:40:35 -0700 (PDT) Received: by 10.76.103.235 with HTTP; Wed, 22 May 2013 12:40:35 -0700 (PDT) In-Reply-To: <1369062263.4503.40.camel@acorde.it.uc3m.es> References: <1369062263.4503.40.camel@acorde.it.uc3m.es> Date: Wed, 22 May 2013 14:40:35 -0500 Message-ID: From: Basavaraj Patil To: "cjbc@it.uc3m.es" Content-Type: multipart/alternative; boundary=089e012948025876e704dd53bd7f Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Wed, 22 May 2013 19:40:43 -0000 --089e012948025876e704dd53bd7f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos et al, My comments inline: On Mon, May 20, 2013 at 10:04 AM, Carlos Jes=FAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi Raj, > > Some additional responses inline below (as Joy mentioned, we believe > that everything is clearer in the new version, but just in case). > > On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote: > > > > > > > > > > Questions: > > > > > > 1. In the terminology section: > > "The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router > > and advertised in the mobile network." > > > > > > What is the mobile network being refered to in this statement? > > Is it the PMIP6 domain itself? Or is it the network that the > > mobile router is hosting? > > [Carlos] It is the network that the mobile router is hosting. > Raj> Okay. However the current statement in the I-D: " The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix delegated to a mobile router and is hosted in the mobile network. " Would be better to say that this prefix is hosted by the PMIP6 mobility agent, i.e LMA. > > > > > 2. In Sec 4.3.1: > > "It is possible that the delegated prefix(es) may > > have been assigned to the MAG by the LMA during this procedure > > of > > PMIPv6 tunnel establishment. That is the MAG may include one > > (or > > more) Delegated Mobile Network Prefix (DMNP) mobility options > > which MUST be set to the unspecified IPv6 address "::" in the > > PBU > > to request the delegated prefix(es). The LMA assigns a new set > > of DMNP(s) in PBA message." > > > > > > Not sure what your assumptions are here. Why does the LMA > > assign delegated prefix(es) during normal RFC5213 PMIP6 tunnel > > establishment procedures? > > What would cause the MAG to include the DMNP option in the PBU > > at this stage (Step 2) of the session? > > [Carlos] We have clarified this in the new version. > Raj> Section 4.3.1 no longer exists. Would have been easier if the revised section was pasted here :( > > > > > > 3. In Sec 4.3.1: > > " The mobile router, acting as a "Requesting Router" as described > > in [RFC3633], sends a DHCPv6 SOLICIT message including one or > > more IA_PD option(s) to the mobile access gateway (which has a > > "DHCPv6 Server" function) to acquire the delegated prefix(es)." > > > > > > Is there an assumption that the MAG is also the DHCPv6 server? > > The MAG could be a DHCP relay as well, right? > > [Carlos] Right, two deployment models are considered: one in which the > MAG acts a DHCPv6 Delegating Router (i.e., server) and another in which > the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating Router. > This has been further clarified in the new version. > Raj> Okay.. Good. > > > > > > 4. In Sec 4.3.1, step 5: > > "The LMA must set > > up forwarding for the delegated prefixes as reachable through > > the > > PMIPv6 tunnel." > > > > > > The LMA may or may not assign these delegated prefixes. The MAG > > could be the one assigning the delegated prefixes as per the > > description. Are those prefixes routable by the LMA? > > [Carlos] Yes, the prefixes are routable by the LMA. > Raj> How?? Are those prefixes which the MAG delegates also anchored at the LMA? > > > > > > 5. In Sec 4.4.1, step 4: > > "If the mobile access > > gateway does not know the delegated prefix(es), then the > > delegated mobile network prefix in the DMNP option(s) MUST be > > set to the unspecified IPv6 address "::", " > > > > > > How would the MAG know the delegated prefix(es)? Unless it is > > just renewing the assigned prefix(es)? > > [Carlos] This has been further revised and clarified in the new version. > Raj> What is the new section in the document? Sec 4.4.1 is no longer there. > > > > > > 6. Is the assumption that the DHCP server functionality resides either > > at the MAG or the LMA in this I-D? > > [Carlos] Yes. It should be now clearer with the updates we have done in > the text. > Raj> Okay. > > > > > > 7. In Sec 6.2 you state: > > "In order to receive these packets, the > > local mobility anchor MUST be the topological anchor of the MR's > > delegated mobile network prefix(es)." > > > > > > This should be made clear up front in order to avoid confusion > > about how forwarding is accomplished. > > > > > [Carlos] This should be now clear. > Raj> Can you point me to the new text that clarifies this? -Raj > > > Thanks for your comments! > > Carlos > > > > > > Editorial: > > > > > > s/Proxy Mobile IPv6 enables IP mobility for a host without requiring > > its participation in any mobility signaling, being the network > > responsible for managing IP mobility on behalf of the host./ Proxy > > Mobile IPv6 enables IP mobility for a host without requiring > > its participation in any mobility signaling. Mobility elements in > > the network are responsible for managing IP mobility on behalf of > > the host. > > > > > > s/However, > > Proxy Mobile IPv6 does not support assigning a prefix to a router > > and > > managing its IP mobility./However, Proxy Mobile IPv6 lacks the > > ability to assign a prefix to a router and manage its IP > > mobility. > > > > > > s/and be able to obtain IP mobility support for those IP addresses./ > > and enable IP mobility support for the assigned IP address or > > prefixes. > > > > > > s/However, > > this network-based mobility management support is specific to an IP > > host and currently there is no such network-based mobility > > management > > support for a mobile router with a cluster of IP hosts behind > > it./However, > > the Proxy Mobile IPv6 based solution for network-based mobility > > management is specific to IP hosts and does not provide similar > > functionality for a mobile router with a cluster of IP hosts behind > > it. > > > > > > -Raj > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Basavaraj Patil --089e012948025876e704dd53bd7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Carlos et al,

My comments inline:

On Mon, May 20, 2013 at 10:04 AM, Carlos Jes=FAs Bernardos Cano <cjbc@i= t.uc3m.es> wrote:

Hi Raj,

Some additional responses inline below (as Joy mentioned, we believe
that everything is clearer in the new version, but just in case).

On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote:
>
>
>
>
> Questions:
>
>
> 1. In the terminology section:
> =A0 =A0"The DMNP is an IPv4 or an IPv6 prefix delegated to a mobi= le router
> =A0 =A0 =A0 and advertised in the mobile network."
>
>
> =A0 =A0 =A0 What is the mobile network being refered to in this statem= ent?
> =A0 =A0 =A0 Is it the PMIP6 domain itself? Or is it the network that t= he
> =A0 =A0 =A0 mobile router is hosting?

[Carlos] It is the network that the mobile router is hosting.

Raj> Okay.
However th= e current statement in the I-D:
"
T=
he Delegated Mobile Network Prefix is an IPv4/IPv6 prefix
delegated to a mobile router and is hosted in the mobile network.
"
Would be better to say that this prefix= is hosted by the PMIP6 mobility agent, i.e LMA.=A0

>
>
> 2. In Sec 4.3.1:
> =A0 =A0"It is possible that the delegated prefix(es) may
> =A0 =A0 =A0 =A0have been assigned to the MAG by the LMA during this pr= ocedure
> of
> =A0 =A0 =A0 =A0PMIPv6 tunnel establishment. =A0That is the MAG may inc= lude one
> (or
> =A0 =A0 =A0 =A0more) Delegated Mobile Network Prefix (DMNP) mobility o= ptions
> =A0 =A0 =A0 =A0which MUST be set to the unspecified IPv6 address "= ;::" in the
> PBU
> =A0 =A0 =A0 =A0to request the delegated prefix(es). =A0The LMA assigns= a new set
> =A0 =A0 =A0 =A0of DMNP(s) in PBA message."
>
>
> =A0 =A0 =A0 =A0Not sure what your assumptions are here. Why does the L= MA
> =A0 =A0 =A0 =A0assign delegated prefix(es) during normal RFC5213 PMIP6= tunnel
> =A0 =A0 =A0 =A0establishment procedures?
> =A0 =A0 =A0 =A0What would cause the MAG to include the DMNP option in = the PBU
> =A0 =A0 =A0 =A0at this stage (Step 2) of the session?

[Carlos] We have clarified this in the new version.
<= div>
Raj> Section 4.3.1 no longer exists. Would have= been easier if the revised section was pasted here :(
=A0

>
>
> 3. In Sec 4.3.1:
> =A0 =A0" The mobile router, acting as a "Requesting Router&q= uot; as described
> =A0 =A0 =A0 =A0in [RFC3633], sends a DHCPv6 SOLICIT message including = one or
> =A0 =A0 =A0 =A0more IA_PD option(s) to the mobile access gateway (whic= h has a
> =A0 =A0 =A0 =A0"DHCPv6 Server" function) to acquire the dele= gated prefix(es)."
>
>
> =A0 =A0 =A0 =A0Is there an assumption that the MAG is also the DHCPv6 = server?
> =A0 =A0 =A0 =A0The MAG could be a DHCP relay as well, right?

[Carlos] Right, two deployment models are considered: one in which th= e
MAG acts a DHCPv6 Delegating Router (i.e., server) and another in which
the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating Router.
This has been further clarified in the new version.
Raj> Okay.. Good.=A0
=A0

>
>
> 4. In Sec 4.3.1, step 5:
> =A0 =A0"The LMA must set
> =A0 =A0 =A0 =A0up forwarding for the delegated prefixes as reachable t= hrough
> the
> =A0 =A0 =A0 =A0PMIPv6 tunnel."
>
>
> =A0 =A0 =A0 =A0The LMA may or may not assign these delegated prefixes.= The MAG
> =A0 =A0 =A0 =A0could be the one assigning the delegated prefixes as pe= r the
> =A0 =A0 =A0 =A0description. Are those prefixes routable by the LMA?

[Carlos] Yes, the prefixes are routable by the LMA.
<= div>

Raj> How?? Are those prefixes which the MAG del= egates also anchored at the LMA?

=A0

>
>
> 5. In Sec 4.4.1, step 4:
> =A0 =A0"If the mobile access
> =A0 =A0 =A0 =A0 gateway does not know the delegated prefix(es), then t= he
> =A0 =A0 =A0 =A0 delegated mobile network prefix in the DMNP option(s) = MUST be
> =A0 =A0 =A0 =A0 set to the unspecified IPv6 address "::", &q= uot;
>
>
> How would the MAG know the delegated prefix(es)? Unless it is
> just renewing the assigned prefix(es)?

[Carlos] This has been further revised and clarified in the new versi= on.

Raj> What is the new secti= on in the document? Sec 4.4.1 is no longer there.=A0

>
>
> 6. Is the assumption that the DHCP server functionality resides either=
> =A0 =A0at the MAG or the LMA in this I-D?

[Carlos] Yes. It should be now clearer with the updates we have done = in
the text.

Raj> Okay.=A0

<= div>=A0

>
>
> 7. In Sec 6.2 you state:
> =A0 =A0"In order to receive these packets, the
> =A0 =A0 =A0 local mobility anchor MUST be the topological anchor of th= e MR's
> =A0 =A0 =A0 delegated mobile network prefix(es)."
>
>
> =A0 =A0 =A0 This should be made clear up front in order to avoid confu= sion
> =A0 =A0 =A0 about how forwarding is accomplished.
>
>

[Carlos] This should be now clear.

Raj> Can you point me to the new text that clarifies this?

-Raj

=A0

>
Thanks for your comments!

Carlos

>
>
> Editorial:
>
>
> s/Proxy Mobile IPv6 enables IP mobility for a host without requiring > =A0 =A0its participation in any mobility signaling, being the network<= br> > =A0 =A0responsible for managing IP mobility on behalf of the host./ Pr= oxy
> =A0 =A0Mobile IPv6 enables IP mobility for a host without requiring > =A0 =A0its participation in any mobility signaling. Mobility elements = in
> =A0 =A0the network are responsible for managing IP mobility on behalf = of
> =A0 =A0the host.
>
>
> s/However,
> =A0 =A0Proxy Mobile IPv6 does not support assigning a prefix to a rout= er
> and
> =A0 =A0managing its IP mobility./However, Proxy Mobile IPv6 lacks the<= br> > =A0 =A0ability to assign a prefix to a router and =A0manage its IP
> =A0 =A0mobility.
>
>
> s/and be able to obtain IP mobility support for those IP addresses./ > =A0 =A0and enable IP mobility support for the assigned IP address or > =A0 =A0prefixes.
>
>
> s/However,
> =A0 =A0this network-based mobility management support is specific to a= n IP
> =A0 =A0host and currently there is no such network-based mobility
> management
> =A0 =A0support for a mobile router with a cluster of IP hosts behind > it./However,
> =A0 =A0the Proxy Mobile IPv6 based solution for =A0network-based mobil= ity
> =A0 =A0management is specific to IP hosts and does not provide similar=
> =A0 =A0functionality for a mobile router with a cluster of IP hosts be= hind
> =A0 =A0it.
>
>
> -Raj
>
>

> ________________________= _______________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext

_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

--
= Basavaraj Patil

--089e012948025876e704dd53bd7f-- From bpatil1@gmail.com Wed May 22 12:49:10 2013 Return-Path: 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 EE92B21F96C0 for ; Wed, 22 May 2013 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 W2cuHtvWaI1m for ; Wed, 22 May 2013 12:49:04 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE821F96BE for ; Wed, 22 May 2013 12:49:04 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so3245330oag.39 for ; Wed, 22 May 2013 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4W0YFvdF1fdfRhhoNwXYHJ8Ilxxb00IywOEuemTjiQ4=; b=nakqz1R/IkggY1jwqxPfziTS1aRfku94Jfcgj99CR8linys1IJFVIgsbQbKa/Auy0o tZWw3lEWA819A7nJTUn+ruEKRHl4YlXWkHeQHQoJUzEjSezsQGEqnBgik2vQldwkQYXr urf4zfuANexDVMDLY24Cs0HsOzsd7URdhnSCwhqvrqSnlsxOxe9tl70D2s5PSQaaLy6X mJ3uUGmmP8/YiKu+ipxz4lmqZqC3druXXdgJoiO4EwVftAlpVRi2GRY0Y1sAKZyVghCl LqdA2EmdPU5Qz9Y+2MXq+YcaZ95+WINx+ZRsCkzpyzc6yBpkgYRBCJ2qSCazqh1DtByI OF8A== MIME-Version: 1.0 X-Received: by 10.182.237.77 with SMTP id va13mr6157464obc.65.1369252140971; Wed, 22 May 2013 12:49:00 -0700 (PDT) Received: by 10.76.103.235 with HTTP; Wed, 22 May 2013 12:49:00 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8102A40D0@xmb-aln-x03.cisco.com> References: <1369062263.4503.40.camel@acorde.it.uc3m.es> <24C0F3E22276D9438D6F366EB89FAEA8102A40D0@xmb-aln-x03.cisco.com> Date: Wed, 22 May 2013 14:49:00 -0500 Message-ID: From: Basavaraj Patil To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=e89a8ff1cdcc78cbd404dd53db2e Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Wed, 22 May 2013 19:49:10 -0000 --e89a8ff1cdcc78cbd404dd53db2e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline: On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Raj, > > > Adding to what carlos said. Just one clarification. > > > > On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" wro= te: > > > > >> 5. In Sec 4.4.1, step 4: > >> "If the mobile access > >> gateway does not know the delegated prefix(es), then the > >> delegated mobile network prefix in the DMNP option(s) MUST be > >> set to the unspecified IPv6 address "::", " > >> > >> > >> How would the MAG know the delegated prefix(es)? Unless it is > >> just renewing the assigned prefix(es)? > > > The prefixes can be statically configured in the policy profile. Typicall= y > mobile networks are statically configured (but registered with the LMA) a= s > we don't want the prefixes to disappear if the egress link goes down and > that will result in local communication between the hosts to break. So, > the prefixes are statically provisioned in the mobile network. But, > mobility support comes up only when there is active session with LMA > enabling the forwarding. > > If the MAG knows the prefixes, it can indicate them in the DMNP option. > If the MAG does not know the prefixes, it will carry a NULL value. > LMA assigns them based on what is in the BCE state. > > This is consistent with how the home address (IPv4 HoA, HNP) options are > carried in PMIP signaling messages. > > Raj> What does this mean: "Typically mobile networks are statically configured (but registered with the LMA)...."? Also: "So, the prefixes are statically provisioned in the mobile network." Would be good if you can clarify since you have a view or interpretation that I am not sure everyone is in sync with. -Raj > > Regards > Sri > > > --e89a8ff1cdcc78cbd404dd53db2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Inline:

On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli (sgundave) <s= gundave@cisco.com> wrote:

Hi Raj,

Adding to what carlos said. Just one clarification.

On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote:

>> 5. In Sec 4.4.1, step 4:
>> =A0 =A0"If the mobile access
>> =A0 =A0 =A0 =A0 gateway does not know the delegated prefix(es), th= en the
>> =A0 =A0 =A0 =A0 delegated mobile network prefix in the DMNP option= (s) MUST be
>> =A0 =A0 =A0 =A0 set to the unspecified IPv6 address "::"= , "
>>
>>
>> How would the MAG know the delegated prefix(es)? Unless it is
>> just renewing the assigned prefix(es)?

The prefixes can be statically configured in the policy profile= . Typically
mobile networks are statically configured (but registered with the LMA) as<= br> we don't want the prefixes to disappear if the egress link goes down an= d
that will result in local communication between the hosts to break. So,
the prefixes are statically provisioned in the mobile network. But,
mobility support comes up only when there is active session with LMA
enabling the forwarding.

If the MAG knows the prefixes, it can indicate them in the DMNP option.
If the MAG does not know the prefixes, =A0it will carry a NULL value.
LMA assigns them based on what is in the BCE state.

This is consistent with how the home address (IPv4 HoA, HNP) options are carried in PMIP signaling messages.

Raj> =A0What does this mean: = "Typically

mobile networks are statically configured (but registe= red with the LMA)...."?

Also: "So,

the prefixes are statically provisioned in the mobile = network."

Would be good if you can clarify since you have a view or interpre= tation that I am not sure everyone is in sync with.

-Raj

=A0

Regards
Sri

--e89a8ff1cdcc78cbd404dd53db2e-- From sgundave@cisco.com Wed May 22 14:01:39 2013 Return-Path: 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 D283D21F9654 for ; Wed, 22 May 2013 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 wn90bQq9BZwG for ; Wed, 22 May 2013 14:01:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2421F964C for ; Wed, 22 May 2013 14:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9433; q=dns/txt; s=iport; t=1369256487; x=1370466087; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=I5nAz0X+qzIDzqtxZaqGiW6QZXLYV/0NaP6NNzAxYJI=; b=e0bxVQLyCYW/ZnyFVNjMSpS/FhgUx686OpRn1N5fQmdlcim2pAWdBh1f XAif2lbabNu5KBV31TdQVVAmQlLGrWYbumu6pOGgdnUIHCksGzVxZjsX6 oZ1EOrFhuNE9ZHo0FW5GEzKfftu85SjEF2r0z2wl36ga3JiVaHF/GIGXy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFANwxnVGtJXHB/2dsb2JhbABagkREwiKBBxZ0giMBAQEDAWcSEgEIDgMDAQILHSgRFAkIAgQOBQiHcwMJBrIdDYh0jEaCJiARB4JzYQOVUo4DhSODD4Im X-IronPort-AV: E=Sophos;i="4.87,723,1363132800"; d="scan'208,217";a="213816036" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 22 May 2013 21:01:07 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4ML171H012587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 21:01:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 22 May 2013 16:01:06 -0500 From: "Sri Gundavelli (sgundave)" To: Basavaraj Patil Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 Thread-Index: AQHOVy96RsvRLCtAEUCu95E5Obm4XA== Date: Wed, 22 May 2013 21:01:06 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102A9890@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.214] Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA8102A9890xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Wed, 22 May 2013 21:01:39 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA8102A9890xmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Raj, Inline =85 From: Basavaraj Patil > Date: Wednesday, May 22, 2013 12:49 PM To: Sri Gundavelli > Cc: "cjbc@it.uc3m.es" >, "netext@ietf.org" >, "draft-ietf-netext-pd-pmip@tools.ietf.org" > Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 Inline: On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli (sgundave) > wrote: Hi Raj, Adding to what carlos said. Just one clarification. On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" > wrote: >> 5. In Sec 4.4.1, step 4: >> "If the mobile access >> gateway does not know the delegated prefix(es), then the >> delegated mobile network prefix in the DMNP option(s) MUST be >> set to the unspecified IPv6 address "::", " >> >> >> How would the MAG know the delegated prefix(es)? Unless it is >> just renewing the assigned prefix(es)? The prefixes can be statically configured in the policy profile. Typically mobile networks are statically configured (but registered with the LMA) as we don't want the prefixes to disappear if the egress link goes down and that will result in local communication between the hosts to break. So, the prefixes are statically provisioned in the mobile network. But, mobility support comes up only when there is active session with LMA enabling the forwarding. If the MAG knows the prefixes, it can indicate them in the DMNP option. If the MAG does not know the prefixes, it will carry a NULL value. LMA assigns them based on what is in the BCE state. This is consistent with how the home address (IPv4 HoA, HNP) options are carried in PMIP signaling messages. Raj> What does this mean: "Typically mobile networks are statically configured (but registered with the LMA)....= "? Also: "So, the prefixes are statically provisioned in the mobile network." Would be good if you can clarify since you have a view or interpretation th= at I am not sure everyone is in sync with. [Sri] I'm just saying, the subnets (DMNP's) are configured manually in the = mobile network. But, those subnets belong to the LMA from routing point of = view. This is almost like a static IP configuration. There is also the other approach, every thing happens dynamically, the pref= ix is obtained from the LMA/MAG and then gets configured in the mobile netw= ork. In most deployments, IMO, static configuration is preferred as they don't w= ant the networks/prefixes to disappear, if the LMA is not reachable and the= PMIP tunnel goes down. There won't be IP mobility or external reachability= , but there will be internal node to node communication. Regards Sri --_000_24C0F3E22276D9438D6F366EB89FAEA8102A9890xmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2944D7E344FAF24DA79E6F5FEEA2C0D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Raj,

Inline =85

From: Basavaraj Patil <bpatil1@gmail.com>
Date: Wednesday, May 22, 2013 12:49= PM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: "cjbc@it.uc3m.es" <= cjbc@it.uc3m.es>, "netext@ie= tf.org" <netext@ietf.org= >, "draft-ie= tf-netext-pd-pmip@tools.ietf.org" <draft-ietf-netext-pd-pmip@tools.ietf.org>
Subject: Re: [netext] Review of I-D= : draft-ietf-netext-pd-pmip6-06

Inline:

On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli= (sgundave) <sgundave@cisco.com> wrote:

Hi Raj,

Adding to what carlos said. Just one clarification.

On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote:

>> 5. In Sec 4.4.1, step 4:
>> "If the mobile access
>> gateway does not know the delegated pr= efix(es), then the
>> delegated mobile network prefix in the= DMNP option(s) MUST be
>> set to the unspecified IPv6 address &q= uot;::", "
>>
>>
>> How would the MAG know the delegated prefix(es)? Unless it is
>> just renewing the assigned prefix(es)?

The prefixes can be statically configured in the policy profile. Typically<= br> mobile networks are statically configured (but registered with the LMA) as<= br> we don't want the prefixes to disappear if the egress link goes down and that will result in local communication between the hosts to break. So,
the prefixes are statically provisioned in the mobile network. But,
mobility support comes up only when there is active session with LMA
enabling the forwarding.

If the MAG knows the prefixes, it can indicate them in the DMNP option.
If the MAG does not know the prefixes, it will carry a NULL value. LMA assigns them based on what is in the BCE state.

This is consistent with how the home address (IPv4 HoA, HNP) options are carried in PMIP signaling messages.

Raj> What does this mean: "Typically

mobile networks are statically configured (but registered with the LMA)....= "?

Also: "So,

the prefixes are statically provisioned in the mobile network."

Would be good if you can clarify since you have = a view or interpretation that I am not sure everyone is in sync with.

[Sri] I'm just saying, the subnets (DMNP's) are configured manually in= the mobile network. But, those subnets belong to the LMA from routing poin= t of view. This is almost like a static IP configuration.

There is also the other approach, every thing happens dynamically, the= prefix is obtained from the LMA/MAG and then gets configured in the mobile= network.

In most deployments, IMO, static configuration is preferred as they do= n't want the networks/prefixes to disappear, if the LMA is not reachable an= d the PMIP tunnel goes down. There won't be IP mobility or external reachab= ility, but there will be internal node to node communication.

Regards

Sri

--_000_24C0F3E22276D9438D6F366EB89FAEA8102A9890xmbalnx03ciscoc_-- From bpatil1@gmail.com Thu May 23 07:16:34 2013 Return-Path: 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 530D621F9669 for ; Thu, 23 May 2013 07:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 sl3uC1zSZ1lf for ; Thu, 23 May 2013 07:16:29 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id D042F21F9654 for ; Thu, 23 May 2013 07:16:28 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so4365856oah.7 for ; Thu, 23 May 2013 07:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+LaqaU/DxRiCXwVbjoPLwRgB1fzDCgSKv1MmyhzdLhE=; b=QNL+6IX8E8Ug76KBcNIQJo6Ma6ixh4YOmmzh2Q1C50wLnSjgp1eyu/YbSrovP2OKcC 0vEcPNU+Xokc1E/JqH65xYvbCGVqSqDfEAfShblmtd+wvJsqJLTj39ruJ3ogzCSCmb1/ D1Ab+we9d0X+FnNP0axlspOQaLbfwk8m/HRVXU/MGSQSanSY/VZnvkWK46OU+DS8Vkid j3QzI77nUHWOumIdeEmXpneKV8MvvaJhvimhtEht9L/K1HQAtjNg5n046Yuxk2OLCDfK Lb4QEpR9rqgqxem4GTDHlmNqjzqSadih3aM/p3GvMykd1aCjkT7gWen3sMoeiaJPIpcw 0w0w== MIME-Version: 1.0 X-Received: by 10.182.40.202 with SMTP id z10mr8410959obk.74.1369318588389; Thu, 23 May 2013 07:16:28 -0700 (PDT) Received: by 10.76.103.235 with HTTP; Thu, 23 May 2013 07:16:28 -0700 (PDT) In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8102A9890@xmb-aln-x03.cisco.com> References: <24C0F3E22276D9438D6F366EB89FAEA8102A9890@xmb-aln-x03.cisco.com> Date: Thu, 23 May 2013 09:16:28 -0500 Message-ID: From: Basavaraj Patil To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=001a11c32db60ba0fd04dd635445 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Thu, 23 May 2013 14:16:34 -0000 --001a11c32db60ba0fd04dd635445 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Inline: On Wed, May 22, 2013 at 4:01 PM, Sri Gundavelli (sgundave) < sgundave@cisco.com> wrote: > Hi Raj, > > Inline =85 > > Inline: > > > On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli (sgundave) < > sgundave@cisco.com> wrote: > >> Hi Raj, >> >> >> Adding to what carlos said. Just one clarification. >> >> >> >> On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" >> wrote: >> >> >> >> >> 5. In Sec 4.4.1, step 4: >> >> "If the mobile access >> >> gateway does not know the delegated prefix(es), then the >> >> delegated mobile network prefix in the DMNP option(s) MUST be >> >> set to the unspecified IPv6 address "::", " >> >> >> >> >> >> How would the MAG know the delegated prefix(es)? Unless it is >> >> just renewing the assigned prefix(es)? >> >> >> The prefixes can be statically configured in the policy profile. >> Typically >> mobile networks are statically configured (but registered with the LMA) = as >> we don't want the prefixes to disappear if the egress link goes down and >> that will result in local communication between the hosts to break. So, >> the prefixes are statically provisioned in the mobile network. But, >> mobility support comes up only when there is active session with LMA >> enabling the forwarding. >> >> If the MAG knows the prefixes, it can indicate them in the DMNP option. >> If the MAG does not know the prefixes, it will carry a NULL value. >> LMA assigns them based on what is in the BCE state. >> >> This is consistent with how the home address (IPv4 HoA, HNP) options are >> carried in PMIP signaling messages. >> >> > Raj> What does this mean: "Typically > mobile networks are statically configured (but registered with the > LMA)...."? > > Also: "So, > the prefixes are statically provisioned in the mobile network." > > Would be good if you can clarify since you have a view or interpretation > that I am not sure everyone is in sync with. > > > [Sri] I'm just saying, the subnets (DMNP's) are configured manually in > the mobile network. But, those subnets belong to the LMA from routing poi= nt > of view. This is almost like a static IP configuration. > There is also the other approach, every thing happens dynamically, the > prefix is obtained from the LMA/MAG and then gets configured in the mobil= e > network. > In most deployments, IMO, static configuration is preferred as they don't > want the networks/prefixes to disappear, if the LMA is not reachable and > the PMIP tunnel goes down. There won't be IP mobility or external > reachability, but there will be internal node to node communication. > > Regards > Sri > Raj> Well, okay. I get that. But from reading the text in the I-D it is not very clear. Would recommend reworking the text to explain the above. -Raj --=20 Basavaraj Patil --001a11c32db60ba0fd04dd635445 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Inline:

On Wed, May 22, 2013 at 4:01 PM, Sri Gundavelli (sgundave) <sg= undave@cisco.com> wrote:

Hi Raj,

Inline =85

Inline:

On Mon, May 20, 2013 at 10:26 AM, Sri Gundavelli= (sgundave) <sgundave@cisco.com> wrote:

Hi Raj,

Adding to what carlos said. Just one clarification.

On 5/20/13 8:04 AM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote= :

>> 5. In Sec 4.4.1, step 4:
>> =A0 =A0"If the mobile access
>> =A0 =A0 =A0 =A0 gateway does not know the delegated prefix(es), th= en the
>> =A0 =A0 =A0 =A0 delegated mobile network prefix in the DMNP option= (s) MUST be
>> =A0 =A0 =A0 =A0 set to the unspecified IPv6 address "::"= , "
>>
>>
>> How would the MAG know the delegated prefix(es)? Unless it is
>> just renewing the assigned prefix(es)?

The prefixes can be statically configured in the policy profile. Typically<= br> mobile networks are statically configured (but registered with the LMA) as<= br> we don't want the prefixes to disappear if the egress link goes down an= d
that will result in local communication between the hosts to break. So,
the prefixes are statically provisioned in the mobile network. But,
mobility support comes up only when there is active session with LMA
enabling the forwarding.

If the MAG knows the prefixes, it can indicate them in the DMNP option.
If the MAG does not know the prefixes, =A0it will carry a NULL value.
LMA assigns them based on what is in the BCE state.

This is consistent with how the home address (IPv4 HoA, HNP) options are carried in PMIP signaling messages.

Raj> =A0What does this mean: "Typically
mobile networks are statically configured (but registered with the LMA)....= "?

Also: "So,
the prefixes are statically provisioned in the mobile network."

Would be good if you can clarify since you have = a view or interpretation that I am not sure everyone is in sync with.

[Sri] I'm just saying, the subnets (DMNP's) are configured man= ually in the mobile network. But, those subnets belong to the LMA from rout= ing point of view. This is almost like a static IP configuration.

There is also the other approach, every thing happens dynamically, the= prefix is obtained from the LMA/MAG and then gets configured in the mobile= network.=A0

In most deployments, IMO, static configuration is preferred as they do= n't want the networks/prefixes to disappear, if the LMA is not reachabl= e and the PMIP tunnel goes down. There won't be IP mobility or external= reachability, but there will be internal node to node communication.

Regards

Sri

Raj> Well, ok= ay. I get that. But from reading the text in the I-D it is not very clear. = Would recommend reworking the text to explain the above.=A0

-Raj=A0

--
Basavaraj Patil

--001a11c32db60ba0fd04dd635445-- From cjbc@it.uc3m.es Thu May 23 11:11:26 2013 Return-Path: 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 D78FF21F869A for ; Thu, 23 May 2013 11:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CEtHenlHqfmy for ; Thu, 23 May 2013 11:11:05 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 100C621F8696 for ; Thu, 23 May 2013 10:54:56 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B5CE9894E03; Thu, 23 May 2013 19:54:55 +0200 (CEST) X-uc3m-safe: yes 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) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id A85B5891802; Thu, 23 May 2013 19:54:55 +0200 (CEST) Message-ID: <1369331695.4605.12.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj Patil Date: Thu, 23 May 2013 19:54:55 +0200 In-Reply-To: References: <1369062263.4503.40.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19888.000 X-TM-AS-Result: No--25.617-7.0-31-1 X-imss-scan-details: No--25.617-7.0-31-1 Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 18:11:27 -0000 Hi Raj, all, Some answers inline below. On Wed, 2013-05-22 at 14:40 -0500, Basavaraj Patil wrote: > Hi Carlos et al, > > > My comments inline: > > > > > On Mon, May 20, 2013 at 10:04 AM, Carlos Jesús Bernardos Cano > wrote: > Hi Raj, > > Some additional responses inline below (as Joy mentioned, we > believe > that everything is clearer in the new version, but just in > case). > > On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote: > > > > > > > > > > Questions: > > > > > > 1. In the terminology section: > > "The DMNP is an IPv4 or an IPv6 prefix delegated to a > mobile router > > and advertised in the mobile network." > > > > > > What is the mobile network being refered to in this > statement? > > Is it the PMIP6 domain itself? Or is it the network > that the > > mobile router is hosting? > > > [Carlos] It is the network that the mobile router is hosting. > > > Raj> Okay. > However the current statement in the I-D: > " > The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix > delegated to a mobile router and is hosted in the mobile network. > " > Would be better to say that this prefix is hosted by the PMIP6 > mobility agent, i.e LMA. > [Carlos] There are two considerations here: 1. The prefix is configured in the mobile network. RA's are sent in those networks. 2. The LMA advertises that prefix into IGP. The LMA is the routing anchor, but is not hosting those prefixes. Text below (from Section 5.2.3): o The local mobility anchor MUST advertise a connected route into the Routing Infrastructure for the IP prefixes delegated to all of the mobile routers that it is serving. This step essentially enables the local mobility anchor to be a routing anchor for those IP prefixes and be able to intercept IP packets sent to those mobile networks. > > > > > > > 2. In Sec 4.3.1: > > "It is possible that the delegated prefix(es) may > > have been assigned to the MAG by the LMA during this > procedure > > of > > PMIPv6 tunnel establishment. That is the MAG may > include one > > (or > > more) Delegated Mobile Network Prefix (DMNP) mobility > options > > which MUST be set to the unspecified IPv6 address > "::" in the > > PBU > > to request the delegated prefix(es). The LMA assigns > a new set > > of DMNP(s) in PBA message." > > > > > > Not sure what your assumptions are here. Why does the > LMA > > assign delegated prefix(es) during normal RFC5213 > PMIP6 tunnel > > establishment procedures? > > What would cause the MAG to include the DMNP option > in the PBU > > at this stage (Step 2) of the session? > > > [Carlos] We have clarified this in the new version. > > > Raj> Section 4.3.1 no longer exists. Would have been easier if the > revised section was pasted here :( [Carlos] Sorry about this, my fault. We reorganized the document for readability and so moved sections around. The MAG will include the DMNP option in the PBU, triggered by: 1) MN's policy profile 2) Receives a trigger from DHCP module This is covered in Section 5.1.2. > > > > > > > 3. In Sec 4.3.1: > > " The mobile router, acting as a "Requesting Router" as > described > > in [RFC3633], sends a DHCPv6 SOLICIT message > including one or > > more IA_PD option(s) to the mobile access gateway > (which has a > > "DHCPv6 Server" function) to acquire the delegated > prefix(es)." > > > > > > Is there an assumption that the MAG is also the > DHCPv6 server? > > The MAG could be a DHCP relay as well, right? > > > [Carlos] Right, two deployment models are considered: one in > which the > MAG acts a DHCPv6 Delegating Router (i.e., server) and another > in which > the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating > Router. > This has been further clarified in the new version. > > > Raj> Okay.. Good. > > > > > > > 4. In Sec 4.3.1, step 5: > > "The LMA must set > > up forwarding for the delegated prefixes as reachable > through > > the > > PMIPv6 tunnel." > > > > > > The LMA may or may not assign these delegated > prefixes. The MAG > > could be the one assigning the delegated prefixes as > per the > > description. Are those prefixes routable by the LMA? > > > [Carlos] Yes, the prefixes are routable by the LMA. > > > Raj> How?? Are those prefixes which the MAG delegates also anchored at > the LMA? [Carlos] This is covered in Section 5.2.3. Text below: 5.2.3: o The local mobility anchor MUST advertise a connected route into the Routing Infrastructure for the IP prefixes delegated to all of the mobile routers that it is serving. This step essentially enables the local mobility anchor to be a routing anchor for those IP prefixes and be able to intercept IP packets sent to those mobile networks. > > > > > > > 5. In Sec 4.4.1, step 4: > > "If the mobile access > > gateway does not know the delegated prefix(es), then > the > > delegated mobile network prefix in the DMNP > option(s) MUST be > > set to the unspecified IPv6 address "::", " > > > > > > How would the MAG know the delegated prefix(es)? Unless it > is > > just renewing the assigned prefix(es)? > > > [Carlos] This has been further revised and clarified in the > new version. > > > Raj> What is the new section in the document? Sec 4.4.1 is no longer > there. [Carlos] Again, sorry about this. This is also due to the reorganization of the document that we have done to improve readability. If the MAG has the list of delegated prefixes belonging to a session: - it includes the specific prefix values in the DMNP option If the MAG does not have the list of delegated prefixes belonging to a session: - it includes a value of 0::0 in the DMNP option > > > > > > 6. Is the assumption that the DHCP server functionality > resides either > > at the MAG or the LMA in this I-D? > > > [Carlos] Yes. It should be now clearer with the updates we > have done in > the text. > > > Raj> Okay. > > > > > > > 7. In Sec 6.2 you state: > > "In order to receive these packets, the > > local mobility anchor MUST be the topological anchor > of the MR's > > delegated mobile network prefix(es)." > > > > > > This should be made clear up front in order to avoid > confusion > > about how forwarding is accomplished. > > > > > > [Carlos] This should be now clear. > > > Raj> Can you point me to the new text that clarifies this? [Carlos] This is clarified in Section 5.2.3: o The local mobility anchor MUST advertise a connected route into the Routing Infrastructure for the IP prefixes delegated to all of the mobile routers that it is serving. This step essentially enables the local mobility anchor to be a routing anchor for those IP prefixes and be able to intercept IP packets sent to those mobile networks. > > -Raj > > > > Thanks for your comments! > > Carlos > > > > > > Editorial: > > > > > > s/Proxy Mobile IPv6 enables IP mobility for a host without > requiring > > its participation in any mobility signaling, being the > network > > responsible for managing IP mobility on behalf of the > host./ Proxy > > Mobile IPv6 enables IP mobility for a host without > requiring > > its participation in any mobility signaling. Mobility > elements in > > the network are responsible for managing IP mobility on > behalf of > > the host. > > > > > > s/However, > > Proxy Mobile IPv6 does not support assigning a prefix to > a router > > and > > managing its IP mobility./However, Proxy Mobile IPv6 > lacks the > > ability to assign a prefix to a router and manage its IP > > mobility. > > > > > > s/and be able to obtain IP mobility support for those IP > addresses./ > > and enable IP mobility support for the assigned IP > address or > > prefixes. > > > > > > s/However, > > this network-based mobility management support is > specific to an IP > > host and currently there is no such network-based > mobility > > management > > support for a mobile router with a cluster of IP hosts > behind > > it./However, > > the Proxy Mobile IPv6 based solution for network-based > mobility > > management is specific to IP hosts and does not provide > similar > > functionality for a mobile router with a cluster of IP > hosts behind > > it. > > > > > > -Raj > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > > > > -- > Basavaraj Patil From bpatil1@gmail.com Thu May 23 11:16:05 2013 Return-Path: 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 AE6F221F958B for ; Thu, 23 May 2013 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FGTlrp36nVQ8 for ; Thu, 23 May 2013 11:15:50 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAE21F87D2 for ; Thu, 23 May 2013 10:57:39 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n9so4841079oag.28 for ; Thu, 23 May 2013 10:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XVSCwCZ2nI27eAcY0i2KYkTKOSa3vlNoEAKtOg2DKMI=; b=HBqfZ6ORySUvFC57pjHh/oQ0ap9euC+qv7+ws1fkD3B0p3BP9FMmOCfK37OG+Zndt2 N0je958lZ4ZAq4WUEADdVkypU9Sb3pu5xoMuTKg6C14otzrHkDJyobrYQR1w/idzOwwq wgkNoQTI3T5FaKtFTAFn8lJcnaoGJG1MFzXC/3UyGZGAUFvHRGE/FobJYgZq8TYXnMz9 nLiF2+g5gC+1pcC4TQIY90w0STkHc5I4iHXMYgxd/R3UPYEYUZ4UUUEpztoqaNiC7kuG ywkAzeK3ggilw78SjTRUu411zNC1s617wbUt0PKW5IQqjusJUhDUfXa4wlsPSxrpu824 O7QA== MIME-Version: 1.0 X-Received: by 10.60.33.202 with SMTP id t10mr9197905oei.2.1369331859360; Thu, 23 May 2013 10:57:39 -0700 (PDT) Received: by 10.76.103.235 with HTTP; Thu, 23 May 2013 10:57:39 -0700 (PDT) In-Reply-To: <1369331695.4605.12.camel@acorde.it.uc3m.es> References: <1369062263.4503.40.camel@acorde.it.uc3m.es> <1369331695.4605.12.camel@acorde.it.uc3m.es> Date: Thu, 23 May 2013 12:57:39 -0500 Message-ID: From: Basavaraj Patil To: "cjbc@it.uc3m.es" Content-Type: multipart/alternative; boundary=089e013c66b40e950004dd666b5b Cc: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06 X-BeenThere: netext@ietf.org 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: Thu, 23 May 2013 18:16:05 -0000 --089e013c66b40e950004dd666b5b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Carlos. That helps. I am fine with the changes. Will initiate a WG LC on the I-D. -Raj On Thu, May 23, 2013 at 12:54 PM, Carlos Jes=FAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi Raj, all, > > Some answers inline below. > > On Wed, 2013-05-22 at 14:40 -0500, Basavaraj Patil wrote: > > Hi Carlos et al, > > > > > > My comments inline: > > > > > > > > > > On Mon, May 20, 2013 at 10:04 AM, Carlos Jes=FAs Bernardos Cano > > wrote: > > Hi Raj, > > > > Some additional responses inline below (as Joy mentioned, we > > believe > > that everything is clearer in the new version, but just in > > case). > > > > On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote: > > > > > > > > > > > > > > > Questions: > > > > > > > > > 1. In the terminology section: > > > "The DMNP is an IPv4 or an IPv6 prefix delegated to a > > mobile router > > > and advertised in the mobile network." > > > > > > > > > What is the mobile network being refered to in this > > statement? > > > Is it the PMIP6 domain itself? Or is it the network > > that the > > > mobile router is hosting? > > > > > > [Carlos] It is the network that the mobile router is hosting. > > > > > > Raj> Okay. > > However the current statement in the I-D: > > " > > The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix > > delegated to a mobile router and is hosted in the mobile network. > > " > > Would be better to say that this prefix is hosted by the PMIP6 > > mobility agent, i.e LMA. > > > [Carlos] There are two considerations here: > > 1. The prefix is configured in the mobile network. RA's are sent in > those networks. > 2. The LMA advertises that prefix into IGP. The LMA is the routing > anchor, but is not hosting those prefixes. Text below (from Section > 5.2.3): > > o The local mobility anchor MUST advertise a connected route into > the Routing Infrastructure for the IP prefixes delegated to all of > the mobile routers that it is serving. This step essentially > enables the local mobility anchor to be a routing anchor for those > IP prefixes and be able to intercept IP packets sent to those > mobile networks. > > > > > > > > > > > 2. In Sec 4.3.1: > > > "It is possible that the delegated prefix(es) may > > > have been assigned to the MAG by the LMA during this > > procedure > > > of > > > PMIPv6 tunnel establishment. That is the MAG may > > include one > > > (or > > > more) Delegated Mobile Network Prefix (DMNP) mobility > > options > > > which MUST be set to the unspecified IPv6 address > > "::" in the > > > PBU > > > to request the delegated prefix(es). The LMA assigns > > a new set > > > of DMNP(s) in PBA message." > > > > > > > > > Not sure what your assumptions are here. Why does the > > LMA > > > assign delegated prefix(es) during normal RFC5213 > > PMIP6 tunnel > > > establishment procedures? > > > What would cause the MAG to include the DMNP option > > in the PBU > > > at this stage (Step 2) of the session? > > > > > > [Carlos] We have clarified this in the new version. > > > > > > Raj> Section 4.3.1 no longer exists. Would have been easier if the > > revised section was pasted here :( > > [Carlos] Sorry about this, my fault. We reorganized the document for > readability and so moved sections around. The MAG will include the DMNP > option in the PBU, triggered by: > > 1) MN's policy profile > 2) Receives a trigger from DHCP module > > This is covered in Section 5.1.2. > > > > > > > > > > > > 3. In Sec 4.3.1: > > > " The mobile router, acting as a "Requesting Router" as > > described > > > in [RFC3633], sends a DHCPv6 SOLICIT message > > including one or > > > more IA_PD option(s) to the mobile access gateway > > (which has a > > > "DHCPv6 Server" function) to acquire the delegated > > prefix(es)." > > > > > > > > > Is there an assumption that the MAG is also the > > DHCPv6 server? > > > The MAG could be a DHCP relay as well, right? > > > > > > [Carlos] Right, two deployment models are considered: one in > > which the > > MAG acts a DHCPv6 Delegating Router (i.e., server) and another > > in which > > the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating > > Router. > > This has been further clarified in the new version. > > > > > > Raj> Okay.. Good. > > > > > > > > > > > 4. In Sec 4.3.1, step 5: > > > "The LMA must set > > > up forwarding for the delegated prefixes as reachable > > through > > > the > > > PMIPv6 tunnel." > > > > > > > > > The LMA may or may not assign these delegated > > prefixes. The MAG > > > could be the one assigning the delegated prefixes as > > per the > > > description. Are those prefixes routable by the LMA? > > > > > > [Carlos] Yes, the prefixes are routable by the LMA. > > > > > > Raj> How?? Are those prefixes which the MAG delegates also anchored at > > the LMA? > > [Carlos] This is covered in Section 5.2.3. Text below: > > 5.2.3: > o The local mobility anchor MUST advertise a connected route into > the Routing Infrastructure for the IP prefixes delegated to all of > the mobile routers that it is serving. This step essentially > enables the local mobility anchor to be a routing anchor for those > IP prefixes and be able to intercept IP packets sent to those > mobile networks. > > > > > > > > > > > > 5. In Sec 4.4.1, step 4: > > > "If the mobile access > > > gateway does not know the delegated prefix(es), then > > the > > > delegated mobile network prefix in the DMNP > > option(s) MUST be > > > set to the unspecified IPv6 address "::", " > > > > > > > > > How would the MAG know the delegated prefix(es)? Unless it > > is > > > just renewing the assigned prefix(es)? > > > > > > [Carlos] This has been further revised and clarified in the > > new version. > > > > > > Raj> What is the new section in the document? Sec 4.4.1 is no longer > > there. > > [Carlos] Again, sorry about this. This is also due to the reorganization > of the document that we have done to improve readability. > > If the MAG has the list of delegated prefixes belonging to a session: > - it includes the specific prefix values in the DMNP option > > If the MAG does not have the list of delegated prefixes belonging to a > session: > - it includes a value of 0::0 in the DMNP option > > > > > > > > > > > > > 6. Is the assumption that the DHCP server functionality > > resides either > > > at the MAG or the LMA in this I-D? > > > > > > [Carlos] Yes. It should be now clearer with the updates we > > have done in > > the text. > > > > > > Raj> Okay. > > > > > > > > > > > 7. In Sec 6.2 you state: > > > "In order to receive these packets, the > > > local mobility anchor MUST be the topological anchor > > of the MR's > > > delegated mobile network prefix(es)." > > > > > > > > > This should be made clear up front in order to avoid > > confusion > > > about how forwarding is accomplished. > > > > > > > > > > [Carlos] This should be now clear. > > > > > > Raj> Can you point me to the new text that clarifies this? > > [Carlos] This is clarified in Section 5.2.3: > > o The local mobility anchor MUST advertise a connected route into > the Routing Infrastructure for the IP prefixes delegated to all of > the mobile routers that it is serving. This step essentially > enables the local mobility anchor to be a routing anchor for those > IP prefixes and be able to intercept IP packets sent to those > mobile networks. > > > > > -Raj > > > > > > > Thanks for your comments! > > > > Carlos > > > > > > > > > Editorial: > > > > > > > > > s/Proxy Mobile IPv6 enables IP mobility for a host without > > requiring > > > its participation in any mobility signaling, being the > > network > > > responsible for managing IP mobility on behalf of the > > host./ Proxy > > > Mobile IPv6 enables IP mobility for a host without > > requiring > > > its participation in any mobility signaling. Mobility > > elements in > > > the network are responsible for managing IP mobility on > > behalf of > > > the host. > > > > > > > > > s/However, > > > Proxy Mobile IPv6 does not support assigning a prefix to > > a router > > > and > > > managing its IP mobility./However, Proxy Mobile IPv6 > > lacks the > > > ability to assign a prefix to a router and manage its IP > > > mobility. > > > > > > > > > s/and be able to obtain IP mobility support for those IP > > addresses./ > > > and enable IP mobility support for the assigned IP > > address or > > > prefixes. > > > > > > > > > s/However, > > > this network-based mobility management support is > > specific to an IP > > > host and currently there is no such network-based > > mobility > > > management > > > support for a mobile router with a cluster of IP hosts > > behind > > > it./However, > > > the Proxy Mobile IPv6 based solution for network-based > > mobility > > > management is specific to IP hosts and does not provide > > similar > > > functionality for a mobile router with a cluster of IP > > hosts behind > > > it. > > > > > > > > > -Raj > > > > > > > > > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > > > > -- > > Basavaraj Patil > > > --=20 Basavaraj Patil --089e013c66b40e950004dd666b5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Carlos. That helps.=A0

I am fine with the= changes. Will initiate a WG LC on the I-D.

-Raj

On Thu, May 23, 2013 at 12:54 PM, Carlos Jes=FAs Bernardos Cano <cjbc@it.u= c3m.es> wrote:

Hi Raj, all,

Some answers inline below.

On Wed, 2013-05-22 at 14:40 -0500, Basavaraj Patil wrote:
> Hi Carlos et al,
>
>
> My comments inline:
>
>
>
>
> On Mon, May 20, 2013 at 10:04 AM, Carlos Jes=FAs Bernardos Cano
> <cjbc@it.uc3m.es> wrote:<= br> > =A0 =A0 =A0 =A0 Hi Raj,
>
> =A0 =A0 =A0 =A0 Some additional responses inline below (as Joy mention= ed, we
> =A0 =A0 =A0 =A0 believe
> =A0 =A0 =A0 =A0 that everything is clearer in the new version, but jus= t in
> =A0 =A0 =A0 =A0 case).
>
> =A0 =A0 =A0 =A0 On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wro= te:
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > Questions:
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 1. In the terminology section:
> =A0 =A0 =A0 =A0 > =A0 =A0"The DMNP is an IPv4 or an IPv6 prefi= x delegated to a
> =A0 =A0 =A0 =A0 mobile router
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 and advertised in the mobile network.= "
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 What is the mobile network being refe= red to in this
> =A0 =A0 =A0 =A0 statement?
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 Is it the PMIP6 domain itself? Or is = it the network
> =A0 =A0 =A0 =A0 that the
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 mobile router is hosting?
>
>
> =A0 =A0 =A0 =A0 [Carlos] It is the network that the mobile router is h= osting.
>
>
> Raj> Okay.
> However the current statement in the I-D:
> "
> The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix
> delegated to a mobile router and is hosted in the mobile network.
> "
> Would be better to say that this prefix is hosted by the PMIP6
> mobility agent, i.e LMA.
>

[Carlos] There are two considerations here:

1. The prefix is configured in the mobile network. RA's are sent in
those networks.
2. The LMA advertises that prefix into IGP. The LMA is the routing
anchor, but is not hosting those prefixes. Text below (from Section
5.2.3):

=A0 =A0o =A0The local mobility anchor MUST advertise a connected route into=
=A0 =A0 =A0 the Routing Infrastructure for the IP prefixes delegated to all= of
=A0 =A0 =A0 the mobile routers that it is serving. =A0This step essentially=
=A0 =A0 =A0 enables the local mobility anchor to be a routing anchor for th= ose
=A0 =A0 =A0 IP prefixes and be able to intercept IP packets sent to those =A0 =A0 =A0 mobile networks.

>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 2. In Sec 4.3.1:
> =A0 =A0 =A0 =A0 > =A0 =A0"It is possible that the delegated pr= efix(es) may
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0have been assigned to the MAG by t= he LMA during this
> =A0 =A0 =A0 =A0 procedure
> =A0 =A0 =A0 =A0 > of
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0PMIPv6 tunnel establishment. =A0Th= at is the MAG may
> =A0 =A0 =A0 =A0 include one
> =A0 =A0 =A0 =A0 > (or
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0more) Delegated Mobile Network Pre= fix (DMNP) mobility
> =A0 =A0 =A0 =A0 options
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0which MUST be set to the unspecifi= ed IPv6 address
> =A0 =A0 =A0 =A0 "::" in the
> =A0 =A0 =A0 =A0 > PBU
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0to request the delegated prefix(es= ). =A0The LMA assigns
> =A0 =A0 =A0 =A0 a new set
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0of DMNP(s) in PBA message." > =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0Not sure what your assumptions are= here. Why does the
> =A0 =A0 =A0 =A0 LMA
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0assign delegated prefix(es) during= normal RFC5213
> =A0 =A0 =A0 =A0 PMIP6 tunnel
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0establishment procedures?
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0What would cause the MAG to includ= e the DMNP option
> =A0 =A0 =A0 =A0 in the PBU
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0at this stage (Step 2) of the sess= ion?
>
>
> =A0 =A0 =A0 =A0 [Carlos] We have clarified this in the new version. >
>
> Raj> Section 4.3.1 no longer exists. Would have been easier if the<= br> > revised section was pasted here :(

[Carlos] Sorry about this, my fault. We reorganized the documen= t for
readability and so moved sections around. The MAG will include the DMNP
option in the PBU, triggered by:

1) MN's policy profile
2) Receives a trigger from DHCP module

This is covered in Section 5.1.2.

>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 3. In Sec 4.3.1:
> =A0 =A0 =A0 =A0 > =A0 =A0" The mobile router, acting as a &quo= t;Requesting Router" as
> =A0 =A0 =A0 =A0 described
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0in [RFC3633], sends a DHCPv6 SOLIC= IT message
> =A0 =A0 =A0 =A0 including one or
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0more IA_PD option(s) to the mobile= access gateway
> =A0 =A0 =A0 =A0 (which has a
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0"DHCPv6 Server" function= ) to acquire the delegated
> =A0 =A0 =A0 =A0 prefix(es)."
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0Is there an assumption that the MA= G is also the
> =A0 =A0 =A0 =A0 DHCPv6 server?
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0The MAG could be a DHCP relay as w= ell, right?
>
>
> =A0 =A0 =A0 =A0 [Carlos] Right, two deployment models are considered: = one in
> =A0 =A0 =A0 =A0 which the
> =A0 =A0 =A0 =A0 MAG acts a DHCPv6 Delegating Router (i.e., server) and= another
> =A0 =A0 =A0 =A0 in which
> =A0 =A0 =A0 =A0 the MAG acts as DHCPv6 Relay Agent and the LMA as Dele= gating
> =A0 =A0 =A0 =A0 Router.
> =A0 =A0 =A0 =A0 This has been further clarified in the new version. >
>
> Raj> Okay.. Good.
>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 4. In Sec 4.3.1, step 5:
> =A0 =A0 =A0 =A0 > =A0 =A0"The LMA must set
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0up forwarding for the delegated pr= efixes as reachable
> =A0 =A0 =A0 =A0 through
> =A0 =A0 =A0 =A0 > the
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0PMIPv6 tunnel."
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0The LMA may or may not assign thes= e delegated
> =A0 =A0 =A0 =A0 prefixes. The MAG
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0could be the one assigning the del= egated prefixes as
> =A0 =A0 =A0 =A0 per the
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0description. Are those prefixes ro= utable by the LMA?
>
>
> =A0 =A0 =A0 =A0 [Carlos] Yes, the prefixes are routable by the LMA. >
>
> Raj> How?? Are those prefixes which the MAG delegates also anchored= at
> the LMA?

[Carlos] This is covered in Section 5.2.3. Text below:

5.2.3:
=A0 =A0o =A0The local mobility anchor MUST advertise a connected route into=
=A0 =A0 =A0 the Routing Infrastructure for the IP prefixes delegated to all= of
=A0 =A0 =A0 the mobile routers that it is serving. =A0This step essentially=
=A0 =A0 =A0 enables the local mobility anchor to be a routing anchor for th= ose
=A0 =A0 =A0 IP prefixes and be able to intercept IP packets sent to those =A0 =A0 =A0 mobile networks.

>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 5. In Sec 4.4.1, step 4:
> =A0 =A0 =A0 =A0 > =A0 =A0"If the mobile access
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 gateway does not know the delegat= ed prefix(es), then
> =A0 =A0 =A0 =A0 the
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 delegated mobile network prefix i= n the DMNP
> =A0 =A0 =A0 =A0 option(s) MUST be
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 set to the unspecified IPv6 addre= ss "::", "
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > How would the MAG know the delegated prefix(es)? = Unless it
> =A0 =A0 =A0 =A0 is
> =A0 =A0 =A0 =A0 > just renewing the assigned prefix(es)?
>
>
> =A0 =A0 =A0 =A0 [Carlos] This has been further revised and clarified i= n the
> =A0 =A0 =A0 =A0 new version.
>
>
> Raj> What is the new section in the document? Sec 4.4.1 is no longe= r
> there.

[Carlos] Again, sorry about this. This is also due to the reorganizat= ion
of the document that we have done to improve readability.

If the MAG has the list of delegated prefixes belonging to a session:
- it includes the specific prefix values in the DMNP option

If the MAG does not have the list of delegated prefixes belonging to a
session:
- it includes a value of 0::0 in the DMNP option

> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 6. Is the assumption that the DHCP server functio= nality
> =A0 =A0 =A0 =A0 resides either
> =A0 =A0 =A0 =A0 > =A0 =A0at the MAG or the LMA in this I-D?
>
>
> =A0 =A0 =A0 =A0 [Carlos] Yes. It should be now clearer with the update= s we
> =A0 =A0 =A0 =A0 have done in
> =A0 =A0 =A0 =A0 the text.
>
>
> Raj> Okay.
>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > 7. In Sec 6.2 you state:
> =A0 =A0 =A0 =A0 > =A0 =A0"In order to receive these packets, t= he
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 local mobility anchor MUST be the top= ological anchor
> =A0 =A0 =A0 =A0 of the MR's
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 delegated mobile network prefix(es).&= quot;
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 This should be made clear up front in= order to avoid
> =A0 =A0 =A0 =A0 confusion
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 about how forwarding is accomplished.=
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
>
> =A0 =A0 =A0 =A0 [Carlos] This should be now clear.
>
>
> Raj> Can you point me to the new text that clarifies this?

[Carlos] This is clarified in Section 5.2.3:

=A0 =A0o =A0The local mobility anchor MUST advertise a connected route into=
=A0 =A0 =A0 the Routing Infrastructure for the IP prefixes delegated to all= of
=A0 =A0 =A0 the mobile routers that it is serving. =A0This step essentially=
=A0 =A0 =A0 enables the local mobility anchor to be a routing anchor for th= ose
=A0 =A0 =A0 IP prefixes and be able to intercept IP packets sent to those =A0 =A0 =A0 mobile networks.

>
> -Raj
>
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 Thanks for your comments!
>
> =A0 =A0 =A0 =A0 Carlos
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > Editorial:
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > s/Proxy Mobile IPv6 enables IP mobility for a hos= t without
> =A0 =A0 =A0 =A0 requiring
> =A0 =A0 =A0 =A0 > =A0 =A0its participation in any mobility signalin= g, being the
> =A0 =A0 =A0 =A0 network
> =A0 =A0 =A0 =A0 > =A0 =A0responsible for managing IP mobility on be= half of the
> =A0 =A0 =A0 =A0 host./ Proxy
> =A0 =A0 =A0 =A0 > =A0 =A0Mobile IPv6 enables IP mobility for a host= without
> =A0 =A0 =A0 =A0 requiring
> =A0 =A0 =A0 =A0 > =A0 =A0its participation in any mobility signalin= g. Mobility
> =A0 =A0 =A0 =A0 elements in
> =A0 =A0 =A0 =A0 > =A0 =A0the network are responsible for managing I= P mobility on
> =A0 =A0 =A0 =A0 behalf of
> =A0 =A0 =A0 =A0 > =A0 =A0the host.
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > s/However,
> =A0 =A0 =A0 =A0 > =A0 =A0Proxy Mobile IPv6 does not support assigni= ng a prefix to
> =A0 =A0 =A0 =A0 a router
> =A0 =A0 =A0 =A0 > and
> =A0 =A0 =A0 =A0 > =A0 =A0managing its IP mobility./However, Proxy M= obile IPv6
> =A0 =A0 =A0 =A0 lacks the
> =A0 =A0 =A0 =A0 > =A0 =A0ability to assign a prefix to a router and= =A0manage its IP
> =A0 =A0 =A0 =A0 > =A0 =A0mobility.
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > s/and be able to obtain IP mobility support for t= hose IP
> =A0 =A0 =A0 =A0 addresses./
> =A0 =A0 =A0 =A0 > =A0 =A0and enable IP mobility support for the ass= igned IP
> =A0 =A0 =A0 =A0 address or
> =A0 =A0 =A0 =A0 > =A0 =A0prefixes.
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > s/However,
> =A0 =A0 =A0 =A0 > =A0 =A0this network-based mobility management sup= port is
> =A0 =A0 =A0 =A0 specific to an IP
> =A0 =A0 =A0 =A0 > =A0 =A0host and currently there is no such networ= k-based
> =A0 =A0 =A0 =A0 mobility
> =A0 =A0 =A0 =A0 > management
> =A0 =A0 =A0 =A0 > =A0 =A0support for a mobile router with a cluster= of IP hosts
> =A0 =A0 =A0 =A0 behind
> =A0 =A0 =A0 =A0 > it./However,
> =A0 =A0 =A0 =A0 > =A0 =A0the Proxy Mobile IPv6 based solution for = =A0network-based
> =A0 =A0 =A0 =A0 mobility
> =A0 =A0 =A0 =A0 > =A0 =A0management is specific to IP hosts and doe= s not provide
> =A0 =A0 =A0 =A0 similar
> =A0 =A0 =A0 =A0 > =A0 =A0functionality for a mobile router with a c= luster of IP
> =A0 =A0 =A0 =A0 hosts behind
> =A0 =A0 =A0 =A0 > =A0 =A0it.
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > -Raj
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
>
> =A0 =A0 =A0 =A0 > _______________________________________________ > =A0 =A0 =A0 =A0 > netext mailing list
> =A0 =A0 =A0 =A0 > netext@ietf.or= g
> =A0 =A0 =A0 =A0 > https://www.ietf.org/mailman/listinfo/netext<= br> >
>
> =A0 =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 =A0 netext mailing list
> =A0 =A0 =A0 =A0 netext@ietf.org=
> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/netext
>
>
>
>
>
> --
> Basavaraj Patil

--
= Basavaraj Patil

--089e013c66b40e950004dd666b5b-- From bpatil1@gmail.com Thu May 23 14:43:08 2013 Return-Path: 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 EBB5D21F987B for ; Thu, 23 May 2013 14:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 JhJ7HC7WLYYv for ; Thu, 23 May 2013 14:42:58 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE121F988B for ; Thu, 23 May 2013 13:56:26 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id eh20so4666212obb.32 for ; Thu, 23 May 2013 13:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yGlJp21V7/lAPGfUHLpNGv2dzbTB1NsdYMDMx3HlMgE=; b=ljFPibZrQtV1UscfH1GH5pL0Q1AGkaS+Nr4aPOFBhr7rvESp3XbWA4DDmuQzJk8Qvh 8C00iX43Kfhkgvpbl1y84ehozHt/53ZglNAmqzmD3mWdLyXZouZAwkajPkSgnx9J9TsF 1htoQLcdSgFFKz177jle77v3rN49nri807ZY6REyYHLX0pjtwDJoPw8Nijr7181EZ8Kl f+/HLLQsUFu9gmJYKxkLfL+DB9QW4V2v3sBjG3UdOjUpFg7i4LnYK6qUOuv/3tdMdobL BgFbTxTPA1CXkj2aRkcgE/8XfFb36qTtKBO1ojJC539d1skgh0svhDvj2pnkJu5p5pDj 4hCQ== MIME-Version: 1.0 X-Received: by 10.60.40.36 with SMTP id u4mr9611531oek.93.1369342586085; Thu, 23 May 2013 13:56:26 -0700 (PDT) Received: by 10.76.103.235 with HTTP; Thu, 23 May 2013 13:56:26 -0700 (PDT) Date: Thu, 23 May 2013 15:56:26 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" , "netext-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=e89a8f921a066bb83c04dd68ea2b Subject: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-netext-pd-pmip X-BeenThere: netext@ietf.org 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: Thu, 23 May 2013 21:43:08 -0000 --e89a8f921a066bb83c04dd68ea2b Content-Type: text/plain; charset=ISO-8859-1 Hello, Please consider this as the start of the working group last call for the I-D: Prefix Delegation Support for Proxy Mobile IPv6 . This I-D is intended to be progressed on the standards track. Please review the I-D and post your comments on the mailing list. The WGLC will end on June 7th, 2013. I would again encourage WG members to review the document and provide feedback at this stage of the process itself. -Chairs -- Basavaraj Patil --e89a8f921a066bb83c04dd68ea2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

Please= consider this as the start of the working group last call for

th= e I-D:=A0

Prefix Delegation Support for Proxy Mobile IPv6

<draft-ietf-netext-pd-pmip-08>.

This I-D is = intended to be progressed on the standards track.=A0

Please review the I-D and post your comments on the mailing list.

The WGLC will end on June 7th, 2013.

I would = again encourage WG members to review the document and provide

fee= dback at this stage of the process itself.

-Chairs=

--
Basavaraj Patil

--e89a8f921a066bb83c04dd68ea2b-- From cjbc@it.uc3m.es Tue May 28 06:24:08 2013 Return-Path: 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 36AFF21F9709 for ; Tue, 28 May 2013 06:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CjAuB1nJhQrz for ; Tue, 28 May 2013 06:24:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5678E21F9701 for ; Tue, 28 May 2013 06:23:59 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 10AEC86A6E2; Tue, 28 May 2013 15:23:56 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [172.24.10.8] (public.eurecom.fr [193.55.113.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id D7E3D86A017; Tue, 28 May 2013 15:23:55 +0200 (CEST) Message-ID: <1369747435.4365.13.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj Patil Date: Tue, 28 May 2013 15:23:55 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19898.007 X-TM-AS-Result: No--21.368-7.0-31-1 X-imss-scan-details: No--21.368-7.0-31-1 Cc: "netext@ietf.org" Subject: Re: [netext] WGLC: I-D draft-ietf-netext-update-notifications 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:24:08 -0000 Hi, I've read the document and I support moving it forward. I just have a very minor comment: Figure 1 shows the re-registration use case in which the notification message is acked (message 6), while in the text of Section 5.1 it is recommended not to set the flag A in the Update Notification message (and therefore, not to send an acknowledgement message). Thanks, Carlos On Fri, 2013-05-17 at 11:49 -0500, Basavaraj Patil wrote: > > > The Netext working group I-D: Update Notifications for Proxy Mobile > IPv6 has been revised > following the chair review. > > > This note is the start of the working group last call for the Update > Notifications for PMIPv6 I-D. Please review and post your comments to > the list. > > > The working group last call will end on June 1st, 2013. > > > I-D URL: > http://www.ietf.org/id/draft-ietf-netext-update-notifications-04.txt > > > -Chairs > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From John.Kaippallimalil@huawei.com Tue May 28 12:40:22 2013 Return-Path: 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 2067211E80F6 for ; Tue, 28 May 2013 12:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PZdqn0YfK5aM for ; Tue, 28 May 2013 12:40:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C83E311E8101 for ; Tue, 28 May 2013 12:40:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATG49546; Tue, 28 May 2013 19:40:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 20:39:43 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 20:40:11 +0100 Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.244]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Tue, 28 May 2013 12:40:05 -0700 From: John Kaippallimalil To: Basavaraj Patil , "netext@ietf.org" , "draft-ietf-netext-pd-pmip@tools.ietf.org" , "netext-chairs@tools.ietf.org" Thread-Topic: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-netext-pd-pmip Thread-Index: AQHOV/6XVhP2BDpcIEG0El6fycjEh5kbA4Pw Date: Tue, 28 May 2013 19:40:03 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D38AF@dfweml511-mbb.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "kmjohn@yahoo.com" Subject: Re: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-netext-pd-pmip X-BeenThere: netext@ietf.org 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, 28 May 2013 19:40:22 -0000 Hi,=20 I've been following draft-ietf-netext-pd-pmip and like the changes made in = the last revision (08). I support the draft moving forward. A couple of minor comments: In chapter 1 (introduction), would it be possible to clarify somewhere that= as the MR moves, the=20 LFN (Locally Fixed Node) does not need to know/detect when the MR has moved= to a new MAG. Second - editorial: a few places in the draft have, "an handoff". Perhaps that could be revised to 'a handoff'.=20 John > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Basavaraj Patil > Sent: Thursday, May 23, 2013 3:56 PM > To: netext@ietf.org; draft-ietf-netext-pd-pmip@tools.ietf.org; netext-cha= irs@tools.ietf.org > Subject: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-= netext-pd-pmip > > > Hello, > > Please consider this as the start of the working group last call for > the I-D:=A0 > Prefix Delegation Support for Proxy Mobile IPv6 > . > > This I-D is intended to be progressed on the standards track.=A0 > > Please review the I-D and post your comments on the mailing list. > The WGLC will end on June 7th, 2013. > > I would again encourage WG members to review the document and provide > feedback at this stage of the process itself. > > -Chairs > > --=20 > Basavaraj Patil=20 From cjbc@it.uc3m.es Wed May 29 00:34:31 2013 Return-Path: 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 4749121F8F12 for ; Wed, 29 May 2013 00:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 EQtJOvG42nmb for ; Wed, 29 May 2013 00:34:19 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD321F8F4D for ; Wed, 29 May 2013 00:34:18 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9EF53FA5067; Wed, 29 May 2013 09:34:13 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [172.24.10.8] (public.eurecom.fr [193.55.113.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 44EE59D439E; Wed, 29 May 2013 09:34:13 +0200 (CEST) Message-ID: <1369812852.4662.11.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: John Kaippallimalil Date: Wed, 29 May 2013 09:34:12 +0200 In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D38AF@dfweml511-mbb.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171D38AF@dfweml511-mbb.china.huawei.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19900.004 X-TM-AS-Result: No--15.650-7.0-31-1 X-imss-scan-details: No--15.650-7.0-31-1 Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , Basavaraj Patil , "draft-ietf-netext-pd-pmip@tools.ietf.org" , "kmjohn@yahoo.com" Subject: Re: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-netext-pd-pmip 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:34:31 -0000 Hi John, Thanks a lot for your comments and suggestions. We'll apply them in the next revision of the draft. Carlos On Tue, 2013-05-28 at 19:40 +0000, John Kaippallimalil wrote: > Hi, > > I've been following draft-ietf-netext-pd-pmip and like the changes made in the last revision (08). > I support the draft moving forward. > > A couple of minor comments: > In chapter 1 (introduction), would it be possible to clarify somewhere that as the MR moves, the > LFN (Locally Fixed Node) does not need to know/detect when the MR has moved to a new MAG. > > Second - editorial: a few places in the draft have, "an handoff". > Perhaps that could be revised to 'a handoff'. > > John > > > > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj Patil > > Sent: Thursday, May 23, 2013 3:56 PM > > To: netext@ietf.org; draft-ietf-netext-pd-pmip@tools.ietf.org; netext-chairs@tools.ietf.org > > Subject: [netext] WGLC: Prefix delegation support for PMIP6 - draft-ietf-netext-pd-pmip > > > > > > Hello, > > > > Please consider this as the start of the working group last call for > > the I-D: > > Prefix Delegation Support for Proxy Mobile IPv6 > > . > > > > This I-D is intended to be progressed on the standards track. > > > > Please review the I-D and post your comments on the mailing list. > > The WGLC will end on June 7th, 2013. > > > > I would again encourage WG members to review the document and provide > > feedback at this stage of the process itself. > > > > -Chairs > > > > -- > > Basavaraj Patil