From Marco.Liebsch@neclab.eu Fri Jul 6 08:47:54 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 DDE8721F869C for ; Fri, 6 Jul 2012 08:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 ZPgZ+OxIdR8X for ; Fri, 6 Jul 2012 08:47:52 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3721F8666 for ; Fri, 6 Jul 2012 08:47:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5090610176D for ; Fri, 6 Jul 2012 17:49:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIujIUaZQxWK for ; Fri, 6 Jul 2012 17:49:27 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1A14610176C for ; Fri, 6 Jul 2012 17:49:22 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.191]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 17:49:41 +0200 From: Marco Liebsch To: "netext@ietf.org" Thread-Topic: review of draft-ietf-netext-pmipv6-flowmob-03 Thread-Index: Ac1bjMGc9CBEdr72RlSY8XvUW+E7tw== Date: Fri, 6 Jul 2012 15:49:41 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24E0884B@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.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] review of draft-ietf-netext-pmipv6-flowmob-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:47:55 -0000 Please find below some comments to the current version of draft-ietf-netext-pmipv6-flowmob-03. General comments: >From a specification to extend RFC5213 to support flow mobility I see the f= ollowing components as key items to specify and describe associated operation: (1) Prefix handling at LMA and MAG (2) Handling and enforcement of flow policies at the LMA IMO, the current draft focuses too much on thing which are not to be placed= in this specification, e.g. how the MN can accomplish multiple address handlin= g. My general recommendation is to thoroughly describe the delta to RFC5213 and which additional or extended functions are needed to accomplish base flow mobility scenario and how these function operate with PMIPv6. My view is that the specification also has lots of should and may. The draft should= be clear about what's really needed to enable flow mobility according to a well unde= rstood problem statement. If there are options to enable additional features, they= should be clearly separated from the core specification. One example is the need to propagate flow templates to MAGs. Only on the last pages (p.17) the read= er learns that maintaining flow level information on MAGs is not mandatory. Is there text at all that explains why flow templates are needed on the MAG= at all? Please find specific comments below in a copy of the draft, labeled with [m= arco]. ---------------- NETEXT Working Group CJ. Bernardos, Ed. Internet-Draft UC3M Intended status: Standards Track March 12, 2012 Expires: September 13, 2012 Proxy Mobile IPv6 Extensions to Support Flow Mobility draft-ietf-netext-pmipv6-flowmob-03 Abstract Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. This document assumes that the mobile node implements the logical interface model, [marco] .. it should not. It's good that NetExt has an informational docume= ntation about how logical interfaces can support multi-homing and flow mobility, bu= t this specification should not assume it or even mandate its use. The spec should solely assume that the MN is able to handle multiple addresses@ multiple in= terfaces as well as to enforce uplink policies to select the right interface.=20 The Abstract should focus on which features can be supported compared to RFC5213 when the specified components are implemented. therefore allowing the support of traffic flows on different physical interfaces regardless of the assigned prefixes on these physical interfaces. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Bernardos Expires September 13, 2012 [Page 1] Internet-Draft PMIPv6 flow mobility March 2012 Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents /..snip Bernardos Expires September 13, 2012 [Page 2] Internet-Draft PMIPv6 flow mobility March 2012 1. Introduction Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the entity detecting Mobile Node's (MN) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all traffic belonging to the MN. PMIPv6 allows an MN to connect to the same PMIPv6 domain through different interfaces. The "logical interface" at the IP layer may enable packet transmission and reception over different physical media. This technique can be used to achieve flow mobility, i.e., the movement of selected flows from one access technology to another. [marco] why does the document introduce the logical interface even before what should be the core of the specification? I'd propose to just mention t= he assumption of such support on the MN and refer to the availability of appropriate tech= nology on the MN.=20 It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). This document specifies protocol extensions to Proxy Mobile IPv6 between the LMA and MAGs to enable distributing specific traffic flows on different physical interfaces. This document assumes that a "logical interface" at the mobile node is capable of supporting [marco] ..again? traffic flows on different physical interfaces regardless of the assigned prefixes on those physical interfaces. In particular, this document specifies how to enable "flow mobility" in the PMIPv6 network (i.e. LMAs and MAGs). Flow mobility is enabled by assigning the required prefixes on the different accesses. [marco] three lines about the actual scope of the draft. I don't want to be nasty, but it really does not help the reader to understand or even implement what's needed for PMIP if you focus on which technology to use on the MN.=20 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC5213]: Local Mobility Agent (LMA). Mobile Access Gateway (MAG). Proxy Mobile IPv6 Domain (PMIPv6-Domain). LMA Address (LMAA). Bernardos Expires September 13, 2012 [Page 3] Internet-Draft PMIPv6 flow mobility March 2012 Proxy Care-of Address (Proxy-CoA). Home Network Prefix (HNP). The following terms used in this document are defined in the Multiple Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: Binding Identification Number (BID). Flow Identifier (FID). Traffic Selector (TS). The following terms are defined and used in this document: FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG conveying the information required to enable flow mobility in a PMIPv6-Domain. This message is only needed when the prefixes initially assigned by the different MAGs to the mobile node are different. FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to an FMI message. [marco] I don't think protocol message definitions are needed in the terms = section. FMC (Flow Mobility Cache). Conceptual data structure maintained by the LMA and the MAG to support the flow mobility management operations described in this document. 3. Overview of the PMIPv6 flow mobility extensions 3.1. Use case scenarios Flow mobility assumes simultaneous access to more than one network, in contrast to a typical handover where connectivity to a physical medium is relinquished, and is re-established with another. In order to support flow mobility in a PMIPv6 network, it is required to be able to to tie the different PMIPv6 mobility sessions (one per [marco] typo: able to to --> able to interface) to a logical interface which is hiding one or more physical interfaces [I-D.ietf-netext-logical-interface-support]. In this specification, it is assumed that the LMA knows that the MN supports the logical interface and it can handle the same prefix(es) or different prefix(es) on both access networks. How this is done is out of the scope of this specification. [marco] this sounds like the spec mandates the logical interface. In I-D.ietf-netext-logical-interface-support I see one approach of solving the MN part being documented. Other possibilities beyond I-D.ietf-netext-logical-interface-support using also virtual interfaces exist. I'd propose to just place assumptions about functional support as written above. If really needed, an Appendix section can be added where a reader gets informed about an exemplary configuration on MNs , e.g. using a logical interface. There are different flow mobility scenarios. In some of them the mobile node might share a common set of prefixes among all its Bernardos Expires September 13, 2012 [Page 4] Internet-Draft PMIPv6 flow mobility March 2012 physical interfaces, whereas in others the mobile node might have a different subset of prefixes configured on each of the phyisical interfaces. The different possibilities are the following: [marco] 'possibilities' =3D 'scenarios', correct? 1. At the time of a new network attachment, the MN obtains the same prefix or the same set of prefixes as already assigned to an existing session. This is not the default behavior with basic PMIPv6 [RFC5213], and the LMA needs to be able to provide the same assignment even for the simultaneous attachment (as opposed to the handover scenario only). 2. At the time of a new network attachment, the MN obtains a new prefix or a new set of prefixes for the new session. This is the default behavior with basic PMIPv6 [RFC5213]. 3. At the time of a new network attachment, the MN obtains a combination of prefix(es) in use and new prefix(es). This is a hybrid of the two above-mentioned scenarios. The local policy determines whether the new prefix is exclusive to the new attachment or it can be assigned to an existing attachment as well. Among these, scenario 1 needs extensions to basic PMIPv6 [RFC5213] signaling at the time of a new attachment, to ensure that the same prefix (or set of prefixes) is assigned to all the interfaces of the same mobile node that are simultaneously attached. Subsequently, no further signaling is necessary. [marco] maybe clearer: '..No further signaling is necessary between the LMA and the MAG and flows are forwarded according to policy rules on the LMA an= d the MN' Scenario 2 requires flow mobility signaling to enable relocating flows between the different attachments, so the MAGs are aware of the prefixes for which the MN is going to receive traffic, and local routing entries are configured accordingly. [marco] scenario 2 per se does not need any extension. As you write above, it's covered by RFC5213. You only need extra signaling if scenario 2 turns = into scenario 3. Hence, you should probably mention this in the next paragraph. Scenario 3 requires flow mobility signaling to enable relocating flows for the new prefix(es) which are not shared across attachments. In all the scenarios, the MAGs should be aware of the prefixes for which is going to receive uplink (UL) or downlink (DL) traffic. These prefixes might not be limited to those delegated by the MAG upon attachment of the connected interface, and therefore in these cases, signaling is required. Once the network is configured with the right set of prefixes, the actual flow mobility can take place at any time thereafter (e.g., by redirecting DL or UL packets from one access to another). The extensions described in this document support any of these aforementioned scenarios. Bernardos Expires September 13, 2012 [Page 5] Internet-Draft PMIPv6 flow mobility March 2012 3.2. Basic Operation This section describes how the PMIPv6 extensions described in this document enable flow mobility support. 3.2.1. MN sharing a common set of prefixes on all MAGs This scenario corresponds to the use case scenario number 1 described in Section 3.1. When a multi-interfaced mobile node connects to a PMIPv6-domain, it performs regular attachment and as a result is able to configure an IP address (or a set of IP addresses) on the logical interface hiding the different physical interfaces. [marco] again, the spec should not assume how flow mobility is implemented in the MN. Hence, no assumption should be taken about the existence of a logical interface in the core specification part of the document. If the LMA assigns a common prefix (or set of prefixes) to the different physical interfaces attached to the domain, then all the MAGs already have all the routing knowledge required to forward UL or DL packets, and the LMA does not need to perform any kind of signaling in order to move flows across the different physical interfaces. The LMA needs to know when to assigne the same set of prefixes to all [marco]: assigne --> assign the different physical interfaces of the mobile node. This can be achieved by different means, such as policy configuration or default policies, etc. In this document a new Handoff Indicator (HI) value ("Attachment over a new interface sharing prefixes") is defined, to allow the mobile access gateway indicate to the local mobility anchor that the same set of prefixes should be assigned to the mobile node. The considerations of Section 5.4.1 of [RFC5213] are updated by this specification as follows: o If there is at least one Home Network Prefix option present in the request with a NON_ZERO prefix value, there exists a Binding Cache entry (with one all home network prefixes in the Binding Cache entry matching the prefix values of all Home Network Prefix options of the received Proxy Binding Update message), and the entry matches the mobile node identifier in the Mobile Node Identifier option of the received Proxy Binding Update message, and the value of the Handoff Indicator of the received Proxy Binding Update is equal to "Attachment over a new interface sharing prefixes". 1. If there is a Mobile Node Link-layer Identifier Option present in the request and the Binding Cache entry matches the Access Technology Type (ATT), and MN-LL-Identifier, the request MUST be considered as a request for updating that Binding Cache entry. [marco] does that conflict with the above mentioned presence of the new HI value? Above it's said that the message comprises a HI which indicates "Attachment over a new interface sharing prefixes", whereas procedure 1.is about a handover (BCE update). Or is the new HI value used also in case of handover, not only at initial attachment? 2. If there is a Mobile Node Link-layer Identifier Option present in the request and the Binding Cache entry does not match the Access Technology Type (ATT), and MN-LL-Identifier, the Bernardos Expires September 13, 2012 [Page 6] Internet-Draft PMIPv6 flow mobility March 2012 request MUST be considered as a request for creating a new mobility session sharing the same set of Home Network Prefixes assigned to the existing Binding Cache entry found. 3. If there is not a Mobile Node Link-layer Identifier Option present in the request, the request MUST be considered as a request for creating a new mobility session sharing the same set of Home Network Prefixes assigned to the existing Binding Cache entry found. As described in [I-D.ietf-netext-logical-interface-support], there [marco] where is 'there' ? The assumption about MN support should have been clarified earlier in this document. I do not see need for the complete para= graph. should be a local policy in place that ensures that packets are forwarded coherently. This SHOULD be enforced by the logical interface engine [I-D.ietf-netext-logical-interface-support]. For unidirectional outbound communications, there SHOULD also be a policy at the mobile node defining which physical interface is used to send the traffic. For bidirectional outbound communications, there SHOULD be also such a policy, but its content must be consistent with the policy at the network-side (the details about how this consistency is ensured are out of the scope of this document). In case the MAGs needs to be configured to support flow mobility, because of packet policing, packet enforcement, charging or similar reasons, the LMA SHOULD re-use the signaling defined later in this document to convey this information. Bernardos Expires September 13, 2012 [Page 7] Internet-Draft PMIPv6 flow mobility March 2012 LMA Binding Cache +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |LMA| MN1, if1, pref1, MAG1 +---+ MN1, if2, pref1, MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN1 Figure 1: Shared prefix across physical interfaces scenario [marco] I propose to just draw the IP box and the two IF boxes. same for the description below. Much clearer for the reader, as focus is on the infrastructure, not on understanding how the LIF works. Next, an example of how flow mobility works in this case is shown. In Figure 1, a mobile node (MN1) has two different physical interfaces (if1 and if2), grouped in a unique logical interface (lif). Each physical interface is attached to a different MAG, both of them anchored and controlled by the same LMA. Since both physical interfaces are assigned the same prefix (pref1) upon attachment to the MAGs, the mobile node has one single IPv6 addresses configured on the logical interface: pref1::lif. Initially, flow X goes through MAG1 and flow Y through MAG2. At certain point, flow Y can be moved to also go through MAG1. As shown in Figure 2, no signaling between the LMA and the MAGs is needed. Bernardos Expires September 13, 2012 [Page 8] Internet-Draft PMIPv6 flow mobility March 2012 +-----+ +------+ +------+ +-----+ 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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 | | | | | Figure 2: Flow mobility message sequence with common set of prefixes [marco] The big decision box confuses, IMHO. I'd propose to draw two small boxes, one on the LMA's and another on the MN's line which say 'flow policy update'. That should be clear enough. Figure 3 shows the state of the different network entities after moving flow Y in the previous example. This documents re-uses some of the terminology and mechanisms of the flow bindings and multiple care-of address registration specifications. Note, that in this case the BIDs shown in the figure are assigned locally by the LMA, since there is no signaling required in this scenario. In any case, alternative implementations of flow routing at the LMA could be used, as it does not impact on the operation of the solution in this case. Bernardos Expires September 13, 2012 [Page 9] Internet-Draft PMIPv6 flow mobility March 2012 LMA Binding Cache LMA flowmob state (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D |LMA| 1, MN1, att1, pref1, MAG1 1, flow X +---+ 2, MN1, att2, pref1, MAG2 1, flow Y //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | ::/0 LMA | +-------+ | | | I P | | MAG2 routing state | +-------+ | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | lif | | (dest) (next hop) | +---+---+ | pref1::/64 p2p-iface-with-MN1 |---|if1|if2|----| ::/0 LMA +---+---+ MN1 Figure 3: Data structures with common set of prefixes [marco] Maybe it's good to be consistent and the LMA Binding Cache in the a= bove figure should also refer to entries IF1, IF1 as depicted in Fig. 1, instead of ATT= . Or vice versa.=20 3.2.2. MN with different sets of prefixes on each MAG A different flow mobility scenario happens when the LMA assigns different sets of prefixes to physical interfaces of the same mobile node. This covers the second and third use case scenarios described in Section 3.1. In this case, specific signaling is required between the LMA and the MAG to support this scenario. Two different possibilities are considered next. The first possibility corresponds to the use case scenario number 2 described in Section 3.1, in which a multi-interfaced MN obtains a different set of prefixes on each attachment. Signaling is required when a flow is to be moved from its original interface to a new one. Since the LMA cannot send a PBA message which has not been triggered in response to a received PBU message, new signaling messages are defined to cover this case. 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). Bernardos Expires September 13, 2012 [Page 10] Internet-Draft PMIPv6 flow mobility March 2012 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. This message is sent to the new target MAG, i.e. the one selected to be the used in the forwarding of the flow. The FMI message contains (as explained in further detail in Section 4.1), the MN-Identifier, the Flow Identification Mobility option (specified in [RFC6089]) which can convey prefix or full flow information, and the type of flow mobility operation (add flow). Optionally, the LMA may send another FMI message, this time to remove the flow Y state at MAG2. Otherwise the flow state at MAG2 will be removed upon timer expiration. The message sequence is shown in Figure 4. [marco] I don't get the point why the flow information is needed on the MAG= . is that mandatory for the key scenarios? I would propose not covering that in the core specification part, maybe in the back of the specification if i= t's really needed. [marco] One technical proposal: The FMI/FMA imply pretty much overhead, IMO. Why can't all prefixed be communicated to a MAG during a PBU/PBA exchange? Having them in the BUL from the beginning allows driving this like scenario 1by having all keys/identifiers at the MAG. LMA and MN just enforce the flow policy. Nothing else needed, or? Well, prefixes might be flagged at the MAG to indi= cate whether or not the prefix is configured on the attached interface, just to = know which ones are to be communicated during ND. But important is the availabil= ity of the HNPs, which serve as key to identify the UE, at the MAG. And these c= ould be established early. No intention to change your spec, but just a proposal to make protocol operation for flow mobility more lightweight. +-----+ +------+ +------+ +-----+ 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 | | pref2::lif | pref2::lif | pref2::lif | |<----------->|<------------------------------->|<---------->if2 | | | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | | | | FMI[MN1-ID,flow_info(Y),add] | | | |---------------->| | | | | FMA | | | | |<----------------| | | | | (optional) | | | | FMI[MN1-ID,flow_info(Y),lft=3D0] | | | |-------------------------------->| | | | | FMA | | | |<--------------------------------| | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | Figure 4: Flow mobility message sequence when the LMA assigns different sets of prefixes per physical interface (FMI signaling) The state in the network after moving a flow, for the case the LMA assigns a different set of prefixes is shown in Figure 5. Bernardos Expires September 13, 2012 [Page 11] Internet-Draft PMIPv6 flow mobility March 2012 LMA Binding Cache LMA flowmob state (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D |LMA| 1, MN1, att1, pref1, 1, flow X +---+ pref2, MAG1 1, flow Y //\\ 2, MN1, att2, pref2, MAG2 +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG1 routing state +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref1::/64 p2p-iface-with-MN1 | | pref2::/64 p2p-iface-with-MN1 | +-------+ | ::/0 LMA | | I P | | | +-------+ | MAG2 routing state | | lif | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | +---+---+ | (dest) (next hop) |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 +---+---+ ::/0 LMA MN1 Figure 5: Data structures when the LMA assigns a different set of prefixes The second possibility corresponds to the use case scenario number 3 described in Section 3.1, in which upon new physical interface attachment, the MN obtains a combination of prefix(es) in use and new prefix(es). Here, the mobile node is already attached to the PMIPv6- Domain via MAG1. At a certain moment, the mobile node attaches a new interface (if2) to MAG2. MAG2 sends a PBU which is then used by the LMA to enable flow mobility. In this case, we consider that flows are moved with a prefix granularity, meaning that flows are moved by moving prefixes among the different MAGs the mobile node is attached to. In this example, flow Y is bound to pref2::/64 and therefore the flow can be moved by just binding pref2::/64 to MAG2. This is done by including the prefix in the PBA message. The scenario is shown in Figure 6. Optionally, a message can be sent to MAG1 to remove the transferred prefix(es). This message can be a Binding Revocation Indication message [RFC5846] with the P bit set to indicate that this is revocation of PMIP prefix(es). After processing BRI, the source MAG will send a Binding Revocation Acknowledgement (BRA) message back to the LMA. Bernardos Expires September 13, 2012 [Page 12] Internet-Draft PMIPv6 flow mobility March 2012 In case flow mobility is needed with a finer granularity than full prefix (e.g., flow level), this is done by including in the PBA a Flow Identification Mobility option (specified in [RFC6089]) which can convey full flow information. The MAG can also include the Flow Identification Mobility option in the PBU message that it sends to the LMA. This serves as a request for the LMA to consider the flow policy rules specified in the option. In this case no prefix is removed from any MAG because the movement is performed at flow level. +-----+ +------+ +------+ +-----+ Internet | LMA | | MAG1 | | MAG2 | | MN | +-----+ +------+ +------+ +-----+ | | | | | | 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 | | pref2::lif | pref2::lif | pref2::lif | |<----------->|<--------------->|<-------------------------->if1 | | | | | | | | | | | | | MN powers on if2 and | | | performs L2 attachment | | | |<-----------if2 | | | PBU | | | |<--------------------------------| | | | PBA (pref2) | | | | |-------------------------------->| | | LMA moves pref2 to new | | | | binding cache entry for if2 | | | | | | | | | | | | | | | (optional) | | | | | BRI[pref2] | | | | |---------------->| | | | | BRA | | | | |<----------------| | | | flow y to | flow y to | flow y to | | pref2::lif | pref2::lif | pref2::lif | |<----------->|<------------------------------->|<---------->if2 | | | | | Figure 6: Flow mobility message sequence with different set of prefixes per physical interface (PBU signaling) Bernardos Expires September 13, 2012 [Page 13] Internet-Draft PMIPv6 flow mobility March 2012 4. Message formats 4.1. Flow Mobility Initiate (FMI) The LMA sends an FMI message to a MAG to enable flow mobility. It is a Mobility Header message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by the LMA sending then initiate message, and used to match a reply in the acknowledge. 'I' (initiate) flag: Set to 1, indicates it is an FMI message. Reserved: This field is unused. MUST be set to zero by the sender. Lifetime: The requested time in seconds for which the LMA asks the MAG keep flow-specific state. A value of all one bits (0xffff) represents infinity. If set to 0, it indicates a request to remove state about the flow (cancel flow mobility) Mobility Options: MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [RFC6089]. Bernardos Expires September 13, 2012 [Page 14] Internet-Draft PMIPv6 flow mobility March 2012 4.2. Flow Mobility Acknowledge (FMA) The MAG sends an FMI message to the LMA as a response to the FMI message. It is a Mobility Header message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Copied from the value set by the sending LMA in the FMI message being acknowledged by this FMA message. 'I' flag: Set to 0, indicates it is an FMA message. Reserved: This field is unused. MUST be set to zero by the sender. Status (values to be assigned by IANA): ??: Success. ??: Reason unspecified. ??: MN not attached. ??: Sequence number out of window. ??: Traffic Selector format unsupported. ??: No existing Flow Mobility Cache entry. Lifetime: Bernardos Expires September 13, 2012 [Page 15] Internet-Draft PMIPv6 flow mobility March 2012 The requested time in seconds for which the MAG keeps flow- specific state. A value of all one bits (0xffff) represents infinity. Mobility Options: When Status code is 0, MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [RFC6089]. 5. Conceptual Data Structures 5.1. Multiple Care-of Address Registration The LMA is extended to allow a mobile node to register multiple proxy care of address (Proxy-CoA). [marco] That's actually supported by RFC5213, isn't it? Maybe you could write ' ..to register multiple proxy care of address (Proxy-CoA) while usin= g the same address (prefix) beyond a single interfaces and MAG' The LMA maintains multiple binding cache entries for an MN. The number of binding cache entries for an MN is equal to the number of the MN's interfaces attaching to any MAGs. +---------+-----+-------+------+-----------+------------+ | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | +---------+-----+-------+------+-----------+------------+ | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | +---------+-----+-------+------+-----------+------------+ Figure 7: Extended Binding Cache Figure 7 shows two Binding Cache Entries of the MN1 when it is attached to the network using two different access technologies. Both of the two attachments share HNP1 and are bounded to two different Proxy-CoAs. 5.2. Flow Mobility Cache Each LMA MUST maintain a flow mobility cache (FMC) as shown in Figure 8. This table MUST contain an entry for each flow sent from the MN. A flow binding entry includes the following fields: o Flow Identifier Priority (FID-PRI). o Flow Identifier (FID). o Traffic Selector (TS). o Binding Identifier (BID). Bernardos Expires September 13, 2012 [Page 16] Internet-Draft PMIPv6 flow mobility March 2012 o Action. o Active/Inactive. +---------+-----+-----+------+---------+----------+ | FID-PRI | FID | TS | BIDs | Action | A/I | +---------+-----+-----+------+---------+----------+ | 10 | 2 | TCP | 1 | Forward | Active | | 20 | 4 | UDP | 1,2 | Forward | Inactive | +---------+-----+-----+------+---------+----------+ Figure 8: Flow Mobility Cache The BID field contains the identifier of the binding cache entry which packets matching the flow information described in the TS field will be forwarded to. When a flow is decided to be moved, the affected BID(s) of the table are updated. Similar to flow binding described in [RFC6089], each flow binding entry points to a specific binding cache entry identifier (BID). When a flow is moved, the LMA simply updates the pointer of the flow binding entry with the BID of the interface to which the flow will be moved. The traffic selector (TS) in flow binding table is defined as in [RFC6088]. TS is used to classify the packets of flows basing on specific parameters such as service type, source and destination address, etc. The packets matching with the same TS will be applied the same forwarding policy. FID-PRI is the order of precedence to take action on the traffic. Action may be forward or drop.=20 [marco] is flow filtering a new feature of the specification? I did not see its description in the operations sections. If a binding entry becomes 'Inactive' it does not affect data traffic. An entry becomes 'Inactive' only if all of the BIDs are deregistered. The Mobile Access Gateway MAY also maintain a similar data structure. In case no full flow mobility state is required at the MAG, the Binding Update List (BUL) data structure is enough and no extra conceptual data entries are needed. In case full per-flow state is required at the MAG, it SHOULD also maintain a Flow Mobility Cache structure. [marco] I think this should be one of the most important sections of the specification. The protocol operation before should refer to the BCE and the table, where the flow rules are available, and describe the procedure from packet arrival to the release of the encapsulated packet on the wire. What's being looked up first, the Flow Mobility Cache or the BCE? 6. Mobile Node considerations This specification assumes the MN implements the logical interface model. [marco] it should not, in my opinion. The "logical interface" at the IP layer hides the use of different physical media from the IP stack, enabling the MN to send and receive packets over different interfaces. This document assumes the MN behaves as stated in the applicability statement document [I-D.ietf-netext-logical-interface-support]. In particular, it is Bernardos Expires September 13, 2012 [Page 17] Internet-Draft PMIPv6 flow mobility March 2012 assumed that -- for the case of bidirectional traffic -- the logical interface at the MN "replicates" the behavior observed for downlink packets on a per-flow basis. This means that the MN sends UL Flow X on the same interface which received the DL Flow X. It also means that if the LMA moves flow X during its lifetime, the MN will follow that change, upon the reception of packets of flow X via a different interface. This specification only supports flow mobility between different physical interfaces belonging to the same logical interface. If an MN has several logical interfaces, flow mobility across different logical interfaces is not supported. ../snip Hope it helps. marco From cjbc@it.uc3m.es Fri Jul 6 09:23:10 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 25AAC21F8665 for ; Fri, 6 Jul 2012 09:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFQZXUjAgS48 for ; Fri, 6 Jul 2012 09:23:06 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2C21F85E0 for ; Fri, 6 Jul 2012 09:23:05 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 456C276B5D2; Fri, 6 Jul 2012 18:23:21 +0200 (CEST) Message-ID: <1341591800.4937.36.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Marco Liebsch Date: Fri, 06 Jul 2012 18:23:20 +0200 In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24E0884B@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24E0884B@PALLENE.office.hd> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LZ2kcX+WHvcm6+9xfG9B" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19024.000 X-TM-AS-Result: No--24.850-7.0-31-1 X-imss-scan-details: No--24.850-7.0-31-1 Cc: "netext@ietf.org" Subject: Re: [netext] review of draft-ietf-netext-pmipv6-flowmob-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 16:23:10 -0000 --=-LZ2kcX+WHvcm6+9xfG9B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marco, Thanks a lot for your review. I'll take a look at it next week and post my comments on how to revise the draft. Thanks, Carlos On Fri, 2012-07-06 at 15:49 +0000, Marco Liebsch wrote: > Please find below some comments to the current version of > draft-ietf-netext-pmipv6-flowmob-03. >=20 > General comments: > From a specification to extend RFC5213 to support flow mobility I see the= following > components as key items to specify and describe associated operation: >=20 > (1) Prefix handling at LMA and MAG > (2) Handling and enforcement of flow policies at the LMA >=20 > IMO, the current draft focuses too much on thing which are not to be plac= ed in > this specification, e.g. how the MN can accomplish multiple address handl= ing. >=20 > My general recommendation is to thoroughly describe the delta to RFC5213 > and which additional or extended functions are needed to accomplish base > flow mobility scenario and how these function operate with PMIPv6. My vie= w > is that the specification also has lots of should and may. The draft shou= ld be clear > about what's really needed to enable flow mobility according to a well un= derstood > problem statement. If there are options to enable additional features, th= ey should > be clearly separated from the core specification. One example is the need > to propagate flow templates to MAGs. Only on the last pages (p.17) the re= ader > learns that maintaining flow level information on MAGs is not mandatory. > Is there text at all that explains why flow templates are needed on the M= AG at all? >=20 > Please find specific comments below in a copy of the draft, labeled with = [marco]. >=20 > ---------------- >=20 >=20 > NETEXT Working Group CJ. Bernardos, Ed. > Internet-Draft UC3M > Intended status: Standards Track March 12, 2012 > Expires: September 13, 2012 >=20 >=20 > Proxy Mobile IPv6 Extensions to Support Flow Mobility > draft-ietf-netext-pmipv6-flowmob-03 >=20 > Abstract >=20 > Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy > Mobile IPv6 domain through different interfaces. However, the > ability of movement of selected flows from one access technology to > another is missing in the basic Proxy Mobile IPv6 protocol. This > document describes extensions to the Proxy Mobile IPv6 protocol that > are required to support network based flow mobility over multiple > physical interfaces. >=20 > This document assumes that the mobile node implements the logical > interface model, >=20 > [marco] .. it should not. It's good that NetExt has an informational docu= mentation > about how logical interfaces can support multi-homing and flow mobility, = but this > specification should not assume it or even mandate its use. The spec shou= ld > solely assume that the MN is able to handle multiple addresses@ multiple = interfaces > as well as to enforce uplink policies to select the right interface.=20 > The Abstract should focus on which features can be supported compared to > RFC5213 when the specified components are implemented. >=20 >=20 >=20 > therefore allowing the support of traffic flows on > different physical interfaces regardless of the assigned prefixes on > these physical interfaces. >=20 > Requirements Language >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on September 13, 2012. >=20 > Copyright Notice >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 1] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > /..snip >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 2] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 1. Introduction >=20 > Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network > based mobility management to hosts connecting to a PMIPv6 domain. > PMIPv6 introduces two new functional entities, the Local Mobility > Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the > entity detecting Mobile Node's (MN) attachment and providing IP > connectivity. The LMA is the entity assigning one or more Home > Network Prefixes (HNPs) to the MN and is the topological anchor for > all traffic belonging to the MN. >=20 > PMIPv6 allows an MN to connect to the same PMIPv6 domain through > different interfaces. The "logical interface" at the IP layer may > enable packet transmission and reception over different physical > media. This technique can be used to achieve flow mobility, i.e., > the movement of selected flows from one access technology to another. >=20 > [marco] why does the document introduce the logical interface even before > what should be the core of the specification? I'd propose to just mention= the assumption > of such support on the MN and refer to the availability of appropriate te= chnology > on the MN.=20 >=20 >=20 > It is assumed that an IP layer interface can simultaneously and/or > sequentially attach to multiple MAGs (possibly over multiple media). > This document specifies protocol extensions to Proxy Mobile IPv6 > between the LMA and MAGs to enable distributing specific traffic > flows on different physical interfaces. This document assumes that a > "logical interface" at the mobile node is capable of supporting >=20 > [marco] ..again? >=20 >=20 > traffic flows on different physical interfaces regardless of the > assigned prefixes on those physical interfaces. >=20 > In particular, this document specifies how to enable "flow mobility" > in the PMIPv6 network (i.e. LMAs and MAGs). Flow mobility is > enabled by assigning the required prefixes on the different accesses. >=20 > [marco] three lines about the actual scope of the draft. I don't want to > be nasty, but it really does not help the reader to understand or even > implement what's needed for PMIP if you focus on which technology to > use on the MN.=20 >=20 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC2119 [RFC2119]. >=20 > The following terms used in this document are defined in the Proxy > Mobile IPv6 [RFC5213]: >=20 > Local Mobility Agent (LMA). >=20 > Mobile Access Gateway (MAG). >=20 > Proxy Mobile IPv6 Domain (PMIPv6-Domain). >=20 > LMA Address (LMAA). >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 3] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > Proxy Care-of Address (Proxy-CoA). >=20 > Home Network Prefix (HNP). >=20 > The following terms used in this document are defined in the Multiple > Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile > IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: >=20 > Binding Identification Number (BID). >=20 > Flow Identifier (FID). >=20 > Traffic Selector (TS). >=20 > The following terms are defined and used in this document: >=20 > FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG > conveying the information required to enable flow mobility in a > PMIPv6-Domain. This message is only needed when the prefixes > initially assigned by the different MAGs to the mobile node are > different. >=20 > FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to > an FMI message. >=20 >=20 > [marco] I don't think protocol message definitions are needed in the term= s section. >=20 >=20 >=20 > FMC (Flow Mobility Cache). Conceptual data structure maintained by > the LMA and the MAG to support the flow mobility management > operations described in this document. >=20 >=20 > 3. Overview of the PMIPv6 flow mobility extensions >=20 > 3.1. Use case scenarios >=20 > Flow mobility assumes simultaneous access to more than one network, > in contrast to a typical handover where connectivity to a physical > medium is relinquished, and is re-established with another. In order > to support flow mobility in a PMIPv6 network, it is required to be > able to to tie the different PMIPv6 mobility sessions (one per >=20 > [marco] typo: able to to --> able to >=20 > interface) to a logical interface which is hiding one or more > physical interfaces [I-D.ietf-netext-logical-interface-support]. In > this specification, it is assumed that the LMA knows that the MN > supports the logical interface and it can handle the same prefix(es) > or different prefix(es) on both access networks. How this is done is > out of the scope of this specification. >=20 > [marco] this sounds like the spec mandates the logical interface. > In I-D.ietf-netext-logical-interface-support I see one approach > of solving the MN part being documented. Other possibilities beyond > I-D.ietf-netext-logical-interface-support using also virtual interfaces > exist. I'd propose to just place assumptions about functional support > as written above. If really needed, an Appendix section can be added > where a reader gets informed about an exemplary configuration > on MNs , e.g. using a logical interface. >=20 >=20 > There are different flow mobility scenarios. In some of them the > mobile node might share a common set of prefixes among all its >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 4] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > physical interfaces, whereas in others the mobile node might have a > different subset of prefixes configured on each of the phyisical > interfaces. The different possibilities are the following: >=20 >=20 > [marco] 'possibilities' =3D 'scenarios', correct? >=20 > 1. At the time of a new network attachment, the MN obtains the same > prefix or the same set of prefixes as already assigned to an > existing session. This is not the default behavior with basic > PMIPv6 [RFC5213], and the LMA needs to be able to provide the > same assignment even for the simultaneous attachment (as opposed > to the handover scenario only). >=20 > 2. At the time of a new network attachment, the MN obtains a new > prefix or a new set of prefixes for the new session. This is the > default behavior with basic PMIPv6 [RFC5213]. >=20 > 3. At the time of a new network attachment, the MN obtains a > combination of prefix(es) in use and new prefix(es). This is a > hybrid of the two above-mentioned scenarios. The local policy > determines whether the new prefix is exclusive to the new > attachment or it can be assigned to an existing attachment as > well. >=20 > Among these, scenario 1 needs extensions to basic PMIPv6 [RFC5213] > signaling at the time of a new attachment, to ensure that the same > prefix (or set of prefixes) is assigned to all the interfaces of the > same mobile node that are simultaneously attached. Subsequently, no > further signaling is necessary. >=20 >=20 > [marco] maybe clearer: '..No further signaling is necessary between the L= MA > and the MAG and flows are forwarded according to policy rules on the LMA = and the MN' >=20 >=20 > Scenario 2 requires flow mobility signaling to enable relocating > flows between the different attachments, so the MAGs are aware of the > prefixes for which the MN is going to receive traffic, and local > routing entries are configured accordingly. >=20 >=20 > [marco] scenario 2 per se does not need any extension. As you write above= , > it's covered by RFC5213. You only need extra signaling if scenario 2 turn= s into > scenario 3. Hence, you should probably mention this in the next paragraph= . >=20 >=20 >=20 > Scenario 3 requires flow mobility signaling to enable relocating > flows for the new prefix(es) which are not shared across attachments. >=20 > In all the scenarios, the MAGs should be aware of the prefixes for > which is going to receive uplink (UL) or downlink (DL) traffic. > These prefixes might not be limited to those delegated by the MAG > upon attachment of the connected interface, and therefore in these > cases, signaling is required. >=20 > Once the network is configured with the right set of prefixes, the > actual flow mobility can take place at any time thereafter (e.g., by > redirecting DL or UL packets from one access to another). >=20 > The extensions described in this document support any of these > aforementioned scenarios. >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 5] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 3.2. Basic Operation >=20 > This section describes how the PMIPv6 extensions described in this > document enable flow mobility support. >=20 > 3.2.1. MN sharing a common set of prefixes on all MAGs >=20 > This scenario corresponds to the use case scenario number 1 described > in Section 3.1. When a multi-interfaced mobile node connects to a > PMIPv6-domain, it performs regular attachment and as a result is able > to configure an IP address (or a set of IP addresses) on the logical > interface hiding the different physical interfaces. >=20 > [marco] again, the spec should not assume how flow mobility is implemente= d > in the MN. Hence, no assumption should be taken about the existence of a > logical interface in the core specification part of the document. >=20 >=20 > If the LMA > assigns a common prefix (or set of prefixes) to the different > physical interfaces attached to the domain, then all the MAGs already > have all the routing knowledge required to forward UL or DL packets, > and the LMA does not need to perform any kind of signaling in order > to move flows across the different physical interfaces. >=20 > The LMA needs to know when to assigne the same set of prefixes to all >=20 > [marco]: assigne --> assign >=20 > the different physical interfaces of the mobile node. This can be > achieved by different means, such as policy configuration or default > policies, etc. In this document a new Handoff Indicator (HI) value > ("Attachment over a new interface sharing prefixes") is defined, to > allow the mobile access gateway indicate to the local mobility anchor > that the same set of prefixes should be assigned to the mobile node. > The considerations of Section 5.4.1 of [RFC5213] are updated by this > specification as follows: >=20 > o If there is at least one Home Network Prefix option present in the > request with a NON_ZERO prefix value, there exists a Binding Cache > entry (with one all home network prefixes in the Binding Cache > entry matching the prefix values of all Home Network Prefix > options of the received Proxy Binding Update message), and the > entry matches the mobile node identifier in the Mobile Node > Identifier option of the received Proxy Binding Update message, > and the value of the Handoff Indicator of the received Proxy > Binding Update is equal to "Attachment over a new interface > sharing prefixes". >=20 > 1. If there is a Mobile Node Link-layer Identifier Option present > in the request and the Binding Cache entry matches the Access > Technology Type (ATT), and MN-LL-Identifier, the request MUST > be considered as a request for updating that Binding Cache > entry. >=20 > [marco] does that conflict with the above mentioned presence of > the new HI value? Above it's said that the message comprises a HI which > indicates "Attachment over a new interface sharing prefixes", whereas > procedure 1.is about a handover (BCE update). Or is the new > HI value used also in case of handover, not only at initial attachment? >=20 >=20 > 2. If there is a Mobile Node Link-layer Identifier Option present > in the request and the Binding Cache entry does not match the > Access Technology Type (ATT), and MN-LL-Identifier, the >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 6] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > request MUST be considered as a request for creating a new > mobility session sharing the same set of Home Network Prefixes > assigned to the existing Binding Cache entry found. >=20 > 3. If there is not a Mobile Node Link-layer Identifier Option > present in the request, the request MUST be considered as a > request for creating a new mobility session sharing the same > set of Home Network Prefixes assigned to the existing Binding > Cache entry found. >=20 > As described in [I-D.ietf-netext-logical-interface-support], there >=20 > [marco] where is 'there' ? The assumption about MN support should have be= en > clarified earlier in this document. I do not see need for the complete pa= ragraph. >=20 >=20 > should be a local policy in place that ensures that packets are > forwarded coherently. This SHOULD be enforced by the logical > interface engine [I-D.ietf-netext-logical-interface-support]. For > unidirectional outbound communications, there SHOULD also be a policy > at the mobile node defining which physical interface is used to send > the traffic. For bidirectional outbound communications, there SHOULD > be also such a policy, but its content must be consistent with the > policy at the network-side (the details about how this consistency is > ensured are out of the scope of this document). >=20 > In case the MAGs needs to be configured to support flow mobility, > because of packet policing, packet enforcement, charging or similar > reasons, the LMA SHOULD re-use the signaling defined later in this > document to convey this information. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 7] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |LMA| MN1, if1, pref1, MAG1 > +---+ MN1, if2, pref1, MAG2 > //\\ > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ > +----+ +----+ > |MAG1| |MAG2| > +----+ +----+ > | | > | +-------+ | > | | I P | | > | +-------+ | > | | lif | | > | +---+---+ | > |---|if1|if2|----| > +---+---+ > MN1 >=20 > Figure 1: Shared prefix across physical interfaces scenario >=20 >=20 > [marco] I propose to just draw the IP box and the two IF boxes. > same for the description below. Much clearer for the reader, as focus > is on the infrastructure, not on understanding how the LIF works. >=20 >=20 > Next, an example of how flow mobility works in this case is shown. > In Figure 1, a mobile node (MN1) has two different physical > interfaces (if1 and if2), grouped in a unique logical interface > (lif). Each physical interface is attached to a different MAG, both > of them anchored and controlled by the same LMA. Since both physical > interfaces are assigned the same prefix (pref1) upon attachment to > the MAGs, the mobile node has one single IPv6 addresses configured on > the logical interface: pref1::lif. Initially, flow X goes through > MAG1 and flow Y through MAG2. At certain point, flow Y can be moved > to also go through MAG1. As shown in Figure 2, no signaling between > the LMA and the MAGs is needed. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 8] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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 > Figure 2: Flow mobility message sequence with common set of prefixes >=20 >=20 > [marco] The big decision box confuses, IMHO. I'd propose to > draw two small boxes, one on the LMA's and another on the MN's > line which say 'flow policy update'. That should be clear enough. >=20 >=20 >=20 > Figure 3 shows the state of the different network entities after > moving flow Y in the previous example. This documents re-uses some > of the terminology and mechanisms of the flow bindings and multiple > care-of address registration specifications. Note, that in this case > the BIDs shown in the figure are assigned locally by the LMA, since > there is no signaling required in this scenario. In any case, > alternative implementations of flow routing at the LMA could be used, > as it does not impact on the operation of the solution in this case. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 9] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache LMA flowmob state > (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > |LMA| 1, MN1, att1, pref1, MAG1 1, flow X > +---+ 2, MN1, att2, pref1, MAG2 1, flow Y > //\\ > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ MAG1 routing state > +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |MAG1| |MAG2| (dest) (next hop) > +----+ +----+ pref1::/64 p2p-iface-with-MN1 > | | ::/0 LMA > | +-------+ | > | | I P | | MAG2 routing state > | +-------+ | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | lif | | (dest) (next hop) > | +---+---+ | pref1::/64 p2p-iface-with-MN1 > |---|if1|if2|----| ::/0 LMA > +---+---+ > MN1 >=20 > Figure 3: Data structures with common set of prefixes >=20 >=20 > [marco] Maybe it's good to be consistent and the LMA Binding Cache in the= above figure > should also refer to entries IF1, IF1 as depicted in Fig. 1, instead of A= TT. Or vice versa.=20 >=20 >=20 > 3.2.2. MN with different sets of prefixes on each MAG >=20 > A different flow mobility scenario happens when the LMA assigns > different sets of prefixes to physical interfaces of the same mobile > node. This covers the second and third use case scenarios described > in Section 3.1. In this case, specific signaling is required between > the LMA and the MAG to support this scenario. Two different > possibilities are considered next. >=20 > The first possibility corresponds to the use case scenario number 2 > described in Section 3.1, in which a multi-interfaced MN obtains a > different set of prefixes on each attachment. Signaling is required > when a flow is to be moved from its original interface to a new one. > Since the LMA cannot send a PBA message which has not been triggered > in response to a received PBU message, new signaling messages are > defined to cover this case. 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 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 10] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=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. This message is sent to the > new target MAG, i.e. the one selected to be the used in the > forwarding of the flow. The FMI message contains (as explained in > further detail in Section 4.1), the MN-Identifier, the Flow > Identification Mobility option (specified in [RFC6089]) which can > convey prefix or full flow information, and the type of flow mobility > operation (add flow). Optionally, the LMA may send another FMI > message, this time to remove the flow Y state at MAG2. Otherwise the > flow state at MAG2 will be removed upon timer expiration. The > message sequence is shown in Figure 4. >=20 >=20 > [marco] I don't get the point why the flow information is needed on the M= AG. > is that mandatory for the key scenarios? I would propose not covering tha= t > in the core specification part, maybe in the back of the specification if= it's > really needed. >=20 > [marco] One technical proposal: The FMI/FMA imply pretty much overhead, > IMO. Why can't all prefixed be communicated to a MAG during a PBU/PBA > exchange? Having them in the BUL from the beginning allows > driving this like scenario 1by having all keys/identifiers at the MAG. > LMA and MN just enforce the flow policy. > Nothing else needed, or? Well, prefixes might be flagged at the MAG to in= dicate > whether or not the prefix is configured on the attached interface, just t= o know > which ones are to be communicated during ND. But important is the availab= ility > of the HNPs, which serve as key to identify the UE, at the MAG. And these= could > be established early. No intention to change your spec, but just a propos= al > to make protocol operation for flow mobility more lightweight. >=20 >=20 >=20 >=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 | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<------------------------------->|<---------->if2 > | | | | | > | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | > | | FMI[MN1-ID,flow_info(Y),add] | | > | |---------------->| | | > | | FMA | | | > | |<----------------| | | > | | (optional) | | > | | FMI[MN1-ID,flow_info(Y),lft=3D0] | | > | |-------------------------------->| | > | | | FMA | | > | |<--------------------------------| | > | flow Y to | flow Y to | flow Y to | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<--------------->|<-------------------------->if1 > | | | | | >=20 > Figure 4: Flow mobility message sequence when the LMA assigns > different sets of prefixes per physical interface (FMI signaling) >=20 > The state in the network after moving a flow, for the case the LMA > assigns a different set of prefixes is shown in Figure 5. >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 11] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache LMA flowmob state > (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > |LMA| 1, MN1, att1, pref1, 1, flow X > +---+ pref2, MAG1 1, flow Y > //\\ 2, MN1, att2, pref2, MAG2 > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ MAG1 routing state > +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |MAG1| |MAG2| (dest) (next hop) > +----+ +----+ pref1::/64 p2p-iface-with-MN1 > | | pref2::/64 p2p-iface-with-MN1 > | +-------+ | ::/0 LMA > | | I P | | > | +-------+ | MAG2 routing state > | | lif | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | +---+---+ | (dest) (next hop) > |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 > +---+---+ ::/0 LMA > MN1 >=20 > Figure 5: Data structures when the LMA assigns a different set of > prefixes >=20 > The second possibility corresponds to the use case scenario number 3 > described in Section 3.1, in which upon new physical interface > attachment, the MN obtains a combination of prefix(es) in use and new > prefix(es). Here, the mobile node is already attached to the PMIPv6- > Domain via MAG1. At a certain moment, the mobile node attaches a new > interface (if2) to MAG2. MAG2 sends a PBU which is then used by the > LMA to enable flow mobility. In this case, we consider that flows > are moved with a prefix granularity, meaning that flows are moved by > moving prefixes among the different MAGs the mobile node is attached > to. In this example, flow Y is bound to pref2::/64 and therefore the > flow can be moved by just binding pref2::/64 to MAG2. This is done > by including the prefix in the PBA message. The scenario is shown in > Figure 6. >=20 > Optionally, a message can be sent to MAG1 to remove the transferred > prefix(es). This message can be a Binding Revocation Indication > message [RFC5846] with the P bit set to indicate that this is > revocation of PMIP prefix(es). After processing BRI, the source MAG > will send a Binding Revocation Acknowledgement (BRA) message back to > the LMA. >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 12] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > In case flow mobility is needed with a finer granularity than full > prefix (e.g., flow level), this is done by including in the PBA a > Flow Identification Mobility option (specified in [RFC6089]) which > can convey full flow information. The MAG can also include the Flow > Identification Mobility option in the PBU message that it sends to > the LMA. This serves as a request for the LMA to consider the flow > policy rules specified in the option. In this case no prefix is > removed from any MAG because the movement is performed at flow level. >=20 > +-----+ +------+ +------+ +-----+ > Internet | LMA | | MAG1 | | MAG2 | | MN | > +-----+ +------+ +------+ +-----+ > | | | | | > | 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 | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<--------------->|<-------------------------->if1 > | | | | | > | | | | | > | | | MN powers on if2 and > | | | performs L2 attachment > | | | |<-----------if2 > | | | PBU | | > | |<--------------------------------| | > | | PBA (pref2) | | | > | |-------------------------------->| | > | LMA moves pref2 to new | | | > | binding cache entry for if2 | | | > | | | | | > | | | | | > | | (optional) | | | > | | BRI[pref2] | | | > | |---------------->| | | > | | BRA | | | > | |<----------------| | | > | flow y to | flow y to | flow y to | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<------------------------------->|<---------->if2 > | | | | | >=20 > Figure 6: Flow mobility message sequence with different set of > prefixes per physical interface (PBU signaling) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 13] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 4. Message formats >=20 > 4.1. Flow Mobility Initiate (FMI) >=20 > The LMA sends an FMI message to a MAG to enable flow mobility. It is > a Mobility Header message. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Sequence Number: >=20 > A monotonically increasing integer. Set by the LMA sending then > initiate message, and used to match a reply in the acknowledge. >=20 > 'I' (initiate) flag: >=20 > Set to 1, indicates it is an FMI message. >=20 > Reserved: >=20 > This field is unused. MUST be set to zero by the sender. >=20 > Lifetime: >=20 > The requested time in seconds for which the LMA asks the MAG keep > flow-specific state. A value of all one bits (0xffff) represents > infinity. If set to 0, it indicates a request to remove state > about the flow (cancel flow mobility) >=20 > Mobility Options: >=20 > MUST contain the MN-ID, followed by one or more Flow > Identification Mobility options [RFC6089]. >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 14] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 4.2. Flow Mobility Acknowledge (FMA) >=20 > The MAG sends an FMI message to the LMA as a response to the FMI > message. It is a Mobility Header message. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| Reserved | Status | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Sequence Number: >=20 > A monotonically increasing integer. Copied from the value set by > the sending LMA in the FMI message being acknowledged by this FMA > message. >=20 > 'I' flag: >=20 > Set to 0, indicates it is an FMA message. >=20 > Reserved: >=20 > This field is unused. MUST be set to zero by the sender. >=20 > Status (values to be assigned by IANA): >=20 > ??: Success. >=20 > ??: Reason unspecified. >=20 > ??: MN not attached. >=20 > ??: Sequence number out of window. >=20 > ??: Traffic Selector format unsupported. >=20 > ??: No existing Flow Mobility Cache entry. >=20 > Lifetime: >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 15] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > The requested time in seconds for which the MAG keeps flow- > specific state. A value of all one bits (0xffff) represents > infinity. >=20 > Mobility Options: >=20 > When Status code is 0, MUST contain the MN-ID, followed by one or > more Flow Identification Mobility options [RFC6089]. >=20 >=20 > 5. Conceptual Data Structures >=20 > 5.1. Multiple Care-of Address Registration >=20 > The LMA is extended to allow a mobile node to register multiple proxy > care of address (Proxy-CoA). >=20 > [marco] That's actually supported by RFC5213, isn't it? Maybe you could > write ' ..to register multiple proxy care of address (Proxy-CoA) while us= ing the > same address (prefix) beyond a single interfaces and MAG' >=20 >=20 > The LMA maintains multiple binding > cache entries for an MN. The number of binding cache entries for an > MN is equal to the number of the MN's interfaces attaching to any > MAGs. >=20 > +---------+-----+-------+------+-----------+------------+ > | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | > +---------+-----+-------+------+-----------+------------+ > | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | > | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | > +---------+-----+-------+------+-----------+------------+ >=20 > Figure 7: Extended Binding Cache >=20 > Figure 7 shows two Binding Cache Entries of the MN1 when it is > attached to the network using two different access technologies. > Both of the two attachments share HNP1 and are bounded to two > different Proxy-CoAs. >=20 > 5.2. Flow Mobility Cache >=20 > Each LMA MUST maintain a flow mobility cache (FMC) as shown in > Figure 8. This table MUST contain an entry for each flow sent from > the MN. A flow binding entry includes the following fields: >=20 > o Flow Identifier Priority (FID-PRI). >=20 > o Flow Identifier (FID). >=20 > o Traffic Selector (TS). >=20 > o Binding Identifier (BID). >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 16] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > o Action. >=20 > o Active/Inactive. >=20 >=20 > +---------+-----+-----+------+---------+----------+ > | FID-PRI | FID | TS | BIDs | Action | A/I | > +---------+-----+-----+------+---------+----------+ > | 10 | 2 | TCP | 1 | Forward | Active | > | 20 | 4 | UDP | 1,2 | Forward | Inactive | > +---------+-----+-----+------+---------+----------+ >=20 > Figure 8: Flow Mobility Cache >=20 > The BID field contains the identifier of the binding cache entry > which packets matching the flow information described in the TS field > will be forwarded to. When a flow is decided to be moved, the > affected BID(s) of the table are updated. >=20 > Similar to flow binding described in [RFC6089], each flow binding > entry points to a specific binding cache entry identifier (BID). > When a flow is moved, the LMA simply updates the pointer of the flow > binding entry with the BID of the interface to which the flow will be > moved. The traffic selector (TS) in flow binding table is defined as > in [RFC6088]. TS is used to classify the packets of flows basing on > specific parameters such as service type, source and destination > address, etc. The packets matching with the same TS will be applied > the same forwarding policy. FID-PRI is the order of precedence to > take action on the traffic. Action may be forward or drop.=20 >=20 > [marco] is flow filtering a new feature of the specification? > I did not see its description in the operations sections. >=20 >=20 > If a > binding entry becomes 'Inactive' it does not affect data traffic. An > entry becomes 'Inactive' only if all of the BIDs are deregistered. >=20 > The Mobile Access Gateway MAY also maintain a similar data structure. > In case no full flow mobility state is required at the MAG, the > Binding Update List (BUL) data structure is enough and no extra > conceptual data entries are needed. In case full per-flow state is > required at the MAG, it SHOULD also maintain a Flow Mobility Cache > structure. >=20 >=20 > [marco] I think this should be one of the most important sections of the > specification. The protocol operation before should refer to the BCE and > the table, where the flow rules are available, and describe the procedure > from packet arrival to the release of the encapsulated packet on the wire= . > What's being looked up first, the Flow Mobility Cache or the BCE? >=20 >=20 > 6. Mobile Node considerations >=20 > This specification assumes the MN implements the logical interface > model. >=20 > [marco] it should not, in my opinion. >=20 >=20 > The "logical interface" at the IP layer hides the use of > different physical media from the IP stack, enabling the MN to send > and receive packets over different interfaces. This document assumes > the MN behaves as stated in the applicability statement document > [I-D.ietf-netext-logical-interface-support]. In particular, it is >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 17] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > assumed that -- for the case of bidirectional traffic -- the logical > interface at the MN "replicates" the behavior observed for downlink > packets on a per-flow basis. This means that the MN sends UL Flow X > on the same interface which received the DL Flow X. It also means > that if the LMA moves flow X during its lifetime, the MN will follow > that change, upon the reception of packets of flow X via a different > interface. >=20 > This specification only supports flow mobility between different > physical interfaces belonging to the same logical interface. If an > MN has several logical interfaces, flow mobility across different > logical interfaces is not supported. >=20 >=20 > ../snip >=20 >=20 >=20 > Hope it helps. >=20 > marco >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Video over Mobile Networks http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-LZ2kcX+WHvcm6+9xfG9B 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.12 (GNU/Linux) iEYEABECAAYFAk/3EPgACgkQNdy6TdFwT2dl+wCgvVWJcIQ3xFASNo8Q5e6r0kmg 6HQAoJpsSab4CVwIu65n2+MtTwXjR/q2 =+uQT -----END PGP SIGNATURE----- --=-LZ2kcX+WHvcm6+9xfG9B-- From kpxue@ustc.edu Mon Jul 9 21:04:08 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 E43DE11E810D for ; Mon, 9 Jul 2012 21:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.293 X-Spam-Level: ** X-Spam-Status: No, score=2.293 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] 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 mbifsyVtvoM5 for ; Mon, 9 Jul 2012 21:04:08 -0700 (PDT) Received: from ustc.edu (smtp2.ustc.edu [202.141.160.101]) by ietfa.amsl.com (Postfix) with SMTP id C5E1D11E80F2 for ; Mon, 9 Jul 2012 21:04:07 -0700 (PDT) Received: from lenovo-09d60efa (unknown [202.38.84.142]) by mail.ustc.edu (Coremail) with SMTP id BxUW2rDr0DLEqftPBedVEg==.2551S2; Tue, 10 Jul 2012 12:04:32 +0800 (CST) Date: Tue, 10 Jul 2012 00:04:16 -0500 From: kpxue To: netext X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201207100004132653742@ustc.edu> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Coremail-Antispam: 1U3129KBjvJXoW7Zw1rtr1xuFW3CF18Gr1fXrb_yoW8GF1kpa 43Wa9Ig3WrZr1xJ3WkJFyUAa4YvrWfXrW5uFy8JF1IqF15CFySkw1rKFWIyay7CryrWrWk Z3WxArs8ZwnxWr7anT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U0I7k0a2IF6F4UMc02F40EFcxC0VAKzVAqx4xG6I80ewAYFVCjjxCrM7AC8VAFwI0_Jr0_ Gr1l1I0E4x80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4yl1IIY67AEw4v_Jr0_Jr4lYx 0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UM4xvF2IEb7IF0Fy264kE 64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjxxvEw4Wlc2IjII80xcxEwVAKI48JMxCjnVAKz4 kxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy70xZFpf9x07jujgxUUUUU= Subject: [netext] Request comments on draft-xue-netext-flowmo-multilma-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 04:04:09 -0000 SGkgYWxsLCANCg0KV2UndmUgc3VibWl0dGVkIGEgZHJhZnQgZm9yIHRoZSBleHRlbnNpb25zIG9m IGZsb3cgbW9iaWxpdHkgaW4gbXVsdGlwbGUgTE1BIGVudmlyb25tZW50LCBiZWxvdyBpcyB0aGUg bGluazoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHVlLW5l dGV4dC1mbG93bW8tbXVsdGlsbWEtMDAudHh0DQoNClBsZWFzZSBwcm92aWRlIGNvbW1lbnRzIGFu ZCBmZWVkYmFjay4gDQoNClRoYW5rcywNCg0KS2FpcGluZyBYdWUNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHVlLW5l dGV4dC1mbG93bW8tbXVsdGlsbWEtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IExlaSBaaHUgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCiANCkZp bGVuYW1lOiAgZHJhZnQteHVlLW5ldGV4dC1mbG93bW8tbXVsdGlsbWENClJldmlzaW9uOiAgMDAN ClRpdGxlOiAgRmxvdyBNb2JpbGl0eSBJbiBNdXRpLUxNQSBFbnZpcm9ubWVudA0KQ3JlYXRpb24g ZGF0ZTogIDIwMTItMDYtMzANCldHIElEOiAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDIyDQpVUkw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXh1ZS1uZXRleHQtZmxvd21vLW11bHRpbG1hLTAwLnR4dA0KU3RhdHVzOiBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1ZS1uZXRleHQtZmxvd21vLW11bHRpbG1hDQpI dG1saXplZDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHVlLW5ldGV4dC1mbG93 bW8tbXVsdGlsbWEtMDANCiANCiANCkFic3RyYWN0Og0KICAgUE1JUHY2IGFsbG93cyBtdWx0aXBs ZSBMb2NhbCBNb2JpbGl0eSBBbmNob3IoTE1BKSB0byBleGlzdCBpbiBhDQogICBQTUlQdjYgZG9t YWluLCBpdCBNQVkgY2F1c2UgdGhhdCBkaWZmZXJlbnQgaW50ZXJmYWNlcyBvZiBhIG1vYmlsZQ0K ICAgbm9kZShNTikgYXJlIGFuY2hvcmVkIHRvIGRpZmZlcmVudCBMTUFzLiAgSW4gdGhpcyBkb2N1 bWVudCwgd2UNCiAgIHByb3Bvc2UgdG8gZGlzY3VzcyBob3cgdG8gc3VwcG9ydCBmbG93IG1vYmls aXR5IGluIG11bHRpLUxNQQ0KICAgZW52aXJvbm1lbnQuICBBbW9uZyB0aGUgZGlzY3Vzc2VkIHNj ZW5hcmlvcywgVGhlIHNjZW5hcmlvIG9mDQogICBkaWZmZXJlbnQgaW50ZXJmYWNlcyB3aXRoIGRp ZmZlcmVudCBNQUdzIGluIG11bHRpLUxNQSBlbnZpcm9ubWVudA0KICAgY2Fubm90IHVzZSB0cmFk aXRpb25hbCB3YXlzIHRvIHJlYWxpemUgZmxvdyBtb2JpbGl0eSB0byBhIGV4aXN0aW5nDQogICBp bnRlcmZhY2UuDQo= From rkoodli@cisco.com Mon Jul 9 21:41:09 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 E80B511E8136 for ; Mon, 9 Jul 2012 21:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 VoLWQ93IWQRK for ; Mon, 9 Jul 2012 21:41:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D9BE711E8117 for ; Mon, 9 Jul 2012 21:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=1950; q=dns/txt; s=iport; t=1341895294; x=1343104894; h=from:to:subject:date:message-id:mime-version; bh=cb5XRmjbPag+lRAAaH5zOtr6BJ5MYNuhAJSl5wMm/1U=; b=IU66FBcYhDl+7M2qJ9P6bnGwPcz8CLIgSEN2xSgbheclJz6X9bpqNMVe GYqBNn/vNBuUNQ7Ws1WUsiIfbPx1fOv4SX8l/o2dmRw/4BGcj1KvHzTow bgK+7QpHeCju7+jpn9N/SHEWZTJA4iy/0ZnFpbhWVh4EzM5RXKjcmuVPm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD6y+0+tJXG//2dsb2JhbABFgkq1MoEHgicSAXgBDAE6ORQTBBMih2ubAIEooD2LQIYiA5U2jh+BZoJf X-IronPort-AV: E=Sophos;i="4.77,556,1336348800"; d="scan'208,217";a="100223075" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jul 2012 04:41:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6A4fYO8004866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jul 2012 04:41:34 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.171]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 23:41:33 -0500 From: "Rajeev Koodli (rkoodli)" To: "netext@ietf.org" Thread-Topic: Soliciting agenda items for IETF 84 Thread-Index: AQHNXlZH33CmXLw8XEKhFhA3AFKiXQ== Date: Tue, 10 Jul 2012 04:41:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.78.90] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.000 x-tm-as-result: No--29.305400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC2102CD5604rkoodliciscocom_" MIME-Version: 1.0 Subject: [netext] Soliciting agenda items for IETF 84 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 04:41:09 -0000 --_000_CC2102CD5604rkoodliciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The Netext WG is scheduled to meet at IETF84 on August 2, 2012 from 1300 - = 1500. If you need an agenda slot at the WG meeting, please send a request to the chairs (netext-chairs@tools.ietf.org) Please indicate: 1. Name of the I-D 2. Relevance to the Netext WG charter 3. Amount of time needed Thanks. -Chairs --_000_CC2102CD5604rkoodliciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1C51F67BA37DC04BAEA026A430E9C5B9@cisco.com> Content-Transfer-Encoding: quoted-printable

Hello,

The Netext WG is scheduled to meet at IETF84 on August 2, 2012 from 1300 - = 1500.

If you nee= d an agenda slot at the WG meeting, please send a request to the
chairs (netext-chairs@tools= .ietf.org)

Please indicate:

1. Name of the I-D
2. Relevance to the Netext WG charter
3. Amount of time needed


Thanks.

-Chairs

--_000_CC2102CD5604rkoodliciscocom_-- From tu.yangwei@zte.com.cn Tue Jul 10 01:43:24 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 393D521F85CE for ; Tue, 10 Jul 2012 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 SJbXM+0Jmukr for ; Tue, 10 Jul 2012 01:43:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 21B6C21F85A1 for ; Tue, 10 Jul 2012 01:43:22 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201465182496; Tue, 10 Jul 2012 16:36:44 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 67558.1465182496; Tue, 10 Jul 2012 16:43:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6A8hcBd063905 for ; Tue, 10 Jul 2012 16:43:38 +0800 (GMT-8) (envelope-from tu.yangwei@zte.com.cn) To: "netext@ietf.org" MIME-Version: 1.0 X-KeepSent: 36AB452F:B1506D61-48257A37:002AC34A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: tu.yangwei@zte.com.cn Date: Tue, 10 Jul 2012 16:43:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-10 16:43:40, Serialize complete at 2012-07-10 16:43:40 Content-Type: multipart/alternative; boundary="=_alternative 0030705248257A37_=" X-MAIL: mse01.zte.com.cn q6A8hcBd063905 Subject: [netext] Request for comments on draft-tu-netext-mn-status-option-02 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:43:24 -0000 This is a multipart message in MIME format. --=_alternative 0030705248257A37_= Content-Type: text/plain; charset="US-ASCII" Dear all, We have submitted a new version of draft-tu-netext-mn-status-option, and you can find the URL below. This draft was previously presented in the IETF 82# meeting, and some good comments were received. To meet those comments, we add some descriptions for use case scenarios and MAG&LMA considerations. We also defines new options allowing the network getting information about mobile node capabilities in this version. Please kindly provide your comments and suggestions, and your help will be truly appreciated. BR, Yangwei Tu ----------------------------------------------------------------- A new version of I-D, draft-tu-netext-mn-status-option-02.txt has been successfully submitted by Yangwei Tu and posted to the IETF repository. Filename: draft-tu-netext-mn-status-option Revision: 02 Title: MN Status Option for Proxy Mobile IPv6 Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-tu-netext-mn-status-option-02.txt Status: http://datatracker.ietf.org/doc/draft-tu-netext-mn-status-option Htmlized: http://tools.ietf.org/html/draft-tu-netext-mn-status-option-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-tu-netext-mn-status-option-02 Abstract: IP flow mobility enables the ability of movement of selected flows from one access technology to another. This document extends the Proxy Mobile IPv6 signaling to convey mobile node's status information that can be used by the network to decide when and how perform flow mobility. It also defines options allowing the network getting information about different mobile node capabilities, which might be considered to decide how to tackle the node's mobility. --=_alternative 0030705248257A37_= Content-Type: text/html; charset="US-ASCII"
Dear all,
We have submitted a new version of draft-tu-netext-mn-status-option, and you can find the URL below.
This draft was previously presented in the IETF 82# meeting, and some good comments were received.
To meet those comments, we add some descriptions for use case scenarios and MAG&LMA considerations.
We also defines new options allowing the network getting information about mobile node capabilities in this version.
Please kindly provide your comments and suggestions, and your help will be truly appreciated.

BR,
Yangwei Tu
-----------------------------------------------------------------
A new version of I-D, draft-tu-netext-mn-status-option-02.txt
has been successfully submitted by Yangwei Tu and posted to the
IETF repository.

Filename:                  draft-tu-netext-mn-status-option
Revision:                  02
Title:                                   MN Status Option for Proxy Mobile IPv6
Creation date:                  2012-07-09
WG ID:                                   Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-tu-netext-mn-status-option-02.txt
Status:          http://datatracker.ietf.org/doc/draft-tu-netext-mn-status-option
Htmlized:        http://tools.ietf.org/html/draft-tu-netext-mn-status-option-02
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-tu-netext-mn-status-option-02

Abstract:
  IP flow mobility enables the ability of movement of selected flows
  from one access technology to another.  This document extends the
  Proxy Mobile IPv6 signaling to convey mobile node's status
  information that can be used by the network to decide when and how
  perform flow mobility.  It also defines options allowing the network
  getting information about different mobile node capabilities, which
  might be considered to decide how to tackle the node's mobility.
 --=_alternative 0030705248257A37_=-- From John.Kaippallimalil@huawei.com Tue Jul 10 06:39:23 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 A330421F86EA for ; Tue, 10 Jul 2012 06:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8kCSb5WbLBU for ; Tue, 10 Jul 2012 06:39:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1321F86D3 for ; Tue, 10 Jul 2012 06:39:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX03993; Tue, 10 Jul 2012 09:39:50 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 06:37:48 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.20]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 06:37:49 -0700 From: John Kaippallimalil To: "netext@ietf.org" Thread-Topic: draft-kaippallimalil-netext-pmip-qos-wifi-00.txt Thread-Index: AQHNXqEyGTGlpfMkYUqGr7C2ULakig== Date: Tue, 10 Jul 2012 13:37:48 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA117077D38@dfweml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.64.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [netext] draft-kaippallimalil-netext-pmip-qos-wifi-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:39:23 -0000 SGksDQpQbGVhc2UgaGF2ZSBhIGxvb2sgYXQgYSBuZXcgZHJhZnQgcmVsYXRlZCB0byBQTUlQIFFv UyBhbmQgV2lGaS4NCiANClRoaXMgZHJhZnQgaXMgZXhwZWN0ZWQgdG8gY29tcGxlbWVudCBjb25j ZXB0cyBpbiBQTUlQIFFvUy4gDQpIZXJlLCB0aGUgUE1JUCBRb1MgaXMgdXNlZCB0byBleHBsaWNp dGx5IHByb3Zpc2lvbiBwZXIgc2Vzc2lvbiBRb1MgcG9saWN5IG9uIHRoZSBXaUZpIEFQLiBUaGUg ZHJhZnQgYWxzbyBzdWdnZXN0cyBhIG1hcHBpbmcgZm9yIDNHUFAgUW9TIHRvIDgwMi4xMWUgQUMu IA0KDQpUaGFua3MsDQpKb2huDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBTYXR1cmRheSwgSnVseSAwNywgMjAxMiAxMjowNiBQTQ0KVG86IEpvaG4gS2Fp cHBhbGxpbWFsaWwNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt a2FpcHBhbGxpbWFsaWwtbmV0ZXh0LXBtaXAtcW9zLXdpZmktMDAudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWthaXBwYWxsaW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13aWZpLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIEthaXBwYWxsaW1h bGlsIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQta2FpcHBhbGxpbWFsaWwtbmV0ZXh0LXBtaXAtcW9zLXdpZmkNClJldmlzaW9uOgkgMDANClRp dGxlOgkJIE1hcHBpbmcgUE1JUCBRdWFsaXR5IG9mIFNlcnZpY2UgaW4gV2lGaSBOZXR3b3JrDQpD cmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0wNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpOdW1iZXIgb2YgcGFnZXM6IDExDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWthaXBwYWxsaW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13 aWZpLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWthaXBwYWxsaW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13aWZpDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthaXBwYWxsaW1hbGlsLW5l dGV4dC1wbWlwLXFvcy13aWZpLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHBy b3Bvc2VzIGEgbWFwcGluZyBmb3IgUE1JUCBRb1MgcGFyYW1ldGVycyBvZiBlYWNoDQogICBtb2Jp bGl0eSBzZXNzaW9uIHRoYXQgYSBXTEMgY29uZmlndXJlcyBvbiBhIFdpRmkgQWNjZXNzIFBvaW50 LiBJbg0KICAgcGFydGljdWxhciB0aGVyZSBpcyBhIHJlY29tbWVuZGF0aW9uIGZvciBjb25zaXN0 ZW50IG1hcHBpbmcgYmV0d2Vlbg0KICAgRFNDUCBhbmQgUUNJIHRvIDgwMi4xMWUgcGFyYW1ldGVy cy4gVGhlIGRvY3VtZW50IGFsc28gZGlzY3Vzc2VzIHRoYXQNCiAgIHRoZXNlIFFvUyBwYXJhbWV0 ZXJzIGNhbiBiZSB1c2VkIGJ5IHRoZSBXaUZpIEFjY2VzcyBQb2ludCB0byBwcm92aWRlDQogICBw cmlvcml0eSBiYXNlZCBzZXJ2aWNlcyBiYXNlZCBvbiBjb250ZW50aW9uIGluIFdpRmkgcmFkaW8g bmV0d29yayBvcg0KICAgcmVzZXJ2YXRpb24gYmFzZWQgc2VydmljZXMgaW4gY29udGVudGlvbiBm cmVlIGN5Y2xlcyBpbiB0aGUgV2lGaQ0KICAgcmFkaW8gbmV0d29yay4NCg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From JuanCarlos.Zuniga@InterDigital.com Tue Jul 10 12:16:53 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 DB7BF11E80EB for ; Tue, 10 Jul 2012 12:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.206, 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 APRfm8tbzjc6 for ; Tue, 10 Jul 2012 12:16:49 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 628E411E80E3 for ; Tue, 10 Jul 2012 12:16:49 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 15:17:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD5ED0.9E708944" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Jul 2012 15:17:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review - draft-ietf-netext-pmipv6-flowmob-03 Thread-Index: Ac1e0J39/ry1AqAHSxaDTyLfahq9xA== From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 10 Jul 2012 19:17:16.0982 (UTC) FILETIME=[9E8C5D60:01CD5ED0] Subject: [netext] review - draft-ietf-netext-pmipv6-flowmob-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: Tue, 10 Jul 2012 19:16:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD5ED0.9E708944 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 These are the comments I have for draft-ietf-netext-pmipv6-flowmob-03: =20 =20 =20 1. Introduction: =20 - I would suggest rewriting the second and third paragraph as follows: =20 "PMIPv6 allows an MN to connect to the same PMIPv6 domain through different interfaces. This document specifies protocol extensions to Proxy Mobile IPv6 between the LMA and MAGs to enable "flow mobility" and hence distribute specific traffic flows on different physical interfaces. It is assumed that an MN IP layer interface can simultaneously and/or sequentially attach to multiple MAGs, possibly over multiple media. One form to achieve this multiple attachment is described in [I-D.ietf-netext-logical-interface-support], which allows the mobile node supporting traffic flows on different physical interfaces regardless of the assigned prefixes on those physical interfaces." =20 =20 2. Terminology =20 - It should be "FMA - Flow Mobility Acknowledgement" (several instances throughout the document) =20 =20 =20 3.1 Use case scenarios =20 - I would suggest changing the first paragraph as follows: =20 "In contrast to a typical handover where connectivity to a physical medium is relinquished and then re-established, flow mobility assumes a mobile node can have simultaneous access to more than one network. In this specification, it is assumed that the LMA is aware of the mobile node's capabilities to have simultaneous access to both access networks and it can handle the same or a different set of prefixes on each access. How this is done is outside the scope of this specification." =20 - The three numbered scenarios are first described at the initialization point (i.e. attachment), and then the flow mobility use case is described for each one of them below in the text. This is confusing, as at first sight it looks like the numbered paragraphs contain the whole use case description text. I would suggest describing each scenario in full in each one of the numbered sections (e.g. scenario 2 should describe the initial attachment and also the flow mobility use case to make it clear why it needs signaling extensions). It would also help adding a reference stating that the operational description will be provided in sections 3.2.1, 3.2.2, etc. =20 - Rewrite the last paragraph in section 3.1 as follows: =20 "The extensions described in this document support all the aforementioned scenarios." =20 =20 =20 3 =20 3.1 =20 3.2.1 MN sharing a common set of prefixes on all MAGs=20 =20 - Remove the following sentence from the paragraph: =20 "When a multi-interfaced mobile node connects to a PMIPv6-domain, it performs regular attachment and as a result is able to configure an IP address (or a set of IP addresses) on the logical interface hiding the different physical interfaces." =20 - I believe the following should be a MUST: =20 "In this document a new Handoff Indicator (HI) value ("Attachment over a new interface sharing prefixes") is defined, to allow the mobile access gateway indicate to the local mobility anchor that the same set of prefixes MUST be assigned to the mobile node. The considerations in Section 5.4.1 of [RFC5213] are updated by this specification as follows:" =20 - Suggest promoting the paragraph starting with "As described in [I-D.ietf-netext-logical-interface-support]..." to the end of section 3.2 (before 3.2.1) and reword as follows: =20 "Both MN and LMA SHOULD have local policies in place that ensure packets are forwarded coherently for unidirectional and bidirectional communications. The details about how this consistency is ensured are out of the scope of this document." =20 - I believe the following should be a MUST (+ typo): =20 "In case the MAGs need to be configured to support flow mobility because of packet policing, packet enforcement, charging or similar reasons, the LMA MUST re-use the signaling defined later in this document to convey this information." =20 - In the paragraph starting with "Figure 3 shows the state...", remove the parenthesis and the text inside. =20 =20 =20 3.2.2 MN with different sets of prefixes on each MAG=20 =20 - I believe the following should be a MUST =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. This message MUST be sent to the new target MAG, i.e. the one selected to be the used in the forwarding of the flow..." =20 - It would probably be clearer to have one section 3.2.1, 3.2.2 and 3.2.3 for each described scenario (1, 2 and 3), even if the text in the section simply states that the use case is the same as the next/previous section. It would make it easier to read back and forth in the document when searching for specific information about a use case. =20 - Figure4: I would suggest exchanging the order of the optional FMI/FMA messages after the new flow Y through MAG1, as these messages are not time-critical. =20 - Figure 6: I would suggest exchanging the order of the optional BRI/BRA messages after the new flow Y through MAG2, as these messages are not time-critical.=20 =20 - I believe the following requirements language is needed (original paragraphs starting with "Optionally, a message can be sent..."): =20 "Optionally, a Binding Revocation Indication message [RFC5846] with the P bit set MAY be sent to MAG1 to indicate that this is a revocation of PMIP prefix(es). After processing BRI, the source MAG MUST send a Binding Revocation Acknowledgement (BRA) message back to the LMA. =20 - Move the paragraph starting with "In case flow mobility is needed with a finer granularity...") to after Figure 6, and reword with requirements language as follows: =20 "In case flow mobility is needed with a finer granularity (e.g., flow level instead of full prefix), a Flow Identification Mobility option (specified in [RFC6089]) that can convey full flow information MUST be included in the PBA. The MAG MAY also include the Flow Identification Mobility option in the PBU message that it sends to the LMA. This serves as a request from MAG to LMA to consider the flow policy rules specified in the option. In this case, no prefix is removed from any MAG because the movement is performed at a flow level." =20 =20 4. Messages =20 - Add the following sentence to the beginning of the section: =20 "This section defines extensions to the Proxy Mobile IPv6 [RFC5213] protocol messages" =20 4.1 Flow Mobility Initiate (FMI) =20 - Replace "acknowledge" by "acknowledgement" in the "Sequence Number:" description =20 =20 =20 I hope you find these comments useful. =20 Best regards, =20 Juan Carlos =20 =20 =20 ------_=_NextPart_001_01CD5ED0.9E708944 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

These are the comments I have for = draft-ietf-netext-pmipv6-flowmob-03:

 

 

 

1.       = Introduction:

 

-          = I would suggest rewriting the second and third = paragraph as follows:

 

“PMIPv6 = allows an MN to connect to the same PMIPv6 domain through different = interfaces.  This document specifies protocol extensions to Proxy = Mobile IPv6 between the LMA and MAGs to enable “flow = mobility” and hence distribute specific traffic flows on different = physical interfaces. It is assumed that an MN IP layer interface can = simultaneously and/or sequentially attach to multiple MAGs, possibly = over multiple media. One form to achieve this multiple attachment is = described in [I-D.ietf-netext-logical-interface-support], which allows = the mobile node supporting traffic flows on different physical = interfaces regardless of the assigned prefixes on those physical = interfaces.”

 

 

2.       = Terminology

 

-          = It should be “FMA – Flow Mobility = Acknowledgement” (several instances throughout the = document)

 

 

 

3.1   = Use case scenarios

 

-          = I would suggest changing the first paragraph as = follows:

 

“In =
contrast to a typical handover where connectivity to a physical medium =
is relinquished and then re-established, flow mobility assumes a mobile =
node can have simultaneous access to more than one network. In this =
specification, it is assumed that the LMA is aware of the mobile =
node’s capabilities to have simultaneous access to both access =
networks and it can handle the same or a different set of prefixes on =
each access.  How this is done is outside the scope of this =
specification.”

 

-          = The three numbered scenarios are first described = at the initialization point (i.e. attachment), and then the flow = mobility use case is described for each one of them below in the text. = This is confusing, as at first sight it looks like the numbered = paragraphs contain the whole use case description text. I would suggest = describing each scenario in full in each one of the numbered sections = (e.g. scenario 2 should describe the initial attachment and also the = flow mobility use case to make it clear why it needs signaling = extensions). It would also help adding a reference stating that the = operational description will be provided in sections 3.2.1, 3.2.2, = etc.

 

-          = Rewrite the last paragraph in section 3.1 as = follows:

 

“The extensions described in this document = support all the aforementioned scenarios.”

 

 

 

3          =  

3.1          =  

3.2.1          = MN sharing a common set of prefixes on all MAGs =

 

-          = Remove the following sentence from the = paragraph:

 

“When a multi-interfaced mobile node connects = to a PMIPv6-domain, it performs regular attachment and as a result is = able to configure an IP address (or a set of IP addresses) on the = logical interface hiding the different physical = interfaces.”

 

-          = I believe the following should be a = MUST:

 

“In this document a new Handoff Indicator = (HI) value ("Attachment over a new interface sharing = prefixes") is defined, to allow the mobile access gateway indicate = to the local mobility anchor that the same set of prefixes MUST be = assigned to the mobile node. The considerations in Section 5.4.1 of = [RFC5213] are updated by this specification as = follows:”

 

-          = Suggest = promoting the paragraph starting with “As described in = [I-D.ietf-netext-logical-interface-support]...” to the end = of section 3.2 (before 3.2.1) and reword as = follows:

 =

“Both= MN and LMA SHOULD have local policies in place that ensure packets are = forwarded coherently for unidirectional and bidirectional = communications. The details about how this consistency is ensured are = out of the scope of this document.”

 

-          = I believe the following should be a MUST (+ = typo):

 

“In case the MAGs need to be configured to = support flow mobility because of packet policing, packet enforcement, = charging or similar reasons, the LMA MUST re-use the signaling defined = later in this document to convey this = information.”

 

-          = In the paragraph starting with “Figure 3 = shows the state…”, remove the parenthesis and the text = inside.

 

 

 

3.2.2          = MN with different sets of prefixes on each MAG =

 

-          = I believe the following should be a = MUST

 

“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.  This = message MUST be sent to the new target MAG, i.e. the one selected to be = the used in the forwarding of the flow...”

 

-          = It would probably be clearer to have one section = 3.2.1, 3.2.2 and 3.2.3 for each described scenario (1, 2 and 3), even if = the text in the section simply states that the use case is the same as = the next/previous section. It would make it easier to read back and = forth in the document when searching for specific information about a = use case.

 

-          = Figure4: I would suggest exchanging the order of = the optional FMI/FMA messages after the new flow Y through MAG1, as = these messages are not time-critical.

 

-          = Figure 6: I would suggest exchanging the order = of the optional BRI/BRA messages after the new flow Y through MAG2, as = these messages are not time-critical.

 

-          = I believe the following requirements language is = needed (original paragraphs starting with “Optionally, a message = can be sent…”):

 

“Optionally, a Binding Revocation Indication = message [RFC5846] with the P bit set MAY be sent to MAG1 to indicate = that this is a revocation of PMIP prefix(es).  After processing = BRI, the source MAG MUST send a Binding Revocation Acknowledgement (BRA) = message back to the LMA.

 

-          = Move the paragraph starting with “In case = flow mobility is needed with a finer granularity…”) to after = Figure 6, and reword with requirements language as = follows:

 

“In case flow mobility is needed with a finer = granularity (e.g., flow level instead of full prefix), a Flow = Identification Mobility option (specified in [RFC6089]) that can convey = full flow information MUST be included in the PBA.  The MAG MAY = also include the Flow Identification Mobility option in the PBU message = that it sends to the LMA.  This serves as a request from MAG to LMA = to consider the flow policy rules specified in the option.  In this = case, no prefix is removed from any MAG because the movement is = performed at a flow level.”

 

 

4.       = Messages

 

-          = Add the following sentence to the beginning of = the section:

 

“This section defines extensions to the Proxy = Mobile IPv6 [RFC5213] protocol messages”

 

4.1   = Flow Mobility Initiate (FMI)

 

-          = Replace “acknowledge” by = “acknowledgement” in the “Sequence Number:” = description

 

 

 

I hope you = find these comments useful.

 

Best = regards,

 

Juan Carlos

 

 

 

------_=_NextPart_001_01CD5ED0.9E708944-- From cjbc@it.uc3m.es Tue Jul 10 13:28:13 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 6D5B811E80CB for ; Tue, 10 Jul 2012 13:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPVRfxYhlADt for ; Tue, 10 Jul 2012 13:28:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E2E5D21F84B6 for ; Tue, 10 Jul 2012 13:28:08 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.3] (89.141.94.44.dyn.user.ono.com [89.141.94.44]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id D0FDB9D7710; Tue, 10 Jul 2012 22:28:36 +0200 (CEST) Message-ID: <1341952116.4617.7.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Zuniga, Juan Carlos" Date: Tue, 10 Jul 2012 22:28:36 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-c8Yq70bkbOCGzeVNdio5" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19032.001 X-TM-AS-Result: No--30.294-7.0-31-1 X-imss-scan-details: No--30.294-7.0-31-1 Cc: netext@ietf.org Subject: Re: [netext] review - draft-ietf-netext-pmipv6-flowmob-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:28:13 -0000 --=-c8Yq70bkbOCGzeVNdio5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan Carlos, Thanks a lot for your review. I'll take a look at it and post an updated version of the draft (taking also into account Marco's comments) by this week. Thanks, Carlos On Tue, 2012-07-10 at 15:17 -0400, Zuniga, Juan Carlos wrote: > Hi all, >=20 > =20 >=20 > These are the comments I have for draft-ietf-netext-pmipv6-flowmob-03: >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 1. Introduction: >=20 > =20 >=20 > - I would suggest rewriting the second and third paragraph as > follows: >=20 > =20 >=20 > =E2=80=9CPMIPv6 allows an MN to connect to the same PMIPv6 domain through > different interfaces. This document specifies protocol extensions to > Proxy Mobile IPv6 between the LMA and MAGs to enable =E2=80=9Cflow mobili= ty=E2=80=9D > and hence distribute specific traffic flows on different physical > interfaces. It is assumed that an MN IP layer interface can > simultaneously and/or sequentially attach to multiple MAGs, possibly > over multiple media. One form to achieve this multiple attachment is > described in [I-D.ietf-netext-logical-interface-support], which allows > the mobile node supporting traffic flows on different physical > interfaces regardless of the assigned prefixes on those physical > interfaces.=E2=80=9D >=20 > =20 >=20 > =20 >=20 > 2. Terminology >=20 > =20 >=20 > - It should be =E2=80=9CFMA =E2=80=93 Flow Mobility Acknowledgem= ent=E2=80=9D (several > instances throughout the document) >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 3.1 Use case scenarios >=20 > =20 >=20 > - I would suggest changing the first paragraph as follows: >=20 > =20 >=20 > =E2=80=9CIn contrast to a typical handover where connectivity to a physic= al medium is relinquished and then re-established, flow mobility assumes a = mobile node can have simultaneous access to more than one network. In this = specification, it is assumed that the LMA is aware of the mobile node=E2=80= =99s capabilities to have simultaneous access to both access networks and i= t can handle the same or a different set of prefixes on each access. How t= his is done is outside the scope of this specification.=E2=80=9D >=20 > =20 >=20 > - The three numbered scenarios are first described at the > initialization point (i.e. attachment), and then the flow mobility use > case is described for each one of them below in the text. This is > confusing, as at first sight it looks like the numbered paragraphs > contain the whole use case description text. I would suggest > describing each scenario in full in each one of the numbered sections > (e.g. scenario 2 should describe the initial attachment and also the > flow mobility use case to make it clear why it needs signaling > extensions). It would also help adding a reference stating that the > operational description will be provided in sections 3.2.1, 3.2.2, > etc. >=20 > =20 >=20 > - Rewrite the last paragraph in section 3.1 as follows: >=20 > =20 >=20 > =E2=80=9CThe extensions described in this document support all the > aforementioned scenarios.=E2=80=9D >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 3 =20 >=20 > 3.1 =20 >=20 > 3.2.1 MN sharing a common set of prefixes on all MAGs=20 >=20 > =20 >=20 > - Remove the following sentence from the paragraph: >=20 > =20 >=20 > =E2=80=9CWhen a multi-interfaced mobile node connects to a PMIPv6-domain,= it > performs regular attachment and as a result is able to configure an IP > address (or a set of IP addresses) on the logical interface hiding the > different physical interfaces.=E2=80=9D >=20 > =20 >=20 > - I believe the following should be a MUST: >=20 > =20 >=20 > =E2=80=9CIn this document a new Handoff Indicator (HI) value ("Attachment= over > a new interface sharing prefixes") is defined, to allow the mobile > access gateway indicate to the local mobility anchor that the same set > of prefixes MUST be assigned to the mobile node. The considerations in > Section 5.4.1 of [RFC5213] are updated by this specification as > follows:=E2=80=9D >=20 > =20 >=20 > - Suggest promoting the paragraph starting with =E2=80=9CAs desc= ribed > in [I-D.ietf-netext-logical-interface-support]...=E2=80=9D to the end of > section 3.2 (before 3.2.1) and reword as follows: >=20 > =20 >=20 > =E2=80=9CBoth MN and LMA SHOULD have local policies in place that ensure > packets are forwarded coherently for unidirectional and bidirectional > communications. The details about how this consistency is ensured are > out of the scope of this document.=E2=80=9D >=20 > =20 >=20 > - I believe the following should be a MUST (+ typo): >=20 > =20 >=20 > =E2=80=9CIn case the MAGs need to be configured to support flow mobility > because of packet policing, packet enforcement, charging or similar > reasons, the LMA MUST re-use the signaling defined later in this > document to convey this information.=E2=80=9D >=20 > =20 >=20 > - In the paragraph starting with =E2=80=9CFigure 3 shows the sta= te=E2=80=A6=E2=80=9D, > remove the parenthesis and the text inside. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 3.2.2 MN with different sets of prefixes on each MAG=20 >=20 > =20 >=20 > - I believe the following should be a MUST >=20 > =20 >=20 > =E2=80=9CIf the flow is being moved from its default path (which is deter= mined > by the destination prefix) to a different one, the LMA constructs a > Flow Mobility Initiate (FMI) message. This message MUST be sent to > the new target MAG, i.e. the one selected to be the used in the > forwarding of the flow...=E2=80=9D >=20 > =20 >=20 > - It would probably be clearer to have one section 3.2.1, > 3.2.2 and 3.2.3 for each described scenario (1, 2 and 3), even if the > text in the section simply states that the use case is the same as the > next/previous section. It would make it easier to read back and forth > in the document when searching for specific information about a use > case. >=20 > =20 >=20 > - Figure4: I would suggest exchanging the order of the > optional FMI/FMA messages after the new flow Y through MAG1, as these > messages are not time-critical. >=20 > =20 >=20 > - Figure 6: I would suggest exchanging the order of the > optional BRI/BRA messages after the new flow Y through MAG2, as these > messages are not time-critical.=20 >=20 > =20 >=20 > - I believe the following requirements language is needed > (original paragraphs starting with =E2=80=9COptionally, a message can be > sent=E2=80=A6=E2=80=9D): >=20 > =20 >=20 > =E2=80=9COptionally, a Binding Revocation Indication message [RFC5846] wi= th > the P bit set MAY be sent to MAG1 to indicate that this is a > revocation of PMIP prefix(es). After processing BRI, the source MAG > MUST send a Binding Revocation Acknowledgement (BRA) message back to > the LMA. >=20 > =20 >=20 > - Move the paragraph starting with =E2=80=9CIn case flow mobilit= y is > needed with a finer granularity=E2=80=A6=E2=80=9D) to after Figure 6, and= reword with > requirements language as follows: >=20 > =20 >=20 > =E2=80=9CIn case flow mobility is needed with a finer granularity (e.g., = flow > level instead of full prefix), a Flow Identification Mobility option > (specified in [RFC6089]) that can convey full flow information MUST be > included in the PBA. The MAG MAY also include the Flow Identification > Mobility option in the PBU message that it sends to the LMA. This > serves as a request from MAG to LMA to consider the flow policy rules > specified in the option. In this case, no prefix is removed from any > MAG because the movement is performed at a flow level.=E2=80=9D >=20 > =20 >=20 > =20 >=20 > 4. Messages >=20 > =20 >=20 > - Add the following sentence to the beginning of the section: >=20 > =20 >=20 > =E2=80=9CThis section defines extensions to the Proxy Mobile IPv6 [RFC521= 3] > protocol messages=E2=80=9D >=20 > =20 >=20 > 4.1 Flow Mobility Initiate (FMI) >=20 > =20 >=20 > - Replace =E2=80=9Cacknowledge=E2=80=9D by =E2=80=9Cacknowledgem= ent=E2=80=9D in the =E2=80=9CSequence > Number:=E2=80=9D description >=20 > =20 >=20 > =20 >=20 > =20 >=20 > I hope you find these comments useful. >=20 > =20 >=20 > Best regards, >=20 > =20 >=20 > Juan Carlos >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Video over Mobile Networks http://www.comsoc.org/netmag/call-papers (EXTENDED: July, 31) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-c8Yq70bkbOCGzeVNdio5 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.12 (GNU/Linux) iEYEABECAAYFAk/8kHQACgkQNdy6TdFwT2dqlwCfYe1y77y5t7QNxqShbvnjUPy7 MCMAoIg8dC0wrVG8tBJkTOEkN2JV7E7w =QK7P -----END PGP SIGNATURE----- --=-c8Yq70bkbOCGzeVNdio5-- From alexandru.petrescu@gmail.com Wed Jul 11 07:07:05 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 69E8821F86EA for ; Wed, 11 Jul 2012 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.582 X-Spam-Level: X-Spam-Status: No, score=-4.582 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 A+MueAI+1nEK for ; Wed, 11 Jul 2012 07:07:04 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70621F86DC for ; Wed, 11 Jul 2012 07:07:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6BE7XB1007286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Jul 2012 16:07:33 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6BE7XED021746 for ; Wed, 11 Jul 2012 16:07:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6BE7NDI008422 for ; Wed, 11 Jul 2012 16:07:33 +0200 Message-ID: <4FFD889B.6070002@gmail.com> Date: Wed, 11 Jul 2012 16:07:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: netext@ietf.org References: <20120711140252.32123.58310.idtracker@ietfa.amsl.com> In-Reply-To: <20120711140252.32123.58310.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120711140252.32123.58310.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [netext] Fwd: New Version Notification for draft-petrescu-netext-pmip-nemo-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, 11 Jul 2012 14:07:05 -0000 Dear participants to NETEXT WG, We have submitted a new version of our individual proposal about Network Mobility support with PMIPv6. The url of the -01 draft is: http://www.ietf.org/internet-drafts/draft-petrescu-netext-pmip-nemo-01.txt There is not much change in the text, other than the slight update of the author address. I would like to announce that implementation has been written for aspects in this draft. For example, we have an implementation that uses DHCPv6-PD combined with PMIPv6 messaging to perform network mobility. More implementation is still ongoing about the other aspects in the draft (HNP Division, etc.). I would like to request feedback from the WG participants. Thank you in advance, Alex Messages cités pour référence (si rien alors fin de message) : -------- Message original -------- Sujet: New Version Notification for draft-petrescu-netext-pmip-nemo-01.txt Date : Wed, 11 Jul 2012 07:02:52 -0700 De : Pour : Copie à : , A new version of I-D, draft-petrescu-netext-pmip-nemo-01.txt has been successfully submitted by Alexandru Petrescu and posted to the IETF repository. Filename: draft-petrescu-netext-pmip-nemo Revision: 01 Title: Network Mobility with Proxy Mobile IPv6 Creation date: 2012-07-11 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-petrescu-netext-pmip-nemo-01.txt Status: http://datatracker.ietf.org/doc/draft-petrescu-netext-pmip-nemo Htmlized: http://tools.ietf.org/html/draft-petrescu-netext-pmip-nemo-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-petrescu-netext-pmip-nemo-01 Abstract: The Proxy Mobile IPv6 protocol supports Mobile Hosts moving independently, but not Mobile Routers in charge of moving networks. This draft addresses this problem. The goal is to allow bidirectional communication between a Local Fixed Node (in the moving network) and a Correspondent Node (situated arbitrarily somewhere in the Internet). First, a mechanism of "prefix division" is presented, whereby the Home Network Prefix typically assigned by PMIPv6 to a MH is used by MR to form Mobile Network sub-Prefix(es); they are used by LFNs within the moving network to form addresses; this avoids changes in the PMIPv6 protocol specification. A second mechanism proposes enhancements to the use of the DHCPv6 Prefix Delegation protocol entities informing the PMIPv6 entities about the allocated MNP; this is achieved by equaling MNID and DUID. The IETF Secretariat From alexandru.petrescu@gmail.com Wed Jul 11 07:15:27 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 D1B3121F864B for ; Wed, 11 Jul 2012 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9yn0tEFPsL-8 for ; Wed, 11 Jul 2012 07:15:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA321F84F8 for ; Wed, 11 Jul 2012 07:15:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6BEFoeR006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Jul 2012 16:15:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6BEFoak024948 for ; Wed, 11 Jul 2012 16:15:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6BEFk74012704 for ; Wed, 11 Jul 2012 16:15:50 +0200 Message-ID: <4FFD8A92.9070101@gmail.com> Date: Wed, 11 Jul 2012 16:15:46 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netext] Milestone update for NetExt WG 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, 11 Jul 2012 14:15:27 -0000 Raj, I have a comment about the proposed milestones: Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a écrit : [...] > Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for > publication as a proposed standard I wonder whether it is not too early for this submission to IESG. I am saying so because we have an individual proposal which is implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, which realizes network mobility: http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt The -00 of this was submitted early March 2012, and some comments were issued on the email list at that time. We now have an implementation of it. However, the draft that is proposed to be submitted to the IESG (I suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal which is to support network mobility in a PMIPv6 domain. There are important differences between the two drafts. Not the least important is that this WG item does not use DHCPv6-PD whereas our individual proposal does, or that maybe we do not know the implementation status of it, or the IPR status, etc. For these reasons, I believe it may be too early to submit to IESG. I think further discussion should be performed before submitting to IESG. What do you think? Yours, Alex > Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile > IPv6 to IESG for publication as a proposed standard Feb 2013 Submit > Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for > publication as a proposed standard Mar 2013 Submit Service Selection > for MIP6 and PMIP6 to the IESG for publication as a proposed > standard Apr 2013 Submit Logical Interface Support for multi-mode IP > Hosts for publication as an Informational document May 2013 Submit > EAP Attributes for WiFi - EPC Integration to IESG for publication as > a proposed standard > > > > _______________________________________________ netext mailing list > netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Wed Jul 11 07:48: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 BCDFB21F84D5 for ; Wed, 11 Jul 2012 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0rbmG98s9GQN for ; Wed, 11 Jul 2012 07:48:14 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA721F84D3 for ; Wed, 11 Jul 2012 07:48:08 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6BEmYmO020066; Wed, 11 Jul 2012 17:48:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 17:48:59 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.156]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Wed, 11 Jul 2012 16:48:33 +0200 From: To: , Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNIyMgDFG/gVNRlk2qm5eFUf23fpckd4YA//+14wA= Date: Wed, 11 Jul 2012 14:48:33 +0000 Message-ID: In-Reply-To: <4FFD8A92.9070101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.91] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jul 2012 14:48:59.0381 (UTC) FILETIME=[4E0B2250:01CD5F74] X-Nokia-AV: Clean Subject: Re: [netext] Milestone update for NetExt WG 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, 11 Jul 2012 14:48:15 -0000 Hi Alex, On 7/11/12 9:15 AM, "ext Alexandru Petrescu" wrote: >Raj, > >I have a comment about the proposed milestones: > >Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : >[...] >> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for >> publication as a proposed standard > >I wonder whether it is not too early for this submission to IESG. The PD I-D that has been discussed is complete and ready to be sent to the IESG. I see no reason to delay it further. > >I am saying so because we have an individual proposal which is >implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, >which realizes network mobility: >http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt > >The -00 of this was submitted early March 2012, and some comments were >issued on the email list at that time. > >We now have an implementation of it. > >However, the draft that is proposed to be submitted to the IESG (I >suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal >which is to support network mobility in a PMIPv6 domain. The PD I-D is a simple solution for delegating prefixes downstream and is not a solution for NEMO in a PMIP6 domain. > >There are important differences between the two drafts. Not the least >important is that this WG item does not use DHCPv6-PD whereas our >individual proposal does, or that maybe we do not know the >implementation status of it, or the IPR status, etc. I hope the authors can clarify. > >For these reasons, I believe it may be too early to submit to IESG. I >think further discussion should be performed before submitting to IESG. > >What do you think? The WG can discuss it on the ML. With my chair hat on, I do believe that the WG PD I-D is ready to be forwarded to the IESG as it is solving a very specific problem.=20 -Raj > >Yours, > >Alex > > >> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile >> IPv6 to IESG for publication as a proposed standard Feb 2013 Submit >> Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for >> publication as a proposed standard Mar 2013 Submit Service Selection >> for MIP6 and PMIP6 to the IESG for publication as a proposed >> standard Apr 2013 Submit Logical Interface Support for multi-mode IP >> Hosts for publication as an Informational document May 2013 Submit >> EAP Attributes for WiFi - EPC Integration to IESG for publication as >> a proposed standard >> >> >> >> _______________________________________________ netext mailing list >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >> > > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From alexandru.petrescu@gmail.com Wed Jul 11 08:01:56 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 572B621F86D4 for ; Wed, 11 Jul 2012 08:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.693 X-Spam-Level: X-Spam-Status: No, score=-4.693 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 gDfxrXv2eta6 for ; Wed, 11 Jul 2012 08:01:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6154121F86C9 for ; Wed, 11 Jul 2012 08:01:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6BF2P1q027050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 17:02:25 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6BF2Ptq012645; Wed, 11 Jul 2012 17:02:25 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6BF2Ojg007612; Wed, 11 Jul 2012 17:02:24 +0200 Message-ID: <4FFD9580.9070703@gmail.com> Date: Wed, 11 Jul 2012 17:02:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] Milestone update for NetExt WG 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, 11 Jul 2012 15:01:56 -0000 Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a écrit : > > Hi Alex, > > On 7/11/12 9:15 AM, "ext Alexandru Petrescu" > wrote: > >> Raj, >> >> I have a comment about the proposed milestones: >> >> Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a écrit : [...] >>> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG >>> for publication as a proposed standard >> >> I wonder whether it is not too early for this submission to IESG. > > The PD I-D that has been discussed is complete and ready to be sent > to the IESG. I see no reason to delay it further. > >> >> I am saying so because we have an individual proposal which is >> implemented and uses DHCPv6-Prefix Delegation, together with >> PBU/PBAck, which realizes network mobility: >> http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt >> >> The -00 of this was submitted early March 2012, and some comments >> were issued on the email list at that time. >> >> We now have an implementation of it. >> >> However, the draft that is proposed to be submitted to the IESG (I >> suppose draft-ietf-netext-pd-pmip-02) seems to me to have the >> same goal which is to support network mobility in a PMIPv6 domain. > > The PD I-D is a simple solution for delegating prefixes downstream > and is not a solution for NEMO in a PMIP6 domain. Raj - I agree with the first part, the WG item draft delegates prefixes by using PMIP extension - yes. But I disagree with the second part. You say it is not a solution for NEMO in a PMIP6 domain. But it says 'Mobile Router' several times. If it is not a solution for NEMO in a PMIP6 domain, then it is a solution to what? >> There are important differences between the two drafts. Not the >> least important is that this WG item does not use DHCPv6-PD >> whereas our individual proposal does, or that maybe we do not know >> the implementation status of it, or the IPR status, etc. > > I hope the authors can clarify. > >> >> For these reasons, I believe it may be too early to submit to >> IESG. I think further discussion should be performed before >> submitting to IESG. >> >> What do you think? > > The WG can discuss it on the ML. With my chair hat on, I do believe > that the WG PD I-D is ready to be forwarded to the IESG as it is > solving a very specific problem. I am trying to understand what problem? WG item draft's first phrase is: > This specification extends PMIPv6 to assign a mobile network prefix > to a mobile router for supporting network mobility. Isn't this NEMO? Yours, Alex > > -Raj > >> >> Yours, >> >> Alex >> >> >>> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy >>> Mobile IPv6 to IESG for publication as a proposed standard Feb >>> 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow >>> Mobility to IESG for publication as a proposed standard Mar 2013 >>> Submit Service Selection for MIP6 and PMIP6 to the IESG for >>> publication as a proposed standard Apr 2013 Submit Logical >>> Interface Support for multi-mode IP Hosts for publication as an >>> Informational document May 2013 Submit EAP Attributes for WiFi - >>> EPC Integration to IESG for publication as a proposed standard >>> >>> >>> >>> _______________________________________________ netext mailing >>> list netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> >> >> _______________________________________________ netext mailing list >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > > > From michael.boc@cea.fr Wed Jul 11 13:54:17 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 9FC0511E813A for ; Wed, 11 Jul 2012 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 40R9sAVXJpbf for ; Wed, 11 Jul 2012 13:54:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6E11E8135 for ; Wed, 11 Jul 2012 13:54:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6BKsjbR030960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 22:54:45 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6BKsjRi008615; Wed, 11 Jul 2012 22:54:45 +0200 (envelope-from michael.boc@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6BKsjMv002071; Wed, 11 Jul 2012 22:54:45 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 22:54:44 +0200 From: BOC Michael To: Alexandru Petrescu , "Basavaraj.Patil@nokia.com" Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNIyMgDFG/gVNRlk2qm5eFUf23fpckd4YA//+14wCAAFckAIAAc8TC Date: Wed, 11 Jul 2012 20:54:44 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> References: , <4FFD9580.9070703@gmail.com> In-Reply-To: <4FFD9580.9070703@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.167.194.4] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19032.007 x-tm-as-result: No--58.808300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: [netext] RE : Milestone update for NetExt WG 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, 11 Jul 2012 20:54:17 -0000 Hello,=0A= =0A= I am co-author of this draft PMIP-NEMO-01 with Alex.=0A= We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors. =0A= =0A= During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft. =0A= =0A= Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward. =0A= =0A= The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite: =0A= - Delegating router location=0A= - Multiple IA_PD request management=0A= - MNP lifetime management in MAG/LMA=0A= - Interferences with (non) Temporary Addresses=0A= - Matching between DHCPv6's DUID and PMIPv6's MNID=0A= - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA=0A= - ...=0A= =0A= We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants.=0A= =0A= =0A= PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network. =0A= =0A= =0A= Best Regards,=0A= =0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= De : netext-bounces@ietf.org [netext-bounces@ietf.org] de la part de Alexan= dru Petrescu [alexandru.petrescu@gmail.com]=0A= Date d'envoi : mercredi 11 juillet 2012 17:02=0A= =C0 : Basavaraj.Patil@nokia.com=0A= Cc : netext@ietf.org=0A= Objet : Re: [netext] Milestone update for NetExt WG=0A= =0A= Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a =E9crit :=0A= >=0A= > Hi Alex,=0A= >=0A= > On 7/11/12 9:15 AM, "ext Alexandru Petrescu"=0A= > wrote:=0A= >=0A= >> Raj,=0A= >>=0A= >> I have a comment about the proposed milestones:=0A= >>=0A= >> Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...]=0A= >>> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG=0A= >>> for publication as a proposed standard=0A= >>=0A= >> I wonder whether it is not too early for this submission to IESG.=0A= >=0A= > The PD I-D that has been discussed is complete and ready to be sent=0A= > to the IESG. I see no reason to delay it further.=0A= >=0A= >>=0A= >> I am saying so because we have an individual proposal which is=0A= >> implemented and uses DHCPv6-Prefix Delegation, together with=0A= >> PBU/PBAck, which realizes network mobility:=0A= >> http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt=0A= >>=0A= >> The -00 of this was submitted early March 2012, and some comments=0A= >> were issued on the email list at that time.=0A= >>=0A= >> We now have an implementation of it.=0A= >>=0A= >> However, the draft that is proposed to be submitted to the IESG (I=0A= >> suppose draft-ietf-netext-pd-pmip-02) seems to me to have the=0A= >> same goal which is to support network mobility in a PMIPv6 domain.=0A= >=0A= > The PD I-D is a simple solution for delegating prefixes downstream=0A= > and is not a solution for NEMO in a PMIP6 domain.=0A= =0A= Raj - I agree with the first part, the WG item draft delegates prefixes=0A= by using PMIP extension - yes.=0A= =0A= But I disagree with the second part. You say it is not a solution for=0A= NEMO in a PMIP6 domain. But it says 'Mobile Router' several times.=0A= =0A= If it is not a solution for NEMO in a PMIP6 domain, then it is a=0A= solution to what?=0A= =0A= >> There are important differences between the two drafts. Not the=0A= >> least important is that this WG item does not use DHCPv6-PD=0A= >> whereas our individual proposal does, or that maybe we do not know=0A= >> the implementation status of it, or the IPR status, etc.=0A= >=0A= > I hope the authors can clarify.=0A= >=0A= >>=0A= >> For these reasons, I believe it may be too early to submit to=0A= >> IESG. I think further discussion should be performed before=0A= >> submitting to IESG.=0A= >>=0A= >> What do you think?=0A= >=0A= > The WG can discuss it on the ML. With my chair hat on, I do believe=0A= > that the WG PD I-D is ready to be forwarded to the IESG as it is=0A= > solving a very specific problem.=0A= =0A= I am trying to understand what problem?=0A= =0A= WG item draft's first phrase is:=0A= > This specification extends PMIPv6 to assign a mobile network prefix=0A= > to a mobile router for supporting network mobility.=0A= =0A= Isn't this NEMO?=0A= =0A= Yours,=0A= =0A= Alex=0A= =0A= >=0A= > -Raj=0A= >=0A= >>=0A= >> Yours,=0A= >>=0A= >> Alex=0A= >>=0A= >>=0A= >>> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy=0A= >>> Mobile IPv6 to IESG for publication as a proposed standard Feb=0A= >>> 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow=0A= >>> Mobility to IESG for publication as a proposed standard Mar 2013=0A= >>> Submit Service Selection for MIP6 and PMIP6 to the IESG for=0A= >>> publication as a proposed standard Apr 2013 Submit Logical=0A= >>> Interface Support for multi-mode IP Hosts for publication as an=0A= >>> Informational document May 2013 Submit EAP Attributes for WiFi -=0A= >>> EPC Integration to IESG for publication as a proposed standard=0A= >>>=0A= >>>=0A= >>>=0A= >>> _______________________________________________ netext mailing=0A= >>> list netext@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/netext=0A= >>>=0A= >>=0A= >>=0A= >>=0A= >> _______________________________________________ netext mailing list=0A= >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext=0A= >=0A= >=0A= >=0A= =0A= =0A= =0A= _______________________________________________=0A= netext mailing list=0A= netext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netext=0A= From sgundave@cisco.com Wed Jul 11 17:18: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 43A9211E80F7 for ; Wed, 11 Jul 2012 17:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 x02ehPGkGIDi for ; Wed, 11 Jul 2012 17:18:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6911E80C6 for ; Wed, 11 Jul 2012 17:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6454; q=dns/txt; s=iport; t=1342052341; x=1343261941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1LZI38YCSzp75UNjH6OIks2lK9KCfUKlKWTiRMuM6vQ=; b=iRKXJqExyYnNeCl4flkMPNSMSyVAzSODcq3zuIkaO4sxUvzjFHCttt5p X9IaWpxFR0+9LxogE2NJbspvVNloJlb6zUSd24/j0mJEUL4nuMGZnSLfx 0OAEuEdXADqboIovGg+3Z9hHXTxE10Oy2djniyR8bhO/LxGNUmCpZRMUm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANoW/k+tJXG//2dsb2JhbABFt3mBB4IgAQEBAwEBAQEPAVsLBQsCAQhGJwslAgQOBQkZh2UGC51coCqLQIUOYAOIFo0kjiCBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,571,1336348800"; d="scan'208";a="101008832" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jul 2012 00:19:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6C0J02q029202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 00:19:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 19:19:00 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandru Petrescu Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX2+0wSxlOSALck62E4eXxUCinJclHM+A Date: Thu, 12 Jul 2012 00:18:59 +0000 Message-ID: <7EF41CB9-D85A-403C-A56B-CCDBA7A37257@cisco.com> References: <4FFD8A92.9070101@gmail.com> In-Reply-To: <4FFD8A92.9070101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001 x-tm-as-result: No--56.222500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 00:18:30 -0000 Alex: As discussed in the past, some of the assumptions you are making are incorr= ect., IMHO I tried hard to understand the approach that you have in mind. S= ome comments below. - In PMIPv6, the home network prefix (HNP) that the LMA assigns is a hosted= on-link prefix on the MN-AR link. This is not a delegated prefix as in cas= e of MR. - The MAG is hosting the prefix on the link, MR can only "generate" address= es from that prefix. Its 64-bit length prefix allowing SLAAC support on the= link - MR performs all ND operations on the link for avoiding address conflict, = generating address configuration and for defending the generated addresses Given the above properties of the Home Network Prefix, I'm struggling to un= derstand why you believe the MR can take the prefix that it receives in a R= A message, splits up the address space and assigns it to the network behind= it. What is your assumption here ? MR can generate an address, two addresses or a dozen addresses and use them= on the link after performing the ND operations. Now, splitting the 64-bits= of MAG hosted prefix, does it mean the MR generates 2 pow 64 addresses and= assigns them to LFNS on the ingress sides ?=20 For a HNP with prefix length 64, two or more MNPs are generated, each having a prefix length longer than 64. For brevity and without losing generality, we present a detailed division example for a fictitious addressing system whose "IP" addresses are of a maximum length of 5 bits (instead of 128 bits of IPv6). Alex: What is this fuzzy logic ? For hosted prefix on a link, we need 64-bi= ts. Can the MR send an RA on its ingress link with /96 prefix length ? How = will the LFN generate an EUI-64 identifier and generate a 128-bit address f= rom a 96-bit prefix ? Can you explain how SLAAC works on the ingress link ? This may be achieved either with DHCPv6 (MR or a DHCPv6 Server send these addresses) or with stateless address auto-configuration (MR or a Router send Router Advertisements containing MNP1 and/or MNP2). >From a 64-bit prefix received in the RA on the egress link, a MR can genera= te a list of prefixes and send RA's for those prefixes on the ingress link = ? Why do we need PD then ? > On the contrary, in the case of shared links, it is necessary to perfor= m an operation of Neighbor Discovery proxying on the Mobile Router. When M= AG receives a packet from CN addressed to LFN, it would solicit the MAC add= ress of LFN on the MAG-MR link (even though LFN is not present on that link= ). For this reason, the MR must pretend it owns the IP address of LFN and = respond to that solicitation with its own MAC address. Lets assume we have enabled SEND on the link ? What happens to that scenar= io ? Can the MR be able to defend the IPv6 address owned by an LFN ? Can th= e MR assert the ownership and use its Link-layer id for that address ? Can you explain how SEND works in your proposal ? =20 > For this reason, the MR must pretend it owns the IP address of LFN and = respond to that solicitation with its own MAC address. Sure. To summarize your draft (from what I understood), a node on an IPv6 = link can take a set of addresses from the prefix that it receives on the eg= ress link and use them on its ingress link. It can cleverly proxy for those= addresses and make the uplink router believe that it owns those addresses.= So, remove mobility from this equation. Can a fixed node do this ? Can the MR take just one address and perform NAT66 operation and still supp= ort a network behind it ?=20 The PD draft that the WG is working on about properly delegating prefixes t= o the MR, so the MR can use them on its ingress link. These are assigned in= a legal manner, with out requiring any hacking requirements on the MR. The= work is am extension to what MEXT WG did for PD support; its an approach f= or network-based mobility. Regards Sri On Jul 11, 2012, at 7:15 AM, Alexandru Petrescu wrote: > Raj, >=20 > I have a comment about the proposed milestones: >=20 > Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : > [...] >> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for >> publication as a proposed standard >=20 > I wonder whether it is not too early for this submission to IESG. >=20 > I am saying so because we have an individual proposal which is > implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, > which realizes network mobility: > http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt >=20 > The -00 of this was submitted early March 2012, and some comments were > issued on the email list at that time. >=20 > We now have an implementation of it. >=20 > However, the draft that is proposed to be submitted to the IESG (I > suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal > which is to support network mobility in a PMIPv6 domain. >=20 > There are important differences between the two drafts. Not the least > important is that this WG item does not use DHCPv6-PD whereas our > individual proposal does, or that maybe we do not know the > implementation status of it, or the IPR status, etc. >=20 > For these reasons, I believe it may be too early to submit to IESG. I > think further discussion should be performed before submitting to IESG. >=20 > What do you think? >=20 > Yours, >=20 > Alex >=20 >=20 >> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile >> IPv6 to IESG for publication as a proposed standard Feb 2013 Submit >> Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for >> publication as a proposed standard Mar 2013 Submit Service Selection >> for MIP6 and PMIP6 to the IESG for publication as a proposed >> standard Apr 2013 Submit Logical Interface Support for multi-mode IP >> Hosts for publication as an Informational document May 2013 Submit >> EAP Attributes for WiFi - EPC Integration to IESG for publication as >> a proposed standard >>=20 >>=20 >>=20 >> _______________________________________________ netext mailing list >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >>=20 >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Jul 11 17:40:40 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 A2B1B11E814F for ; Wed, 11 Jul 2012 17:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baJGWCCyOD89 for ; Wed, 11 Jul 2012 17:40:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BADF511E80A4 for ; Wed, 11 Jul 2012 17:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=28644; q=dns/txt; s=iport; t=1342053671; x=1343263271; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UvhNeiv/e5Z396qvrdDr8rrRvgExCTRZsoSi0JD0YrY=; b=kGPoHs1xK1mvf+zoJJDMc6FJO/3k5SVAF6SITd8fuN/HTS+2lGZeNUTB PMRQzNalvErtsKHThNI3LTlPvdRKt61mawU6xC+it4ZpasvsvAJv+91mb JzhTiqsNPHl2lL8ii7pB0RKAm0hvln5qT1sQhbjaa5vNqdnCNVmUSZ+hH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOgb/k+tJV2Z/2dsb2JhbABFt3qBB4IhAQEEAQEBDwEURwsQAgEIOAcHIQYLFBECBA4FCRIHh1wDDAudWZZPDYlOilpmhQ5gA5U6iwSDHIFmgl+BVgka X-IronPort-AV: E=Sophos;i="4.77,571,1336348800"; d="scan'208,217";a="101017153" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jul 2012 00:41:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6C0fAfE011488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 00:41:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 19:41:09 -0500 From: "Sri Gundavelli (sgundave)" To: BOC Michael Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cHSJkJyZxPeUOlqQZLnkmKow== Date: Thu, 12 Jul 2012 00:41:08 +0000 Message-ID: <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> In-Reply-To: <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001 x-tm-as-result: No--61.263400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_3B51081E10E441B285DD36DF487D8B71ciscocom_" MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 00:40:40 -0000 --_000_3B51081E10E441B285DD36DF487D8B71ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for sharing the details about your project. Nice to know, you have a= n implementation. - Delegating router location Its the LMA. That is the session anchor and for supporting mobility, that n= eeds to be in path and is the only option - Multiple IA_PD request management This is per RFC 3693, standard RR operation, no change - MNP lifetime management in MAG/LMA Its tied to the PMIP session lifetime. This is identical to session lifetim= e when using DHCPv4 per 5844 - Interferences with (non) Temporary Addresses Please clarify what is the issue - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two different identifiers uses in different protocol planes. MN Id is the mobile node's identifier. This is tied to the access authentic= ation. DHCP DUID is the identifier used by the RR. - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA - =85 MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the LMA,= so it will have proper correlation and route when subsequent allocation ov= er DHCP PD is complete Please explain which part of the call flow, you have implementation challen= ge +-------------+ +--------------+ +-------------------+ |Mobile Router| | MAG | | LMA | |(Req. Router)| |(DHCPv6 Relay)| |(Delegating Router)| +-------------+ +--------------+ +-------------------+ | | | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 1) | | PMIPv6 tunnel | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 2) |-- Solicit ------>| | | | | 3) | |----------PBU------------>| | | | 4) | |<---------PBA-------------| | | | 5) | |--- Solicit ------------->| - - - - <-+ 6) | |<-- Advertise ------------| | | | | | 7) |<- Advertise -----| | Opt | | | ion 8) |-- Request ------>| | al. | | | | 9) | |--- Request ------------->| | - - - - <-+ 10) | |<-- Reply-----------------| | | | 11) |<-- Reply --------| | | | | Figure 1: Prefix Delegation in PMIPv6 during the initial attachment to the PMIPv6 Domain Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote: Hello, I am co-author of this draft PMIP-NEMO-01 with Alex. We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors. During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft. Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward. The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite: - Delegating router location - Multiple IA_PD request management - MNP lifetime management in MAG/LMA - Interferences with (non) Temporary Addresses - Matching between DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA - ... We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants. PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network. Best Regards, Michael ________________________________________ De : netext-bounces@ietf.org [netext-bounce= s@ietf.org] de la part de Alexandru Petresc= u [alexandru.petrescu@gmail.com] Date d'envoi : mercredi 11 juillet 2012 17:02 =C0 : Basavaraj.Patil@nokia.com Cc : netext@ietf.org Objet : Re: [netext] Milestone update for NetExt WG Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a =E9crit : Hi Alex, On 7/11/12 9:15 AM, "ext Alexandru Petrescu" > wrote: Raj, I have a comment about the proposed milestones: Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...] Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard I wonder whether it is not too early for this submission to IESG. The PD I-D that has been discussed is complete and ready to be sent to the IESG. I see no reason to delay it further. I am saying so because we have an individual proposal which is implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, which realizes network mobility: http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt The -00 of this was submitted early March 2012, and some comments were issued on the email list at that time. We now have an implementation of it. However, the draft that is proposed to be submitted to the IESG (I suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal which is to support network mobility in a PMIPv6 domain. The PD I-D is a simple solution for delegating prefixes downstream and is not a solution for NEMO in a PMIP6 domain. Raj - I agree with the first part, the WG item draft delegates prefixes by using PMIP extension - yes. But I disagree with the second part. You say it is not a solution for NEMO in a PMIP6 domain. But it says 'Mobile Router' several times. If it is not a solution for NEMO in a PMIP6 domain, then it is a solution to what? There are important differences between the two drafts. Not the least important is that this WG item does not use DHCPv6-PD whereas our individual proposal does, or that maybe we do not know the implementation status of it, or the IPR status, etc. I hope the authors can clarify. For these reasons, I believe it may be too early to submit to IESG. I think further discussion should be performed before submitting to IESG. What do you think? The WG can discuss it on the ML. With my chair hat on, I do believe that the WG PD I-D is ready to be forwarded to the IESG as it is solving a very specific problem. I am trying to understand what problem? WG item draft's first phrase is: This specification extends PMIPv6 to assign a mobile network prefix to a mobile router for supporting network mobility. Isn't this NEMO? Yours, Alex -Raj Yours, Alex Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listin= fo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_3B51081E10E441B285DD36DF487D8B71ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91227ED030137B459B75D909FE87769B@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Michael,


Thanks for sharing the details about your project. Nice to know, you h= ave an implementation.




- Delegating router location

Its the LMA. That is the session anchor and for supporting mobility, t= hat needs to be in path and is the only option


- Multiple IA_PD request management

This is per RFC 3693, standard RR operation, no change


- MNP lifetime management in MAG/LMA

Its tied to the PMIP session lifetime. This is identical to session li= fetime when using DHCPv4 per 5844


- Interferences with (non) Temporary Addresses

Please clarify what is the issue


- Matching between DHCPv6's DUID and PMIPv6's MNID

Those are two different identifiers uses in different protocol planes.=
MN Id is the mobile node's identifier. This is tied to the access auth= entication.
DHCP DUID is the identifier used by the RR. 


- Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
- =85

MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the= LMA, so it will have proper correlation and route when subsequent allocati= on over DHCP PD is complete



Please explain which part of the call flow, you have implementation ch= allenge

   +-----=
--------+    +--------------+          +-------------------=
+
   |Mobile Router|    |      MAG     |          |      LMA          |
   |(Req. Router)|    |(DHCPv6 Relay)|          |(Delegating Router)|
   +-------------+    +--------------+          +------=
-------------+
          |                  |                          |
          |                  |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do|
   1)     |                  |      PMIPv6 tunnel       |
          |                  |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do|
   2)     |-- Solicit ------>|                          |
          |                  |                          |
   3)     |                  |----------PBU------------>|
          |                  |                          |
   4)     |                  |<---------PBA-------------|
          |                  |                          |
   5)     |                  |--- Solicit ------------->|
          -                  -                -         - <-+
   6)     |                  |<-- Advertise ------------|   |
          |                  |                          |   |
   7)     |<- Advertise -----|                          |  Opt
          |                  |                          |  ion
   8)     |-- Request ------>|                          |  al.
          |                  |                          |   |
   9)     |                  |--- Request ------------->|   |
          -                  -                -         - <-+
   10)    |                  |<-- Reply-----------------|
          |                  |                          |
   11)    |<-- Reply --------|                          |
          |                  |                          |

    Figure 1: Prefix Delegation in PMIPv6 during the initial attachment
                           to the PMIPv6 Domain





Regards
Sri



On Jul 11, 2012, at 1:54 PM, BOC Michael wrote:

Hello,

I am co-author of this draft PMIP-NEMO-01 with Alex.
We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors.

During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft.  

Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward.

The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite:
- Delegating router location
- Multiple IA_PD request management
- MNP lifetime management in MAG/LMA
- Interferences with (non) Temporary Addresses
- Matching between DHCPv6's DUID and PMIPv6's MNID
- Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
- ...

We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants.


PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network.  


Best Regards,


Michael


________________________________________
De : netext-bounces@ietf.org= [netext-bounces@ietf.org] d= e la part de Alexandru Petrescu [alexandru.petrescu@gmail.com]
Date d'envoi : mercredi 11 juillet 2012 17:02
=C0 : Basavaraj.Patil@nokia.co= m
Cc : netext@ietf.org
Objet : Re: [netext] Milestone update for NetExt WG

Le 11/07/2012 16:48, Basavaraj= .Patil@nokia.com a =E9crit :

Hi Alex,

On 7/11/12 9:15 AM, "ext Alexandru Petrescu&= quot;
<alexandru.petrescu@gmail.com> wrote:

Raj,

I have a comment about the proposed milestones:

Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...]
Jul 2012    Submit Prefix Delegati= on for Proxy Mobile IPv6 to IESG
for publication as a proposed standard

I wonder whether it is not too early for this sub= mission to IESG.

The PD I-D that has been discussed is complete an= d ready to be sent
to the IESG. I see no reason to delay it further.=


I am saying so because we have an individual prop= osal which is
implemented and uses DHCPv6-Prefix Delegation, to= gether with
PBU/PBAck, which realizes network mobility:
http://www.ietf.org/id/draft-petrescu-netext-pmip-= nemo-01.txt

The -00 of this was submitted early March 2012, a= nd some comments
were issued on the email list at that time.

We now have an implementation of it.

However, the draft that is proposed to be submitt= ed to the IESG (I
suppose draft-ietf-netext-pd-pmip-02) seems to me= to have the
same goal which is to support network mobility in= a PMIPv6 domain.

The PD I-D is a simple solution for delegating pr= efixes downstream
and is not a solution for NEMO in a PMIP6 domain.=

Raj - I agree with the first part, the WG item draft delegates prefixes
by using PMIP extension - yes.

But I disagree with the second part.  You say it is not a solution for=
NEMO in a PMIP6 domain.  But it says 'Mobile Router' several times.
If it is not a solution for NEMO in a PMIP6 domain, then it is a
solution to what?

There are important differences between the two d= rafts.  Not the
least important is that this WG item does not use= DHCPv6-PD
whereas our individual proposal does, or that may= be we do not know
the implementation status of it, or the IPR statu= s, etc.

I hope the authors can clarify.


For these reasons, I believe it may be too early = to submit to
IESG. I think further discussion should be perfor= med before
submitting to IESG.

What do you think?

The WG can discuss it on the ML. With my chair ha= t on, I do believe
that the WG PD I-D is ready to be forwarded to th= e IESG as it is
solving a very specific problem.

I am trying to understand what problem?

WG item draft's first phrase is:
This specification extends PMIPv6 to assign a mob= ile network prefix
to a mobile router for supporting network mobilit= y.

Isn't this NEMO?

Yours,

Alex


-Raj


Yours,

Alex


Nov 2012    Submit IPv4 Traffic Of= fload Selector Option for Proxy
Mobile IPv6 to IESG for publication as a proposed= standard Feb
2013        Su= bmit Proxy Mobile IPv6 Extensions to Support Flow
Mobility to IESG for publication as a proposed st= andard Mar 2013
Submit Service Selection for MIP6 and PMIP6 to th= e IESG for
publication as a proposed standard Apr 2013 Submi= t Logical
Interface Support for multi-mode IP Hosts for pub= lication as an
Informational document May 2013    = ; Submit EAP Attributes for WiFi -
EPC Integration to IESG for publication as a prop= osed standard



_______________________________________________ n= etext mailing
list netext@ie= tf.org
https://www.ietf.org/mailman/listinfo/netext




_______________________________________________ n= etext mailing list
netext@ietf.or= g https://www.ietf.org/mailman/listinfo/netext






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

--_000_3B51081E10E441B285DD36DF487D8B71ciscocom_-- From michael.boc@cea.fr Thu Jul 12 02:56:35 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 A95E621F87C8 for ; Thu, 12 Jul 2012 02:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_FR=0.35, 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 rowEnGEIUAtN for ; Thu, 12 Jul 2012 02:56:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20621F879D for ; Thu, 12 Jul 2012 02:56:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6C9uv4E004336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 11:56:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6C9uu6b031723; Thu, 12 Jul 2012 11:56:56 +0200 (envelope-from michael.boc@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6C9uu1C008255; Thu, 12 Jul 2012 11:56:56 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Thu, 12 Jul 2012 11:56:56 +0200 From: BOC Michael To: "Sri Gundavelli (sgundave)" Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNYBSrr2jpI+E+CE6cJV8oC9j4Qw== Date: Thu, 12 Jul 2012 09:56:55 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> In-Reply-To: <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19034.002 x-tm-as-result: No--42.495100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_94D2EEADE1F74740979E8041CBA3393803559E07EXDAG0B3intrace_" MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 09:56:35 -0000 --_000_94D2EEADE1F74740979E8041CBA3393803559E07EXDAG0B3intrace_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sri, The cited points were more =AB topics =BB than just technical misunderstand= ing. Please have a look of my responses in line. I hope they will highlight the = need for a slight delay in the Netext WG milestone plan. Maybe we can change the subject of this mail. Michael De : Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 12 juillet 2012 02:41 =C0 : BOC Michael Cc : Alexandru Petrescu; Basavaraj.Patil@nokia.com; netext@ietf.org Objet : Re: [netext] Milestone update for NetExt WG Hi Michael, Thanks for sharing the details about your project. Nice to know, you have a= n implementation. - Delegating router location Its the LMA. That is the session anchor and for supporting mobility, that n= eeds to be in path and is the only option As in RFC5844, the DHCP server or relay may be located on the MAG then the = location of the Delegating router cannot be simply set on the LMA as "the o= nly option". We have deployment issues where the DHCPv6 server (and the delegating route= r also) will be located on another server than the MAG and LMA (and this is= an option for us). If the LMA is the session anchor, the delegating router can accommodate wit= h specific configuration. A bit off-topic, I can design a solution much more efficient by having dele= gating routers on MAGs. - Multiple IA_PD request management This is per RFC 3693, standard RR operation, no change You mean RFC3633 ? How does the MAG knows that the MR request specific MNPs= (Section 7, about hints). How does those multiples prefixes are included i= n PBU/PBA? - MNP lifetime management in MAG/LMA Its tied to the PMIP session lifetime. This is identical to session lifetim= e when using DHCPv4 per 5844 RFC5844 says in Section 3.4.3 : The DHCP lease length allocated to the mobile node's IPv4 home address may be different from the binding lifetime at the local mobility anchor for that mobile node's session. It is not possible to keep these lifetimes synchronized, and so its not required that the configured lifetimes should be kept same in both DHCP and Proxy Mobile IPv6. So there are no required synchronization between PMIP session lifetime and = DHCPv6 lease length. In our implementation this cause high overhead in term= s of treatments to evaluate if only one MNP is still valid or not. When we consider tens of MNP per UE and thousands of UEs this is not possib= le. - Interferences with (non) Temporary Addresses Please clarify what is the issue You let the MR sends DHCPv6 SOLICIT. So you let any mobile node to send DHC= Pv6 SOLICIT. So you will have to treat IANA, IATA, IAPD, and so on.. How th= is is done is not presented in the PD I-D draft. And I don't even talk about the signaling overhead caused by this. - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two different identifiers uses in different protocol planes. MN Id is the mobile node's identifier. This is tied to the access authentic= ation. DHCP DUID is the identifier used by the RR. PMIPv6 session lifetime is not synchronized with DHCPv6 lease length. Then = if one control plane takes a decision, like PMIPv6's mobile node rejection,= the delegating router database will remain desynchronized. This can be solved through obscure mechanisms but I think it is important t= o clarify this point (and yes we assume that the delegating router may not = be collocated with the LMA). - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA If the lease length is much more lower than the session lifetime you multip= ly the number of PBU/PBA and DHCPv6 SOLICIT/REQUEST/REPLY/... messages - ... MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the LMA,= so it will have proper correlation and route when subsequent allocation ov= er DHCP PD is complete Please explain which part of the call flow, you have implementation challen= ge +-------------+ +--------------+ +-------------------+ |Mobile Router| | MAG | | LMA | |(Req. Router)| |(DHCPv6 Relay)| |(Delegating Router)| +-------------+ +--------------+ +-------------------+ | | | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 1) | | PMIPv6 tunnel | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 2) |-- Solicit ------>| | | | | 3) | |----------PBU------------>| | | | 4) | |<---------PBA-------------| | | | 5) | |--- Solicit ------------->| - - - - <-+ 6) | |<-- Advertise ------------| | | | | | 7) |<- Advertise -----| | Opt | | | ion 8) |-- Request ------>| | al. | | | | 9) | |--- Request ------------->| | - - - - <-+ 10) | |<-- Reply-----------------| | | | 11) |<-- Reply --------| | | | | Figure 1: Prefix Delegation in PMIPv6 during the initial attachment to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose the solutions we found as we addressed = the design, technical, and implementation challenges. They may not solve all cited problems but we are committed to improve the q= uality of the prefix delegation support draft that will be submitted to the= IESG. Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote: Hello, I am co-author of this draft PMIP-NEMO-01 with Alex. We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors. During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft. Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward. The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite: - Delegating router location - Multiple IA_PD request management - MNP lifetime management in MAG/LMA - Interferences with (non) Temporary Addresses - Matching between DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA - ... We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants. PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network. Best Regards, Michael ________________________________________ De : netext-bounces@ietf.org [netext-bounce= s@ietf.org] de la part de Alexandru Petresc= u [alexandru.petrescu@gmail.com] Date d'envoi : mercredi 11 juillet 2012 17:02 =C0 : Basavaraj.Patil@nokia.com Cc : netext@ietf.org Objet : Re: [netext] Milestone update for NetExt WG Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a =E9crit : Hi Alex, On 7/11/12 9:15 AM, "ext Alexandru Petrescu" > wrote: Raj, I have a comment about the proposed milestones: Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...] Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard I wonder whether it is not too early for this submission to IESG. The PD I-D that has been discussed is complete and ready to be sent to the IESG. I see no reason to delay it further. I am saying so because we have an individual proposal which is implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, which realizes network mobility: http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt The -00 of this was submitted early March 2012, and some comments were issued on the email list at that time. We now have an implementation of it. However, the draft that is proposed to be submitted to the IESG (I suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal which is to support network mobility in a PMIPv6 domain. The PD I-D is a simple solution for delegating prefixes downstream and is not a solution for NEMO in a PMIP6 domain. Raj - I agree with the first part, the WG item draft delegates prefixes by using PMIP extension - yes. But I disagree with the second part. You say it is not a solution for NEMO in a PMIP6 domain. But it says 'Mobile Router' several times. If it is not a solution for NEMO in a PMIP6 domain, then it is a solution to what? There are important differences between the two drafts. Not the least important is that this WG item does not use DHCPv6-PD whereas our individual proposal does, or that maybe we do not know the implementation status of it, or the IPR status, etc. I hope the authors can clarify. For these reasons, I believe it may be too early to submit to IESG. I think further discussion should be performed before submitting to IESG. What do you think? The WG can discuss it on the ML. With my chair hat on, I do believe that the WG PD I-D is ready to be forwarded to the IESG as it is solving a very specific problem. I am trying to understand what problem? WG item draft's first phrase is: This specification extends PMIPv6 to assign a mobile network prefix to a mobile router for supporting network mobility. Isn't this NEMO? Yours, Alex -Raj Yours, Alex Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listin= fo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_94D2EEADE1F74740979E8041CBA3393803559E07EXDAG0B3intrace_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sri,=

 <= /p>

The cited = points were more =AB topics =BB than just technical misunderstand= ing.

 

Please hav= e a look of my responses in line. I hope they will highlight the need for a= slight delay in the Netext WG milestone plan.

Maybe we c= an change the subject of this mail.

 = ;

 = ;

Michael

 = ;

De : Sri = Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Envoy=E9 : jeudi 12 juillet 2012 02:41
=C0 : BOC Michael
Cc : Alexandru Petrescu; Basavaraj.Patil@nokia.com; netext@ietf= .org
Objet : Re: [netext] Milestone update for NetExt WG<= /span>

 

Hi Michael,

 

 

Thanks for sharing the details about your project. N= ice to know, you have an implementation.

 

 

 

 

- Delegating router location

 

Its the LMA. That is the session anchor and for supp= orting mobility, that needs to be in path and is the only option=

 

As in R= FC5844, the DHCP server or relay may be located on the MAG then the locatio= n of the Delegating router cannot be simply set on the LMA as “the on= ly option”.

We have= deployment issues where the DHCPv6 server (and the delegating router also)= will be located on another server than the MAG and LMA (and this is an opt= ion for us).

If the = LMA is the session anchor, the delegating router can accommodate with speci= fic configuration.

&n= bsp;

A bit o= ff-topic, I can design a solution much more efficient by having delegating = routers on MAGs.  

 = ;



- Multiple IA_PD request manage= ment

 

This is per RFC 3693, standard = RR operation, no change

 

You mean R= FC3633 ? How does the MAG knows that the MR request specific MNPs (Sec= tion 7, about hints). How does those multiples prefixes are included in PBU/PBA?



- MNP lifetime management in MAG/LMA

 

Its tied to the PMIP session lifetime. This is ident= ical to session lifetime when using DHCPv4 per 5844

 

RFC5844 sa= ys in Section 3.4.3 :

 

The DHCP leas= e length allocated to the mobile node's IPv4 home

  &= nbsp;   address may be different from the binding lifetime at the= local

  &= nbsp;   mobility anchor for that mobile node's session.  It = is not

  &= nbsp;   possible to keep these lifetimes synchronized, and so its= not

  &= nbsp;   required that the configured lifetimes should be kept sam= e in both

  &= nbsp;   DHCP and Proxy Mobile IPv6.

 = ;

So there a= re no required synchronization between PMIP session lifetime and DHCPv6 lea= se length. In our implementation this cause high overhead in terms of treatments to evaluate if only one MNP is still valid or not.<= o:p>

When we co= nsider tens of MNP per UE and thousands of UEs this is not possible.



- Interferences with (non) Temporary Addresses<= /o:p>

 

Please clarify what is the issue

 

 

You let th= e MR sends DHCPv6 SOLICIT. So you let any mobile node to send DHCPv6 SOLICI= T. So you will have to treat IANA, IATA, IAPD, and so on.. How this is done is not presented in the PD I-D draft.

And I don&= #8217;t even talk about the signaling overhead caused by this.

 = ;

 = ;



- Matching between DHCPv6's DUID and PMIPv6's MNID

 

Those are two different identifiers uses in differen= t protocol planes.

MN Id is the mobile node's identifier. This is tied = to the access authentication.

DHCP DUID is the identifier used by the RR. 

 

 

PMIPv6 ses= sion lifetime is not synchronized with DHCPv6 lease length. Then if one con= trol plane takes a decision, like PMIPv6’s mobile node rejection, the delegating router database will remain desynchronized.

This can b= e solved through obscure mechanisms but I think it is important to clarify = this point (and yes we assume that the delegating router may not be collocated with the LMA).

 = ;

 

- Increasing load of DHCPv6 sol= icit/reply and by extension PBU/PBA

If the lea= se length is much more lower than the session lifetime you multiply the num= ber of PBU/PBA and DHCPv6 SOLICIT/REQUEST/REPLY/… messages=

 = ;

 = ;

- …

 

MAG uses the DHCPv6 solicit as a trigger for MNP sta= te creation on the LMA, so it will have proper correlation and route when s= ubsequent allocation over DHCP PD is complete

 

 

 

Please explain which part of the call flow, you have= implementation challenge

 

   +=
;-------------+    +--------------+  &=
nbsp;       +-------------------+
   |Mobile Router|    |   &nbs=
p;  MAG     |      &=
nbsp;   |      LMA   &nbs=
p;      |
   |(Req. Router)|    |(DHCPv6 Relay)| &=
nbsp;        |(Delegating Router)|<=
/o:p>
   +-------------+    +----------=
----+          +------=
-------------+
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
          |  &n=
bsp;            =
;   |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3Do|
   1)     |     =
;             |=
      PMIPv6 tunnel     &=
nbsp; |
          |  &n=
bsp;            =
;   |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3Do|
   2)     |-- Solicit ------>| &=
nbsp;           &nbs=
p;            |=

          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
   3)     |     =
;             |=
----------PBU------------>|
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
   4)     |     =
;             |=
<---------PBA-------------|
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
   5)     |     =
;             |=
--- Solicit ------------->|
          -  &n=
bsp;            =
;   -          =
      -       &=
nbsp; - <-+
   6)     |     =
;             |=
<-- Advertise ------------|   |
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |   |
   7)     |<- Advertise -----| &=
nbsp;           &nbs=
p;            | =
; Opt
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |  ion
   8)     |-- Request ------>| &=
nbsp;           &nbs=
p;            | =
; al.
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |   |
   9)     |     =
;             |=
--- Request ------------->|   |
          -  &n=
bsp;            =
;   -          =
      -       &=
nbsp; - <-+
   10)    |     &nbs=
p;            |<-=
- Reply-----------------|
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
   11)    |<-- Reply --------|  =
            &nb=
sp;           |
          |  &n=
bsp;            =
;   |          =
            &nb=
sp;   |
 
    Figure 1: Prefix Delegation in PMIPv6 during the in=
itial attachment
           &nbs=
p;            &=
nbsp;  to the PMIPv6 Domain

 

 <= /p>

In the draft PMIP-NEMO-02 we expos= e the solutions we found as we addressed the design, technical, and impleme= ntation challenges.

They may not solve all cited probl= ems but we are committed to improve the quality of the prefix delegation su= pport draft that will be submitted to the IESG.  

 

 

 

Regards

Sri

 

 

 

On Jul 11, 2012, at 1:54 PM, BOC Michael wrote:=



Hello,

I am co-author of this draft PMIP-NEMO-01 with Alex.
We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors.

During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft.  

Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward.

The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite:
- Delegating router location
- Multiple IA_PD request management
- MNP lifetime management in MAG/LMA
- Interferences with (non) Temporary Addresses
- Matching between DHCPv6's DUID and PMIPv6's MNID
- Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
- ...

We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants.


PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network.  


Best Regards,


Michael


________________________________________
De : netext-bounces@ietf.org= [netext-bounces@ietf.org] d= e la part de Alexandru Petrescu [alexandru.petrescu@gmail.com]
Date d'envoi : mercredi 11 juillet 2012 17:02
=C0 : Basavaraj.Patil@nokia.co= m
Cc : netext@ietf.org
Objet : Re: [netext] Milestone update for NetExt WG

Le 11/07/2012 16:48, Basavaraj= .Patil@nokia.com a =E9crit :

 

Hi Alex,

 

On 7/11/12 9:15 AM, "ext Alexandru Petrescu&quo= t;

<= alexandru.petrescu@gmail.com> wrote:

 

Raj,

 

I have a comment about the proposed milestones:=

 

Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...]

Jul 2012    Submit Prefix Delegation = for Proxy Mobile IPv6 to IESG

for publication as a proposed standard

 

I wonder whether it is not too early for this submis= sion to IESG.

 

The PD I-D that has been discussed is complete and r= eady to be sent

to the IESG. I see no reason to delay it further.

 

 

I am saying so because we have an individual proposa= l which is

implemented and uses DHCPv6-Prefix Delegation, toget= her with

PBU/PBAck, which realizes network mobility:

http://www.ietf.org/id/draft-petrescu-netext-pmip-nem= o-01.txt

 

The -00 of this was submitted early March 2012, and = some comments

were issued on the email list at that time.

 

We now have an implementation of it.

 

However, the draft that is proposed to be submitted = to the IESG (I

suppose draft-ietf-netext-pd-pmip-02) seems to me to= have the

same goal which is to support network mobility in a = PMIPv6 domain.

 

The PD I-D is a simple solution for delegating prefi= xes downstream

and is not a solution for NEMO in a PMIP6 domain.


Raj - I agree with the first part, the WG item draft delegates prefixes
by using PMIP extension - yes.

But I disagree with the second part.  You say it is not a solution for=
NEMO in a PMIP6 domain.  But it says 'Mobile Router' several times.
If it is not a solution for NEMO in a PMIP6 domain, then it is a
solution to what?


There are important differences between the two draf= ts.  Not the

least important is that this WG item does not use DH= CPv6-PD

whereas our individual proposal does, or that maybe = we do not know

the implementation status of it, or the IPR status, = etc.

 

I hope the authors can clarify.

 

 

For these reasons, I believe it may be too early to = submit to

IESG. I think further discussion should be performed= before

submitting to IESG.

 

What do you think?

 

The WG can discuss it on the ML. With my chair hat o= n, I do believe

that the WG PD I-D is ready to be forwarded to the I= ESG as it is

solving a very specific problem.


I am trying to understand what problem?

WG item draft's first phrase is:

This specification extends PMIPv6 to assign a mobile= network prefix

to a mobile router for supporting network mobility.<= o:p>


Isn't this NEMO?

Yours,

Alex


 

-Raj

 

 

Yours,

 

Alex

 

 

Nov 2012    Submit IPv4 Traffic Offlo= ad Selector Option for Proxy

Mobile IPv6 to IESG for publication as a proposed st= andard Feb

2013        Submi= t Proxy Mobile IPv6 Extensions to Support Flow

Mobility to IESG for publication as a proposed stand= ard Mar 2013

Submit Service Selection for MIP6 and PMIP6 to the I= ESG for

publication as a proposed standard Apr 2013 Submit L= ogical

Interface Support for multi-mode IP Hosts for public= ation as an

Informational document May 2013    &n= bsp;Submit EAP Attributes for WiFi -

EPC Integration to IESG for publication as a propose= d standard

 

 

 

_______________________________________________ nete= xt mailing

list netext@ietf.= org

https://www.ietf.org/mailman/listinfo/netext

 

 

 

 

_______________________________________________ nete= xt mailing list

netext@ietf.org https://www.ietf.org/mailman/listinfo/netext

 

 

 




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

 

--_000_94D2EEADE1F74740979E8041CBA3393803559E07EXDAG0B3intrace_-- From sgundave@cisco.com Thu Jul 12 03:29:09 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 D1DDF21F87BF for ; Thu, 12 Jul 2012 03:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cskOBrmjRtpq for ; Thu, 12 Jul 2012 03:29:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFF521F87DE for ; Thu, 12 Jul 2012 03:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=97526; q=dns/txt; s=iport; t=1342088980; x=1343298580; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QC87JRSesxFlNZMM/wYzbmW1mW981KojAOBySsSfMKc=; b=h+4mOunT93AeRmOjzh1J36wWzuNCBG53V33+5yJTtdxC1HZM4pHbZj6v nimjnUjief4Dt/2MFCdhtwMpt4BgjMbrqu42XQ3iIVZjuHjblarAT1+g+ ewpBSIn7XKz6vdxKD1DlbhKDhP75zBhWAyC8m4FbKow7RSLhjaTath1XS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADGm/k+tJV2a/2dsb2JhbABFgkq1LYEHgiEBAQQBAQEPAQcNRgELEAIBCDgBBgchBgsUEQIEDgUJEgeHXAMMC51KlkcNiU6KWmYahQJgA5Fag2CLBIMcgWaCX4FWCRo X-IronPort-AV: E=Sophos;i="4.77,573,1336348800"; d="scan'208,217";a="101187125" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jul 2012 10:29:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6CATcFp025004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 10:29:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 05:29:38 -0500 From: "Sri Gundavelli (sgundave)" To: BOC Michael Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cHSJkJyZxPeUOlqQZLnkmKo5clvZmAgAAJIYA= Date: Thu, 12 Jul 2012 10:29:37 +0000 Message-ID: References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> In-Reply-To: <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.006 x-tm-as-result: No--50.369000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_BE67BB35591F477EB9CEF2A0EE20F1C4ciscocom_" MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 10:29:10 -0000 --_000_BE67BB35591F477EB9CEF2A0EE20F1C4ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Michael. Sure. We can discuss offline and work on any clarifications needed. I've one comment with regards to your draft. As Raj said, what the WG draft= is supporting is delegated prefix model and in alignment with the other ap= proaches that were used in DSMIP based protocols after lots of debates and = careful evaluation. The approaches such as NAT-based, or MR doing some for= m of bridging with changing MAC addresses ..etc are approaches that are not= about PD, but about some techniques. You are welcome to publish specs and = get support from the WG to standardize, or publish them as informational sp= ecs (if the WG likes them). Please note that the charter is not disallowing= such approaches, so the PD IESG timeline does not imply the gates are clos= ed. In any case, you want WG reviews on all the assumptions that your draft is = making. The approach of an host learning a Prefix in RA and hosting a part = of the prefix on its ingress side is some magic, IMO. This technique, if le= gal, valid and works for SLAAC, SEND, can be a generic technique useful for= wireless and wireless. Nothing specific to mobility. Regards Sri On Jul 12, 2012, at 2:56 AM, BOC Michael wrote: Hi Sri, The cited points were more =AB topics =BB than just technical misunderstand= ing. Please have a look of my responses in line. I hope they will highlight the = need for a slight delay in the Netext WG milestone plan. Maybe we can change the subject of this mail. Michael De : Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 12 juillet 2012 02:41 =C0 : BOC Michael Cc : Alexandru Petrescu; Basavaraj.Patil@nokia.com; netext@ietf.org Objet : Re: [netext] Milestone update for NetExt WG Hi Michael, Thanks for sharing the details about your project. Nice to know, you have a= n implementation. - Delegating router location Its the LMA. That is the session anchor and for supporting mobility, that n= eeds to be in path and is the only option As in RFC5844, the DHCP server or relay may be located on the MAG then the = location of the Delegating router cannot be simply set on the LMA as =93the= only option=94. We have deployment issues where the DHCPv6 server (and the delegating route= r also) will be located on another server than the MAG and LMA (and this is= an option for us). If the LMA is the session anchor, the delegating router can accommodate wit= h specific configuration. A bit off-topic, I can design a solution much more efficient by having dele= gating routers on MAGs. - Multiple IA_PD request management This is per RFC 3693, standard RR operation, no change You mean RFC3633 ? How does the MAG knows that the MR request specific MNPs= (Section 7, about hints). How does those multiples prefixes are included i= n PBU/PBA? - MNP lifetime management in MAG/LMA Its tied to the PMIP session lifetime. This is identical to session lifetim= e when using DHCPv4 per 5844 RFC5844 says in Section 3.4.3 : The DHCP lease length allocated to the mobile node's IPv4 home address may be different from the binding lifetime at the local mobility anchor for that mobile node's session. It is not possible to keep these lifetimes synchronized, and so its not required that the configured lifetimes should be kept same in both DHCP and Proxy Mobile IPv6. So there are no required synchronization between PMIP session lifetime and = DHCPv6 lease length. In our implementation this cause high overhead in term= s of treatments to evaluate if only one MNP is still valid or not. When we consider tens of MNP per UE and thousands of UEs this is not possib= le. - Interferences with (non) Temporary Addresses Please clarify what is the issue You let the MR sends DHCPv6 SOLICIT. So you let any mobile node to send DHC= Pv6 SOLICIT. So you will have to treat IANA, IATA, IAPD, and so on.. How th= is is done is not presented in the PD I-D draft. And I don=92t even talk about the signaling overhead caused by this. - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two different identifiers uses in different protocol planes. MN Id is the mobile node's identifier. This is tied to the access authentic= ation. DHCP DUID is the identifier used by the RR. PMIPv6 session lifetime is not synchronized with DHCPv6 lease length. Then = if one control plane takes a decision, like PMIPv6=92s mobile node rejectio= n, the delegating router database will remain desynchronized. This can be solved through obscure mechanisms but I think it is important t= o clarify this point (and yes we assume that the delegating router may not = be collocated with the LMA). - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA If the lease length is much more lower than the session lifetime you multip= ly the number of PBU/PBA and DHCPv6 SOLICIT/REQUEST/REPLY/=85 messages - =85 MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the LMA,= so it will have proper correlation and route when subsequent allocation ov= er DHCP PD is complete Please explain which part of the call flow, you have implementation challen= ge +-------------+ +--------------+ +-------------------+ |Mobile Router| | MAG | | LMA | |(Req. Router)| |(DHCPv6 Relay)| |(Delegating Router)| +-------------+ +--------------+ +-------------------+ | | | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 1) | | PMIPv6 tunnel | | |o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do| 2) |-- Solicit ------>| | | | | 3) | |----------PBU------------>| | | | 4) | |<---------PBA-------------| | | | 5) | |--- Solicit ------------->| - - - - <-+ 6) | |<-- Advertise ------------| | | | | | 7) |<- Advertise -----| | Opt | | | ion 8) |-- Request ------>| | al. | | | | 9) | |--- Request ------------->| | - - - - <-+ 10) | |<-- Reply-----------------| | | | 11) |<-- Reply --------| | | | | Figure 1: Prefix Delegation in PMIPv6 during the initial attachment to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose the solutions we found as we addressed = the design, technical, and implementation challenges. They may not solve all cited problems but we are committed to improve the q= uality of the prefix delegation support draft that will be submitted to the= IESG. Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote: Hello, I am co-author of this draft PMIP-NEMO-01 with Alex. We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors. During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft. Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward. The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite: - Delegating router location - Multiple IA_PD request management - MNP lifetime management in MAG/LMA - Interferences with (non) Temporary Addresses - Matching between DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA - ... We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants. PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network. Best Regards, Michael ________________________________________ De : netext-bounces@ietf.org [netext-bounce= s@ietf.org] de la part de Alexandru Petresc= u [alexandru.petrescu@gmail.com] Date d'envoi : mercredi 11 juillet 2012 17:02 =C0 : Basavaraj.Patil@nokia.com Cc : netext@ietf.org Objet : Re: [netext] Milestone update for NetExt WG Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a =E9crit : Hi Alex, On 7/11/12 9:15 AM, "ext Alexandru Petrescu" > wrote: Raj, I have a comment about the proposed milestones: Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...] Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard I wonder whether it is not too early for this submission to IESG. The PD I-D that has been discussed is complete and ready to be sent to the IESG. I see no reason to delay it further. I am saying so because we have an individual proposal which is implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck, which realizes network mobility: http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt The -00 of this was submitted early March 2012, and some comments were issued on the email list at that time. We now have an implementation of it. However, the draft that is proposed to be submitted to the IESG (I suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal which is to support network mobility in a PMIPv6 domain. The PD I-D is a simple solution for delegating prefixes downstream and is not a solution for NEMO in a PMIP6 domain. Raj - I agree with the first part, the WG item draft delegates prefixes by using PMIP extension - yes. But I disagree with the second part. You say it is not a solution for NEMO in a PMIP6 domain. But it says 'Mobile Router' several times. If it is not a solution for NEMO in a PMIP6 domain, then it is a solution to what? There are important differences between the two drafts. Not the least important is that this WG item does not use DHCPv6-PD whereas our individual proposal does, or that maybe we do not know the implementation status of it, or the IPR status, etc. I hope the authors can clarify. For these reasons, I believe it may be too early to submit to IESG. I think further discussion should be performed before submitting to IESG. What do you think? The WG can discuss it on the ML. With my chair hat on, I do believe that the WG PD I-D is ready to be forwarded to the IESG as it is solving a very specific problem. I am trying to understand what problem? WG item draft's first phrase is: This specification extends PMIPv6 to assign a mobile network prefix to a mobile router for supporting network mobility. Isn't this NEMO? Yours, Alex -Raj Yours, Alex Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listin= fo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_BE67BB35591F477EB9CEF2A0EE20F1C4ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8CC3E03FB8C1F8458839D9FF5D8813EF@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Michael.

Sure. We can discuss offline and work on any clarifications needed.

I've one comment with regards to your draft. As Raj said, what the WG = draft is supporting is delegated prefix model and in alignment with the oth= er approaches that were used in DSMIP based protocols after lots of debates= and careful evaluation.  The approaches such as NAT-based, or MR doing some form of bridging with changing MAC add= resses ..etc are approaches that are not about PD, but about some technique= s. You are welcome to publish specs and get support from the WG to standard= ize, or publish them as informational specs (if the WG likes them). Please note that the charter is not disallow= ing such approaches, so the PD IESG timeline does not imply the gates are c= losed.

In any case, you want WG reviews on all the assumptions that your draf= t is making. The approach of an host learning a Prefix in RA and hosting a = part of the prefix on its ingress side is some magic, IMO. This technique, = if legal, valid and works for SLAAC, SEND, can be a generic technique useful for wireless and wireless. Nothing= specific to mobility.

 
Regards
Sri






On Jul 12, 2012, at 2:56 AM, BOC Michael wrote:

Hi Sri,
 
The cited points were more =AB topics=  =BB than just technical misunderstanding.
 
Please have a look of my responses in line= . I hope they will highlight the need for a slight delay in the Netext WG m= ilestone plan.
Maybe we can change the subject of this ma= il.
 
 
Michael
 
De&nb= sp;: Sri Gundavelli (s= gundave) [mailto:sgundave@cisco.com]&= nbsp;
Envoy=E9 : je= udi 12 juillet 2012 02:41
=C0 : BOC Mic= hael
Cc : Alexandr= u Petrescu; Basavaraj.Patil@nokia.com; netext@ietf.org
Objet : Re: [= netext] Milestone update for NetExt WG
 
Hi Michael,
 
 
Thanks for sharing the details about your project. Nice to know, you have a= n implementation.
 
 
 
 
- Delegating router location
 
Its the LMA. That is the session anchor and for supporting mobility, that n= eeds to be in path and is the only option
 
As in RFC5844, the= DHCP server or relay may be located on the MAG then the location of the De= legating router cannot be simply set on the LMA as =93the only option=94.
We have deployment= issues where the DHCPv6 server (and the delegating router also) will be lo= cated on another server than the MAG and LMA (and this is an option for us)= .
If the LMA is the = session anchor, the delegating router can accommodate with specific configu= ration.
 <= /span>
A bit off-topic, I= can design a solution much more efficient by having delegating routers on = MAGs.  
 


- Multiple IA_PD request management<= /div>
 
This is per RFC 3693, standard RR operation, no= change
 
You mean RFC3633 ? How does the MAG k= nows that the MR request specific MNPs (Section 7, about hints). How does t= hose multiples prefixes are included in PBU/PBA?


- MNP lifetime management in MAG/LMA
 
Its tied to the PMIP session lifetime. This is identical to session lifetim= e when using DHCPv4 per 5844
 
RFC5844 says in Section 3.4.3 :<= /o:p>
<= o:p> 
T= he DHCP lease length allocated to the mobile node's IPv4 home
&= nbsp;     address may be different from the binding lif= etime at the local
&= nbsp;     mobility anchor for that mobile node's sessio= n.  It is not
&= nbsp;     possible to keep these lifetimes synchronized= , and so its not
&= nbsp;     required that the configured lifetimes should= be kept same in both
&= nbsp;     DHCP and Proxy Mobile IPv6.=
 
So there are no required synchronization b= etween PMIP session lifetime and DHCPv6 lease length. In our implementation= this cause high overhead in terms of treatments to evaluate if only one MNP is still valid or not.
When we consider tens of MNP per UE and th= ousands of UEs this is not possible.


- Interferences with (non) Temporary Addresses
 
Please clarify what is the issue
 
 
You let the MR sends DHCPv6 SOLICIT. So yo= u let any mobile node to send DHCPv6 SOLICIT. So you will have to treat IAN= A, IATA, IAPD, and so on.. How this is done is not presented in the PD I-D draft.
And I don=92t even talk about the signalin= g overhead caused by this.
 
 


- Matching between DHCPv6's DUID and PMIPv6's MNID
 
Those are two different identifiers uses in different protocol planes.=
MN Id is the mobile node's identifier. This is tied to the access authentic= ation.
DHCP DUID is the identifier used by the RR. 
 
 
PMIPv6 session lifetime is not synchronize= d with DHCPv6 lease length. Then if one control plane takes a decision, lik= e PMIPv6=92s mobile node rejection, the delegating router database will remain desynchronized.
This can be solved through obscure mechani= sms but I think it is important to clarify this point (and yes we assume th= at the delegating router may not be collocated with the LMA).
 
 
- Increasing load of DHCPv6 solicit/reply and by exten= sion PBU/PBA

If the lease length is much more lower tha= n the session lifetime you multiply the number of PBU/PBA and DHCPv6 SOLICI= T/REQUEST/REPLY/=85 messages
 
 
- =85
 
MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the LMA,= so it will have proper correlation and route when subsequent allocation ov= er DHCP PD is complete
 
 
 
Please explain which part of the call flow, you have implementation challen= ge
 
   +-------------+&nb=
sp;   +--------------+      =
;    +-------------------+
 &nbs=
p; |Mobile Router|    |      MAG&nb=
sp;    |        &nbs=
p; |      LMA      &=
nbsp;   |
 &nbs=
p; |(Req. Router)|    |(DHCPv6 Relay)|   &nbs=
p;      |(Delegating Router)|
 &nbs=
p; +-------------+    +--------------+ =
         +-------------------&#=
43;
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
 &nbs=
p;        |     =
;             |=
o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do|=

 &nbs=
p; 1)     |       &n=
bsp;          |  &nb=
sp;   PMIPv6 tunnel       |
 &nbs=
p;        |     =
;             |=
o=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Do|=

 &nbs=
p; 2)     |-- Solicit ------>|   &nbs=
p;            &=
nbsp;         |
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
 &nbs=
p; 3)     |       &n=
bsp;          |----------PBU--=
---------->|
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
  &nb=
sp;4)     |       &n=
bsp;          |<---------PB=
A-------------|
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
 &nbs=
p; 5)     |       &n=
bsp;          |--- Solicit ---=
---------->|
 &nbs=
p;        -     =
;             -=
            &nb=
sp;   -         - <-&#=
43;
 &nbs=
p; 6)     |       &n=
bsp;          |<-- Advertis=
e ------------|   |
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |   |
 &nbs=
p; 7)     |<- Advertise -----|   &nbs=
p;            &=
nbsp;         |  Opt
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |  ion
 &nbs=
p; 8)     |-- Request ------>|   &nbs=
p;            &=
nbsp;         |  al.
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |   |
 &nbs=
p; 9)     |       &n=
bsp;          |--- Request ---=
---------->|   |
 &nbs=
p;        -     =
;             -=
            &nb=
sp;   -         - <-&#=
43;
 &nbs=
p; 10)    |        &=
nbsp;         |<-- Reply--------=
---------|
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
 &nbs=
p; 11)    |<-- Reply --------|    &nb=
sp;            =
         |
 &nbs=
p;        |     =
;             |=
            &nb=
sp;            =
 |
 =
;
 &nbs=
p;  Figure 1: Prefix Delegation in PMIPv6 during the initial attachmen=
t
 &nbs=
p;            &=
nbsp;            to =
the PMIPv6 Domain
&= nbsp;
 
In the draft PMIP-NEMO-02 we expose the solutions we found as we a= ddressed the design, technical, and implementation challenges.
They may not solve all cited problems but we are committed to impr= ove the quality of the prefix delegation support draft that will be submitt= ed to the IESG.  
 
 
 
Regards
Sri
 
 
 
On Jul 11, 2012, at 1:54 PM, BOC Michael wrote:


Hello,

I am co-author of this draft PMIP-NEMO-01 with Alex.
We have implemented PMIPv6 from scratch, our extension as well as other ext= ensions proposed by netext contributors. 

During the implementation of the PMIP-NEMO extension, we faced a lot of tec= hnical problems but also design ones that were not solved by PD I-D -00 and= still not with -02. We want to share with you about these problems and the= solutions that we selected in our draft.  

Hence, beside the very specific support of prefix delegation in PMIPv6 the = PD I-D proposes, we do consider that important related design choices and f= unctionalities must be discussed before going forward. 

The design choices and some of the important functionalities are discussed = in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are= different than PD I-D). For early discussions we can cite: 
- Delegating router location
- Multiple IA_PD request management
- MNP lifetime management in MAG/LMA
- Interferences with (non) Temporary Addresses
- Matching between DHCPv6's DUID and PMIPv6's MNID
- Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
- ...

We are open to discuss about them with the PD I-D authors at IETF84 and on = the ML with all interested participants.


PS: I don't want to come back on the discussion about NEMO support or not. = I agree that the MR does not participate actively in any IP mobility signal= ing on the interface towards the mobile operator network.  


Best Regards,


Michael


________________________________________
De : = netext-bounces@ietf.org [netext-bounces@ietf.org] de la part de Alexandru Petrescu [alexandru.petre= scu@gmail.com]
Date d'envoi : mercredi 11 juillet 2012 17:02
=C0 :  netext@i= etf.org
Objet : Re: [netext] Milestone update for NetExt WG

Le 11/07/2012 16:48, Basavaraj.Patil@nokia.com a =E9crit :

 
Hi Alex,
 
On 7/11/12 9:15 AM, "ext Alexandru Petrescu"
 
Raj,
 
I have a comment about the proposed milestones:
 
Le 25/04/2012 22:36, Basavaraj.Patil@nokia.com a =E9crit : [...]
Jul 2012    Submit Prefix Delegation for Proxy Mobile IPv6 t= o IESG
for publication as a proposed standard
 
I wonder whether it is not too early for this submission to IESG.
 
The PD I-D that has been discussed is complete and ready to be sent
to the IESG. I see no reason to delay it further.
 
 
I am saying so because we have an individual proposal which is
implemented and uses DHCPv6-Prefix Delegation, together with
PBU/PBAck, which realizes network mobility:
 
The -00 of this was submitted early March 2012, and some comments
were issued on the email list at that time.
 
We now have an implementation of it.
 
However, the draft that is proposed to be submitted to the IESG (I
suppose draft-ietf-netext-pd-pmip-02) seems to me to have the
same goal which is to support network mobility in a PMIPv6 domain.
 
The PD I-D is a simple solution for delegating prefixes downstream
and is not a solution for NEMO in a PMIP6 domain.

Raj - I agree with the first part, the WG item draft delegates prefixes
by using PMIP extension - yes.

But I disagree with the second part.  You say it is not a solution for=
NEMO in a PMIP6 domain.  But it says 'Mobile Router' several times.
If it is not a solution for NEMO in a PMIP6 domain, then it is a
solution to what?


There are important differences between the two drafts.  Not the<= /o:p>
least important is that this WG item does not use DHCPv6-PD
whereas our individual proposal does, or that maybe we do not know
the implementation status of it, or the IPR status, etc.
 
I hope the authors can clarify.
 
 
For these reasons, I believe it may be too early to submit to
IESG. I think further discussion should be performed before
submitting to IESG.
 
What do you think?
 
The WG can discuss it on the ML. With my chair hat on, I do believe
that the WG PD I-D is ready to be forwarded to the IESG as it is=
solving a very specific problem.

I am trying to understand what problem?

WG item draft's first phrase is:

This specification extends PMIPv6 to assign a mobile network prefix
to a mobile router for supporting network mobility.

Isn't this NEMO?

Yours,

Alex


 
-Raj
 
 
Yours,
 
Alex
 
 
Nov 2012    Submit IPv4 Traffic Offload Selector Option for = Proxy
Mobile IPv6 to IESG for publication as a proposed standard Feb
2013        Submit Proxy Mobile IPv6 Ext= ensions to Support Flow
Mobility to IESG for publication as a proposed standard Mar 2013=
Submit Service Selection for MIP6 and PMIP6 to the IESG for
publication as a proposed standard Apr 2013 Submit Logical
Interface Support for multi-mode IP Hosts for publication as an<= /div>
Informational document May 2013     Submit EAP Attribut= es for WiFi -
EPC Integration to IESG for publication as a proposed standard
 
 
 
_______________________________________________ netext mailing
 
 
 
 
_______________________________________________ netext mailing list
 
 
 



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

--_000_BE67BB35591F477EB9CEF2A0EE20F1C4ciscocom_-- From alexandru.petrescu@gmail.com Thu Jul 12 04:21:55 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 213A421F880F for ; Thu, 12 Jul 2012 04:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_FR=0.35, 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 LkxQMt8Ll-bo for ; Thu, 12 Jul 2012 04:21:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 039F821F8815 for ; Thu, 12 Jul 2012 04:21:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CBMMRE030006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 13:22:22 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CBMMBq025435; Thu, 12 Jul 2012 13:22:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CBMGro008378; Thu, 12 Jul 2012 13:22:21 +0200 Message-ID: <4FFEB368.1030503@gmail.com> Date: Thu, 12 Jul 2012 13:22:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] Is draft-ietf-netext-pd-pmip-02 about network mobility or not? (was: Milestone update for NetExt WG) 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, 12 Jul 2012 11:21:55 -0000 Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : > Hi Michael. > > Sure. We can discuss offline and work on any clarifications needed. Offline? > I've one comment with regards to your draft. As Raj said, what the WG > draft is supporting is delegated prefix model I tend to agree with a model where the prefix is delegated. > and in alignment with the other approaches that were used in DSMIP > based protocols after lots of debates and careful evaluation. What does this mean in particular? I don't understand what do you refer to by this alignment? There doesn't seem to be v4/v6 in this PMIP-NEMO discussion, so why mentioning DSMIP? > The approaches such as NAT-based, or MR doing some form of bridging > with changing MAC addresses ..etc are approaches that are not about > PD, but about some techniques. Well, we do not consider neither NAT, nor changing MAC addresses aka ND proxy, other than maybe tangential - these are not core to our PMIP-NEMO proposals The manner we propose by which a HNP can be subdivided into several MNPs is none of these. > You are welcome to publish specs and get support from the WG to > standardize, or publish them as informational specs (if the WG likes > them). Please note that the charter is not disallowing such > approaches, so the PD IESG timeline does not imply the gates are > closed. No no Sri, please read our comments. Please clarify. For example, both you and Raj seem to insist that draft-ietf-netext-pd-pmip-02 is not about network mobility. But the draft says "This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation." So again - is this draft about network mobility or not? Alex > > In any case, you want WG reviews on all the assumptions that your > draft is making. The approach of an host learning a Prefix in RA and > hosting a part of the prefix on its ingress side is some magic, IMO. > This technique, if legal, valid and works for SLAAC, SEND, can be a > generic technique useful for wireless and wireless. Nothing specific > to mobility. > > Regards Sri > > > > > > > On Jul 12, 2012, at 2:56 AM, BOC Michael wrote: > >> Hi Sri, The cited points were more « topics » than just technical >> misunderstanding. Please have a look of my responses in line. I >> hope they will highlight the need for a slight delay in the Netext >> WG milestone plan. Maybe we can change the subject of this mail. >> Michael *De :*Sri Gundavelli (sgundave) >> [mailto:sgundave@cisco.com] *Envoyé :*jeudi 12 juillet 2012 02:41 >> *À :*BOC Michael *Cc :*Alexandru Petrescu;Basavaraj.Patil@nokia.com >> ;netext@ietf.org >> *Objet :*Re: [netext] Milestone update for >> NetExt WG Hi Michael, Thanks for sharing the details about your >> project. Nice to know, you have an implementation. >> >> - Delegating router location >> >> Its the LMA. That is the session anchor and for supporting >> mobility, that needs to be in path and is the only option As in >> RFC5844, the DHCP server or relay may be located on the MAG then >> the location of the Delegating router cannot be simply set on the >> LMA as “the only option”. We have deployment issues where the >> DHCPv6 server (and the delegating router also) will be located on >> another server than the MAG and LMA (and this is an option for >> us). If the LMA is the session anchor, the delegating router can >> accommodate with specific configuration. A bit off-topic, I can >> design a solution much more efficient by having delegating routers >> on MAGs. >> >> >> - Multiple IA_PD request management This is per RFC 3693, standard >> RR operation, no change You mean RFC3633 ? How does the MAG knows >> that the MR request specific MNPs (Section 7, about hints). How >> does those multiples prefixes are included in PBU/PBA? >> >> >> - MNP lifetime management in MAG/LMA Its tied to the PMIP session >> lifetime. This is identical to session lifetime when using DHCPv4 >> per 5844 RFC5844 says in Section 3.4.3 : The DHCP lease length >> allocated to the mobile node's IPv4 home address may be different >> from the binding lifetime at the local mobility anchor for that >> mobile node's session. It is not possible to keep these lifetimes >> synchronized, and so its not required that the configured >> lifetimes should be kept same in both DHCP and Proxy Mobile IPv6. >> So there are no required synchronization between PMIP session >> lifetime and DHCPv6 lease length. In our implementation this cause >> high overhead in terms of treatments to evaluate if only one MNP >> is still valid or not. When we consider tens of MNP per UE and >> thousands of UEs this is not possible. >> >> >> - Interferences with (non) Temporary Addresses Please clarify what >> is the issue You let the MR sends DHCPv6 SOLICIT. So you let any >> mobile node to send DHCPv6 SOLICIT. So you will have to treat IANA, >> IATA, IAPD, and so on.. How this is done is not presented in the PD >> I-D draft. And I don’t even talk about the signaling overhead >> caused by this. >> >> >> - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two >> different identifiers uses in different protocol planes. MN Id is >> the mobile node's identifier. This is tied to the access >> authentication. DHCP DUID is the identifier used by the RR. PMIPv6 >> session lifetime is not synchronized with DHCPv6 lease length. >> Then if one control plane takes a decision, like PMIPv6’s mobile >> node rejection, the delegating router database will remain >> desynchronized. This can be solved through obscure mechanisms but I >> think it is important to clarify this point (and yes we assume that >> the delegating router may not be collocated with the LMA). - >> Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA >> >> If the lease length is much more lower than the session lifetime >> you multiply the number of PBU/PBA and DHCPv6 >> SOLICIT/REQUEST/REPLY/… messages - … MAG uses the DHCPv6 solicit as >> a trigger for MNP state creation on the LMA, so it will have proper >> correlation and route when subsequent allocation over DHCP PD is >> complete Please explain which part of the call flow, you have >> implementation challenge +-------------+ +--------------+ >> +-------------------+ |Mobile Router| | MAG | | LMA >> | |(Req. Router)| |(DHCPv6 Relay)| |(Delegating Router)| >> +-------------+ +--------------+ +-------------------+ | >> | | | |o========================o| 1) | | PMIPv6 tunnel >> | | |o========================o| 2) |-- Solicit ------>| | | | >> | 3) | |----------PBU------------>| | | | 4) >> | |<---------PBA-------------| | | | 5) | >> |--- Solicit ------------->| - - - - <-+ 6) >> | |<-- Advertise ------------| | | | >> | | 7) |<- Advertise -----| | Opt | | | ion 8) >> |-- Request ------>| | al. | | | | 9) >> | |--- Request ------------->| | - - >> - - <-+ 10) | |<-- Reply-----------------| | | >> | 11) |<-- Reply --------| | | | >> | >> >> Figure 1: Prefix Delegation in PMIPv6 during the initial >> attachment to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose >> the solutions we found as we addressed the design, technical, and >> implementation challenges. They may not solve all cited problems >> but we are committed to improve the quality of the prefix >> delegation support draft that will be submitted to the IESG. >> Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote: >> >> >> Hello, >> >> I am co-author of this draft PMIP-NEMO-01 with Alex. We have >> implemented PMIPv6 from scratch, our extension as well as other >> extensions proposed by netext contributors. >> >> During the implementation of the PMIP-NEMO extension, we faced a >> lot of technical problems but also design ones that were not solved >> by PD I-D -00 and still not with -02. We want to share with you >> about these problems and the solutions that we selected in our >> draft. >> >> Hence, beside the very specific support of prefix delegation in >> PMIPv6 the PD I-D proposes, we do consider that important related >> design choices and functionalities must be discussed before going >> forward. >> >> The design choices and some of the important functionalities are >> discussed in our draft PMIP-NEMO-02 (and yes the solutions >> described in our draft are different than PD I-D). For early >> discussions we can cite: - Delegating router location - Multiple >> IA_PD request management - MNP lifetime management in MAG/LMA - >> Interferences with (non) Temporary Addresses - Matching between >> DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6 >> solicit/reply and by extension PBU/PBA - ... >> >> We are open to discuss about them with the PD I-D authors at IETF84 >> and on the ML with all interested participants. >> >> >> PS: I don't want to come back on the discussion about NEMO support >> or not. I agree that the MR does not participate actively in any >> IP mobility signaling on the interface towards the mobile operator >> network. >> >> >> Best Regards, >> >> >> Michael >> >> >> ________________________________________ De >> :netext-bounces@ietf.org >> [netext-bounces@ietf.org >> ] de la part de Alexandru Petrescu >> [alexandru.petrescu@gmail.com >> ] Date d'envoi : mercredi 11 >> juillet 2012 17:02 À :Basavaraj.Patil@nokia.com >> Cc :netext@ietf.org >> Objet : Re: [netext] Milestone update for >> NetExt WG >> >> Le 11/07/2012 16:48,Basavaraj.Patil@nokia.com >> a écrit : >> >> Hi Alex, >> >> On 7/11/12 9:15 AM, "ext Alexandru Petrescu" >> >> > > wrote: >> >> Raj, >> >> I have a comment about the proposed milestones: >> >> Le 25/04/2012 22:36,Basavaraj.Patil@nokia.com >> a écrit : [...] >> >> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG >> >> for publication as a proposed standard >> >> I wonder whether it is not too early for this submission to IESG. >> >> The PD I-D that has been discussed is complete and ready to be >> sent >> >> to the IESG. I see no reason to delay it further. >> >> I am saying so because we have an individual proposal which is >> >> implemented and uses DHCPv6-Prefix Delegation, together with >> >> PBU/PBAck, which realizes network mobility: >> >> http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt >> >> The -00 of this was submitted early March 2012, and some comments >> >> were issued on the email list at that time. >> >> We now have an implementation of it. >> >> However, the draft that is proposed to be submitted to the IESG (I >> >> suppose draft-ietf-netext-pd-pmip-02) seems to me to have the >> >> same goal which is to support network mobility in a PMIPv6 domain. >> >> The PD I-D is a simple solution for delegating prefixes downstream >> >> and is not a solution for NEMO in a PMIP6 domain. >> >> >> Raj - I agree with the first part, the WG item draft delegates >> prefixes by using PMIP extension - yes. >> >> But I disagree with the second part. You say it is not a solution >> for NEMO in a PMIP6 domain. But it says 'Mobile Router' several >> times. >> >> If it is not a solution for NEMO in a PMIP6 domain, then it is a >> solution to what? >> >> >> There are important differences between the two drafts. Not the >> >> least important is that this WG item does not use DHCPv6-PD >> >> whereas our individual proposal does, or that maybe we do not know >> >> the implementation status of it, or the IPR status, etc. >> >> I hope the authors can clarify. >> >> For these reasons, I believe it may be too early to submit to >> >> IESG. I think further discussion should be performed before >> >> submitting to IESG. >> >> What do you think? >> >> The WG can discuss it on the ML. With my chair hat on, I do >> believe >> >> that the WG PD I-D is ready to be forwarded to the IESG as it is >> >> solving a very specific problem. >> >> >> I am trying to understand what problem? >> >> WG item draft's first phrase is: >> >> This specification extends PMIPv6 to assign a mobile network >> prefix >> >> to a mobile router for supporting network mobility. >> >> >> Isn't this NEMO? >> >> Yours, >> >> Alex >> >> >> -Raj >> >> Yours, >> >> Alex >> >> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy >> >> Mobile IPv6 to IESG for publication as a proposed standard Feb >> >> 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow >> >> Mobility to IESG for publication as a proposed standard Mar 2013 >> >> Submit Service Selection for MIP6 and PMIP6 to the IESG for >> >> publication as a proposed standard Apr 2013 Submit Logical >> >> Interface Support for multi-mode IP Hosts for publication as an >> >> Informational document May 2013 Submit EAP Attributes for WiFi >> - >> >> EPC Integration to IESG for publication as a proposed standard >> >> _______________________________________________ netext mailing >> >> listnetext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ netext mailing >> list >> >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> >> >> >> >> >> >> _______________________________________________ >> netext mailing list netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> _______________________________________________ netext mailing >> list netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From alexandru.petrescu@gmail.com Thu Jul 12 04:47:59 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 2928E21F8819 for ; Thu, 12 Jul 2012 04:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-2.596, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 s6EnjxEofYUJ for ; Thu, 12 Jul 2012 04:47:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF1D21F8615 for ; Thu, 12 Jul 2012 04:47:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CBmRAA012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 13:48:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CBmRbT001016; Thu, 12 Jul 2012 13:48:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CBmNEc019832; Thu, 12 Jul 2012 13:48:27 +0200 Message-ID: <4FFEB987.8050608@gmail.com> Date: Thu, 12 Jul 2012 13:48:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 11:47:59 -0000 Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : [...] > In any case, you want WG reviews on all the assumptions that your > draft is making. The approach of an host learning a Prefix in RA and > hosting a part of the prefix on its ingress side is some magic, IMO. Sri, sorry for intervening on this aspect. I wanted to mention: This HNP Division approach is nothing magic, there are a number of other proposals doing similar prefix division in order to deliver further in a network. The other comment is that our method of achieving network mobility with PMIP and DHCP Prefix Delegation works without the above HNP prefix division. The two methods are alternative - do HNP Division and no need of Prefix Delegation, do Prefix Delegation and no need of HNP Division. > This technique, if legal, valid and works for SLAAC, SEND, can be a > generic technique useful for wireless and wireless. Nothing specific > to mobility. Well we do it for network mobility and not for generic technique. I am afraid that if you submit now a draft doing network mobility in PMIP any other subsequent network mobility PMIP submission will have to face the question of why we do it again. Or, the question now is why is PMIP-Prefix Delegation claiming to do network mobility and not do network mobility at the same time? My supposition is that authors claim to the WG that authors do not do network mobility and authors claim to elsewhere that authors _do_ network mobility. This is obvious to me that it is illogic. Yours, Alex > > Regards Sri > > > > > > > On Jul 12, 2012, at 2:56 AM, BOC Michael wrote: > >> Hi Sri, The cited points were more « topics » than just technical >> misunderstanding. Please have a look of my responses in line. I >> hope they will highlight the need for a slight delay in the Netext >> WG milestone plan. Maybe we can change the subject of this mail. >> Michael *De :*Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >> *Envoyé :*jeudi 12 juillet 2012 02:41 *À :*BOC Michael *Cc >> :*Alexandru Petrescu;Basavaraj.Patil@nokia.com >> ;netext@ietf.org >> *Objet :*Re: [netext] Milestone update >> for NetExt WG Hi Michael, Thanks for sharing the details about >> your project. Nice to know, you have an implementation. >> >> - Delegating router location >> >> Its the LMA. That is the session anchor and for supporting >> mobility, that needs to be in path and is the only option As in >> RFC5844, the DHCP server or relay may be located on the MAG then >> the location of the Delegating router cannot be simply set on the >> LMA as “the only option”. We have deployment issues where the >> DHCPv6 server (and the delegating router also) will be located on >> another server than the MAG and LMA (and this is an option for us). >> If the LMA is the session anchor, the delegating router can >> accommodate with specific configuration. A bit off-topic, I can >> design a solution much more efficient by having delegating routers >> on MAGs. >> >> >> - Multiple IA_PD request management This is per RFC 3693, standard >> RR operation, no change You mean RFC3633 ? How does the MAG knows >> that the MR request specific MNPs (Section 7, about hints). How >> does those multiples prefixes are included in PBU/PBA? >> >> >> - MNP lifetime management in MAG/LMA Its tied to the PMIP session >> lifetime. This is identical to session lifetime when using DHCPv4 >> per 5844 RFC5844 says in Section 3.4.3 : The DHCP lease length >> allocated to the mobile node's IPv4 home address may be different >> from the binding lifetime at the local mobility anchor for that >> mobile node's session. It is not possible to keep these lifetimes >> synchronized, and so its not required that the configured >> lifetimes should be kept same in both DHCP and Proxy Mobile IPv6. >> So there are no required synchronization between PMIP session >> lifetime and DHCPv6 lease length. In our implementation this cause >> high overhead in terms of treatments to evaluate if only one MNP is >> still valid or not. When we consider tens of MNP per UE and >> thousands of UEs this is not possible. >> >> >> - Interferences with (non) Temporary Addresses Please clarify what >> is the issue You let the MR sends DHCPv6 SOLICIT. So you let any >> mobile node to send DHCPv6 SOLICIT. So you will have to treat >> IANA, IATA, IAPD, and so on.. How this is done is not presented in >> the PD I-D draft. And I don’t even talk about the signaling >> overhead caused by this. >> >> >> - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two >> different identifiers uses in different protocol planes. MN Id is >> the mobile node's identifier. This is tied to the access >> authentication. DHCP DUID is the identifier used by the RR. PMIPv6 >> session lifetime is not synchronized with DHCPv6 lease length. >> Then if one control plane takes a decision, like PMIPv6’s mobile >> node rejection, the delegating router database will remain >> desynchronized. This can be solved through obscure mechanisms but >> I think it is important to clarify this point (and yes we assume >> that the delegating router may not be collocated with the LMA). - >> Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA >> >> If the lease length is much more lower than the session lifetime >> you multiply the number of PBU/PBA and DHCPv6 >> SOLICIT/REQUEST/REPLY/… messages - … MAG uses the DHCPv6 solicit >> as a trigger for MNP state creation on the LMA, so it will have >> proper correlation and route when subsequent allocation over DHCP >> PD is complete Please explain which part of the call flow, you >> have implementation challenge +-------------+ +--------------+ >> +-------------------+ |Mobile Router| | MAG | | >> LMA | |(Req. Router)| |(DHCPv6 Relay)| |(Delegating >> Router)| +-------------+ +--------------+ +-------------------+ >> | | | | >> |o========================o| 1) | | PMIPv6 tunnel | >> | |o========================o| 2) |-- Solicit ------>| | | >> | | 3) | |----------PBU------------>| >> | | | 4) | >> |<---------PBA-------------| | | | 5) >> | |--- Solicit ------------->| - >> - - - <-+ 6) | |<-- >> Advertise ------------| | | | | | 7) >> |<- Advertise -----| | Opt | | >> | ion 8) |-- Request ------>| | al. | | >> | | 9) | |--- Request ------------->| | - >> - - - <-+ 10) | |<-- >> Reply-----------------| | | | 11) |<-- >> Reply --------| | | | | >> >> Figure 1: Prefix Delegation in PMIPv6 during the initial attachment >> to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose the >> solutions we found as we addressed the design, technical, and >> implementation challenges. They may not solve all cited problems >> but we are committed to improve the quality of the prefix >> delegation support draft that will be submitted to the IESG. >> Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote: >> >> >> Hello, >> >> I am co-author of this draft PMIP-NEMO-01 with Alex. We have >> implemented PMIPv6 from scratch, our extension as well as other >> extensions proposed by netext contributors. >> >> During the implementation of the PMIP-NEMO extension, we faced a >> lot of technical problems but also design ones that were not >> solved by PD I-D -00 and still not with -02. We want to share with >> you about these problems and the solutions that we selected in our >> draft. >> >> Hence, beside the very specific support of prefix delegation in >> PMIPv6 the PD I-D proposes, we do consider that important related >> design choices and functionalities must be discussed before going >> forward. >> >> The design choices and some of the important functionalities are >> discussed in our draft PMIP-NEMO-02 (and yes the solutions >> described in our draft are different than PD I-D). For early >> discussions we can cite: - Delegating router location - Multiple >> IA_PD request management - MNP lifetime management in MAG/LMA - >> Interferences with (non) Temporary Addresses - Matching between >> DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6 >> solicit/reply and by extension PBU/PBA - ... >> >> We are open to discuss about them with the PD I-D authors at >> IETF84 and on the ML with all interested participants. >> >> >> PS: I don't want to come back on the discussion about NEMO support >> or not. I agree that the MR does not participate actively in any >> IP mobility signaling on the interface towards the mobile operator >> network. >> >> >> Best Regards, >> >> >> Michael >> >> >> ________________________________________ De >> :netext-bounces@ietf.org >> [netext-bounces@ietf.org >> ] de la part de Alexandru Petrescu >> [alexandru.petrescu@gmail.com >> ] Date d'envoi : mercredi 11 >> juillet 2012 17:02 À :Basavaraj.Patil@nokia.com >> Cc :netext@ietf.org >> Objet : Re: [netext] Milestone update for >> NetExt WG >> >> Le 11/07/2012 16:48,Basavaraj.Patil@nokia.com >> a écrit : >> >> Hi Alex, >> >> On 7/11/12 9:15 AM, "ext Alexandru Petrescu" >> >> > > wrote: >> >> Raj, >> >> I have a comment about the proposed milestones: >> >> Le 25/04/2012 22:36,Basavaraj.Patil@nokia.com >> a écrit : [...] >> >> Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG >> >> for publication as a proposed standard >> >> I wonder whether it is not too early for this submission to IESG. >> >> The PD I-D that has been discussed is complete and ready to be >> sent >> >> to the IESG. I see no reason to delay it further. >> >> I am saying so because we have an individual proposal which is >> >> implemented and uses DHCPv6-Prefix Delegation, together with >> >> PBU/PBAck, which realizes network mobility: >> >> http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt >> >> The -00 of this was submitted early March 2012, and some comments >> >> were issued on the email list at that time. >> >> We now have an implementation of it. >> >> However, the draft that is proposed to be submitted to the IESG (I >> >> suppose draft-ietf-netext-pd-pmip-02) seems to me to have the >> >> same goal which is to support network mobility in a PMIPv6 domain. >> >> The PD I-D is a simple solution for delegating prefixes downstream >> >> and is not a solution for NEMO in a PMIP6 domain. >> >> >> Raj - I agree with the first part, the WG item draft delegates >> prefixes by using PMIP extension - yes. >> >> But I disagree with the second part. You say it is not a solution >> for NEMO in a PMIP6 domain. But it says 'Mobile Router' several >> times. >> >> If it is not a solution for NEMO in a PMIP6 domain, then it is a >> solution to what? >> >> >> There are important differences between the two drafts. Not the >> >> least important is that this WG item does not use DHCPv6-PD >> >> whereas our individual proposal does, or that maybe we do not know >> >> the implementation status of it, or the IPR status, etc. >> >> I hope the authors can clarify. >> >> For these reasons, I believe it may be too early to submit to >> >> IESG. I think further discussion should be performed before >> >> submitting to IESG. >> >> What do you think? >> >> The WG can discuss it on the ML. With my chair hat on, I do >> believe >> >> that the WG PD I-D is ready to be forwarded to the IESG as it is >> >> solving a very specific problem. >> >> >> I am trying to understand what problem? >> >> WG item draft's first phrase is: >> >> This specification extends PMIPv6 to assign a mobile network >> prefix >> >> to a mobile router for supporting network mobility. >> >> >> Isn't this NEMO? >> >> Yours, >> >> Alex >> >> >> -Raj >> >> Yours, >> >> Alex >> >> Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy >> >> Mobile IPv6 to IESG for publication as a proposed standard Feb >> >> 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow >> >> Mobility to IESG for publication as a proposed standard Mar 2013 >> >> Submit Service Selection for MIP6 and PMIP6 to the IESG for >> >> publication as a proposed standard Apr 2013 Submit Logical >> >> Interface Support for multi-mode IP Hosts for publication as an >> >> Informational document May 2013 Submit EAP Attributes for WiFi >> - >> >> EPC Integration to IESG for publication as a proposed standard >> >> _______________________________________________ netext mailing >> >> listnetext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ netext mailing >> list >> >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> >> >> >> >> >> _______________________________________________ >> netext mailing list netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> _______________________________________________ netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Thu Jul 12 06:26:29 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 ED9CC21F884B for ; Thu, 12 Jul 2012 06:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 c4lCQL2+LrAd for ; Thu, 12 Jul 2012 06:26:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D528D21F8849 for ; Thu, 12 Jul 2012 06:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4399; q=dns/txt; s=iport; t=1342099622; x=1343309222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dzaOKymie6TfMy4aTISnLo72fkYjhwMDM+NeIjO6FlM=; b=RzxlYDtl+ym23AHkJNBpC1wMLUf73s7NzKOObFNfvzTVZNhuv1ovLASY WSWJblvqOIJgCZ2twQpkOkZA2QAOhaMyXJ28JOrqZ5S3Nt2FNV6wCfzWE ZB5yMT7h17M3S9Daigcf68SBn8DhVRHCAMlhikuPH9Ix0lY+yHoAheNDn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGDO/k+tJV2d/2dsb2JhbABFtB6DWoEHgiABAQEDARIBWgcFBQsCAQhGMiUCBA4nh2UGnVGgHItAhRxgA5U6jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,573,1336348800"; d="scan'208";a="101237382" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jul 2012 13:27:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6CDR1xF017444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 13:27:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 08:27:01 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandru Petrescu Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cHSJkJyZxPeUOlqQZLnkmKo5clvZmAgAAJIYCAABYEgIAAG4yA Date: Thu, 12 Jul 2012 13:27:00 +0000 Message-ID: <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> <4FFEB987.8050608@gmail.com> In-Reply-To: <4FFEB987.8050608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.144.60] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.006 x-tm-as-result: No--44.916500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 13:26:30 -0000 Alex: On Jul 12, 2012, at 4:48 AM, Alexandru Petrescu wrote: > Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a =E9crit : > [...] >> In any case, you want WG reviews on all the assumptions that your >> draft is making. The approach of an host learning a Prefix in RA and >> hosting a part of the prefix on its ingress side is some magic, IMO. >=20 > Sri, sorry for intervening on this aspect. I wanted to mention: >=20 > This HNP Division approach is nothing magic, there are a number of other > proposals doing similar prefix division in order to deliver further in a > network. >=20 > The other comment is that our method of achieving network mobility with > PMIP and DHCP Prefix Delegation works without the above HNP prefix > division. The two methods are alternative - do HNP Division and no need > of Prefix Delegation, do Prefix Delegation and no need of HNP Division. >=20 No. Prefix Delegation per RFC 3633, allows a node to request a prefix and h= ost that prefix on its ingress links. The model support RR and DR functions= ; it is based on a standard model of prefix delegation. The change is to su= pport mobile environment. The approach of learning a prefix "hosted on a link", and claiming ownershi= p of some art of the prefix as supposed to claiming ownership on an address= is a new concept. FWIW, the router never delegated that prefix and it neve= r allowed it to be any other link, other than that link. So, there is a wor= ld of difference. Analogy is ilke this. You rented a taxi, on the way you s= tarted offering taxi service :). Also, please explain: a. how SLAAC works b. how SEND is enabled=20 c. how a host on a link operating in SLAAC mode, can learn a prefix in the = RA, claim ownership on part of the prefix and in turn host that prefix on t= he ingress link d. if SLAAC is disabled and DHCPv6 stageful mode is supported on the MAG-MN= link, what happens to your proposal >> This technique, if legal, valid and works for SLAAC, SEND, can be a >> generic technique useful for wireless and wireless. Nothing specific >> to mobility. >=20 > Well we do it for network mobility and not for generic technique. I am > afraid that if you submit now a draft doing network mobility in PMIP any > other subsequent network mobility PMIP submission will have to face the > question of why we do it again. >=20 The WG document went through a long review process and was adopted after an= adoption call. You have a new idea now, but in all "fairness", we cannot h= ijack an IETF WG document, with the fear that some future work of ours will= have some questions. That is not right. If your approach has merit, has su= pport from the WG, you can always publish an alternative approach. Or, even= deprecate a standard. You can request the chairs to Ask for reviews and WG= adoption. If there is consensus, it will get approved. Again, Xingue's WG = draft is not stopping you from achieving this. > Or, the question now is why is PMIP-Prefix Delegation claiming to do > network mobility and not do network mobility at the same time? My > supposition is that authors claim to the WG that authors do not do > network mobility and authors claim to elsewhere that authors _do_ > network mobility. >=20 I do not know where to go if we start arguing about the definitions of MR, = MH, IP Node =85 We do adding prefix delegation to PMIP sessions. The ability to support PD = support per DHCPv6 is what we are supporting. > Well, we do not consider neither NAT, nor changing MAC addresses aka ND > proxy, other than maybe tangential - these are not core to our PMIP-NEMO > proposals >=20 > The manner we propose by which a HNP can be subdivided into several MNPs > is none of these. You do. Draft text: "For this reason, the MR must pretend it owns the IP address of LFN and res= pond to that solicitation with its own MAC address." > The manner we propose by which a HNP can be subdivided into several MNPs > is none of these. I know this discussion won't end and you will thoroughly enjoy this discuss= ions :). But, to make progress,=20 Please explain how your draft works and get WG support. Note that Xingyue's= draft is not your blocker. My final comment, please ask the chairs to request WG adoption on your draf= t. Regards Sri From alexandru.petrescu@gmail.com Thu Jul 12 07:34:06 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 C292C21F87CC for ; Thu, 12 Jul 2012 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.66 X-Spam-Level: X-Spam-Status: No, score=-8.66 tagged_above=-999 required=5 tests=[AWL=1.589, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AWQnRKK2PIle for ; Thu, 12 Jul 2012 07:34:05 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id EB7C121F87C1 for ; Thu, 12 Jul 2012 07:34:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CEYZgZ021647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 16:34:35 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CEYZZE007755; Thu, 12 Jul 2012 16:34:35 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CEYViu018532; Thu, 12 Jul 2012 16:34:34 +0200 Message-ID: <4FFEE077.7030005@gmail.com> Date: Thu, 12 Jul 2012 16:34:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> <4FFEB987.8050608@gmail.com> <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> In-Reply-To: <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 14:34:06 -0000 Sri, Le 12/07/2012 15:27, Sri Gundavelli (sgundave) a écrit : > Alex: > > On Jul 12, 2012, at 4:48 AM, Alexandru Petrescu wrote: > >> Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : [...] >>> In any case, you want WG reviews on all the assumptions that your >>> draft is making. The approach of an host learning a Prefix in RA >>> and hosting a part of the prefix on its ingress side is some >>> magic, IMO. >> >> Sri, sorry for intervening on this aspect. I wanted to mention: >> >> This HNP Division approach is nothing magic, there are a number of >> other proposals doing similar prefix division in order to deliver >> further in a network. >> >> The other comment is that our method of achieving network mobility >> with PMIP and DHCP Prefix Delegation works without the above HNP >> prefix division. The two methods are alternative - do HNP >> Division and no need of Prefix Delegation, do Prefix Delegation and >> no need of HNP Division. >> > > No. Prefix Delegation per RFC 3633, allows a node to request a > prefix and host that prefix on its ingress links. The model support > RR and DR functions; it is based on a standard model of prefix > delegation. The change is to support mobile environment. I suppose you want to mean that a mobile environment is exclusively PMIP? This would be to claim more than necessary, no? MIP is also mobile, DHCP is also mobile. > The approach of learning a prefix "hosted on a link", and claiming > ownership of some art of the prefix as supposed to claiming > ownership on an address is a new concept. FWIW, the router never > delegated that prefix and it never allowed it to be any other link, > other than that link. So, there is a world of difference. Analogy is > ilke this. You rented a taxi, on the way you started offering taxi > service :). I tend to agree with your description, in the WiFi case. Yes, a router receiving an RA containing a prefix, and extracting a part of it for use in its ingress interface would be more than what the semantics of a RFC RA is. In practice, e.g. on WiFi, a router receiving an RA even if it would be able to use parts of it on its ingress interface, the access router which provided that prefix does not have a routing table entry for it, so the entities on the ingress would not work. On another hand, still in practice, a cellular link "no-ARP" would not suffer of this shortcoming. The route for HNP on the access router is a connected route and has no next-hop. In this sense, it is very well possible on cellular link (wireless, mobility) to use this HDNP division; and without doing ND proxy. It is also possible to try to specify extensions to RA such that this prefix in it has additional semantics, like "Type 200" means "prefix to be used further down the line" - a kind of prefix delegation with ND. We work on it as well. But even without this ND PD, the HNP Division can work well on cellular links to offer network mobility. > Also, please explain: > > a. how SLAAC works There may be an issue on how SLAAC works, on the ingress interface. If the HNP is /64 then HNP division would obviously offer an MNP at /65 or longer. And because Ethernet IIDs are 64 length and addresses are 128, there is obviously an issue here. But there are solutions to that. For example, if one uses LFNs in the moving network which are not Ethernet (IID of length shorter than 64), then SLAAC works with a MNP /65. Or otherwise don't use SLAAC on ingress, but use DHCP. I don't see other issues. Is this what you meant? > b. how SEND is enabled Should be checked. I don't see it as impossible. > c. how a host on a link operating in SLAAC mode, can learn a prefix > in the RA, claim ownership on part of the prefix and in turn host > that prefix on the ingress link Works on cellular links. > d. if SLAAC is disabled and DHCPv6 stageful mode is supported on the > MAG-MN link, what happens to your proposal If SLAAC is disabled and DHCPv6 is used on the MAG-MN link then DHCPv6 Prefix Delegation should be used. In this case, HNP Division has maybe less place here. But the way in which you propose the use of Prefix Delegation has some problems: what do you set in the MNID of a PBU provoked by the DHCP Request? (DHCP Request does not contain MNID). Alex > > >>> This technique, if legal, valid and works for SLAAC, SEND, can >>> be a generic technique useful for wireless and wireless. Nothing >>> specific to mobility. >> >> Well we do it for network mobility and not for generic technique. I >> am afraid that if you submit now a draft doing network mobility in >> PMIP any other subsequent network mobility PMIP submission will >> have to face the question of why we do it again. >> > > The WG document went through a long review process and was adopted > after an adoption call. You have a new idea now, but in all > "fairness", we cannot hijack an IETF WG document, with the fear that > some future work of ours will have some questions. That is not right. > If your approach has merit, has support from the WG, you can always > publish an alternative approach. Or, even deprecate a standard. You > can request the chairs to Ask for reviews and WG adoption. If there > is consensus, it will get approved. Again, Xingue's WG draft is not > stopping you from achieving this. > > >> Or, the question now is why is PMIP-Prefix Delegation claiming to >> do network mobility and not do network mobility at the same time? >> My supposition is that authors claim to the WG that authors do not >> do network mobility and authors claim to elsewhere that authors >> _do_ network mobility. >> > > I do not know where to go if we start arguing about the definitions > of MR, MH, IP Node … We do adding prefix delegation to PMIP > sessions. The ability to support PD support per DHCPv6 is what we > are supporting. > > > >> Well, we do not consider neither NAT, nor changing MAC addresses >> aka ND proxy, other than maybe tangential - these are not core to >> our PMIP-NEMO proposals >> >> The manner we propose by which a HNP can be subdivided into >> several MNPs is none of these. > > You do. Draft text: > > "For this reason, the MR must pretend it owns the IP address of LFN > and respond to that solicitation with its own MAC address." > > > >> The manner we propose by which a HNP can be subdivided into >> several MNPs is none of these. > > > > I know this discussion won't end and you will thoroughly enjoy this > discussions :). But, to make progress, Please explain how your draft > works and get WG support. Note that Xingyue's draft is not your > blocker. My final comment, please ask the chairs to request WG > adoption on your draft. > > > > > > Regards Sri > > > > > > From alexandru.petrescu@gmail.com Thu Jul 12 07:56:10 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 39BC121F87B3 for ; Thu, 12 Jul 2012 07:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.766 X-Spam-Level: X-Spam-Status: No, score=-8.766 tagged_above=-999 required=5 tests=[AWL=1.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6MwPU6aKkHKO for ; Thu, 12 Jul 2012 07:56:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 538E621F877A for ; Thu, 12 Jul 2012 07:56:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CEughG030695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Jul 2012 16:56:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CEufM3015990 for ; Thu, 12 Jul 2012 16:56:41 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CEucbs030505 for ; Thu, 12 Jul 2012 16:56:41 +0200 Message-ID: <4FFEE5A6.7040600@gmail.com> Date: Thu, 12 Jul 2012 16:56:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: netext@ietf.org References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> <4FFEB987.8050608@gmail.com> <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> <4FFEE077.7030005@gmail.com> In-Reply-To: <4FFEE077.7030005@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 14:56:10 -0000 Sri, Le 12/07/2012 16:34, Alexandru Petrescu a écrit : > Sri, > > Le 12/07/2012 15:27, Sri Gundavelli (sgundave) a écrit : >> Alex: >> >> On Jul 12, 2012, at 4:48 AM, Alexandru Petrescu wrote: >> >>> Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : [...] [...] >> The WG document went through a long review process and was adopted >> after an adoption call. But any Last Call? (the adoption call was July 2011; some of the comments at mic at that time was about working on a problem statement - that happens now). >> You have a new idea now, but in all "fairness", we cannot hijack an >> IETF WG document, with the fear that some future work of ours will >> have some questions. That is not right. If your approach has merit, >> has support from the WG, you can always publish an alternative >> approach. Or, even deprecate a standard. You can request the chairs >> to Ask for reviews and WG adoption. If there is consensus, it will >> get approved. Again, Xingue's WG draft is not stopping you from >> achieving this. Well, of course half empty is not half full and hijacking is not good. But one would not submit a draft to IESG when: - competitor exists - LC is not there - implementation and IPR are not mentioned. Or? Alex >>> Or, the question now is why is PMIP-Prefix Delegation claiming >>> to do network mobility and not do network mobility at the same >>> time? My supposition is that authors claim to the WG that authors >>> do not do network mobility and authors claim to elsewhere that >>> authors _do_ network mobility. >>> >> >> I do not know where to go if we start arguing about the >> definitions of MR, MH, IP Node … We do adding prefix delegation to >> PMIP sessions. The ability to support PD support per DHCPv6 is what >> we are supporting. >> >> >> >>> Well, we do not consider neither NAT, nor changing MAC addresses >>> aka ND proxy, other than maybe tangential - these are not core >>> to our PMIP-NEMO proposals >>> >>> The manner we propose by which a HNP can be subdivided into >>> several MNPs is none of these. >> >> You do. Draft text: >> >> "For this reason, the MR must pretend it owns the IP address of >> LFN and respond to that solicitation with its own MAC address." >> >> >> >>> The manner we propose by which a HNP can be subdivided into >>> several MNPs is none of these. >> >> >> >> I know this discussion won't end and you will thoroughly enjoy >> this discussions :). But, to make progress, Please explain how your >> draft works and get WG support. Note that Xingyue's draft is not >> your blocker. My final comment, please ask the chairs to request >> WG adoption on your draft. >> >> >> >> >> >> Regards Sri >> >> >> >> >> >> > > > > _______________________________________________ netext mailing list > netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > > From alexandru.petrescu@gmail.com Thu Jul 12 08:04:43 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 E3DEE21F876E for ; Thu, 12 Jul 2012 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.858 X-Spam-Level: X-Spam-Status: No, score=-8.858 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 otL4Sdvc-BgZ for ; Thu, 12 Jul 2012 08:04:43 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 07BDF21F86F1 for ; Thu, 12 Jul 2012 08:04:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CF5Cmf032002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 17:05:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CF5CtH019175; Thu, 12 Jul 2012 17:05:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CF5BTn003537; Thu, 12 Jul 2012 17:05:11 +0200 Message-ID: <4FFEE7A7.2090406@gmail.com> Date: Thu, 12 Jul 2012 17:05:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: , <4FFD9580.9070703@gmail.com> <94D2EEADE1F74740979E8041CBA3393803559D17@EXDAG0-B3.intra.cea.fr> <3B51081E-10E4-41B2-85DD-36DF487D8B71@cisco.com> <94D2EEADE1F74740979E8041CBA3393803559E07@EXDAG0-B3.intra.cea.fr> <4FFEB987.8050608@gmail.com> <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> In-Reply-To: <5E622143-2D41-4220-9940-69AE309799FE@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:04:44 -0000 Le 12/07/2012 15:27, Sri Gundavelli (sgundave) a écrit : > On Jul 12, 2012, at 4:48 AM, Alexandru Petrescu wrote: > >> Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : [...] >> Well, we do not consider neither NAT, nor changing MAC addresses >> aka ND proxy, other than maybe tangential - these are not core to >> our PMIP-NEMO proposals >> >> The manner we propose by which a HNP can be subdivided into several >> MNPs is none of these. > > You do. Draft text: > > "For this reason, the MR must pretend it owns the IP address of LFN > and respond to that solicitation with its own MAC address." Right, but that is only in the case of 'shared' links like WiFi. In the case of ptp wireless links like cellular links "it is not necessary to add any additional behaviour for MR to work (LFN to be reachable from CN). It is sufficient for MR to perform HNP division [...]" >> The manner we propose by which a HNP can be subdivided into several >> MNPs is none of these. > > > > I know this discussion won't end and you will thoroughly enjoy this > discussions :). :-) well I am trying to enjoy more... only if we could have agreed on this logical interface draft. But it's dropped :-( > But, to make progress, Please explain how your draft works and get > WG support. I would like to get an opportunity to present at the face-to-face meeting if possible. Maybe 5 minutes presentation of PMIP-NEMO à la petrescu-boc-janneteau may help clarify? > Note that Xingyue's draft is not your blocker. This is something we could try to identify. I personally strongly believe that if WG delivers to IESG now a draft doing network mobility with PMIP then that's done - any future try is going to face this need to answer _why_ network mobility with PMIP again, do it once and only one way, etc. This is something we could ask others oppinions: do you think that other PMIP-NEMO solution drafts are possible if we submit now draft-ietf-netext-pd-pmip-02 to IESG? What do you think? > My final comment, please ask the chairs to request WG adoption on > your draft. I would like to but I believe it may be too early? It has never been presented to a face-to-face WG session... Alex > > > > > > Regards Sri > > > > > > From Basavaraj.Patil@nokia.com Thu Jul 12 08:07:23 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 73AF621F877E for ; Thu, 12 Jul 2012 08:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 AtF3UKJ0vWr7 for ; Thu, 12 Jul 2012 08:07:22 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A3CF521F87CC for ; Thu, 12 Jul 2012 08:07:21 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6CF6utf031194; Thu, 12 Jul 2012 18:07:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 18:07:31 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Thu, 12 Jul 2012 17:07:04 +0200 From: To: , Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNYD6RO6j90wULb0G/s53AUsvO35clSq6A Date: Thu, 12 Jul 2012 15:07:03 +0000 Message-ID: In-Reply-To: <4FFEE5A6.7040600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.36] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9D86EEDBECF022479271EDB0226E6B26@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2012 15:07:31.0452 (UTC) FILETIME=[0F4D73C0:01CD6040] X-Nokia-AV: Clean Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:07:23 -0000 Alex, The I-D is ready for WG LC and will be issued shortly. I-D authors are expected to follow IETFs IPR policies and I would expect the same for the WGs P-D I-D. -Raj On 7/12/12 9:56 AM, "ext Alexandru Petrescu" wrote: >Sri, > >Le 12/07/2012 16:34, Alexandru Petrescu a =E9crit : >> Sri, >> >> Le 12/07/2012 15:27, Sri Gundavelli (sgundave) a =E9crit : >>> Alex: >>> >>> On Jul 12, 2012, at 4:48 AM, Alexandru Petrescu wrote: >>> >>>> Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a =E9crit : [...] >[...] >>> The WG document went through a long review process and was adopted >>> after an adoption call. > >But any Last Call? > >(the adoption call was July 2011; some of the comments at mic at that >time was about working on a problem statement - that happens now). > >>> You have a new idea now, but in all "fairness", we cannot hijack an >>> IETF WG document, with the fear that some future work of ours will >>> have some questions. That is not right. If your approach has merit, >>> has support from the WG, you can always publish an alternative >>> approach. Or, even deprecate a standard. You can request the chairs >>> to Ask for reviews and WG adoption. If there is consensus, it will >>> get approved. Again, Xingue's WG draft is not stopping you from >>> achieving this. > >Well, of course half empty is not half full and hijacking is not good. > >But one would not submit a draft to IESG when: >- competitor exists >- LC is not there >- implementation and IPR are not mentioned. > >Or? > >Alex > >>>> Or, the question now is why is PMIP-Prefix Delegation claiming >>>> to do network mobility and not do network mobility at the same >>>> time? My supposition is that authors claim to the WG that authors >>>> do not do network mobility and authors claim to elsewhere that >>>> authors _do_ network mobility. >>>> >>> >>> I do not know where to go if we start arguing about the >>> definitions of MR, MH, IP Node =8A We do adding prefix delegation to >>> PMIP sessions. The ability to support PD support per DHCPv6 is what >>> we are supporting. >>> >>> >>> >>>> Well, we do not consider neither NAT, nor changing MAC addresses >>>> aka ND proxy, other than maybe tangential - these are not core >>>> to our PMIP-NEMO proposals >>>> >>>> The manner we propose by which a HNP can be subdivided into >>>> several MNPs is none of these. >>> >>> You do. Draft text: >>> >>> "For this reason, the MR must pretend it owns the IP address of >>> LFN and respond to that solicitation with its own MAC address." >>> >>> >>> >>>> The manner we propose by which a HNP can be subdivided into >>>> several MNPs is none of these. >>> >>> >>> >>> I know this discussion won't end and you will thoroughly enjoy >>> this discussions :). But, to make progress, Please explain how your >>> draft works and get WG support. Note that Xingyue's draft is not >>> your blocker. My final comment, please ask the chairs to request >>> WG adoption on your draft. >>> >>> >>> >>> >>> >>> Regards Sri >>> >>> >>> >>> >>> >>> >> >> >> >> _______________________________________________ netext mailing list >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >> >> > > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Jul 12 08:09:10 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 C4E8E21F87B8 for ; Thu, 12 Jul 2012 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 EprW3QLiFBTn for ; Thu, 12 Jul 2012 08:09:10 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E497421F87B6 for ; Thu, 12 Jul 2012 08:09:09 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6CF8vZD010840; Thu, 12 Jul 2012 18:09:25 +0300 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, 12 Jul 2012 18:09:32 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Thu, 12 Jul 2012 17:09:06 +0200 From: To: , Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cLnd1kS0xrWkKZfe1DwH3taZclSEGAgAAJIoCAABYCgIAAG44AgAAbb4D//63VAA== Date: Thu, 12 Jul 2012 15:09:05 +0000 Message-ID: In-Reply-To: <4FFEE7A7.2090406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.36] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <67DAE2D55EE3374BA6DDD80789F27955@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2012 15:09:32.0866 (UTC) FILETIME=[57ABC220:01CD6040] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:09:10 -0000 Alex, On 7/12/12 10:05 AM, "ext Alexandru Petrescu" wrote: > >I would like to get an opportunity to present at the face-to-face >meeting if possible. Maybe 5 minutes presentation of PMIP-NEMO =E0 la >petrescu-boc-janneteau may help clarify? If you need an agenda slot to present your I-D and make the case to the WG, please submit a request. See: http://www.ietf.org/mail-archive/web/netext/current/msg02537.html -Raj From alexandru.petrescu@gmail.com Thu Jul 12 08:18:05 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 BBF5C21F859E for ; Thu, 12 Jul 2012 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.94 X-Spam-Level: X-Spam-Status: No, score=-8.94 tagged_above=-999 required=5 tests=[AWL=1.309, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 al0-4lTbOBRy for ; Thu, 12 Jul 2012 08:18:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2587921F8539 for ; Thu, 12 Jul 2012 08:18:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CFIYTw003827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 17:18:34 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CFIYir023528; Thu, 12 Jul 2012 17:18:34 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CFIUU1009671; Thu, 12 Jul 2012 17:18:34 +0200 Message-ID: <4FFEEAC6.1050901@gmail.com> Date: Thu, 12 Jul 2012 17:18:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: netext-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] Soliciting agenda items for IETF 84 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, 12 Jul 2012 15:18:05 -0000 Dear Rajeev, Raj, I request a short slot to present my I-D and make the case to the WG: 1. draft-petrescu-netext-pmip-nemo-01.txt 2. This draft is relevant to the Netext WG Charter which accommodates the following WG item: draft-ietf-netext-pd-pmip 3. 5 to 10 minutes. Yours, Alex > > Hello, > > The Netext WG is scheduled to meet at IETF84 on August 2, 2012 from 1300 - 1500. > > If you need an agenda slot at the WG meeting, please send a request to the > chairs (netext-chairs at tools.ietf.org) > > Please indicate: > > 1. Name of the I-D > 2. Relevance to the Netext WG charter > 3. Amount of time needed > > > Thanks. > > -Chairs Le 10/07/2012 06:41, Rajeev Koodli (rkoodli) a écrit : From Basavaraj.Patil@nokia.com Thu Jul 12 08:19:46 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 6326721F87E6 for ; Thu, 12 Jul 2012 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 hj3IFYOwmW4L for ; Thu, 12 Jul 2012 08:19:45 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B925A21F85A4 for ; Thu, 12 Jul 2012 08:19:45 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6CFK65j013920; Thu, 12 Jul 2012 18:20:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 18:20:32 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Thu, 12 Jul 2012 17:20:05 +0200 From: To: , Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cLnd1kS0xrWkKZfe1DwH3taZclSEGAgAAJIoCAABYCgIAAG44AgAAbb4D//7DjAA== Date: Thu, 12 Jul 2012 15:20:04 +0000 Message-ID: In-Reply-To: <4FFEE7A7.2090406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.36] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2012 15:20:32.0415 (UTC) FILETIME=[E0CAF2F0:01CD6041] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:19:46 -0000 Hi Alex, On 7/12/12 10:05 AM, "ext Alexandru Petrescu" wrote: > >This is something we could try to identify. I personally strongly >believe that if WG delivers to IESG now a draft doing network mobility >with PMIP then that's done - any future try is going to face this need >to answer _why_ network mobility with PMIP again, do it once and only >one way, etc. > >This is something we could ask others oppinions: do you think that other >PMIP-NEMO solution drafts are possible if we submit now >draft-ietf-netext-pd-pmip-02 to IESG? > >What do you think? The WG has worked on the P-D solution as specified in draft-ietf-netext-pd-pmip for a while now. Is the solution broken? I do not believe so. If the WG members are in favor of the solution proposed in this I-D, then the chairs will issue a WG LC and forward it to the IESG. The WG is not limited to standardizing a single solution only for network mobility. And hence if your ideas proposed in the I-D have traction, the WG could take up that work as well. Your fears that the work would stop is unfounded. -Raj > >> My final comment, please ask the chairs to request WG adoption on >> your draft. > >I would like to but I believe it may be too early? It has never been >presented to a face-to-face WG session... > >Alex > >> >> >> >> >> >> Regards Sri >> >> >> >> >> >> > > > From alexandru.petrescu@gmail.com Thu Jul 12 08:28:29 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 4A34721F85E3 for ; Thu, 12 Jul 2012 08:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[AWL=-2.764, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 V6MlHcuN3Gt5 for ; Thu, 12 Jul 2012 08:28:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 697C421F85DF for ; Thu, 12 Jul 2012 08:28:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6CFSune004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 17:28:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6CFStKJ026437; Thu, 12 Jul 2012 17:28:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6CFSqSv014011; Thu, 12 Jul 2012 17:28:55 +0200 Message-ID: <4FFEED34.4040808@gmail.com> Date: Thu, 12 Jul 2012 17:28:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:28:29 -0000 Le 12/07/2012 17:20, Basavaraj.Patil@nokia.com a écrit : > > Hi Alex, > > On 7/12/12 10:05 AM, "ext Alexandru Petrescu" > wrote: >> >> This is something we could try to identify. I personally strongly >> believe that if WG delivers to IESG now a draft doing network >> mobility with PMIP then that's done - any future try is going to >> face this need to answer _why_ network mobility with PMIP again, do >> it once and only one way, etc. >> >> This is something we could ask others oppinions: do you think that >> other PMIP-NEMO solution drafts are possible if we submit now >> draft-ietf-netext-pd-pmip-02 to IESG? >> >> What do you think? > > The WG has worked on the P-D solution as specified in > draft-ietf-netext-pd-pmip for a while now. Is the solution broken? I > do not believe so. If the WG members are in favor of the solution > proposed in this I-D, then the chairs will issue a WG LC and forward > it to the IESG. The WG is not limited to standardizing a single > solution only for network mobility. And hence if your ideas proposed > in the I-D have traction, the WG could take up that work as well. > Your fears that the work would stop is unfounded. Raj, Half of the solution we propose is too close to the WG item: allocate a prefix with DHCPv6-PD, and PMIP, such that to support network mobility. (the other half - HNP division is more different). In the details, we believe our implementation to be better and the message sequence are different. For example, our MAG would not interoperate with WG item's LMA. And we need a DHCPv6 Server whereas WG item works _without_ a DHCPv6 Server. These are all variants of a single solution. If this WG item goes to IESG then half of our draft is dead. (the other half - HNP Division - may still live, trying to do network mobility without modifying DHCP, nor PMIP). In my experience, it is very hard to convince a WG to do new work again. The WG item's most prominent proponents will backfire very strongly about any new proposal doing the same thing. This is why I complain about the use of the term 'network mobility' in the existing draft. Were it to say that the existing WG item draft does just 'prefix delegation' then maybe it could go. But its current aim is particularly clear, and it is not 'prefix delegation'. Also, there is this work on the problem statement of network mobility draft... it seems decoupled from the WG item solution. Yours, Alex > > -Raj > >> >>> My final comment, please ask the chairs to request WG adoption >>> on your draft. >> >> I would like to but I believe it may be too early? It has never >> been presented to a face-to-face WG session... >> >> Alex >> >>> >>> >>> >>> >>> >>> Regards Sri >>> >>> >>> >>> >>> >>> >> >> >> > > > From Basavaraj.Patil@nokia.com Thu Jul 12 08:40:13 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 4A7A611E80C4 for ; Thu, 12 Jul 2012 08:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 gLb--9dsuB6Y for ; Thu, 12 Jul 2012 08:40:12 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 96D5311E80D3 for ; Thu, 12 Jul 2012 08:40:11 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6CFeOAU012230; Thu, 12 Jul 2012 18:40:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 18:40:51 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Thu, 12 Jul 2012 17:40:24 +0200 From: To: Thread-Topic: [netext] Milestone update for NetExt WG Thread-Index: AQHNX8cLnd1kS0xrWkKZfe1DwH3taZclSEGAgAAJIoCAABYCgIAAG44AgAAbb4D//7DjAIAAVboA//+v9oA= Date: Thu, 12 Jul 2012 15:40:23 +0000 Message-ID: In-Reply-To: <4FFEED34.4040808@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.36] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <85CD1445C4135148AAE7ADF46A15A7E8@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2012 15:40:51.0211 (UTC) FILETIME=[B74075B0:01CD6044] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Milestone update for NetExt WG 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, 12 Jul 2012 15:40:13 -0000 If the PD part of the I-Ds are the same, then you will need to justify the advantages of your solution or identify issues with those specified in the WG document. =20 As you stated, "these are variants of a single solution". The WG has decided to proceed with one approach and there is consensus on that.=20 What you are proposing is an alternative approach which needs to be evaluated by the WG to determine what to do with it. Since you have requested an agenda slot at IETF84, you will get an opportunity to make the case to the WG. -Raj On 7/12/12 10:28 AM, "ext Alexandru Petrescu" wrote: >Le 12/07/2012 17:20, Basavaraj.Patil@nokia.com a =E9crit : >> >> Hi Alex, >> >> On 7/12/12 10:05 AM, "ext Alexandru Petrescu" >> wrote: >>> >>> This is something we could try to identify. I personally strongly >>> believe that if WG delivers to IESG now a draft doing network >>> mobility with PMIP then that's done - any future try is going to >>> face this need to answer _why_ network mobility with PMIP again, do >>> it once and only one way, etc. >>> >>> This is something we could ask others oppinions: do you think that >>> other PMIP-NEMO solution drafts are possible if we submit now >>> draft-ietf-netext-pd-pmip-02 to IESG? >>> >>> What do you think? >> >> The WG has worked on the P-D solution as specified in >> draft-ietf-netext-pd-pmip for a while now. Is the solution broken? I >> do not believe so. If the WG members are in favor of the solution >> proposed in this I-D, then the chairs will issue a WG LC and forward >> it to the IESG. The WG is not limited to standardizing a single >> solution only for network mobility. And hence if your ideas proposed >> in the I-D have traction, the WG could take up that work as well. >> Your fears that the work would stop is unfounded. > >Raj, > >Half of the solution we propose is too close to the WG item: allocate a >prefix with DHCPv6-PD, and PMIP, such that to support network mobility. >(the other half - HNP division is more different). > >In the details, we believe our implementation to be better and the >message sequence are different. For example, our MAG would not >interoperate with WG item's LMA. And we need a DHCPv6 Server whereas WG >item works _without_ a DHCPv6 Server. > >These are all variants of a single solution. If this WG item goes to >IESG then half of our draft is dead. (the other half - HNP Division - >may still live, trying to do network mobility without modifying DHCP, >nor PMIP). > >In my experience, it is very hard to convince a WG to do new work again. > The WG item's most prominent proponents will backfire very strongly >about any new proposal doing the same thing. > >This is why I complain about the use of the term 'network mobility' in >the existing draft. Were it to say that the existing WG item draft does >just 'prefix delegation' then maybe it could go. But its current aim is >particularly clear, and it is not 'prefix delegation'. > >Also, there is this work on the problem statement of network mobility >draft... it seems decoupled from the WG item solution. > >Yours, > >Alex > >> >> -Raj >> >>> >>>> My final comment, please ask the chairs to request WG adoption >>>> on your draft. >>> >>> I would like to but I believe it may be too early? It has never >>> been presented to a face-to-face WG session... >>> >>> Alex >>> >>>> >>>> >>>> >>>> >>>> >>>> Regards Sri >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From sarikaya2012@gmail.com Thu Jul 12 14:45:45 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 A402611E811B for ; Thu, 12 Jul 2012 14:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 W2LwNYdFJiMb for ; Thu, 12 Jul 2012 14:45:45 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CD11E80BB for ; Thu, 12 Jul 2012 14:45:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3211240ghb.31 for ; Thu, 12 Jul 2012 14:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=AlmngpIUQHNY93Yb9ELpGU9YOE8s28+ezklStDHeBCs=; b=r9dF1zexvSctNCKpa5BM4JM2usYOFsBIsP3s/quYi8dvA0uYvLmMIGOK8H3XzhdCW+ bmBTQNwjItEQ7jtHs+lf6+zQ+CXiWs4W4eJ8kbf9OWyd8imAE2oIzTglJtUGbQ5F4xM6 L00Tf8GXT+CtJlQP9uHkvRxm0xeHFGtloLP3I/FUkjZexeeQT72uALkpa4YTzRqe9b7j d95GuQGQc1/NHbHPzqUoq+/j9QVR/OcOwTM0wQYAb4Vsq/ydw3jLV9PzOUH2+59xxEaq TZ1hdGUrv1Nz450AHps5Ql3K5DUwdYxqyetYtre0Ke6n29ZbNbBmL99cj+5/QG3t15tl IoVg== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr19156039igc.63.1342129579009; Thu, 12 Jul 2012 14:46:19 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 12 Jul 2012 14:46:18 -0700 (PDT) In-Reply-To: <20120712214448.16522.88929.idtracker@ietfa.amsl.com> References: <20120712214448.16522.88929.idtracker@ietfa.amsl.com> Date: Thu, 12 Jul 2012 16:46:18 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] Fwd: New Version Notification for draft-sarikaya-netext-pmipv6-shared-link-01.txt 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:45:45 -0000 A new version of I-D, draft-sarikaya-netext-pmipv6-shared-link-01.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-netext-pmipv6-shared-link Revision: 01 Title: PMIPv6 Operation on Shared Links Creation date: 2012-07-12 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-netext-pmipv6-shared-link-01.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-netext-pmipv6-shared-link Htmlized: http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-netext-pmipv6-shared-link-01 Abstract: This document describes Proxy Mobile IPv6 (PMIPv6) operation on shared links such as IEEE 802.11. Two solutions of providing point- to-point link operation on the shared links are compared. Advantages and disadvantages of each solution are identified. Issues related to the placement of Mobile Access Gateway (MAG) in fixed broadband network are also discussed. The IETF Secretariat From alexandru.petrescu@gmail.com Fri Jul 13 02:23:10 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 ADCF121F84F6 for ; Fri, 13 Jul 2012 02:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.867 X-Spam-Level: X-Spam-Status: No, score=-8.867 tagged_above=-999 required=5 tests=[AWL=1.382, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 TEwIHS2vYWf1 for ; Fri, 13 Jul 2012 02:23:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 974E421F84F4 for ; Fri, 13 Jul 2012 02:23:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6D9Ni5H010892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Jul 2012 11:23:44 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6D9NhGx028289 for ; Fri, 13 Jul 2012 11:23:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6D9NhoK003584 for ; Fri, 13 Jul 2012 11:23:43 +0200 Message-ID: <4FFFE91F.8030006@gmail.com> Date: Fri, 13 Jul 2012 11:23:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] PMIP purists - is PMIP-NEMO impossible? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 09:23:11 -0000 NETEXT WG members, It was said at times that PMIP-NEMO is impossible. PMIP is a core network protocol, where mobility is supported without modifying the MN. Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it adds DHCP Client on it; or other times it performs HNP Division. BEcause of this there exist statements that PMIP-NEMO is impossible. Do you think there are other reasons why PMIP-NEMO is impossible? Do you think that running DHCP Client on MN is a modification to MN? Alex From sgundave@cisco.com Fri Jul 13 03:02:45 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 8649421F86AA for ; Fri, 13 Jul 2012 03:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 8KpDbTQ8fBlE for ; Fri, 13 Jul 2012 03:02:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A944A21F86A8 for ; Fri, 13 Jul 2012 03:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1710; q=dns/txt; s=iport; t=1342173800; x=1343383400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m/p1s/JvUhvinoKa3AOO7jX9egQSRgTP2G7BLMEFN6A=; b=iuhRSZxioQoZpbi2D/I/fAydVamPcWF00ByU0yLnyF5PZ8DeRlcqYiuj 8Sxy3MhwK68p9k66Ahq0un4f/6/H4nww+qs4XRP34cNkuxhLVy9Va6awp CcXHrAzSK/kpPRenrXVVhgXo6RAESDgoFGyvt91os154sh+lG9u4xW/pT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEDx/0+tJV2Z/2dsb2JhbABFuB6BB4IgAQEBAwEBAQEPASc0CwULAgEINhAnCyUCBA4FIodlBgubMaATBIs8hRZgA5U6jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208";a="101536829" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jul 2012 10:03:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6DA3JIX017444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 10:03:19 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 05:03:19 -0500 From: "Sri Gundavelli (sgundave)" To: Alexandru Petrescu Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? Thread-Index: AQHNYNk41DDwxEC9MEKKPEnLuUBjrZcnT5IA Date: Fri, 13 Jul 2012 10:03:19 +0000 Message-ID: References: <4FFFE91F.8030006@gmail.com> In-Reply-To: <4FFFE91F.8030006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.213] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.006 x-tm-as-result: No--33.179400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 10:02:45 -0000 Alex: 1.) For allowing a mobile node to obtain an IPv4 address, it requires DHCPv= 4 client functionality based on RFC-2131. This is already assumed in RFC-58= 44. 2.) For allowing a mobile router to obtains a delegated IPv6 prefix, it req= uires DHCPv6 client functionality based on RFC-3315/RFC-3633, so it can obt= ains a delegated prefix. In either of the above cases, we are not "changing" the client. We are requ= iring standard DHCP client functionality for obtaining address configuratio= n.=20 Now, we should really move the discussions to focus on the proposal you hav= e. Ignoring, if we require a client change, or not, we need to analyze this= idea of address splitting. If SLAAC can be enabled on that and if there ar= e no issues, the approach can be relevant for DSMIP based systems, PMIP-bas= ed, both, wireline, or all/none. We can focus on the procedural aspects lat= er. Regards Sri On Jul 13, 2012, at 2:23 AM, Alexandru Petrescu wrote: > NETEXT WG members, >=20 > It was said at times that PMIP-NEMO is impossible. PMIP is a core > network protocol, where mobility is supported without modifying the MN. >=20 > Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it > adds DHCP Client on it; or other times it performs HNP Division. >=20 > BEcause of this there exist statements that PMIP-NEMO is impossible. >=20 > Do you think there are other reasons why PMIP-NEMO is impossible? >=20 > Do you think that running DHCP Client on MN is a modification to MN? >=20 > Alex >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Fri Jul 13 05:08:21 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 4768E21F8648 for ; Fri, 13 Jul 2012 05:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 elFmxWIy+StX for ; Fri, 13 Jul 2012 05:08:19 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C65F21F85C9 for ; Fri, 13 Jul 2012 05:08:18 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6DC8pA5027086; Fri, 13 Jul 2012 15:08:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jul 2012 15:09:18 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Fri, 13 Jul 2012 14:08:50 +0200 From: To: , Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? Thread-Index: AQHNYNk4gAMYTdsgxkWSuCD0y/Yk0JcmqX0A Date: Fri, 13 Jul 2012 12:08:50 +0000 Message-ID: In-Reply-To: <4FFFE91F.8030006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2012 12:09:18.0757 (UTC) FILETIME=[545F6D50:01CD60F0] X-Nokia-AV: Clean Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:08:21 -0000 Alex, I don=B9t know where you have come across statements about PMIP-NEMO being impossible. Its just FUD. DHCP is an independent protocol and hence has no implications regarding network based mobility teams design of not modifying the MN. -Raj On 7/13/12 4:23 AM, "ext Alexandru Petrescu" wrote: >NETEXT WG members, > >It was said at times that PMIP-NEMO is impossible. PMIP is a core >network protocol, where mobility is supported without modifying the MN. > >Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it >adds DHCP Client on it; or other times it performs HNP Division. > >BEcause of this there exist statements that PMIP-NEMO is impossible. > >Do you think there are other reasons why PMIP-NEMO is impossible? > >Do you think that running DHCP Client on MN is a modification to MN? > >Alex > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From alexandru.petrescu@gmail.com Fri Jul 13 05:29:50 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 8961B21F8659 for ; Fri, 13 Jul 2012 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.937 X-Spam-Level: X-Spam-Status: No, score=-8.937 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 y0L2K7TuuM2u for ; Fri, 13 Jul 2012 05:29:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9242F21F85E3 for ; Fri, 13 Jul 2012 05:29:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6DCUOBk021604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 14:30:24 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6DCUOMg024076; Fri, 13 Jul 2012 14:30:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6DCULwa023163; Fri, 13 Jul 2012 14:30:24 +0200 Message-ID: <500014DD.2060107@gmail.com> Date: Fri, 13 Jul 2012 14:30:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:29:50 -0000 Raj, thank you for the reply. I agree mainly with you abou this: DHCP is an independent protocol. Alex Le 13/07/2012 14:08, Basavaraj.Patil@nokia.com a écrit : > > Alex, > > I don¹t know where you have come across statements about PMIP-NEMO > being impossible. It depends to what extent one allows for 'modifications' to MN, for an interpretation at your will of 'modification'. E.g. one is more easier tempted to believe that if ND is there then this is a normal node, but if one adds dhcpv6 then it's more like an added feature and a modification. (it's not the same as in the IPv4 world where DHCPv4 is always there). To this there may be made some remarks in the 3GPP context where apparently dhcpv6-pd is always there, but the picture is not that clear. > Its just FUD. 'FUD' - fear uncertainty and despair? I wouldn't qualify it so... there is some part of truth in it. In some context where I work we consider that the MN has no ND in it (being very simple) and adding ND in it is a 'modification'. > DHCP is an independent protocol and hence has no implications > regarding network based mobility teams design of not modifying the > MN. Yes but: adding DHCPv6 on a MN is considered as modification or not. Alex > > -Raj > > On 7/13/12 4:23 AM, "ext Alexandru Petrescu" > wrote: > >> NETEXT WG members, >> >> It was said at times that PMIP-NEMO is impossible. PMIP is a core >> network protocol, where mobility is supported without modifying the >> MN. >> >> Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example >> it adds DHCP Client on it; or other times it performs HNP >> Division. >> >> BEcause of this there exist statements that PMIP-NEMO is >> impossible. >> >> Do you think there are other reasons why PMIP-NEMO is impossible? >> >> Do you think that running DHCP Client on MN is a modification to >> MN? >> >> Alex >> >> _______________________________________________ netext mailing >> list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > > > From Basavaraj.Patil@nokia.com Fri Jul 13 07:27:20 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 DD2B821F87C6 for ; Fri, 13 Jul 2012 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 vr3Fw6tWA34Q for ; Fri, 13 Jul 2012 07:27:19 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 686CA21F87B2 for ; Fri, 13 Jul 2012 07:27:18 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6DERkl0018709; Fri, 13 Jul 2012 17:27:46 +0300 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); Fri, 13 Jul 2012 17:28:12 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Fri, 13 Jul 2012 16:27:44 +0200 From: To: Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? Thread-Index: AQHNYNk4gAMYTdsgxkWSuCD0y/Yk0JcmqX0AgABZ0oD//8z8gA== Date: Fri, 13 Jul 2012 14:27:44 +0000 Message-ID: In-Reply-To: <500014DD.2060107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.29] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2012 14:28:12.0819 (UTC) FILETIME=[BBDC5E30:01CD6103] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 14:27:20 -0000 On 7/13/12 7:30 AM, "ext Alexandru Petrescu" wrote: > >> DHCP is an independent protocol and hence has no implications >> regarding network based mobility teams design of not modifying the >> MN. > >Yes but: adding DHCPv6 on a MN is considered as modification or not. Not in the context of PMIP6. -Raj > >Alex From sarikaya2012@gmail.com Fri Jul 13 11:47: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 C979311E80B5 for ; Fri, 13 Jul 2012 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 EKNg1WpLQ1Aj for ; Fri, 13 Jul 2012 11:47:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06011E808D for ; Fri, 13 Jul 2012 11:47:37 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4267852ghb.31 for ; Fri, 13 Jul 2012 11:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=+wO3JwzcVyH3YpeWkLVT0ZMVjqmU64HJ1IOfUET5Uws=; b=Gww5v7qwBBScVO46csGkqHU7KJPG0THKj8w6+uXnZ43fEOeYK1ZzMVcE0OS4qL1juz p0+FQHwtnMAPC7K78IvIfZkSa1QPL6fHoSl6555wLPWJoSmH5VzLijqcDEqRFWACtSvx 5Ws2oY3Apgaax665r5Nhm7EqiD02QUm0nhnNtVVZrAr0sSHOnVRS9B45A3d2pOQNkjwX U1iJERsiaNM3uBQNHcoA7q+J/RR/ZCaXKz5A1AF+t/lrv/mxE4oaN0ts6iyvt8AAcuZT UJiv59/HH2WxfFC0sI6nw7yuQaAx2T6/PaEnQM14PuwqyRvml9QN5vZn10v8b9DBMIJp 7xHA== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr2365977igc.63.1342205293360; Fri, 13 Jul 2012 11:48:13 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Fri, 13 Jul 2012 11:48:13 -0700 (PDT) Date: Fri, 13 Jul 2012 13:48:13 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 18:47:38 -0000 Hi Alex, Thanks for bringing this issue up :-). On Fri, Jul 13, 2012 at 4:23 AM, Alexandru Petrescu wrote: > NETEXT WG members, > > It was said at times that PMIP-NEMO is impossible. PMIP is a core > network protocol, where mobility is supported without modifying the MN. > > Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it > adds DHCP Client on it; or other times it performs HNP Division. > > BEcause of this there exist statements that PMIP-NEMO is impossible. > > Do you think there are other reasons why PMIP-NEMO is impossible? > Basically, Nemo requires an MR. MR must be placed at the PMIP MN. This is the fundamental problem. I don't think it is possible to make an MR without changing MN. So far I have not seen any solutions. You are talking about a protocol that is designed to not to modify MN. > Do you think that running DHCP Client on MN is a modification to MN? > Standard clients are OK. The problem with the WG draft is that it requires an DHCP client extended with PD. I would like draft-bernardos-netext-pmipv6-nemo-ps to be revised with a discussion of this fundamental problem in PMIP-Nemo. Regards, Behcet From seiljeon@av.it.pt Fri Jul 13 13:03:10 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 5C9CA11E80EA for ; Fri, 13 Jul 2012 13:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 t4DQbZFdz4xu for ; Fri, 13 Jul 2012 13:03:08 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8911E809B for ; Fri, 13 Jul 2012 13:03:06 -0700 (PDT) Received: from [188.81.85.238] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65466929; Fri, 13 Jul 2012 21:03:42 +0100 From: "Seil Jeon" To: References: In-Reply-To: Date: Fri, 13 Jul 2012 21:03:43 +0100 Message-ID: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPLlIDc7vacGOJCsOgNieqat2H5pakBeBA Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:03:10 -0000 Hi Behcet, See inline [SJ]. Regards, Seil -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, July 13, 2012 7:48 PM To: Alexandru Petrescu Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps Hi Alex, Thanks for bringing this issue up :-). On Fri, Jul 13, 2012 at 4:23 AM, Alexandru Petrescu wrote: > NETEXT WG members, > > It was said at times that PMIP-NEMO is impossible. PMIP is a core > network protocol, where mobility is supported without modifying the MN. > > Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it > adds DHCP Client on it; or other times it performs HNP Division. > > BEcause of this there exist statements that PMIP-NEMO is impossible. > > Do you think there are other reasons why PMIP-NEMO is impossible? > Basically, Nemo requires an MR. MR must be placed at the PMIP MN. This is the fundamental problem. I don't think it is possible to make an MR without changing MN. So far I have not seen any solutions. [SJ] In my knowledge, an MN doesn't need to be changed if the MR acts as a moving MAG, which has the responsibility of MN detection i.e. MN's attach and detach, and sending/receiving PBU/PBA instead of the MN. Regarding on this issue, it was described at the Paris meeting I remember. You are talking about a protocol that is designed to not to modify MN. > Do you think that running DHCP Client on MN is a modification to MN? > Standard clients are OK. The problem with the WG draft is that it requires an DHCP client extended with PD. I would like draft-bernardos-netext-pmipv6-nemo-ps to be revised with a discussion of this fundamental problem in PMIP-Nemo. Regards, Behcet _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sarikaya2012@gmail.com Fri Jul 13 13:21:10 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 9367411E80E2 for ; Fri, 13 Jul 2012 13:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 88lRlH6RxtNE for ; Fri, 13 Jul 2012 13:21:09 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C87CD11E80C7 for ; Fri, 13 Jul 2012 13:21:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4362120ghb.31 for ; Fri, 13 Jul 2012 13:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I2yV8uRUx1Y5lnwSIwSpjw+j04geAFjuLYT8bwSoqMM=; b=Xje2TL2iuM55rT31dYSQZjdGecBY6rfRkK9w/s2C14Fh5z2nuqmqWEPq61sBFOguSC HtrklyTBa4930OVuHRRhzpvkFe+sCuMppklzt+kz59/CA9ngnS2w9Rw0ab+dLmNR9OOJ Y7QeGcTVdpAICbkOW9uJzeqNLSoflaL4jBP6lOVwVJwIIcPVAxuB3NNuQx9QeHe345p5 tlNKYvi+OJYbJN4gHhSdExyp7NmvdInGc6ztAAlu8Og/NiQDqUNzz8rtgZXkaRYz8oDp vXPnYdwZk/s03bQ+mZCFDGuLN+ZMLNYfFM4TOESMRD/vGrYn0/zfuvsqhdbtqMp/PQDg LS2g== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr133501iga.9.1342210905941; Fri, 13 Jul 2012 13:21:45 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Fri, 13 Jul 2012 13:21:45 -0700 (PDT) In-Reply-To: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> References: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> Date: Fri, 13 Jul 2012 15:21:45 -0500 Message-ID: From: Behcet Sarikaya To: Seil Jeon Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:21:10 -0000 Hi Seil, MR as mobile MAG could work. Is there a draft on this? Regards, Behcet On Fri, Jul 13, 2012 at 3:03 PM, Seil Jeon wrote: > Hi Behcet, > > See inline [SJ]. > > Regards, > > Seil > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: Friday, July 13, 2012 7:48 PM > To: Alexandru Petrescu > Cc: netext@ietf.org > Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? > draft-bernardos-netext-pmipv6-nemo-ps > > Hi Alex, > > Thanks for bringing this issue up :-). > > On Fri, Jul 13, 2012 at 4:23 AM, Alexandru Petrescu > wrote: >> NETEXT WG members, >> >> It was said at times that PMIP-NEMO is impossible. PMIP is a core >> network protocol, where mobility is supported without modifying the MN. >> >> Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it >> adds DHCP Client on it; or other times it performs HNP Division. >> >> BEcause of this there exist statements that PMIP-NEMO is impossible. >> >> Do you think there are other reasons why PMIP-NEMO is impossible? >> > > Basically, Nemo requires an MR. MR must be placed at the PMIP MN. This is > the fundamental problem. I don't think it is possible to make an MR without > changing MN. So far I have not seen any solutions. > > [SJ] In my knowledge, an MN doesn't need to be changed if the MR acts as a > moving MAG, which has the responsibility of MN detection i.e. MN's attach > and detach, and sending/receiving PBU/PBA instead of the MN. Regarding on > this issue, it was described at the Paris meeting I remember. > > > You are talking about a protocol that is designed to not to modify MN. > >> Do you think that running DHCP Client on MN is a modification to MN? >> > > Standard clients are OK. > > The problem with the WG draft is that it requires an DHCP client extended > with PD. > > I would like draft-bernardos-netext-pmipv6-nemo-ps to be revised with a > discussion of this fundamental problem in PMIP-Nemo. > > > Regards, > > Behcet > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From seiljeon@av.it.pt Fri Jul 13 13:58:52 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 7278C11E8080 for ; Fri, 13 Jul 2012 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8IdkOFiuGe-8 for ; Fri, 13 Jul 2012 13:58:51 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id F32F211E8097 for ; Fri, 13 Jul 2012 13:58:50 -0700 (PDT) Received: from [188.81.85.238] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65467107; Fri, 13 Jul 2012 21:59:26 +0100 From: "Seil Jeon" To: References: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> In-Reply-To: Date: Fri, 13 Jul 2012 21:59:27 +0100 Message-ID: <001a01cd613a$64aa6b20$2dff4160$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPLlIDc7vacGOJCsOgNieqat2H5gKMaGD/Ab4wr72WgcG1gA== Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:58:52 -0000 Hi Behcet, No draft but magazine journal. http://dx.doi.org/10.1109/MCOM.2009.4939291 Regards, Seil -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Friday, July 13, 2012 9:22 PM To: Seil Jeon Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps Hi Seil, MR as mobile MAG could work. Is there a draft on this? Regards, Behcet On Fri, Jul 13, 2012 at 3:03 PM, Seil Jeon wrote: > Hi Behcet, > > See inline [SJ]. > > Regards, > > Seil > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Friday, July 13, 2012 7:48 PM > To: Alexandru Petrescu > Cc: netext@ietf.org > Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? > draft-bernardos-netext-pmipv6-nemo-ps > > Hi Alex, > > Thanks for bringing this issue up :-). > > On Fri, Jul 13, 2012 at 4:23 AM, Alexandru Petrescu > wrote: >> NETEXT WG members, >> >> It was said at times that PMIP-NEMO is impossible. PMIP is a core >> network protocol, where mobility is supported without modifying the MN. >> >> Or, in some PMIP-NEMO proposals, the MN _is_ modified: for example it >> adds DHCP Client on it; or other times it performs HNP Division. >> >> BEcause of this there exist statements that PMIP-NEMO is impossible. >> >> Do you think there are other reasons why PMIP-NEMO is impossible? >> > > Basically, Nemo requires an MR. MR must be placed at the PMIP MN. This > is the fundamental problem. I don't think it is possible to make an MR > without changing MN. So far I have not seen any solutions. > > [SJ] In my knowledge, an MN doesn't need to be changed if the MR acts > as a moving MAG, which has the responsibility of MN detection i.e. > MN's attach and detach, and sending/receiving PBU/PBA instead of the > MN. Regarding on this issue, it was described at the Paris meeting I remember. > > > You are talking about a protocol that is designed to not to modify MN. > >> Do you think that running DHCP Client on MN is a modification to MN? >> > > Standard clients are OK. > > The problem with the WG draft is that it requires an DHCP client > extended with PD. > > I would like draft-bernardos-netext-pmipv6-nemo-ps to be revised with > a discussion of this fundamental problem in PMIP-Nemo. > > > Regards, > > Behcet > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From hesham@elevatemobile.com Fri Jul 13 21:44:24 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 1BC0B11E8086 for ; Fri, 13 Jul 2012 21:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 flJsMt3jdCYP for ; Fri, 13 Jul 2012 21:44:21 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1799011E8072 for ; Fri, 13 Jul 2012 21:44:20 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SpuDe-0005Lv-Jg; Sat, 14 Jul 2012 14:44:39 +1000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sat, 14 Jul 2012 14:44:30 +1000 From: Hesham Soliman To: Seil Jeon , Message-ID: Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps In-Reply-To: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sat, 14 Jul 2012 04:44:25 -0000 > >[SJ] In my knowledge, an MN doesn't need to be changed if the MR acts as a >moving MAG, which has the responsibility of MN detection i.e. MN's attach >and detach, and sending/receiving PBU/PBA instead of the MN. Regarding on >this issue, it was described at the Paris meeting I remember. => Moving MAG = MR in RFC 3963 basically. So it's not PMIP anymore it's normal MIPv6. Hesham From seiljeon@av.it.pt Sat Jul 14 07:06:56 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 2CE1621F87B9 for ; Sat, 14 Jul 2012 07:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 XTcmW3RAgeCO for ; Sat, 14 Jul 2012 07:06:55 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 39C2721F87B8 for ; Sat, 14 Jul 2012 07:06:53 -0700 (PDT) Received: from [188.80.101.79] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65470750; Sat, 14 Jul 2012 15:07:30 +0100 From: "Seil Jeon" To: "'Hesham Soliman'" References: <001501cd6132$9b3e8fc0$d1bbaf40$@av.it.pt> In-Reply-To: Date: Sat, 14 Jul 2012 15:07:30 +0100 Message-ID: <000601cd61ca$03068760$09139620$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQPixyBA5p0ovlLhTN6QeR7kwTzZejFr4w Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sat, 14 Jul 2012 14:06:56 -0000 Hi Hesham, Regards, Seil -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com] Sent: Saturday, July 14, 2012 5:45 AM To: Seil Jeon; sarikaya@ieee.org Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps > >[SJ] In my knowledge, an MN doesn't need to be changed if the MR acts >as a moving MAG, which has the responsibility of MN detection i.e. MN's >attach and detach, and sending/receiving PBU/PBA instead of the MN. >Regarding on this issue, it was described at the Paris meeting I remember. => Moving MAG = MR in RFC 3963 basically. So it's not PMIP anymore it's normal MIPv6. [SJ] Moving MAG is not a MR defined in RFC 3963. See above how I defined the moving MAG. Hesham From hesham@elevatemobile.com Sat Jul 14 07:14:29 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 2FCA021F86A8 for ; Sat, 14 Jul 2012 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 s2vw+fV3Rukn for ; Sat, 14 Jul 2012 07:14:27 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2E21F8698 for ; Sat, 14 Jul 2012 07:14:23 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1Sq37Z-0006Ay-Mv; Sun, 15 Jul 2012 00:14:58 +1000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sun, 15 Jul 2012 00:14:52 +1000 From: Hesham Soliman To: Seil Jeon Message-ID: Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps In-Reply-To: <000601cd61ca$03068760$09139620$@av.it.pt> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sat, 14 Jul 2012 14:14:29 -0000 > >> >>[SJ] In my knowledge, an MN doesn't need to be changed if the MR acts >>as a moving MAG, which has the responsibility of MN detection i.e. MN's >>attach and detach, and sending/receiving PBU/PBA instead of the MN. >>Regarding on this issue, it was described at the Paris meeting I >>remember. > >=> Moving MAG = MR in RFC 3963 basically. So it's not PMIP anymore it's >normal MIPv6. > >[SJ] Moving MAG is not a MR defined in RFC 3963. See above how I defined >the >moving MAG. => Apart from calling it a PBU, as opposed to a BU, what is the real difference between a moving MAG and MR? Ironically, people called the Prefix Binding Updates PBUs in early discussions of NEMO. Are you saying it sends one BU per address, as opposed to one BU for the entire prefix? If so, why? a prefix BU is much more efficient. That would just be a less efficient version of MIP-based MRs. Hesham From seiljeon@av.it.pt Sat Jul 14 17:03: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 43B5221F84AE for ; Sat, 14 Jul 2012 17:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 STUFCoTa1OEi for ; Sat, 14 Jul 2012 17:03:29 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id C092E21F84A7 for ; Sat, 14 Jul 2012 17:03:24 -0700 (PDT) Received: from [188.80.97.202] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65473068; Sun, 15 Jul 2012 01:04:00 +0100 From: "Seil Jeon" To: "'Hesham Soliman'" References: <000601cd61ca$03068760$09139620$@av.it.pt> In-Reply-To: Date: Sun, 15 Jul 2012 01:03:52 +0100 Message-ID: <000301cd621d$57cbcc80$07636580$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJLoLZjQ/1ZF7dqLh9VIoXpjYP+75YsytZA Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sun, 15 Jul 2012 00:03:30 -0000 Hi Hesham, Regards, Seil -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com] Sent: Saturday, July 14, 2012 3:15 PM To: Seil Jeon Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps > >> >>[SJ] In my knowledge, an MN doesn't need to be changed if the MR acts >>as a moving MAG, which has the responsibility of MN detection i.e. >>MN's attach and detach, and sending/receiving PBU/PBA instead of the MN. >>Regarding on this issue, it was described at the Paris meeting I >>remember. > >=> Moving MAG = MR in RFC 3963 basically. So it's not PMIP anymore it's >normal MIPv6. > >[SJ] Moving MAG is not a MR defined in RFC 3963. See above how I >defined the moving MAG. => Apart from calling it a PBU, as opposed to a BU, what is the real difference between a moving MAG and MR? Ironically, people called the Prefix Binding Updates PBUs in early discussions of NEMO. [SJ] It sounds to me what is difference between HA - MN (MIPv6 client) and LMA - MAG. PBU is meant to be Proxy Binding Update as defined in RFC 5213. Are you saying it sends one BU per address, as opposed to one BU for the entire prefix? If so, why? a prefix BU is much more efficient. That would just be a less efficient version of MIP-based MRs. [SJ] Actually, there's no standard draft yet for PMIP-NEMO we're discussing. Protocol designs for MR would be varied depending on the design perspective. But one example could be as follows. Moving MAG would attach to PMIPv6 domain and have unique prefix assigned from a LMA. For attaching and detaching mobile node, moving MAG should send PBU instead of MN individually. However, in the case of mobile network's moving, PBU sent by a MAG detecting mMAG's attachment to a LMA would be enough. Moving MAG doesn't need to send anything for network moving event itself. Following extended LMA binding cache entry can be an example. When the LMA receives PBU sent by the MAG regarding on moving MAG attachment (MAG1 -> MAG2), it only changes tunnel endpoint of mMAG to MAG 2 and doesn't need to touch MNs' entries belonging to mMAG. ID Prefix AR M flag -------------------------------------------------------------------- mMAG 1 Pref1::/64 MAG 2 no MN 1 Pref2::/64 mMAG 1 yes Actually, the above might be one example among many possible ways .. and it's not my idea. FYI, you can see following. I just wanted to describe possibility of PMIPv6-NEMO support using moving MAG. http://dx.doi.org/10.1109/MCOM.2009.4939291 From hesham@elevatemobile.com Sun Jul 15 02:42:49 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 51CD121F85CE for ; Sun, 15 Jul 2012 02:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 UnCPGL+3Nd8c for ; Sun, 15 Jul 2012 02:42:48 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA221F85CC for ; Sun, 15 Jul 2012 02:42:47 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SqLLy-0008Sg-Mr; Sun, 15 Jul 2012 19:43:03 +1000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sun, 15 Jul 2012 19:42:53 +1000 From: Hesham Soliman To: Seil Jeon Message-ID: Thread-Topic: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps In-Reply-To: <000301cd621d$57cbcc80$07636580$@av.it.pt> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sun, 15 Jul 2012 09:42:49 -0000 > > >[SJ] Actually, there's no standard draft yet for PMIP-NEMO we're >discussing. >Protocol designs for MR would be varied depending on the design >perspective. >But one example could be as follows. Moving MAG would attach to PMIPv6 >domain and have unique prefix assigned from a LMA. For attaching and >detaching mobile node, moving MAG should send PBU instead of MN >individually. However, in the case of mobile network's moving, PBU sent >by a >MAG detecting mMAG's attachment to a LMA would be enough. Moving MAG >doesn't >need to send anything for network moving event itself. Following extended >LMA binding cache entry can be an example. >When the LMA receives PBU sent by the MAG regarding on moving MAG >attachment >(MAG1 -> MAG2), it only changes tunnel endpoint of mMAG to MAG 2 and >doesn't >need to touch MNs' entries belonging to mMAG. => Doesn't sound like something you would deploy on shared links, but I guess that's a generic statement for PMIP. Anyway, lets see when a draft is proposed. Hesham > > >ID Prefix AR M flag >-------------------------------------------------------------------- >mMAG 1 Pref1::/64 MAG 2 no >MN 1 Pref2::/64 mMAG 1 yes > > >Actually, the above might be one example among many possible ways .. and >it's not my idea. FYI, you can see following. >I just wanted to describe possibility of PMIPv6-NEMO support using moving >MAG. > >http://dx.doi.org/10.1109/MCOM.2009.4939291 > > > > From seiljeon@av.it.pt Sun Jul 15 09:03:16 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 573B621F84FA for ; Sun, 15 Jul 2012 09:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Wf7iWGFXOv30 for ; Sun, 15 Jul 2012 09:03:15 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 23D6821F84EF for ; Sun, 15 Jul 2012 09:03:13 -0700 (PDT) Received: from [188.80.97.202] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65476309; Sun, 15 Jul 2012 17:03:54 +0100 From: "Seil Jeon" To: "'Hesham Soliman'" References: <000301cd621d$57cbcc80$07636580$@av.it.pt> In-Reply-To: Date: Sun, 15 Jul 2012 17:03:56 +0100 Message-ID: <000001cd62a3$70ef88b0$52ce9a10$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMcgLdgSGvU7cLAezFDGa9uo/9S5esYWVA Content-Language: ko Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps 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: Sun, 15 Jul 2012 16:03:16 -0000 Hi Hesham, Regards, Seil -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com] Sent: Sunday, July 15, 2012 10:43 AM To: Seil Jeon Cc: netext@ietf.org Subject: Re: [netext] PMIP purists - is PMIP-NEMO impossible? draft-bernardos-netext-pmipv6-nemo-ps > > >[SJ] Actually, there's no standard draft yet for PMIP-NEMO we're >discussing. >Protocol designs for MR would be varied depending on the design >perspective. >But one example could be as follows. Moving MAG would attach to PMIPv6 >domain and have unique prefix assigned from a LMA. For attaching and >detaching mobile node, moving MAG should send PBU instead of MN >individually. However, in the case of mobile network's moving, PBU sent >by a MAG detecting mMAG's attachment to a LMA would be enough. Moving >MAG doesn't need to send anything for network moving event itself. >Following extended LMA binding cache entry can be an example. >When the LMA receives PBU sent by the MAG regarding on moving MAG >attachment >(MAG1 -> MAG2), it only changes tunnel endpoint of mMAG to MAG 2 and >doesn't need to touch MNs' entries belonging to mMAG. => Doesn't sound like something you would deploy on shared links, but I guess that's a generic statement for PMIP. Anyway, lets see when a draft is proposed. [SJ] Yes, the given example was not based on shared link. For shared link support, we may check another way. > > >ID Prefix AR M flag >-------------------------------------------------------------------- >mMAG 1 Pref1::/64 MAG 2 no >MN 1 Pref2::/64 mMAG 1 yes > > >Actually, the above might be one example among many possible ways .. >and it's not my idea. FYI, you can see following. >I just wanted to describe possibility of PMIPv6-NEMO support using >moving MAG. > >http://dx.doi.org/10.1109/MCOM.2009.4939291 > > > > From internet-drafts@ietf.org Sun Jul 15 18:29:04 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 624FE21F847A; Sun, 15 Jul 2012 18:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 QGX1p1stxdpU; Sun, 15 Jul 2012 18:29:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC96D21F846B; Sun, 15 Jul 2012 18:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716012903.13491.99397.idtracker@ietfa.amsl.com> Date: Sun, 15 Jul 2012 18:29:03 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-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: Mon, 16 Jul 2012 01:29:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-03.txt Pages : 16 Date : 2012-07-15 Abstract: Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael.boc@cea.fr Mon Jul 16 02:12:16 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 7C16521F86BA; Mon, 16 Jul 2012 02:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=4.251, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 jVO6EigyKqVt; Mon, 16 Jul 2012 02:12:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6928C21F86B9; Mon, 16 Jul 2012 02:12:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6G9Cw0Z009448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2012 11:12:58 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6G9CwqA011435; Mon, 16 Jul 2012 11:12:58 +0200 (envelope-from michael.boc@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6G9CvlK003869; Mon, 16 Jul 2012 11:12:57 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Mon, 16 Jul 2012 11:12:57 +0200 From: BOC Michael To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [netext] I-D Action: draft-ietf-netext-pd-pmip-03.txt Thread-Index: AQHNYvKCvhAGL3znHEuOVmE7wTRHpJcrmk7g Date: Mon, 16 Jul 2012 09:12:56 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA339380355A4EB@EXDAG0-B3.intra.cea.fr> References: <20120716012903.13491.99397.idtracker@ietfa.amsl.com> In-Reply-To: <20120716012903.13491.99397.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19042.002 x-tm-as-result: No--32.581400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-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: Mon, 16 Jul 2012 09:12:16 -0000 Hello all, Concerning this draft, I would like to know why you need to set the R flag = in PBU=20 (because you don't explain it in the draft) and if your approach is to not = take=20 into account possible hints in IA_PD(s). If this is the case, we just have = to provide=20 MNP(s) at MR attachment with the HNP(s) and we move on another subject. =20 Regards, Michael > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la > part de internet-drafts@ietf.org > Envoy=E9=A0: lundi 16 juillet 2012 03:29 > =C0=A0: i-d-announce@ietf.org > Cc=A0: netext@ietf.org > Objet=A0: [netext] I-D Action: draft-ietf-netext-pd-pmip-03.txt >=20 >=20 > 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. >=20 > Title : Prefix Delegation for Proxy Mobile IPv6 > Author(s) : Xingyue Zhou > Jouni Korhonen > Carl Williams > Sri Gundavelli > Carlos J. Bernardos > Filename : draft-ietf-netext-pd-pmip-03.txt > Pages : 16 > Date : 2012-07-15 >=20 > Abstract: > Proxy Mobile IPv6 enables IP mobility for a host without requiring > its participation in any mobility signaling, being the network > responsible for managing IP mobility on behalf of the host. > However, > Proxy Mobile IPv6 does not support assigning a prefix to a router > and > managing its IP mobility. This document specifies an extension to > Proxy Mobile IPv6 protocol for supporting network mobility using > DHCPv6-based Prefix Delegation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-03 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From internet-drafts@ietf.org Mon Jul 16 10:12:43 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 DC76F21F87C9; Mon, 16 Jul 2012 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 MkzEmNBoxbjF; Mon, 16 Jul 2012 10:12:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD921F87A3; Mon, 16 Jul 2012 10:12:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716171243.14554.5384.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 10:12:43 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-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: Mon, 16 Jul 2012 17:12:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : EAP Attributes for WiFi - EPC Integration Author(s) : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-01.txt Pages : 12 Date : 2012-07-16 Abstract: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-wifi-epc-eap-attribu= tes-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 12:15:09 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 6858911E8301; Mon, 16 Jul 2012 12:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 oOXWpAHL4MF8; Mon, 16 Jul 2012 12:15:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55E711E82FD; Mon, 16 Jul 2012 12:15:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716191508.23121.42932.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 12:15:08 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:15:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Proxy Mobile IPv6 Extensions to Support Flow Mobility Author(s) : Carlos J. Bernardos Filename : draft-ietf-netext-pmipv6-flowmob-04.txt Pages : 21 Date : 2012-07-16 Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions required consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmipv6-flowmob-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Mon Jul 16 12:15:47 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 DF92111E830C for ; Mon, 16 Jul 2012 12:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.034, 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 wW0k9gw3ka8A for ; Mon, 16 Jul 2012 12:15:42 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 480A711E82E8 for ; Mon, 16 Jul 2012 12:15:41 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 308D776BEB9; Mon, 16 Jul 2012 21:16:25 +0200 (CEST) Message-ID: <1342466184.5049.76.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Marco Liebsch Date: Mon, 16 Jul 2012 21:16:24 +0200 In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24E0884B@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24E0884B@PALLENE.office.hd> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8TdfOF2fTdTE+EA3RU7v" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19042.007 X-TM-AS-Result: No--20.118-7.0-31-1 X-imss-scan-details: No--20.118-7.0-31-1 Cc: "netext@ietf.org" Subject: Re: [netext] review of draft-ietf-netext-pmipv6-flowmob-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:15:47 -0000 --=-8TdfOF2fTdTE+EA3RU7v Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marco, all, Please find below some comments inline. Since Juan Carlos also made some comments regarding the draft, and some are related, I've tried to update the document taking into account both reviews. On Fri, 2012-07-06 at 15:49 +0000, Marco Liebsch wrote: > Please find below some comments to the current version of > draft-ietf-netext-pmipv6-flowmob-03. >=20 > General comments: > From a specification to extend RFC5213 to support flow mobility I see the= following > components as key items to specify and describe associated operation: >=20 > (1) Prefix handling at LMA and MAG > (2) Handling and enforcement of flow policies at the LMA >=20 > IMO, the current draft focuses too much on thing which are not to be plac= ed in > this specification, e.g. how the MN can accomplish multiple address handl= ing. Taking into account your comments and Juan Carlos's ones, I've tried to make the draft focus less on the MN and more on the delta from RFC 5213 (the core was already there, so I've tried to make it more clear). >=20 > My general recommendation is to thoroughly describe the delta to RFC5213 > and which additional or extended functions are needed to accomplish base > flow mobility scenario and how these function operate with PMIPv6. My vie= w > is that the specification also has lots of should and may. The draft shou= ld be clear > about what's really needed to enable flow mobility according to a well un= derstood > problem statement. If there are options to enable additional features, th= ey should > be clearly separated from the core specification. One example is the need OK, I've tried to do that in -04. > to propagate flow templates to MAGs. Only on the last pages (p.17) the re= ader > learns that maintaining flow level information on MAGs is not mandatory. > Is there text at all that explains why flow templates are needed on the M= AG at all? OK, same than above. >=20 > Please find specific comments below in a copy of the draft, labeled with = [marco]. >=20 > ---------------- >=20 >=20 > NETEXT Working Group CJ. Bernardos, Ed. > Internet-Draft UC3M > Intended status: Standards Track March 12, 2012 > Expires: September 13, 2012 >=20 >=20 > Proxy Mobile IPv6 Extensions to Support Flow Mobility > draft-ietf-netext-pmipv6-flowmob-03 >=20 > Abstract >=20 > Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy > Mobile IPv6 domain through different interfaces. However, the > ability of movement of selected flows from one access technology to > another is missing in the basic Proxy Mobile IPv6 protocol. This > document describes extensions to the Proxy Mobile IPv6 protocol that > are required to support network based flow mobility over multiple > physical interfaces. >=20 > This document assumes that the mobile node implements the logical > interface model, >=20 > [marco] .. it should not. It's good that NetExt has an informational docu= mentation > about how logical interfaces can support multi-homing and flow mobility, = but this > specification should not assume it or even mandate its use. The spec shou= ld > solely assume that the MN is able to handle multiple addresses@ multiple = interfaces > as well as to enforce uplink policies to select the right interface.=20 > The Abstract should focus on which features can be supported compared to > RFC5213 when the specified components are implemented. [Carlos] I've modified the abstract. >=20 >=20 >=20 > therefore allowing the support of traffic flows on > different physical interfaces regardless of the assigned prefixes on > these physical interfaces. >=20 > Requirements Language >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on September 13, 2012. >=20 > Copyright Notice >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 1] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > /..snip >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 2] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 1. Introduction >=20 > Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network > based mobility management to hosts connecting to a PMIPv6 domain. > PMIPv6 introduces two new functional entities, the Local Mobility > Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the > entity detecting Mobile Node's (MN) attachment and providing IP > connectivity. The LMA is the entity assigning one or more Home > Network Prefixes (HNPs) to the MN and is the topological anchor for > all traffic belonging to the MN. >=20 > PMIPv6 allows an MN to connect to the same PMIPv6 domain through > different interfaces. The "logical interface" at the IP layer may > enable packet transmission and reception over different physical > media. This technique can be used to achieve flow mobility, i.e., > the movement of selected flows from one access technology to another. >=20 > [marco] why does the document introduce the logical interface even before > what should be the core of the specification? I'd propose to just mention= the assumption > of such support on the MN and refer to the availability of appropriate te= chnology > on the MN.=20 [Carlos] I've modified it following your suggestion, and re-using part of Juan Carlos's proposed text. >=20 >=20 > It is assumed that an IP layer interface can simultaneously and/or > sequentially attach to multiple MAGs (possibly over multiple media). > This document specifies protocol extensions to Proxy Mobile IPv6 > between the LMA and MAGs to enable distributing specific traffic > flows on different physical interfaces. This document assumes that a > "logical interface" at the mobile node is capable of supporting >=20 > [marco] ..again? [Carlos] Addressed above. >=20 >=20 > traffic flows on different physical interfaces regardless of the > assigned prefixes on those physical interfaces. >=20 > In particular, this document specifies how to enable "flow mobility" > in the PMIPv6 network (i.e. LMAs and MAGs). Flow mobility is > enabled by assigning the required prefixes on the different accesses. >=20 > [marco] three lines about the actual scope of the draft. I don't want to > be nasty, but it really does not help the reader to understand or even > implement what's needed for PMIP if you focus on which technology to > use on the MN.=20 [Carlos] I've modified this part a bit. I preferred not to describe in detail the extensions, because they are different depending on the considered use case. Therefore, I preferred to introduce the reader that different use case scenarios are analyzed in the draft, each one involving different prefix management requirements and protocol extensions. >=20 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC2119 [RFC2119]. >=20 > The following terms used in this document are defined in the Proxy > Mobile IPv6 [RFC5213]: >=20 > Local Mobility Agent (LMA). >=20 > Mobile Access Gateway (MAG). >=20 > Proxy Mobile IPv6 Domain (PMIPv6-Domain). >=20 > LMA Address (LMAA). >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 3] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > Proxy Care-of Address (Proxy-CoA). >=20 > Home Network Prefix (HNP). >=20 > The following terms used in this document are defined in the Multiple > Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile > IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: >=20 > Binding Identification Number (BID). >=20 > Flow Identifier (FID). >=20 > Traffic Selector (TS). >=20 > The following terms are defined and used in this document: >=20 > FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG > conveying the information required to enable flow mobility in a > PMIPv6-Domain. This message is only needed when the prefixes > initially assigned by the different MAGs to the mobile node are > different. >=20 > FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to > an FMI message. >=20 >=20 > [marco] I don't think protocol message definitions are needed in the term= s section. >=20 [Carlos] Well, many documents do so. RFC5213 for example follows the same approach. Unless more people think they should be remove, I'd prefer to keep them. >=20 >=20 > FMC (Flow Mobility Cache). Conceptual data structure maintained by > the LMA and the MAG to support the flow mobility management > operations described in this document. >=20 >=20 > 3. Overview of the PMIPv6 flow mobility extensions >=20 > 3.1. Use case scenarios >=20 > Flow mobility assumes simultaneous access to more than one network, > in contrast to a typical handover where connectivity to a physical > medium is relinquished, and is re-established with another. In order > to support flow mobility in a PMIPv6 network, it is required to be > able to to tie the different PMIPv6 mobility sessions (one per >=20 > [marco] typo: able to to --> able to [Carlos] fixed. >=20 > interface) to a logical interface which is hiding one or more > physical interfaces [I-D.ietf-netext-logical-interface-support]. In > this specification, it is assumed that the LMA knows that the MN > supports the logical interface and it can handle the same prefix(es) > or different prefix(es) on both access networks. How this is done is > out of the scope of this specification. >=20 > [marco] this sounds like the spec mandates the logical interface. > In I-D.ietf-netext-logical-interface-support I see one approach > of solving the MN part being documented. Other possibilities beyond > I-D.ietf-netext-logical-interface-support using also virtual interfaces > exist. I'd propose to just place assumptions about functional support > as written above. If really needed, an Appendix section can be added > where a reader gets informed about an exemplary configuration > on MNs , e.g. using a logical interface. [Carlos] I've modified it, taking also into account Juan Carlos's comments to avoid mandating a concrete approach. >=20 >=20 > There are different flow mobility scenarios. In some of them the > mobile node might share a common set of prefixes among all its >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 4] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > physical interfaces, whereas in others the mobile node might have a > different subset of prefixes configured on each of the phyisical > interfaces. The different possibilities are the following: >=20 >=20 > [marco] 'possibilities' =3D 'scenarios', correct? [Carlos] Right. >=20 > 1. At the time of a new network attachment, the MN obtains the same > prefix or the same set of prefixes as already assigned to an > existing session. This is not the default behavior with basic > PMIPv6 [RFC5213], and the LMA needs to be able to provide the > same assignment even for the simultaneous attachment (as opposed > to the handover scenario only). >=20 > 2. At the time of a new network attachment, the MN obtains a new > prefix or a new set of prefixes for the new session. This is the > default behavior with basic PMIPv6 [RFC5213]. >=20 > 3. At the time of a new network attachment, the MN obtains a > combination of prefix(es) in use and new prefix(es). This is a > hybrid of the two above-mentioned scenarios. The local policy > determines whether the new prefix is exclusive to the new > attachment or it can be assigned to an existing attachment as > well. >=20 > Among these, scenario 1 needs extensions to basic PMIPv6 [RFC5213] > signaling at the time of a new attachment, to ensure that the same > prefix (or set of prefixes) is assigned to all the interfaces of the > same mobile node that are simultaneously attached. Subsequently, no > further signaling is necessary. >=20 >=20 > [marco] maybe clearer: '..No further signaling is necessary between the L= MA > and the MAG and flows are forwarded according to policy rules on the LMA = and the MN' [Carlos] right. >=20 >=20 > Scenario 2 requires flow mobility signaling to enable relocating > flows between the different attachments, so the MAGs are aware of the > prefixes for which the MN is going to receive traffic, and local > routing entries are configured accordingly. >=20 >=20 > [marco] scenario 2 per se does not need any extension. As you write above= , > it's covered by RFC5213. You only need extra signaling if scenario 2 turn= s into > scenario 3. Hence, you should probably mention this in the next paragraph= . [Carlos] Not really. Scenario 2 needs extensions. Juan Carlos pointed out in his review that the way this section is written may lead to confusion and suggested to merge the description of the scenarios with the parts where the full scenario is tackled. I've tried to do so in -04. Please check if now it is clearer. >=20 >=20 >=20 > Scenario 3 requires flow mobility signaling to enable relocating > flows for the new prefix(es) which are not shared across attachments. >=20 > In all the scenarios, the MAGs should be aware of the prefixes for > which is going to receive uplink (UL) or downlink (DL) traffic. > These prefixes might not be limited to those delegated by the MAG > upon attachment of the connected interface, and therefore in these > cases, signaling is required. >=20 > Once the network is configured with the right set of prefixes, the > actual flow mobility can take place at any time thereafter (e.g., by > redirecting DL or UL packets from one access to another). >=20 > The extensions described in this document support any of these > aforementioned scenarios. >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 5] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 3.2. Basic Operation >=20 > This section describes how the PMIPv6 extensions described in this > document enable flow mobility support. >=20 > 3.2.1. MN sharing a common set of prefixes on all MAGs >=20 > This scenario corresponds to the use case scenario number 1 described > in Section 3.1. When a multi-interfaced mobile node connects to a > PMIPv6-domain, it performs regular attachment and as a result is able > to configure an IP address (or a set of IP addresses) on the logical > interface hiding the different physical interfaces. >=20 > [marco] again, the spec should not assume how flow mobility is implemente= d > in the MN. Hence, no assumption should be taken about the existence of a > logical interface in the core specification part of the document. [Carlos] Fixed. >=20 >=20 > If the LMA > assigns a common prefix (or set of prefixes) to the different > physical interfaces attached to the domain, then all the MAGs already > have all the routing knowledge required to forward UL or DL packets, > and the LMA does not need to perform any kind of signaling in order > to move flows across the different physical interfaces. >=20 > The LMA needs to know when to assigne the same set of prefixes to all >=20 > [marco]: assigne --> assign [Carlos] Fixed. >=20 > the different physical interfaces of the mobile node. This can be > achieved by different means, such as policy configuration or default > policies, etc. In this document a new Handoff Indicator (HI) value > ("Attachment over a new interface sharing prefixes") is defined, to > allow the mobile access gateway indicate to the local mobility anchor > that the same set of prefixes should be assigned to the mobile node. > The considerations of Section 5.4.1 of [RFC5213] are updated by this > specification as follows: >=20 > o If there is at least one Home Network Prefix option present in the > request with a NON_ZERO prefix value, there exists a Binding Cache > entry (with one all home network prefixes in the Binding Cache > entry matching the prefix values of all Home Network Prefix > options of the received Proxy Binding Update message), and the > entry matches the mobile node identifier in the Mobile Node > Identifier option of the received Proxy Binding Update message, > and the value of the Handoff Indicator of the received Proxy > Binding Update is equal to "Attachment over a new interface > sharing prefixes". >=20 > 1. If there is a Mobile Node Link-layer Identifier Option present > in the request and the Binding Cache entry matches the Access > Technology Type (ATT), and MN-LL-Identifier, the request MUST > be considered as a request for updating that Binding Cache > entry. >=20 > [marco] does that conflict with the above mentioned presence of > the new HI value? Above it's said that the message comprises a HI which > indicates "Attachment over a new interface sharing prefixes", whereas > procedure 1.is about a handover (BCE update). Or is the new > HI value used also in case of handover, not only at initial attachment? [Carlos] The HI value is also used in case of handover. >=20 >=20 > 2. If there is a Mobile Node Link-layer Identifier Option present > in the request and the Binding Cache entry does not match the > Access Technology Type (ATT), and MN-LL-Identifier, the >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 6] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > request MUST be considered as a request for creating a new > mobility session sharing the same set of Home Network Prefixes > assigned to the existing Binding Cache entry found. >=20 > 3. If there is not a Mobile Node Link-layer Identifier Option > present in the request, the request MUST be considered as a > request for creating a new mobility session sharing the same > set of Home Network Prefixes assigned to the existing Binding > Cache entry found. >=20 > As described in [I-D.ietf-netext-logical-interface-support], there >=20 > [marco] where is 'there' ? The assumption about MN support should have be= en > clarified earlier in this document. I do not see need for the complete pa= ragraph. [Carlos] This is related to a comment made by Juan Carlos. I've modified the text according to his suggestion and promoted before in the document. >=20 >=20 > should be a local policy in place that ensures that packets are > forwarded coherently. This SHOULD be enforced by the logical > interface engine [I-D.ietf-netext-logical-interface-support]. For > unidirectional outbound communications, there SHOULD also be a policy > at the mobile node defining which physical interface is used to send > the traffic. For bidirectional outbound communications, there SHOULD > be also such a policy, but its content must be consistent with the > policy at the network-side (the details about how this consistency is > ensured are out of the scope of this document). >=20 > In case the MAGs needs to be configured to support flow mobility, > because of packet policing, packet enforcement, charging or similar > reasons, the LMA SHOULD re-use the signaling defined later in this > document to convey this information. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 7] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |LMA| MN1, if1, pref1, MAG1 > +---+ MN1, if2, pref1, MAG2 > //\\ > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ > +----+ +----+ > |MAG1| |MAG2| > +----+ +----+ > | | > | +-------+ | > | | I P | | > | +-------+ | > | | lif | | > | +---+---+ | > |---|if1|if2|----| > +---+---+ > MN1 >=20 > Figure 1: Shared prefix across physical interfaces scenario >=20 >=20 > [marco] I propose to just draw the IP box and the two IF boxes. > same for the description below. Much clearer for the reader, as focus > is on the infrastructure, not on understanding how the LIF works. >=20 [Carlos] Done. >=20 > Next, an example of how flow mobility works in this case is shown. > In Figure 1, a mobile node (MN1) has two different physical > interfaces (if1 and if2), grouped in a unique logical interface > (lif). Each physical interface is attached to a different MAG, both > of them anchored and controlled by the same LMA. Since both physical > interfaces are assigned the same prefix (pref1) upon attachment to > the MAGs, the mobile node has one single IPv6 addresses configured on > the logical interface: pref1::lif. Initially, flow X goes through > MAG1 and flow Y through MAG2. At certain point, flow Y can be moved > to also go through MAG1. As shown in Figure 2, no signaling between > the LMA and the MAGs is needed. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 8] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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 > Figure 2: Flow mobility message sequence with common set of prefixes >=20 >=20 > [marco] The big decision box confuses, IMHO. I'd propose to > draw two small boxes, one on the LMA's and another on the MN's > line which say 'flow policy update'. That should be clear enough. [Carlos] Done. >=20 >=20 >=20 > Figure 3 shows the state of the different network entities after > moving flow Y in the previous example. This documents re-uses some > of the terminology and mechanisms of the flow bindings and multiple > care-of address registration specifications. Note, that in this case > the BIDs shown in the figure are assigned locally by the LMA, since > there is no signaling required in this scenario. In any case, > alternative implementations of flow routing at the LMA could be used, > as it does not impact on the operation of the solution in this case. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 9] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache LMA flowmob state > (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > |LMA| 1, MN1, att1, pref1, MAG1 1, flow X > +---+ 2, MN1, att2, pref1, MAG2 1, flow Y > //\\ > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ MAG1 routing state > +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |MAG1| |MAG2| (dest) (next hop) > +----+ +----+ pref1::/64 p2p-iface-with-MN1 > | | ::/0 LMA > | +-------+ | > | | I P | | MAG2 routing state > | +-------+ | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | lif | | (dest) (next hop) > | +---+---+ | pref1::/64 p2p-iface-with-MN1 > |---|if1|if2|----| ::/0 LMA > +---+---+ > MN1 >=20 > Figure 3: Data structures with common set of prefixes >=20 >=20 > [marco] Maybe it's good to be consistent and the LMA Binding Cache in the= above figure > should also refer to entries IF1, IF1 as depicted in Fig. 1, instead of A= TT. Or vice versa.=20 [Carlos] Done. >=20 >=20 > 3.2.2. MN with different sets of prefixes on each MAG >=20 > A different flow mobility scenario happens when the LMA assigns > different sets of prefixes to physical interfaces of the same mobile > node. This covers the second and third use case scenarios described > in Section 3.1. In this case, specific signaling is required between > the LMA and the MAG to support this scenario. Two different > possibilities are considered next. >=20 > The first possibility corresponds to the use case scenario number 2 > described in Section 3.1, in which a multi-interfaced MN obtains a > different set of prefixes on each attachment. Signaling is required > when a flow is to be moved from its original interface to a new one. > Since the LMA cannot send a PBA message which has not been triggered > in response to a received PBU message, new signaling messages are > defined to cover this case. 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 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 10] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=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. This message is sent to the > new target MAG, i.e. the one selected to be the used in the > forwarding of the flow. The FMI message contains (as explained in > further detail in Section 4.1), the MN-Identifier, the Flow > Identification Mobility option (specified in [RFC6089]) which can > convey prefix or full flow information, and the type of flow mobility > operation (add flow). Optionally, the LMA may send another FMI > message, this time to remove the flow Y state at MAG2. Otherwise the > flow state at MAG2 will be removed upon timer expiration. The > message sequence is shown in Figure 4. >=20 >=20 > [marco] I don't get the point why the flow information is needed on the M= AG. > is that mandatory for the key scenarios? I would propose not covering tha= t > in the core specification part, maybe in the back of the specification if= it's > really needed. [Carlos] If different prefixes are assigned to the different interfaces of the MN, in order to perform flow mobility, the MAGs need to know the prefixes assigned to the other MN's interfaces (not only to the one attached to the MAG itself), that are involved in the flow mobility. No information at flow-granularity itself is required, but at least on the prefix level. Providing information at flow-level is optional. I've modified the text a bit to make clearer that flow-level granularity info is not mandatory. >=20 > [marco] One technical proposal: The FMI/FMA imply pretty much overhead, > IMO. Why can't all prefixed be communicated to a MAG during a PBU/PBA > exchange? Having them in the BUL from the beginning allows > driving this like scenario 1by having all keys/identifiers at the MAG. > LMA and MN just enforce the flow policy. > Nothing else needed, or? Well, prefixes might be flagged at the MAG to in= dicate > whether or not the prefix is configured on the attached interface, just t= o know > which ones are to be communicated during ND. But important is the availab= ility > of the HNPs, which serve as key to identify the UE, at the MAG. And these= could > be established early. No intention to change your spec, but just a propos= al > to make protocol operation for flow mobility more lightweight. [Carlos] Well, there is a tradeoff here. Signaling the prefixes during PBU/PBA in this scenario is only possible once the prefixes are known, as the PBA can only be sent as a response to a received PBU. It might be the case that only one interface is attached, then the MN attaches a new one and a flow mobility operation is desired to be performed without waiting for the first MAG to send a periodic PBU (so a PBA with all the prefixes can be included in the response to it). I think FMI/FMA was discussed previously and the consensus on the WG was to keep it. >=20 >=20 >=20 >=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 | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<------------------------------->|<---------->if2 > | | | | | > | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | | | | > | | FMI[MN1-ID,flow_info(Y),add] | | > | |---------------->| | | > | | FMA | | | > | |<----------------| | | > | | (optional) | | > | | FMI[MN1-ID,flow_info(Y),lft=3D0] | | > | |-------------------------------->| | > | | | FMA | | > | |<--------------------------------| | > | flow Y to | flow Y to | flow Y to | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<--------------->|<-------------------------->if1 > | | | | | >=20 > Figure 4: Flow mobility message sequence when the LMA assigns > different sets of prefixes per physical interface (FMI signaling) >=20 > The state in the network after moving a flow, for the case the LMA > assigns a different set of prefixes is shown in Figure 5. >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 11] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > LMA Binding Cache LMA flowmob state > (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) > +---+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > |LMA| 1, MN1, att1, pref1, 1, flow X > +---+ pref2, MAG1 1, flow Y > //\\ 2, MN1, att2, pref2, MAG2 > +---------//--\\-------------+ > ( // \\ ) PMIPv6 domain > ( // \\ ) > +------//--------\\----------+ > // \\ > // \\ MAG1 routing state > +----+ +----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > |MAG1| |MAG2| (dest) (next hop) > +----+ +----+ pref1::/64 p2p-iface-with-MN1 > | | pref2::/64 p2p-iface-with-MN1 > | +-------+ | ::/0 LMA > | | I P | | > | +-------+ | MAG2 routing state > | | lif | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | +---+---+ | (dest) (next hop) > |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 > +---+---+ ::/0 LMA > MN1 >=20 > Figure 5: Data structures when the LMA assigns a different set of > prefixes >=20 > The second possibility corresponds to the use case scenario number 3 > described in Section 3.1, in which upon new physical interface > attachment, the MN obtains a combination of prefix(es) in use and new > prefix(es). Here, the mobile node is already attached to the PMIPv6- > Domain via MAG1. At a certain moment, the mobile node attaches a new > interface (if2) to MAG2. MAG2 sends a PBU which is then used by the > LMA to enable flow mobility. In this case, we consider that flows > are moved with a prefix granularity, meaning that flows are moved by > moving prefixes among the different MAGs the mobile node is attached > to. In this example, flow Y is bound to pref2::/64 and therefore the > flow can be moved by just binding pref2::/64 to MAG2. This is done > by including the prefix in the PBA message. The scenario is shown in > Figure 6. >=20 > Optionally, a message can be sent to MAG1 to remove the transferred > prefix(es). This message can be a Binding Revocation Indication > message [RFC5846] with the P bit set to indicate that this is > revocation of PMIP prefix(es). After processing BRI, the source MAG > will send a Binding Revocation Acknowledgement (BRA) message back to > the LMA. >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 12] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > In case flow mobility is needed with a finer granularity than full > prefix (e.g., flow level), this is done by including in the PBA a > Flow Identification Mobility option (specified in [RFC6089]) which > can convey full flow information. The MAG can also include the Flow > Identification Mobility option in the PBU message that it sends to > the LMA. This serves as a request for the LMA to consider the flow > policy rules specified in the option. In this case no prefix is > removed from any MAG because the movement is performed at flow level. >=20 > +-----+ +------+ +------+ +-----+ > Internet | LMA | | MAG1 | | MAG2 | | MN | > +-----+ +------+ +------+ +-----+ > | | | | | > | 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 | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<--------------->|<-------------------------->if1 > | | | | | > | | | | | > | | | MN powers on if2 and > | | | performs L2 attachment > | | | |<-----------if2 > | | | PBU | | > | |<--------------------------------| | > | | PBA (pref2) | | | > | |-------------------------------->| | > | LMA moves pref2 to new | | | > | binding cache entry for if2 | | | > | | | | | > | | | | | > | | (optional) | | | > | | BRI[pref2] | | | > | |---------------->| | | > | | BRA | | | > | |<----------------| | | > | flow y to | flow y to | flow y to | > | pref2::lif | pref2::lif | pref2::lif | > |<----------->|<------------------------------->|<---------->if2 > | | | | | >=20 > Figure 6: Flow mobility message sequence with different set of > prefixes per physical interface (PBU signaling) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 13] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 4. Message formats >=20 > 4.1. Flow Mobility Initiate (FMI) >=20 > The LMA sends an FMI message to a MAG to enable flow mobility. It is > a Mobility Header message. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Sequence Number: >=20 > A monotonically increasing integer. Set by the LMA sending then > initiate message, and used to match a reply in the acknowledge. >=20 > 'I' (initiate) flag: >=20 > Set to 1, indicates it is an FMI message. >=20 > Reserved: >=20 > This field is unused. MUST be set to zero by the sender. >=20 > Lifetime: >=20 > The requested time in seconds for which the LMA asks the MAG keep > flow-specific state. A value of all one bits (0xffff) represents > infinity. If set to 0, it indicates a request to remove state > about the flow (cancel flow mobility) >=20 > Mobility Options: >=20 > MUST contain the MN-ID, followed by one or more Flow > Identification Mobility options [RFC6089]. >=20 >=20 >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 14] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > 4.2. Flow Mobility Acknowledge (FMA) >=20 > The MAG sends an FMI message to the LMA as a response to the FMI > message. It is a Mobility Header message. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| Reserved | Status | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Sequence Number: >=20 > A monotonically increasing integer. Copied from the value set by > the sending LMA in the FMI message being acknowledged by this FMA > message. >=20 > 'I' flag: >=20 > Set to 0, indicates it is an FMA message. >=20 > Reserved: >=20 > This field is unused. MUST be set to zero by the sender. >=20 > Status (values to be assigned by IANA): >=20 > ??: Success. >=20 > ??: Reason unspecified. >=20 > ??: MN not attached. >=20 > ??: Sequence number out of window. >=20 > ??: Traffic Selector format unsupported. >=20 > ??: No existing Flow Mobility Cache entry. >=20 > Lifetime: >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 15] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > The requested time in seconds for which the MAG keeps flow- > specific state. A value of all one bits (0xffff) represents > infinity. >=20 > Mobility Options: >=20 > When Status code is 0, MUST contain the MN-ID, followed by one or > more Flow Identification Mobility options [RFC6089]. >=20 >=20 > 5. Conceptual Data Structures >=20 > 5.1. Multiple Care-of Address Registration >=20 > The LMA is extended to allow a mobile node to register multiple proxy > care of address (Proxy-CoA). >=20 > [marco] That's actually supported by RFC5213, isn't it? Maybe you could > write ' ..to register multiple proxy care of address (Proxy-CoA) while us= ing the > same address (prefix) beyond a single interfaces and MAG' >=20 [Carlos] Yes, thanks for the suggested text. >=20 > The LMA maintains multiple binding > cache entries for an MN. The number of binding cache entries for an > MN is equal to the number of the MN's interfaces attaching to any > MAGs. >=20 > +---------+-----+-------+------+-----------+------------+ > | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | > +---------+-----+-------+------+-----------+------------+ > | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | > | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | > +---------+-----+-------+------+-----------+------------+ >=20 > Figure 7: Extended Binding Cache >=20 > Figure 7 shows two Binding Cache Entries of the MN1 when it is > attached to the network using two different access technologies. > Both of the two attachments share HNP1 and are bounded to two > different Proxy-CoAs. >=20 > 5.2. Flow Mobility Cache >=20 > Each LMA MUST maintain a flow mobility cache (FMC) as shown in > Figure 8. This table MUST contain an entry for each flow sent from > the MN. A flow binding entry includes the following fields: >=20 > o Flow Identifier Priority (FID-PRI). >=20 > o Flow Identifier (FID). >=20 > o Traffic Selector (TS). >=20 > o Binding Identifier (BID). >=20 >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 16] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > o Action. >=20 > o Active/Inactive. >=20 >=20 > +---------+-----+-----+------+---------+----------+ > | FID-PRI | FID | TS | BIDs | Action | A/I | > +---------+-----+-----+------+---------+----------+ > | 10 | 2 | TCP | 1 | Forward | Active | > | 20 | 4 | UDP | 1,2 | Forward | Inactive | > +---------+-----+-----+------+---------+----------+ >=20 > Figure 8: Flow Mobility Cache >=20 > The BID field contains the identifier of the binding cache entry > which packets matching the flow information described in the TS field > will be forwarded to. When a flow is decided to be moved, the > affected BID(s) of the table are updated. >=20 > Similar to flow binding described in [RFC6089], each flow binding > entry points to a specific binding cache entry identifier (BID). > When a flow is moved, the LMA simply updates the pointer of the flow > binding entry with the BID of the interface to which the flow will be > moved. The traffic selector (TS) in flow binding table is defined as > in [RFC6088]. TS is used to classify the packets of flows basing on > specific parameters such as service type, source and destination > address, etc. The packets matching with the same TS will be applied > the same forwarding policy. FID-PRI is the order of precedence to > take action on the traffic. Action may be forward or drop.=20 >=20 > [marco] is flow filtering a new feature of the specification? > I did not see its description in the operations sections. [Carlos] This is the way the LMA performs flow routing, which is needed to perform flow mobility, and mentioned in the document. Do you think we should explicitly mention that we re-use RFC6089 procedures when describing the flow mobility operations in sections 3.2.X? >=20 >=20 > If a > binding entry becomes 'Inactive' it does not affect data traffic. An > entry becomes 'Inactive' only if all of the BIDs are deregistered. >=20 > The Mobile Access Gateway MAY also maintain a similar data structure. > In case no full flow mobility state is required at the MAG, the > Binding Update List (BUL) data structure is enough and no extra > conceptual data entries are needed. In case full per-flow state is > required at the MAG, it SHOULD also maintain a Flow Mobility Cache > structure. >=20 >=20 > [marco] I think this should be one of the most important sections of the > specification. The protocol operation before should refer to the BCE and > the table, where the flow rules are available, and describe the procedure > from packet arrival to the release of the encapsulated packet on the wire= . > What's being looked up first, the Flow Mobility Cache or the BCE? [Carlos] The approach followed here is the same than in RFC 6089, so the FMC is first looked up first. I think this an important aspect to be discussed in the WG. Do we want to extend this section, probably re-using text from RFC6089 to explain in detail how this works? Do we want also to include more details in the Sections 3.2.X about how flow routing is performed and how the signaling defined updates the FMC and extended BCE? >=20 >=20 > 6. Mobile Node considerations >=20 > This specification assumes the MN implements the logical interface > model. >=20 > [marco] it should not, in my opinion. [Carlos] I've updated this section. >=20 >=20 > The "logical interface" at the IP layer hides the use of > different physical media from the IP stack, enabling the MN to send > and receive packets over different interfaces. This document assumes > the MN behaves as stated in the applicability statement document > [I-D.ietf-netext-logical-interface-support]. In particular, it is >=20 >=20 >=20 > Bernardos Expires September 13, 2012 [Page 17] >=20 >=20 > Internet-Draft PMIPv6 flow mobility March 2012 >=20 >=20 > assumed that -- for the case of bidirectional traffic -- the logical > interface at the MN "replicates" the behavior observed for downlink > packets on a per-flow basis. This means that the MN sends UL Flow X > on the same interface which received the DL Flow X. It also means > that if the LMA moves flow X during its lifetime, the MN will follow > that change, upon the reception of packets of flow X via a different > interface. >=20 > This specification only supports flow mobility between different > physical interfaces belonging to the same logical interface. If an > MN has several logical interfaces, flow mobility across different > logical interfaces is not supported. >=20 >=20 > ../snip >=20 >=20 >=20 > Hope it helps. It does indeed. Thanks again for the comments! Carlos >=20 > marco >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Video over Mobile Networks http://www.comsoc.org/netmag/call-papers (EXTENDED: July, 31) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-8TdfOF2fTdTE+EA3RU7v 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.12 (GNU/Linux) iEYEABECAAYFAlAEaIgACgkQNdy6TdFwT2crPgCfd2y21BtoutgCQMZzdI4VZr+h SVwAoLqUG3r7eEuh8YOBgbMayFNjKgQW =mr0A -----END PGP SIGNATURE----- --=-8TdfOF2fTdTE+EA3RU7v-- From cjbc@it.uc3m.es Mon Jul 16 12:15:48 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 7274811E830C for ; Mon, 16 Jul 2012 12:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.667 X-Spam-Level: X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=0.032, 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 xTLSlVC9GYZv for ; Mon, 16 Jul 2012 12:15:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 901BE11E82F8 for ; Mon, 16 Jul 2012 12:15:46 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 90317C3D2F6; Mon, 16 Jul 2012 21:16:30 +0200 (CEST) Message-ID: <1342466190.5049.77.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Zuniga, Juan Carlos" Date: Mon, 16 Jul 2012 21:16:30 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-X4iJOJuP1VGX5E1T4IdN" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1350-6.5.0.1024-19036.005 X-TM-AS-Result: No--32.509-7.0-31-10 X-imss-scan-details: No--32.509-7.0-31-10 X-TMASE-MatchedRID: j4nUk6F+aLZaNYs/JxOwj7xygpRxo469W3jYwshBfqadCqKtxM6bh7y+ AbgLgbEpAHwTf4ujhzzlPWOZdnoFfJxjBzzEqmFVcfsdX+Y7hROC7C2rJeUToSBs0OU9P6tbRtU L4XifTnu4im0X5j1OA6eyKhZEdyKFipM1Zj6B3qt2aFFWhkT3QBLXa2P1m93zRJWmeOMHa+QzBH KsDHLon1ZYRD96EE5oJjac64tbHnfAGaY4XmIHD6ytfdfXBswybd6rGhWOAwQwplGJ7NxS07A3Q 3nP0dUI24Qa/Z56Ho4Eqn6a/3h6KxtEDpEjEWsF87gU9YZmSw9bAoaK+wS4jRYvl21FOKshJ0WR QI2EG7RL0uSHldDmQN/y4J8tbxR4yesd/MvbgTvAJnGRMfFxyTFcf92WG8u/grAXgr/AjP30/2E E/ezCUEXBRTTN1gI9qcsv52UIWyeiSIetIxcPtKAgbKrIL4LaTJDl9FKHbrmSgFxye3PuoZDP6Y RaMaJFl2I2xv+RjW5/XpjeKg+SbxKz3vhHKFOLsyw+ZJnFumRTes6dDCWUQ3zlhuYw8JsTUh2QV WfkzrtuM+DMfvHpno4I+kP0cLT8nY4buaRVSKeJQ9k+Ypk5CcWehUuGOy2PLPCFTY0a70U3ClBV VpXbgPXrF+v5nbG2KDdWDqWcnBIP5kb0rKmFe3VwoTtZdpvXMZm0+sEE9msPyQfrTcMk4AOkuVk kJKW76kKbiMDnAdulYAbwCZOHV2FqPXSLpNdAQr2qXCJMSV91k+gP1XamtDP3WYNhkszl+r4kso UQ8wVYQOjNXw5B6JWD5DDAqPadrD+4De3fSMFGONWF/6P/CkxF1JQZeyoY Cc: netext@ietf.org Subject: Re: [netext] review - draft-ietf-netext-pmipv6-flowmob-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:15:48 -0000 --=-X4iJOJuP1VGX5E1T4IdN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan Carlos, Please see inline below. Since Marco also made some comments regarding the draft, and some are related, I've tried to update the document taking into account both reviews. On Tue, 2012-07-10 at 15:17 -0400, Zuniga, Juan Carlos wrote: > Hi all, >=20 > =20 >=20 > These are the comments I have for draft-ietf-netext-pmipv6-flowmob-03: >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 1. Introduction: >=20 > =20 >=20 > - I would suggest rewriting the second and third paragraph as > follows: >=20 > =20 >=20 > =E2=80=9CPMIPv6 allows an MN to connect to the same PMIPv6 domain through > different interfaces. This document specifies protocol extensions to > Proxy Mobile IPv6 between the LMA and MAGs to enable =E2=80=9Cflow mobili= ty=E2=80=9D > and hence distribute specific traffic flows on different physical > interfaces. It is assumed that an MN IP layer interface can > simultaneously and/or sequentially attach to multiple MAGs, possibly > over multiple media. One form to achieve this multiple attachment is > described in [I-D.ietf-netext-logical-interface-support], which allows > the mobile node supporting traffic flows on different physical > interfaces regardless of the assigned prefixes on those physical > interfaces.=E2=80=9D >=20 [Carlos] OK, thanks for the proposed text. I've modified the draft re-using most of your proposed text. > =20 >=20 > =20 >=20 > 2. Terminology >=20 > =20 >=20 > - It should be =E2=80=9CFMA =E2=80=93 Flow Mobility Acknowledgem= ent=E2=80=9D (several > instances throughout the document) >=20 [Carlos] OK, fixed. > =20 >=20 > =20 >=20 > =20 >=20 > 3.1 Use case scenarios >=20 > =20 >=20 > - I would suggest changing the first paragraph as follows: >=20 > =20 >=20 > =E2=80=9CIn contrast to a typical handover where connectivity to a physic= al medium is relinquished and then re-established, flow mobility assumes a = mobile node can have simultaneous access to more than one network. In this = specification, it is assumed that the LMA is aware of the mobile node=E2=80= =99s capabilities to have simultaneous access to both access networks and i= t can handle the same or a different set of prefixes on each access. How t= his is done is outside the scope of this specification.=E2=80=9D >=20 [Carlos] OK, thanks. > =20 >=20 > - The three numbered scenarios are first described at the > initialization point (i.e. attachment), and then the flow mobility use > case is described for each one of them below in the text. This is > confusing, as at first sight it looks like the numbered paragraphs > contain the whole use case description text. I would suggest > describing each scenario in full in each one of the numbered sections > (e.g. scenario 2 should describe the initial attachment and also the > flow mobility use case to make it clear why it needs signaling > extensions). It would also help adding a reference stating that the > operational description will be provided in sections 3.2.1, 3.2.2, > etc. >=20 [Carlos] OK, thanks. I've tried to implement this change in -04. > =20 >=20 > - Rewrite the last paragraph in section 3.1 as follows: >=20 > =20 >=20 > =E2=80=9CThe extensions described in this document support all the > aforementioned scenarios.=E2=80=9D >=20 > =20 >=20 > =20 >=20 > =20 >=20 > 3 =20 >=20 > 3.1 =20 >=20 > 3.2.1 MN sharing a common set of prefixes on all MAGs=20 >=20 > =20 >=20 > - Remove the following sentence from the paragraph: >=20 > =20 >=20 > =E2=80=9CWhen a multi-interfaced mobile node connects to a PMIPv6-domain,= it > performs regular attachment and as a result is able to configure an IP > address (or a set of IP addresses) on the logical interface hiding the > different physical interfaces.=E2=80=9D >=20 [Carlos] OK, done. > =20 >=20 > - I believe the following should be a MUST: >=20 > =20 >=20 > =E2=80=9CIn this document a new Handoff Indicator (HI) value ("Attachment= over > a new interface sharing prefixes") is defined, to allow the mobile > access gateway indicate to the local mobility anchor that the same set > of prefixes MUST be assigned to the mobile node. The considerations in > Section 5.4.1 of [RFC5213] are updated by this specification as > follows:=E2=80=9D >=20 [Carlos] Fixed. > =20 >=20 > - Suggest promoting the paragraph starting with =E2=80=9CAs desc= ribed > in [I-D.ietf-netext-logical-interface-support]...=E2=80=9D to the end of > section 3.2 (before 3.2.1) and reword as follows: >=20 > =20 >=20 > =E2=80=9CBoth MN and LMA SHOULD have local policies in place that ensure > packets are forwarded coherently for unidirectional and bidirectional > communications. The details about how this consistency is ensured are > out of the scope of this document.=E2=80=9D [Carlos] OK, done. >=20 > =20 >=20 > - I believe the following should be a MUST (+ typo): >=20 > =20 >=20 > =E2=80=9CIn case the MAGs need to be configured to support flow mobility > because of packet policing, packet enforcement, charging or similar > reasons, the LMA MUST re-use the signaling defined later in this > document to convey this information.=E2=80=9D >=20 [Carlos] Fixed. > =20 >=20 > - In the paragraph starting with =E2=80=9CFigure 3 shows the sta= te=E2=80=A6=E2=80=9D, > remove the parenthesis and the text inside. >=20 [Carlos] What parenthesis are you referring to? > =20 >=20 > =20 >=20 > =20 >=20 > 3.2.2 MN with different sets of prefixes on each MAG=20 >=20 > =20 >=20 > - I believe the following should be a MUST >=20 > =20 >=20 > =E2=80=9CIf the flow is being moved from its default path (which is deter= mined > by the destination prefix) to a different one, the LMA constructs a > Flow Mobility Initiate (FMI) message. This message MUST be sent to > the new target MAG, i.e. the one selected to be the used in the > forwarding of the flow...=E2=80=9D >=20 [Carlos] Fixed. > =20 >=20 > - It would probably be clearer to have one section 3.2.1, > 3.2.2 and 3.2.3 for each described scenario (1, 2 and 3), even if the > text in the section simply states that the use case is the same as the > next/previous section. It would make it easier to read back and forth > in the document when searching for specific information about a use > case. [Carlos] Done. >=20 > =20 >=20 > - Figure4: I would suggest exchanging the order of the > optional FMI/FMA messages after the new flow Y through MAG1, as these > messages are not time-critical. >=20 [Carlos] Done. > =20 >=20 > - Figure 6: I would suggest exchanging the order of the > optional BRI/BRA messages after the new flow Y through MAG2, as these > messages are not time-critical.=20 [Carlos] Done. >=20 > =20 >=20 > - I believe the following requirements language is needed > (original paragraphs starting with =E2=80=9COptionally, a message can be > sent=E2=80=A6=E2=80=9D): >=20 > =20 >=20 > =E2=80=9COptionally, a Binding Revocation Indication message [RFC5846] wi= th > the P bit set MAY be sent to MAG1 to indicate that this is a > revocation of PMIP prefix(es). After processing BRI, the source MAG > MUST send a Binding Revocation Acknowledgement (BRA) message back to > the LMA. [Carlos] Done. >=20 > =20 >=20 > - Move the paragraph starting with =E2=80=9CIn case flow mobilit= y is > needed with a finer granularity=E2=80=A6=E2=80=9D) to after Figure 6, and= reword with > requirements language as follows: >=20 > =20 >=20 > =E2=80=9CIn case flow mobility is needed with a finer granularity (e.g., = flow > level instead of full prefix), a Flow Identification Mobility option > (specified in [RFC6089]) that can convey full flow information MUST be > included in the PBA. The MAG MAY also include the Flow Identification > Mobility option in the PBU message that it sends to the LMA. This > serves as a request from MAG to LMA to consider the flow policy rules > specified in the option. In this case, no prefix is removed from any > MAG because the movement is performed at a flow level.=E2=80=9D >=20 [Carlos] Done. > =20 >=20 > =20 >=20 > 4. Messages >=20 > =20 >=20 > - Add the following sentence to the beginning of the section: >=20 > =20 >=20 > =E2=80=9CThis section defines extensions to the Proxy Mobile IPv6 [RFC521= 3] > protocol messages=E2=80=9D [Carlos] Done. >=20 > =20 >=20 > 4.1 Flow Mobility Initiate (FMI) >=20 > =20 >=20 > - Replace =E2=80=9Cacknowledge=E2=80=9D by =E2=80=9Cacknowledgem= ent=E2=80=9D in the =E2=80=9CSequence > Number:=E2=80=9D description >=20 [Carlos] Fixed. > =20 >=20 > =20 >=20 > =20 >=20 > I hope you find these comments useful. I did indeed. Thanks again for providing them. Carlos >=20 > =20 >=20 > Best regards, >=20 > =20 >=20 > Juan Carlos >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Video over Mobile Networks http://www.comsoc.org/netmag/call-papers (EXTENDED: July, 31) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-X4iJOJuP1VGX5E1T4IdN 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.12 (GNU/Linux) iEYEABECAAYFAlAEaI4ACgkQNdy6TdFwT2fdmQCdGcKOI1MnwBp4Oho+o67RmHY+ ph0An0V9wb1gH6KDaEsHS0BYdsqc16iS =Lpuq -----END PGP SIGNATURE----- --=-X4iJOJuP1VGX5E1T4IdN-- From michael.boc@cea.fr Mon Jul 16 13:06:47 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 DC1B411E8159 for ; Mon, 16 Jul 2012 13:06:47 -0700 (PDT) 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=4.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0oEA4RpbPD3k for ; Mon, 16 Jul 2012 13:06:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A461811E8298 for ; Mon, 16 Jul 2012 13:06:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6GK7RTQ028658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Jul 2012 22:07:27 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6GK7Rqb001432 for ; Mon, 16 Jul 2012 22:07:27 +0200 (envelope-from michael.boc@cea.fr) Received: from EXCAH-A0.intra.cea.fr (excah-a0.intra.cea.fr [132.166.88.74]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6GK7QxD023755 for ; Mon, 16 Jul 2012 22:07:26 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by EXCAH-A0.intra.cea.fr ([fe80::446e:fe1a:2892:9de1%11]) with mapi id 14.01.0339.001; Mon, 16 Jul 2012 22:07:26 +0200 From: BOC Michael To: "netext@ietf.org" Thread-Topic: New Version Notification for draft-boc-netext-lr-roext-03.txt Thread-Index: AQHNY4yQG2TvA5T6rEOpc4nVg1EgKpcsUwaf Date: Mon, 16 Jul 2012 20:07:25 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA339380355A644@EXDAG0-B3.intra.cea.fr> References: <20120716195148.1662.5800.idtracker@ietfa.amsl.com> In-Reply-To: <20120716195148.1662.5800.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.167.194.4] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19042.006 x-tm-as-result: No--20.314800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] RE : New Version Notification for draft-boc-netext-lr-roext-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: Mon, 16 Jul 2012 20:06:48 -0000 Hello NetExt WG,=0A= =0A= We have submitted an update of a draft we think may be an extension to PMIP= -LR operations.=0A= =0A= In this draft we propose to better control the data path by adding intermed= iate data anchors (IAs).=0A= One IA is a PMIPv6 functionality located on the optimized path, which ancho= r the data traffic to =0A= perform operator's services.=0A= =0A= On one hand we reduce the load at the LMA (as in PMIP-LR), which is one of = the main objective =0A= of localized routing and routing optimization. On the other hand, we also c= ontribute through =0A= intermediate data anchors (IAs) to maintain a control on the data path to p= erform services =0A= such as lawful interception, charging, content filtering. =0A= =0A= =0A= >>>>>>>>=0A= =0A= A new version of I-D, draft-boc-netext-lr-roext-03.txt=0A= has been successfully submitted by Michael Mathias Boc and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-boc-netext-lr-roext=0A= Revision: 03=0A= Title: RO Extensions for PMIPv6-LR (ROEXT)=0A= Creation date: 2012-07-16=0A= WG ID: Individual Submission=0A= Number of pages: 16=0A= URL: http://www.ietf.org/internet-drafts/draft-boc-netext-lr-ro= ext-03.txt=0A= Status: http://datatracker.ietf.org/doc/draft-boc-netext-lr-roext= =0A= Htmlized: http://tools.ietf.org/html/draft-boc-netext-lr-roext-03=0A= Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-boc-netext-lr-r= oext-03=0A= =0A= Abstract:=0A= The communication path between two Hosts within a Proxy Mobile IPv6=0A= domain is artificially long - it involves the LMA, even if straight=0A= paths exist (under same MAG, or MAG-to-MAG). Localized Routing=0A= PMIPv6-LR concepts developped by NETEXT WG make use of LRI/LRA=0A= messages to achieve optimized MAG-to-MAG straight paths. This may=0A= prove inconvenient for the network operator, in that it may loose=0A= ability to control traffic (LMA control point is skipped).=0A= =0A= In this draft we present a middle-ground solution. It employs new=0A= Intermediary Anchors (IAs) in the paths between MAGs and offers=0A= points of control of traffic useful for QoS and lawful interception.=0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= From internet-drafts@ietf.org Mon Jul 16 15:51:11 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 432E711E8189; Mon, 16 Jul 2012 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 JcmJQuau00fR; Mon, 16 Jul 2012 15:51:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4411E8156; Mon, 16 Jul 2012 15:51:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716225110.15605.17405.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:51:10 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:51:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : 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-11.txt Pages : 18 Date : 2012-07-16 Abstract: The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-access-network-option-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-access-network-optio= n-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Basavaraj.Patil@nokia.com Tue Jul 17 14:01:36 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 7015E11E80A6 for ; Tue, 17 Jul 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 LrDZrXZxFHOy for ; Tue, 17 Jul 2012 14:01:36 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C780311E80A5 for ; Tue, 17 Jul 2012 14:01:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6HL2HQH024185 for ; Wed, 18 Jul 2012 00:02:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jul 2012 00:02:49 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Tue, 17 Jul 2012 23:02:16 +0200 From: To: Thread-Topic: Draft agenda of WG meeting at IETF84 Thread-Index: AQHNZF9xr2wxVcibI0aeWVqEfs18SA== Date: Tue, 17 Jul 2012 21:02:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.85] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D427C8BE2D0CB4E806EDE43B699A4C1@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2012 21:02:49.0072 (UTC) FILETIME=[85A8DF00:01CD645F] X-Nokia-AV: Clean Subject: [netext] Draft agenda of WG meeting at IETF84 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:01:36 -0000 Rev: 0 Network-Based Mobility Extensions (NetExt) WG meeting Thursday, August 2nd, 2012 1300-1500 Afternoon Session I (Regency E) ----------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 20 Mins I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos 4. Prefix Delegation for Proxy Mobile IPv6 5 Mins I-D: draft-ietf-netext-pd-pmip Carl Williams 5. EAP Attributes for WiFi - EPC Integration 10 Mins I-D: draft-ietf-netext-wifi-epc-eap-attributes R. Koodli Proposals for consideration: 1. Mapping PMIP Quality of Service in WiFi 10 mins I-D: draft-kaippallimalil-netext-pmip-qos-wifi J. Kaippallimalil 2. Network Mobility with Proxy Mobile IPv6 10 mins I-D: draft-petrescu-netext-pmip-nemo A. Petrescu 3. PMIPv6 Multihoming Support for Flow Mobility 10 Mins I-D: draft-sarikaya-netext-fb-support-extensions B. Sarikaya Remote participation info: TBD Presentation slides will be available 2 hours prior to the meeting. From zhou.xingyue@zte.com.cn Thu Jul 19 19:20:47 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 99C4311E8072; Thu, 19 Jul 2012 19:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 6grT0TmfbnbS; Thu, 19 Jul 2012 19:20:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5511E80BE; Thu, 19 Jul 2012 19:20:42 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107235771751954; Fri, 20 Jul 2012 10:12:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 28955.6127390430; Fri, 20 Jul 2012 10:21:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6K2LPGG004023; Fri, 20 Jul 2012 10:21:25 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: <94D2EEADE1F74740979E8041CBA339380355A4EB@EXDAG0-B3.intra.cea.fr> To: BOC Michael MIME-Version: 1.0 X-KeepSent: 483CD781:DF06E9B0-48257A41:000AE6D9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 20 Jul 2012 10:21:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-20 10:21:26, Serialize complete at 2012-07-20 10:21:26 Content-Type: multipart/alternative; boundary="=_alternative 000CEE4548257A41_=" X-MAIL: mse02.zte.com.cn q6K2LPGG004023 Cc: "netext@ietf.org" , netext-bounces@ietf.org, "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: [netext] =?gb2312?b?tPC4tDogUmU6ICBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm?= =?gb2312?b?LW5ldGV4dC1wZC1wbWlwLTAzLnR4dA==?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 02:20:47 -0000 This is a multipart message in MIME format. --=_alternative 000CEE4548257A41_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBwdXJwb3NlIG9mIHNldHRpbmcgUiBmbGFnIGlzIHRvIGluZGljYXRlIHRoZSBu ZXR3b3JrIHRoYXQgbmV0d29yayANCm1vYmlsaXR5IHNlcnZpY2UgaXMgYWxsb3dlZCB0byB0aGUg bW9iaWxlIG5vZGUgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gDQozLjIuIEluIHRoaXMgZHJhZnQs IGl0IGp1c3QgZm9jdXMgb24gdGhlIHdheSB0byBhc3NpZ24gdGhlIE1OUCB0byB0aGUgTVIgDQpi YXNlZCBvbiBESENQdjYtUEQgdHJpZ2dlcmluZyBtZWNoYW5pc20uDQoNClJlZ2FyZGluZyB0aGUg cG9zc2libGUgaGludHMgaW4gSUFfUEQocyksIEkgZG9udCBnZXQgeW91ciBwb2ludCB2ZXJ5IG11 Y2guIA0KQ291bGQgeW91IGV4cGxhaW4gbW9yZT8NCg0KQmVzdCBSZWdhcmRzLA0KSm95DQoNCm5l dGV4dC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTA3LTE2IDE3OjEyOjU2Og0KDQo+IEhl bGxvIGFsbCwNCj4gDQo+IENvbmNlcm5pbmcgdGhpcyBkcmFmdCwgSSB3b3VsZCBsaWtlIHRvIGtu b3cgd2h5IHlvdSBuZWVkIHRvIHNldCB0aGUgDQo+IFIgZmxhZyBpbiBQQlUgDQo+IChiZWNhdXNl IHlvdSBkb24ndCBleHBsYWluIGl0IGluIHRoZSBkcmFmdCkgYW5kIGlmIHlvdXIgYXBwcm9hY2gg aXMgDQo+IHRvIG5vdCB0YWtlIA0KPiBpbnRvIGFjY291bnQgcG9zc2libGUgaGludHMgaW4gSUFf UEQocykuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHdlDQo+IGp1c3QgaGF2ZSB0byBwcm92aWRlIA0K PiBNTlAocykgYXQgTVIgYXR0YWNobWVudCB3aXRoIHRoZSBITlAocykgYW5kIHdlIG1vdmUgb24g YW5vdGhlciBzdWJqZWN0LiAgDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiANCj4gTWljaGFlbA0K PiANCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBuZXRleHQt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYQ0K PiA+IHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4gRW52b3nDqSA6IGx1bmRp IDE2IGp1aWxsZXQgMjAxMiAwMzoyOQ0KPiA+IMOAIDogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ ID4gQ2MgOiBuZXRleHRAaWV0Zi5vcmcNCj4gPiBPYmpldCA6IFtuZXRleHRdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0DQo+ID4gDQo+ID4gDQo+ID4gQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzDQo+ID4gZGlyZWN0b3JpZXMuDQo+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIE5ldHdvcmstQmFzZWQgTW9iaWxpdHkgRXh0ZW5zaW9ucw0KPiA+IFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuDQo+ID4gDQo+ID4gICAgVGl0bGUgICAgICAgICAgIDogUHJlZml4IERlbGVn YXRpb24gZm9yIFByb3h5IE1vYmlsZSBJUHY2DQo+ID4gICAgQXV0aG9yKHMpICAgICAgIDogWGlu Z3l1ZSBaaG91DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb3VuaSBLb3Job25lbg0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybCBXaWxsaWFtcw0KPiA+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgU3JpIEd1bmRhdmVsbGkNCj4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIENhcmxvcyBKLiBCZXJuYXJkb3MNCj4gPiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dA0KPiA+ICAgIFBhZ2VzICAgICAgICAgICA6IDE2 DQo+ID4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0wNy0xNQ0KPiA+IA0KPiA+IEFic3RyYWN0 Og0KPiA+ICAgIFByb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9yIGEgaG9z dCB3aXRob3V0IHJlcXVpcmluZw0KPiA+ICAgIGl0cyBwYXJ0aWNpcGF0aW9uIGluIGFueSBtb2Jp bGl0eSBzaWduYWxpbmcsIGJlaW5nIHRoZSBuZXR3b3JrDQo+ID4gICAgcmVzcG9uc2libGUgZm9y IG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZiB0aGUgaG9zdC4NCj4gPiBIb3dldmVy LA0KPiA+ICAgIFByb3h5IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEg cHJlZml4IHRvIGEgcm91dGVyDQo+ID4gYW5kDQo+ID4gICAgbWFuYWdpbmcgaXRzIElQIG1vYmls aXR5LiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvDQo+ID4gICAgUHJv eHkgTW9iaWxlIElQdjYgcHJvdG9jb2wgZm9yIHN1cHBvcnRpbmcgbmV0d29yayBtb2JpbGl0eSB1 c2luZw0KPiA+ICAgIERIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi4NCj4gPiANCj4gPiAN Cj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGV4dC1w ZC1wbWlwDQo+ID4gDQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQt cGQtcG1pcC0wMw0KPiA+IA0KPiA+IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1uZXRleHQtcGQtcG1pcC0wMw0KPiA+IA0KPiA+IA0KPiA+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiA+IG5l dGV4dEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0ZXh0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KDQo= --=_alternative 000CEE4548257A41_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHB1cnBvc2Ugb2Ygc2V0dGluZyBS IGZsYWcgaXMgdG8NCmluZGljYXRlIHRoZSBuZXR3b3JrIHRoYXQgbmV0d29yayBtb2JpbGl0eSBz ZXJ2aWNlIGlzIGFsbG93ZWQgdG8gdGhlIG1vYmlsZQ0Kbm9kZSBhcyBzcGVjaWZpZWQgaW4gc2Vj dGlvbiAzLjIuIEluIHRoaXMgZHJhZnQsIGl0IGp1c3QgZm9jdXMgb24gdGhlIHdheQ0KdG8gYXNz aWduIHRoZSBNTlAgdG8gdGhlIE1SIGJhc2VkIG9uIERIQ1B2Ni1QRCB0cmlnZ2VyaW5nIG1lY2hh bmlzbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJl Z2FyZGluZyB0aGUgcG9zc2libGUgaGludHMgaW4gSUFfUEQocyksDQpJIGRvbnQgZ2V0IHlvdXIg cG9pbnQgdmVyeSBtdWNoLiBDb3VsZCB5b3UgZXhwbGFpbiBtb3JlPzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Sm95PC9mb250Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTItMDctMTYg MTc6MTI6NTY6PGJyPg0KPGJyPg0KJmd0OyBIZWxsbyBhbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IENvbmNlcm5pbmcgdGhpcyBkcmFmdCwgSSB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IHlvdSBuZWVk IHRvIHNldCB0aGUNCjxicj4NCiZndDsgUiBmbGFnIGluIFBCVSA8YnI+DQomZ3Q7IChiZWNhdXNl IHlvdSBkb24ndCBleHBsYWluIGl0IGluIHRoZSBkcmFmdCkgYW5kIGlmIHlvdXIgYXBwcm9hY2gg aXMNCjxicj4NCiZndDsgdG8gbm90IHRha2UgPGJyPg0KJmd0OyBpbnRvIGFjY291bnQgcG9zc2li bGUgaGludHMgaW4gSUFfUEQocykuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHdlPGJyPg0KJmd0OyBq dXN0IGhhdmUgdG8gcHJvdmlkZSA8YnI+DQomZ3Q7IE1OUChzKSBhdCBNUiBhdHRhY2htZW50IHdp dGggdGhlIEhOUChzKSBhbmQgd2UgbW92ZSBvbiBhbm90aGVyIHN1YmplY3QuDQombmJzcDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgTWljaGFlbDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IERlJm5ic3A7OiBuZXRleHQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXQ0KRGUgbGE8YnI+DQom Z3Q7ICZndDsgcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg RW52b3nDqSZuYnNwOzogbHVuZGkgMTYganVpbGxldCAyMDEyIDAzOjI5PGJyPg0KJmd0OyAmZ3Q7 IMOAJm5ic3A7OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgQ2MmbmJzcDs6 IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBPYmpldCZuYnNwOzogW25ldGV4dF0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQ8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7ICZndDsg ZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIE5ldHdvcmstQmFzZWQgTW9iaWxpdHkNCkV4dGVuc2lvbnM8YnI+DQomZ3Q7ICZn dDsgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogUHJlZml4DQpEZWxlZ2F0aW9uIGZvciBQcm94eSBNb2JpbGUgSVB2Njxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7QXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogWGluZ3l1ZSBa aG91PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSm91 bmkgS29yaG9uZW48YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBDYXJsIFdpbGxpYW1zPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgU3JpIEd1bmRhdmVsbGk8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBDYXJsb3MgSi4gQmVybmFyZG9zPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWll dGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQYWdl cyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTY8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6DQoyMDEyLTA3LTE1PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBYnN0cmFjdDo8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAg bW9iaWxpdHkgZm9yIGEgaG9zdA0Kd2l0aG91dCByZXF1aXJpbmc8YnI+DQomZ3Q7ICZndDsgJm5i c3A7ICZuYnNwO2l0cyBwYXJ0aWNpcGF0aW9uIGluIGFueSBtb2JpbGl0eSBzaWduYWxpbmcsIGJl aW5nDQp0aGUgbmV0d29yazxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cmVzcG9uc2libGUg Zm9yIG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZg0KdGhlIGhvc3QuPGJyPg0KJmd0 OyAmZ3Q7IEhvd2V2ZXIsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUg SVB2NiBkb2VzIG5vdCBzdXBwb3J0IGFzc2lnbmluZyBhIHByZWZpeA0KdG8gYSByb3V0ZXI8YnI+ DQomZ3Q7ICZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDttYW5hZ2luZyBpdHMg SVAgbW9iaWxpdHkuICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzDQphbiBleHRlbnNpb24g dG88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmlsZSBJUHY2IHByb3RvY29s IGZvciBzdXBwb3J0aW5nIG5ldHdvcmsNCm1vYmlsaXR5IHVzaW5nPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtESENQdjYtYmFzZWQgUHJlZml4IERlbGVnYXRpb24uPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Ojxicj4NCiZndDsgJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGV4dC1wZC1wbWlwLTAzPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBIGRp ZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7ICZndDsg aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGV4dC1wZC1w bWlwLTAzPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4N CiZndDsgJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgbmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsg Jmd0OyBuZXRleHRAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBuZXRleHQgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBuZXRleHRAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0ZXh0PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 000CEE4548257A41_=-- From michael.boc@cea.fr Thu Jul 19 23:12: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 2115521F8575; Thu, 19 Jul 2012 23:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9JJglKgDgcX; Thu, 19 Jul 2012 23:12:10 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEFC21F856F; Thu, 19 Jul 2012 23:12:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6K6D2wK027060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jul 2012 08:13:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6K6D16F003305; Fri, 20 Jul 2012 08:13:01 +0200 (envelope-from michael.boc@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6K6D1xm020177; Fri, 20 Jul 2012 08:13:01 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Fri, 20 Jul 2012 08:13:00 +0200 From: BOC Michael To: "zhou.xingyue@zte.com.cn" Thread-Topic: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-03.txt Thread-Index: AQHNYvKCvhAGL3znHEuOVmE7wTRHpJcrmk7ggAW68ICAAF62SA== Date: Fri, 20 Jul 2012 06:12:59 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA339380355AC45@EXDAG0-B3.intra.cea.fr> References: <94D2EEADE1F74740979E8041CBA339380355A4EB@EXDAG0-B3.intra.cea.fr>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.167.194.4] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19052.002 x-tm-as-result: No--32.266600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_94D2EEADE1F74740979E8041CBA339380355AC45EXDAG0B3intrace_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "netext-bounces@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: [netext] RE : Re: I-D Action: draft-ietf-netext-pd-pmip-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: Fri, 20 Jul 2012 06:12:12 -0000 --_000_94D2EEADE1F74740979E8041CBA339380355AC45EXDAG0B3intrace_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5LA0KDQpPaywgbm93IEkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgZHJhZnQgaXMgYWJvdXQgdXNp bmcgREhDUHY2LVBEIHNpZ25hbGxpbmcgbWVzc2FnZXMgdG8gdHJpZ2dlciBhIHNwZWNpZmljIGJl aGF2aW9yIG9mIFBNSVB2NiBhbmQgbm90IGF0IGFsbCBhYm91dCB1c2luZyBESENQdjYgYW5kIGl0 cyBQRCBleHRlbnNpb24gdG8gcHJvdmlkZSBNTlBzIHRvIFBNSVB2NiBhbmQgYnkgZXh0ZW5zaW9u IHRvIHRoZSBNUi4NCg0KVHdvIChtb3JlKSBlZmZpY2llbnQgc29sdXRpb25zIGZvciB0aGlzIGFw cHJvYWNoOg0KMSkgWW91IGRvbid0IG5lZWQgREhDUHY2IGVudGl0aWVzIChkZWxlZ2F0aW5nIHJv dXRlciwgREhDUHY2IHJlbGF5IGFuZCBzbyBvbikuIFlvdSBqdXN0IG5lZWQgdG8gaW50ZXJjZXB0 IERIQ1B2Ni1QRCByZWxhdGVkIG1lc3NhZ2VzIGFuZCB0byBlbmhhbmNlcyBMTUEgdG8gZGVsaXZl ciBwcmVmaXhlcyBzaG9ydGVyIHRoYW4gNjQgYml0cy4NCjIpIFlvdSBkZWxpdmVyIEhOUHMgYW5k IE1OUHMgKHdpdGggcHJlZml4ZXMgc2hvcnRlciB0aGFuIDY0IGJpdHMpIGZvciBldmVyeSBub2Rl cy4gVGhpcyBpcyBhIGNvdXBsZSBvZiBsaW5lcyB0byBhZGQgaW4gUkZDNTIxMy4NCg0KT3VyIGFw cHJvYWNoIGNhbiB0aGVuIGJlIHNlZW4gYXMgb25lIHN0ZXAgZnVydGhlciBpbiBpbnRlZ3JhdGlu ZyBhIHJlYWwgREhDUHY2IGFyY2hpdGVjdHVyZSBpbiBwYXJhbGxlbCBvZiBQTUlQdjYgdG8gZGVs aXZlciBNTlBzIHRvIG1vYmlsZSByb3V0ZXJzLg0KDQpNaWNoYWVsDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpEZSA6IHpob3UueGluZ3l1ZUB6dGUuY29tLmNuIFt6aG91Lnhp bmd5dWVAenRlLmNvbS5jbl0NCkRhdGUgZCdlbnZvaSA6IHZlbmRyZWRpIDIwIGp1aWxsZXQgMjAx MiAwNDoyMQ0Kw4AgOiBCT0MgTWljaGFlbA0KQ2MgOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc7IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsgbmV0ZXh0QGlldGYub3JnOyBuZXRleHQtYm91bmNlc0Bp ZXRmLm9yZw0KT2JqZXQgOiDnrZTlpI06IFJlOiBbbmV0ZXh0XSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dA0KDQoNCkhpLA0KDQpUaGUgcHVycG9zZSBvZiBzZXR0 aW5nIFIgZmxhZyBpcyB0byBpbmRpY2F0ZSB0aGUgbmV0d29yayB0aGF0IG5ldHdvcmsgbW9iaWxp dHkgc2VydmljZSBpcyBhbGxvd2VkIHRvIHRoZSBtb2JpbGUgbm9kZSBhcyBzcGVjaWZpZWQgaW4g c2VjdGlvbiAzLjIuIEluIHRoaXMgZHJhZnQsIGl0IGp1c3QgZm9jdXMgb24gdGhlIHdheSB0byBh c3NpZ24gdGhlIE1OUCB0byB0aGUgTVIgYmFzZWQgb24gREhDUHY2LVBEIHRyaWdnZXJpbmcgbWVj aGFuaXNtLg0KDQpSZWdhcmRpbmcgdGhlIHBvc3NpYmxlIGhpbnRzIGluIElBX1BEKHMpLCBJIGRv bnQgZ2V0IHlvdXIgcG9pbnQgdmVyeSBtdWNoLiBDb3VsZCB5b3UgZXhwbGFpbiBtb3JlPw0KDQpC ZXN0IFJlZ2FyZHMsDQpKb3kNCg0KbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTIt MDctMTYgMTc6MTI6NTY6DQoNCj4gSGVsbG8gYWxsLA0KPg0KPiBDb25jZXJuaW5nIHRoaXMgZHJh ZnQsIEkgd291bGQgbGlrZSB0byBrbm93IHdoeSB5b3UgbmVlZCB0byBzZXQgdGhlDQo+IFIgZmxh ZyBpbiBQQlUNCj4gKGJlY2F1c2UgeW91IGRvbid0IGV4cGxhaW4gaXQgaW4gdGhlIGRyYWZ0KSBh bmQgaWYgeW91ciBhcHByb2FjaCBpcw0KPiB0byBub3QgdGFrZQ0KPiBpbnRvIGFjY291bnQgcG9z c2libGUgaGludHMgaW4gSUFfUEQocykuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHdlDQo+IGp1c3Qg aGF2ZSB0byBwcm92aWRlDQo+IE1OUChzKSBhdCBNUiBhdHRhY2htZW50IHdpdGggdGhlIEhOUChz KSBhbmQgd2UgbW92ZSBvbiBhbm90aGVyIHN1YmplY3QuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+DQo+ IE1pY2hhZWwNCj4NCj4NCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZSA6 IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhDQo+ID4gcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiBFbnZvecOp IDogbHVuZGkgMTYganVpbGxldCAyMDEyIDAzOjI5DQo+ID4gw4AgOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmcNCj4gPiBDYyA6IG5ldGV4dEBpZXRmLm9yZw0KPiA+IE9iamV0IDogW25ldGV4dF0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQNCj4gPg0KPiA+DQo+ID4g QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzDQo+ID4gZGlyZWN0b3JpZXMuDQo+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIE5ldHdvcmstQmFzZWQgTW9iaWxpdHkgRXh0ZW5zaW9ucw0KPiA+IFdvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuDQo+ID4NCj4gPiAgICBUaXRsZSAgICAgICAgICAgOiBQcmVmaXgg RGVsZWdhdGlvbiBmb3IgUHJveHkgTW9iaWxlIElQdjYNCj4gPiAgICBBdXRob3IocykgICAgICAg OiBYaW5neXVlIFpob3UNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvdW5pIEtvcmhv bmVuDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBDYXJsIFdpbGxpYW1zDQo+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICBTcmkgR3VuZGF2ZWxsaQ0KPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2FybG9zIEouIEJlcm5hcmRvcw0KPiA+ICAgIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0DQo+ID4gICAgUGFnZXMgICAgICAgICAg IDogMTYNCj4gPiAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA3LTE1DQo+ID4NCj4gPiBBYnN0 cmFjdDoNCj4gPiAgICBQcm94eSBNb2JpbGUgSVB2NiBlbmFibGVzIElQIG1vYmlsaXR5IGZvciBh IGhvc3Qgd2l0aG91dCByZXF1aXJpbmcNCj4gPiAgICBpdHMgcGFydGljaXBhdGlvbiBpbiBhbnkg bW9iaWxpdHkgc2lnbmFsaW5nLCBiZWluZyB0aGUgbmV0d29yaw0KPiA+ICAgIHJlc3BvbnNpYmxl IGZvciBtYW5hZ2luZyBJUCBtb2JpbGl0eSBvbiBiZWhhbGYgb2YgdGhlIGhvc3QuDQo+ID4gSG93 ZXZlciwNCj4gPiAgICBQcm94eSBNb2JpbGUgSVB2NiBkb2VzIG5vdCBzdXBwb3J0IGFzc2lnbmlu ZyBhIHByZWZpeCB0byBhIHJvdXRlcg0KPiA+IGFuZA0KPiA+ICAgIG1hbmFnaW5nIGl0cyBJUCBt b2JpbGl0eS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGV4dGVuc2lvbiB0bw0KPiA+ICAg IFByb3h5IE1vYmlsZSBJUHY2IHByb3RvY29sIGZvciBzdXBwb3J0aW5nIG5ldHdvcmsgbW9iaWxp dHkgdXNpbmcNCj4gPiAgICBESENQdjYtYmFzZWQgUHJlZml4IERlbGVnYXRpb24uDQo+ID4NCj4g Pg0KPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0ZXh0 LXBkLXBtaXANCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0ZXh0 LXBkLXBtaXAtMDMNCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1uZXRleHQtcGQtcG1pcC0wMw0KPiA+DQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiA+IG5ldGV4 dEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 ZXh0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+DQo= --_000_94D2EEADE1F74740979E8041CBA339380355AC45EXDAG0B3intrace_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIx IiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhv bWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+SGV5LA0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+T2ssIG5vdyBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGRyYWZ0IGlzIGFib3V0IHVz aW5nIERIQ1B2Ni1QRCBzaWduYWxsaW5nIG1lc3NhZ2VzIHRvIHRyaWdnZXIgYSBzcGVjaWZpYyBi ZWhhdmlvciBvZiBQTUlQdjYgYW5kIG5vdCBhdCBhbGwgYWJvdXQgdXNpbmcgREhDUHY2IGFuZCBp dHMgUEQgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgTU5QcyB0byBQTUlQdjYgYW5kIGJ5IGV4dGVuc2lv biB0byB0aGUgTVIuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ud28gKG1v cmUpIGVmZmljaWVudCBzb2x1dGlvbnMgZm9yIHRoaXMgYXBwcm9hY2g6PC9kaXY+DQo8ZGl2PjEp IFlvdSBkb24ndCBuZWVkIERIQ1B2NiBlbnRpdGllcyAoZGVsZWdhdGluZyByb3V0ZXIsIERIQ1B2 NiByZWxheSBhbmQgc28gb24pLiBZb3UganVzdCBuZWVkIHRvIGludGVyY2VwdCBESENQdjYtUEQg cmVsYXRlZCBtZXNzYWdlcyBhbmQgdG8gZW5oYW5jZXMgTE1BIHRvIGRlbGl2ZXIgcHJlZml4ZXMg c2hvcnRlciB0aGFuIDY0IGJpdHMuPC9kaXY+DQo8ZGl2PjIpIFlvdSBkZWxpdmVyIEhOUHMgYW5k IE1OUHMgKHdpdGggcHJlZml4ZXMgc2hvcnRlciB0aGFuIDY0IGJpdHMpIGZvciBldmVyeSBub2Rl cy4gVGhpcyBpcyBhIGNvdXBsZSBvZiBsaW5lcyB0byBhZGQgaW4gUkZDNTIxMy48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk91ciBhcHByb2FjaCBjYW4gdGhlbiBiZSBzZWVuIGFzIG9u ZSBzdGVwIGZ1cnRoZXIgaW4gaW50ZWdyYXRpbmcgYSByZWFsIERIQ1B2NiBhcmNoaXRlY3R1cmUg aW4gcGFyYWxsZWwgb2YgUE1JUHY2IHRvIGRlbGl2ZXIgTU5QcyB0byBtb2JpbGUgcm91dGVycy48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1pY2hhZWw8L2Rpdj4NCjxkaXY+PGJyPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbjsgY29sb3I6ICMwMDAwMDA7 IGZvbnQtc2l6ZTogMTZweCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwRjc0 MTI3MiIgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyAiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0i MiIgY29sb3I9IiMwMDAwMDAiPjxiPkRlIDo8L2I+IHpob3UueGluZ3l1ZUB6dGUuY29tLmNuIFt6 aG91Lnhpbmd5dWVAenRlLmNvbS5jbl08YnI+DQo8Yj5EYXRlIGQnZW52b2kgOjwvYj4gdmVuZHJl ZGkgMjAganVpbGxldCAyMDEyIDA0OjIxPGJyPg0KPGI+w4AgOjwvYj4gQk9DIE1pY2hhZWw8YnI+ DQo8Yj5DYyA6PC9iPiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc7IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzsgbmV0ZXh0QGlldGYub3JnOyBuZXRleHQtYm91bmNlc0BpZXRmLm9yZzxicj4NCjxiPk9i amV0IDo8L2I+IOetlOWkjTogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0 ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4N CjxkaXY+PGJyPg0KPGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+SGksPC9mb250PiA8 YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgcHVycG9zZSBv ZiBzZXR0aW5nIFIgZmxhZyBpcyB0byBpbmRpY2F0ZSB0aGUgbmV0d29yayB0aGF0IG5ldHdvcmsg bW9iaWxpdHkgc2VydmljZSBpcyBhbGxvd2VkIHRvIHRoZSBtb2JpbGUgbm9kZSBhcyBzcGVjaWZp ZWQgaW4gc2VjdGlvbiAzLjIuIEluIHRoaXMgZHJhZnQsIGl0IGp1c3QgZm9jdXMgb24gdGhlIHdh eSB0byBhc3NpZ24gdGhlIE1OUCB0byB0aGUgTVIgYmFzZWQgb24gREhDUHY2LVBEDQogdHJpZ2dl cmluZyBtZWNoYW5pc20uPC9mb250PiA8YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJz YW5zLXNlcmlmIj5SZWdhcmRpbmcgdGhlIHBvc3NpYmxlIGhpbnRzIGluIElBX1BEKHMpLCBJIGRv bnQgZ2V0IHlvdXIgcG9pbnQgdmVyeSBtdWNoLiBDb3VsZCB5b3UgZXhwbGFpbiBtb3JlPzwvZm9u dD4NCjxicj4NCjxicj4NCjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVn YXJkcyw8L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPkpveTwv Zm9udD4gPGJyPg0KPGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPm5ldGV4dC1ib3VuY2VzQGlldGYu b3JnIOWGmeS6jiAyMDEyLTA3LTE2IDE3OjEyOjU2Ojxicj4NCjxicj4NCiZndDsgSGVsbG8gYWxs LDxicj4NCiZndDsgPGJyPg0KJmd0OyBDb25jZXJuaW5nIHRoaXMgZHJhZnQsIEkgd291bGQgbGlr ZSB0byBrbm93IHdoeSB5b3UgbmVlZCB0byBzZXQgdGhlIDxicj4NCiZndDsgUiBmbGFnIGluIFBC VSA8YnI+DQomZ3Q7IChiZWNhdXNlIHlvdSBkb24ndCBleHBsYWluIGl0IGluIHRoZSBkcmFmdCkg YW5kIGlmIHlvdXIgYXBwcm9hY2ggaXMgPGJyPg0KJmd0OyB0byBub3QgdGFrZSA8YnI+DQomZ3Q7 IGludG8gYWNjb3VudCBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKS4gSWYgdGhpcyBpcyB0aGUg Y2FzZSwgd2U8YnI+DQomZ3Q7IGp1c3QgaGF2ZSB0byBwcm92aWRlIDxicj4NCiZndDsgTU5QKHMp IGF0IE1SIGF0dGFjaG1lbnQgd2l0aCB0aGUgSE5QKHMpIGFuZCB3ZSBtb3ZlIG9uIGFub3RoZXIg c3ViamVjdC4gJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1pY2hhZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsgJmd0OyBEZSZu YnNwOzogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGE8YnI+DQomZ3Q7ICZndDsgcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8YnI+DQomZ3Q7ICZndDsgRW52b3nDqSZuYnNwOzogbHVuZGkgMTYganVpbGxldCAyMDEyIDAz OjI5PGJyPg0KJmd0OyAmZ3Q7IMOAJm5ic3A7OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQom Z3Q7ICZndDsgQ2MmbmJzcDs6IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBPYmpldCZu YnNwOzogW25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50 eHQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHM8YnI+DQomZ3Q7ICZndDsgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO1RoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmstQmFzZWQgTW9iaWxpdHkgRXh0ZW5z aW9uczxicj4NCiZndDsgJmd0OyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgOiBQcmVmaXggRGVsZWdhdGlvbiBmb3IgUHJveHkgTW9iaWxlIElQ djY8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IFhpbmd5dWUgWmhvdTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgSm91bmkgS29yaG9uZW48YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IENhcmwgV2lsbGlhbXM8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNyaSBHdW5kYXZlbGxpPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYXJsb3MgSi4gQmVybmFyZG9zPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTY8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs6IDIwMTItMDctMTU8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEFic3RyYWN0Ojxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UHJveHkgTW9iaWxlIElQdjYg ZW5hYmxlcyBJUCBtb2JpbGl0eSBmb3IgYSBob3N0IHdpdGhvdXQgcmVxdWlyaW5nPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpdHMgcGFydGljaXBhdGlvbiBpbiBhbnkgbW9iaWxpdHkgc2ln bmFsaW5nLCBiZWluZyB0aGUgbmV0d29yazxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cmVz cG9uc2libGUgZm9yIG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZiB0aGUgaG9zdC48 YnI+DQomZ3Q7ICZndDsgSG93ZXZlciw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5 IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEgcHJlZml4IHRvIGEgcm91 dGVyPGJyPg0KJmd0OyAmZ3Q7IGFuZDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bWFuYWdp bmcgaXRzIElQIG1vYmlsaXR5LiAmbmJzcDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBleHRl bnNpb24gdG88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmlsZSBJUHY2IHBy b3RvY29sIGZvciBzdXBwb3J0aW5nIG5ldHdvcmsgbW9iaWxpdHkgdXNpbmc8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwO0RIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsg Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0ZXh0 LXBkLXBtaXAtMDM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PGJyPg0KJmd0OyAmZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBuZXRleHQgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldGV4dCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_94D2EEADE1F74740979E8041CBA339380355AC45EXDAG0B3intrace_-- From michael.boc@cea.fr Thu Jul 19 23:16:34 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 292C521F8589; Thu, 19 Jul 2012 23:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.915 X-Spam-Level: X-Spam-Status: No, score=-8.915 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEm9l7AFKECS; Thu, 19 Jul 2012 23:16:33 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 55BE321F85E3; Thu, 19 Jul 2012 23:16:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6K6HQ1t027868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jul 2012 08:17:26 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6K6HQc4004255; Fri, 20 Jul 2012 08:17:26 +0200 (envelope-from michael.boc@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6K6HQMf004969; Fri, 20 Jul 2012 08:17:26 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Fri, 20 Jul 2012 08:17:25 +0200 From: BOC Michael To: "zhou.xingyue@zte.com.cn" Thread-Topic: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-03.txt Thread-Index: AQHNYvKCvhAGL3znHEuOVmE7wTRHpJcrmk7ggAW68ICAAGMMZQ== Date: Fri, 20 Jul 2012 06:17:24 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA339380355AC67@EXDAG0-B3.intra.cea.fr> References: <94D2EEADE1F74740979E8041CBA339380355A4EB@EXDAG0-B3.intra.cea.fr>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.167.194.4] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19052.002 x-tm-as-result: No--36.268700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_94D2EEADE1F74740979E8041CBA339380355AC67EXDAG0B3intrace_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "netext-bounces@ietf.org" Subject: [netext] RE : Re: I-D Action: draft-ietf-netext-pd-pmip-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: Fri, 20 Jul 2012 06:16:34 -0000 --_000_94D2EEADE1F74740979E8041CBA339380355AC67EXDAG0B3intrace_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KQnkgdGhlIHdheSwgaWYgdGhlIE1BRyBzZW5kcyBhIE1OUHMgb3B0aW9uIHNldCB0 byAwIGluIHRoZSBQQlUgaXQgaXMgcmVkdW5kYW50IHRvIHNldCBhIGZsYWcgdG8gdW5kZXJzdGFu ZCBpdCBpcyBmb3IgYSBtb2JpbGUgcm91dGVyLg0KDQoNCk1pY2hhZWwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkRlIDogemhvdS54aW5neXVlQHp0ZS5jb20uY24gW3pob3Uu eGluZ3l1ZUB6dGUuY29tLmNuXQ0KRGF0ZSBkJ2Vudm9pIDogdmVuZHJlZGkgMjAganVpbGxldCAy MDEyIDA0OjIxDQrDgCA6IEJPQyBNaWNoYWVsDQpDYyA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzsg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnOyBuZXRleHRAaWV0Zi5vcmc7IG5ldGV4dC1ib3VuY2Vz QGlldGYub3JnDQpPYmpldCA6IOetlOWkjTogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0DQoNCg0KSGksDQoNClRoZSBwdXJwb3NlIG9mIHNl dHRpbmcgUiBmbGFnIGlzIHRvIGluZGljYXRlIHRoZSBuZXR3b3JrIHRoYXQgbmV0d29yayBtb2Jp bGl0eSBzZXJ2aWNlIGlzIGFsbG93ZWQgdG8gdGhlIG1vYmlsZSBub2RlIGFzIHNwZWNpZmllZCBp biBzZWN0aW9uIDMuMi4gSW4gdGhpcyBkcmFmdCwgaXQganVzdCBmb2N1cyBvbiB0aGUgd2F5IHRv IGFzc2lnbiB0aGUgTU5QIHRvIHRoZSBNUiBiYXNlZCBvbiBESENQdjYtUEQgdHJpZ2dlcmluZyBt ZWNoYW5pc20uDQoNClJlZ2FyZGluZyB0aGUgcG9zc2libGUgaGludHMgaW4gSUFfUEQocyksIEkg ZG9udCBnZXQgeW91ciBwb2ludCB2ZXJ5IG11Y2guIENvdWxkIHlvdSBleHBsYWluIG1vcmU/DQoN CkJlc3QgUmVnYXJkcywNCkpveQ0KDQpuZXRleHQtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAx Mi0wNy0xNiAxNzoxMjo1NjoNCg0KPiBIZWxsbyBhbGwsDQo+DQo+IENvbmNlcm5pbmcgdGhpcyBk cmFmdCwgSSB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IHlvdSBuZWVkIHRvIHNldCB0aGUNCj4gUiBm bGFnIGluIFBCVQ0KPiAoYmVjYXVzZSB5b3UgZG9uJ3QgZXhwbGFpbiBpdCBpbiB0aGUgZHJhZnQp IGFuZCBpZiB5b3VyIGFwcHJvYWNoIGlzDQo+IHRvIG5vdCB0YWtlDQo+IGludG8gYWNjb3VudCBw b3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgd2UNCj4ganVz dCBoYXZlIHRvIHByb3ZpZGUNCj4gTU5QKHMpIGF0IE1SIGF0dGFjaG1lbnQgd2l0aCB0aGUgSE5Q KHMpIGFuZCB3ZSBtb3ZlIG9uIGFub3RoZXIgc3ViamVjdC4NCj4NCj4gUmVnYXJkcywNCj4NCj4N Cj4gTWljaGFlbA0KPg0KPg0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERl IDogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGENCj4gPiBwYXJ0IGRlIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+IEVudm95 w6kgOiBsdW5kaSAxNiBqdWlsbGV0IDIwMTIgMDM6MjkNCj4gPiDDgCA6IGktZC1hbm5vdW5jZUBp ZXRmLm9yZw0KPiA+IENjIDogbmV0ZXh0QGlldGYub3JnDQo+ID4gT2JqZXQgOiBbbmV0ZXh0XSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dA0KPiA+DQo+ID4NCj4g PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMNCj4gPiBkaXJlY3Rvcmllcy4NCj4gPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgTmV0d29yay1CYXNlZCBNb2JpbGl0eSBFeHRlbnNpb25zDQo+ID4gV29ya2lu ZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPg0KPiA+ICAgIFRpdGxlICAgICAgICAgICA6IFByZWZp eCBEZWxlZ2F0aW9uIGZvciBQcm94eSBNb2JpbGUgSVB2Ng0KPiA+ICAgIEF1dGhvcihzKSAgICAg ICA6IFhpbmd5dWUgWmhvdQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm91bmkgS29y aG9uZW4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmwgV2lsbGlhbXMNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNyaSBHdW5kYXZlbGxpDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICBDYXJsb3MgSi4gQmVybmFyZG9zDQo+ID4gICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQNCj4gPiAgICBQYWdlcyAgICAgICAg ICAgOiAxNg0KPiA+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTItMDctMTUNCj4gPg0KPiA+IEFi c3RyYWN0Og0KPiA+ICAgIFByb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9y IGEgaG9zdCB3aXRob3V0IHJlcXVpcmluZw0KPiA+ICAgIGl0cyBwYXJ0aWNpcGF0aW9uIGluIGFu eSBtb2JpbGl0eSBzaWduYWxpbmcsIGJlaW5nIHRoZSBuZXR3b3JrDQo+ID4gICAgcmVzcG9uc2li bGUgZm9yIG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZiB0aGUgaG9zdC4NCj4gPiBI b3dldmVyLA0KPiA+ICAgIFByb3h5IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWdu aW5nIGEgcHJlZml4IHRvIGEgcm91dGVyDQo+ID4gYW5kDQo+ID4gICAgbWFuYWdpbmcgaXRzIElQ IG1vYmlsaXR5LiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvDQo+ID4g ICAgUHJveHkgTW9iaWxlIElQdjYgcHJvdG9jb2wgZm9yIHN1cHBvcnRpbmcgbmV0d29yayBtb2Jp bGl0eSB1c2luZw0KPiA+ICAgIERIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi4NCj4gPg0K PiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRl eHQtcGQtcG1pcA0KPiA+DQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRl eHQtcGQtcG1pcC0wMw0KPiA+DQo+ID4gQSBkaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzDQo+ID4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ID4gbmV0 ZXh0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRleHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4NCg== --_000_94D2EEADE1F74740979E8041CBA339380355AC67EXDAG0B3intrace_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBmcHN0eWxlPSIx IiBvY3NpPSIwIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyO2ZvbnQtZmFtaWx5OiBUYWhv bWE7Y29sb3I6ICMwMDAwMDA7Zm9udC1zaXplOiAxMHB0OyI+SGksDQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnkgdGhlIHdheSwgaWYgdGhlIE1BRyBzZW5kcyBh IE1OUHMgb3B0aW9uIHNldCB0byAwIGluIHRoZSBQQlUgaXQgaXMgcmVkdW5kYW50IHRvIHNldCBh IGZsYWcgdG8gdW5kZXJzdGFuZCBpdCBpcyBmb3IgYSBtb2JpbGUgcm91dGVyLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1pY2hhZWw8L2Rpdj4NCjxk aXY+PGJyPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbjsgY29sb3I6 ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZweCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9 ImRpdlJwRjgwODA3OCIgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyAiPjxmb250IGZhY2U9IlRhaG9t YSIgc2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiPjxiPkRlIDo8L2I+IHpob3UueGluZ3l1ZUB6dGUu Y29tLmNuIFt6aG91Lnhpbmd5dWVAenRlLmNvbS5jbl08YnI+DQo8Yj5EYXRlIGQnZW52b2kgOjwv Yj4gdmVuZHJlZGkgMjAganVpbGxldCAyMDEyIDA0OjIxPGJyPg0KPGI+w4AgOjwvYj4gQk9DIE1p Y2hhZWw8YnI+DQo8Yj5DYyA6PC9iPiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc7IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzsgbmV0ZXh0QGlldGYub3JnOyBuZXRleHQtYm91bmNlc0BpZXRmLm9yZzxi cj4NCjxiPk9iamV0IDo8L2I+IOetlOWkjTogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRp dj48L2Rpdj4NCjxkaXY+PGJyPg0KPGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+SGks PC9mb250PiA8YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUg cHVycG9zZSBvZiBzZXR0aW5nIFIgZmxhZyBpcyB0byBpbmRpY2F0ZSB0aGUgbmV0d29yayB0aGF0 IG5ldHdvcmsgbW9iaWxpdHkgc2VydmljZSBpcyBhbGxvd2VkIHRvIHRoZSBtb2JpbGUgbm9kZSBh cyBzcGVjaWZpZWQgaW4gc2VjdGlvbiAzLjIuIEluIHRoaXMgZHJhZnQsIGl0IGp1c3QgZm9jdXMg b24gdGhlIHdheSB0byBhc3NpZ24gdGhlIE1OUCB0byB0aGUgTVIgYmFzZWQgb24gREhDUHY2LVBE DQogdHJpZ2dlcmluZyBtZWNoYW5pc20uPC9mb250PiA8YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIy IiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRpbmcgdGhlIHBvc3NpYmxlIGhpbnRzIGluIElBX1BE KHMpLCBJIGRvbnQgZ2V0IHlvdXIgcG9pbnQgdmVyeSBtdWNoLiBDb3VsZCB5b3UgZXhwbGFpbiBt b3JlPzwvZm9udD4NCjxicj4NCjxicj4NCjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYi PkJlc3QgUmVnYXJkcyw8L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2Vy aWYiPkpveTwvZm9udD4gPGJyPg0KPGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPm5ldGV4dC1ib3Vu Y2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTA3LTE2IDE3OjEyOjU2Ojxicj4NCjxicj4NCiZndDsg SGVsbG8gYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBDb25jZXJuaW5nIHRoaXMgZHJhZnQsIEkg d291bGQgbGlrZSB0byBrbm93IHdoeSB5b3UgbmVlZCB0byBzZXQgdGhlIDxicj4NCiZndDsgUiBm bGFnIGluIFBCVSA8YnI+DQomZ3Q7IChiZWNhdXNlIHlvdSBkb24ndCBleHBsYWluIGl0IGluIHRo ZSBkcmFmdCkgYW5kIGlmIHlvdXIgYXBwcm9hY2ggaXMgPGJyPg0KJmd0OyB0byBub3QgdGFrZSA8 YnI+DQomZ3Q7IGludG8gYWNjb3VudCBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKS4gSWYgdGhp cyBpcyB0aGUgY2FzZSwgd2U8YnI+DQomZ3Q7IGp1c3QgaGF2ZSB0byBwcm92aWRlIDxicj4NCiZn dDsgTU5QKHMpIGF0IE1SIGF0dGFjaG1lbnQgd2l0aCB0aGUgSE5QKHMpIGFuZCB3ZSBtb3ZlIG9u IGFub3RoZXIgc3ViamVjdC4gJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1pY2hhZWw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsg Jmd0OyBEZSZuYnNwOzogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGE8YnI+DQomZ3Q7ICZndDsgcGFydCBkZSBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgRW52b3nDqSZuYnNwOzogbHVuZGkgMTYganVpbGxl dCAyMDEyIDAzOjI5PGJyPg0KJmd0OyAmZ3Q7IMOAJm5ic3A7OiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmc8YnI+DQomZ3Q7ICZndDsgQ2MmbmJzcDs6IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgJmd0 OyBPYmpldCZuYnNwOzogW25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQt cG1pcC0wMy50eHQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHM8YnI+DQomZ3Q7ICZndDsgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmstQmFzZWQgTW9iaWxp dHkgRXh0ZW5zaW9uczxicj4NCiZndDsgJmd0OyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBQcmVmaXggRGVsZWdhdGlvbiBmb3IgUHJveHkg TW9iaWxlIElQdjY8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IFhpbmd5dWUgWmhvdTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSm91bmkgS29yaG9uZW48YnI+DQomZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhcmwgV2lsbGlhbXM8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNyaSBHdW5kYXZlbGxpPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYXJsb3MgSi4gQmVybmFy ZG9zPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogMTY8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMDctMTU8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UHJveHkgTW9i aWxlIElQdjYgZW5hYmxlcyBJUCBtb2JpbGl0eSBmb3IgYSBob3N0IHdpdGhvdXQgcmVxdWlyaW5n PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpdHMgcGFydGljaXBhdGlvbiBpbiBhbnkgbW9i aWxpdHkgc2lnbmFsaW5nLCBiZWluZyB0aGUgbmV0d29yazxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7cmVzcG9uc2libGUgZm9yIG1hbmFnaW5nIElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZiB0 aGUgaG9zdC48YnI+DQomZ3Q7ICZndDsgSG93ZXZlciw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwO1Byb3h5IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEgcHJlZml4 IHRvIGEgcm91dGVyPGJyPg0KJmd0OyAmZ3Q7IGFuZDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7bWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5LiAmbmJzcDtUaGlzIGRvY3VtZW50IHNwZWNpZmll cyBhbiBleHRlbnNpb24gdG88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmls ZSBJUHY2IHByb3RvY29sIGZvciBzdXBwb3J0aW5nIG5ldHdvcmsgbW9iaWxpdHkgdXNpbmc8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0RIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZndDsg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1p cDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDM8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxi cj4NCiZndDsgJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbmV0ZXh0LXBkLXBtaXAtMDM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6PGJyPg0KJmd0OyAmZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBuZXRleHQgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyAmZ3Q7IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldGV4dCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG5ldGV4dEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8YnI+DQomZ3Q7IDxicj4NCjwvZm9u dD48L3R0PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_94D2EEADE1F74740979E8041CBA339380355AC67EXDAG0B3intrace_-- From zhou.xingyue@zte.com.cn Thu Jul 19 23:24:25 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 B631121F85DB; Thu, 19 Jul 2012 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 5Fs2stpHpDzI; Thu, 19 Jul 2012 23:24:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF821F85DF; Thu, 19 Jul 2012 23:24:23 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107233502467742; Fri, 20 Jul 2012 14:16:25 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 28955.3858106218; Fri, 20 Jul 2012 14:25:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6K6P57q062199; Fri, 20 Jul 2012 14:25:05 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: <94D2EEADE1F74740979E8041CBA339380355AC67@EXDAG0-B3.intra.cea.fr> To: BOC Michael MIME-Version: 1.0 X-KeepSent: 97EFFCA1:0B541570-48257A41:0022FF38; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 20 Jul 2012 14:24:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-20 14:25:07, Serialize complete at 2012-07-20 14:25:07 Content-Type: multipart/alternative; boundary="=_alternative 00233DC548257A41_=" X-MAIL: mse02.zte.com.cn q6K6P57q062199 Cc: "netext@ietf.org" , "netext-bounces@ietf.org" Subject: [netext] =?gb2312?b?tPC4tDogUkUgOiBSZTogIEktRCBBY3Rpb246IGRyYWZ0?= =?gb2312?b?LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:24:25 -0000 This is a multipart message in MIME format. --=_alternative 00233DC548257A41_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCllvdSBjYW4gZG91YmxlIGNoZWNrIHRoZSBkcmFmdCB3aGljaCBzYXlzIHRoZSBS IGZsYWcgaXMgc2V0IGR1cmluZyB0aGUgDQppbml0aWFsIGF0dGFjaG1lbnQgcHJvY2VkdXJlLg0K DQpKb3kNCg0KDQoNCkJPQyBNaWNoYWVsIDxtaWNoYWVsLmJvY0BjZWEuZnI+IA0KMjAxMi0wNy0y MCAxNDoxNw0KDQrmlLbku7bkuroNCiJ6aG91Lnhpbmd5dWVAenRlLmNvbS5jbiIgPHpob3UueGlu Z3l1ZUB6dGUuY29tLmNuPg0K5oqE6YCBDQoibmV0ZXh0QGlldGYub3JnIiA8bmV0ZXh0QGlldGYu b3JnPiwgIm5ldGV4dC1ib3VuY2VzQGlldGYub3JnIiANCjxuZXRleHQtYm91bmNlc0BpZXRmLm9y Zz4NCuS4u+mimA0KUkUgOiBSZTogW25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRl eHQtcGQtcG1pcC0wMy50eHQNCg0KDQoNCg0KDQoNCkhpLCANCg0KDQpCeSB0aGUgd2F5LCBpZiB0 aGUgTUFHIHNlbmRzIGEgTU5QcyBvcHRpb24gc2V0IHRvIDAgaW4gdGhlIFBCVSBpdCBpcyANCnJl ZHVuZGFudCB0byBzZXQgYSBmbGFnIHRvIHVuZGVyc3RhbmQgaXQgaXMgZm9yIGEgbW9iaWxlIHJv dXRlci4NCg0KDQpNaWNoYWVsDQoNCg0KRGUgOiB6aG91Lnhpbmd5dWVAenRlLmNvbS5jbiBbemhv dS54aW5neXVlQHp0ZS5jb20uY25dDQpEYXRlIGQnZW52b2kgOiB2ZW5kcmVkaSAyMCBqdWlsbGV0 IDIwMTIgMDQ6MjENCsOAIDogQk9DIE1pY2hhZWwNCkNjIDogaS1kLWFubm91bmNlQGlldGYub3Jn OyBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc7IG5ldGV4dEBpZXRmLm9yZzsgDQpuZXRleHQtYm91 bmNlc0BpZXRmLm9yZw0KT2JqZXQgOiDnrZTlpI06IFJlOiBbbmV0ZXh0XSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dA0KDQoNCkhpLCANCg0KVGhlIHB1cnBvc2Ug b2Ygc2V0dGluZyBSIGZsYWcgaXMgdG8gaW5kaWNhdGUgdGhlIG5ldHdvcmsgdGhhdCBuZXR3b3Jr IA0KbW9iaWxpdHkgc2VydmljZSBpcyBhbGxvd2VkIHRvIHRoZSBtb2JpbGUgbm9kZSBhcyBzcGVj aWZpZWQgaW4gc2VjdGlvbiANCjMuMi4gSW4gdGhpcyBkcmFmdCwgaXQganVzdCBmb2N1cyBvbiB0 aGUgd2F5IHRvIGFzc2lnbiB0aGUgTU5QIHRvIHRoZSBNUiANCmJhc2VkIG9uIERIQ1B2Ni1QRCB0 cmlnZ2VyaW5nIG1lY2hhbmlzbS4gDQoNClJlZ2FyZGluZyB0aGUgcG9zc2libGUgaGludHMgaW4g SUFfUEQocyksIEkgZG9udCBnZXQgeW91ciBwb2ludCB2ZXJ5IG11Y2guIA0KQ291bGQgeW91IGV4 cGxhaW4gbW9yZT8gDQoNCkJlc3QgUmVnYXJkcywgDQpKb3kgDQoNCm5ldGV4dC1ib3VuY2VzQGll dGYub3JnIOWGmeS6jiAyMDEyLTA3LTE2IDE3OjEyOjU2Og0KDQo+IEhlbGxvIGFsbCwNCj4gDQo+ IENvbmNlcm5pbmcgdGhpcyBkcmFmdCwgSSB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IHlvdSBuZWVk IHRvIHNldCB0aGUgDQo+IFIgZmxhZyBpbiBQQlUgDQo+IChiZWNhdXNlIHlvdSBkb24ndCBleHBs YWluIGl0IGluIHRoZSBkcmFmdCkgYW5kIGlmIHlvdXIgYXBwcm9hY2ggaXMgDQo+IHRvIG5vdCB0 YWtlIA0KPiBpbnRvIGFjY291bnQgcG9zc2libGUgaGludHMgaW4gSUFfUEQocykuIElmIHRoaXMg aXMgdGhlIGNhc2UsIHdlDQo+IGp1c3QgaGF2ZSB0byBwcm92aWRlIA0KPiBNTlAocykgYXQgTVIg YXR0YWNobWVudCB3aXRoIHRoZSBITlAocykgYW5kIHdlIG1vdmUgb24gYW5vdGhlciBzdWJqZWN0 LiAgDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiANCj4gTWljaGFlbA0KPiANCj4gDQo+ID4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBuZXRleHQtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYQ0KPiA+IHBhcnQgZGUgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4gRW52b3nDqSA6IGx1bmRpIDE2IGp1aWxsZXQgMjAx MiAwMzoyOQ0KPiA+IMOAIDogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4gQ2MgOiBuZXRleHRA aWV0Zi5vcmcNCj4gPiBPYmpldCA6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0 ZXh0LXBkLXBtaXAtMDMudHh0DQo+ID4gDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4gZGlyZWN0 b3JpZXMuDQo+ID4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmstQmFz ZWQgTW9iaWxpdHkgRXh0ZW5zaW9ucw0KPiA+IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ ID4gDQo+ID4gICAgVGl0bGUgICAgICAgICAgIDogUHJlZml4IERlbGVnYXRpb24gZm9yIFByb3h5 IE1vYmlsZSBJUHY2DQo+ID4gICAgQXV0aG9yKHMpICAgICAgIDogWGluZ3l1ZSBaaG91DQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICBKb3VuaSBLb3Job25lbg0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2FybCBXaWxsaWFtcw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgU3JpIEd1bmRhdmVsbGkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBK LiBCZXJuYXJkb3MNCj4gPiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGV4dC1w ZC1wbWlwLTAzLnR4dA0KPiA+ICAgIFBhZ2VzICAgICAgICAgICA6IDE2DQo+ID4gICAgRGF0ZSAg ICAgICAgICAgIDogMjAxMi0wNy0xNQ0KPiA+IA0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFByb3h5 IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9yIGEgaG9zdCB3aXRob3V0IHJlcXVp cmluZw0KPiA+ICAgIGl0cyBwYXJ0aWNpcGF0aW9uIGluIGFueSBtb2JpbGl0eSBzaWduYWxpbmcs IGJlaW5nIHRoZSBuZXR3b3JrDQo+ID4gICAgcmVzcG9uc2libGUgZm9yIG1hbmFnaW5nIElQIG1v YmlsaXR5IG9uIGJlaGFsZiBvZiB0aGUgaG9zdC4NCj4gPiBIb3dldmVyLA0KPiA+ICAgIFByb3h5 IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEgcHJlZml4IHRvIGEgcm91 dGVyDQo+ID4gYW5kDQo+ID4gICAgbWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5LiAgVGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvDQo+ID4gICAgUHJveHkgTW9iaWxlIElQdjYg cHJvdG9jb2wgZm9yIHN1cHBvcnRpbmcgbmV0d29yayBtb2JpbGl0eSB1c2luZw0KPiA+ICAgIERI Q1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi4NCj4gPiANCj4gPiANCj4gPiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwDQo+ID4gDQo+ ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMw0KPiA+ IA0KPiA+IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRleHQtcGQt cG1pcC0wMw0KPiA+IA0KPiA+IA0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiA+IG5ldGV4dEBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGV4dCBtYWls aW5nIGxpc3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KDQo= --=_alternative 00233DC548257A41_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WW91IGNhbiBkb3VibGUgY2hlY2sg dGhlIGRyYWZ0IHdoaWNoDQpzYXlzIHRoZSBSIGZsYWcgaXMgc2V0IGR1cmluZyB0aGUgPGk+aW5p dGlhbCBhdHRhY2htZW50IHByb2NlZHVyZTwvaT4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Kb3k8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Qk9DIE1pY2hhZWwgJmx0O21pY2hhZWwuYm9jQGNlYS5m ciZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAx Mi0wNy0yMCAxNDoxNzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+5pS25Lu25Lq6PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt6aG91Lnhpbmd5dWVAenRlLmNvbS5jbiZxdW90Ow0KJmx0 O3pob3UueGluZ3l1ZUB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCB PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtu ZXRleHRAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGV4dEBpZXRmLm9yZyZndDssDQomcXVvdDtuZXRl eHQtYm91bmNlc0BpZXRmLm9yZyZxdW90OyAmbHQ7bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFIDogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+SGksIDwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5CeSB0aGUgd2F5LCBpZiB0aGUg TUFHIHNlbmRzIGEgTU5QcyBvcHRpb24NCnNldCB0byAwIGluIHRoZSBQQlUgaXQgaXMgcmVkdW5k YW50IHRvIHNldCBhIGZsYWcgdG8gdW5kZXJzdGFuZCBpdCBpcyBmb3INCmEgbW9iaWxlIHJvdXRl ci48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+TWlj aGFlbDwvZm9udD4NCjxicj4NCjxicj4NCjxocj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj5EZSA6PC9iPiB6aG91Lnhpbmd5dWVAenRlLmNvbS5jbiBbemhvdS54aW5neXVlQHp0 ZS5jb20uY25dPGI+PGJyPg0KRGF0ZSBkJ2Vudm9pIDo8L2I+IHZlbmRyZWRpIDIwIGp1aWxsZXQg MjAxMiAwNDoyMTxiPjxicj4NCsOAIDo8L2I+IEJPQyBNaWNoYWVsPGI+PGJyPg0KQ2MgOjwvYj4g aS1kLWFubm91bmNlQGlldGYub3JnOyBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc7IG5ldGV4dEBp ZXRmLm9yZzsNCm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPGI+PGJyPg0KT2JqZXQgOjwvYj4g562U 5aSNOiBSZTogW25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0w My50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj48YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpLDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NClRoZSBwdXJwb3NlIG9mIHNldHRpbmcgUiBmbGFnIGlzIHRvIGluZGljYXRlIHRo ZSBuZXR3b3JrIHRoYXQgbmV0d29yayBtb2JpbGl0eQ0Kc2VydmljZSBpcyBhbGxvd2VkIHRvIHRo ZSBtb2JpbGUgbm9kZSBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiAzLjIuIEluIHRoaXMNCmRyYWZ0 LCBpdCBqdXN0IGZvY3VzIG9uIHRoZSB3YXkgdG8gYXNzaWduIHRoZSBNTlAgdG8gdGhlIE1SIGJh c2VkIG9uIERIQ1B2Ni1QRA0KdHJpZ2dlcmluZyBtZWNoYW5pc20uPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KUmVnYXJkaW5nIHRoZSBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKSwgSSBkb250 IGdldCB5b3VyIHBvaW50IHZlcnkgbXVjaC4NCkNvdWxkIHlvdSBleHBsYWluIG1vcmU/PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KQmVzdCBSZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkpv eTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IlJvbWFuIj48YnI+DQpuZXRleHQtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAx Mi0wNy0xNiAxNzoxMjo1Njo8YnI+DQo8YnI+DQomZ3Q7IEhlbGxvIGFsbCw8YnI+DQomZ3Q7IDxi cj4NCiZndDsgQ29uY2VybmluZyB0aGlzIGRyYWZ0LCBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkg eW91IG5lZWQgdG8gc2V0IHRoZQ0KPGJyPg0KJmd0OyBSIGZsYWcgaW4gUEJVIDxicj4NCiZndDsg KGJlY2F1c2UgeW91IGRvbid0IGV4cGxhaW4gaXQgaW4gdGhlIGRyYWZ0KSBhbmQgaWYgeW91ciBh cHByb2FjaCBpcw0KPGJyPg0KJmd0OyB0byBub3QgdGFrZSA8YnI+DQomZ3Q7IGludG8gYWNjb3Vu dCBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgd2U8YnI+ DQomZ3Q7IGp1c3QgaGF2ZSB0byBwcm92aWRlIDxicj4NCiZndDsgTU5QKHMpIGF0IE1SIGF0dGFj aG1lbnQgd2l0aCB0aGUgSE5QKHMpIGFuZCB3ZSBtb3ZlIG9uIGFub3RoZXIgc3ViamVjdC4NCiZu YnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBNaWNoYWVsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7ICZndDsgRGUgOiBuZXRleHQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXQ0KRGUgbGE8YnI+ DQomZ3Q7ICZndDsgcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn dDsgRW52b3nDqSA6IGx1bmRpIDE2IGp1aWxsZXQgMjAxMiAwMzoyOTxicj4NCiZndDsgJmd0OyDD gCA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBDYyA6IG5ldGV4dEBpZXRm Lm9yZzxicj4NCiZndDsgJmd0OyBPYmpldCA6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyAmZ3Q7IGRpcmVjdG9yaWVzLjxicj4N CiZndDsgJmd0OyAmbmJzcDtUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3Jr LUJhc2VkIE1vYmlsaXR5DQpFeHRlbnNpb25zPGJyPg0KJmd0OyAmZ3Q7IFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 VGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFByZWZpeA0KRGVsZWdh dGlvbiBmb3IgUHJveHkgTW9iaWxlIElQdjY8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0F1 dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFhpbmd5dWUgWmhvdTxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEpvdW5pIEtvcmhvbmVuPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FybCBXaWxsaWFt czxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNyaSBH dW5kYXZlbGxpPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQ2FybG9zIEouIEJlcm5hcmRvczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7RmlsZW5h bWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlw LTAzLnR4dDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UGFnZXMgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IDE2PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtEYXRl ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Og0KMjAxMi0wNy0xNTxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtQcm94eSBNb2JpbGUgSVB2NiBlbmFibGVzIElQIG1vYmlsaXR5IGZvciBhIGhv c3QNCndpdGhvdXQgcmVxdWlyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpdHMgcGFy dGljaXBhdGlvbiBpbiBhbnkgbW9iaWxpdHkgc2lnbmFsaW5nLCBiZWluZw0KdGhlIG5ldHdvcms8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3Jlc3BvbnNpYmxlIGZvciBtYW5hZ2luZyBJUCBt b2JpbGl0eSBvbiBiZWhhbGYgb2YNCnRoZSBob3N0Ljxicj4NCiZndDsgJmd0OyBIb3dldmVyLDxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UHJveHkgTW9iaWxlIElQdjYgZG9lcyBub3Qgc3Vw cG9ydCBhc3NpZ25pbmcgYSBwcmVmaXgNCnRvIGEgcm91dGVyPGJyPg0KJmd0OyAmZ3Q7IGFuZDxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5LiAmbmJz cDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcw0KYW4gZXh0ZW5zaW9uIHRvPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUgSVB2NiBwcm90b2NvbCBmb3Igc3VwcG9ydGluZyBu ZXR3b3JrDQptb2JpbGl0eSB1c2luZzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7REhDUHY2 LWJhc2VkIFByZWZpeCBEZWxlZ2F0aW9uLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOjxicj4NCiZndDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7 ICZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1p cC0wMzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQSBkaWZmIGZyb20gcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMzxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsgZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7IG5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgbmV0ZXh0QGlldGYu b3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0ZXh0PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgbmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgbmV0ZXh0QGll dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGV4dDxicj4NCiZndDsgPC9mb250Pg0KPGJyPg0K --=_alternative 00233DC548257A41_=-- From zhou.xingyue@zte.com.cn Thu Jul 19 23:32:39 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 AAA4C21F8678; Thu, 19 Jul 2012 23:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 B8H0yGwNTsdM; Thu, 19 Jul 2012 23:32:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 294FF21F8675; Thu, 19 Jul 2012 23:32:36 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 232555771751954; Fri, 20 Jul 2012 14:29:55 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 29176.6127390430; Fri, 20 Jul 2012 14:33:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6K6XB6H091372; Fri, 20 Jul 2012 14:33:11 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: <94D2EEADE1F74740979E8041CBA339380355AC45@EXDAG0-B3.intra.cea.fr> To: BOC Michael MIME-Version: 1.0 X-KeepSent: FA8CF2E4:97DA4C3F-48257A41:00236978; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 20 Jul 2012 14:32:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-20 14:33:12, Serialize complete at 2012-07-20 14:33:12 Content-Type: multipart/alternative; boundary="=_alternative 0023FA7F48257A41_=" X-MAIL: mse01.zte.com.cn q6K6XB6H091372 Cc: "netext@ietf.org" , "netext-bounces@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: [netext] =?gb2312?b?tPC4tDogUkUgOiBSZTogIEktRCBBY3Rpb246IGRyYWZ0?= =?gb2312?b?LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:32:39 -0000 This is a multipart message in MIME format. --=_alternative 0023FA7F48257A41_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNClBsZWFzZSBzZWUgaW5saW5lIGJlbG93Lg0KDQpCT0MgTWljaGFlbCA8bWljaGFlbC5i b2NAY2VhLmZyPiDlhpnkuo4gMjAxMi0wNy0yMCAxNDoxMjo1OToNCg0KPiBIZXksIA0KPiANCj4g T2ssIG5vdyBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGRyYWZ0IGlzIGFib3V0IHVzaW5nIERIQ1B2 Ni1QRCANCj4gc2lnbmFsbGluZyBtZXNzYWdlcyB0byB0cmlnZ2VyIGEgc3BlY2lmaWMgYmVoYXZp b3Igb2YgUE1JUHY2IGFuZCBub3QNCj4gYXQgYWxsIGFib3V0IHVzaW5nIERIQ1B2NiBhbmQgaXRz IFBEIGV4dGVuc2lvbiB0byBwcm92aWRlIE1OUHMgdG8gDQo+IFBNSVB2NiBhbmQgYnkgZXh0ZW5z aW9uIHRvIHRoZSBNUi4gDQo+IA0KPiBUd28gKG1vcmUpIGVmZmljaWVudCBzb2x1dGlvbnMgZm9y IHRoaXMgYXBwcm9hY2g6DQo+IDEpIFlvdSBkb24ndCBuZWVkIERIQ1B2NiBlbnRpdGllcyAoZGVs ZWdhdGluZyByb3V0ZXIsIERIQ1B2NiByZWxheSANCj4gYW5kIHNvIG9uKS4gWW91IGp1c3QgbmVl ZCB0byBpbnRlcmNlcHQgREhDUHY2LVBEIHJlbGF0ZWQgbWVzc2FnZXMgDQo+IGFuZCB0byBlbmhh bmNlcyBMTUEgdG8gZGVsaXZlciBwcmVmaXhlcyBzaG9ydGVyIHRoYW4gNjQgYml0cy4NCltKb3ld WWVzLCB5b3Ugc3VyZWx5IGNhbiBkbyB0aGlzLiBIb3dldmVyLCB0aGlzIGlzIGp1c3QgYSBraW5k IG9mIA0KaW1wbGVtZW50YXRpb24gd2F5IHdoaWxlIHdlIHdvcmsgb24gYSBzdGFuZGFyZCB3YXku DQoNCj4gMikgWW91IGRlbGl2ZXIgSE5QcyBhbmQgTU5QcyAod2l0aCBwcmVmaXhlcyBzaG9ydGVy IHRoYW4gNjQgYml0cykgDQo+IGZvciBldmVyeSBub2Rlcy4gVGhpcyBpcyBhIGNvdXBsZSBvZiBs aW5lcyB0byBhZGQgaW4gUkZDNTIxMy4NCltKb3ldSW4gb3VyIHNjZW5hcmlvLCB0aGUgTU5QKHMp IGFyZSBhc3NpZ25lZCBvbmx5IHdoZW4gdGhlIE1SIGluaXRpYXRlIA0KdGhlIERIQ1B2Ni1QRCBw cm9jZWR1cmUuDQoNCj4gDQo+IE91ciBhcHByb2FjaCBjYW4gdGhlbiBiZSBzZWVuIGFzIG9uZSBz dGVwIGZ1cnRoZXIgaW4gaW50ZWdyYXRpbmcgYSANCj4gcmVhbCBESENQdjYgYXJjaGl0ZWN0dXJl IGluIHBhcmFsbGVsIG9mIFBNSVB2NiB0byBkZWxpdmVyIE1OUHMgdG8gDQo+IG1vYmlsZSByb3V0 ZXJzLg0KPiANCj4gTWljaGFlbA0KPiANCj4gRGUgOiB6aG91Lnhpbmd5dWVAenRlLmNvbS5jbiBb emhvdS54aW5neXVlQHp0ZS5jb20uY25dDQo+IERhdGUgZCdlbnZvaSA6IHZlbmRyZWRpIDIwIGp1 aWxsZXQgMjAxMiAwNDoyMQ0KPiDDgCA6IEJPQyBNaWNoYWVsDQo+IENjIDogaS1kLWFubm91bmNl QGlldGYub3JnOyBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc7IG5ldGV4dEBpZXRmLg0KPiBvcmc7 IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnDQo+IE9iamV0IDog562U5aSNOiBSZTogW25ldGV4dF0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQNCg0KPiANCj4gSGks IA0KPiANCj4gVGhlIHB1cnBvc2Ugb2Ygc2V0dGluZyBSIGZsYWcgaXMgdG8gaW5kaWNhdGUgdGhl IG5ldHdvcmsgdGhhdCANCj4gbmV0d29yayBtb2JpbGl0eSBzZXJ2aWNlIGlzIGFsbG93ZWQgdG8g dGhlIG1vYmlsZSBub2RlIGFzIHNwZWNpZmllZCANCj4gaW4gc2VjdGlvbiAzLjIuIEluIHRoaXMg ZHJhZnQsIGl0IGp1c3QgZm9jdXMgb24gdGhlIHdheSB0byBhc3NpZ24gDQo+IHRoZSBNTlAgdG8g dGhlIE1SIGJhc2VkIG9uIERIQ1B2Ni1QRCB0cmlnZ2VyaW5nIG1lY2hhbmlzbS4gDQo+IA0KPiBS ZWdhcmRpbmcgdGhlIHBvc3NpYmxlIGhpbnRzIGluIElBX1BEKHMpLCBJIGRvbnQgZ2V0IHlvdXIg cG9pbnQgdmVyeQ0KPiBtdWNoLiBDb3VsZCB5b3UgZXhwbGFpbiBtb3JlPyANCj4gDQo+IEJlc3Qg UmVnYXJkcywgDQo+IEpveSANCj4gDQo+IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAy MDEyLTA3LTE2IDE3OjEyOjU2Og0KPiANCj4gPiBIZWxsbyBhbGwsDQo+ID4gDQo+ID4gQ29uY2Vy bmluZyB0aGlzIGRyYWZ0LCBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkgeW91IG5lZWQgdG8gc2V0 IHRoZSANCj4gPiBSIGZsYWcgaW4gUEJVIA0KPiA+IChiZWNhdXNlIHlvdSBkb24ndCBleHBsYWlu IGl0IGluIHRoZSBkcmFmdCkgYW5kIGlmIHlvdXIgYXBwcm9hY2ggaXMgDQo+ID4gdG8gbm90IHRh a2UgDQo+ID4gaW50byBhY2NvdW50IHBvc3NpYmxlIGhpbnRzIGluIElBX1BEKHMpLiBJZiB0aGlz IGlzIHRoZSBjYXNlLCB3ZQ0KPiA+IGp1c3QgaGF2ZSB0byBwcm92aWRlIA0KPiA+IE1OUChzKSBh dCBNUiBhdHRhY2htZW50IHdpdGggdGhlIEhOUChzKSBhbmQgd2UgbW92ZSBvbiBhbm90aGVyIA0K c3ViamVjdC4gDQo+ID4gDQo+ID4gUmVnYXJkcywNCj4gPiANCj4gPiANCj4gPiBNaWNoYWVsDQo+ ID4gDQo+ID4gDQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlIDog bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGENCj4gPiA+IHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4gPiBFbnZv ecOpIDogbHVuZGkgMTYganVpbGxldCAyMDEyIDAzOjI5DQo+ID4gPiDDgCA6IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0KPiA+ID4gQ2MgOiBuZXRleHRAaWV0Zi5vcmcNCj4gPiA+IE9iamV0IDogW25l dGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQNCj4gPiA+ IA0KPiA+ID4gDQo+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPiA+IGRpcmVjdG9yaWVzLg0KPiA+ID4gIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmstQmFzZWQgTW9iaWxpdHkgRXh0 ZW5zaW9ucw0KPiA+ID4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPiA+IA0KPiA+ID4g ICAgVGl0bGUgICAgICAgICAgIDogUHJlZml4IERlbGVnYXRpb24gZm9yIFByb3h5IE1vYmlsZSBJ UHY2DQo+ID4gPiAgICBBdXRob3IocykgICAgICAgOiBYaW5neXVlIFpob3UNCj4gPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgSm91bmkgS29yaG9uZW4NCj4gPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2FybCBXaWxsaWFtcw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAg ICBTcmkgR3VuZGF2ZWxsaQ0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBDYXJsb3Mg Si4gQmVybmFyZG9zDQo+ID4gPiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGV4 dC1wZC1wbWlwLTAzLnR4dA0KPiA+ID4gICAgUGFnZXMgICAgICAgICAgIDogMTYNCj4gPiA+ICAg IERhdGUgICAgICAgICAgICA6IDIwMTItMDctMTUNCj4gPiA+IA0KPiA+ID4gQWJzdHJhY3Q6DQo+ ID4gPiAgICBQcm94eSBNb2JpbGUgSVB2NiBlbmFibGVzIElQIG1vYmlsaXR5IGZvciBhIGhvc3Qg d2l0aG91dCANCnJlcXVpcmluZw0KPiA+ID4gICAgaXRzIHBhcnRpY2lwYXRpb24gaW4gYW55IG1v YmlsaXR5IHNpZ25hbGluZywgYmVpbmcgdGhlIG5ldHdvcmsNCj4gPiA+ICAgIHJlc3BvbnNpYmxl IGZvciBtYW5hZ2luZyBJUCBtb2JpbGl0eSBvbiBiZWhhbGYgb2YgdGhlIGhvc3QuDQo+ID4gPiBI b3dldmVyLA0KPiA+ID4gICAgUHJveHkgTW9iaWxlIElQdjYgZG9lcyBub3Qgc3VwcG9ydCBhc3Np Z25pbmcgYSBwcmVmaXggdG8gYSByb3V0ZXINCj4gPiA+IGFuZA0KPiA+ID4gICAgbWFuYWdpbmcg aXRzIElQIG1vYmlsaXR5LiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIA0K dG8NCj4gPiA+ICAgIFByb3h5IE1vYmlsZSBJUHY2IHByb3RvY29sIGZvciBzdXBwb3J0aW5nIG5l dHdvcmsgbW9iaWxpdHkgdXNpbmcNCj4gPiA+ICAgIERIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdh dGlvbi4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXANCj4gPiA+IA0KPiA+ID4gVGhlcmUncyBh bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4gPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzDQo+ID4gPiANCj4gPiA+ IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+ID4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlw LTAzDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldGV4 dEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRleHQNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRleHRAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+IA0K --=_alternative 0023FA7F48257A41_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cu PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Qk9DIE1pY2hhZWwgJmx0O21pY2hh ZWwuYm9jQGNlYS5mciZndDsg5YaZ5LqOIDIwMTItMDctMjANCjE0OjEyOjU5Ojxicj4NCjxicj4N CiZndDsgSGV5LCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyBPaywgbm93IEkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgZHJhZnQgaXMgYWJvdXQgdXNpbmcg REhDUHY2LVBEIDxicj4NCiZndDsgc2lnbmFsbGluZyBtZXNzYWdlcyB0byB0cmlnZ2VyIGEgc3Bl Y2lmaWMgYmVoYXZpb3Igb2YgUE1JUHY2IGFuZCBub3Q8YnI+DQomZ3Q7IGF0IGFsbCBhYm91dCB1 c2luZyBESENQdjYgYW5kIGl0cyBQRCBleHRlbnNpb24gdG8gcHJvdmlkZSBNTlBzIHRvDQo8YnI+ DQomZ3Q7IFBNSVB2NiBhbmQgYnkgZXh0ZW5zaW9uIHRvIHRoZSBNUi4gPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVHdvIChtb3JlKSBlZmZpY2llbnQg c29sdXRpb25zIGZvciB0aGlzIGFwcHJvYWNoOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAxKSBZb3UgZG9uJ3QgbmVlZCBESENQdjYgZW50aXRpZXMgKGRlbGVnYXRpbmcN CnJvdXRlciwgREhDUHY2IHJlbGF5IDxicj4NCiZndDsgYW5kIHNvIG9uKS4gWW91IGp1c3QgbmVl ZCB0byBpbnRlcmNlcHQgREhDUHY2LVBEIHJlbGF0ZWQgbWVzc2FnZXMNCjxicj4NCiZndDsgYW5k IHRvIGVuaGFuY2VzIExNQSB0byBkZWxpdmVyIHByZWZpeGVzIHNob3J0ZXIgdGhhbiA2NCBiaXRz LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0pveV1ZZXMsIHlvdSBzdXJlbHkg Y2FuIGRvIHRoaXMuIEhvd2V2ZXIsIHRoaXMgaXMNCmp1c3QgYSBraW5kIG9mIGltcGxlbWVudGF0 aW9uIHdheSB3aGlsZSB3ZSB3b3JrIG9uIGEgc3RhbmRhcmQgd2F5LjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyKSBZb3UgZGVsaXZlciBITlBzIGFuZCBNTlBz ICh3aXRoIHByZWZpeGVzIHNob3J0ZXINCnRoYW4gNjQgYml0cykgPGJyPg0KJmd0OyBmb3IgZXZl cnkgbm9kZXMuIFRoaXMgaXMgYSBjb3VwbGUgb2YgbGluZXMgdG8gYWRkIGluIFJGQzUyMTMuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSm95XUluIG91ciBzY2VuYXJpbywgdGhl IE1OUChzKSBhcmUgYXNzaWduZWQgb25seQ0Kd2hlbiB0aGUgTVIgaW5pdGlhdGUgdGhlIERIQ1B2 Ni1QRCBwcm9jZWR1cmUuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IDxicj4NCiZndDsgT3VyIGFwcHJvYWNoIGNhbiB0aGVuIGJlIHNlZW4gYXMgb25lIHN0ZXAg ZnVydGhlciBpbiBpbnRlZ3JhdGluZyBhDQo8YnI+DQomZ3Q7IHJlYWwgREhDUHY2IGFyY2hpdGVj dHVyZSBpbiBwYXJhbGxlbCBvZiBQTUlQdjYgdG8gZGVsaXZlciBNTlBzIHRvDQo8YnI+DQomZ3Q7 IG1vYmlsZSByb3V0ZXJzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IE1pY2hhZWw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBEZSA6IHpob3UueGluZ3l1ZUB6dGUuY29tLmNuIFt6aG91Lnhpbmd5dWVAenRl LmNvbS5jbl08YnI+DQomZ3Q7IERhdGUgZCdlbnZvaSA6IHZlbmRyZWRpIDIwIGp1aWxsZXQgMjAx MiAwNDoyMTxicj4NCiZndDsgw4AgOiBCT0MgTWljaGFlbDxicj4NCiZndDsgQ2MgOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmc7IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsgbmV0ZXh0QGlldGYuPGJy Pg0KJmd0OyBvcmc7IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyBPYmpldCA6IOet lOWkjTogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAt MDMudHh0PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsgSGksIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgcHVycG9zZSBvZiBzZXR0aW5nIFIg ZmxhZyBpcyB0byBpbmRpY2F0ZSB0aGUgbmV0d29yayB0aGF0IDxicj4NCiZndDsgbmV0d29yayBt b2JpbGl0eSBzZXJ2aWNlIGlzIGFsbG93ZWQgdG8gdGhlIG1vYmlsZSBub2RlIGFzIHNwZWNpZmll ZA0KPGJyPg0KJmd0OyBpbiBzZWN0aW9uIDMuMi4gSW4gdGhpcyBkcmFmdCwgaXQganVzdCBmb2N1 cyBvbiB0aGUgd2F5IHRvIGFzc2lnbg0KPGJyPg0KJmd0OyB0aGUgTU5QIHRvIHRoZSBNUiBiYXNl ZCBvbiBESENQdjYtUEQgdHJpZ2dlcmluZyBtZWNoYW5pc20uIDxicj4NCiZndDsgPGJyPg0KJmd0 OyBSZWdhcmRpbmcgdGhlIHBvc3NpYmxlIGhpbnRzIGluIElBX1BEKHMpLCBJIGRvbnQgZ2V0IHlv dXIgcG9pbnQgdmVyeTxicj4NCiZndDsgbXVjaC4gQ291bGQgeW91IGV4cGxhaW4gbW9yZT8gPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgUmVnYXJkcywgPGJyPg0KJmd0OyBKb3kgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTA3LTE2IDE3 OjEyOjU2Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhlbGxvIGFsbCw8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IENvbmNlcm5pbmcgdGhpcyBkcmFmdCwgSSB3b3VsZCBsaWtlIHRv IGtub3cgd2h5IHlvdSBuZWVkIHRvIHNldA0KdGhlIDxicj4NCiZndDsgJmd0OyBSIGZsYWcgaW4g UEJVIDxicj4NCiZndDsgJmd0OyAoYmVjYXVzZSB5b3UgZG9uJ3QgZXhwbGFpbiBpdCBpbiB0aGUg ZHJhZnQpIGFuZCBpZiB5b3VyIGFwcHJvYWNoDQppcyA8YnI+DQomZ3Q7ICZndDsgdG8gbm90IHRh a2UgPGJyPg0KJmd0OyAmZ3Q7IGludG8gYWNjb3VudCBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChz KS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwNCndlPGJyPg0KJmd0OyAmZ3Q7IGp1c3QgaGF2ZSB0byBw cm92aWRlIDxicj4NCiZndDsgJmd0OyBNTlAocykgYXQgTVIgYXR0YWNobWVudCB3aXRoIHRoZSBI TlAocykgYW5kIHdlIG1vdmUgb24gYW5vdGhlcg0Kc3ViamVjdC4gJm5ic3A7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBNaWNoYWVsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQom Z3Q7ICZndDsgJmd0OyBEZSA6IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0ZXh0 LWJvdW5jZXNAaWV0Zi5vcmddDQpEZSBsYTxicj4NCiZndDsgJmd0OyAmZ3Q7IHBhcnQgZGUgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRW52b3nDqSA6IGx1bmRp IDE2IGp1aWxsZXQgMjAxMiAwMzoyOTxicj4NCiZndDsgJmd0OyAmZ3Q7IMOAIDogaS1kLWFubm91 bmNlQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2MgOiBuZXRleHRAaWV0Zi5vcmc8YnI+ DQomZ3Q7ICZndDsgJmd0OyBPYmpldCA6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt bmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg ZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgTmV0d29yay1CYXNlZCBNb2JpbGl0eQ0KRXh0ZW5zaW9uczxicj4NCiZn dDsgJmd0OyAmZ3Q7IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgOg0KUHJlZml4IERlbGVnYXRpb24gZm9yIFByb3h5IE1vYmls ZSBJUHY2PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IFhpbmd5dWUgWmhvdTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSm91bmkgS29yaG9uZW48YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhcmwgV2lsbGlhbXM8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNyaSBH dW5kYXZlbGxpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBDYXJsb3MgSi4gQmVybmFyZG9zPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwO0ZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1uZXRl eHQtcGQtcG1pcC0wMy50eHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UGFnZXMg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6DQoxNjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Og0KMjAxMi0wNy0xNTxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQcm94eSBNb2Jp bGUgSVB2NiBlbmFibGVzIElQIG1vYmlsaXR5IGZvciBhDQpob3N0IHdpdGhvdXQgcmVxdWlyaW5n PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2l0cyBwYXJ0aWNpcGF0aW9uIGluIGFu eSBtb2JpbGl0eSBzaWduYWxpbmcsDQpiZWluZyB0aGUgbmV0d29yazxicj4NCiZndDsgJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtyZXNwb25zaWJsZSBmb3IgbWFuYWdpbmcgSVAgbW9iaWxpdHkgb24g YmVoYWxmDQpvZiB0aGUgaG9zdC48YnI+DQomZ3Q7ICZndDsgJmd0OyBIb3dldmVyLDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUgSVB2NiBkb2VzIG5vdCBzdXBw b3J0IGFzc2lnbmluZw0KYSBwcmVmaXggdG8gYSByb3V0ZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyBh bmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bWFuYWdpbmcgaXRzIElQIG1vYmls aXR5LiAmbmJzcDtUaGlzIGRvY3VtZW50DQpzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmlsZSBJUHY2IHByb3RvY29sIGZv ciBzdXBwb3J0aW5nIG5ldHdvcmsNCm1vYmlsaXR5IHVzaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwO0RIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi48YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZn dDsgJmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGV4 dC1wZC1wbWlwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0w Mzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEEgZGlmZiBmcm9tIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0w Mzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDo8YnI+DQomZ3Q7ICZndDsgJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsg bmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IG5ldGV4dEBpZXRmLm9yZzxi cj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0ZXh0PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsgbmV0ZXh0QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0Pg0K --=_alternative 0023FA7F48257A41_=-- From michael.boc@cea.fr Fri Jul 20 00:19:05 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 BB36E21F853C; Fri, 20 Jul 2012 00:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.123 X-Spam-Level: X-Spam-Status: No, score=-8.123 tagged_above=-999 required=5 tests=[AWL=2.125, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vnny32d2a5Sb; Fri, 20 Jul 2012 00:19:04 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8C21F8526; Fri, 20 Jul 2012 00:19:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6K7JvuV009468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jul 2012 09:19:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6K7JvfG024908; Fri, 20 Jul 2012 09:19:57 +0200 (envelope-from michael.boc@cea.fr) Received: from EXCAH-A2.intra.cea.fr (excah-a2.intra.cea.fr [132.166.88.76]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6K7JuqC031826; Fri, 20 Jul 2012 09:19:56 +0200 Received: from EXDAG0-B3.intra.cea.fr ([fe80::d0da:1b48:7560:ee73]) by EXCAH-A2.intra.cea.fr ([fe80::1424:a20d:95ab:8077%11]) with mapi id 14.01.0339.001; Fri, 20 Jul 2012 09:19:56 +0200 From: BOC Michael To: "zhou.xingyue@zte.com.cn" Thread-Topic: RE : Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-03.txt Thread-Index: AQHNYvKCvhAGL3znHEuOVmE7wTRHpJcrmk7ggAW68ICAAGMMZf//4QuAgAAp9bA= Date: Fri, 20 Jul 2012 07:19:55 +0000 Message-ID: <94D2EEADE1F74740979E8041CBA339380355ACBF@EXDAG0-B3.intra.cea.fr> References: <94D2EEADE1F74740979E8041CBA339380355AC67@EXDAG0-B3.intra.cea.fr> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19052.002 x-tm-as-result: No--40.293200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_94D2EEADE1F74740979E8041CBA339380355ACBFEXDAG0B3intrace_" MIME-Version: 1.0 Cc: "netext@ietf.org" , "netext-bounces@ietf.org" Subject: Re: [netext] RE : Re: I-D Action: draft-ietf-netext-pd-pmip-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: Fri, 20 Jul 2012 07:19:05 -0000 --_000_94D2EEADE1F74740979E8041CBA339380355ACBFEXDAG0B3intrace_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm95LA0KDQpPayBzbyBJIGd1ZXNzIGZvciB5b3UgdGhlIGluaXRpYWwgYXR0YWNobWVudCBwcm9j ZWR1cmUgaXMgdGhlIFBCVSBzZW50IGZvciBITlBzLiBSaWdodD8NCklmIHNvOg0KRG8geW91IG1l YW4geW91IGRvbuKAmXQgc2V0IHRoZSBmbGFnIGluIHN1YnNlcXVlbnQgUEJVcyA/DQpEbyB5b3Ug bWVhbiB0aGUgTE1BIGhhcyB0byBkbyBzb21ldGhpbmcgc3BlY2lhbCB3aGVuIGl0IHJlY2VpdmVz IHRoZSBSIGZsYWcgdGhhdCBpdCB3aWxsIG5vdCBkbyB3aGVuIHJlY2VpdmluZyB0aGUgTU5QIG9w dGlvbiBzZXQgdG8gemVybz8NCkRvIHlvdSBtZWFuIHRoZSBjaGVjayBvZiBwb2xpY3kgcHJvZmls ZSBmb3IgdGhlIE1SIGlzIOKAnHN0YXRlbGVzc+KAnSAodGhlIE1BRyBkbyBub3Qgc3RvcmUgdGhl IGZhY3QgdGhhdCB0aGUgTVIgbmVlZHMgTU5Qcyk/DQoNCk1pY2hhZWwNCg0KRGUgOiB6aG91Lnhp bmd5dWVAenRlLmNvbS5jbiBbbWFpbHRvOnpob3UueGluZ3l1ZUB6dGUuY29tLmNuXQ0KRW52b3nD qSA6IHZlbmRyZWRpIDIwIGp1aWxsZXQgMjAxMiAwODoyNQ0Kw4AgOiBCT0MgTWljaGFlbA0KQ2Mg OiBuZXRleHRAaWV0Zi5vcmc7IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnDQpPYmpldCA6IOetlOWk jTogUkUgOiBSZTogW25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1p cC0wMy50eHQNCg0KDQpIZWxsbywNCg0KWW91IGNhbiBkb3VibGUgY2hlY2sgdGhlIGRyYWZ0IHdo aWNoIHNheXMgdGhlIFIgZmxhZyBpcyBzZXQgZHVyaW5nIHRoZSBpbml0aWFsIGF0dGFjaG1lbnQg cHJvY2VkdXJlLg0KDQpKb3kNCg0KQk9DIE1pY2hhZWwgPG1pY2hhZWwuYm9jQGNlYS5mcjxtYWls dG86bWljaGFlbC5ib2NAY2VhLmZyPj4NCg0KMjAxMi0wNy0yMCAxNDoxNw0KDQrmlLbku7bkuroN Cg0KInpob3UueGluZ3l1ZUB6dGUuY29tLmNuPG1haWx0bzp6aG91Lnhpbmd5dWVAenRlLmNvbS5j bj4iIDx6aG91Lnhpbmd5dWVAenRlLmNvbS5jbjxtYWlsdG86emhvdS54aW5neXVlQHp0ZS5jb20u Y24+Pg0KDQrmioTpgIENCg0KIm5ldGV4dEBpZXRmLm9yZzxtYWlsdG86bmV0ZXh0QGlldGYub3Jn PiIgPG5ldGV4dEBpZXRmLm9yZzxtYWlsdG86bmV0ZXh0QGlldGYub3JnPj4sICJuZXRleHQtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmc+IiA8bmV0ZXh0LWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPj4NCg0K5Li76aKY DQoNClJFIDogUmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBt aXAtMDMudHh0DQoNCg0KDQoNCg0KDQoNCkhpLA0KDQoNCkJ5IHRoZSB3YXksIGlmIHRoZSBNQUcg c2VuZHMgYSBNTlBzIG9wdGlvbiBzZXQgdG8gMCBpbiB0aGUgUEJVIGl0IGlzIHJlZHVuZGFudCB0 byBzZXQgYSBmbGFnIHRvIHVuZGVyc3RhbmQgaXQgaXMgZm9yIGEgbW9iaWxlIHJvdXRlci4NCg0K DQpNaWNoYWVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpEZSA6IHpob3Uu eGluZ3l1ZUB6dGUuY29tLmNuPG1haWx0bzp6aG91Lnhpbmd5dWVAenRlLmNvbS5jbj4gW3pob3Uu eGluZ3l1ZUB6dGUuY29tLmNuXQ0KRGF0ZSBkJ2Vudm9pIDogdmVuZHJlZGkgMjAganVpbGxldCAy MDEyIDA0OjIxDQrDgCA6IEJPQyBNaWNoYWVsDQpDYyA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPjsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+OyBuZXRleHRAaWV0Zi5vcmc8bWFpbHRvOm5l dGV4dEBpZXRmLm9yZz47IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRleHQtYm91 bmNlc0BpZXRmLm9yZz4NCk9iamV0IDog562U5aSNOiBSZTogW25ldGV4dF0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQNCg0KDQpIaSwNCg0KVGhlIHB1cnBvc2Ug b2Ygc2V0dGluZyBSIGZsYWcgaXMgdG8gaW5kaWNhdGUgdGhlIG5ldHdvcmsgdGhhdCBuZXR3b3Jr IG1vYmlsaXR5IHNlcnZpY2UgaXMgYWxsb3dlZCB0byB0aGUgbW9iaWxlIG5vZGUgYXMgc3BlY2lm aWVkIGluIHNlY3Rpb24gMy4yLiBJbiB0aGlzIGRyYWZ0LCBpdCBqdXN0IGZvY3VzIG9uIHRoZSB3 YXkgdG8gYXNzaWduIHRoZSBNTlAgdG8gdGhlIE1SIGJhc2VkIG9uIERIQ1B2Ni1QRCB0cmlnZ2Vy aW5nIG1lY2hhbmlzbS4NCg0KUmVnYXJkaW5nIHRoZSBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChz KSwgSSBkb250IGdldCB5b3VyIHBvaW50IHZlcnkgbXVjaC4gQ291bGQgeW91IGV4cGxhaW4gbW9y ZT8NCg0KQmVzdCBSZWdhcmRzLA0KSm95DQoNCm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTItMDctMTYgMTc6MTI6NTY6DQoN Cj4gSGVsbG8gYWxsLA0KPg0KPiBDb25jZXJuaW5nIHRoaXMgZHJhZnQsIEkgd291bGQgbGlrZSB0 byBrbm93IHdoeSB5b3UgbmVlZCB0byBzZXQgdGhlDQo+IFIgZmxhZyBpbiBQQlUNCj4gKGJlY2F1 c2UgeW91IGRvbid0IGV4cGxhaW4gaXQgaW4gdGhlIGRyYWZ0KSBhbmQgaWYgeW91ciBhcHByb2Fj aCBpcw0KPiB0byBub3QgdGFrZQ0KPiBpbnRvIGFjY291bnQgcG9zc2libGUgaGludHMgaW4gSUFf UEQocykuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHdlDQo+IGp1c3QgaGF2ZSB0byBwcm92aWRlDQo+ IE1OUChzKSBhdCBNUiBhdHRhY2htZW50IHdpdGggdGhlIEhOUChzKSBhbmQgd2UgbW92ZSBvbiBh bm90aGVyIHN1YmplY3QuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+DQo+IE1pY2hhZWwNCj4NCj4NCj4g PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZSA6IG5ldGV4dC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpuZXRleHQtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGENCj4gPiBwYXJ0IGRlIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+IEVudm95w6kgOiBsdW5kaSAx NiBqdWlsbGV0IDIwMTIgMDM6MjkNCj4gPiDDgCA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWls dG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiA+IENjIDogbmV0ZXh0QGlldGYub3JnPG1haWx0 bzpuZXRleHRAaWV0Zi5vcmc+DQo+ID4gT2JqZXQgOiBbbmV0ZXh0XSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4g PiBkaXJlY3Rvcmllcy4NCj4gPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0 d29yay1CYXNlZCBNb2JpbGl0eSBFeHRlbnNpb25zDQo+ID4gV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4gPg0KPiA+ICAgIFRpdGxlICAgICAgICAgICA6IFByZWZpeCBEZWxlZ2F0aW9uIGZv ciBQcm94eSBNb2JpbGUgSVB2Ng0KPiA+ICAgIEF1dGhvcihzKSAgICAgICA6IFhpbmd5dWUgWmhv dQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm91bmkgS29yaG9uZW4NCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIENhcmwgV2lsbGlhbXMNCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNyaSBHdW5kYXZlbGxpDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBD YXJsb3MgSi4gQmVybmFyZG9zDQo+ID4gICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1u ZXRleHQtcGQtcG1pcC0wMy50eHQNCj4gPiAgICBQYWdlcyAgICAgICAgICAgOiAxNg0KPiA+ICAg IERhdGUgICAgICAgICAgICA6IDIwMTItMDctMTUNCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAg IFByb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMgSVAgbW9iaWxpdHkgZm9yIGEgaG9zdCB3aXRob3V0 IHJlcXVpcmluZw0KPiA+ICAgIGl0cyBwYXJ0aWNpcGF0aW9uIGluIGFueSBtb2JpbGl0eSBzaWdu YWxpbmcsIGJlaW5nIHRoZSBuZXR3b3JrDQo+ID4gICAgcmVzcG9uc2libGUgZm9yIG1hbmFnaW5n IElQIG1vYmlsaXR5IG9uIGJlaGFsZiBvZiB0aGUgaG9zdC4NCj4gPiBIb3dldmVyLA0KPiA+ICAg IFByb3h5IE1vYmlsZSBJUHY2IGRvZXMgbm90IHN1cHBvcnQgYXNzaWduaW5nIGEgcHJlZml4IHRv IGEgcm91dGVyDQo+ID4gYW5kDQo+ID4gICAgbWFuYWdpbmcgaXRzIElQIG1vYmlsaXR5LiAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvDQo+ID4gICAgUHJveHkgTW9iaWxl IElQdjYgcHJvdG9jb2wgZm9yIHN1cHBvcnRpbmcgbmV0d29yayBtb2JpbGl0eSB1c2luZw0KPiA+ ICAgIERIQ1B2Ni1iYXNlZCBQcmVmaXggRGVsZWdhdGlvbi4NCj4gPg0KPiA+DQo+ID4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcA0KPiA+ DQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMw0K PiA+DQo+ID4gQSBkaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGV4dC1w ZC1wbWlwLTAzDQo+ID4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ID4gbmV0ZXh0QGlldGYub3JnPG1h aWx0bzpuZXRleHRAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRleHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRleHRAaWV0Zi5vcmc8bWFpbHRv Om5ldGV4dEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRleHQNCj4NCg== --_000_94D2EEADE1F74740979E8041CBA339380355ACBFEXDAG0B3intrace_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToy IDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVu aWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJ cGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpveSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2sgc28gSSBndWVzcyBmb3IgeW91IHRoZSBpbml0 aWFsIGF0dGFjaG1lbnQgcHJvY2VkdXJlIGlzIHRoZSBQQlUgc2VudCBmb3IgSE5Qcy4gUmlnaHQ/ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHNvOg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EbyB5b3UgbWVhbiB5b3Ug ZG9u4oCZdCBzZXQgdGhlIGZsYWcgaW4gc3Vic2VxdWVudCBQQlVzID88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSBtZWFuIHRoZSBMTUEgaGFzIHRvIGRv IHNvbWV0aGluZyBzcGVjaWFsIHdoZW4gaXQgcmVjZWl2ZXMgdGhlIFIgZmxhZyB0aGF0IGl0IHdp bGwgbm90IGRvIHdoZW4gcmVjZWl2aW5nIHRoZSBNTlAgb3B0aW9uIHNldCB0byB6ZXJvPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8geW91IG1lYW4gdGhlIGNo ZWNrIG9mIHBvbGljeSBwcm9maWxlIGZvciB0aGUgTVIgaXMg4oCcc3RhdGVsZXNz4oCdICh0aGUg TUFHIGRvIG5vdCBzdG9yZSB0aGUgZmFjdCB0aGF0IHRoZSBNUiBuZWVkcyBNTlBzKT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gemhvdS54aW5neXVl QHp0ZS5jb20uY24gW21haWx0bzp6aG91Lnhpbmd5dWVAenRlLmNvbS5jbl0NCjxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAyMCBqdWlsbGV0IDIwMTIgMDg6MjU8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IEJPQyBNaWNoYWVsPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBuZXRleHRAaWV0 Zi5vcmc7IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7Ij7nrZQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij7lpI08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogUkUgOiBSZTogW25l dGV4dF0gSS1EDQogQWN0aW9uOiBkcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVsbG8sPC9z cGFuPiA8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb3UgY2FuIGRvdWJs ZSBjaGVjayB0aGUgZHJhZnQgd2hpY2ggc2F5cyB0aGUgUiBmbGFnIGlzIHNldCBkdXJpbmcgdGhl DQo8aT5pbml0aWFsIGF0dGFjaG1lbnQgcHJvY2VkdXJlPC9pPi48L3NwYW4+IDxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkpveTwvc3Bhbj4gPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgd2lkdGg9IjM1JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNS4wJTtwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Qk9DIE1pY2hhZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpt aWNoYWVsLmJvY0BjZWEuZnIiPm1pY2hhZWwuYm9jQGNlYS5mcjwvYT4mZ3Q7PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDEyLTA3LTIwIDE0OjE3PC9zcGFuPg0KPG86cD48L286 cD48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2NCUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6 NjQuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5 bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7mlLbku7bkuro8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OzxhIGhyZWY9Im1haWx0bzp6aG91Lnhpbmd5dWVA enRlLmNvbS5jbiI+emhvdS54aW5neXVlQHp0ZS5jb20uY248L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86emhvdS54aW5neXVlQHp0ZS5jb20uY24iPnpob3UueGluZ3l1ZUB6dGUuY29tLmNu PC9hPiZndDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNo byZxdW90OyI+5oqE6YCBPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDs8YSBocmVmPSJtYWls dG86bmV0ZXh0QGlldGYub3JnIj5uZXRleHRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bmV0ZXh0QGlldGYub3JnIj5uZXRleHRAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnIj5uZXRleHQtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGV4dC1ib3VuY2VzQGll dGYub3JnIj5uZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPiA8bzpwPg0KPC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPumimDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UkUgOiBSZTog W25ldGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcC0wMy50eHQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQi PjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0 IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkhpLCA8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkJ5IHRoZSB3YXksIGlmIHRoZSBNQUcgc2VuZHMgYSBNTlBzIG9wdGlvbiBzZXQgdG8gMCBpbiB0 aGUgUEJVIGl0IGlzIHJlZHVuZGFudCB0byBzZXQgYSBmbGFnIHRvIHVuZGVyc3RhbmQgaXQgaXMg Zm9yIGEgbW9iaWxlIHJvdXRlci48L3NwYW4+DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+TWljaGFlbDwvc3Bhbj4gPG86cD4NCjwvbzpwPjwvcD4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGUgOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i bWFpbHRvOnpob3UueGluZ3l1ZUB6dGUuY29tLmNuIj48c3BhbiBsYW5nPSJFTi1VUyI+emhvdS54 aW5neXVlQHp0ZS5jb20uY248L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBbemhvdS54aW5neXVlQHp0ZS5jb20uY25dPGI+PGJyPg0KRGF0 ZSBkJ2Vudm9pIDo8L2I+IHZlbmRyZWRpIDIwIGp1aWxsZXQgMjAxMiAwNDoyMTxiPjxicj4NCsOA IDo8L2I+IEJPQyBNaWNoYWVsPGI+PGJyPg0KQ2MgOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj48c3Bh biBsYW5nPSJFTi1VUyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciPjxzcGFuIGxhbmc9IkVOLVVTIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOm5ldGV4dEBpZXRm Lm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPm5ldGV4dEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5uZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KT2JqZXQgOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtNUyBNaW5jaG8mcXVvdDsiPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuWkjTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjog UmU6IFtuZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkhpLDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+IDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGJyPg0KVGhlIHB1cnBvc2Ugb2Ygc2V0dGluZyBSIGZsYWcgaXMgdG8gaW5kaWNhdGUgdGhl IG5ldHdvcmsgdGhhdCBuZXR3b3JrIG1vYmlsaXR5IHNlcnZpY2UgaXMgYWxsb3dlZCB0byB0aGUg bW9iaWxlIG5vZGUgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gMy4yLg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkluIHRoaXMgZHJhZnQsIGl0IGp1c3QgZm9jdXMgb24gdGhlIHdh eSB0byBhc3NpZ24gdGhlIE1OUCB0byB0aGUgTVIgYmFzZWQgb24gREhDUHY2LVBEIHRyaWdnZXJp bmcgbWVjaGFuaXNtLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxi cj4NClJlZ2FyZGluZyB0aGUgcG9zc2libGUgaGludHMgaW4gSUFfUEQocyksIEkgZG9udCBnZXQg eW91ciBwb2ludCB2ZXJ5IG11Y2guIENvdWxkIHlvdSBleHBsYWluIG1vcmU/PC9zcGFuPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KSm95PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5uZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsi PuWGmeS6jjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiAyMDEyLTA3LTE2IDE3OjEyOjU2Ojxicj4NCjxicj4NCiZndDsgSGVsbG8gYWxsLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBDb25jZXJuaW5nIHRoaXMgZHJhZnQsIEkgd291bGQgbGlrZSB0byBrbm93 IHdoeSB5b3UgbmVlZCB0byBzZXQgdGhlIDxicj4NCiZndDsgUiBmbGFnIGluIFBCVSA8YnI+DQom Z3Q7IChiZWNhdXNlIHlvdSBkb24ndCBleHBsYWluIGl0IGluIHRoZSBkcmFmdCkgYW5kIGlmIHlv dXIgYXBwcm9hY2ggaXMgPGJyPg0KJmd0OyB0byBub3QgdGFrZSA8YnI+DQomZ3Q7IGludG8gYWNj b3VudCBwb3NzaWJsZSBoaW50cyBpbiBJQV9QRChzKS4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5JZiB0aGlzIGlzIHRoZSBjYXNlLCB3ZTxicj4NCiZndDsganVzdCBoYXZl IHRvIHByb3ZpZGUgPGJyPg0KJmd0OyBNTlAocykgYXQgTVIgYXR0YWNobWVudCB3aXRoIHRoZSBI TlAocykgYW5kIHdlIG1vdmUgb24gYW5vdGhlciBzdWJqZWN0LiAmbmJzcDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTWljaGFl bDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IERlIDogPGEgaHJlZj0ibWFpbHRvOm5ldGV4dC1ib3Vu Y2VzQGlldGYub3JnIj5uZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0 bzpuZXRleHQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3Jn PC9hPl0gRGUgbGE8YnI+DQomZ3Q7ICZndDsgcGFydCBkZSA8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyAmZ3Q7IEVudm95w6kgOiBsdW5kaSAxNiBqdWlsbGV0IDIwMTIgMDM6Mjk8YnI+DQomZ3Q7ICZn dDsgw4AgOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IENjIDogPGEgaHJlZj0ibWFpbHRvOm5ldGV4 dEBpZXRmLm9yZyI+bmV0ZXh0QGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyBPYmpldCA6IFtu ZXRleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDMudHh0PGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0K Jmd0OyAmZ3Q7IGRpcmVjdG9yaWVzLjxicj4NCiZndDsgJmd0OyAmbmJzcDtUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrLUJhc2VkIE1vYmlsaXR5IEV4dGVuc2lvbnM8YnI+ DQomZ3Q7ICZndDsgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogUHJlZml4IERlbGVnYXRpb24gZm9yIFByb3h5IE1vYmlsZSBJUHY2PGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBY aW5neXVlIFpob3U8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEpvdW5pIEtvcmhvbmVuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBDYXJsIFdpbGxpYW1zPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBTcmkgR3VuZGF2ZWxsaTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FybG9zIEouIEJlcm5hcmRvczxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7RmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFm dC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzLnR4dDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 UGFnZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDE2PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDtEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7OiAyMDEyLTA3LTE1PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBYnN0cmFj dDo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1Byb3h5IE1vYmlsZSBJUHY2IGVuYWJsZXMg SVAgbW9iaWxpdHkgZm9yIGEgaG9zdCB3aXRob3V0IHJlcXVpcmluZzxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7aXRzIHBhcnRpY2lwYXRpb24gaW4gYW55IG1vYmlsaXR5IHNpZ25hbGluZywg YmVpbmcgdGhlIG5ldHdvcms8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3Jlc3BvbnNpYmxl IGZvciBtYW5hZ2luZyBJUCBtb2JpbGl0eSBvbiBiZWhhbGYgb2YgdGhlIGhvc3QuPGJyPg0KJmd0 OyAmZ3Q7IEhvd2V2ZXIsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUg SVB2NiBkb2VzIG5vdCBzdXBwb3J0IGFzc2lnbmluZyBhIHByZWZpeCB0byBhIHJvdXRlcjxicj4N CiZndDsgJmd0OyBhbmQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO21hbmFnaW5nIGl0cyBJ UCBtb2JpbGl0eS4gJm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRv PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQcm94eSBNb2JpbGUgSVB2NiBwcm90b2NvbCBm b3Igc3VwcG9ydGluZyBuZXR3b3JrIG1vYmlsaXR5IHVzaW5nPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtESENQdjYtYmFzZWQgUHJlZml4IERlbGVnYXRpb24uPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1uZXRleHQtcGQtcG1pcCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXA8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lv biBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1uZXRleHQtcGQtcG1pcC0wMyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0ZXh0LXBkLXBtaXAtMDM8L3NwYW4+PC9hPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgQSBkaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6PGJyPg0KJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW5ldGV4dC1wZC1wbWlwLTAzIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGV4dC1wZC1wbWlwLTAzPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyAmZ3Q7IDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjxzcGFuIGxhbmc9IkVOLVVTIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyBuZXRleHQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0ibWFpbHRvOm5ldGV4dEBpZXRmLm9yZyI+ PHNwYW4gbGFuZz0iRU4tVVMiPm5ldGV4dEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KJmd0OyAmZ3Q7IDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg bmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86bmV0ZXh0QGlldGYub3JnIj48c3BhbiBsYW5nPSJF Ti1VUyI+bmV0ZXh0QGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_94D2EEADE1F74740979E8041CBA339380355ACBFEXDAG0B3intrace_-- From Basavaraj.Patil@nokia.com Mon Jul 23 09:27:47 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 B2A7311E8091 for ; Mon, 23 Jul 2012 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 CCcqeVPlfOk8 for ; Mon, 23 Jul 2012 09:27:47 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2B11E807F for ; Mon, 23 Jul 2012 09:27:46 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NGRiYJ028974 for ; Mon, 23 Jul 2012 19:27:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 19:28:23 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Mon, 23 Jul 2012 18:27:43 +0200 From: To: Thread-Topic: Comment on I-D: draft-krishnan-netext-update-notifications Thread-Index: AQHNaPAWQListUIooU6YpPuxXJiVRw== Date: Mon, 23 Jul 2012 16:27:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <1281A771D30CEC4891A4DC984DA4B4A1@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2012 16:28:23.0231 (UTC) FILETIME=[2DBB6CF0:01CD68F0] X-Nokia-AV: Clean Subject: [netext] Comment on I-D: draft-krishnan-netext-update-notifications X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 16:27:47 -0000 Suresh, You are proposing unsolicited messages to be sent by the LMA to the MAG for changing mobility session characteristics in I-D: draft-krishnan-netext-update-notifications. The I-D states:=20 " One such scenario where such a mechanism is needed is when the LMA wants to inform the MAG that it needs to reregister. " A mobility session has a lifetime associated with it. Policy could limit this lifetime to be reasonably short and as a result the renewal of the binding initiated by the MAG could provide the LMA the necessary means. It would be good if you can provide a few good use cases justifying the need for such unsolicited LMA initiated messages to the MAG in the I-D. While we do have revocation capability, it is not preferred to be used for reasons other than its intended purpose. -Raj From Basavaraj.Patil@nokia.com Mon Jul 23 09:40:39 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 52DED21F8564 for ; Mon, 23 Jul 2012 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BJGkWefzcADk for ; Mon, 23 Jul 2012 09:40:38 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2D21F858D for ; Mon, 23 Jul 2012 09:40:38 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NGeYEp003402 for ; Mon, 23 Jul 2012 19:40:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 19:41:12 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Mon, 23 Jul 2012 18:40:16 +0200 From: To: Thread-Topic: Comments on I-D: draft-bhandari-netext-pmipv6-dhcp-options Thread-Index: AQHNaPHWBFu37wgJmEONXE0MaJ3J3g== Date: Mon, 23 Jul 2012 16:40:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.54] Content-Type: multipart/alternative; boundary="_000_CC32E7B021A7Fbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2012 16:41:12.0162 (UTC) FILETIME=[F80CFC20:01CD68F1] X-Nokia-AV: Clean Subject: [netext] Comments on I-D: draft-bhandari-netext-pmipv6-dhcp-options X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 16:40:39 -0000 --_000_CC32E7B021A7Fbasavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding the dhcp-options I-D: 1. I think it would be better served if this I-D was presented in the DH= C WG 2. The MAG may host a DHCPv4 server=85 However the details of how such a= DHCPv4 server gets the options that are relevant to an MN are outside the = scope of Netext and the PMIP6 protocol IMHO. You could just as well deliver= the specific options like SIP server address etc. to the MAG in the AAA re= sponse and deliver them to the DHCPv4 server collocated at the MAG. 3. The idea of doing PMIP6 signaling to the LMA to get DHCPv4 options fo= r the server collocated at the MAG does not make sense IMO. What does the L= MA have to do with DHCPv4 options? -Raj --_000_CC32E7B021A7Fbasavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <00097376C39036419CA37D68E4D6B24E@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Regarding the dhcp-options I-D:

  1. I think it would be better served if this I-D was presented in the DHC = WG
  2. The MAG may host a DHCPv4 server=85 However the details of how s= uch a DHCPv4 server gets the options that are relevant to an MN are outside= the scope of Netext and the PMIP6 protocol IMHO. You could just as well de= liver the specific options like SIP server address etc. to the MAG in the AAA response and deliver them to the DHCPv4= server collocated at the MAG. 
  3. The idea of doing PMIP6 signal= ing to the LMA to get DHCPv4 options for the server collocated at the MAG d= oes not make sense IMO. What does the LMA have to do with DHCPv4 options?&n= bsp;

-Raj

--_000_CC32E7B021A7Fbasavarajpatilnokiacom_-- From Basavaraj.Patil@nokia.com Mon Jul 23 10:11:21 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 A099D21F8596 for ; Mon, 23 Jul 2012 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 6cNFXSEk-oX5 for ; Mon, 23 Jul 2012 10:11:15 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2CE21F859A for ; Mon, 23 Jul 2012 10:11:15 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NHBDau029990 for ; Mon, 23 Jul 2012 20:11:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 20:11:51 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Mon, 23 Jul 2012 19:11:13 +0200 From: To: Thread-Topic: Comments on I-D: draft-sarikaya-netext-fb-support-extensions Thread-Index: AQHNaPYpTX/0CSvGiU6Gu/2cDgKw+g== Date: Mon, 23 Jul 2012 17:11:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <59C6AD8F5FE0CB4C8CC51B7E9F7BC031@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2012 17:11:51.0990 (UTC) FILETIME=[40AC7560:01CD68F6] X-Nokia-AV: Clean Subject: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:11:21 -0000 A few comments: 1. I am not convinced with the problem statement specified in the I-D. The WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended to provide a solution that is similar (albeit without UE interaction) to what exists for MIP6.=20 2. If the UE is assigned different HNPs to its interfaces as a result of connecting via more than one interface, the current assumption is that there is no switching of flows between those interfaces. The only case where we enable flow mobility is when the UE has a single HNP assigned to it but connected via multiple interfaces (possible via the use of logical-interface at the UE). 3. The I-D does not explain how flow switching would work if the MN has different HNPs assigned to its interfaces.The extensions to PMIP6 signaling with the new flags to support flow mobility can wait until you have a clear explanation for the same. -Raj From Basavaraj.Patil@nokia.com Mon Jul 23 10:23:56 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 C77B421F85FC for ; Mon, 23 Jul 2012 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 5QQw0hvnkvSf for ; Mon, 23 Jul 2012 10:23:56 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3B21F861B for ; Mon, 23 Jul 2012 10:23:55 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NHNn7w012379 for ; Mon, 23 Jul 2012 20:23:53 +0300 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); Mon, 23 Jul 2012 20:24:30 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Mon, 23 Jul 2012 19:23:50 +0200 From: To: Thread-Topic: Comments on I-D: draft-tu-netext-mn-status-option-02.txt Thread-Index: AQHNaPfsr+OVqfbzHEuWSUjuqpiZjg== Date: Mon, 23 Jul 2012 17:23:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <460B04D5E699B140B96D38D617FF6F0F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2012 17:24:30.0278 (UTC) FILETIME=[04A60660:01CD68F8] X-Nokia-AV: Clean Subject: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:23:56 -0000 Hello, The proposal of sending additional information related to the MNs connectivity state is no doubt useful and can help the LMA make a more informed decision about switching flows. However I am trying to understand how the MAG gets such access/interface specific information. Do you expect the access network to provide such information on a per MN basis? There is an implicit assumption that the MAG has access to resource information that is maintained by nodes in the access network. Is that the case? -Raj=20 From sarikaya2012@gmail.com Mon Jul 23 13:03:39 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 80DCF11E807F for ; Mon, 23 Jul 2012 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 Xmwuz2sA96CR for ; Mon, 23 Jul 2012 13:03:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D30BE11E80A1 for ; Mon, 23 Jul 2012 13:03:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so6455548yen.31 for ; Mon, 23 Jul 2012 13:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3PZMsUKS3fhf3ZWbm6BVf0OvHiZiQqtIJ/FeepqnNxo=; b=cSIQCEmkUDYyg/sO6XSOMLazIO8nKMEvh/zxIeEvoGKAvkE6QCmUwIY4vwcElJqMYn f0gEumRu+E1LpzIldAcP6+wtjgMoLelbVJAkyBhrIP65M4SzH5Dv6HiUFFh06ZrXCAol gIiefOQT2Hrw0xd2HM0XWh/5QL4pERmHePjVkKwbKyaHBThi2meSg3FU4aUQbQiS+3XX YqZID0CRjw8zAvr4oAXrJ3zV9oSg3nv7KpmBFeWeM0yDIuKpCgPFwcxw4H3v95QdyYLZ OuTVTDpfEWvd79Lm07GvNjiNDZ2J5tIoiY9N/KRhTU6pSAuPyUxpkrI7ymWpHUyUOxII 7T7A== MIME-Version: 1.0 Received: by 10.42.154.199 with SMTP id r7mr9349191icw.55.1343073817857; Mon, 23 Jul 2012 13:03:37 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 23 Jul 2012 13:03:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jul 2012 15:03:37 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 20:03:39 -0000 Hi Basavaraj, On Mon, Jul 23, 2012 at 12:11 PM, wrote: > > A few comments: > > 1. I am not convinced with the problem statement specified in the I-D. The > WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended to > provide a solution that is similar (albeit without UE interaction) to what > exists for MIP6. > > 2. If the UE is assigned different HNPs to its interfaces as a result of > connecting via more than one interface, the current assumption is that > there is no switching of flows between those interfaces. The only case > where we enable flow mobility is when the UE has a single HNP assigned to > it but connected via multiple interfaces (possible via the use of > logical-interface at the UE). > > 3. The I-D does not explain how flow switching would work if the MN has > different HNPs assigned to its interfaces.The extensions to PMIP6 > signaling with the new flags to support flow mobility can wait until you > have a clear explanation for the same. The problem that my I-D addresses is better explained in (from 3rd paragraph of Section 3, a little bit annotated): In base Proxy Mobile IPv6, i.e. RFC 5213, LMA treats each interface independently of the other interface(s) MN may have and tries to provide mobility support for each interface. LMA does not manage bindings from different interfaces of the mobile node in an integrated fashion. So LMA can not be in control of moving the flows in between interfaces. So a binding cache management similar to RFC 5648, i.e. the MCoA work in MIPv6 is needed and this is what my I-D comes up with. Reading Carlos' I-D, version 04, he comes close to it, but specific modifications to the binding cache are not spelled out and they should be using draft-sarikaya-netext-fb-support-extensions-02 or draft-sarikaya-netext-fb-support-extensions-02 should be normative reference. Hope this clarifies. Behcet From tu.yangwei@zte.com.cn Wed Jul 25 00:11:47 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 BC62711E807F; Wed, 25 Jul 2012 00:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.436 X-Spam-Level: X-Spam-Status: No, score=-99.436 tagged_above=-999 required=5 tests=[AWL=-1.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 dgibAWaOaMK2; Wed, 25 Jul 2012 00:11:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 57D7E21F8493; Wed, 25 Jul 2012 00:11:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107233502467742; Wed, 25 Jul 2012 15:01:19 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 46806.5406157678; Wed, 25 Jul 2012 15:11:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6P7BV5R099177; Wed, 25 Jul 2012 15:11:31 +0800 (GMT-8) (envelope-from tu.yangwei@zte.com.cn) In-Reply-To: To: MIME-Version: 1.0 X-KeepSent: 769F0E31:5762C27E-48257A46:00221758; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: tu.yangwei@zte.com.cn Date: Wed, 25 Jul 2012 15:11:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-25 15:11:28, Serialize complete at 2012-07-25 15:11:28 Content-Type: multipart/alternative; boundary="=_alternative 0028054448257A46_=" X-MAIL: mse02.zte.com.cn q6P7BV5R099177 Cc: netext@ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.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, 25 Jul 2012 07:11:47 -0000 This is a multipart message in MIME format. --=_alternative 0028054448257A46_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQmFzYXZhcmFqLA0KSW4gbXkgdW5kZXJzdGFuZGluZyB0aGUgSWRsZS9Qb3dlciBzYXZpbmcg bW9kZSBpbmZvcm1hdGlvbiBjYW4gYmUgDQpyZXRyaWV2ZWQgYnkgdGhlIE1BRyBmcm9tIHNvbWUg bmV0d29yayBlbGVtZW50cywgc3VjaCBhcyBQYWdpbmcgY29udHJvbGxlciANCmluIFdpTUFYLCBN TUUgaW4gM0dQUCBhbmQgQVAgaW4gV0xBTi4gSW4gc29tZSBvZiB0aGUgYWNjZXNzIG5ldHdvcmtz LCB0aGUgDQpNQUcgaXMgZXZlbiBjb21iaW5lZCB3aXRoIHRoZXNlIG5ldHdvcmsgZWxlbWVudHMo ZS5nLiBQQyBpbiBXaU1BWCmho0ZvciANCnRoZSByYWRpbyBxdWFsaXR5IGluZm9ybWF0aW9uLCB0 aGVyZSBhcmUgc29tZSBtZWNoYW5pc21lcyBoYXZlIGFscmVhZHkgYmUgDQpwcm92aWRlZCBmb3Ig c29tZSBhY2Nlc3MgbmV0d29ya3MsIHRha2UgM0dQUCBhY2Nlc3MgbmV0d29yayBmb3IgZXhhbXBs ZSwgDQp0aGUgZU5CIG9idGFpbnMgdGhlIHJhZGlvIHF1YWxpdHkgb2YgdGhlIE1vYmlsZSBub2Rl IHBlcmlvZGljYWxseShlLmcuIHRvIA0Kb2ZmZXIgc29tZSBsb2NhdGlvbiBiYXNlIHNlcnZpY2Vz ICksIGFuZCB0aGVzZSBpbmZvcm1hdGlvbiBjYW4gYmUgDQpyZXRyaWV2ZWQgYnkgdGhlIE1BRyB0 byBtYWtlIHRoZSBkZWNpc2lvbiB0byB1cGRhdGUgbG93IHJhZGlvIHF1YWxpdHkgDQpldmVudCB0 byB0aGUgTE1BLg0KRm9yIG1vYmlsZSBub2RlIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24oTElGLCBk dWFsIElQdjQvSVB2NiBzdGFjayBhbmQgTUlQIA0Kc3RhY2spLCB0aGVzZSBpbmZvcm1hdGlvbiBj YW4gYmUgZm9yd2FyZGVkIGZyb20gdGhlIE1OIHRvIHRoZSBNQUcgYmVmb3JlIA0KdGhlIFBNSVAg c2lnbmFsbGluZyAob25lIHBvc3NpYmlsaXR5IGlzIHVzaW5nIHRoZSBFQVAgcHJvY2VzcykuIEFu ZCB0aGVuIA0KdGhlIE1BRyBjYW4gZm9yd2FyZCB0aGVzZSBpbmZvcm1hdGlvbiB0byB0aGUgTE1B IHVzaW5nIHRoZSBQQlUvUEJBIA0KbWVzc2FnZXMuDQpUaGFua3MgZm9yIHlvdXIgZ29vZCBjb21t ZW50cywgYW5kIGhvcGUgdGhpcyBjbGFyaWZpZXMsDQpCUiwNCllhbmd3ZWkgVHUNCiANCg0KDQoN CjxCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tPiANCreivP7IyzogIG5ldGV4dC1ib3VuY2VzQGll dGYub3JnDQoyMDEyLTA3LTI0IDAxOjIzDQoNCsrVvP7Iyw0KPG5ldGV4dEBpZXRmLm9yZz4NCrOt y80NCg0K1vfM4g0KW25ldGV4dF0gQ29tbWVudHMgb24gSS1EOiBkcmFmdC10dS1uZXRleHQtbW4t c3RhdHVzLW9wdGlvbi0wMi50eHQNCg0KDQoNCg0KDQoNCg0KSGVsbG8sDQoNClRoZSBwcm9wb3Nh bCBvZiBzZW5kaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgTU5zDQpj b25uZWN0aXZpdHkgc3RhdGUgaXMgbm8gZG91YnQgdXNlZnVsIGFuZCBjYW4gaGVscCB0aGUgTE1B IG1ha2UgYSBtb3JlDQppbmZvcm1lZCBkZWNpc2lvbiBhYm91dCBzd2l0Y2hpbmcgZmxvd3MuDQpI b3dldmVyIEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IHRoZSBNQUcgZ2V0cyBzdWNoIGFj Y2Vzcy9pbnRlcmZhY2UNCnNwZWNpZmljIGluZm9ybWF0aW9uLiBEbyB5b3UgZXhwZWN0IHRoZSBh Y2Nlc3MgbmV0d29yayB0byBwcm92aWRlIHN1Y2gNCmluZm9ybWF0aW9uIG9uIGEgcGVyIE1OIGJh c2lzPyBUaGVyZSBpcyBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlDQpNQUcgaGFzIGFj Y2VzcyB0byByZXNvdXJjZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG1haW50YWluZWQgYnkgbm9kZXMg aW4gdGhlDQphY2Nlc3MgbmV0d29yay4gSXMgdGhhdCB0aGUgY2FzZT8NCg0KLVJhaiANCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGV4dCBtYWls aW5nIGxpc3QNCm5ldGV4dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRleHQNCg0KDQoNCg== --=_alternative 0028054448257A46_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IaSBCYXNhdmFyYWosPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SW4gbXkgdW5kZXJzdGFuZGluZyB0aGUgSWRsZS9Q b3dlciBzYXZpbmcNCm1vZGUgaW5mb3JtYXRpb24gY2FuIGJlIHJldHJpZXZlZCBieSB0aGUgTUFH IGZyb20gc29tZSBuZXR3b3JrIGVsZW1lbnRzLA0Kc3VjaCBhcyBQYWdpbmcgY29udHJvbGxlciBp biBXaU1BWCwgTU1FIGluIDNHUFAgYW5kIEFQIGluIFdMQU4uIEluIHNvbWUNCm9mIHRoZSBhY2Nl c3MgbmV0d29ya3MsIHRoZSBNQUcgaXMgZXZlbiBjb21iaW5lZCB3aXRoIHRoZXNlIG5ldHdvcmsg ZWxlbWVudHMoZS5nLg0KUEMgaW4gV2lNQVgpoaNGb3IgdGhlIHJhZGlvIHF1YWxpdHkgaW5mb3Jt YXRpb24sIHRoZXJlIGFyZSBzb21lIG1lY2hhbmlzbWVzDQpoYXZlIGFscmVhZHkgYmUgcHJvdmlk ZWQgZm9yIHNvbWUgYWNjZXNzIG5ldHdvcmtzLCB0YWtlIDNHUFAgYWNjZXNzIG5ldHdvcmsNCmZv ciBleGFtcGxlLCB0aGUgZU5CIG9idGFpbnMgdGhlIHJhZGlvIHF1YWxpdHkgb2YgdGhlIE1vYmls ZSBub2RlIHBlcmlvZGljYWxseShlLmcuDQp0byBvZmZlciBzb21lIGxvY2F0aW9uIGJhc2Ugc2Vy dmljZXMgKSwgYW5kIHRoZXNlIGluZm9ybWF0aW9uIGNhbiBiZSByZXRyaWV2ZWQNCmJ5IHRoZSBN QUcgdG8gbWFrZSB0aGUgZGVjaXNpb24gdG8gdXBkYXRlIGxvdyByYWRpbyBxdWFsaXR5IGV2ZW50 IHRvIHRoZQ0KTE1BLjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Rm9yIG1v YmlsZSBub2RlIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24oTElGLA0KZHVhbCBJUHY0L0lQdjYgc3Rh Y2sgYW5kIE1JUCBzdGFjayksIHRoZXNlIGluZm9ybWF0aW9uIGNhbiBiZSBmb3J3YXJkZWQNCmZy b20gdGhlIE1OIHRvIHRoZSBNQUcgYmVmb3JlIHRoZSBQTUlQIHNpZ25hbGxpbmcgKG9uZSBwb3Nz aWJpbGl0eSBpcyB1c2luZw0KdGhlIEVBUCBwcm9jZXNzKS4gQW5kIHRoZW4gdGhlIE1BRyBjYW4g Zm9yd2FyZCB0aGVzZSBpbmZvcm1hdGlvbiB0byB0aGUNCkxNQSB1c2luZyB0aGUgUEJVL1BCQSBt ZXNzYWdlcy48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoYW5rcyBmb3Ig eW91ciBnb29kIGNvbW1lbnRzLCBhbmQgaG9wZSB0aGlzDQpjbGFyaWZpZXMsPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5CUiw8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPllhbmd3ZWkgVHU8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+Jm5ic3A7PC9iPjwvZm9udD4NCjxwPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPiZsdDtCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tJmd0OzwvYj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtu ZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDEyLTA3LTI0IDAxOjIzPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtuZXRleHRAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbmV0ZXh0 XSBDb21tZW50cyBvbiBJLUQ6IGRyYWZ0LXR1LW5ldGV4dC1tbi1zdGF0dXMtb3B0aW9uLTAyLnR4 dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+PGJyPg0KSGVsbG8sPGJyPg0KPGJyPg0KVGhlIHByb3Bvc2FsIG9mIHNlbmRpbmcgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBNTnM8YnI+DQpjb25uZWN0aXZpdHkgc3Rh dGUgaXMgbm8gZG91YnQgdXNlZnVsIGFuZCBjYW4gaGVscCB0aGUgTE1BIG1ha2UgYSBtb3JlPGJy Pg0KaW5mb3JtZWQgZGVjaXNpb24gYWJvdXQgc3dpdGNoaW5nIGZsb3dzLjxicj4NCkhvd2V2ZXIg SSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cgdGhlIE1BRyBnZXRzIHN1Y2ggYWNjZXNzL2lu dGVyZmFjZTxicj4NCnNwZWNpZmljIGluZm9ybWF0aW9uLiBEbyB5b3UgZXhwZWN0IHRoZSBhY2Nl c3MgbmV0d29yayB0byBwcm92aWRlIHN1Y2g8YnI+DQppbmZvcm1hdGlvbiBvbiBhIHBlciBNTiBi YXNpcz8gVGhlcmUgaXMgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0aGF0IHRoZTxicj4NCk1BRyBo YXMgYWNjZXNzIHRvIHJlc291cmNlIGluZm9ybWF0aW9uIHRoYXQgaXMgbWFpbnRhaW5lZCBieSBu b2RlcyBpbiB0aGU8YnI+DQphY2Nlc3MgbmV0d29yay4gSXMgdGhhdCB0aGUgY2FzZT88YnI+DQo8 YnI+DQotUmFqIDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbmV0ZXh0IG1haWxpbmcgbGlzdDxicj4NCm5ldGV4dEBpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PGJyPg0K PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0028054448257A46_=-- From Basavaraj.Patil@nokia.com Wed Jul 25 12:53:03 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 D1C8521F8753 for ; Wed, 25 Jul 2012 12:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3BU0f2K3UPkW for ; Wed, 25 Jul 2012 12:53:02 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3A21F8750 for ; Wed, 25 Jul 2012 12:53:01 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PJquXb032566; Wed, 25 Jul 2012 22:52:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jul 2012 22:53:36 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Wed, 25 Jul 2012 21:52:54 +0200 From: To: Thread-Topic: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt Thread-Index: AQHNaPfsr+OVqfbzHEuWSUjuqpiZjpc5dfQAgACA5oA= Date: Wed, 25 Jul 2012 19:52:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.98] Content-Type: multipart/alternative; boundary="_000_CC35B7ED21BECbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jul 2012 19:53:36.0115 (UTC) FILETIME=[2D9BEC30:01CD6A9F] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.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, 25 Jul 2012 19:53:04 -0000 --_000_CC35B7ED21BECbasavarajpatilnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFncmVlIHRoYXQgbmV0d29yayBlbGVtZW50cyBzdWNoIGFzIHRoZSBlTkIgaGF2ZSBmYWly bHkgcmVsZXZhbnQgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgc3RhdGUgb2YgdGhlIGNvbm5l Y3Rpb24gYXNzb2NpYXRlZCB3aXRoIGFuIE1OLiBHZXR0aW5nIHRoaXMgaW5mb3JtYXRpb24gb3Zl ciB0byBhIE1BRyBpcyBub3QgZWFzaWx5IGRvbmUuIFNvIHRoZXJlIGlzIGEgbGVhcCBvZiBmYWl0 aCBoZXJlLiBIb3cgZG8geW91IHByb3Bvc2UgdG8gb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gaXMg c2hhcmVkIHdpdGggdGhlIE1BRz8NCg0KTU4gY2FwYWJpbGl0eSBjb3VsZCBiZSBpbmRpY2F0ZWQg ZHVyaW5nIHRoZSBFQVAgZXhjaGFuZ2UgYXMgeW91IHN1Z2dlc3RlZC4gSSB0aGluayBSYWplZXYn cyBJLUQgZGlzY3Vzc2VzIHN1Y2ggY2FwYWJpbGl0eS4NCg0KLVJhag0KDQpGcm9tOiAiZXh0IHR1 Lnlhbmd3ZWlAenRlLmNvbS5jbjxtYWlsdG86dHUueWFuZ3dlaUB6dGUuY29tLmNuPiIgPHR1Lnlh bmd3ZWlAenRlLmNvbS5jbjxtYWlsdG86dHUueWFuZ3dlaUB6dGUuY29tLmNuPj4NCkRhdGU6IFdl ZG5lc2RheSwgSnVseSAyNSwgMjAxMiAyOjExIEFNDQpUbzogQmFzYXZhcmFqIFBhdGlsIDxiYXNh dmFyYWoucGF0aWxAbm9raWEuY29tPG1haWx0bzpiYXNhdmFyYWoucGF0aWxAbm9raWEuY29tPj4N CkNjOiBOZXRleHQgPG5ldGV4dEBpZXRmLm9yZzxtYWlsdG86bmV0ZXh0QGlldGYub3JnPj4sICJu ZXRleHQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmc+IiA8 bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPj4N ClN1YmplY3Q6IHJlOiBbbmV0ZXh0XSBDb21tZW50cyBvbiBJLUQ6IGRyYWZ0LXR1LW5ldGV4dC1t bi1zdGF0dXMtb3B0aW9uLTAyLnR4dA0KDQoNCkhpIEJhc2F2YXJhaiwNCkluIG15IHVuZGVyc3Rh bmRpbmcgdGhlIElkbGUvUG93ZXIgc2F2aW5nIG1vZGUgaW5mb3JtYXRpb24gY2FuIGJlIHJldHJp ZXZlZCBieSB0aGUgTUFHIGZyb20gc29tZSBuZXR3b3JrIGVsZW1lbnRzLCBzdWNoIGFzIFBhZ2lu ZyBjb250cm9sbGVyIGluIFdpTUFYLCBNTUUgaW4gM0dQUCBhbmQgQVAgaW4gV0xBTi4gSW4gc29t ZSBvZiB0aGUgYWNjZXNzIG5ldHdvcmtzLCB0aGUgTUFHIGlzIGV2ZW4gY29tYmluZWQgd2l0aCB0 aGVzZSBuZXR3b3JrIGVsZW1lbnRzKGUuZy4gUEMgaW4gV2lNQVgp44CCRm9yIHRoZSByYWRpbyBx dWFsaXR5IGluZm9ybWF0aW9uLCB0aGVyZSBhcmUgc29tZSBtZWNoYW5pc21lcyBoYXZlIGFscmVh ZHkgYmUgcHJvdmlkZWQgZm9yIHNvbWUgYWNjZXNzIG5ldHdvcmtzLCB0YWtlIDNHUFAgYWNjZXNz IG5ldHdvcmsgZm9yIGV4YW1wbGUsIHRoZSBlTkIgb2J0YWlucyB0aGUgcmFkaW8gcXVhbGl0eSBv ZiB0aGUgTW9iaWxlIG5vZGUgcGVyaW9kaWNhbGx5KGUuZy4gdG8gb2ZmZXIgc29tZSBsb2NhdGlv biBiYXNlIHNlcnZpY2VzICksIGFuZCB0aGVzZSBpbmZvcm1hdGlvbiBjYW4gYmUgcmV0cmlldmVk IGJ5IHRoZSBNQUcgdG8gbWFrZSB0aGUgZGVjaXNpb24gdG8gdXBkYXRlIGxvdyByYWRpbyBxdWFs aXR5IGV2ZW50IHRvIHRoZSBMTUEuDQoNCkZvciBtb2JpbGUgbm9kZSBjYXBhYmlsaXR5IGluZm9y bWF0aW9uKExJRiwgZHVhbCBJUHY0L0lQdjYgc3RhY2sgYW5kIE1JUCBzdGFjayksIHRoZXNlIGlu Zm9ybWF0aW9uIGNhbiBiZSBmb3J3YXJkZWQgZnJvbSB0aGUgTU4gdG8gdGhlIE1BRyBiZWZvcmUg dGhlIFBNSVAgc2lnbmFsbGluZyAob25lIHBvc3NpYmlsaXR5IGlzIHVzaW5nIHRoZSBFQVAgcHJv Y2VzcykuIEFuZCB0aGVuIHRoZSBNQUcgY2FuIGZvcndhcmQgdGhlc2UgaW5mb3JtYXRpb24gdG8g dGhlIExNQSB1c2luZyB0aGUgUEJVL1BCQSBtZXNzYWdlcy4NCg0KVGhhbmtzIGZvciB5b3VyIGdv b2QgY29tbWVudHMsIGFuZCBob3BlIHRoaXMgY2xhcmlmaWVzLA0KDQpCUiwNCg0KWWFuZ3dlaSBU dQ0KDQoNCg0KDQo8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbTxtYWlsdG86QmFzYXZhcmFqLlBh dGlsQG5va2lhLmNvbT4+DQrlj5Hku7bkuro6ICBuZXRleHQtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmc+DQoNCjIwMTItMDctMjQgMDE6MjMNCg0KDQrmlLbk u7bkuroNCiAgICAgICAgPG5ldGV4dEBpZXRmLm9yZzxtYWlsdG86bmV0ZXh0QGlldGYub3JnPj4N CuaKhOmAgQ0KDQrkuLvpopgNCiAgICAgICAgW25ldGV4dF0gQ29tbWVudHMgb24gSS1EOiBkcmFm dC10dS1uZXRleHQtbW4tc3RhdHVzLW9wdGlvbi0wMi50eHQNCg0KDQoNCg0KDQoNCg0KDQpIZWxs bywNCg0KVGhlIHByb3Bvc2FsIG9mIHNlbmRpbmcgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWxh dGVkIHRvIHRoZSBNTnMNCmNvbm5lY3Rpdml0eSBzdGF0ZSBpcyBubyBkb3VidCB1c2VmdWwgYW5k IGNhbiBoZWxwIHRoZSBMTUEgbWFrZSBhIG1vcmUNCmluZm9ybWVkIGRlY2lzaW9uIGFib3V0IHN3 aXRjaGluZyBmbG93cy4NCkhvd2V2ZXIgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cgdGhl IE1BRyBnZXRzIHN1Y2ggYWNjZXNzL2ludGVyZmFjZQ0Kc3BlY2lmaWMgaW5mb3JtYXRpb24uIERv IHlvdSBleHBlY3QgdGhlIGFjY2VzcyBuZXR3b3JrIHRvIHByb3ZpZGUgc3VjaA0KaW5mb3JtYXRp b24gb24gYSBwZXIgTU4gYmFzaXM/IFRoZXJlIGlzIGFuIGltcGxpY2l0IGFzc3VtcHRpb24gdGhh dCB0aGUNCk1BRyBoYXMgYWNjZXNzIHRvIHJlc291cmNlIGluZm9ybWF0aW9uIHRoYXQgaXMgbWFp bnRhaW5lZCBieSBub2RlcyBpbiB0aGUNCmFjY2VzcyBuZXR3b3JrLiBJcyB0aGF0IHRoZSBjYXNl Pw0KDQotUmFqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmc8bWFpbHRvOm5ldGV4dEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQoN Cg0K --_000_CC35B7ED21BECbasavarajpatilnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkkgYWdyZWUgdGhhdCBuZXR3b3JrIGVsZW1lbnRzIHN1Y2ggYXMgdGhlIGVOQiBo YXZlIGZhaXJseSByZWxldmFudCBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBzdGF0ZSBvZiB0 aGUgY29ubmVjdGlvbiBhc3NvY2lhdGVkIHdpdGggYW4gTU4uIEdldHRpbmcgdGhpcyBpbmZvcm1h dGlvbiBvdmVyIHRvIGEgTUFHIGlzIG5vdCBlYXNpbHkgZG9uZS4gU28gdGhlcmUgaXMgYSBsZWFw IG9mIGZhaXRoIGhlcmUuIEhvdyBkbyB5b3UgcHJvcG9zZQ0KIHRvIG9idGFpbiB0aGlzIGluZm9y bWF0aW9uIGlzIHNoYXJlZCB3aXRoIHRoZSBNQUc/Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5NTiBjYXBhYmlsaXR5IGNvdWxkIGJlIGluZGljYXRlZCBkdXJpbmcgdGhlIEVB UCBleGNoYW5nZSBhcyB5b3Ugc3VnZ2VzdGVkLiBJIHRoaW5rIFJhamVldidzIEktRCBkaXNjdXNz ZXMgc3VjaCBjYXBhYmlsaXR5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LVJhajwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1h bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtleHQgPGEgaHJlZj0ibWFpbHRv OnR1Lnlhbmd3ZWlAenRlLmNvbS5jbiI+DQp0dS55YW5nd2VpQHp0ZS5jb20uY248L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86dHUueWFuZ3dlaUB6dGUuY29tLmNuIj50dS55YW5nd2VpQHp0 ZS5jb20uY248L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+V2VkbmVzZGF5LCBKdWx5IDI1LCAyMDEyIDI6MTEgQU08YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CYXNhdmFyYWogUGF0aWwgJmx0OzxhIGhy ZWY9Im1haWx0bzpiYXNhdmFyYWoucGF0aWxAbm9raWEuY29tIj5iYXNhdmFyYWoucGF0aWxAbm9r aWEuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwv c3Bhbj5OZXRleHQgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRleHRAaWV0Zi5vcmciPm5ldGV4dEBp ZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0ZXh0LWJvdW5jZXNAaWV0 Zi5vcmciPm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnIj5uZXRleHQtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5y ZTogW25ldGV4dF0gQ29tbWVudHMgb24gSS1EOiBkcmFmdC10dS1uZXRleHQtbW4tc3RhdHVzLW9w dGlvbi0wMi50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48 YnI+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+SGkgQmFzYXZhcmFqLDwvZm9udD4gPGJy Pg0KPGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPkluIG15IHVuZGVyc3RhbmRpbmcgdGhlIElk bGUvUG93ZXIgc2F2aW5nIG1vZGUgaW5mb3JtYXRpb24gY2FuIGJlIHJldHJpZXZlZCBieSB0aGUg TUFHIGZyb20gc29tZSBuZXR3b3JrIGVsZW1lbnRzLCBzdWNoIGFzIFBhZ2luZyBjb250cm9sbGVy IGluIFdpTUFYLCBNTUUgaW4gM0dQUCBhbmQgQVAgaW4gV0xBTi4gSW4gc29tZSBvZiB0aGUgYWNj ZXNzIG5ldHdvcmtzLCB0aGUgTUFHIGlzIGV2ZW4gY29tYmluZWQNCiB3aXRoIHRoZXNlIG5ldHdv cmsgZWxlbWVudHMoZS5nLiBQQyBpbiBXaU1BWCnjgIJGb3IgdGhlIHJhZGlvIHF1YWxpdHkgaW5m b3JtYXRpb24sIHRoZXJlIGFyZSBzb21lIG1lY2hhbmlzbWVzIGhhdmUgYWxyZWFkeSBiZSBwcm92 aWRlZCBmb3Igc29tZSBhY2Nlc3MgbmV0d29ya3MsIHRha2UgM0dQUCBhY2Nlc3MgbmV0d29yayBm b3IgZXhhbXBsZSwgdGhlIGVOQiBvYnRhaW5zIHRoZSByYWRpbyBxdWFsaXR5IG9mIHRoZSBNb2Jp bGUgbm9kZSBwZXJpb2RpY2FsbHkoZS5nLg0KIHRvIG9mZmVyIHNvbWUgbG9jYXRpb24gYmFzZSBz ZXJ2aWNlcyApLCBhbmQgdGhlc2UgaW5mb3JtYXRpb24gY2FuIGJlIHJldHJpZXZlZCBieSB0aGUg TUFHIHRvIG1ha2UgdGhlIGRlY2lzaW9uIHRvIHVwZGF0ZSBsb3cgcmFkaW8gcXVhbGl0eSBldmVu dCB0byB0aGUgTE1BLjwvZm9udD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj5Gb3Ig bW9iaWxlIG5vZGUgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbihMSUYsIGR1YWwgSVB2NC9JUHY2IHN0 YWNrIGFuZCBNSVAgc3RhY2spLCB0aGVzZSBpbmZvcm1hdGlvbiBjYW4gYmUgZm9yd2FyZGVkIGZy b20gdGhlIE1OIHRvIHRoZSBNQUcgYmVmb3JlIHRoZSBQTUlQIHNpZ25hbGxpbmcgKG9uZSBwb3Nz aWJpbGl0eSBpcyB1c2luZyB0aGUgRUFQIHByb2Nlc3MpLiBBbmQgdGhlbiB0aGUgTUFHDQogY2Fu IGZvcndhcmQgdGhlc2UgaW5mb3JtYXRpb24gdG8gdGhlIExNQSB1c2luZyB0aGUgUEJVL1BCQSBt ZXNzYWdlcy48L2ZvbnQ+IDwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj5UaGFu a3MgZm9yIHlvdXIgZ29vZCBjb21tZW50cywgYW5kIGhvcGUgdGhpcyBjbGFyaWZpZXMsPC9mb250 PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj5CUiw8L2ZvbnQ+IDwvcD4NCjxw Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj5ZYW5nd2VpIFR1PC9mb250PiA8L3A+DQo8cD48 Zm9udCBzaXplPSIzIiBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mbmJzcDs8L2I+PC9mb250PiA8L3A+ DQo8cD48YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9IjEwMCUiPg0KPHRib2R5Pg0KPHRyIHZhbGln bj0idG9wIj4NCjx0ZCB3aWR0aD0iMzUlIj48Zm9udCBzaXplPSIxIiBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mbHQ7PGEgaHJlZj0ibWFpbHRvOkJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20iPkJhc2F2 YXJhai5QYXRpbEBub2tpYS5jb208L2E+Jmd0OzwvYj48L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6ZT0i MSIgZmFjZT0ic2Fucy1zZXJpZiI+5Y+R5Lu25Lq6OiAmbmJzcDs8YSBocmVmPSJtYWlsdG86bmV0 ZXh0LWJvdW5jZXNAaWV0Zi5vcmciPm5ldGV4dC1ib3VuY2VzQGlldGYub3JnPC9hPjwvZm9udD4N CjxwPjxmb250IHNpemU9IjEiIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDctMjQgMDE6MjM8L2Zv bnQ+IDwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjY0JSI+DQo8dGFibGUgd2lkdGg9IjEwMCUiPg0K PHRib2R5Pg0KPHRyIHZhbGlnbj0idG9wIj4NCjx0ZD4NCjxkaXYgYWxpZ249InJpZ2h0Ij48Zm9u dCBzaXplPSIxIiBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8L3Rk Pg0KPHRkPjxmb250IHNpemU9IjEiIGZhY2U9InNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWls dG86bmV0ZXh0QGlldGYub3JnIj5uZXRleHRAaWV0Zi5vcmc8L2E+Jmd0OzwvZm9udD4NCjwvdGQ+ DQo8L3RyPg0KPHRyIHZhbGlnbj0idG9wIj4NCjx0ZD4NCjxkaXYgYWxpZ249InJpZ2h0Ij48Zm9u dCBzaXplPSIxIiBmYWNlPSJzYW5zLXNlcmlmIj7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8L3RkPg0K PHRkPjwvdGQ+DQo8L3RyPg0KPHRyIHZhbGlnbj0idG9wIj4NCjx0ZD4NCjxkaXYgYWxpZ249InJp Z2h0Ij48Zm9udCBzaXplPSIxIiBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+ DQo8L3RkPg0KPHRkPjxmb250IHNpemU9IjEiIGZhY2U9InNhbnMtc2VyaWYiPltuZXRleHRdIENv bW1lbnRzIG9uIEktRDogZHJhZnQtdHUtbmV0ZXh0LW1uLXN0YXR1cy1vcHRpb24tMDIudHh0PC9m b250PjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dGJv ZHk+DQo8dHIgdmFsaWduPSJ0b3AiPg0KPHRkPjwvdGQ+DQo8dGQ+PC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxicj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+PGJyPg0KSGVsbG8sPGJyPg0KPGJy Pg0KVGhlIHByb3Bvc2FsIG9mIHNlbmRpbmcgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWxhdGVk IHRvIHRoZSBNTnM8YnI+DQpjb25uZWN0aXZpdHkgc3RhdGUgaXMgbm8gZG91YnQgdXNlZnVsIGFu ZCBjYW4gaGVscCB0aGUgTE1BIG1ha2UgYSBtb3JlPGJyPg0KaW5mb3JtZWQgZGVjaXNpb24gYWJv dXQgc3dpdGNoaW5nIGZsb3dzLjxicj4NCkhvd2V2ZXIgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFu ZCBob3cgdGhlIE1BRyBnZXRzIHN1Y2ggYWNjZXNzL2ludGVyZmFjZTxicj4NCnNwZWNpZmljIGlu Zm9ybWF0aW9uLiBEbyB5b3UgZXhwZWN0IHRoZSBhY2Nlc3MgbmV0d29yayB0byBwcm92aWRlIHN1 Y2g8YnI+DQppbmZvcm1hdGlvbiBvbiBhIHBlciBNTiBiYXNpcz8gVGhlcmUgaXMgYW4gaW1wbGlj aXQgYXNzdW1wdGlvbiB0aGF0IHRoZTxicj4NCk1BRyBoYXMgYWNjZXNzIHRvIHJlc291cmNlIGlu Zm9ybWF0aW9uIHRoYXQgaXMgbWFpbnRhaW5lZCBieSBub2RlcyBpbiB0aGU8YnI+DQphY2Nlc3Mg bmV0d29yay4gSXMgdGhhdCB0aGUgY2FzZT88YnI+DQo8YnI+DQotUmFqIDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0ZXh0 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRleHRAaWV0Zi5vcmciPm5ldGV4 dEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGV4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRleHQ8L2E+PGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+PGJyPg0KPC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CC35B7ED21BECbasavarajpatilnokiacom_-- From Basavaraj.Patil@nokia.com Wed Jul 25 14:32:09 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 A443111E8093; Wed, 25 Jul 2012 14:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fi5IXqrlE9dV; Wed, 25 Jul 2012 14:32:08 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A832811E808D; Wed, 25 Jul 2012 14:32:08 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PLVs5F013046; Thu, 26 Jul 2012 00:32:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 00:32:38 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Wed, 25 Jul 2012 23:31:57 +0200 From: To: Thread-Topic: Request for updating the Netext WG Milestones Thread-Index: AQHNaqzqubqSpknQAECF+VsvRi7nZw== Date: Wed, 25 Jul 2012 21:31:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.98] Content-Type: multipart/alternative; boundary="_000_CC35CFF921CAAbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jul 2012 21:32:38.0184 (UTC) FILETIME=[035BB280:01CD6AAD] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: [netext] Request for updating the Netext WG Milestones 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, 25 Jul 2012 21:32:09 -0000 --_000_CC35CFF921CAAbasavarajpatilnokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The Netext WG milestones currently listed on the WG charter page are obsole= te. Many of them have been completed while at least one of them dropped. I would like to request the milestones to be updated as per the list below. -Basavaraj As of: July 25, 2012: Goals and Milestones Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Done Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Done Submit LMA Redirection to IESG for publication as a Proposed Standard = RFC Done Initial WG document on RADIUS extensions to PMIP6 Done Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC Done Initial WG draft on Localized Routing Solution Done Submit Access Network Identifier (ANI) Option for PMIP6 to IESG for publication as a proposed standard Apr 2012 Initial WG document on Service Selection for MIP6 and PMIP6 Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration Oct 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard --_000_CC35CFF921CAAbasavarajpatilnokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0B125E1D13C2744AB589E8B91B25A66E@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hello,

The Netext WG milestones currently listed on the WG charter page are o= bsolete. Many of them have been completed while at least one of them droppe= d. 

I would like to request the milestones to be updated as per the list b= elow.

-Basavaraj


As of: July 25, 2012:

Goals and Milestones

Done W= G chartered
Done I= nitial WG draft on Bulk Refresh
Done D= ecision on the inclusion of possible additional work items
Done I= nitial WG draft on LMA Redirection
Done I= nitial WG draft on Localized Routing Problem Statement
Done S= ubmit Bulk Refresh to IESG for publication as a Proposed Standard RFC
Done S= ubmit LMA Redirection to IESG for publication as a Proposed Standard RFC
Done I= nitial WG document on RADIUS extensions to PMIP6
Done S= ubmit Localized Routing Problem Statement to IESG for
    publication as an Informational RFC 
Done I= nitial WG draft on Localized Routing Solution
Done S= ubmit Access Network Identifier (ANI) Option for
    PMIP6 to IESG for publication as a proposed standard

Apr 2012 Initial WG document on Service Selection for MIP6 and
    PMIP6
Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration
Oct 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG
    for publication as a proposed standard
Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy
    Mobile IPv6 to IESG for publication as a proposed
    standard
Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow
    Mobility to IESG for publication as a proposed
    standard
Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the
    IESG for publication as a proposed standard
Apr 2013 Submit Logical Interface Support for multi-mode IP
    Hosts for publication as an Informational document
May 2013 Submit EAP Attributes for WiFi - EPC Integration to
    IESG for publication as a proposed standard






--_000_CC35CFF921CAAbasavarajpatilnokiacom_-- From Basavaraj.Patil@nokia.com Wed Jul 25 14:40:58 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 E5BAD21F84B3 for ; Wed, 25 Jul 2012 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 en5TkB+C3O0o for ; Wed, 25 Jul 2012 14:40:58 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 39E8821F84AF for ; Wed, 25 Jul 2012 14:40:57 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PLep1s008558; Thu, 26 Jul 2012 00:40:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 00:41:31 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Wed, 25 Jul 2012 23:40:50 +0200 From: To: Thread-Topic: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions Thread-Index: AQHNaPYpTX/0CSvGiU6Gu/2cDgKw+pc3KQqAgALsAQA= Date: Wed, 25 Jul 2012 21:40:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.98] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jul 2012 21:41:31.0716 (UTC) FILETIME=[415E3840:01CD6AAE] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions 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, 25 Jul 2012 21:40:59 -0000 Hi Behcet, On 7/23/12 3:03 PM, "ext Behcet Sarikaya" wrote: >Hi Basavaraj, > >On Mon, Jul 23, 2012 at 12:11 PM, wrote: >> >> A few comments: >> >> 1. I am not convinced with the problem statement specified in the I-D. >>The >> WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended to >> provide a solution that is similar (albeit without UE interaction) to >>what >> exists for MIP6. >> >> 2. If the UE is assigned different HNPs to its interfaces as a result of >> connecting via more than one interface, the current assumption is that >> there is no switching of flows between those interfaces. The only case >> where we enable flow mobility is when the UE has a single HNP assigned >>to >> it but connected via multiple interfaces (possible via the use of >> logical-interface at the UE). >> >> 3. The I-D does not explain how flow switching would work if the MN has >> different HNPs assigned to its interfaces.The extensions to PMIP6 >> signaling with the new flags to support flow mobility can wait until you >> have a clear explanation for the same. > >The problem that my I-D addresses is better explained in (from 3rd >paragraph of Section 3, a little bit annotated): > >In base Proxy Mobile IPv6, i.e. RFC 5213, LMA treats each interface >independently of > the other interface(s) MN may have and tries to provide mobility > support for each interface. LMA does not manage bindings from > different interfaces of the mobile node in an integrated fashion. So > LMA can not be in control of moving the flows in between interfaces. > >So a binding cache management similar to RFC 5648, i.e. the MCoA work >in MIPv6 is needed and this is what my I-D comes up with. I get that.. But my point is this is not needed in the context of flow mobility for PMIP6. > >Reading Carlos' I-D, version 04, he comes close to it, but specific >modifications to the binding cache are not spelled out and they should >be using draft-sarikaya-netext-fb-support-extensions-02 or >draft-sarikaya-netext-fb-support-extensions-02 should be normative >reference. I don=B9t see a shortcoming in the WG I-D in terms of solving the problem o= f flow switching. Please elaborate what you see as an issue and a scenario that you believe cannot be achieved as per the current WG I-D. -Raj > >Hope this clarifies. > >Behcet From pierrick.seite@orange.com Thu Jul 26 00:35:54 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 997C921F869F for ; Thu, 26 Jul 2012 00:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 XhfJgbqrMasA for ; Thu, 26 Jul 2012 00:35:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2680121F869C for ; Thu, 26 Jul 2012 00:35:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3FD4E22C346; Thu, 26 Jul 2012 09:35:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2188127C046; Thu, 26 Jul 2012 09:35:46 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 09:35:45 +0200 From: To: "'Basavaraj.Patil@nokia.com'" Thread-Topic: Request for updating the Netext WG Milestones Thread-Index: AQHNaqzqubqSpknQAECF+VsvRi7nZ5c7K1mA Date: Thu, 26 Jul 2012 07:35:45 +0000 Message-ID: <1912_1343288146_5010F352_1912_5096_1_81C77F07008CA24F9783A98CFD706F7102CAB8@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F7102CAB8PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Cc: "netext@ietf.org" Subject: Re: [netext] Request for updating the Netext WG Milestones 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, 26 Jul 2012 07:35:54 -0000 --_000_81C77F07008CA24F9783A98CFD706F7102CAB8PEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Raj, Shouldn't we also include milestones for "Quality of Service Option for Pro= xy Mobile IPv6"? Pierrick De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de= Basavaraj.Patil@nokia.com Envoy=E9 : mercredi 25 juillet 2012 23:32 =C0 : iesg-secretary@ietf.org Cc : netext@ietf.org Objet : [netext] Request for updating the Netext WG Milestones Hello, The Netext WG milestones currently listed on the WG charter page are obsole= te. Many of them have been completed while at least one of them dropped. I would like to request the milestones to be updated as per the list below. -Basavaraj As of: July 25, 2012: Goals and Milestones Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Done Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Done Submit LMA Redirection to IESG for publication as a Proposed Standard = RFC Done Initial WG document on RADIUS extensions to PMIP6 Done Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC Done Initial WG draft on Localized Routing Solution Done Submit Access Network Identifier (ANI) Option for PMIP6 to IESG for publication as a proposed standard Apr 2012 Initial WG document on Service Selection for MIP6 and PMIP6 Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration Oct 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F7102CAB8PEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Raj,

 

Shouldn’t we also include= milestones for “Quality of Service Option for Proxy Mobile IPv6̶= 1;?

 

Pierrick

 = ;

De : nete= xt-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Basavaraj.Patil@nokia.com
Envoy=E9 : mercredi 25 juillet 2012 23:32
=C0 : iesg-secretary@ietf.org
Cc : netext@ietf.org
Objet : [netext] Request for updating the Netext WG Milestones<= o:p>

 

 

Hello,

 

The Netext WG milestones cu= rrently listed on the WG charter page are obsolete. Many of them have been = completed while at least one of them dropped. 

 

I would like to request the= milestones to be updated as per the list below.

 

-Basavaraj

 

 

As of: July 25, 2012:<= /o:p>

 

Goals and Milestones

 

Done WG chartered

Done Initial WG draft on Bulk Refresh

Done Decision on the inclusion of possible additional work items

Done Initial WG draft on LMA Redirection

Done Initial WG draft on Localized Routing Problem Statement

Done Submit Bulk Refresh to IESG for publication as a Proposed Standard R= FC

Done Submit LMA Redirection to IESG for publication as a Proposed Standar= d RFC

Done Initial WG document on RADIUS extensions to PMIP6<= /p>

Done Submit Localized Routing Problem Statement to IESG for

    publication a= s an Informational RFC 

Done Initial WG draft on Localized Routing Solution

Done Submit Access Network = Identifier (ANI) Option for

    PMIP6 to IESG= for publication as a proposed standard

 

Apr 2012 Initial WG documen= t on Service Selection for MIP6 and

    PMIP6

Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration

Oct 2012 Submit Prefix Dele= gation for Proxy Mobile IPv6 to IESG

    for publicati= on as a proposed standard

Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy

    Mobile IPv6 t= o IESG for publication as a proposed

    standard=

Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow

    Mobility to I= ESG for publication as a proposed

    standard=

Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the=

    IESG for publ= ication as a proposed standard

Apr 2013 Submit Logical Interface Support for multi-mode IP=

    Hosts for pub= lication as an Informational document

May 2013 Submit EAP Attributes for WiFi - EPC Integration to

    IESG for publ= ication as a proposed standard

 

 

 

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F7102CAB8PEXCVZYM12corpora_-- From Basavaraj.Patil@nokia.com Thu Jul 26 08:20:47 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 3272B21F86AD for ; Thu, 26 Jul 2012 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 WYP4AAwCuLAR for ; Thu, 26 Jul 2012 08:20:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 18B8C21F86AA for ; Thu, 26 Jul 2012 08:20:44 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QFKeq2017526 for ; Thu, 26 Jul 2012 18:20:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 18:21:21 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Thu, 26 Jul 2012 17:20:33 +0200 From: To: Thread-Topic: Slides from presenters allotted slots at IETF84 WG meeting due by Monday Thread-Index: AQHNa0IyJJWcPbB6tEeWYFuyJQc2hQ== Date: Thu, 26 Jul 2012 15:20:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [72.64.105.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <214058274BEF4145BBE6F7F302602888@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2012 15:21:22.0128 (UTC) FILETIME=[50350D00:01CD6B42] X-Nokia-AV: Clean Subject: [netext] Slides from presenters allotted slots at IETF84 WG meeting due by Monday 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, 26 Jul 2012 15:20:47 -0000 Hello, If you are on the agenda of the Netext WG meeting at IETF84, please send us the slides (netext-chairs@tools.ietf.org) by Monday evening 7 PM (PST). -Chairs From sarikaya2012@gmail.com Thu Jul 26 12:06:53 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 B39F921F861C for ; Thu, 26 Jul 2012 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 w9vjEqxyIrrU for ; Thu, 26 Jul 2012 12:06:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1B21F85F1 for ; Thu, 26 Jul 2012 12:06:50 -0700 (PDT) Received: by yhq56 with SMTP id 56so2575267yhq.31 for ; Thu, 26 Jul 2012 12:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=n+CS7LL6XEkaI0xyKPIDwRAwqTAeqU+CaucTEQ7e3SA=; b=iVC916EshJCzDHDudbw9agPZIjy4qcDIdA+rWFiVXeqYAgZNfhArLiAd/w2QWeljl1 uy/gElsZ+DZp20v5vQwtZwn6eeNaI7nXvf7o+0ZdnyUp8QNnzLFmWCT1zrdral5y8H+a /B8XBsjNpCkyu7S/Yia4rx+jyReKgIaH9QPBtQ7Xp5BSJksO9g9ngjSF7gz0LmY9fNU4 SGq7BMmDKjq+L2pLAIRfBtmnziOqtE4wzdV3VzlwE+LFJg+BjEa2ePtNyTJTCOFRiX2G v6Na5+tLSfierWRKhxQbCLXhOFtgCo3WBYI4hBTbqHH/RV8uArcaOwZ/7M90db4iuYlH 2GLw== MIME-Version: 1.0 Received: by 10.50.17.230 with SMTP id r6mr2612279igd.63.1343329609996; Thu, 26 Jul 2012 12:06:49 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Thu, 26 Jul 2012 12:06:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jul 2012 14:06:49 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 19:06:53 -0000 Hi Basavaraj, On Wed, Jul 25, 2012 at 4:40 PM, wrote: > > Hi Behcet, > > On 7/23/12 3:03 PM, "ext Behcet Sarikaya" wrote: > >>Hi Basavaraj, >> >>On Mon, Jul 23, 2012 at 12:11 PM, wrote: >>> >>> A few comments: >>> >>> 1. I am not convinced with the problem statement specified in the I-D. >>>The >>> WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended to >>> provide a solution that is similar (albeit without UE interaction) to >>>what >>> exists for MIP6. >>> >>> 2. If the UE is assigned different HNPs to its interfaces as a result o= f >>> connecting via more than one interface, the current assumption is that >>> there is no switching of flows between those interfaces. The only case >>> where we enable flow mobility is when the UE has a single HNP assigned >>>to >>> it but connected via multiple interfaces (possible via the use of >>> logical-interface at the UE). >>> >>> 3. The I-D does not explain how flow switching would work if the MN has >>> different HNPs assigned to its interfaces.The extensions to PMIP6 >>> signaling with the new flags to support flow mobility can wait until yo= u >>> have a clear explanation for the same. >> >>The problem that my I-D addresses is better explained in (from 3rd >>paragraph of Section 3, a little bit annotated): >> >>In base Proxy Mobile IPv6, i.e. RFC 5213, LMA treats each interface >>independently of >> the other interface(s) MN may have and tries to provide mobility >> support for each interface. LMA does not manage bindings from >> different interfaces of the mobile node in an integrated fashion. So >> LMA can not be in control of moving the flows in between interfaces. >> >>So a binding cache management similar to RFC 5648, i.e. the MCoA work >>in MIPv6 is needed and this is what my I-D comes up with. > > I get that.. But my point is this is not needed in the context of flow > mobility for PMIP6. > >> >>Reading Carlos' I-D, version 04, he comes close to it, but specific >>modifications to the binding cache are not spelled out and they should >>be using draft-sarikaya-netext-fb-support-extensions-02 or >>draft-sarikaya-netext-fb-support-extensions-02 should be normative >>reference. > > I don=B9t see a shortcoming in the WG I-D in terms of solving the problem= of > flow switching. > Please elaborate what you see as an issue and a scenario that you believe > cannot be achieved as per the current WG I-D. This is from RFC 5213, Sec. 5.4 on multihoming support: When a mobile node connects to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access, the local mobility anchor MUST allocate a mobility session for each of the attached interfaces. Each mobility session should be managed under a separate Binding Cache entry and with its own lifetime. This is the problem. Without modifying the way mobility sessions are handled it is impossible to do any flow mobility among multiple interfaces. draft-sarikaya-netext-fb-support-extensions-02 offers a solution and to my knowledge the only solution to this problem. Maybe I should explain the problem better in the next version of my draft. In fact some implementers contacted me offline and then said the first thing they did was to implement draft-sarikaya-netext-fb-support-extensions-02 and then draft-ietf-netext-pmipv6-flowmob. I hope this clarifies and nevertheless, thanks for your comments. Regards, Behcet From Basavaraj.Patil@nokia.com Fri Jul 27 10:08: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 966DF21F877B for ; Fri, 27 Jul 2012 10:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.705 X-Spam-Level: X-Spam-Status: No, score=-105.705 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 ucsUKPOA46dm for ; Fri, 27 Jul 2012 10:08:15 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C739321F8691 for ; Fri, 27 Jul 2012 10:08:13 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6RH87ga011034; Fri, 27 Jul 2012 20:08:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 20:08:49 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0283.004; Fri, 27 Jul 2012 19:08:05 +0200 From: To: Thread-Topic: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions Thread-Index: AQHNaPYpTX/0CSvGiU6Gu/2cDgKw+pc3KQqAgALsAQCAAbsfgIABHVSA Date: Fri, 27 Jul 2012 17:08:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.87] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2012 17:08:49.0918 (UTC) FILETIME=[7DCD79E0:01CD6C1A] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 17:08:15 -0000 SW5saW5lOiANCg0KT24gNy8yNi8xMiAyOjA2IFBNLCAiZXh0IEJlaGNldCBTYXJpa2F5YSIgPHNh cmlrYXlhMjAxMkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+SGkgQmFzYXZhcmFqLA0KPg0KPk9uIFdl ZCwgSnVsIDI1LCAyMDEyIGF0IDQ6NDAgUE0sICA8QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbT4g d3JvdGU6DQo+Pg0KPj4gSGkgQmVoY2V0LA0KPj4NCj4+IE9uIDcvMjMvMTIgMzowMyBQTSwgImV4 dCBCZWhjZXQgU2FyaWtheWEiIDxzYXJpa2F5YTIwMTJAZ21haWwuY29tPg0KPj53cm90ZToNCj4+ DQo+Pj5IaSBCYXNhdmFyYWosDQo+Pj4NCj4+Pk9uIE1vbiwgSnVsIDIzLCAyMDEyIGF0IDEyOjEx IFBNLCAgPEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBBIGZl dyBjb21tZW50czoNCj4+Pj4NCj4+Pj4gMS4gSSBhbSBub3QgY29udmluY2VkIHdpdGggdGhlIHBy b2JsZW0gc3RhdGVtZW50IHNwZWNpZmllZCBpbiB0aGUgSS1ELg0KPj4+PlRoZQ0KPj4+PiBXRyBm bG93LW1vYmlsaXR5IEktRCAoZHJhZnQtaWV0Zi1uZXRleHQtcG1pcHY2LWZsb3dtb2IpIGlzIGlu dGVuZGVkIHRvDQo+Pj4+IHByb3ZpZGUgYSBzb2x1dGlvbiB0aGF0IGlzIHNpbWlsYXIgKGFsYmVp dCB3aXRob3V0IFVFIGludGVyYWN0aW9uKSB0bw0KPj4+PndoYXQNCj4+Pj4gZXhpc3RzIGZvciBN SVA2Lg0KPj4+Pg0KPj4+PiAyLiBJZiB0aGUgVUUgaXMgYXNzaWduZWQgZGlmZmVyZW50IEhOUHMg dG8gaXRzIGludGVyZmFjZXMgYXMgYSByZXN1bHQNCj4+Pj5vZg0KPj4+PiBjb25uZWN0aW5nIHZp YSBtb3JlIHRoYW4gb25lIGludGVyZmFjZSwgdGhlIGN1cnJlbnQgYXNzdW1wdGlvbiBpcyB0aGF0 DQo+Pj4+IHRoZXJlIGlzIG5vIHN3aXRjaGluZyBvZiBmbG93cyBiZXR3ZWVuIHRob3NlIGludGVy ZmFjZXMuIFRoZSBvbmx5IGNhc2UNCj4+Pj4gd2hlcmUgd2UgZW5hYmxlIGZsb3cgbW9iaWxpdHkg aXMgd2hlbiB0aGUgVUUgaGFzIGEgc2luZ2xlIEhOUCBhc3NpZ25lZA0KPj4+PnRvDQo+Pj4+IGl0 IGJ1dCBjb25uZWN0ZWQgdmlhIG11bHRpcGxlIGludGVyZmFjZXMgKHBvc3NpYmxlIHZpYSB0aGUg dXNlIG9mDQo+Pj4+IGxvZ2ljYWwtaW50ZXJmYWNlIGF0IHRoZSBVRSkuDQo+Pj4+DQo+Pj4+IDMu IFRoZSBJLUQgZG9lcyBub3QgZXhwbGFpbiBob3cgZmxvdyBzd2l0Y2hpbmcgd291bGQgd29yayBp ZiB0aGUgTU4NCj4+Pj5oYXMNCj4+Pj4gZGlmZmVyZW50IEhOUHMgYXNzaWduZWQgdG8gaXRzIGlu dGVyZmFjZXMuVGhlIGV4dGVuc2lvbnMgdG8gUE1JUDYNCj4+Pj4gc2lnbmFsaW5nIHdpdGggdGhl IG5ldyBmbGFncyB0byBzdXBwb3J0IGZsb3cgbW9iaWxpdHkgY2FuIHdhaXQgdW50aWwNCj4+Pj55 b3UNCj4+Pj4gaGF2ZSBhIGNsZWFyIGV4cGxhbmF0aW9uIGZvciB0aGUgc2FtZS4NCj4+Pg0KPj4+ VGhlIHByb2JsZW0gdGhhdCBteSBJLUQgYWRkcmVzc2VzIGlzIGJldHRlciBleHBsYWluZWQgaW4g KGZyb20gM3JkDQo+Pj5wYXJhZ3JhcGggb2YgU2VjdGlvbiAzLCBhIGxpdHRsZSBiaXQgYW5ub3Rh dGVkKToNCj4+Pg0KPj4+SW4gYmFzZSBQcm94eSBNb2JpbGUgSVB2NiwgaS5lLiBSRkMgNTIxMywg TE1BIHRyZWF0cyBlYWNoIGludGVyZmFjZQ0KPj4+aW5kZXBlbmRlbnRseSBvZg0KPj4+ICAgdGhl IG90aGVyIGludGVyZmFjZShzKSBNTiBtYXkgaGF2ZSBhbmQgdHJpZXMgdG8gcHJvdmlkZSBtb2Jp bGl0eQ0KPj4+ICAgc3VwcG9ydCBmb3IgZWFjaCBpbnRlcmZhY2UuICBMTUEgZG9lcyBub3QgbWFu YWdlIGJpbmRpbmdzIGZyb20NCj4+PiAgIGRpZmZlcmVudCBpbnRlcmZhY2VzIG9mIHRoZSBtb2Jp bGUgbm9kZSBpbiBhbiBpbnRlZ3JhdGVkIGZhc2hpb24uICBTbw0KPj4+ICAgTE1BIGNhbiBub3Qg YmUgaW4gY29udHJvbCBvZiBtb3ZpbmcgdGhlIGZsb3dzIGluIGJldHdlZW4gaW50ZXJmYWNlcy4N Cj4+Pg0KPj4+U28gYSBiaW5kaW5nIGNhY2hlIG1hbmFnZW1lbnQgc2ltaWxhciB0byBSRkMgNTY0 OCwgaS5lLiB0aGUgTUNvQSB3b3JrDQo+Pj5pbiBNSVB2NiBpcyBuZWVkZWQgYW5kIHRoaXMgaXMg d2hhdCBteSBJLUQgY29tZXMgdXAgd2l0aC4NCj4+DQo+PiBJIGdldCB0aGF0Li4gQnV0IG15IHBv aW50IGlzIHRoaXMgaXMgbm90IG5lZWRlZCBpbiB0aGUgY29udGV4dCBvZiBmbG93DQo+PiBtb2Jp bGl0eSBmb3IgUE1JUDYuDQo+Pg0KPj4+DQo+Pj5SZWFkaW5nIENhcmxvcycgSS1ELCB2ZXJzaW9u IDA0LCBoZSBjb21lcyBjbG9zZSB0byBpdCwgYnV0IHNwZWNpZmljDQo+Pj5tb2RpZmljYXRpb25z IHRvIHRoZSBiaW5kaW5nIGNhY2hlIGFyZSBub3Qgc3BlbGxlZCBvdXQgYW5kIHRoZXkgc2hvdWxk DQo+Pj5iZSB1c2luZyBkcmFmdC1zYXJpa2F5YS1uZXRleHQtZmItc3VwcG9ydC1leHRlbnNpb25z LTAyIG9yDQo+Pj5kcmFmdC1zYXJpa2F5YS1uZXRleHQtZmItc3VwcG9ydC1leHRlbnNpb25zLTAy IHNob3VsZCBiZSBub3JtYXRpdmUNCj4+PnJlZmVyZW5jZS4NCj4+DQo+PiBJIGRvbqn2dCBzZWUg YSBzaG9ydGNvbWluZyBpbiB0aGUgV0cgSS1EIGluIHRlcm1zIG9mIHNvbHZpbmcgdGhlIHByb2Js ZW0NCj4+b2YNCj4+IGZsb3cgc3dpdGNoaW5nLg0KPj4gUGxlYXNlIGVsYWJvcmF0ZSB3aGF0IHlv dSBzZWUgYXMgYW4gaXNzdWUgYW5kIGEgc2NlbmFyaW8gdGhhdCB5b3UNCj4+YmVsaWV2ZQ0KPj4g Y2Fubm90IGJlIGFjaGlldmVkIGFzIHBlciB0aGUgY3VycmVudCBXRyBJLUQuDQo+DQo+VGhpcyBp cyBmcm9tIFJGQyA1MjEzLCBTZWMuIDUuNCBvbiBtdWx0aWhvbWluZyBzdXBwb3J0Og0KPg0KPldo ZW4gYSBtb2JpbGUgbm9kZSBjb25uZWN0cyB0byBhIFByb3h5IE1vYmlsZSBJUHY2IGRvbWFpbiB0 aHJvdWdoDQo+ICAgICAgbXVsdGlwbGUgaW50ZXJmYWNlcyBmb3Igc2ltdWx0YW5lb3VzIGFjY2Vz cywgdGhlIGxvY2FsIG1vYmlsaXR5DQo+ICAgICAgYW5jaG9yIE1VU1QgYWxsb2NhdGUgYSBtb2Jp bGl0eSBzZXNzaW9uIGZvciBlYWNoIG9mIHRoZSBhdHRhY2hlZA0KPiAgICAgIGludGVyZmFjZXMu ICBFYWNoIG1vYmlsaXR5IHNlc3Npb24gc2hvdWxkIGJlIG1hbmFnZWQgdW5kZXIgYQ0KPiAgICAg IHNlcGFyYXRlIEJpbmRpbmcgQ2FjaGUgZW50cnkgYW5kIHdpdGggaXRzIG93biBsaWZldGltZS4N Cg0KWW91IGtlZXAgdG9zc2luZyB0aGVzZSBzbmlwcGV0cyBvZiB0ZXh0IGFuZCByZWZlcmVuY2Vz IGFuZCBob3BpbmcgdGhhdCBpdA0KZXhwbGFpbnMgdGhlIHF1ZXN0aW9uLiBJdCBkb2VzIG5vdC4N Cg0KPg0KPg0KPlRoaXMgaXMgdGhlIHByb2JsZW0uIFdpdGhvdXQgbW9kaWZ5aW5nIHRoZSB3YXkg bW9iaWxpdHkgc2Vzc2lvbnMgYXJlDQo+aGFuZGxlZCBpdCBpcyBpbXBvc3NpYmxlIHRvIGRvIGFu eSBmbG93IG1vYmlsaXR5IGFtb25nIG11bHRpcGxlDQo+aW50ZXJmYWNlcy4NCg0KDQpJIGRpc2Fn cmVlLiBJZiB5b3UgbG9vayBhdCBTY2VuYXJpbyAyIGluIFNlYyAzLjIuMiBvZiB0aGUgV0cgSS1E DQooZHJhZnQtaWV0Zi1uZXRleHQtcG1pcHY2LWZsb3dtb2ItMDQudHh0KSwgeW91IHdpbGwgc2Vl IHRoZSBiaW5kaW5nIGNhY2hlDQpkZXRhaWxzLiANCkhlbmNlIEkgZG8gbm90IHNlZSB3aGF0IHNw ZWNpZmljIHByb2JsZW0geW91ciBJLUQgaXMgc29sdmluZy4NCg0KLVJhag0KDQoNCj4NCj5kcmFm dC1zYXJpa2F5YS1uZXRleHQtZmItc3VwcG9ydC1leHRlbnNpb25zLTAyIG9mZmVycyBhIHNvbHV0 aW9uIGFuZA0KPnRvIG15IGtub3dsZWRnZSB0aGUgb25seSBzb2x1dGlvbiB0byB0aGlzIHByb2Js ZW0uDQo+DQo+TWF5YmUgSSBzaG91bGQgZXhwbGFpbiB0aGUgcHJvYmxlbSBiZXR0ZXIgaW4gdGhl IG5leHQgdmVyc2lvbiBvZiBteSBkcmFmdC4NCg0KSSB3b3VsZCBwcmVmZXIgdGhhdCB5b3UgZXhw bGFpbiB0aGUgcHJvYmxlbSBvbiB0aGUgTUwgZmlyc3QuDQoNCi1SYWoNCg0KPg0KPkluIGZhY3Qg c29tZSBpbXBsZW1lbnRlcnMgY29udGFjdGVkIG1lIG9mZmxpbmUgYW5kIHRoZW4gc2FpZCB0aGUg Zmlyc3QNCj50aGluZyB0aGV5IGRpZCB3YXMgdG8gaW1wbGVtZW50DQo+ZHJhZnQtc2FyaWtheWEt bmV0ZXh0LWZiLXN1cHBvcnQtZXh0ZW5zaW9ucy0wMiBhbmQgdGhlbg0KPmRyYWZ0LWlldGYtbmV0 ZXh0LXBtaXB2Ni1mbG93bW9iLg0KPkkgaG9wZSB0aGlzIGNsYXJpZmllcyBhbmQgbmV2ZXJ0aGVs ZXNzLCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+DQo+UmVnYXJkcywNCj4NCj5CZWhjZXQN Cg0K From sarikaya2012@gmail.com Fri Jul 27 11:35:54 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 9E93C21F8615 for ; Fri, 27 Jul 2012 11:35:54 -0700 (PDT) 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 xXSACjd-TE6u for ; Fri, 27 Jul 2012 11:35:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 253AF21F860D for ; Fri, 27 Jul 2012 11:35:53 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5274259obb.31 for ; Fri, 27 Jul 2012 11:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=toSuxbsvb7RdhmqfzOLgJSSJ5EnfjvT082FgbJGWy5c=; b=A227zaaFg0FWEaB70Lo2+pZWulaQFFuygE3urS1sh/jN5MG3Zl+kSVBc/PaOETM1in rqGiP93oI8fkeowvw9RuayQdjvJOSyL86P/BqMn9dMLVx2PSpuLuAQrJ2RVYh0bC0ai6 0ujbbEtjrUXA3eMXu3kJYqMAd2/GiAINmZqT2QErKCPOXEzxqk1W/ghNKDf5ob5UsAXa 7RoFhGbX7Ig1fnkHBIaiKtz+Qo84I35zc/UzZZt6mYQ8J3cjBo+lVPfYS+iI24pN3BfM UPk7n9DeOPv6KDm8fzs5IraBEovj2ce9q8KPqxdXkTdgZGrh12OMJS6tjAMTscFlOg/P KsaA== MIME-Version: 1.0 Received: by 10.60.8.35 with SMTP id o3mr4802135oea.39.1343414152055; Fri, 27 Jul 2012 11:35:52 -0700 (PDT) Received: by 10.60.37.197 with HTTP; Fri, 27 Jul 2012 11:35:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 13:35:51 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:35:54 -0000 Hi Basavaraj, Please see inline. On Fri, Jul 27, 2012 at 12:08 PM, wrote: > Inline: > > On 7/26/12 2:06 PM, "ext Behcet Sarikaya" wrote: > >>Hi Basavaraj, >> >>On Wed, Jul 25, 2012 at 4:40 PM, wrote: >>> >>> Hi Behcet, >>> >>> On 7/23/12 3:03 PM, "ext Behcet Sarikaya" >>>wrote: >>> >>>>Hi Basavaraj, >>>> >>>>On Mon, Jul 23, 2012 at 12:11 PM, wrote: >>>>> >>>>> A few comments: >>>>> >>>>> 1. I am not convinced with the problem statement specified in the I-D= . >>>>>The >>>>> WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended t= o >>>>> provide a solution that is similar (albeit without UE interaction) to >>>>>what >>>>> exists for MIP6. >>>>> >>>>> 2. If the UE is assigned different HNPs to its interfaces as a result >>>>>of >>>>> connecting via more than one interface, the current assumption is tha= t >>>>> there is no switching of flows between those interfaces. The only cas= e >>>>> where we enable flow mobility is when the UE has a single HNP assigne= d >>>>>to >>>>> it but connected via multiple interfaces (possible via the use of >>>>> logical-interface at the UE). >>>>> >>>>> 3. The I-D does not explain how flow switching would work if the MN >>>>>has >>>>> different HNPs assigned to its interfaces.The extensions to PMIP6 >>>>> signaling with the new flags to support flow mobility can wait until >>>>>you >>>>> have a clear explanation for the same. >>>> >>>>The problem that my I-D addresses is better explained in (from 3rd >>>>paragraph of Section 3, a little bit annotated): >>>> >>>>In base Proxy Mobile IPv6, i.e. RFC 5213, LMA treats each interface >>>>independently of >>>> the other interface(s) MN may have and tries to provide mobility >>>> support for each interface. LMA does not manage bindings from >>>> different interfaces of the mobile node in an integrated fashion. S= o >>>> LMA can not be in control of moving the flows in between interfaces. >>>> >>>>So a binding cache management similar to RFC 5648, i.e. the MCoA work >>>>in MIPv6 is needed and this is what my I-D comes up with. >>> >>> I get that.. But my point is this is not needed in the context of flow >>> mobility for PMIP6. >>> >>>> >>>>Reading Carlos' I-D, version 04, he comes close to it, but specific >>>>modifications to the binding cache are not spelled out and they should >>>>be using draft-sarikaya-netext-fb-support-extensions-02 or >>>>draft-sarikaya-netext-fb-support-extensions-02 should be normative >>>>reference. >>> >>> I don=B9t see a shortcoming in the WG I-D in terms of solving the probl= em >>>of >>> flow switching. >>> Please elaborate what you see as an issue and a scenario that you >>>believe >>> cannot be achieved as per the current WG I-D. >> >>This is from RFC 5213, Sec. 5.4 on multihoming support: >> >>When a mobile node connects to a Proxy Mobile IPv6 domain through >> multiple interfaces for simultaneous access, the local mobility >> anchor MUST allocate a mobility session for each of the attached >> interfaces. Each mobility session should be managed under a >> separate Binding Cache entry and with its own lifetime. > > You keep tossing these snippets of text and references and hoping that it > explains the question. It does not. > >> >> >>This is the problem. Without modifying the way mobility sessions are >>handled it is impossible to do any flow mobility among multiple >>interfaces. > > > I disagree. If you look at Scenario 2 in Sec 3.2.2 of the WG I-D > (draft-ietf-netext-pmipv6-flowmob-04.txt), you will see the binding cache > details. > Hence I do not see what specific problem your I-D is solving. > Sorry, I could not see any reference to the binding cache in Sec. 3.2.2 :-)= . Maybe you meant Sec. 3.2.1? It seems that Sec. 3.2.1 is ignoring the problem in binding cache management from RFC 5213, i.e. each entry corresponds to a different mobility session and therefore independent, i.e. the analogy here is the binding cache entry for another MN. Without changing this first, how can you talk about flow mobility in PMIP? OTOH, Section 5.1 comes close, it adopts MIP6 MCoA approach, i.e. binding cache entries for the same MN are treated in an integral way, not representing different mobility sessions. The problem of independent binding cache entries for different interfaces of MN seems to be ignored except somewhat in Section 5.1. That even though draft-sarikaya-netext-fb-support-extensions was an input document to the design team. Regards, Behcet From internet-drafts@ietf.org Mon Jul 30 01:00:49 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 5EDD521F86C5; Mon, 30 Jul 2012 01:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rN2DaoLbLZYO; Mon, 30 Jul 2012 01:00:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCAC21F86B6; Mon, 30 Jul 2012 01:00:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730080048.24251.24478.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 01:00:48 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 08:00:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : 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-12.txt Pages : 19 Date : 2012-07-30 Abstract: The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-access-network-option-12 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-access-network-optio= n-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/