From Basavaraj.Patil@nokia.com Thu Dec 8 11:00:12 2011 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 C371821F8509 for ; Thu, 8 Dec 2011 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 0GIctPcpg0IP for ; Thu, 8 Dec 2011 11:00:11 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3260E21F8AF5 for ; Thu, 8 Dec 2011 11:00:11 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB8J08n6029769 for ; Thu, 8 Dec 2011 21:00:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 21:00:08 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by 008-AM1MMR1-012.mgdnok.nokia.com (65.54.30.21) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 8 Dec 2011 20:00:07 +0100 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.69]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Thu, 8 Dec 2011 20:00:01 +0100 From: To: Thread-Topic: IETF82 Working group meeting minutes Thread-Index: AQHMtduWkVcPuomKTkaU//z0VCwgkw== Date: Thu, 8 Dec 2011 19:00:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: <91E38C290C8C0A46BAA125C8CCA21CF2@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2011 19:00:08.0774 (UTC) FILETIME=[9AE00660:01CCB5DB] X-Nokia-AV: Clean Subject: [netext] IETF82 Working group meeting minutes 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, 08 Dec 2011 19:00:12 -0000 Please see the Netext WG meeting minutes from IETF82. If you find any discrepancies, please let me know. -Basavaraj Network-Based Mobility Extensions WG meeting at IETF82 (Taipei, Taiwan) Wedensday, November 16, 2011 0900-11:30 Morning session I (Room 101B) Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) attending remotely via Meetecho These meeting minutes are courtesy of: 1. Ved Kafle (kafle at nict.go.jp) 2. Carl Williams (carlw at mcsr-labs.org) Thanks also to the Meetecho team for providing support with the remote-participation tools. ------------------------------------------------------------ 1. Work group status update: Basavaraj provided an update on working group activities including working group documents. Basavaraj stated that the working group made good progress between IETF 81 and IETF 82. The draft draft-ietf-netext-redirect-12 is in the RFC editors queue. Basavaraj stated that thanks to reviewers that the working group also was able to forward three IDs to the IESG: (1) draft-ietf-netext-radius-pmip6-05; (2) draft-ietf-netext-pmip-lr-07; (3) draft-ietf-netext-bulk-re-registration-08. Basavaraj stated that the goal is to get the following drafts to working group last call prior to IETF 83 for : (1) draft-ietf-netext-pd-pmip; and (2) draft-ietf-netext-access-network-option. Basavaraj stated that further reviews and feedback is being looked for (1) draft-ietf-netext-pmipv6-flowmob; (2) draft-ietf-netext-logical-interface-support. .......................................... 2. Logical Interface Support for Multi-mode IP hosts I-D: draft-ietf-netext-logical-interface-support Presenter: Sri Gundavelli Sri states that six of the previous 7 open issues were address since version -01 of the I-D . (1) Behavior of ND; (3) Use of the Virtual LLID; (4) Point-to-point Links; (5) Multicast Traffic; (6) MTU issues; (7) UL/DL packet processing. Raj: ND related question =AD logical interface hides the fact that you have multiple active multiple physical interfaces. When you send a RS what you are saying is that the RS is being sent to both interfaces. It will then respond by send replicate and send out on both interfaecs? Sri: exactly Raj: In absent of logical interfaces would that be normal behavior? Jari: It is correct action to send it on both in general but the issue is more about what is the definition of link-up? Jari: In case of router discovery it is a good approximation to send out an RS when one of the interfaces comes up. Jari: there is another aspect to think about =AD what is the DNA behavior =AD how does IP layer know what is going on. I suppose you are changing source link layer address. Sri: link layer address must be same =AD from perspective of the upper layer and what is sent. Jari: If you have a link layer address =AD it must be same. Jouni: how to expose different routers to logical i/f Sri: exposing multiple neighbors is possible Sri: this is not concerned with multihoming, above logical i/f it looks single homing Raj: what about DHCP including some v4 addresses? DHCP aspects covered? Sri: discovery messages will be sent to all physical i/f; somehow covered. Raj: Regarding MTU =AD if you receive RA from both interfaces with two different MTU which one. Sri: Lowest one of the access technologies. Jari: What does IPv6 say? Sri: Good point and will look into it. Raj: Asked for reviewers. Pete McCann: Will review. Raj: Ask that the issues on slide 1 be looked at and determined if they have been resolved satisfactorily.. It was also agreed that the document should be sent to 6man for review as well. .................................................. 3. Proxy Mobile IPv6 Extensions to Support flow Mobility I-D: draft-ietf-netext-pmipv6-flowmob-02 Presenter: Carlos Bernardos Carlos Bernardos (editor) updated briefly the status of draft-bernardos-netext-pmipv6-flowmob. Sri: What are the open issues? Carlos: It is to work on details and then wait for to request comments. We are lacking input so there is no formal list. Carlos: We have to provide clean details on signaling. Sri: LMA initiated flow mobility =AD I am just trying to think of other contention points. Raj: This draft depends on logical interface draft =AD do you have any questions or comments on logical interface that derives from flow mobility.=20 Carlos: Not really. Co-authors of flow mobility also co-authors of the logical interface draft. It was agreed that Jouni Korhonen and Alper Yegin will perform a review of this document. ........................................................ 4. Prefix delegation for PMIPv6 I-D: draft-ietf-netext-pd-pmip-01 Presenter: Carl Williams Provide means to enable DHCPv6 Prefix Delegation for a Proxy Mobile IPv6 deployment because RFC 3633 is sufficient for PMIPv6 - Binding Cache Entry (BCE) and Binding Update List Entry (BULE) extended with a new prefix information field as specified in RFC3963. This prefix information field is used to store the mobile network prefix information Sri: there is no context transfer between MAG? Carl: yes; LMA is used for it Behcet: does it need change in DHCP client? If so it can be outside netext scope. Raj: Prefix delegation is not a new item, it falls within the charter; same thing was done in nemo etc. Jouni: since routers are also supporting DHCP pd, there is no problem to adopt DHCP pd for mobile routers in PMIPv6; Rajiv: if routers support DHCP; they should support DHCP PD. Carlos Bernardos agreed to do a review of this I-D. ........................................................ 5. Optimizing IP Mobility Authentication with EAP I-D: draft-perkins-netext-eapbu Presenter: Charles Perkins Jouni: if multiple routers are requested, do you do a bunch of PBU/PBAcks between LMA and MAG =AD then you have multiple extensions with AAA at same time. Raj: PBU with EAP with authentication option is actually being carried in Radius attribute. Encapsulating the PBU in the radius access request message =AD not shown here but implied here. If you have multiple EAP messages that are going through then LMA acts as a relay. Subsequent messages wouldn=B9t necessary contain that data option =AD just forwarded through LMA. Sri: Today we use the CUI in some cases =AD Access and home network are in two administration domains. What are considerations? Charlie: You should be able to use a lot of different identifiers =AD CUI is a good point. No compelling the identification to NAI. Alper: why not carry EAP over radius and then you can piggy back binding update over radius. Charlie: I want to get rid of this separate access authentication and I am happy either way. Alper: Either way you need to maintain Radius between access network and core network =AD radius and similar diameter have a lot of attributes =AD you don=B9t want to put them in the binding update =AD they need to stay with the AAA messaging. Alper: I thought that Raj stated that PBU is carried over radius. Charlie: If you have more radius specific information then this is a convenient approach. Pete: Then it would like the DIAMETER-Mobile IP approach done a number of years ago. Charlie: If you want to run 802.1x then it is not obvious how to do that. Pete: This is the proxy version of the DIAMETER-Mobile IP application. It looks like the MAG and LMA must be in the same trust domain. Normally if an access router is authenticating a device it goes to a local AAA server that it trusts and in this case it going to the remote=8A. Charlie: Point is to allow mobility smoothly not just in the home domain. Part of the point is to tell what the authorization domain is. You want to roam remotely you have to allow the access authorization to eventually be done in the home network. Now if you want a concentrator in the access network Pete: For scalability Charlie: that point was brought up earlier. Pete: It is not just concentrating the access network but also encapsulating the business agreements between the different operators and those are typically done with radius brokers. Charlie: Essentially you want another vertical line here that says AAA aggregator =AD no problem. Charlie: I agree with that. Pete: I agree with what Jouni said that the overhead being dominated by the EAP method =AD if you are not careful =AD in particular if y= ou are using one of these EAP TLS methods =AD that can be numerous round trips. =20 Charlie: I agree =AD you can view this as me asking the working group if this is a sensible approach. If it is, then let us make a better EAP method. =20 Pete: And if you are talking about handoff, then you can get some input from HOKEY working group because they are looking at EAP methods and dealing with keying material. Charlie: I doubt if they give me feedback because the working group is shutting down. Pete: ok but folks that did that work you can ask. Charlie: You are right. Raj: Yokota-san is asking about accounting aspect. Are accounting messages relayed through the LMA. Charlie: LMA doesn=B9t take on the accounting =AD PBU and PBA in encap radius =AD and identifier will give it the proper home network to go to but the proper home network need to go to the proper AAA server and it will check authorization. If the LMA has that ability is not part of scope of this document. ........................................................ 6. Service Selection for Mobile IPv6 I-D: draft-korhonen-netext-rfc5149bis-00.txt Presenter: Jouni Korhonen To update RFC5149 from informational to standard track category - update service selection identifier field encoding to UTF-8 - extend identifiers with additional =B3index=B2 Raj: Request authors to clarify more about the problem statement and applicability; usage and service selection parameters, get additional feedback from WG; ........................................................ 7. Problem Statement of Flow Mobility Triggering=09 I-D: draft-tian-netext-flow-mobility-trigger-ps-00 Presenter: Tian Tian - making the trigger for flow mobility clear - host based and net based triggers possible - Host based triggering - L3-signaling trigger - L2-signaling trigger (MAG trigger) =AD maybe outside ietf scope - Explicit flow trigger =AD MN sends trigger to MAG (maybe outside netext scope) - Network based triggering - LMA trigger (issue: how lma know that MN supports flow mob) Raj: host-based triggering is outside netext scope Sri: this is some how related with MN-aware document discussed long ago. Raj: MN-aware was about link model =8A Sri: since IETF should provide how MN interface looks like; this can be an informational document Rajiv: multi-access indicator ID can be used to indicate if the MN supports flow mobility ........................................................ 8. PMIPv6 Multihoming Support for Flow Mobility I-D: draft-sarikaya-netext-fb-support-extensions Presenter: Behcet Sarikaya - Current pmip RFC has no flow mobility; LMA does not know that MN has different i/f - Solution: - The bindings in binding cache from each interface are kept together so that the flows can be moved among interfaces In binding: one home interface (for incoming flows); and many secondary interfaces Raj: Wg members, please read the draft; provide comments. ........................................................ 9. MN Status Option for Proxy Mobile IPv6 I-D: draft-tu-netext-mn-status-option-00 Presenter: Yangwei Tu Yangwei presented problem statement regarding sleep mode and flow mobility and solution for optimization for moving flow mobility to interface that may have went into sleep mode. Sri: can you clarify on wifi what idle state. I think there is good stuff but trying to figuring how it can be used. Yangwei: On wifi it is called power saving mode. Similar but different. Sri: It can be access technology type specific. Yangwei: yes. Sri: It is important information but see how it can be applied in different use cases. Overall you have to build more things to justify it.=20 Raj: If flow is switched when you send packets down to next MAG =AD what you expect to happen that you would page the mobile. Yangwei: But this would cause delay to the mobile. Raj: not sure if problem per-se. Yangwei: we don=B9t want bad user experience. Mobile move out of coverage =AD no method to move data that sent to MAG 2 and can=B9t be sent to MAG 3. Takes time to do and bad service. Raj: We have done work to deal with fast handover. Please take a look at these fast handover drafts. I recommend more discussion on list. Please create more discussion on list ........................................................ 10. Quality of Service Option for Proxy Mobile IPv6 I-D: draft-liebsch-netext-pmip6-qos-00.txt Presenter: Marco Liebsch Marco presented QoS option for PMIPv6. Set of enforcement of QoS in network an access network. Raj: With regard to the =B3Support enabling QoS differentiation of traffic between MAG and LMA for any non-3G access=B2 =AD assuming yo= u have some kind of QoS on the radio bearer you are trying now to specify QoS between the MAG and LMA? Marco: we don=B9t expect that between the LMA and the MAG that serves a non-3GPP network is more fine granular =AD in access we need more fine granular policies to allow for the mapping radius qos. Raj: What are you doing with the awareness =AD between the MAG and LMA you have multiple flows and so on =AD what are you doing between the MAG and LMA =AD are you doing diffserv markings? Other part of question is how to enforce it. Marco: For dynamic QoS flows in diffserv network we have to discuss =AD so far we assume static rules. For dynamic ones it depends on where intelligence is located. Do you think it should be dynamic.=20 Raj: Not sure. Still trying to figure out what you do between the MAG and LMA regarding handling the traffic as a result of the QoS requirement awareness =AD that is sort of thing I am asking. Marco: PMIP is the vehicle to exchange this information. If you want intelligence than this is out of scope of PMIP (NETEXT). We should make use of use cases. Raj: I would appreciate use cases of how this would be use. Raj: How many people think of interest? How many people think that PMIP should handle QoS information? 8 hands raised. Raj: How many people think that PMIP should not do this work? A couple of hands. Raj: Please enhance the draft with use cases and discuss on mailing list. .............................................................. Chair concluded the meeting with next steps for a couple drafts =AD working group review of logical interface draft and flow mobility in particular. Last call by next IETF meeting. From suresh.krishnan@ericsson.com Thu Dec 8 22:44:56 2011 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 BBB6F21F8531 for ; Thu, 8 Dec 2011 22:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.139 X-Spam-Level: X-Spam-Status: No, score=-106.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 gKJ0Cx6mPQ7a for ; Thu, 8 Dec 2011 22:44:55 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id ABC9521F84ED for ; Thu, 8 Dec 2011 22:44:55 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pB96ihDe014644; Fri, 9 Dec 2011 00:44:49 -0600 Received: from [164.48.125.41] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 9 Dec 2011 01:44:41 -0500 Message-ID: <4EE1ADE5.3050001@ericsson.com> Date: Fri, 9 Dec 2011 01:42:45 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4ECFDD66.2040801@piuha.net> In-Reply-To: <4ECFDD66.2040801@piuha.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netext-pmip-lr@tools.ietf.org" , "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-pmip-lr X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 06:44:56 -0000 Hi Jari, Thanks for the review. I have made most of the changes you suggested, but I have one question. Jari Arkko wrote: > I have reviewed this draft. > > It is in good shape and almost ready to move forward. I did find a couple of issues, however, and the most serious one of these is the one about tear-down. Please fix this and submit a new draft so that I can initiate an IETF last call. > ... > >> All the Localized routing messages use a new mobility header type >> (TBA1). >> The Localized Routing Initiation, described inSection 9.1 and the >> Localized Routing Acknowledgment, described inSection 9.2 require a >> single Mobility Header Type (TBA1) from the Mobility Header Types >> registry athttp://www.iana.org/assignments/mobility-parameters >> > > This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages. I do not have a strong preference one way or another, but the last two MH messages for Binding Revocation (RFC5846) and Heartbeat (RFC5847) seem to be using a shared MH type for both the request and a response. Let me know if you want me to change this and I will do so. Thanks Suresh From Basavaraj.Patil@nokia.com Fri Dec 9 08:47:14 2011 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 50B6C21F8801 for ; Fri, 9 Dec 2011 08:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfvQ2rt798hV for ; Fri, 9 Dec 2011 08:47:13 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 86BEB21F87FC for ; Fri, 9 Dec 2011 08:47:13 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB9Gl5Dj004578; Fri, 9 Dec 2011 18:47:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 18:47:05 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.69]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Fri, 9 Dec 2011 17:47:05 +0100 From: To: , Thread-Topic: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? Thread-Index: AQHMpAbNXcKzKnB2d0K7cZZ3yVH6bZWu6f6AgAFxdo+AIwuIAA== Date: Fri, 9 Dec 2011 16:47: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.13.0.110805 x-originating-ip: [173.74.226.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C156C4CB0B08E4B96ECB18404329328@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Dec 2011 16:47:05.0863 (UTC) FILETIME=[2F1A3970:01CCB692] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? 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, 09 Dec 2011 16:47:14 -0000 Hi Sri, In your text below you state: " Any time there is an inter-technology handover between two access technologies, the applications on the host bound to the IP address configuration on the logical interface will not detect the change and will continue to use the MTU value of the logical interface for the outbound packets, which is never greater than the MTU value on that supported access network.=20 " How do you guarantee that the MTU value of the LI is never greater than that of the IF to which the MN performed a handover to? I do not believe this is realistic unless you set the value to the Min MTU value (1280) as the default and simply ignore whatever MTU the link supports. -Raj On 11/17/11 10:36 AM, "ext Sri Gundavelli" wrote: >Hi Charlie/Raj: > >Agree. This is what we have for the MTU considerations. > > >5.2. MTU considerations > > The link MTU (maximum transmission unit) value configured on a > logical interface should be the lowest of the MTU values supported > across any of the physical interfaces that are part of that logical > interface construct. The MTU value should be configured as part of > the logical interface creation on the host. > > Furthermore, this value must be updated any time there is a change to > the logical interface construct, such as when interfaces are added or > deleted from the logical interface setup. Any time there is an > inter-technology handover between two access technologies, the > applications on the host bound to the IP address configuration on the > logical interface will not detect the change and will continue to use > the MTU value of the logical interface for the outbound packets, > which is never greater than the MTU value on that supported access > network. However, the access network may continue to deliver the > packets conforming to the MTU value supported on that access > technology and the logical interface should be able to receive those > packets from the physical interface attached to that network. This > approach of MTU configuration will ensure there is no IP packet > fragmentation after inter-technology handovers. > > >On 11/15/11 9:34 PM, "Basavaraj.Patil@nokia.com" > >wrote: > >>=20 >> Hi Charlie, >>=20 >> Using the minimum MTU as the value for the logical IF is probably the >>right >> thing to do. >> However you can also consider this as a sort of a DoS attack in the >>sense that >> you are forcing the MN to use an MTU to a smaller value thereby causing >>less >> efficient use of an air IF. >> As an example a wifi network may advertise an MTU of 1280 and if the MN >>uses >> this as the default even on the cellular IF, the cellular IF is being >>used sub >> optimally. >>=20 >> -Basavaraj >>=20 >> On Nov 16, 2011, at 10:23 AM, ext Charles E. Perkins wrote: >>=20 >>>=20 >>> Hello folks, >>>=20 >>> At the meeting this morning, a question was raised >>> about the proper behavior on a logical interface if >>> more than one value of MTU were advertised on any of >>> the links of the interface. This was discussed in >>> the IPv6 working group. IIRC, the sense of the >>> discussion was that this was simply an error. >>> See section 6.2.7 of RFC 4861. >>>=20 >>> In the case for logical interfaces, it seems to >>> me that (a) a device can pick the MTU for whatever >>> router advertisement it is using and (b) for the >>> purposes of multicast across all links the source >>> should pick the minimum of all advertised values. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> Regards, >>> Charlie P. >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From jari.arkko@piuha.net Sun Dec 11 14:44:36 2011 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 4FE9A21F849D for ; Sun, 11 Dec 2011 14:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 OcDQ77Rjv5Vv for ; Sun, 11 Dec 2011 14:44:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0F21F845D for ; Sun, 11 Dec 2011 14:44:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D0A5C2CC43; Mon, 12 Dec 2011 00:44:33 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj9jADtRhTqD; Mon, 12 Dec 2011 00:44:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CE13D2CC31; Mon, 12 Dec 2011 00:44:32 +0200 (EET) Message-ID: <4EE5324E.3010803@piuha.net> Date: Mon, 12 Dec 2011 00:44:30 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD review of draft-ietf-netext-radius-pmip6 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, 11 Dec 2011 22:44:36 -0000 I have reviewed this specification. The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical issue. I would like to talk about the technical issue before we send the draft forward. Please reply to this e-mail and/or revise the draft accordingly so that I can start an IETF Last Call. Section 4.9: Shouldn't this section include some text about not including this attribute, if MIP6-Home-HN-Prefix is already present? (Like Section 4.7 had for its corresponding attribute pair.) The same problem may appear in Section 4.13 and elsewhere as well. Please check. Section 4.10 & 4.11: This is the technical issue that worries me. While RFC 5213 does say that there are cases where MN-HoA is known, this is certainly an exception rather than the rule: Mobile Node's Home Address (MN-HoA) MN-HoA is an address from a mobile node's home network prefix. The mobile node will be able to use this address as long as it is attached to the access network that is in the scope of that Proxy Mobile IPv6 domain. If the mobile node uses more than one address from its home network prefix(es), any one of these addresses is referred to as mobile node's home address. Unlike in Mobile IPv6 where the home agent is aware of the home address of the mobile node, in Proxy Mobile IPv6, the mobility entities are only aware of the mobile node's home network prefix(es) and are not always aware of the exact address(es) that the mobile node configured on its interface from its home network prefix(es). However, in some configurations and based on the enabled address configuration modes on the access link, the mobility entities in the network can be certain about the exact address(es) configured by the mobile node. Sections 4.10 and 4.11 talk about IIDs without any context on how they should be derived, used, and whether they can even exist on a given deployment. One approach to fix this would be to delete the subsections. Another one would be explain how the IID values are determined, when they can be determined, and how they should be used. Yet another approach is to point me (and the reader) to another RFC that describes this (as I could of course have missed something). > 4.18. Calling-Station-Id > > The Calling-Station-Id attribute (Type value 31) is of type String > and when used for PMIPv6 it contains the link-layer identifier of the > MN as defined in [RFC5213], Sections 2.2 and 8.6. You should refer to the RFC that originally defined Calling-Station-Id. > The User-Name attribute MUST be present in the Access-Request. It > SHOULD carry a valid MN identity unless the identity is being > suppressed for policy reasons, for example, when identity hiding is > in effect. The MN identity, if available, MUST be in Network Access > Identifier (NAI) [RFC4282] format. I think there is always an identifier that is of the valid form. It just may not reveal the identity of the user (at least not in an 1-1 and stable fashion). Consider making this change: ... MUST carry a correctly formed identifier that SHOULD correspond to a MN identity unless ... Jari From jouni.nospam@gmail.com Tue Dec 13 05:04:09 2011 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 7571721F8490 for ; Tue, 13 Dec 2011 05:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 s1gIey0SmK3e for ; Tue, 13 Dec 2011 05:04:08 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1660521F8483 for ; Tue, 13 Dec 2011 05:04:07 -0800 (PST) Received: by laah2 with SMTP id h2so1820690laa.31 for ; Tue, 13 Dec 2011 05:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uW9tW7ZgPH5dtFv2ttrPP0FGzEiOAwBWup1r58qgqK0=; b=Ins+JZ1/RmGv4Rarvb3+eSH+aqRzpLIPXoJWfSkRqxTKiD3VDpEVisz+52Wj8LXR1+ BiHWpn/QkOC9LKaiAvZ5nZqg9eyz1rqWF4BcyV1q/4pR6/+co5BHafATuEdJvNalJYYn sKGz8tzNqW8e1ojSY2I+0IVstF+tGVxT9oldY= Received: by 10.152.109.5 with SMTP id ho5mr10838652lab.51.1323781447026; Tue, 13 Dec 2011 05:04:07 -0800 (PST) Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id lr3sm957659lab.17.2011.12.13.05.04.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Dec 2011 05:04:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EE5324E.3010803@piuha.net> Date: Tue, 13 Dec 2011 15:04:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <436DC79F-5BF8-474A-BCEF-9D8A50B0DCC4@gmail.com> References: <4EE5324E.3010803@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netext-radius-pmip6@tools.ietf.org, "netext@ietf.org" Subject: Re: [netext] AD review of draft-ietf-netext-radius-pmip6 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, 13 Dec 2011 13:04:09 -0000 Jari, Thanks for the detailed review. See my comments online.=20 On Dec 12, 2011, at 12:44 AM, Jari Arkko wrote: > I have reviewed this specification. >=20 > The draft is well written. Thanks for that. I only found a couple of = minor editorial issues, and one technical issue. I would like to talk = about the technical issue before we send the draft forward. Please reply = to this e-mail and/or revise the draft accordingly so that I can start = an IETF Last Call. >=20 > Section 4.9: Shouldn't this section include some text about not = including this attribute, if MIP6-Home-HN-Prefix is already present? = (Like Section 4.7 had for its corresponding attribute pair.) The same = problem may appear in Section 4.13 and elsewhere as well. Please check. If I recall our (authors) discussion correctly the motivation not to add = any restriction in these cases was to allow a (possible future) = deployment where the MAG receives both home & visited LMA addresses and = then picks based on some policy either one. For this to work, we would = need address allocation also have the same functionality. No problem to = add "SHOULD NOT"s there and explain the situation. > Section 4.10 & 4.11: This is the technical issue that worries me. = While RFC 5213 does say that there are cases where MN-HoA is known, this = is certainly an exception rather than the rule: >=20 > Mobile Node's Home Address (MN-HoA) >=20 > MN-HoA is an address from a mobile node's home network prefix. > The mobile node will be able to use this address as long as it is > attached to the access network that is in the scope of that Proxy > Mobile IPv6 domain. If the mobile node uses more than one = address > from its home network prefix(es), any one of these addresses is > referred to as mobile node's home address. Unlike in Mobile IPv6 > where the home agent is aware of the home address of the mobile > node, in Proxy Mobile IPv6, the mobility entities are only aware > of the mobile node's home network prefix(es) and are not always > aware of the exact address(es) that the mobile node configured on > its interface from its home network prefix(es). However, in some > configurations and based on the enabled address configuration > modes on the access link, the mobility entities in the network = can > be certain about the exact address(es) configured by the mobile > node. >=20 > Sections 4.10 and 4.11 talk about IIDs without any context on how they = should be derived, used, and whether they can even exist on a given = deployment. >=20 > One approach to fix this would be to delete the subsections. Another = one would be explain how the IID values are determined, when they can be = determined, and how they should be used. Yet another approach is to = point me (and the reader) to another RFC that describes this (as I could = of course have missed something). Right, good point. I would remove the "derivation text" and add = applicability statement for links where the network actually delivers = the IID to the end host (PPP, 3GPP, ...) these attributes contain the = IID. >=20 >> 4.18. Calling-Station-Id >>=20 >> The Calling-Station-Id attribute (Type value 31) is of type String >> and when used for PMIPv6 it contains the link-layer identifier of = the >> MN as defined in [RFC5213], Sections 2.2 and 8.6. >=20 > You should refer to the RFC that originally defined = Calling-Station-Id. Ack. >=20 >> The User-Name attribute MUST be present in the Access-Request. It >> SHOULD carry a valid MN identity unless the identity is being >> suppressed for policy reasons, for example, when identity hiding is >> in effect. The MN identity, if available, MUST be in Network = Access >> Identifier (NAI) [RFC4282] format. >=20 > I think there is always an identifier that is of the valid form. It = just may not reveal the identity of the user (at least not in an 1-1 and = stable fashion). Consider making this change: >=20 > ... MUST carry a correctly formed identifier that SHOULD correspond to = a MN identity unless ... Ok. Will change. Thanks, Jouni >=20 > Jari >=20 From internet-drafts@ietf.org Mon Dec 26 23:25:07 2011 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 A58E721F8A70; Mon, 26 Dec 2011 23:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 f0vB1wudIkYG; Mon, 26 Dec 2011 23:25:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEEC21F88B7; Mon, 26 Dec 2011 23:25:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111227072507.539.52627.idtracker@ietfa.amsl.com> Date: Mon, 26 Dec 2011 23:25:07 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 07:25:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier Option for Proxy Mobile IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-01.txt Pages : 13 Date : 2011-12-26 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 01.txt From internet-drafts@ietf.org Tue Dec 27 09:25:35 2011 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 3851721F854D; Tue, 27 Dec 2011 09:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 OQXTEkHBhSKd; Tue, 27 Dec 2011 09:25:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3121F853A; Tue, 27 Dec 2011 09:25:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111227172534.31485.95052.idtracker@ietfa.amsl.com> Date: Tue, 27 Dec 2011 09:25:34 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-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: Tue, 27 Dec 2011 17:25:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-02.txt Pages : 15 Date : 2011-12-27 This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 02.txt