From pierrick.seite@orange.com Wed Feb 1 04:09:37 2012 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 E298E21F85F7 for ; Wed, 1 Feb 2012 04:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nofM2CKC7qZh for ; Wed, 1 Feb 2012 04:09:36 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 29A7421F8513 for ; Wed, 1 Feb 2012 04:09:36 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B9652DE4001; Wed, 1 Feb 2012 13:11:02 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id AB6C8A441C6; Wed, 1 Feb 2012 13:11:02 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 13:09:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2012 13:09:32 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462022B3275@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3wARCdkwA== References: <1FCAE7B6027FE3489B8497A060C704C4443BD93B1B@EUSAACMS0714.eamcs.ericsson.se> From: To: , X-OriginalArrivalTime: 01 Feb 2012 12:09:34.0743 (UTC) FILETIME=[5C917270:01CCE0DA] Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.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: Wed, 01 Feb 2012 12:09:38 -0000 Hi, Please find below my review of draft-gundavelli-netext-pmipv6-sipto-option-01: This document is in good shape and my comments are mainly editorial. My main concern is that the introduction is focusing too much on the 3GPP S2a use-case while the offload option could be useful in other type of architectures. With the current text, the reader may think that the offload option has been designed only for 3GPP/EPC. So, at least the document should avoid using 3GPP specific terminology such as S2a and SIPTO. But, what about this rewording for the intro: ------ OLD TEXT ------ Mobile Operators are expanding their network coverage by integrating various access technology domains into a common IP mobile core. For providing IP mobility support to a mobile node irrespective of the access network to which it is attached, the 3GPP S2/a Proxy Mobile IPv6 [TS23402] interface, specified by the 3GPP system architecture, is providing the needed protocol glue. When this protocol interface based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is topologically anchored on the local mobility anchor [RFC5213] in the home network. The mobile node's IP traffic is always tunneled back from the mobile access gateway [RFC5213] in the access network to the local mobility anchor in the home network. ---- NEW TEXT ---- In current IP mobility architecture, the mobile node is topologically anchored on the mobility anchor in the home network. As a consequence, the mobile node's IP traffic is always tunneled back to the mobility anchor in the home network. However, some of the traffic does need mobility support and, so, does not need to be anchored. Actually, in this situation, routing can be easily optimized when using Proxy Mobile IPv6 [RFC5213]: the mobile access gateway could forward this traffic to the local Internet peering point instead of tunneling back to the local mobility anchor. The 3GPP/Wi-Fi offloading use-case is a concrete example of such an optimization. Indeed, mobile Operators are expanding their network coverage by integrating various access technology domains into a common IP mobile core. For providing IP mobility support to a mobile node irrespective of the access network to which it is attached, a Proxy Mobile IPv6 interface, specified by the 3GPP system architecture, is providing the needed protocol glue [TS23402]. =20 Other comments on the introduction: ---- OLD TEXT ------------ some of the non-essential traffic=20 -----NEW TEXT -------- some of the traffic Note: non-essential traffic sounds pejorative (for an conscientious operator, there is no non-essential traffic :-)) while the goal is to distinguish traffic which need mobility support from traffic which does not... accessing mobile operator services (as depicted on figure 1) is another use-case for PMIP but it is a specific usage for 3GPP/Wi-Fi interworking, so I suggest to not refer to this use-case and focus on mobility; so I've modified fig.1 (see below). 2.2 Terminology I suggest to remove SIPTO acronym which a 3GPP terminology (it gives a 3GPP coloring to the document and it should be avoided IMHO). Moreover SIPTO is not used in the rest of the document. 3. Solution Overview: ---- OLD TEXT ------------ The following illustrates the scenario where the mobile access gateway in an access network having the ability to offload some of the IPv4 traffic flows, based on the traffic selectors it received from the local mobility anchor in the home network. -----NEW TEXT -------- The following illustrates the scenario where the mobile access gateway has the ability to offload some of the IPv4 traffic flows, based on the traffic selectors it received from the local mobility anchor in the home network. ----- NEW PICTURE for figure 1 -------- _----_ _( )_ ( Internet ) =20 (_ _) =20 '----' =20 | +-----------------+ (IPv4 Traffic Offload Point | Services with | =20 at access edge gateway for | mobility support| offloaded traffic +-----------------+ Ex: HTTP Traffic Offloaded) | | | ...........................................|........... | . | +---+ . | |NAT| . | +---+ . | | _----_ | +-----+ _( )_ +-----+ [MN]----| MAG |=3D=3D=3D=3D=3D=3D( IP )=3D=3D=3D=3D=3D=3D| LMA = |-- Internet +-----+ (_ _) +-----+ '----' ( . . . [Access Network] . [Home Network] ...................................................... 3.1 LMA considerations ------ OLD TEXT ------- The following considerations apply to the local mobility anchor and the mobile access gateway. ------- NEW TEXT --------- The following considerations apply to the local mobility anchor. Inconsistency in Figure 2: There are 6 operations in the sequence chart and 7 bullets: "7. Forwarding rule - Tunnel home/offload" is not represented in the message flow. Moreover I think the DHCP OFFER/REQUEST and ACK messages should come right after step #5. It'd lead to the following picture: MN MAG(NAT) LMA |------>| | 1. Mobile Node Attach | |------->| 2. Proxy Binding Update | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) | |=3D=3D=3D=3D=3D=3D=3D=3D| 4. Tunnel/Route Setup | + | 5. Installing the traffic offload rules |<----->| | 6. DHCP OFFER/REQUEST/ACK exchange |------>| | 7. IPv4 packet from mobile node | + | 8. Forwarding rule - Tunnel home/offload | | | ------ OLD TEXT ------- If the received Proxy Binding Update includes the IP Traffic Offload Selector Option Section 4, but if the configuration variable, EnableIPTrafficOffloadSupport on the local mobility anchor is set to a value of (0), then the local mobility anchor MUST ignore the IP Traffic Offload Selector Option and process the rest of the packet. ------- NEW TEXT --------- If the received Proxy Binding Update includes the IP Traffic Offload Selector Option Section 4, but if the configuration variable, EnableIPTrafficOffloadSupport (Section 6) on the local mobility anchor is set to a value of (0), then the local mobility anchor MUST ignore the IP Traffic Offload Selector Option and process the rest of the packet as per [RFC5213]. ------ OLD TEXT ------- If the received Proxy Binding Update includes the IP Traffic Offload Selector Option Section 4, and if the configuration variable, EnableIPTrafficOffloadSupport on the local mobility anchor is set to a value of (1) , then the local mobility anchor can construct the traffic selectors based on the offload policy and deliver those selectors in the Proxy Binding Acknowledgement message using the IP Traffic Offload Selector Option. ------- NEW TEXT --------- If the received Proxy Binding Update includes the IP Traffic Offload Selector Option (Section 4), and if the configuration variable, EnableIPTrafficOffloadSupport (Section 6) on the local mobility anchor is set to a value of (1) , then the local mobility anchor can construct the traffic selectors based on the offload policy=20 and deliver those selectors in the Proxy Binding Acknowledgement message using the IP Traffic Offload Selector Option. How to provision offload policy on the local mobility anchor is out of the scope of that document. What about adding the following LMA operation?: If the received Proxy Binding Update does not include the IP Traffic Offload Selector Option (Section 4), and if the configuration variable, EnableIPTrafficOffloadSupport (Section 6) on the local mobility anchor is set to a value of (1), then the local mobility anchor SHOULD not include the IP Traffic Offload Selector Option in the Proxy Binding Acknowledgement. 3.2 MAG considerations Second bullet: replace "mobility access gateway" by "mobile access gateway"=20 --- OLD TEXT ---- The mobility access upon accepting the Proxy Binding Acknowledgement message MUST NOT enable any offload policy for that mobility session. --- NEW TEXT ---- The mobile access gateway upon accepting the Proxy Binding Acknowledgement message MUST NOT enable any offload policy for that mobility session. Is the following operation covered (Though, I'm not sure it does make sense) ? : If there is IP Traffic Offload Selector Option without selector in the corresponding Proxy Binding Acknowledgement message, the mobile access gateway SHOULD apply its policy. 4. IP Traffic Offload Selector Option For a better readability: insert carriage return after "Reserverd", "IP Traffic Offload Mode Flag", "TS Format" and "TS Selector". ---- OLD TEXT ------ If the (M) flag value is set to a value of (0), it is an indication that the identified IP flow(s) needs to be offloaded at the mobile access gateway and all other IP flows associated with that mobility session needs to be tunneled to the local mobility anchor. ---- NEW TEXT --------- If the (M) flag value is set to a value of (0), it is an indication that the identified IP flow(s) must be offloaded at the mobile access gateway and all other IP flows associated with that mobility session need to be tunneled to the local mobility anchor. ---- OLD TEXT ------ TS Format =20 An 8-bit unsigned integer indicating the Traffic Selector Format. The value of "0" is reserved and is used when there are no selectors to carry, relevant when the option is used as a capability indicator. The value of (1) is assigned for IPv4 Binary Traffic Selector [RFC6088]. ---- NEW TEXT --------- TS Format =20 An 8-bit unsigned integer indicating the Traffic Selector Format. The value of "0" is reserved and is used when there are no selectors to carry. In this case, the option is used only as a capability indicator. When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of [RFC6088]. ---- OLD TEXT ------ TS Selector =20 A variable-length opaque field for including the traffic specification identified by the TS format field. When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of [RFC6088]. ---- NEW TEXT --------- TS Selector =20 A variable-length opaque field for including the traffic specification identified by the TS format field. [the rest is already in description of TS format] 6. Protocol Configuration Variables --- OLD TEXT ---- it MUST include the IP Traffic Offload Selector option in the Proxy Binding Update messages and offload the negotiated IP flows to the access network. ---- NEW TEXT ---- it MUST include the IP Traffic Offload Selector option in the Proxy Binding Update messages and offload the negotiated IP flows to the nearest Internet peering point. 7. Security Considerations Just for discussion: Allowing the MAG to provide its policy may induce a security risk: IMU, the MAG is a more vulnerable than the LMA. For instance, if the MAG is in a residential gateway, there is a risk for that MAG to be corrupted. If so, the MAG may provide corrupted offloading policy to the LMA which has no way to check the policy. Of course this is out of scope of securing PMIP signaling but maybe we could stress the requirement for a secured policy provisioning mechanism... Hope that helps, BR, Pierrick From sgundave@cisco.com Wed Feb 1 08:37:15 2012 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 7315821F8C7E for ; Wed, 1 Feb 2012 08:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 t9e2xnBJtCYb for ; Wed, 1 Feb 2012 08:37:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3100A21F8C7A for ; Wed, 1 Feb 2012 08:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=14962; q=dns/txt; s=iport; t=1328114234; x=1329323834; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ZMTUOhu7JrBr1sK2fatRAxLNqqQl96QbggLFzkZUDrs=; b=kjtAo9oCwVXraADSwM3GYJvV8G4qbBbgRCOJq3QGa1HbdOGOftKwPflp CrM6namZPG2l6H6LRMJmuAHUX0JjJPnv4rq2zoF6p/mmtgO0VUZk/j1LK rMiIoyQDUBbFr7cKJEOXpRqKesGbPvS+YuCigpcmnjXhQmDfP/Qn5C+vL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGNpKU+rRDoJ/2dsb2JhbABDrn2BBYFyAQEBAwESARQTAgEqFw0BCBJ9DgEBBAESGweHWpl3AZ5UizIBKRMBCAUDAwkHAQcHAoQtg1gEiEGMYJJ1 X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="28230461" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 Feb 2012 16:37:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q11GbCOc006365; Wed, 1 Feb 2012 16:37:12 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 08:37:12 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Feb 2012 16:37:11 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 01 Feb 2012 08:37:10 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3wARCdkwAAP7HHm In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462022B3275@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2012 16:37:12.0048 (UTC) FILETIME=[BF77BF00:01CCE0FF] Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.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: Wed, 01 Feb 2012 16:37:15 -0000 Hi Pierrick, Thanks for your review. Please see inline. On 2/1/12 4:09 AM, "pierrick.seite@orange.com" wrote: > > Hi, > > > Please find below my review of > draft-gundavelli-netext-pmipv6-sipto-option-01: > > This document is in good shape and my comments are mainly editorial. My > main concern is that the introduction is focusing too much on the 3GPP > S2a use-case while the offload option could be useful in other type of > architectures. With the current text, the reader may think that the > offload option has been designed only for 3GPP/EPC. So, at least the > document should avoid using 3GPP specific terminology such as S2a and > SIPTO. But, what about this rewording for the intro: > I agree with that. It was more an example. I can reword it. > ------ OLD TEXT ------ > Mobile Operators are expanding their network coverage by integrating > various access technology domains into a common IP mobile core. For > providing IP mobility support to a mobile node irrespective of the > access network to which it is attached, the 3GPP S2/a Proxy Mobile IPv6 > [TS23402] interface, specified by the 3GPP system architecture, is > providing the needed protocol glue. When this protocol interface based > on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is topologically > anchored on the local mobility anchor [RFC5213] in the home network. > The mobile node's IP traffic is always tunneled back from the mobile > access gateway [RFC5213] in the access network to the local mobility > anchor in the home network. > > ---- NEW TEXT ---- > > In current IP mobility architecture, the mobile node is topologically > anchored on the mobility anchor in the home network. As a consequence, > the mobile node's IP traffic is always tunneled back to the mobility > anchor in the home network. However, some of the traffic does need > mobility support and, so, does not need to be anchored. Actually, in > this situation, routing can be easily optimized when using Proxy Mobile > IPv6 [RFC5213]: the mobile access gateway could forward this traffic to > the local Internet peering point instead of tunneling back to the local > mobility anchor. The 3GPP/Wi-Fi offloading use-case is a concrete > example of such an optimization. Indeed, mobile Operators are expanding > their network coverage by integrating various access technology domains > into a common IP mobile core. For providing IP mobility support to a > mobile node irrespective of the access network to which it is attached, > a Proxy Mobile IPv6 interface, specified by the 3GPP system > architecture, is providing the needed protocol glue [TS23402]. > Thanks for the text. Appreciated. Structuring along these lines makes sense. Let me use it and rework it a bit. > > > Other comments on the introduction: > > ---- OLD TEXT ------------ > some of the non-essential traffic > -----NEW TEXT -------- > some of the traffic > > Note: non-essential traffic sounds pejorative (for an conscientious > operator, there is no non-essential traffic :-)) while the goal is to > distinguish traffic which need mobility support from traffic which does > not... accessing mobile operator services (as depicted on figure 1) is > another use-case for PMIP but it is a specific usage for 3GPP/Wi-Fi > interworking, so I suggest to not refer to this use-case and focus on > mobility; so I've modified fig.1 (see below). > Ok. Good point. > 2.2 Terminology > > I suggest to remove SIPTO acronym which a 3GPP terminology (it gives a > 3GPP coloring to the document and it should be avoided IMHO). Moreover > SIPTO is not used in the rest of the document. > Yes. I did try to stay away from that term, some how ended up using it one place by error. Will fix it and stay away from the 3GPP color :) > > 3. Solution Overview: > > > ---- OLD TEXT ------------ > The following illustrates the scenario where the mobile access gateway > in an access network having the ability to offload some of the IPv4 > traffic flows, based on the traffic selectors it received from the local > mobility anchor in the home network. > -----NEW TEXT -------- > The following illustrates the scenario where the mobile access gateway > has the ability to offload some of the IPv4 traffic flows, based on the > traffic selectors it received from the local mobility anchor in the home > network. > OK. > ----- NEW PICTURE for figure 1 -------- > > _----_ > _( )_ > ( Internet ) > (_ _) > '----' > | +-----------------+ > > (IPv4 Traffic Offload Point | Services with | > at access edge gateway for | mobility support| > offloaded traffic +-----------------+ > Ex: HTTP Traffic Offloaded) | > | | > ...........................................|........... > | . | > +---+ . | > |NAT| . | > +---+ . | > | _----_ | > +-----+ _( )_ +-----+ > [MN]----| MAG |======( IP )======| LMA |-- Internet > +-----+ (_ _) +-----+ > '----' ( > . > . > . > [Access Network] . [Home Network] > ...................................................... > So, the change is on the "Operator Value added services" to "Services with mobility support". Sure. Makes lot of sense. > > > 3.1 LMA considerations > > ------ OLD TEXT ------- > The following considerations apply to the local mobility anchor and the > mobile access gateway. > ------- NEW TEXT --------- > The following considerations apply to the local mobility anchor. > Ok > Inconsistency in Figure 2: > > There are 6 operations in the sequence chart and 7 bullets: "7. > Forwarding rule - Tunnel home/offload" is not represented in the message > flow. > I represented the state creation as an operation and hence the mismatch. Let me clarify that. > Moreover I think the DHCP OFFER/REQUEST and ACK messages should come > right after step #5. It'd lead to the following picture: > Yes. I agree, for completeness, I can put some dotted lines after Step-1 and Step-3. > MN MAG(NAT) LMA > |------>| | 1. Mobile Node Attach > | |------->| 2. Proxy Binding Update > | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) > | |========| 4. Tunnel/Route Setup > | + | 5. Installing the traffic offload rules > |<----->| | 6. DHCP OFFER/REQUEST/ACK exchange > |------>| | 7. IPv4 packet from mobile node > | + | 8. Forwarding rule - Tunnel home/offload > | | | > > ------ OLD TEXT ------- > If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, but if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (0), then the local mobility anchor > MUST ignore the IP Traffic Offload Selector Option and process the > rest of the packet. > ------- NEW TEXT --------- > If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, but if the configuration > variable, EnableIPTrafficOffloadSupport (Section 6) on the local > mobility > anchor is set to a value of (0), then the local mobility anchor > MUST ignore the IP Traffic Offload Selector Option and process the > rest of the packet as per [RFC5213]. > OK > ------ OLD TEXT ------- > If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option Section 4, and if the configuration > variable, EnableIPTrafficOffloadSupport on the local mobility > anchor is set to a value of (1) , then the local mobility anchor > can construct the traffic selectors based on the offload policy > and deliver those selectors in the Proxy Binding Acknowledgement > message using the IP Traffic Offload Selector Option. > ------- NEW TEXT --------- > If the received Proxy Binding Update includes the IP Traffic > Offload Selector Option (Section 4), and if the configuration > variable, EnableIPTrafficOffloadSupport (Section 6) on the local > mobility > anchor is set to a value of (1) , then the local mobility anchor > can construct the traffic selectors based on the offload policy > and deliver those selectors in the Proxy Binding Acknowledgement > message using the IP Traffic Offload Selector Option. How to > provision offload policy on the local mobility anchor is out of the > scope of that document. > OK. I thought I covered this point. But, I will use this text and consolidate. > What about adding the following LMA operation?: > > If the received Proxy Binding Update does not include the IP Traffic > Offload Selector Option (Section 4), and if the configuration variable, > EnableIPTrafficOffloadSupport (Section 6) on the local mobility anchor > is set to a value of (1), then the local mobility anchor SHOULD not > include the IP Traffic Offload Selector Option in the Proxy Binding > Acknowledgement. > Good point. Ack. Thanks. > 3.2 MAG considerations > > Second bullet: replace "mobility access gateway" by "mobile access > gateway" > Yep. Its fixed in -02. > --- OLD TEXT ---- > The mobility access upon accepting the Proxy Binding Acknowledgement > message MUST NOT enable any offload policy for that mobility session. > --- NEW TEXT ---- > The mobile access gateway upon accepting the Proxy Binding > Acknowledgement message MUST NOT enable any offload policy for that > mobility session. > Yep. Its fixed in -02. > Is the following operation covered (Though, I'm not sure it does make > sense) ? : If there is IP Traffic Offload Selector Option without > selector in the corresponding Proxy Binding Acknowledgement message, the > mobile access gateway SHOULD apply its policy. > I thought about this. If we go with the assumption that the MAG needs to indicate its capability, this may not do good for MAG. Else, we remove the capability concept and allow LMA always send the offload spec. Or, we can simply state, MAG should ignore the option, if it got the TS spec, when it never included the option in the PBU. > 4. IP Traffic Offload Selector Option > > For a better readability: insert carriage return after "Reserverd", "IP > Traffic Offload Mode Flag", "TS Format" and "TS Selector". > Sure. Its fixed in -02. > > ---- OLD TEXT ------ > If the (M) flag value is set to a value of (0), it is an indication that > the identified IP flow(s) needs to be offloaded at the mobile access > gateway and all other IP flows associated with that mobility session > needs to be tunneled to the local mobility anchor. > ---- NEW TEXT --------- > If the (M) flag value is set to a value of (0), it is an indication that > the identified IP flow(s) must be offloaded at the mobile access gateway > and all other IP flows associated with that mobility session need to be > tunneled to the local mobility anchor. > > OK > ---- OLD TEXT ------ > TS Format > An 8-bit unsigned integer indicating the Traffic Selector Format. The > value of "0" is reserved and is used when there are no selectors to > carry, relevant when the option is used as a capability indicator. The > value of (1) is assigned for IPv4 Binary Traffic Selector [RFC6088]. > > ---- NEW TEXT --------- > TS Format > An 8-bit unsigned integer indicating the Traffic Selector Format. The > value of "0" is reserved and is used when there are no selectors to > carry. In this case, the option is used only as a capability indicator. > When the value of TS Format field is set to (1), the format that follows > is the IPv4 Binary Traffic Selector specified in section 3.1 of > [RFC6088]. > Much better. OK. > > ---- OLD TEXT ------ > TS Selector > A variable-length opaque field for including the traffic specification > identified by the TS format field. When the value of TS Format field is > set to (1), the format that follows is the IPv4 Binary Traffic Selector > specified in section 3.1 of [RFC6088]. > ---- NEW TEXT --------- > TS Selector > A variable-length opaque field for including the traffic specification > identified by the TS format field. [the rest is already in description > of TS format] > > Ok. > 6. Protocol Configuration Variables > > --- OLD TEXT ---- > it MUST include the IP Traffic Offload Selector option in the Proxy > Binding Update messages and offload the negotiated IP flows to the > access network. > ---- NEW TEXT ---- > it MUST include the IP Traffic Offload Selector option in the Proxy > Binding Update messages and offload the negotiated IP flows to the > nearest Internet peering point. > Well, it can be for local access as well. As long as the NAT requirement is met, the traffic need not always hit the internet peering point. In many use-cases I've seen, its for local service access. Say a wireless subscriber is using wire line access from the same operator, for local service access (Ex: content) within the wireline network, and all the rest of the traffic comes back. But, the offloaded traffic never hits internet. > > 7. Security Considerations > > Just for discussion: > > Allowing the MAG to provide its policy may induce a security risk: IMU, > the MAG is a more vulnerable than the LMA. For instance, if the MAG is > in a residential gateway, there is a risk for that MAG to be corrupted. > If so, the MAG may provide corrupted offloading policy to the LMA which > has no way to check the policy. Of course this is out of scope of > securing PMIP signaling but maybe we could stress the requirement for a > secured policy provisioning mechanism... > > This is a good comment. But, the MAG always has the control on the traffic offload. If its a compromised node, it can just offload every thing. We can see if there are additional security considerations to be added. Thanks for the review Pierrick. This really helps. Appreciated !!! Regards Sri > Hope that helps, > BR, > Pierrick > > From internet-drafts@ietf.org Wed Feb 1 10:59:30 2012 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 9899E11E8094; Wed, 1 Feb 2012 10:59:30 -0800 (PST) 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=[BAYES_00=-2.599, 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 fuVu6tXcj8zK; Wed, 1 Feb 2012 10:59:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1695B11E8079; Wed, 1 Feb 2012 10:59:10 -0800 (PST) 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: 3.64p1 Message-ID: <20120201185910.2999.74760.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 10:59:10 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-03.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: Wed, 01 Feb 2012 18:59:30 -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 Wor= king Group of the IETF. Title : IPv4 Traffic Offload Selector Option for Proxy Mobile IP= v6 Author(s) : Sri Gundavelli Xingyue Zhou Jouni Korhonen Rajeev Koodli Filename : draft-ietf-netext-pmipv6-sipto-option-03.txt Pages : 12 Date : 2012-02-01 This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-0= 3.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-03= .txt From Marco.Liebsch@neclab.eu Thu Feb 2 05:26:41 2012 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 5085321F8870 for ; Thu, 2 Feb 2012 05:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 uP1FbPePXLc1 for ; Thu, 2 Feb 2012 05:26:39 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7251E21F8868 for ; Thu, 2 Feb 2012 05:26:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6C445280001D0 for ; Thu, 2 Feb 2012 14:26:38 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSaltSQV6AKp for ; Thu, 2 Feb 2012 14:26:38 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4D3E228000085 for ; Thu, 2 Feb 2012 14:26:33 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.103]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 2 Feb 2012 14:26:33 +0100 From: Marco Liebsch To: "netext@ietf.org" Thread-Topic: review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: Aczhqsy+0pRYoJA/RC22UTcJjZKe/w== Date: Thu, 2 Feb 2012 13:26:33 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24D50BC4@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.212] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D24D50BC4PALLENEofficehd_" MIME-Version: 1.0 Subject: [netext] review of draft-ietf-netext-pmipv6-sipto-option-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: Thu, 02 Feb 2012 13:26:41 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D24D50BC4PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find some comments about the 3rd revision of draft-ietf-netext-pmipv= 6-sipto-option-03 below. - Sect 1. Intro, 2nd paragraph: ..IP flows that needs to be.. -> ..that nee= d to be.. - Sect 3. First paragraph: ..HTTP flows may be be offload.. -> ..may be off= load.. - Sect 3. Second paragraph: talks about the traffic selector attributes whi= ch can be matched against the fields in the 'IP packet header'. As the TS includes attributes= from the transport header or even deeper in the packet, matching against IP header i= s not sufficient. Just write 'matched against the header fields in the data packe= ts'. Seems less confusing. - Page 5, reference to the figure 1 should be a reference to Figure 2, as t= he text mentions. 'operational sequence'. Then a reference to Figure 1 is missing, = which I would include to the first paragraph of Section 3. Same page and paragraph: '..access link are not show here' -> '..not shown = here..' General comment: The current procedure assumes pretty static offload rules. These can be eit= her recommended by the MAG and approved by the LMA or the LMA provides the rules. Something like 'all port 80 traffic to be offloaded ', etc. This doe= s not allow a decision on a flow basis, as the rules are established with the PBU/PBA w= here no flow has been initiated yet. Hence, beside well-known ports, information ab= out port numbers for TS is rather limited. Maybe an extended use of the proposed option makes sense to support dynamic decisions about traffic offload. After registration, the MAG may re= ceive an uplink packet of a new flow and takes decision about an offload policy o= r requests the policy from the LMA. The same options can be used (now ports are clear)= , but an additional PBU/PBA need to be sent to establish the dynamic rule. The sp= ecification could just consider this in the MAG/LMA operations section. marco --_000_69756203DDDDE64E987BC4F70B71A26D24D50BC4PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find some comments about the 3rd r= evision of draft-ietf-netext-pmipv6-sipto-option-03
below.

 

- Sect 1. Intro, 2nd paragraph: ..IP flow= s that needs to be.. -> ..that need to be..

 

- Sect 3. First paragraph: ..HTTP flows may be be of= fload.. -> ..may be offload..

 

- Sect 3. Second paragraph: talks about the traffic = selector attributes which can be matched
against the fields in the ‘IP packet header’. As the TS include= s attributes from the
transport header or even deeper in the packet, matching against IP header i= s not

sufficient. Just write ‘matched against the he= ader fields in the data packets’.

Seems less confusing.

 

- Page 5, reference to the figure 1 should be a refe= rence to Figure 2, as the text
mentions. ‘operational sequence’. Then a reference to Figure 1 = is missing, which
I would include to the first paragraph of Section 3.

 

Same page and paragraph: ‘..access link are no= t show here’ -> ‘..not shown here..’

 

General comment:

 

The current procedure assumes pretty static offload = rules. These can be either
recommended by the MAG and approved by the LMA or the LMA provides the
rules. Something like ‘all port 80 traffic to be offloaded ’, e= tc. This does not allow
a decision on a flow basis, as the rules are established with the PBU/PBA w= here no
flow has been initiated yet. Hence, beside well-known ports, information ab= out
port numbers for TS is rather limited.

 

Maybe an extended use of the proposed option makes s= ense to support
dynamic decisions about traffic offload. After registration, the MAG may re= ceive
an uplink packet of a new flow and takes decision about an offload policy o= r requests
the policy from the LMA. The same options can be used (now ports are clear)= , but

an additional PBU/PBA need to be sent to establish t= he dynamic rule. The specification
could just consider this in the MAG/LMA operations section.

 

marco

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D24D50BC4PALLENEofficehd_-- From sgundave@cisco.com Thu Feb 2 11:38:12 2012 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 B0DA321F85D4 for ; Thu, 2 Feb 2012 11:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.73 X-Spam-Level: X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 OJQOT7X8RSCF for ; Thu, 2 Feb 2012 11:38:10 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C389921F8528 for ; Thu, 2 Feb 2012 11:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6136; q=dns/txt; s=iport; t=1328211490; x=1329421090; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=C8+MfUHGLIWzbZSIYvrWgpmtmFdBzfTcNQ3wOpTZuoQ=; b=GOh7FFXuXmgwRyqLLJbU+JZHNK6jciGnorDeL+ZOs5JY7ctAVC/gNHci 8vRhHRU+mIgQBpcbieuEMdmslRLJwOmObff7vVOLgAHL3c5ufmb6+6j7e jLZYlF04mM781RxAYrFUGETLABiWprXLbjmgMwzlr/LwvEMa/eStEFYSZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEXlKk+rRDoG/2dsb2JhbABDgk2rXGWBBYFyAQEBAwESARQWQQ0BCASBGQEBBAESIodamUwBnmqLexMBCAUDAwkHAQcHAoQtg1gEiA8zjGGSdg X-IronPort-AV: E=Sophos;i="4.73,347,1325462400"; d="scan'208,217";a="28408175" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Feb 2012 19:38:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q12JcAJw025287; Thu, 2 Feb 2012 19:38:10 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 11:38:10 -0800 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2012 19:38:09 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 02 Feb 2012 11:38:08 -0800 From: Sri Gundavelli To: Marco Liebsch , "netext@ietf.org" Message-ID: Thread-Topic: [netext] review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: Aczhqsy+0pRYoJA/RC22UTcJjZKe/wAN2PKM In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24D50BC4@PALLENE.office.hd> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3411027488_45757326" X-OriginalArrivalTime: 02 Feb 2012 19:38:10.0319 (UTC) FILETIME=[31EA29F0:01CCE1E2] Subject: Re: [netext] review of draft-ietf-netext-pmipv6-sipto-option-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: Thu, 02 Feb 2012 19:38:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3411027488_45757326 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Marco: Thanks for the review. Inline. On 2/2/12 5:26 AM, "Marco Liebsch" wrote: > Please find some comments about the 3rd revision of > draft-ietf-netext-pmipv6-sipto-option-03 > below. > =20 > - Sect 1. Intro, 2nd paragraph: ..IP flows that needs to be.. -> ..that n= eed > to be.. > =20 > [Sri] OK >=20 >=20 > - Sect 3. First paragraph: ..HTTP flows may be be offload.. -> ..may be > offload.. >=20 >=20 > [Sri] OK >=20 > =20 > - Sect 3. Second paragraph: talks about the traffic selector attributes w= hich > can be matched > against the fields in the =8CIP packet header=B9. As the TS includes attribut= es > from the > transport header or even deeper in the packet, matching against IP header= is > not > sufficient. Just write =8Cmatched against the header fields in the data > packets=B9. > Seems less confusing. >=20 > [Sri] OK > =20 >=20 > - Page 5, reference to the figure 1 should be a reference to Figure 2, as= the > text > mentions. =8Coperational sequence=B9. Then a reference to Figure 1 is missing= , > which > I would include to the first paragraph of Section 3. >=20 > [Sri] OK. Thanks for catching this. >=20 >=20 > =20 > Same page and paragraph: =8C..access link are not show here=B9 -> =8C..not show= n > here..=B9 >=20 >=20 > [Sri] OK > =20 > General comment: > =20 > The current procedure assumes pretty static offload rules. These can be e= ither > recommended by the MAG and approved by the LMA or the LMA provides the > rules. Something like =8Call port 80 traffic to be offloaded =B9, etc. This d= oes > not allow > a decision on a flow basis, as the rules are established with the PBU/PBA > where no > flow has been initiated yet. Hence, beside well-known ports, information = about > port numbers for TS is rather limited. > =20 > Maybe an extended use of the proposed option makes sense to support > dynamic decisions about traffic offload. After registration, the MAG may > receive > an uplink packet of a new flow and takes decision about an offload policy= or > requests > the policy from the LMA. The same options can be used (now ports are clea= r), > but > an additional PBU/PBA need to be sent to establish the dynamic rule. The > specification > could just consider this in the MAG/LMA operations section. >=20 > [Sri] I agree as well. We need to be able to change the rules dynamically= . I > was planning to make that change. >=20 > Thanks for the review. >=20 >=20 > Regards > Sri >=20 --B_3411027488_45757326 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] review of draft-ietf-netext-pmipv6-sipto-option-03</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Marco:<BR> <BR> Thanks for the review. Inline.<BR> <BR> <BR> <BR> On 2/2/12 5:26 AM, "Marco Liebsch" <<a href=3D"Marco.Liebsch@nec= lab.eu">Marco.Liebsch@neclab.eu</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Please find some comments about the 3rd revision= of draft-ietf-netext-pmipv6-sipto-option-03<BR> below.<BR>  <BR> - Sect 1. Intro, 2nd paragraph: ..IP flows that needs to be.. -> ..that = need to be..<BR>  <BR> [Sri] OK<BR> <BR> <BR> - Sect 3. First paragraph: ..HTTP flows may be be offload.. -> ..may be = offload..<BR> <BR> <BR> [Sri] OK<BR> <BR>  <BR> - Sect 3. Second paragraph: talks about the traffic selector attributes whi= ch can be matched<BR> against the fields in the ‘IP packet header’. As the TS include= s attributes from the<BR> transport header or even deeper in the packet, matching against IP header i= s not<BR> sufficient. Just write ‘matched against the header fields in the data= packets’.<BR> Seems less confusing.<BR> <BR> [Sri] OK<BR>  <BR> <BR> - Page 5, reference to the figure 1 should be a reference to Figure 2, as t= he text<BR> mentions. ‘operational sequence’. Then a reference to Figure 1 = is missing, which<BR> I would include to the first paragraph of Section 3.<BR> <BR> [Sri] OK. Thanks for catching this.<BR> <BR> <BR>  <BR> Same page and paragraph: ‘..access link are not show here’ ->= ; ‘..not shown here..’<BR> <BR> <BR> [Sri] OK<BR>  <BR> General comment:<BR>  <BR> The current procedure assumes pretty static offload rules. These can be eit= her<BR> recommended by the MAG and approved by the LMA or the LMA provides the<BR> rules. Something like ‘all port 80 traffic to be offloaded ’, e= tc. This does not allow<BR> a decision on a flow basis, as the rules are established with the PBU/PBA w= here no<BR> flow has been initiated yet. Hence, beside well-known ports, information ab= out<BR> port numbers for TS is rather limited.<BR>  <BR> Maybe an extended use of the proposed option makes sense to support<BR> dynamic decisions about traffic offload. After registration, the MAG may re= ceive<BR> an uplink packet of a new flow and takes decision about an offload policy o= r requests<BR> the policy from the LMA. The same options can be used (now ports are clear)= , but<BR> an additional PBU/PBA need to be sent to establish the dynamic rule. The sp= ecification<BR> could just consider this in the MAG/LMA operations section.<BR> <BR> [Sri] I agree as well. We need to be able to change the rules dynamically. =  I was planning to make that change. <BR> <BR> Thanks for the review.<BR> <BR> <BR> Regards<BR> Sri<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3411027488_45757326-- From pierrick.seite@orange.com Fri Feb 3 05:58:24 2012 Return-Path: <pierrick.seite@orange.com> 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 D6EB421F8534 for <netext@ietfa.amsl.com>; Fri, 3 Feb 2012 05:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SQ9RLFdiCq22 for <netext@ietfa.amsl.com>; Fri, 3 Feb 2012 05:58:24 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id E90A621F8528 for <netext@ietf.org>; Fri, 3 Feb 2012 05:58:23 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9EA1FDE4003 for <netext@ietf.org>; Fri, 3 Feb 2012 14:59:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 94CB8DE4002 for <netext@ietf.org>; Fri, 3 Feb 2012 14:59:49 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 14:58:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Feb 2012 14:58:20 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462022B3876@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments/question on draft-ietf-netext-pmipv6-flowmob Thread-Index: Aczie+Ltg56J/V8cRju3vMHTfCQmqQ== From: <pierrick.seite@orange.com> To: <netext@ietf.org> X-OriginalArrivalTime: 03 Feb 2012 13:58:21.0702 (UTC) FILETIME=[E3C3DA60:01CCE27B] Subject: [netext] comments/question on draft-ietf-netext-pmipv6-flowmob 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Feb 2012 13:58:24 -0000 Hi Carlos and flowmob authors, In draft-ietf-netext-pmipv6-flowmob-02, LMA-initiated handover is supposed to be out-of-scope (http://www.ietf.org/mail-archive/web/netext/current/msg02184.html). However, on section 3.2.2, it is stated: The trigger for the flow movement can be on the mobile node (e.g., by using layer-2 signaling, by explicitly start sending flow packets via a new interface, etc.) or on the network (e.g., based on congestion and measurements performed at the network). It should be: ------------------------ The trigger for the flow movement is on the mobile node (e.g., by using layer-2 signaling, by explicitly start sending flow packets via a new interface, etc.). ------------------------- Moreover, call-flows (figures 2 and 4) show the operation "handover decision" over multiple entities, including MN, MAGs and LMA. It is confusing; the handover decision should be only on the MN side. Example: +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN1 | +-----+ +------+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::lif | pref1::lif | pref1::lif | |<----------->|<--------------->|<-------------------------->if1 | flow Y to | flow Y to | flow Y to | | pref1::lif | pref1::lif | pref1::lif | |<----------->|<------------------------------->|<---------->if2 | | | | | | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | | decision to=20 | | | | | move flow Y=20 | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | | | flow Y to | flow Y to | flow Y to | | pref1::lif | pref1::lif | pref1::lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | Now, my question: With a MN driven handover decision, I do not understand the scenario "MN with different sets of prefixes on each MAG". Quoting section 3.2.2: "If the flow is being moved from its default path (which is determined by the destination prefix) to a different one, the LMA constructs a Flow Mobility Initiate (FMI) message."=20 I understand the reason for FMI, but how the LMA can be aware of the handover if the decision is made by the MN? In other words, what is the trigger for FMI initiation? My understanding is that the scenario relying on FMI/FMA can only be a LMA-initiated handover scenario; thus should be addressed in another document. BR, Pierrick From yokota@kddilabs.jp Sun Feb 5 00:01:26 2012 Return-Path: <yokota@kddilabs.jp> 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 F0BFE21F853E for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 00:01:25 -0800 (PST) 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] 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 NYqlttIh-dWW for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 00:01:19 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27121F8537 for <netext@ietf.org>; Sun, 5 Feb 2012 00:01:19 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 7A96E1748226 for <netext@ietf.org>; Sun, 5 Feb 2012 17:01:18 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ynqWV62f1vt for <netext@ietf.org>; Sun, 5 Feb 2012 17:01:18 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 341AA1748223 for <netext@ietf.org>; Sun, 5 Feb 2012 17:01:18 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 87FD51B9B6 for <netext@ietf.org>; Sun, 5 Feb 2012 17:00:58 +0900 (JST) Message-ID: <4F2E3749.8050404@kddilabs.jp> Date: Sun, 05 Feb 2012 17:01:13 +0900 From: Hidetoshi Yokota <yokota@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 05 Feb 2012 08:01:26 -0000 Hi Sri, Good work. Here are my comments and suggestions for version -03: [Section 2.2] Selective IP Traffic Offload (SIPTO) The approach of selecting specific IP flows and routing them to the local network, as supposed to tunneling them to the home network. ^^^^^^^^^^^^^^ "as opposed to" ? Also, the box entitled with "Local Services" in Figure 1 is a bit confusing because this doesn't seem to be related to "traffic offload". It is ok if you use it for route optimization, but for an example of traffic offload, this box may not be necessary. [Section 3] The following caption does not seem to express the whole figure: Figure 1: Access Networks attached to MAG Suggested one is like: "Network configuration/architecture where traffic offloading is applicable" [Section 3.1] My general comment is that it is not very clear if the traffic offload selector is provided by the LMA or can be done by the MAG as well. According to Section 3 and Figure 2, the traffic offload selector comes from the LMA to the MAG, so the first bullet of Section 3.1 is a little bit confusing. If this spec allows the MAG to send the IPTS option, such scenario should also be included in Section 3 and #2 of Figure 2 | |------->| 2. Proxy Binding Update (IPTS Option) ^^^^^^^^^^^^^^ [Q] If the MAG can also send this option, I have one question: when the MN's IPv4 address is assigned by the LMA, the MAG may not be able to know that address until it receives the PBA with that address from the LMA. In that case, the MAG cannot create a valid traffic offload selector, which requires the MN's IPv4 address. I guess the PBU/PBA need to be exchanged multiple times. If the traffic offload selector is provided only by the LMA, the scenario will be simpler. I recommend clarifying possible scenarios and procedures. Regards, -- Hidetoshi From yokota@kddilabs.jp Sun Feb 5 03:13:58 2012 Return-Path: <yokota@kddilabs.jp> 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 DB45F21F84A1 for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 03:13:58 -0800 (PST) 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] 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 bU4hP7j0-5Kg for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 03:13:58 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 2F11A21F84DF for <netext@ietf.org>; Sun, 5 Feb 2012 03:13:58 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 476A31748238 for <netext@ietf.org>; Sun, 5 Feb 2012 20:13:48 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UZJLhMe7eNk for <netext@ietf.org>; Sun, 5 Feb 2012 20:13:36 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id C43751748237 for <netext@ietf.org>; Sun, 5 Feb 2012 20:13:36 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id E35D11B867 for <netext@ietf.org>; Sun, 5 Feb 2012 20:13:16 +0900 (JST) Message-ID: <4F2E645B.6060104@kddilabs.jp> Date: Sun, 05 Feb 2012 20:13:31 +0900 From: Hidetoshi Yokota <yokota@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "netext@ietf.org" <netext@ietf.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 05 Feb 2012 11:13:59 -0000 Hi Sri, The latest version is well written, but I have just one comment on Network-Identifier Sub-Option. According to the discussion with Raj, the network name should not be only WLAN SSID, but also PLMN ID for example. So, the text in Section 3.1.1 should be modified as follows: In Section 3.1.1: --- Current text ---- SSID: SSID of the access network to which the mobile node is attached. The string is carried in UTF-8 representation. --- Proposed text --- Network Name: The name of the access network to which the mobile node is attached. The string is carried in UTF-8 representation. --------------------- As an example of the Network Name, it is a good idea to include the PLMN ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. If I can add one more thing, it would be more convenient to add the network name type (NType) before the Network Name strings as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANI Type=1 | ANI Length | NType | Network Name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NType: SSID (0), PLMN ID (1), ... [As a side note, 3GPP2 has also defined the Access Network Identifier (ANID)] This is just a suggestion and if it looks too much complex, you can ignore it. Regards, -- Hidetoshi From sgundave@cisco.com Sun Feb 5 20:04:18 2012 Return-Path: <sgundave@cisco.com> 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 625C621F84D6 for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 9Fs0DKWVwlkR for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:04:17 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 99F6721F84CF for <netext@ietf.org>; Sun, 5 Feb 2012 20:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3940; q=dns/txt; s=iport; t=1328501057; x=1329710657; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=l3KxwJu/RsesQ0RqR8WLoleWyj/LrtI8lyWbWF4gx10=; b=KZi/O9iWKQmdtlCm0Lfy5jR2XPE73mm37tgCvD/T+S0eh5xwi4Zm8W/2 9G3+FJpefg/7YxgyGSdCEAPD3LBScsC58OIRuCLgEkf/CVKsHPu9Fm75c fLH40IEEFtDccVaeokEp7QJY3hTd9svx+urJOTS4KcHjhzL97VTQaOk2B I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAtRL0+rRDoI/2dsb2JhbABErzeBBYFyAQEBAwESARQTAgEqFw0BCBJ9DgEBBAESIodaml0BngmLZAEpEwEIBQMDCQcBBwcChC0fgzkEiESMZJJ8 X-IronPort-AV: E=Sophos;i="4.73,368,1325462400"; d="scan'208";a="27161814" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Feb 2012 04:04:16 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1644Hub006659; Mon, 6 Feb 2012 04:04:17 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 20:04:16 -0800 Received: from 10.21.80.135 ([10.21.80.135]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Feb 2012 04:04:16 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 05 Feb 2012 20:04:15 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org> Message-ID: <CB54913F.394A8%sgundave@cisco.com> Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: AczkhGPqCe6W44Y4XUaFaVDydgvLbw== In-Reply-To: <4F2E3749.8050404@kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Feb 2012 04:04:16.0788 (UTC) FILETIME=[64FADD40:01CCE484] Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Feb 2012 04:04:18 -0000 Hi Yokota-san, Thanks for your review. Please see inline. On 2/5/12 12:01 AM, "Hidetoshi Yokota" <yokota@kddilabs.jp> wrote: > Hi Sri, > > Good work. Here are my comments and suggestions for version -03: > > [Section 2.2] > > Selective IP Traffic Offload (SIPTO) > > The approach of selecting specific IP flows and routing them to > the local network, as supposed to tunneling them to the home > network. ^^^^^^^^^^^^^^ > > "as opposed to" ? > OK. Will rephrase it. > Also, the box entitled with "Local Services" in Figure 1 is a bit > confusing because this doesn't seem to be related to "traffic offload". > It is ok if you use it for route optimization, but for an example of > traffic offload, this box may not be necessary. > This is a good discussion point. The way I see it, any time, an IP flow that uses the home address is directly offloaded into the access network, there are two aspects to it: #a: The offloaded traffic may be for a local destination within the access network #b: It may be for a destination in the Internet, outside the access network In both these cases, depending on the location of the MAG, there may or may not be NAT translation required for that flow. If its for Internet, NAT translation is needed, for topological correctness, and is also a MUST if the CN is not directly connected to the MAG and if that MAG is not an higher-level aggregation router, where all the traffic goes through that node. These are the different possible offload cases. So, for case #a, specifically if the CN is directly attached to the MAG, this may appear as a case of route optimization, but that is one specific case in the list of offload cases and also the reason for offload is not exactly for RO, but more policy driven. I can fix the diagram to avoid any confusion. > [Section 3] > > The following caption does not seem to express the whole figure: > > Figure 1: Access Networks attached to MAG > > Suggested one is like: > "Network configuration/architecture where traffic offloading is applicable" > Ok. > [Section 3.1] > > My general comment is that it is not very clear if the traffic offload > selector is provided by the LMA or can be done by the MAG as well. > According to Section 3 and Figure 2, the traffic offload selector comes > from the LMA to the MAG, so the first bullet of Section 3.1 is a little > bit confusing. If this spec allows the MAG to send the IPTS option, such > scenario should also be included in Section 3 and #2 of Figure 2 > The spec does allow the option to be carried in both the directions. When carried from MAG to LMA, its up to the LMA to accept or override the request. I will clarify this bullet point. > | |------->| 2. Proxy Binding Update (IPTS Option) > ^^^^^^^^^^^^^^ > [Q] If the MAG can also send this option, I have one question: when the > MN's IPv4 address is assigned by the LMA, the MAG may not be able to > know that address until it receives the PBA with that address from the > LMA. In that case, the MAG cannot create a valid traffic offload > selector, which requires the MN's IPv4 address. I guess the PBU/PBA need > to be exchanged multiple times. If the traffic offload selector is > provided only by the LMA, the scenario will be simpler. I recommend > clarifying possible scenarios and procedures. > The traffic selector is always specific to the flows associated with a mobility session. This is an implicit assumption. This is a good comment, we are probably missing one consideration there. When the selectors are based on source address of the IP flow, the related assumptions have to be stated. We Will clarify that part. This is a good catch. Thanks again for your review. Regards Sri > Regards, From sgundave@cisco.com Sun Feb 5 20:04:56 2012 Return-Path: <sgundave@cisco.com> 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 A541F21F853A for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 bwWtmyUwCIKe for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:04:56 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E29C21F84CF for <netext@ietf.org>; Sun, 5 Feb 2012 20:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2057; q=dns/txt; s=iport; t=1328501096; x=1329710696; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=E/l0a/Z/k4golj7v8ZqjkhgHq8wF/WsRF3rSWbP/PL8=; b=QgWTobheiqG0Nbbsbre2gZl4qJaHDWPfLMfBPMm1/2/VSuuiymonLKpD yEMs/BeL+gTX6CeF1P8cN+X9rU+APOfcpm4DANd3Ptd9uoXDz9q93rMSy F8IjJvs0kVURacH+r7b1auwnR/74TnFhNJdq8/O8u1RBbBf9+VQFmAnE+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAtRL0+rRDoG/2dsb2JhbABErzeBBYFyAQEBAwESAScCASoXDQEIgR0BAQQBEiKHWppdAZ4Ji2QBKRMBCAUDAwkHAQcHAgeEJh+DOQSIRIxkknw X-IronPort-AV: E=Sophos;i="4.73,368,1325462400"; d="scan'208";a="27161905" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Feb 2012 04:04:55 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1644u3q020127; Mon, 6 Feb 2012 04:04:56 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 20:04:55 -0800 Received: from 10.21.80.135 ([10.21.80.135]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Feb 2012 04:04:55 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 05 Feb 2012 20:04:54 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org> Message-ID: <CB549166.394AA%sgundave@cisco.com> Thread-Topic: [netext] Review of ID: draft-ietf-netext-access-network-option-05.txt Thread-Index: AczkhHsoTz3KPyWmlUW4+lN3R5bbqQ== In-Reply-To: <4F2E645B.6060104@kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Feb 2012 04:04:55.0615 (UTC) FILETIME=[7C1F64F0:01CCE484] Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Feb 2012 04:04:56 -0000 Hi Yokota-san, Thanks again for the review. Please see inline. On 2/5/12 3:13 AM, "Hidetoshi Yokota" <yokota@kddilabs.jp> wrote: > Hi Sri, > > The latest version is well written, but I have just one comment on > Network-Identifier Sub-Option. According to the discussion with Raj, the > network name should not be only WLAN SSID, but also PLMN ID for example. > So, the text in Section 3.1.1 should be modified as follows: > I agree, I was thinking about this as well. With the use of this sub-type, we should be able to generalize the network-name and carry SSID, or PLMID ..etc I will make the changes. Thanks for the suggestion. > In Section 3.1.1: > > --- Current text ---- > SSID: SSID of the access network to which the mobile node is > attached. The string is carried in UTF-8 representation. > --- Proposed text --- > Network Name: The name of the access network to which the mobile > node is attached. The string is carried in UTF-8 representation. > --------------------- > Sure > As an example of the Network Name, it is a good idea to include the PLMN > ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. > > If I can add one more thing, it would be more convenient to add the > network name type (NType) before the Network Name strings as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ANI Type=1 | ANI Length | NType | Network Name ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NType: SSID (0), PLMN ID (1), ... > This looks good. Thanks. I will make the changes. > [As a side note, 3GPP2 has also defined the Access Network Identifier > (ANID)] > > This is just a suggestion and if it looks too much complex, you can > ignore it. > No, this is much better. Thanks Sri > Regards, From sgundave@cisco.com Sun Feb 5 20:46:52 2012 Return-Path: <sgundave@cisco.com> 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 C726C21F855F for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 0n-lDWaCehtB for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 20:46:52 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5421F8547 for <netext@ietf.org>; Sun, 5 Feb 2012 20:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1337; q=dns/txt; s=iport; t=1328503612; x=1329713212; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=wnzxe21KUz+DWsH9v7EC+wc3QxiVXuPAeTvMgxMn3Xo=; b=UCv/NBPJ5wdXEkKRr45weCd73Fpzt1l+Nhx5TwOvDsTImiTbD+B4u9sr v2LyvO8uo/ERbf2mlp8O3n36SiICf1u3E9A0qR1i5b4IXUau3XjEnHdIk Y1X62TGyzIItur4aVJLDAxfmz4RER0cA9Le0RIMvTY7VnD6YuJMjogBEz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKFaL0+rRDoI/2dsb2JhbABErzeBBYF0AQQSAScCAU4BCA6BDwEBBAESIqIsAZ4Ni2QBKRMBCAUDAwkHAQcHAgeEJh+DOQSIRIxkknw X-IronPort-AV: E=Sophos;i="4.73,368,1325462400"; d="scan'208";a="28824681" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 06 Feb 2012 04:46:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q164kpUW024360; Mon, 6 Feb 2012 04:46:51 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 20:46:51 -0800 Received: from 10.21.80.135 ([10.21.80.135]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Feb 2012 04:46:51 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 05 Feb 2012 20:46:49 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: Sri Gundavelli <sgundave@cisco.com>, Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org> Message-ID: <CB549B39.394BB%sgundave@cisco.com> Thread-Topic: [netext] Review of ID: draft-ietf-netext-access-network-option-05.txt Thread-Index: AczkhHsoTz3KPyWmlUW4+lN3R5bbqQABdsP4 In-Reply-To: <CB549166.394AA%sgundave@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Feb 2012 04:46:51.0876 (UTC) FILETIME=[57EE5A40:01CCE48A] Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Feb 2012 04:46:52 -0000 Hi Yokota-san: One comment below. On 2/5/12 8:04 PM, "Sri Gundavelli" <sgundave@cisco.com> wrote: > > > >> As an example of the Network Name, it is a good idea to include the PLMN >> ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. >> >> If I can add one more thing, it would be more convenient to add the >> network name type (NType) before the Network Name strings as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ANI Type=1 | ANI Length | NType | Network Name ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> NType: SSID (0), PLMN ID (1), ... I remembered now why we did not add this Ntype. Given the Access Technology Type option is mandatory option, we thought the Ntype will just be specific to the ATT and the network name can be just SSID, or PLMNId based on that. If there is a possibility to have multiple network-name types under a given ATT, we can eliminate this option. So, we can add this Sub-type, or just state the network-name can be SSID, when the ATT is 802.11, or PLMIND for other other UMTS/LTE access. Regards Sri From cjbc@it.uc3m.es Sun Feb 5 23:58:21 2012 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA821F855F for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 23:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLkMJXBp4Jp for <netext@ietfa.amsl.com>; Sun, 5 Feb 2012 23:58:20 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 54F8921F8453 for <netext@ietf.org>; Sun, 5 Feb 2012 23:58:20 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4ABCC75ABE0 for <netext@ietf.org>; Mon, 6 Feb 2012 08:58:18 +0100 (CET) Message-ID: <1328515089.3833.8.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: "netext@ietf.org" <netext@ietf.org> Date: Mon, 06 Feb 2012 08:58:09 +0100 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tdjO8XF1+BtVDx3oC8zo" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18692.003 Subject: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Feb 2012 07:58:21 -0000 --=-tdjO8XF1+BtVDx3oC8zo Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, Some additional comments after a quick review of the draft: - Section 3.1: I think there is a problem with the references, because it appears in thge text: "If the received Proxy Binding Update includes the IP Traffic Offload Selector option Section 4". I guess it should say: "If the received Proxy Binding Update includes the IP Traffic Offload Selector option (Section 4)". There are more instances referring to other sections. - Section 4. The IPTS options has the field "TS Format", which resembles the option defined in RFC 6089 for the traffic selector sub-option, and in this way re-uses the binary TS defined for IPv4 in RFC 6088. However, the draft defines a new IANA space for this "TS Format" field, which might be a bit confusing. Can we just re-use RFC 6089 space (now it only has three values reserved: "0" that should not be used, and "1" for binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some redundancy that might lead to confusion. If we do that, the draft would probably need to define a flag or something to catch what it is now done by putting a "TS Format" equal to "0". - By doing offloading, there are issues associated to handovers (if the mobile node moves, any traffic that was being offloaded would need to be restarted). I guess some text on that would be helfpul. Hope this helps, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-tdjO8XF1+BtVDx3oC8zo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8viBEACgkQNdy6TdFwT2dUtQCcC/r2bCQ2s9tTorbFhDqxs5S3 0VoAn1Zgyd1seJ6VqDnE34OW4uropmoy =z+kb -----END PGP SIGNATURE----- --=-tdjO8XF1+BtVDx3oC8zo-- From jari.arkko@piuha.net Tue Feb 7 01:04:34 2012 Return-Path: <jari.arkko@piuha.net> 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 893BD21F86A7 for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 01:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 c3oXHWN3nJK9 for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 01:04:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7E91A21F869E for <netext@ietf.org>; Tue, 7 Feb 2012 01:04:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 101BE2CDFB; Tue, 7 Feb 2012 11:04:32 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJIuHBXMks8S; Tue, 7 Feb 2012 11:04:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4FC9D2CC39; Tue, 7 Feb 2012 11:04:31 +0200 (EET) Message-ID: <4F30E91F.8000002@piuha.net> Date: Tue, 07 Feb 2012 11:04:31 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Suresh Krishnan <suresh.krishnan@ericsson.com> References: <4ECFDD66.2040801@piuha.net> <4EE1ADE5.3050001@ericsson.com> <4F018F51.1060908@piuha.net> <4F022A5E.8000808@ericsson.com> In-Reply-To: <4F022A5E.8000808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netext-pmip-lr@tools.ietf.org" <draft-ietf-netext-pmip-lr@tools.ietf.org>, "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] AD review of draft-ietf-netext-pmip-lr 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Feb 2012 09:04:34 -0000 I have reviewed the new version and it looks good. Thank you for the changes. I have asked for an IETF Last Call to be initiated. Jari From pierrick.seite@orange.com Tue Feb 7 03:07:25 2012 Return-Path: <pierrick.seite@orange.com> 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 91D7121F852C for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 03:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uUQku6eCbPEq for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 03:07:25 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C121F84D6 for <netext@ietf.org>; Tue, 7 Feb 2012 03:07:22 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B926AE302C1 for <netext@ietf.org>; Tue, 7 Feb 2012 12:07:58 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B47A3E302A6 for <netext@ietf.org>; Tue, 7 Feb 2012 12:07:58 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 12:07:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 12:07:20 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462022B3DA6@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use-cases of draft-ietf-netext-logical-interface-support Thread-Index: AczliKlCnkdcjYMARrmv0/IHxEYr7Q== From: <pierrick.seite@orange.com> To: <netext@ietf.org> X-OriginalArrivalTime: 07 Feb 2012 11:07:22.0172 (UTC) FILETIME=[AA42CFC0:01CCE588] Subject: [netext] use-cases of draft-ietf-netext-logical-interface-support 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Feb 2012 11:07:25 -0000 Hi Tele and Sri, The WG has decided to specify the flow mobility without LMA-Initiated handover. However, section 6 (use-cases) of draft-ietf-netext-logical-interface-support focuses only on LMA-initiated handover. I'm not saying that LMA-Initiated use-case is irrelevant and I've no problem to include it in the document dealing with LI support. But for the sake of consistency with the solution draft, I think that draft-ietf-netext-logical-interface-support should also cover MN-initiated handovers. What do you think? BR, Pierrick From iesg-secretary@ietf.org Tue Feb 7 06:52:36 2012 Return-Path: <iesg-secretary@ietf.org> 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 2DE4621F869F; Tue, 7 Feb 2012 06:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 CxWZbhDKPzmW; Tue, 7 Feb 2012 06:52:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6274521F87FC; Tue, 7 Feb 2012 06:52:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120207145216.20149.19438.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 06:52:16 -0800 Cc: netext@ietf.org Subject: [netext] Last Call: <draft-ietf-netext-pmip-lr-08.txt> (Localized Routing for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Feb 2012 14:52:36 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Localized Routing for Proxy Mobile IPv6' <draft-ietf-netext-pmip-lr-08.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/ No IPR declarations have been submitted directly on this I-D. From yokota@kddilabs.jp Tue Feb 7 18:26:11 2012 Return-Path: <yokota@kddilabs.jp> 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 0C2BE11E80A4 for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 18:26:11 -0800 (PST) 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] 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 dCYbPppLogT2 for <netext@ietfa.amsl.com>; Tue, 7 Feb 2012 18:26:10 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 39FBB11E809C for <netext@ietf.org>; Tue, 7 Feb 2012 18:26:10 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 06FF417480BE; Wed, 8 Feb 2012 11:25:57 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rdRv2o3s9so; Wed, 8 Feb 2012 11:25:55 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6EDD617480B6; Wed, 8 Feb 2012 11:25:55 +0900 (JST) Received: from [127.0.0.1] (yokoletsR9.mn.mip.kddilabs.jp [172.19.90.30]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 27B361B9B1; Wed, 8 Feb 2012 11:25:33 +0900 (JST) Message-ID: <4F31DD30.9070108@kddilabs.jp> Date: Wed, 08 Feb 2012 11:25:52 +0900 From: Hidetoshi Yokota <yokota@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Sri Gundavelli <sgundave@cisco.com> References: <CB549B39.394BB%sgundave@cisco.com> In-Reply-To: <CB549B39.394BB%sgundave@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2012 02:26:11 -0000 Hi Sri, (2012/02/06 13:46), Sri Gundavelli wrote: > Hi Yokota-san: > > One comment below. > > > On 2/5/12 8:04 PM, "Sri Gundavelli"<sgundave@cisco.com> wrote: > >> >> >> >>> As an example of the Network Name, it is a good idea to include the PLMN >>> ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. >>> >>> If I can add one more thing, it would be more convenient to add the >>> network name type (NType) before the Network Name strings as follows: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | ANI Type=1 | ANI Length | NType | Network Name ~ >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> NType: SSID (0), PLMN ID (1), ... > > I remembered now why we did not add this Ntype. Given the Access Technology > Type option is mandatory option, we thought the Ntype will just be specific > to the ATT and the network name can be just SSID, or PLMNId based on that. > If there is a possibility to have multiple network-name types under a given > ATT, we can eliminate this option. So, we can add this Sub-type, or just > state the network-name can be SSID, when the ATT is 802.11, or PLMIND for > other other UMTS/LTE access. I see. Until there arises a requirement that there could be multiple network names for one access type, we can live with a combination of the ATT option and ANI option without NType. Thanks for your clarification, -- Hidetoshi > Regards > Sri > > > > > > From jouni.nospam@gmail.com Wed Feb 8 00:48:34 2012 Return-Path: <jouni.nospam@gmail.com> 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 66A5E21F8592 for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 00:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 2pq62xw7blQK for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 00:48:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF621F8587 for <netext@ietf.org>; Wed, 8 Feb 2012 00:48:23 -0800 (PST) Received: by qafi29 with SMTP id i29so3251942qaf.10 for <netext@ietf.org>; Wed, 08 Feb 2012 00:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Y1MtJIvKbTNiIUwOZilG4M0VdsJ9LRrkp1Ql7Rcn2HI=; b=ak7UGAuqy0gLCsrJP+75OyUHrIp1Sbin7bcG3vsWsogZMuhc0jHfKc47t6gILw4c/G TLG5QRVB2pNn6twEkZqVapj2IFW4f43Ie99+VhV+cLJO7hyNzuikZFUYZQOd62gS7Q5u nEK0J7HkR4EjXdjolFbZK9q5kmItWoAX7HAP4= Received: by 10.224.190.6 with SMTP id dg6mr19171613qab.25.1328690899737; Wed, 08 Feb 2012 00:48:19 -0800 (PST) Received: from [10.255.132.44] ([192.100.123.77]) by mx.google.com with ESMTPS id el3sm1552123qab.8.2012.02.08.00.48.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 00:48:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen <jouni.nospam@gmail.com> In-Reply-To: <4F2E645B.6060104@kddilabs.jp> Date: Wed, 8 Feb 2012 10:48:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: <A264F854-8247-4589-A613-FD59CA739C13@gmail.com> References: <4F2E645B.6060104@kddilabs.jp> To: Hidetoshi Yokota <yokota@kddilabs.jp> X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2012 08:48:34 -0000 Hidetoshi-san, On Feb 5, 2012, at 1:13 PM, Hidetoshi Yokota wrote: > Hi Sri, > > The latest version is well written, but I have just one comment on > Network-Identifier Sub-Option. According to the discussion with Raj, the > network name should not be only WLAN SSID, but also PLMN ID for example. > So, the text in Section 3.1.1 should be modified as follows: Actually.. Section 3.1.3 has Operator-Identifier and there we got realm of the operator. It is common practice to express MNC & MCC codes as "NAI realms". This was my thinking when we added realm there. There is a bit of semantical overlap but MNC & MCC codes also identify the operator and the network, at least in this case. So I am not too sure we need to tweak the Section 3.1.1 Network-Identifier any further. I rather keep it as it was now and at most change the option name to something more closer to SSID. - Jouni > > In Section 3.1.1: > > --- Current text ---- > SSID: SSID of the access network to which the mobile node is > attached. The string is carried in UTF-8 representation. > --- Proposed text --- > Network Name: The name of the access network to which the mobile > node is attached. The string is carried in UTF-8 representation. > --------------------- > > As an example of the Network Name, it is a good idea to include the PLMN > ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. > > If I can add one more thing, it would be more convenient to add the > network name type (NType) before the Network Name strings as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ANI Type=1 | ANI Length | NType | Network Name ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NType: SSID (0), PLMN ID (1), ... > > [As a side note, 3GPP2 has also defined the Access Network Identifier > (ANID)] > > This is just a suggestion and if it looks too much complex, you can > ignore it. > > Regards, > -- > Hidetoshi > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Feb 8 07:03:40 2012 Return-Path: <sgundave@cisco.com> 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 CAF6321F85E7 for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 P0TQKR7NFIHH for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:03:40 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8C521F8546 for <netext@ietf.org>; Wed, 8 Feb 2012 07:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1874; q=dns/txt; s=iport; t=1328713420; x=1329923020; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=j2XrjrrDplVl3stDzUt2/+eEaBxL1dPj/w2Jz4Q9NLA=; b=RmA0KizmJo4vQsqXSetGNnRFyPNLyJwSWlIgPeShZjyaHlax+2D05C0c FzSu9RYU3Shy4eKxzWmhoINk9eoClY5GTmAQ5IsTPjeh04X8SBy5LVsQe 3x6VMMhvxeNV/XYMREZ7OZzSV/UHO5jn3tPNUwpsDXIWEP8ozqsqjmYeE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPWNMk+rRDoI/2dsb2JhbABDr2qBB4FyAQEBAwEBAQEPAScCATEEDA0BCG0wAQEEARIbB4daCZpnAZ5nBItLASkTAQgFAwMJBwEHBwIHhCaDWQSIRoxnkn4 X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="29173298" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Feb 2012 15:03:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q18F3cqF008418; Wed, 8 Feb 2012 15:03:38 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:03:38 -0800 Received: from 10.21.80.5 ([10.21.80.5]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2012 15:03:37 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 08 Feb 2012 07:03:36 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <pierrick.seite@orange.com>, <netext@ietf.org> Message-ID: <CB57CEC8.39B13%sgundave@cisco.com> Thread-Topic: [netext] use-cases of draft-ietf-netext-logical-interface-support Thread-Index: AczliKlCnkdcjYMARrmv0/IHxEYr7QA6iuss In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462022B3DA6@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2012 15:03:38.0098 (UTC) FILETIME=[D62F3520:01CCE672] Subject: Re: [netext] use-cases of draft-ietf-netext-logical-interface-support 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2012 15:03:40 -0000 Hi Pierrick, Section 6, is listing three scenarios where logical interface is relevant, as a set of example use-cases. 1. Multihoming Support (what is specified in RFC5213) 2. Inter-technology handovers (what is specified in RFC 5213) 3. Flow Mobility (Carlos Doc ..) #1 and #2 have no discussion/relation on the LMA initiated signaling. The UE brings up one interface and does an handoff to a different interface, or brings up a new interface. There is no LMA initiated signaling from LMA to MAG. #3 covers about flow mobility. There I believe some text which talks about signaling, which we need to fix. >From logical interface draft perspective, the draft only deals with the interface abstraction and ND interworking, it should not be aware of signaling aspects, LMA-initiated or MAG initiated. At an point, it attaches/detaches an interface to the network and how the logical interface construct hides these different interfaces and presents a single logical interface to the applications. I will fix text in #3. Regards Sri On 2/7/12 3:07 AM, "pierrick.seite@orange.com" <pierrick.seite@orange.com> wrote: > Hi Tele and Sri, > > The WG has decided to specify the flow mobility without LMA-Initiated > handover. However, section 6 (use-cases) of > draft-ietf-netext-logical-interface-support focuses only on > LMA-initiated handover. I'm not saying that LMA-Initiated use-case is > irrelevant and I've no problem to include it in the document dealing > with LI support. But for the sake of consistency with the solution > draft, I think that draft-ietf-netext-logical-interface-support should > also cover MN-initiated handovers. What do you think? > > BR, > Pierrick > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From pierrick.seite@orange.com Wed Feb 8 07:07:00 2012 Return-Path: <pierrick.seite@orange.com> 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 7EAFB21F8701 for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 T6eHwldsm-W7 for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:06:59 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0F21F85FB for <netext@ietf.org>; Wed, 8 Feb 2012 07:06:59 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B0B3FE1C00A; Wed, 8 Feb 2012 16:08:25 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A65D8E1C001; Wed, 8 Feb 2012 16:08:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 16:06:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 16:06:56 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462022FC346@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <CB57CEC8.39B13%sgundave@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] use-cases of draft-ietf-netext-logical-interface-support Thread-Index: AczliKlCnkdcjYMARrmv0/IHxEYr7QA6iussAAAcHcA= References: <843DA8228A1BA74CA31FB4E111A5C462022B3DA6@ftrdmel0.rd.francetelecom.fr> <CB57CEC8.39B13%sgundave@cisco.com> From: <pierrick.seite@orange.com> To: <sgundave@cisco.com>, <netext@ietf.org> X-OriginalArrivalTime: 08 Feb 2012 15:06:57.0399 (UTC) FILETIME=[4CFA2070:01CCE673] Subject: Re: [netext] use-cases of draft-ietf-netext-logical-interface-support 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2012 15:07:00 -0000 Ok, Thanks. > -----Message d'origine----- > De=A0: Sri Gundavelli [mailto:sgundave@cisco.com] > Envoy=E9=A0: mercredi 8 f=E9vrier 2012 16:04 > =C0=A0: SEITE Pierrick RD-RESA-REN; netext@ietf.org > Objet=A0: Re: [netext] use-cases of = draft-ietf-netext-logical-interface- > support >=20 > Hi Pierrick, >=20 > Section 6, is listing three scenarios where logical interface is > relevant, > as a set of example use-cases. >=20 > 1. Multihoming Support (what is specified in RFC5213) > 2. Inter-technology handovers (what is specified in RFC 5213) > 3. Flow Mobility (Carlos Doc ..) >=20 > #1 and #2 have no discussion/relation on the LMA initiated signaling. > The UE > brings up one interface and does an handoff to a different interface, > or > brings up a new interface. There is no LMA initiated signaling from = LMA > to > MAG. #3 covers about flow mobility. There I believe some text which > talks > about signaling, which we need to fix. >=20 > From logical interface draft perspective, the draft only deals with = the > interface abstraction and ND interworking, it should not be aware of > signaling aspects, LMA-initiated or MAG initiated. At an point, it > attaches/detaches an interface to the network and how the logical > interface > construct hides these different interfaces and presents a single > logical > interface to the applications. >=20 > I will fix text in #3. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 2/7/12 3:07 AM, "pierrick.seite@orange.com" > <pierrick.seite@orange.com> > wrote: >=20 > > Hi Tele and Sri, > > > > The WG has decided to specify the flow mobility without = LMA-Initiated > > handover. However, section 6 (use-cases) of > > draft-ietf-netext-logical-interface-support focuses only on > > LMA-initiated handover. I'm not saying that LMA-Initiated use-case = is > > irrelevant and I've no problem to include it in the document dealing > > with LI support. But for the sake of consistency with the solution > > draft, I think that draft-ietf-netext-logical-interface-support > should > > also cover MN-initiated handovers. What do you think? > > > > BR, > > Pierrick > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Feb 8 07:23:22 2012 Return-Path: <sgundave@cisco.com> 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 03A2A21F8598 for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 fqMT1MbFQf-h for <netext@ietfa.amsl.com>; Wed, 8 Feb 2012 07:23:21 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 163F221F855D for <netext@ietf.org>; Wed, 8 Feb 2012 07:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3422; q=dns/txt; s=iport; t=1328714601; x=1329924201; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=e2aA1lnBpZYLxOlGusH1TeCd6tFphmuXLRg5MXn71iU=; b=X3qolNYOWZsDAbGT9BE5YtzBNYiSazh/6freh+xftZuV2KigXCA76/4c VA91nHv6IEbGBWIA2y673uZ1WbQ9zO23x1U1yC7P40bjIX7+rQIFcUd5T PC2htexMRxLi4GHENkPYYZMe87o02NeNvYWIJQKpa4As4c20okrvHsDIH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIeSMk+rRDoG/2dsb2JhbAA5Cq9rgQeBcgEBAQMBAQEBDwEnAgEqBwsFDQEIGE8GMAEBBAENBSKHWgmaYwGeaQSIHE6CYQEpEwEIBQMDCQcBBwcChC2DWQSIRoxniwyHcg X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="29176294" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Feb 2012 15:23:21 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q18FNKiZ028914; Wed, 8 Feb 2012 15:23:20 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:23:20 -0800 Received: from 10.21.80.5 ([10.21.80.5]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2012 15:23:20 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 08 Feb 2012 07:23:19 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: jouni korhonen <jouni.nospam@gmail.com>, Hidetoshi Yokota <yokota@kddilabs.jp> Message-ID: <CB57D367.39B3E%sgundave@cisco.com> Thread-Topic: [netext] Review of ID: draft-ietf-netext-access-network-option-05.txt Thread-Index: AczmdZYOfMiN7kVNj06DmSlBcNRgEw== In-Reply-To: <A264F854-8247-4589-A613-FD59CA739C13@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2012 15:23:20.0520 (UTC) FILETIME=[96F67C80:01CCE675] Cc: netext@ietf.org Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Feb 2012 15:23:22 -0000 Hi Jouni: Between the two information elements, I saw the difference as, Network Identifier is for carrying the name of the network that is being hosted. The network elements are aware of this network-name (Ex: SSID). Whereas, Operator-Id is more a business entity, which is not visible to any of the network nodes (Ex: Cisco, ATT). Now, if I take WLAN as an example, if Ex: Operator AT&T is hosting SSID, "ATT-Internet", the Network-name is "ATT-Internet", where as the Operator-Id is the SMI Enterprise Id for AT&T. Mapping the same logic for 3GPP, I assume the PLMNID is exposed to the network elements and is a network-name, where the operator id is of the 3GPP operator Id. If the operator id is embedded in the network-name, its just an approach, and the same can be true for WLAN access as well. So, should the PLMNID be in the network-name option ? Regards Sri On 2/8/12 12:48 AM, "jouni korhonen" <jouni.nospam@gmail.com> wrote: > Hidetoshi-san, > > On Feb 5, 2012, at 1:13 PM, Hidetoshi Yokota wrote: > >> Hi Sri, >> >> The latest version is well written, but I have just one comment on >> Network-Identifier Sub-Option. According to the discussion with Raj, the >> network name should not be only WLAN SSID, but also PLMN ID for example. >> So, the text in Section 3.1.1 should be modified as follows: > > Actually.. Section 3.1.3 has Operator-Identifier and there we got > realm of the operator. It is common practice to express MNC & MCC > codes as "NAI realms". This was my thinking when we added realm there. > There is a bit of semantical overlap but MNC & MCC codes also > identify the operator and the network, at least in this case. > > So I am not too sure we need to tweak the Section 3.1.1 > Network-Identifier any further. I rather keep it as it was now > and at most change the option name to something more closer to > SSID. > > - Jouni > > > >> >> In Section 3.1.1: >> >> --- Current text ---- >> SSID: SSID of the access network to which the mobile node is >> attached. The string is carried in UTF-8 representation. >> --- Proposed text --- >> Network Name: The name of the access network to which the mobile >> node is attached. The string is carried in UTF-8 representation. >> --------------------- >> >> As an example of the Network Name, it is a good idea to include the PLMN >> ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. >> >> If I can add one more thing, it would be more convenient to add the >> network name type (NType) before the Network Name strings as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ANI Type=1 | ANI Length | NType | Network Name ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> NType: SSID (0), PLMN ID (1), ... >> >> [As a side note, 3GPP2 has also defined the Access Network Identifier >> (ANID)] >> >> This is just a suggestion and if it looks too much complex, you can >> ignore it. >> >> Regards, >> -- >> Hidetoshi >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From internet-drafts@ietf.org Thu Feb 9 21:23:27 2012 Return-Path: <internet-drafts@ietf.org> 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 AB3C521F854B; Thu, 9 Feb 2012 21:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 NmWRvMMvHs+L; Thu, 9 Feb 2012 21:23:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A563721E806B; Thu, 9 Feb 2012 21:23:23 -0800 (PST) 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: 3.64p1 Message-ID: <20120210052321.20666.21911.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 21:23:21 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-sipto-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2012 05:23:27 -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 Wor= king Group of the IETF. Title : IPv4 Traffic Offload Selector Option for Proxy Mobile IP= v6 Author(s) : Sri Gundavelli Xingyue Zhou Jouni Korhonen Rajeev Koodli Filename : draft-ietf-netext-pmipv6-sipto-option-04.txt Pages : 12 Date : 2012-02-09 This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-0= 4.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-sipto-option-04= .txt From internet-drafts@ietf.org Thu Feb 9 21:42:33 2012 Return-Path: <internet-drafts@ietf.org> 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 3027121F8644; Thu, 9 Feb 2012 21:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 ZlPWT+QDlYgn; Thu, 9 Feb 2012 21:42:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981021F863C; Thu, 9 Feb 2012 21:42:32 -0800 (PST) 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: 3.64p1 Message-ID: <20120210054232.25142.24770.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 21:42:32 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-06.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2012 05:42:33 -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 Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-06.txt Pages : 16 Date : 2012-02-09 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 06.txt From sgundave@cisco.com Thu Feb 9 21:45:45 2012 Return-Path: <sgundave@cisco.com> 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 B1EC321F865D for <netext@ietfa.amsl.com>; Thu, 9 Feb 2012 21:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 pWjpJdh+PIlS for <netext@ietfa.amsl.com>; Thu, 9 Feb 2012 21:45:36 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 165A221F8658 for <netext@ietf.org>; Thu, 9 Feb 2012 21:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1731; q=dns/txt; s=iport; t=1328852736; x=1330062336; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=N2361G/NjPHOTwkYU8ZsgWooYjC6PJsVVHMCnfoyP2U=; b=Vdwd8yHl4OijyzTMFTHMqE6ruE2da2wPR7Oj9Xfg6ASA3CYIwR09r/Io MYKSX2H4k25ABuBanx+ENshFN7ltTsI/Gd7PMjjMpNcsAb4E4jJpRCTNG 9rkgS6JFG1Y+dfdqWy9SIXPxR7PAG1Y0yy9WLD+1fjMmWN8fkcdPLyJS0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALmuNE+rRDoG/2dsb2JhbABDr2CBB4FyAQEBAwESASkBQQ0BCIEdAQEEARIih1qaBAGeeIs6KgIVNxQBCg6EP4M9BIgWM4xnkwM X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="29645049" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Feb 2012 05:45:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1A5jUhn003879; Fri, 10 Feb 2012 05:45:30 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 21:45:30 -0800 Received: from 10.21.112.166 ([10.21.112.166]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Feb 2012 05:45:30 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 09 Feb 2012 21:45:29 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <cjbc@it.uc3m.es>, "netext@ietf.org" <netext@ietf.org> Message-ID: <CB59EEF9.39FBD%sgundave@cisco.com> Thread-Topic: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: AczntzHztgiegDINjEi75K+JMFSheQ== In-Reply-To: <1328515089.3833.8.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 10 Feb 2012 05:45:30.0699 (UTC) FILETIME=[32F721B0:01CCE7B7] Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2012 05:45:46 -0000 Hi Carlos, Thanks for the review. Please see inline ... On 2/5/12 11:58 PM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote: > Hi, >=20 > Some additional comments after a quick review of the draft: >=20 > - Section 3.1: I think there is a problem with the references, because > it appears in thge text: "If the received Proxy Binding Update includes > the IP Traffic Offload Selector option Section 4". I guess it should > say: "If the received Proxy Binding Update includes the IP Traffic > Offload Selector option (Section 4)". There are more instances referring > to other sections. Thanks. Fixed it. >=20 > - Section 4. The IPTS options has the field "TS Format", which resembles > the option defined in RFC 6089 for the traffic selector sub-option, and > in this way re-uses the binary TS defined for IPv4 in RFC 6088. However, > the draft defines a new IANA space for this "TS Format" field, which > might be a bit confusing. Can we just re-use RFC 6089 space (now it only > has three values reserved: "0" that should not be used, and "1" for > binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some > redundancy that might lead to confusion. If we do that, the draft would > probably need to define a flag or something to catch what it is now done > by putting a "TS Format" equal to "0". > This is a very good point. Fixed it. =20 > - By doing offloading, there are issues associated to handovers (if the > mobile node moves, any traffic that was being offloaded would need to be > restarted). I guess some text on that would be helfpul. > Sure. Added couple of lines of text on this. Regards Sri =20 > Hope this helps, >=20 > Carlos From jouni.nospam@gmail.com Thu Feb 9 23:39:53 2012 Return-Path: <jouni.nospam@gmail.com> 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 855AD21E803B for <netext@ietfa.amsl.com>; Thu, 9 Feb 2012 23:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 RboGFqf4fXcw for <netext@ietfa.amsl.com>; Thu, 9 Feb 2012 23:39:53 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E210121E801B for <netext@ietf.org>; Thu, 9 Feb 2012 23:39:51 -0800 (PST) Received: by qan41 with SMTP id 41so1568391qan.10 for <netext@ietf.org>; Thu, 09 Feb 2012 23:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cxXUBLp0XQ0LmSPk7x3PCt4b/z6ajTPUPpUxH8B/0/s=; b=jrOnLfpoK2P7DZnPTlo1GXtyHL1nz3j/zz51iHkaban4yPe7Hgsiw3p5XUKouY7T0D gGBHiuf7wvt5e4AvWyhgQJJ2iDhebGS/BSMRunBZN0Pen/lK7gBoMFTVvuHJ9aNtha6H jhCncCEguzRBZuDoOHafF+LlFF92gkKLZEzBE= Received: by 10.229.77.12 with SMTP id e12mr3565908qck.41.1328859589743; Thu, 09 Feb 2012 23:39:49 -0800 (PST) Received: from [10.255.128.151] ([192.100.123.77]) by mx.google.com with ESMTPS id fi8sm11230802qab.21.2012.02.09.23.39.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 23:39:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen <jouni.nospam@gmail.com> In-Reply-To: <4F2E645B.6060104@kddilabs.jp> Date: Fri, 10 Feb 2012 09:39:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: <B8EECEAC-3340-42D3-A430-6CA25580C6B9@gmail.com> References: <4F2E645B.6060104@kddilabs.jp> To: Hidetoshi Yokota <yokota@kddilabs.jp> X-Mailer: Apple Mail (2.1084) Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2012 07:39:53 -0000 Hidetoshi-san, A question regarding the 3GPP2 ANID. Is it using the same values as 3GPP 24302 ANID? - Jouni On Feb 5, 2012, at 1:13 PM, Hidetoshi Yokota wrote: > Hi Sri, > > The latest version is well written, but I have just one comment on > Network-Identifier Sub-Option. According to the discussion with Raj, the > network name should not be only WLAN SSID, but also PLMN ID for example. > So, the text in Section 3.1.1 should be modified as follows: > > In Section 3.1.1: > > --- Current text ---- > SSID: SSID of the access network to which the mobile node is > attached. The string is carried in UTF-8 representation. > --- Proposed text --- > Network Name: The name of the access network to which the mobile > node is attached. The string is carried in UTF-8 representation. > --------------------- > > As an example of the Network Name, it is a good idea to include the PLMN > ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. > > If I can add one more thing, it would be more convenient to add the > network name type (NType) before the Network Name strings as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ANI Type=1 | ANI Length | NType | Network Name ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NType: SSID (0), PLMN ID (1), ... > > [As a side note, 3GPP2 has also defined the Access Network Identifier > (ANID)] > > This is just a suggestion and if it looks too much complex, you can > ignore it. > > Regards, > -- > Hidetoshi > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From iesg-secretary@ietf.org Fri Feb 10 08:30:13 2012 Return-Path: <iesg-secretary@ietf.org> 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 A923821F8645; Fri, 10 Feb 2012 08:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 V0jGSn1bbKvB; Fri, 10 Feb 2012 08:30:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C709A21F86D0; Fri, 10 Feb 2012 08:30:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120210163012.28867.60375.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2012 08:30:12 -0800 Cc: netext mailing list <netext@ietf.org>, netext chair <netext-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [netext] Protocol Action: 'RADIUS Support for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-radius-pmip6-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Feb 2012 16:30:13 -0000 The IESG has approved the following document: - 'RADIUS Support for Proxy Mobile IPv6' (draft-ietf-netext-radius-pmip6-08.txt) as a Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ Technical Summary This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol specified here uses RADIUS based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches to the network, authenticates and authorizes within a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. Additionally, this document specifies the baseline for the mobile access gateway and the local mobility anchor generated accounting. Working group summary: The document has been reviewed by several RADIUS protocol experts as well as key members within the working group. It has undergone two working group last calls and has been revised based on feedback from reviewers as well as implementation experience. There is strong WG consensus behind this document. Document quality: There is at least one known implementation of the protocol. Multiple vendors have indicated plans to implement this specification. All the key people who have reviewed this I-D are acknowledged in the document. Personnel The Document Shepherd is Basavaraj Patil, and the responsible Area Director is Jari Arkko. From yokota@kddilabs.jp Sat Feb 11 06:40:51 2012 Return-Path: <yokota@kddilabs.jp> 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 00E8721F84C5 for <netext@ietfa.amsl.com>; Sat, 11 Feb 2012 06:40:50 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] 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 hfc3ZhYXY5VP for <netext@ietfa.amsl.com>; Sat, 11 Feb 2012 06:40:50 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 6947A21F84C9 for <netext@ietf.org>; Sat, 11 Feb 2012 06:40:01 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 714B71748117; Sat, 11 Feb 2012 23:39:55 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKZEq1B4NEc7; Sat, 11 Feb 2012 23:39:54 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1418917480E9; Sat, 11 Feb 2012 23:39:54 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id B27E81B9B1; Sat, 11 Feb 2012 23:39:27 +0900 (JST) Message-ID: <4F367DB7.5070900@kddilabs.jp> Date: Sat, 11 Feb 2012 23:39:51 +0900 From: Hidetoshi Yokota <yokota@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: jouni korhonen <jouni.nospam@gmail.com> References: <4F2E645B.6060104@kddilabs.jp> <B8EECEAC-3340-42D3-A430-6CA25580C6B9@gmail.com> In-Reply-To: <B8EECEAC-3340-42D3-A430-6CA25580C6B9@gmail.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" <netext@ietf.org> Subject: Re: [netext] Review of ID: draft-ietf-netext-access-network-option-05.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 11 Feb 2012 14:40:51 -0000 Hi Jouni, (2012/02/10 16:39), jouni korhonen wrote: > Hidetoshi-san, > > A question regarding the 3GPP2 ANID. Is it using the same values > as 3GPP 24302 ANID? No, it's different. 24302's ANID is like "HRPD" or "WIMAX", but 3GPP2's ANID is composed of the System ID (SID), Network ID (NID), and Packet Zone ID (PZID). I think the latest spec is below: 3GPP2 TSG-A, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network", A.S0008-A v3.0, October 2008. Regards, -- Hidetoshi > - Jouni > > > On Feb 5, 2012, at 1:13 PM, Hidetoshi Yokota wrote: > >> Hi Sri, >> >> The latest version is well written, but I have just one comment on >> Network-Identifier Sub-Option. According to the discussion with Raj, the >> network name should not be only WLAN SSID, but also PLMN ID for example. >> So, the text in Section 3.1.1 should be modified as follows: >> >> In Section 3.1.1: >> >> --- Current text ---- >> SSID: SSID of the access network to which the mobile node is >> attached. The string is carried in UTF-8 representation. >> --- Proposed text --- >> Network Name: The name of the access network to which the mobile >> node is attached. The string is carried in UTF-8 representation. >> --------------------- >> >> As an example of the Network Name, it is a good idea to include the PLMN >> ID, which is composed of MCC and MNC, in addition to the SSID of WLAN. >> >> If I can add one more thing, it would be more convenient to add the >> network name type (NType) before the Network Name strings as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ANI Type=1 | ANI Length | NType | Network Name ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> NType: SSID (0), PLMN ID (1), ... >> >> [As a side note, 3GPP2 has also defined the Access Network Identifier >> (ANID)] >> >> This is just a suggestion and if it looks too much complex, you can >> ignore it. >> >> Regards, >> -- >> Hidetoshi >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > > From cjbc@it.uc3m.es Mon Feb 13 08:51:22 2012 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B677421F8740 for <netext@ietfa.amsl.com>; Mon, 13 Feb 2012 08:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwCAGO1i4M0w for <netext@ietfa.amsl.com>; Mon, 13 Feb 2012 08:51:21 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2B37321F873B for <netext@ietf.org>; Mon, 13 Feb 2012 08:51:20 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B793F9C6139; Mon, 13 Feb 2012 17:51:19 +0100 (CET) Message-ID: <1329151879.4133.57.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: pierrick.seite@orange.com Date: Mon, 13 Feb 2012 17:51:19 +0100 In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462022B3876@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C462022B3876@ftrdmel0.rd.francetelecom.fr> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bSgHQiQ7pTY/wgTifXc5" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18708.000 Cc: netext@ietf.org Subject: Re: [netext] comments/question on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Feb 2012 16:51:23 -0000 --=-bSgHQiQ7pTY/wgTifXc5 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Pierrick, Sorry for the late answer, last week I was on a business trip. Thanks for your comments. Please see inline below. On Fri, 2012-02-03 at 14:58 +0100, pierrick.seite@orange.com wrote: > Hi Carlos and flowmob authors, >=20 > In draft-ietf-netext-pmipv6-flowmob-02, LMA-initiated handover is > supposed to be out-of-scope > (http://www.ietf.org/mail-archive/web/netext/current/msg02184.html). >=20 > However, on section 3.2.2, it is stated: >=20 > The trigger for the flow movement can be on the mobile node (e.g., by > using layer-2 signaling, by explicitly start sending flow packets via a > new interface, etc.) or on the network (e.g., based on congestion and > measurements performed at the network). >=20 > It should be: >=20 > ------------------------ >=20 > The trigger for the flow movement is on the mobile node (e.g., by using > layer-2 signaling, by explicitly start sending flow packets via a new > interface, etc.). >=20 > ------------------------- >=20 That part of the text just provides some examples of potential triggers, but the draft now only describes MN-initiated handovers. The specific triggers for initiating a handover are out of the scope of the document. > Moreover, call-flows (figures 2 and 4) show the operation "handover > decision" over multiple entities, including MN, MAGs and LMA. It is > confusing; the handover decision should be only on the MN side. Example: >=20 > +-----+ +------+ +------+ +-----+ > Internet | LMA | | MAG1 | | MAG2 | | MN1 | > +-----+ +------+ +------+ +-----+ > | | | | | > | flow X to | flow X to | flow X to | > | pref1::lif | pref1::lif | pref1::lif | > |<----------->|<--------------->|<-------------------------->if1 > | flow Y to | flow Y to | flow Y to | > | pref1::lif | pref1::lif | pref1::lif | > |<----------->|<------------------------------->|<---------->if2 > | | | | | > | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | > decision to=20 > | | | | | move > flow Y=20 > | | | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | > | flow Y to | flow Y to | flow Y to | > | pref1::lif | pref1::lif | pref1::lif | > |<----------->|<--------------->|<-------------------------->if1 > | | | | | >=20 >=20 > Now, my question: >=20 > With a MN driven handover decision, I do not understand the scenario "MN > with different sets of prefixes on each MAG". Quoting section 3.2.2: >=20 > "If the flow is being moved from its default path (which is determined > by the destination prefix) to a different one, the LMA constructs a Flow > Mobility Initiate (FMI) message."=20 >=20 > I understand the reason for FMI, but how the LMA can be aware of the > handover if the decision is made by the MN? In other words, what is the > trigger for FMI initiation? My understanding is that the scenario > relying on FMI/FMA can only be a LMA-initiated handover scenario; thus > should be addressed in another document. Again, this trigger is outside of the scope of the document. Thanks, Carlos >=20 > BR, > Pierrick > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-bSgHQiQ7pTY/wgTifXc5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk85P4cACgkQNdy6TdFwT2dm7QCffSK9zhPfC3mJlI3zP5EhDY6T V3oAoN/yTWgzu7u/0X1UEK3X/SE62ecg =f1rV -----END PGP SIGNATURE----- --=-bSgHQiQ7pTY/wgTifXc5-- From internet-drafts@ietf.org Mon Feb 13 22:22:15 2012 Return-Path: <internet-drafts@ietf.org> 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 ED48421E8075; Mon, 13 Feb 2012 22:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, 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 y+F5UKefKJoC; Mon, 13 Feb 2012 22:22:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3A321E8067; Mon, 13 Feb 2012 22:21:48 -0800 (PST) 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: 3.64p2 Message-ID: <20120214062148.3483.8476.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 22:21:48 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-11.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Feb 2012 06:22:15 -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 Wor= king Group of the IETF. Title : Bulk Binding Update Support for Proxy Mobile IPv6 Author(s) : Fuad Abinader Sri Gundavelli Kent Leung Suresh Krishnan Domagoj Premec Filename : draft-ietf-netext-bulk-re-registration-11.txt Pages : 23 Date : 2012-02-13 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-= 11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-1= 1.txt From pierrick.seite@orange.com Tue Feb 14 02:18:05 2012 Return-Path: <pierrick.seite@orange.com> 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 764B021F8796 for <netext@ietfa.amsl.com>; Tue, 14 Feb 2012 02:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, 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 uYNGfxqmzheU for <netext@ietfa.amsl.com>; Tue, 14 Feb 2012 02:18:04 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id EB66F21F8762 for <netext@ietf.org>; Tue, 14 Feb 2012 02:18:03 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0302F1074002; Tue, 14 Feb 2012 11:18:46 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id EC7B31074001; Tue, 14 Feb 2012 11:18:45 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 11:18:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 11:17:59 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462022FCD73@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1329151879.4133.57.camel@acorde.it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] comments/question on draft-ietf-netext-pmipv6-flowmob Thread-Index: Aczqb7aayw2aNkXYSYmhNx4WT/E/VwAiYiJw References: <843DA8228A1BA74CA31FB4E111A5C462022B3876@ftrdmel0.rd.francetelecom.fr> <1329151879.4133.57.camel@acorde.it.uc3m.es> From: <pierrick.seite@orange.com> To: <cjbc@it.uc3m.es> X-OriginalArrivalTime: 14 Feb 2012 10:18:01.0414 (UTC) FILETIME=[EE673E60:01CCEB01] Cc: netext@ietf.org Subject: Re: [netext] comments/question on draft-ietf-netext-pmipv6-flowmob 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Feb 2012 10:18:05 -0000 Hi Carlos, I agree that triggers are out of scope and that we can leave the door = open to different scenarios. But, at least, the I-D should clearly = describe the scenario where the MN sends flow packets via a new = interface. It would remove any ambiguity on protocol operation as it = does not rely on unknown triggers. I don't want to reopen long ML = discussion we had on triggers, but I think that the document would have = more weight if implementers could have a clear understanding of the = protocol in above simple handover scenario. So, I'm not suggesting deep = modification of the I-D, I'm just suggesting to stress and clarify some = points.=20 Pierrick > -----Message d'origine----- > De=A0: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Envoy=E9=A0: lundi 13 f=E9vrier 2012 17:51 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: netext@ietf.org > Objet=A0: Re: [netext] comments/question on draft-ietf-netext-pmipv6- > flowmob >=20 > Hi Pierrick, >=20 > Sorry for the late answer, last week I was on a business trip. >=20 > Thanks for your comments. Please see inline below. >=20 > On Fri, 2012-02-03 at 14:58 +0100, pierrick.seite@orange.com wrote: > > Hi Carlos and flowmob authors, > > > > In draft-ietf-netext-pmipv6-flowmob-02, LMA-initiated handover is > > supposed to be out-of-scope > > (http://www.ietf.org/mail-archive/web/netext/current/msg02184.html). > > > > However, on section 3.2.2, it is stated: > > > > The trigger for the flow movement can be on the mobile node (e.g., = by > > using layer-2 signaling, by explicitly start sending flow packets = via > > a new interface, etc.) or on the network (e.g., based on congestion > > and measurements performed at the network). > > > > It should be: > > > > ------------------------ > > > > The trigger for the flow movement is on the mobile node (e.g., by > > using > > layer-2 signaling, by explicitly start sending flow packets via a = new > > interface, etc.). > > > > ------------------------- > > >=20 > That part of the text just provides some examples of potential > triggers, but the draft now only describes MN-initiated handovers. The > specific triggers for initiating a handover are out of the scope of = the > document. >=20 > > Moreover, call-flows (figures 2 and 4) show the operation "handover > > decision" over multiple entities, including MN, MAGs and LMA. It is > > confusing; the handover decision should be only on the MN side. > Example: > > > > +-----+ +------+ +------+ = +--- > --+ > > Internet | LMA | | MAG1 | | MAG2 | | > MN1 | > > +-----+ +------+ +------+ = +--- > --+ > > | | | | = | > > | flow X to | flow X to | flow X to = | > > | pref1::lif | pref1::lif | pref1::lif = | > > |<----------->|<--------------->|<-------------------------- > >if1 > > | flow Y to | flow Y to | flow Y to = | > > | pref1::lif | pref1::lif | pref1::lif = | > > |<----------->|<------------------------------->|<---------- > >if2 > > | | | | = | > > | | | | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | | | | | > > decision to > > | | | | | > move > > flow Y > > | | | | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | | | | = | > > | flow Y to | flow Y to | flow Y to = | > > | pref1::lif | pref1::lif | pref1::lif = | > > |<----------->|<--------------->|<-------------------------- > >if1 > > | | | | = | > > > > > > Now, my question: > > > > With a MN driven handover decision, I do not understand the scenario > > "MN with different sets of prefixes on each MAG". Quoting section > 3.2.2: > > > > "If the flow is being moved from its default path (which is > determined > > by the destination prefix) to a different one, the LMA constructs a > > Flow Mobility Initiate (FMI) message." > > > > I understand the reason for FMI, but how the LMA can be aware of the > > handover if the decision is made by the MN? In other words, what is > > the trigger for FMI initiation? My understanding is that the = scenario > > relying on FMI/FMA can only be a LMA-initiated handover scenario; > thus > > should be addressed in another document. >=20 > Again, this trigger is outside of the scope of the document. >=20 > Thanks, >=20 > Carlos >=20 > > > > BR, > > Pierrick > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 > -- > Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: = D29B > 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From internet-drafts@ietf.org Tue Feb 14 17:05:51 2012 Return-Path: <internet-drafts@ietf.org> 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 151D021E801A; Tue, 14 Feb 2012 17:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 jrjd+zXCJozI; Tue, 14 Feb 2012 17:05:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7821E8033; Tue, 14 Feb 2012 17:05:27 -0800 (PST) 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: 3.64p2 Message-ID: <20120215010527.32362.45023.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 17:05:27 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-12.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Feb 2012 01:05:51 -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 Wor= king Group of the IETF. Title : Bulk Binding Update Support for Proxy Mobile IPv6 Author(s) : Fuad Abinader Sri Gundavelli Kent Leung Suresh Krishnan Domagoj Premec Filename : draft-ietf-netext-bulk-re-registration-12.txt Pages : 23 Date : 2012-02-14 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-= 12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-1= 2.txt From wwwrun@rfc-editor.org Wed Feb 15 09:52:47 2012 Return-Path: <wwwrun@rfc-editor.org> 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 254B621F8543; Wed, 15 Feb 2012 09:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 Eae6mDEGKEmR; Wed, 15 Feb 2012 09:52:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9D921F84E0; Wed, 15 Feb 2012 09:52:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8890AB1E004; Wed, 15 Feb 2012 09:47:55 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120215174755.8890AB1E004@rfc-editor.org> Date: Wed, 15 Feb 2012 09:47:55 -0800 (PST) Cc: netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 6463 on Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Feb 2012 17:52:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6463 Title: Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 Author: J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui Status: Standards Track Stream: IETF Date: February 2012 Mailbox: jouni.nospam@gmail.com, sri.gundavelli@cisco.com, yokota@kddilabs.jp, Xiangsong.Cui@huawei.com Pages: 22 Characters: 50702 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-redirect-12.txt URL: http://www.rfc-editor.org/rfc/rfc6463.txt This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK] This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Basavaraj.Patil@nokia.com Wed Feb 15 10:11:33 2012 Return-Path: <Basavaraj.Patil@nokia.com> 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 8C9DD21E8029 for <netext@ietfa.amsl.com>; Wed, 15 Feb 2012 10:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.689 X-Spam-Level: X-Spam-Status: No, score=-102.689 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, 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 EDAVkmGQgFMw for <netext@ietfa.amsl.com>; Wed, 15 Feb 2012 10:11:32 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF621E8051 for <netext@ietf.org>; Wed, 15 Feb 2012 10:11:31 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1FIBRiJ018836; Wed, 15 Feb 2012 20:11:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 20:11:27 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Wed, 15 Feb 2012 19:11:26 +0100 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: WGLC: I-D Access Network Identifier (ANI) Option for Proxy Mobile IPv6 Thread-Index: AQHM7A07/ipUQMjSCE6jRbamRDDocA== Date: Wed, 15 Feb 2012 18:11:25 +0000 Message-ID: <CB61516F.1AD36%basavaraj.patil@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <A0EE1C12A7B5704B868D31C7A6B6E779@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2012 18:11:27.0329 (UTC) FILETIME=[3C0FA510:01CCEC0D] X-Nokia-AV: Clean Cc: draft-ietf-netext-access-network-option@tools.ietf.org Subject: [netext] WGLC: I-D Access Network Identifier (ANI) Option for Proxy Mobile IPv6 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Feb 2012 18:11:33 -0000 Hello, This is the working group last call for the I-D: Access Network Identifier (ANI) Option for Proxy Mobile IPv6 <draft-ietf-netext-access-network-option-06.txt> The I-D has been updated by the authors following multiple reviews that have been posted on the mailing list. Abstract: This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. The I-D is intended for publication as a proposed standard. The deadline for receiving comments (i.e end of WG LC) is March 2nd, 2012.=20 Please send your review comments to the mailing list or authors. -Chairs From cjbc@it.uc3m.es Thu Feb 16 13:22:32 2012 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46F21E808D for <netext@ietfa.amsl.com>; Thu, 16 Feb 2012 13:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2ZqaWXxUJj8 for <netext@ietfa.amsl.com>; Thu, 16 Feb 2012 13:22:26 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1921E8051 for <netext@ietf.org>; Thu, 16 Feb 2012 13:22:25 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 970EC9CC2AA; Thu, 16 Feb 2012 22:22:22 +0100 (CET) Message-ID: <1329427342.3028.19.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: pierrick.seite@orange.com Date: Thu, 16 Feb 2012 22:22:22 +0100 In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462022FCD73@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C462022B3876@ftrdmel0.rd.francetelecom.fr> <1329151879.4133.57.camel@acorde.it.uc3m.es> <843DA8228A1BA74CA31FB4E111A5C462022FCD73@ftrdmel0.rd.francetelecom.fr> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HPr7oDfRpdaOfls+1PPI" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18714.002 Cc: netext@ietf.org Subject: Re: [netext] comments/question on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Feb 2012 21:22:32 -0000 --=-HPr7oDfRpdaOfls+1PPI Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Pierrick, OK, thanks for the comment. We'll try to improve the document including the scenario you mentioned. Thanks, Carlos On Tue, 2012-02-14 at 11:17 +0100, pierrick.seite@orange.com wrote: > Hi Carlos, >=20 > I agree that triggers are out of scope and that we can leave the door ope= n to different scenarios. But, at least, the I-D should clearly describe th= e scenario where the MN sends flow packets via a new interface. It would re= move any ambiguity on protocol operation as it does not rely on unknown tri= ggers. I don't want to reopen long ML discussion we had on triggers, but I = think that the document would have more weight if implementers could have a= clear understanding of the protocol in above simple handover scenario. So,= I'm not suggesting deep modification of the I-D, I'm just suggesting to st= ress and clarify some points.=20 >=20 > Pierrick >=20 > > -----Message d'origine----- > > De : Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > > Envoy=E9 : lundi 13 f=E9vrier 2012 17:51 > > =C0 : SEITE Pierrick RD-RESA-REN > > Cc : netext@ietf.org > > Objet : Re: [netext] comments/question on draft-ietf-netext-pmipv6- > > flowmob > >=20 > > Hi Pierrick, > >=20 > > Sorry for the late answer, last week I was on a business trip. > >=20 > > Thanks for your comments. Please see inline below. > >=20 > > On Fri, 2012-02-03 at 14:58 +0100, pierrick.seite@orange.com wrote: > > > Hi Carlos and flowmob authors, > > > > > > In draft-ietf-netext-pmipv6-flowmob-02, LMA-initiated handover is > > > supposed to be out-of-scope > > > (http://www.ietf.org/mail-archive/web/netext/current/msg02184.html). > > > > > > However, on section 3.2.2, it is stated: > > > > > > The trigger for the flow movement can be on the mobile node (e.g., by > > > using layer-2 signaling, by explicitly start sending flow packets via > > > a new interface, etc.) or on the network (e.g., based on congestion > > > and measurements performed at the network). > > > > > > It should be: > > > > > > ------------------------ > > > > > > The trigger for the flow movement is on the mobile node (e.g., by > > > using > > > layer-2 signaling, by explicitly start sending flow packets via a new > > > interface, etc.). > > > > > > ------------------------- > > > > >=20 > > That part of the text just provides some examples of potential > > triggers, but the draft now only describes MN-initiated handovers. The > > specific triggers for initiating a handover are out of the scope of the > > document. > >=20 > > > Moreover, call-flows (figures 2 and 4) show the operation "handover > > > decision" over multiple entities, including MN, MAGs and LMA. It is > > > confusing; the handover decision should be only on the MN side. > > Example: > > > > > > +-----+ +------+ +------+ +--- > > --+ > > > Internet | LMA | | MAG1 | | MAG2 | | > > MN1 | > > > +-----+ +------+ +------+ +--- > > --+ > > > | | | | | > > > | flow X to | flow X to | flow X to | > > > | pref1::lif | pref1::lif | pref1::lif | > > > |<----------->|<--------------->|<-------------------------- > > >if1 > > > | flow Y to | flow Y to | flow Y to | > > > | pref1::lif | pref1::lif | pref1::lif | > > > |<----------->|<------------------------------->|<---------- > > >if2 > > > | | | | | > > > | | | | > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > | | | | | > > > decision to > > > | | | | | > > move > > > flow Y > > > | | | | > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > | | | | | > > > | flow Y to | flow Y to | flow Y to | > > > | pref1::lif | pref1::lif | pref1::lif | > > > |<----------->|<--------------->|<-------------------------- > > >if1 > > > | | | | | > > > > > > > > > Now, my question: > > > > > > With a MN driven handover decision, I do not understand the scenario > > > "MN with different sets of prefixes on each MAG". Quoting section > > 3.2.2: > > > > > > "If the flow is being moved from its default path (which is > > determined > > > by the destination prefix) to a different one, the LMA constructs a > > > Flow Mobility Initiate (FMI) message." > > > > > > I understand the reason for FMI, but how the LMA can be aware of the > > > handover if the decision is made by the MN? In other words, what is > > > the trigger for FMI initiation? My understanding is that the scenario > > > relying on FMI/FMA can only be a LMA-initiated handover scenario; > > thus > > > should be addressed in another document. > >=20 > > Again, this trigger is outside of the scope of the document. > >=20 > > Thanks, > >=20 > > Carlos > >=20 > > > > > > BR, > > > Pierrick > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > >=20 > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D2= 9B > > 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-HPr7oDfRpdaOfls+1PPI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk89c44ACgkQNdy6TdFwT2eRxgCgwJIHyVhi+33uoqWDMaRT4nfl AzsAn2qJ05cEkAGTDfRi+t8WyzKeVkfO =Dv5k -----END PGP SIGNATURE----- --=-HPr7oDfRpdaOfls+1PPI-- From sgundave@cisco.com Tue Feb 21 12:41:52 2012 Return-Path: <sgundave@cisco.com> 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 482E921F87CC for <netext@ietfa.amsl.com>; Tue, 21 Feb 2012 12:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.768 X-Spam-Level: X-Spam-Status: No, score=-8.768 tagged_above=-999 required=5 tests=[AWL=1.831, 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 WezpIWy8Lfxa for <netext@ietfa.amsl.com>; Tue, 21 Feb 2012 12:41:44 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 31CFE21F87C7 for <netext@ietf.org>; Tue, 21 Feb 2012 12:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1058; q=dns/txt; s=iport; t=1329856904; x=1331066504; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=XDTbr6ibnACMLyxU2csjl0ySztATPAeeDSkw+OxqSTU=; b=U8wVGRvctWZ0/x/RAbb8HrVONvku4g8mqQchfhRNjH+LTh599atih7xK KpMc5ervLyncE5ZNq3rlwDkVWMuic/ydHLwIh5QL8Fk4v7opxYwm2opHY Du+Uns7eVvq/oulhWqOYiQR8BeqJBXsVBkgnKjPyeZeLnyuI3Re9knp1L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD4ARE+rRDoG/2dsb2JhbABDskeBB4FzAQEBBBIBJwIBOgISAQgRAwECUCwBAQUDAQEEDgUJGYdnoBABlzOIfIJ5MQEBLQEFBwMChAwDBQYBEA+DHgSIT4xpixeHdw X-IronPort-AV: E=Sophos;i="4.73,459,1325462400"; d="scan'208";a="31484604" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 21 Feb 2012 20:41:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1LKfhmj011561; Tue, 21 Feb 2012 20:41:43 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 12:41:43 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 20:41:35 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 21 Feb 2012 12:41:33 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <CB69417D.3B1DD%sgundave@cisco.com> Thread-Topic: New Version Notification for draft-gundavelli-netext-multiple-apn-pmipv6-00.txt Thread-Index: Aczw2TJWn64gc/ep3EWn24JZGkSSAg== In-Reply-To: <20120221203723.20869.79809.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2012 20:41:43.0946 (UTC) FILETIME=[38DCB6A0:01CCF0D9] Cc: yiu_lee@cable.comcast.com Subject: [netext] FW: New Version Notification for draft-gundavelli-netext-multiple-apn-pmipv6-00.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Feb 2012 20:41:52 -0000 Draft on Multiple APN/Home Network support ..comments welcome. http://www.ietf.org/id/draft-gundavelli-netext-multiple-apn-pmipv6-00.txt ------ Forwarded Message From: <internet-drafts@ietf.org> Date: Tue, 21 Feb 2012 12:37:23 -0800 To: <sgundave@cisco.com> Cc: <denghui02@gmail.com>, <yiu_lee@cable.comcast.com>, <mgrayson@cisco.com>, <sgundave@cisco.com> Subject: New Version Notification for draft-gundavelli-netext-multiple-apn-pmipv6-00.txt A new version of I-D, draft-gundavelli-netext-multiple-apn-pmipv6-00.txt has been successfully submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-netext-multiple-apn-pmipv6 Revision: 00 Title: Multiple APN Support for Trusted Wireless LAN Access Creation date: 2012-02-21 WG ID: Individual Submission Number of pages: 12 Abstract: This specification defines a mechanism for extending multiple APN/ home-network support for a mobile node. The IETF Secretariat ------ End of Forwarded Message From iesg-secretary@ietf.org Tue Feb 21 12:57:59 2012 Return-Path: <iesg-secretary@ietf.org> 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 391B611E80AE; Tue, 21 Feb 2012 12:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, 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 5UzD9Awli-Lo; Tue, 21 Feb 2012 12:57:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97611E80B0; Tue, 21 Feb 2012 12:57:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221205750.29784.5512.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 12:57:50 -0800 Cc: netext mailing list <netext@ietf.org>, netext chair <netext-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [netext] Protocol Action: 'Bulk Binding Update Support for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-bulk-re-registration-12.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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Feb 2012 20:57:59 -0000 The IESG has approved the following document: - 'Bulk Binding Update Support for Proxy Mobile IPv6' (draft-ietf-netext-bulk-re-registration-12.txt) as a Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ Technical Summary For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility agent on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope using of a group identifier. Working Group Summary There is WG consensus regarding this proposal. The I-D has been presented and discussed at several WG meetings. It has also been sufficiently reviewed and the document quality improved over multiple revisions. Document Quality There are no known implementations of this protocol at the present time. WG members who helped with the reviews have been acknowledged in the I-D. The document quality is good and can serve as the basis for an implementation. Clear guidelines for processing by the Mobile Access Gateway and the Local Mobility Agent have been specified. Personnel The responsible Area Director is Jari Arkko. The document shepherd is Basavaraj Patil. RFC Editor Note In the IANA considerations Section, make the following change: OLD: o Action-4: The Sub-type field of the Mobile Node Group Identifier option introduces a new number space. This number space needs to be managed by IANA, under the Registry, Mobile Node Group Identifier Type Registry. This specification reserves the sub- type value of (1) (Bulk Binding Update Group). Approval of new sub-type values are to be made through IANA Expert Review. NEW: o Action-4: The Sub-type field of the Mobile Node Group Identifier option introduces a new number space. This number space needs to be managed by IANA, under the Registry, Mobile Node Group Identifier Type Registry. This specification reserves the sub- type value of (1) (Bulk Binding Update Group). Approval of new sub-type values are to be made through IANA Expert Review. The value range of this field is 0 through 255, but the values 0 and 255 are marked as reserved. The remaining values 2-254 are available for allocation. From Basavaraj.Patil@nokia.com Thu Feb 23 12:36:57 2012 Return-Path: <Basavaraj.Patil@nokia.com> 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 7070321F88A3 for <netext@ietfa.amsl.com>; Thu, 23 Feb 2012 12:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, 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 67I5zewnGzR0 for <netext@ietfa.amsl.com>; Thu, 23 Feb 2012 12:36:56 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1764821F8848 for <netext@ietf.org>; Thu, 23 Feb 2012 12:36:53 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1NKamZD001106 for <netext@ietf.org>; Thu, 23 Feb 2012 22:36:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 22:36:47 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Thu, 23 Feb 2012 21:36:47 +0100 From: <Basavaraj.Patil@nokia.com> To: <netext@ietf.org> Thread-Topic: Soliciting agenda items for WG meeting at IETF83 Thread-Index: AQHM8mrcNmrcimo1Bk+lzOJqgcwjHw== Date: Thu, 23 Feb 2012 20:36:46 +0000 Message-ID: <CB6BFF7D.1B29B%basavaraj.patil@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.42] Content-Type: text/plain; charset="us-ascii" Content-ID: <A6813190D1D492408F79CA0C887F4FA3@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 20:36:47.0654 (UTC) FILETIME=[DD15A460:01CCF26A] X-Nokia-AV: Clean Subject: [netext] Soliciting agenda items for WG meeting at IETF83 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Feb 2012 20:36:57 -0000 Hello, The NetExt WG is scheduled to meet at IETF83 for a 2 hour session on Wednesday afternoon. If you need a slot to present an I-D that is relevant to the scope of the Netext working group please send a request at the earliest to the chairs (netext-chairs@tools.ietf.org) Please include the following information in your request: 1. Name of I-D and a brief statement about its relevance to the WG charter 2. Amount of time needed -Chairs From internet-drafts@ietf.org Sat Feb 25 20:03:18 2012 Return-Path: <internet-drafts@ietf.org> 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 E295321F8619; Sat, 25 Feb 2012 20:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 a1Pz6j8l3qLa; Sat, 25 Feb 2012 20:03:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D6321F85CD; Sat, 25 Feb 2012 20:02:53 -0800 (PST) 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.00 Message-ID: <20120226040253.14732.68490.idtracker@ietfa.amsl.com> Date: Sat, 25 Feb 2012 20:02:53 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Feb 2012 04:03:18 -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 Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-07.txt Pages : 17 Date : 2012-02-25 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 07.txt From sgundave@cisco.com Sat Feb 25 20:12:46 2012 Return-Path: <sgundave@cisco.com> 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 F2D7B21F85A1 for <netext@ietfa.amsl.com>; Sat, 25 Feb 2012 20:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.834 X-Spam-Level: X-Spam-Status: No, score=-8.834 tagged_above=-999 required=5 tests=[AWL=1.765, 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 BWX-qvk9yQ58 for <netext@ietfa.amsl.com>; Sat, 25 Feb 2012 20:12:45 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA621F8569 for <netext@ietf.org>; Sat, 25 Feb 2012 20:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2342; q=dns/txt; s=iport; t=1330229565; x=1331439165; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ynGF6QSAhjZedEOfI+96Qn4WKG99dpoc7dPxSOZzoJ0=; b=kJMn/mEzYJ+AVs2h0Hi8NAkmrXysI6q63RWQkXOO825NyXE5ATua3IQ/ 0kS9n0tM1knwCpWt8Lsqz9faKX+JJI0EDBUbcGskzBQp4GswYwvaroiV6 0HRty9hbTXqydMJwL9n4uskZBRGu5vH/bhirbJ7dYSpcYGAzSYurjvgTp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOqwSU+rRDoH/2dsb2JhbABDsyqBB4FzAQEBAwEBAQEPAScCATEdAQhtMAEBBBMJGYdfBAELn1OBJwGWAY0ODQMTAgINAgJBBgEGBAkChUMBDQcEBhoOgx4EiE+MbpMP X-IronPort-AV: E=Sophos;i="4.73,483,1325462400"; d="scan'208";a="32564372" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 26 Feb 2012 04:12:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1Q4CiAD024424 for <netext@ietf.org>; Sun, 26 Feb 2012 04:12:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Feb 2012 20:12:44 -0800 Received: from 10.21.64.143 ([10.21.64.143]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Sun, 26 Feb 2012 04:12:44 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sat, 25 Feb 2012 20:12:39 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <netext@ietf.org> Message-ID: <CB6EF137.3C5A2%sgundave@cisco.com> Thread-Topic: [netext] I-D Action: draft-ietf-netext-access-network-option-07.txt Thread-Index: Acz0POCV3yuKy1PdMkSgibWcH/sRKg== In-Reply-To: <20120226040253.14732.68490.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Feb 2012 04:12:44.0908 (UTC) FILETIME=[E41AD2C0:01CCF43C] Subject: Re: [netext] I-D Action: draft-ietf-netext-access-network-option-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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Feb 2012 04:12:46 -0000 Minor change to one of the network-name sub-option, based on the offline inputs from few people. The change is for including the AP-name in addition to the SSID. This appears to be a critical information element based on WLAN deployments that are out there today. For applying location specific services, we need both the SSID and AP-name. SSID is too broad, it literally identifies the operator and hence cannot be used for applying any location specific services. For example, some WLAN operators want to display a HTTP Page based on the location to which the user is attached and others want to apply different service tariffs. Regards Sri On 2/25/12 8:02 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network-Based Mobility > Extensions Working Group of the IETF. > > Title : Access Network Identifier (ANI) Option for Proxy Mobile IPv6 > Author(s) : Sri Gundavelli > Jouni Korhonen > Mark Grayson > Kent Leung > Rajesh Pazhyannur > Filename : draft-ietf-netext-access-network-option-07.txt > Pages : 17 > Date : 2012-02-25 > > This specification defines a mechanism and a related mobility option > for carrying the access network identifier and the access operator > identification information from the mobile access gateway to the > local mobility anchor over Proxy Mobile IPv6. Based on the received > information, the local mobility anchor is able to provide access > network and access operator specific handling or policing for the > mobile node traffic. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-07 > .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-07. > txt > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Tue Feb 28 10:51:44 2012 Return-Path: <cjbc@it.uc3m.es> X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56D21F85BB for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 10:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C+gWBvapL5B for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 10:51:42 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEAC21F85B4 for <netext@ietf.org>; Tue, 28 Feb 2012 10:51:39 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 0DE6EC28DE0 for <netext@ietf.org>; Tue, 28 Feb 2012 19:51:35 +0100 (CET) Message-ID: <1330455094.4190.52.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: netext@ietf.org Date: Tue, 28 Feb 2012 19:51:34 +0100 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+XXG/J6Ylxq8rN1W+U4f" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18742.000 Subject: [netext] Review of draft-ietf-netext-pd-pmip-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 18:51:44 -0000 --=-+XXG/J6Ylxq8rN1W+U4f Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, As promised in the last meeting, I've reviewed draft-ietf-netext-pd-pmip-01.txt. Here are my comments: - I think the goals of the document should be more clear, as 3 different concepts are involved: DHCPv6 Prefix Delegation, Proxy Mobile IPv6 and NEMO. Actually, I think this is not an easy problem to solve, because the scenario described in the document is not really a NEMO one (I'll explain this better below). - The abstract says: "This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation.". This is not very aligned with the title of the document, which seems to suggest that the document just specifies how to delegate prefixes using DHCPv6 in PMIPv6 (but in reality the document does more than this). - The abstract also says: "DHCPv6 Prefix Delegation can be used to assign a prefix or prefixes to a mobile router for use on the links in the mobile network as specified in [RFC6276] but not supported in Proxy Mobile IPv6.". RFC6276 is for use with the Network Mobility Basic Support protocol (RFC 3963), but the draft does not consider NEMO at all, as what is called "Mobile Router" does not have any IP mobility support at all. Therefore, any link between RC3963/RFC6275 and the draft may lead to confusion, IMHO. - In the Introduction (and in the rest of the document), the term Mobile Router (MR) is used, though it is not accurate, as RFC3963 tends to implicitly assume that an MR implements the NEMO BS protocol (e.g., "A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent."). However, in the draft, it is mentioned that "The specification assumes that a MR is a regular IPv6 router without extension for mobility managements.", so I think it's better not to call this "router" MR. - I'd rewrite the Introduction to make the problem scope clearer. I needed to read the whole document to get the full picture (it was not clear to me when I was reading the intro). - I'd avoid using normative text (like MUST) in the intro. - In Section 3.1, the document starts mixing the terms MN and MR, which again, is a source of potential misunderstandings. For example, it says "The MR (as a RR) MUST either obtain the Home Network Prefix (HNP) before initiating the DHCPv6-PD procedure or in case of stateful address configuration simultaneously while configuring the Mobile Node Home Address (MN-HoA)." - I don't see why the MR should support the Prefix Exclude Option. - In Section 3.2: "If the network mobility service needs to be offered to the mobile node, the mobile access gateway MUST set the Mobile Router Flag (R) when sending the Proxy Binding Update (PBU) message to the LMA.". I think this cannot be done, as RFC3963 states that "The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router.". Therefore, if the "R" bit is set, that means that the (P)BU is sent by an MR implementing RFC3963 (which is not the case here), unless this draft is updating RFC3963. - In Section 3.3.1, the terms "MN" and "MR" are again mixed, which makes it complex to follow. - Another, IMHO, source of potential misleading, is the use of the MNP option, which again is tightly related to the RFC3963. Not sure if it'd be good to define a new option for this. For example, the HNP and MNP options are exactly the same format-wise, but we have two different options (types) because it is better not to overload too much them. - In Section 3.4.2, it says: "On receiving a packet from the bi-directional tunnel established with the MR's LMA, the MAG MUST use the destination address of the inner packet to forward it on the interface where the destination MNP is hosted." --> does this mean that the packet is not decapsulated and then routed, but routed based on the inner packet destination address? If so, this seems very weird to me. I guess the tunnel ends at the MAG, like in regular PMIPv6 for a host. In that case, I'd say that some additional text about forwarding considerations on the MAG is missing (e.g., the MAG has to add a route for the "MNP" via the "MR"). - In Section 3.5.2, it says: "In order to receive those packets, the LMA MUST advertise a connected route into the routing infrastructure for the MR's MNP(s).". I guess the "advertisement" is not really mandatory (no need of using MUST there), as what is required is that the LMA anchores the prefix, right? - I'd say that the Security Considerations section may benefit from additional text. I have not thought of that carefully, but at least some examples of the SPD and SAD entries used to protect the signaling could be helpful (e.g., as used in RFC6276). This is just a first batch of comments. I think the document needs an update and further revisions. Regarding the document's scope, I think it's very important to make it clear. For example, as it is now, a rader could think that this document addresses the problem I tried to describe in draft-bernardos-netext-pmipv6-nemo-ps-01, but this is not the case. While writing that draft I learned/suffered myself how difficult is to clearly explain the problem. In case it is not clear, I'm supportive of the problem described in draft-ietf-netext-pd-pmip-01. I'm just trying to help here, so don't take my comments as negative ones. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-+XXG/J6Ylxq8rN1W+U4f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk9NIjYACgkQNdy6TdFwT2eQRACgmSQmzQqrF4sZ0gy3hQujO8kQ 6T8An3+mDTJ7dpUTazPhUNnc8CV+ihFk =UKXa -----END PGP SIGNATURE----- --=-+XXG/J6Ylxq8rN1W+U4f-- From sarikaya2012@gmail.com Tue Feb 28 12:40:08 2012 Return-Path: <sarikaya2012@gmail.com> 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 70B7221F8674 for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 12:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 DCVrzetaPKeT for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 12:40:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC83521F8672 for <netext@ietf.org>; Tue, 28 Feb 2012 12:40:07 -0800 (PST) Received: by yhpp34 with SMTP id p34so1310976yhp.31 for <netext@ietf.org>; Tue, 28 Feb 2012 12:40:07 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.191.134 as permitted sender) client-ip=10.236.191.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.191.134 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.191.134]) by 10.236.191.134 with SMTP id g6mr30523412yhn.95.1330461607420 (num_hops = 1); Tue, 28 Feb 2012 12:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=oY4HIICi5BTEKNp5bXxhiXFIFUR3PGMBC7i+h0OlEWw=; b=FabFbJVkEeJjw3YivT2zoZtwpvKsS+oxqba5HmEGpJ45PCLnUPLgNKmBdadWXkbAOP ii105KjWDaLXWgvZ4l7PYT3tV4RL3T2inCJVhrdNBYacIDJynhd5hm7Ae/lrdEbL9iAw gCU+2IXa5EEMQFxSfmexb/GEKlR4gM5GePDFo= MIME-Version: 1.0 Received: by 10.236.191.134 with SMTP id g6mr23116540yhn.95.1330461607379; Tue, 28 Feb 2012 12:40:07 -0800 (PST) Received: by 10.236.9.73 with HTTP; Tue, 28 Feb 2012 12:40:07 -0800 (PST) Date: Tue, 28 Feb 2012 14:40:07 -0600 Message-ID: <CAC8QAcexDHM99R-3FP9sJ20orQbZeoy=y91RLvFipxqhTR=kCw@mail.gmail.com> From: Behcet Sarikaya <sarikaya2012@gmail.com> To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] Errata on RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 20:40:08 -0000 Hi all, I would like to claim errate on RFC 5213 as follows: In Section 8.1 on Mobility Options, the paragraph: As per this specification, the following mobility options are valid in a Proxy Binding Update message. These options can be present in the message in any order. There can be one or more instances of the Home Network Prefix options present in the message. However, there cannot be more than one instance of any of the following options. Mobile Node Identifier option Home Network Prefix option Handoff Indicator option Access Technology Type option Timestamp option Mobile Node Link-layer Identifier option Link-local Address option While the text allows one or more instances of HNP, the list that just follows does not. I think that Home Network Prefix option should be deleted from the list. How to report this errata to IETF? Regards, Behcet From Basavaraj.Patil@nokia.com Tue Feb 28 12:48:45 2012 Return-Path: <Basavaraj.Patil@nokia.com> 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 AEBCF21F8714 for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 12:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.861 X-Spam-Level: X-Spam-Status: No, score=-104.861 tagged_above=-999 required=5 tests=[AWL=1.738, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Jkyb1mv9sGwF for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 12:48:45 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 155B921F8503 for <netext@ietf.org>; Tue, 28 Feb 2012 12:48:44 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SKmdNk007132; Tue, 28 Feb 2012 22:48:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 22:48:39 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 21:48:38 +0100 From: <Basavaraj.Patil@nokia.com> To: <sarikaya@ieee.org>, <netext@ietf.org> Thread-Topic: [netext] Errata on RFC 5213 Thread-Index: AQHM9lkvoxcu4dPstkK9BSnAALF+HZZSUreA Date: Tue, 28 Feb 2012 20:48:37 +0000 Message-ID: <CB7298A0.1B50A%basavaraj.patil@nokia.com> In-Reply-To: <CAC8QAcexDHM99R-3FP9sJ20orQbZeoy=y91RLvFipxqhTR=kCw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: <D6823F632A2127439A23FA8BD28AF22F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 20:48:39.0067 (UTC) FILETIME=[592F66B0:01CCF65A] X-Nokia-AV: Clean Subject: Re: [netext] Errata on RFC 5213 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 20:48:45 -0000 Hi Behcet, The text in the section is a bit misleading and could have been written better. The list that is mentioned in "the following mobility options are valid=8A.= " is the one which which includes the HNP option as well. It is clear that the HNP option can have multiple instances whereas the other options can be either one or zero. Hence I don't think that there is a need to do an errata unless it is a cause of confusion to implementers. -Raj On 2/28/12 2:40 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: >Hi all, > >I would like to claim errate on RFC 5213 as follows: > >In Section 8.1 >on Mobility Options, the paragraph: > >As per this specification, the following mobility options are > valid in a Proxy Binding Update message. These options can be > present in the message in any order. There can be one or more > instances of the Home Network Prefix options present in the > message. However, there cannot be more than one instance of any > of the following options. > > Mobile Node Identifier option > > Home Network Prefix option > > Handoff Indicator option > > Access Technology Type option > > Timestamp option > > Mobile Node Link-layer Identifier option > > Link-local Address option > >While the text allows one or more instances of HNP, the list that just >follows does not. >I think that Home Network Prefix option should be deleted from the list. > >How to report this errata to IETF? > >Regards, > >Behcet >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From sarikaya2012@gmail.com Tue Feb 28 13:03:39 2012 Return-Path: <sarikaya2012@gmail.com> 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 8C14E21E806D for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 zo1MXKiJJSVB for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:03:35 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE321E806F for <netext@ietf.org>; Tue, 28 Feb 2012 13:03:33 -0800 (PST) Received: by yenm5 with SMTP id m5so1198914yen.31 for <netext@ietf.org>; Tue, 28 Feb 2012 13:03:33 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.143.40 as permitted sender) client-ip=10.236.143.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.143.40 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.143.40]) by 10.236.143.40 with SMTP id k28mr31249450yhj.112.1330463013734 (num_hops = 1); Tue, 28 Feb 2012 13:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=HrX360z1fA3cj/iMVs91auHDLmvh7OpsD2aJK8u90TQ=; b=SGoe9aSHwdg17b47FlzTmrctUhDa8ZnP/S2DjIOnISWlNowWUEmKzY6wVTiyR0IGJU E9zkEP7YvM26RpaL5tn5dDu2Wt3bZsVNMAmC3hEC1jBsVFUzZqSyNO51CqJ2Wae5TgAx KK4DHE6LA3tlL4BIX/O0i+Laadmlw8CSZYYk0= MIME-Version: 1.0 Received: by 10.236.143.40 with SMTP id k28mr23633619yhj.112.1330463013686; Tue, 28 Feb 2012 13:03:33 -0800 (PST) Received: by 10.236.9.73 with HTTP; Tue, 28 Feb 2012 13:03:33 -0800 (PST) In-Reply-To: <CB7298A0.1B50A%basavaraj.patil@nokia.com> References: <CAC8QAcexDHM99R-3FP9sJ20orQbZeoy=y91RLvFipxqhTR=kCw@mail.gmail.com> <CB7298A0.1B50A%basavaraj.patil@nokia.com> Date: Tue, 28 Feb 2012 15:03:33 -0600 Message-ID: <CAC8QAceLya=5Lwv4SXBNicw6sj55699fNjdxZEqJ75uN2JjHBA@mail.gmail.com> From: Behcet Sarikaya <sarikaya2012@gmail.com> To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Errata on RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 21:03:39 -0000 Hi Raj, The same error is repeated in Section 8.2 as well. There is no errata on RFC 5213 as of today, why not report these two? No one is perfect :-). Behcet On Tue, Feb 28, 2012 at 2:48 PM, <Basavaraj.Patil@nokia.com> wrote: > > Hi Behcet, > > The text in the section is a bit misleading and could have been written > better. > The list that is mentioned in "the following mobility options are valid= =C5=A0." > is the one which which includes the HNP option as well. It is clear that > the HNP option can have multiple instances whereas the other options can > be either one or zero. > > Hence I don't think that there is a need to do an errata unless it is a > cause of confusion to implementers. > > -Raj > > On 2/28/12 2:40 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: > >>Hi all, >> >>I would like to claim errate on RFC 5213 as follows: >> >>In Section 8.1 >>on Mobility Options, the paragraph: >> >>As per this specification, the following mobility options are >> =C2=A0 =C2=A0 =C2=A0valid in a Proxy Binding Update message. =C2=A0These= options can be >> =C2=A0 =C2=A0 =C2=A0present in the message in any order. =C2=A0There can= be one or more >> =C2=A0 =C2=A0 =C2=A0instances of the Home Network Prefix options present= in the >> =C2=A0 =C2=A0 =C2=A0message. =C2=A0However, there cannot be more than on= e instance of any >> =C2=A0 =C2=A0 =C2=A0of the following options. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mobile Node Identifier option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Home Network Prefix option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Handoff Indicator option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Access Technology Type option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Timestamp option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mobile Node Link-layer Identifier option >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Link-local Address option >> >>While the text allows one or more instances of HNP, the list that just >>follows does not. >>I think that Home Network Prefix option should be deleted from the list. >> >>How to report this errata to IETF? >> >>Regards, >> >>Behcet >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Tue Feb 28 13:19:31 2012 Return-Path: <Basavaraj.Patil@nokia.com> 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 06ED621F853D for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.902 X-Spam-Level: X-Spam-Status: No, score=-104.902 tagged_above=-999 required=5 tests=[AWL=1.697, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rgdiSN23a5md for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:19:30 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E4EA721F8510 for <netext@ietf.org>; Tue, 28 Feb 2012 13:19:29 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SLJLoe004467; Tue, 28 Feb 2012 23:19:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 23:19:21 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 22:19:20 +0100 From: <Basavaraj.Patil@nokia.com> To: <sarikaya@ieee.org> Thread-Topic: [netext] Errata on RFC 5213 Thread-Index: AQHM9lkvoxcu4dPstkK9BSnAALF+HZZSUreAgABor4D//5/lgA== Date: Tue, 28 Feb 2012 21:19:20 +0000 Message-ID: <CB72A09F.1B528%basavaraj.patil@nokia.com> In-Reply-To: <CAC8QAceLya=5Lwv4SXBNicw6sj55699fNjdxZEqJ75uN2JjHBA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2308761166C98D42B0DF384D5026DD22@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 21:19:21.0568 (UTC) FILETIME=[A366BE00:01CCF65E] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Errata on RFC 5213 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 21:19:31 -0000 Agree... Lets put some alternative text to the list first to correct the problem and then take it to the RFC editor after we have consensus. Errata can be handled thru: http://www.rfc-editor.org/errata.php -Raj On 2/28/12 3:03 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: >Hi Raj, > >The same error is repeated in Section 8.2 as well. >There is no errata on RFC 5213 as of today, why not report these two? > >No one is perfect :-). > >Behcet > >On Tue, Feb 28, 2012 at 2:48 PM, <Basavaraj.Patil@nokia.com> wrote: >> >> Hi Behcet, >> >> The text in the section is a bit misleading and could have been written >> better. >> The list that is mentioned in "the following mobility options are >>valid=A9." >> is the one which which includes the HNP option as well. It is clear that >> the HNP option can have multiple instances whereas the other options can >> be either one or zero. >> >> Hence I don't think that there is a need to do an errata unless it is a >> cause of confusion to implementers. >> >> -Raj >> >> On 2/28/12 2:40 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> >>wrote: >> >>>Hi all, >>> >>>I would like to claim errate on RFC 5213 as follows: >>> >>>In Section 8.1 >>>on Mobility Options, the paragraph: >>> >>>As per this specification, the following mobility options are >>> valid in a Proxy Binding Update message. These options can be >>> present in the message in any order. There can be one or more >>> instances of the Home Network Prefix options present in the >>> message. However, there cannot be more than one instance of any >>> of the following options. >>> >>> Mobile Node Identifier option >>> >>> Home Network Prefix option >>> >>> Handoff Indicator option >>> >>> Access Technology Type option >>> >>> Timestamp option >>> >>> Mobile Node Link-layer Identifier option >>> >>> Link-local Address option >>> >>>While the text allows one or more instances of HNP, the list that just >>>follows does not. >>>I think that Home Network Prefix option should be deleted from the list. >>> >>>How to report this errata to IETF? >>> >>>Regards, >>> >>>Behcet >>>_______________________________________________ >>>netext mailing list >>>netext@ietf.org >>>https://www.ietf.org/mailman/listinfo/netext >> From sarikaya2012@gmail.com Tue Feb 28 13:37:00 2012 Return-Path: <sarikaya2012@gmail.com> 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 1292A21E806E for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 Q5475pCLPS+y for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 13:36:59 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6536921E806C for <netext@ietf.org>; Tue, 28 Feb 2012 13:36:59 -0800 (PST) Received: by yhpp34 with SMTP id p34so1344071yhp.31 for <netext@ietf.org>; Tue, 28 Feb 2012 13:36:59 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.143.40 as permitted sender) client-ip=10.236.143.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.143.40 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.143.40]) by 10.236.143.40 with SMTP id k28mr31398117yhj.112.1330465019099 (num_hops = 1); Tue, 28 Feb 2012 13:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=T316hFolDfEevfcMr1WBR9+gISznMF61MTzY4R6QCP4=; b=HPc1s0+9bNIM/rF43o+XXOixJQ/I2KfPsSjJ5ANilEKlt7i1A971JWQAGVd4frd3I7 tE0qbMo5DrMbwTPXNYnnXRKeq0n2CLEczEYXubDIhRkOrf5ABzq5AmImFkWNJiFCtSob gtFjYJamrLlR2gQWsmH4jTh5Nezusv8XUp03A= MIME-Version: 1.0 Received: by 10.236.143.40 with SMTP id k28mr23749736yhj.112.1330465018970; Tue, 28 Feb 2012 13:36:58 -0800 (PST) Received: by 10.236.9.73 with HTTP; Tue, 28 Feb 2012 13:36:58 -0800 (PST) In-Reply-To: <CB72A09F.1B528%basavaraj.patil@nokia.com> References: <CAC8QAceLya=5Lwv4SXBNicw6sj55699fNjdxZEqJ75uN2JjHBA@mail.gmail.com> <CB72A09F.1B528%basavaraj.patil@nokia.com> Date: Tue, 28 Feb 2012 15:36:58 -0600 Message-ID: <CAC8QAcc-e9S47TaYt6j2b2JSym9SPHv_XHrdNtUGgqijFfeFhg@mail.gmail.com> From: Behcet Sarikaya <sarikaya2012@gmail.com> To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Errata on RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 21:37:00 -0000 I just did. Behcet 2012/2/28 <Basavaraj.Patil@nokia.com>: > > Agree... > Lets put some alternative text to the list first to correct the problem > and then take it to the RFC editor after we have consensus. > Errata can be handled thru: http://www.rfc-editor.org/errata.php > > -Raj > > On 2/28/12 3:03 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: > >>Hi Raj, >> >>The same error is repeated in Section 8.2 as well. >>There is no errata on RFC 5213 as of today, why not report these two? >> >>No one is perfect :-). >> >>Behcet >> >>On Tue, Feb 28, 2012 at 2:48 PM, =A0<Basavaraj.Patil@nokia.com> wrote: >>> >>> Hi Behcet, >>> >>> The text in the section is a bit misleading and could have been written >>> better. >>> The list that is mentioned in "the following mobility options are >>>valid=A9." >>> is the one which which includes the HNP option as well. It is clear tha= t >>> the HNP option can have multiple instances whereas the other options ca= n >>> be either one or zero. >>> >>> Hence I don't think that there is a need to do an errata unless it is a >>> cause of confusion to implementers. >>> >>> -Raj >>> >>> On 2/28/12 2:40 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> >>>wrote: >>> >>>>Hi all, >>>> >>>>I would like to claim errate on RFC 5213 as follows: >>>> >>>>In Section 8.1 >>>>on Mobility Options, the paragraph: >>>> >>>>As per this specification, the following mobility options are >>>> =A0 =A0 =A0valid in a Proxy Binding Update message. =A0These options c= an be >>>> =A0 =A0 =A0present in the message in any order. =A0There can be one or= more >>>> =A0 =A0 =A0instances of the Home Network Prefix options present in the >>>> =A0 =A0 =A0message. =A0However, there cannot be more than one instance= of any >>>> =A0 =A0 =A0of the following options. >>>> >>>> =A0 =A0 =A0 =A0 Mobile Node Identifier option >>>> >>>> =A0 =A0 =A0 =A0 Home Network Prefix option >>>> >>>> =A0 =A0 =A0 =A0 Handoff Indicator option >>>> >>>> =A0 =A0 =A0 =A0 Access Technology Type option >>>> >>>> =A0 =A0 =A0 =A0 Timestamp option >>>> >>>> =A0 =A0 =A0 =A0 Mobile Node Link-layer Identifier option >>>> >>>> =A0 =A0 =A0 =A0 Link-local Address option >>>> >>>>While the text allows one or more instances of HNP, the list that just >>>>follows does not. >>>>I think that Home Network Prefix option should be deleted from the list= . >>>> >>>>How to report this errata to IETF? >>>> >>>>Regards, >>>> >>>>Behcet >>>>_______________________________________________ >>>>netext mailing list >>>>netext@ietf.org >>>>https://www.ietf.org/mailman/listinfo/netext >>> > From sgundave@cisco.com Tue Feb 28 15:11:19 2012 Return-Path: <sgundave@cisco.com> 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 D421A21E802C for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 15:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.197 X-Spam-Level: X-Spam-Status: No, score=-8.197 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 HIcWPwPRA82C for <netext@ietfa.amsl.com>; Tue, 28 Feb 2012 15:11:12 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C721F8518 for <netext@ietf.org>; Tue, 28 Feb 2012 15:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2656; q=dns/txt; s=iport; t=1330470672; x=1331680272; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=z5WM1ZTbCwu0FrFxgVFo/ceMYC7pWHofuxHorbg1JjE=; b=LblOJgJs++XAb53Kq/ZZs68I24ClwSpUA17wbK0sDseMNm4KXqcg3N2N cCDG756nzBo1f7yaXUQULGt9HuA471wT1bx9cARd0/CqGPLkuDAiZCTZl PsONM1PqMqqtgQskj80GGc2l2Q4ZeGWo0kiLlQFl+uFVrXKzctsMzyf/Q E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACleTU+rRDoI/2dsb2JhbABEs2aBB4F3AQEBAwEBAQEPASkBMR0BCBhPBjACBAESIodhBAELoHQBlwYEiRmDagQGBgUGAQ8CRAYBBgQJAoVDAQ4KBgEEFAGDLASIT4xwixmHeA X-IronPort-AV: E=Sophos;i="4.73,498,1325462400"; d="scan'208";a="33075845" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Feb 2012 23:11:11 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1SNBBM7026724; Tue, 28 Feb 2012 23:11:11 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 15:11:11 -0800 Received: from 10.21.122.192 ([10.21.122.192]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Feb 2012 23:11:10 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 28 Feb 2012 15:11:11 -0800 From: Sri Gundavelli <sgundave@cisco.com> To: <Basavaraj.Patil@nokia.com>, <sarikaya@ieee.org>, <netext@ietf.org> Message-ID: <CB729F0F.3C951%sgundave@cisco.com> Thread-Topic: [netext] Errata on RFC 5213 Thread-Index: AQHM9lkvoxcu4dPstkK9BSnAALF+HZZSUreAgACdG7s= In-Reply-To: <CB7298A0.1B50A%basavaraj.patil@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 28 Feb 2012 23:11:11.0117 (UTC) FILETIME=[429AABD0:01CCF66E] Subject: Re: [netext] Errata on RFC 5213 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. " <netext.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netext> List-Post: <mailto:netext@ietf.org> List-Help: <mailto:netext-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Feb 2012 23:11:19 -0000 Hi Behcet, There are two parts to it. The options that are considered valid in PBU/PBA and the single instance count requirement for the options and one special case. So, I agree, its bit on the border line with respect to how the text came out. We could have simply not talked about the instance count validity= . But, given that the rest of the text is consistent with respect to the instances of each option that are allowed, the overall meaning of the text is still clear, IMO. But, we can discuss further. Regards Sri On 2/28/12 12:48 PM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com= > wrote: >=20 > Hi Behcet, >=20 > The text in the section is a bit misleading and could have been written > better. > The list that is mentioned in "the following mobility options are valid=A9.= " > is the one which which includes the HNP option as well. It is clear that > the HNP option can have multiple instances whereas the other options can > be either one or zero. >=20 > Hence I don't think that there is a need to do an errata unless it is a > cause of confusion to implementers. >=20 > -Raj >=20 > On 2/28/12 2:40 PM, "ext Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: >=20 >> Hi all, >>=20 >> I would like to claim errate on RFC 5213 as follows: >>=20 >> In Section 8.1 >> on Mobility Options, the paragraph: >>=20 >> As per this specification, the following mobility options are >> valid in a Proxy Binding Update message. These options can be >> present in the message in any order. There can be one or more >> instances of the Home Network Prefix options present in the >> message. However, there cannot be more than one instance of any >> of the following options. >>=20 >> Mobile Node Identifier option >>=20 >> Home Network Prefix option >>=20 >> Handoff Indicator option >>=20 >> Access Technology Type option >>=20 >> Timestamp option >>=20 >> Mobile Node Link-layer Identifier option >>=20 >> Link-local Address option >>=20 >> While the text allows one or more instances of HNP, the list that just >> follows does not. >> I think that Home Network Prefix option should be deleted from the list. >>=20 >> How to report this errata to IETF? >>=20 >> Regards, >>=20 >> Behcet >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext