Minutes of : Network-Based Mobility Extensions (netext) At: IETF75 (Stockholm) THURSDAY, July 30, 2009 from 1300-1500 Chairs: Basavaraj Patil Rajeev Koodli Credit for these minutes: 1. Marco Liebsch 2. Juan Carlos Zuniga ============================================================ 1. Agenda bashing, Blueseheets, Note takers, Jabber scribes 5 Mins Basavaraj Patil: First part/hour will be dedicated to the 3 approved items: Localized routing, Runtime LMA association and Bulk registrations Second part will be dedicated to new proposals 2. WG Status update 10 Mins Chairs BP: Charter includes 3 deliverables - Netext2 will determine flow mobility and multiple interface candidate features for re-chartering Localized routing, not to be refered to as routing optimization Sri: scope in single MAG? BP: hold discussion for Marco's presentation Behcet Sarikaya: no multiple MAGs then no routing optimizations BP: Please hold discussion for Marco’s presentation 3. Localized Routing discussion 30~40 Mins Problem statement, Scope and Solutions discussion I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt Presenter: Marco Liebsch Qin Wu: initiation of signaling. What is the sequence between initiating signaling and detection? Shouldn’t it be the other way around? ML: there is no order implied. This is a list of requirements and more may be needed QW: before setting up routing pat you should as LMA to localize routing. ML: You mean negotiation? Rajeev: What negotiation? QW: Negotiate the scenario RK: You are assuming a certain bahaviour. Let’s see slides first Sri Gundavelli: ?? RK: Ref arch 1, Is there LMA-LMA signaling? ML: It depends on the solution. We should first decide on the use cases RK: regardless of the use cases, we should decide if inter-LMA signalling is in scope or not ML: LMA2 should be aware somehow RK: currently we assume no LMA-LMA signaling ML: my opinion is that inter-LMA signaling should not be a reason to rule out scenarios Ken Leung: I agree that this is an architecture and use cases, so no solution assumptions are made Alper Yegin: LMA most likely will be needed QW: In this figure, LMA1 and LMA2 are in one domain. If they were in a different domain, would they be considered. ML: My understanding was that the scope was for a single domain BP: Only in the case of MN registered to different LMA is then this considered. IF they have different prefixes then there is no need for siganlling RK: This doesn’t imply communication between the two LMAs. MAG1 can talk to LMA2 ML: this is the same level AY: In the roaming case MAG1 may not have security association to LMA2. This could be a single PMIP domain still. MAG to MAG may be needed, so we will need to extend beyond the current only LMA-MAG signaling paradigm SG: Even with different operators, we should be able to solve the problem with MAG-LMA signaling RK: We should not rule it out, but we still have to discuss ML: So multiple LMAs are considered but signalling should still be discussed JeanMichel Combes: ??? Subir Das: With roaming we should then consider other things. Two LMA in the same domain (operator) makes sense, but between two different operators we might not need localized routing. BP: we currently refer to LMA and MAG as one domain SD: in terms of localized routing, this only makes sense for a single operator. Otherwise you need a lot more RK: so far we assume a 1-1 mapping PMIP domain and operator. If you have LMA out of domain (operator) it is a different case and this is not in scope SG: they have to be intra domain, otherwise there is no security association SG: if you roam in a PMIP6 domain, then is in scope SG: as long as boxes have a security association ML: cannot restrict scope if terminology is not agreed SG: ?? AP: In WiMAX dynamic security association can be done between one local MAG and remote LMA SD: one to one mappings between all combinations is possible, but we should restrict BP: discussion to be taken in mailing list BS: restrict to single domain and then recharter ML: too restricting ML: continuation on issues, terminology. We assume single and multi-MAG scenarios. Multiple LMAs still under discussions. BP: We agree on MAGs in same domain, but still debate on multiple domains KL: Single should be considered too. ML: it is implicit SG: Is internetwork signaling? Telemaco Melia: Negotiation between MN’s and CN’s MAG should be tight to inter-domain RK: We won’t get agreement if we don’t restrict to single domain Ryuji Kakikawa: This IPv4 may create a big problem. But using IPv4 transport does not make sense. KL: Typically transport will be the same, but some transition networks may have both IPv4 and IPv6, so we should not preclude this mixed transport. SD: We should clarify the assumptions otherwise the solution may be very different BP: send text on mailing list SG: No need to create restrictions. Also all MAGs in the same domain is for sure in scope. Intra-MAG in the same domain would not have address overlapping. RK: we should not preclude but we should not explicitly design for that, as LMA could initiate as well RK: We were planning to spend 1 hr in three topics and we just spent 1 hr in the first topic alone. We should discuss these remaining issues in the mailing list. BP: To make progress, should we consider this document baseline? About 12 in favor, none against BS (for Jari in jabber): for adopting as well - Solution presentations skipped in lieu of time constraints 4. Runtime LMA Assignment Support for Proxy Mobile IPv6" I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins Jouni presents: *LMA re-selection during running connection *Define solution that is not dependent on external infrastructure *Issues with selection *Typically implies AAA interaction *From LMA point of view the selection of the MAG may be suboptimal *Initiating a new selection is costly *Why runtime selection of LMA? *Loadbalancing *current solution draft has two solution approaches Discussion: Rajeev: You look at PBU from LMA1 to LMA2? Sri: It's just a relay Rajeev: This protocol is about telling MAG about a different LMA. Why do we overload the proposal by sending PBU from LMA1 to LMA2? Alper: First PBU not for discovery, but to create a BCE. Its optimization Rajeev: That optimization should not be part of this protocol Just have LMA1 telling MAG: go to LMA2. Out of scope should be how LMA1 finds LMA2 Jouni: May be misleading Ryuji: Seems very simmilar to HAHA document Rajeev: Everything going between LMAs should be out of scope of this document PBU is misleading, as we know what PBU means Jean-Michel: LMA redirect solution exists, why not using it? Jouni: I don't know how to use it here Jouni: Vijay said the redirection is not applicable to this space Sri: At what point is the BCE created on the LMA2? Jouni: Depends on the implementation Sri: Assume three boxes, at what point is the BCE created? Jouni: Here (points to the slides, I guess it was at the PBU between LMAs) Rajeev: Then I have a problem. Sri: Point is you have no longer the LMA1 in path kent: r2LMA should have some states at some point. This is not described how to set up? What if LMA1 and LMA2 are different vendors? Jouni: Did not think about different vendors Rajeev: You solve two problems at the same time. Selection is fine. PBU below (MAG-LMA2) should create the BCE Jouni: So you propose to delete the LMA1->LMA2 signaling? Raj: Valid questions about different vendors Rajeev: Take it to the list Two things: LMA selection one issue. How to create BCE at the second LMA2 is not an issue here. Jouni: Adopt as WG document? Raj: Clarify remaining questions first. Clarify on the ML, then we take the consensus discussion on the list Kent: Ok with this work. Should be ok to ask now Result: Pros-> 10 in favour Cons-> opposed, take as baseline but do something else: 4 Raj: Formal consensus call on the ML LZ: we submitted a document to address a similar solution, so we can review it SG: A second document 4 months after is a waste of time 5. Bulk Re-registration for Proxy Mobile IPv6 10 Mins I-D: draft-premec-netlmm-bulk-re-registration-02 Jouni Korhonen AY: numbers should be 1:20000. Why to group (…) JK:??? ML/SG: If all sessions are in the same MAG you want them together BS: is like CSG concept in 3GPP for femto JK: no BP: should be separate concepts wrt mobile node group identifier? BP: Should we consider adopting RK: Group identifier is an interesting concept. We should specify it when we have use cases like bulk … and then you define it. JK: ??? RK: In deregistration LMA needs to know. You need something stating that if the MN has a group id then you should deregister JK: this is a detail RK: An important one KL: Bulk registration is a specific case, whereas group id is more generic and useful thinking of the use cases AY: Group id ok, Bulk not so much. Group id could be useful for these and other concepts SG: ??? RW: I would like to see usage and justify this for single MAG SG: all group id can be used BP: We might specify in different documents Raj: Adopt as WG baseline document?: 5 hands Raj: Specify group ID in a separate document may be ok. ++++++++++++++++++++++++++++++ 6. Mobile Node Group Identifier Option 10 Mins I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli Sri proposes a Mobile Node Group Identifier Option Alper: LMA assigns the group ID? Do you consider that the MAG assigns? Sri: Yes. Group ID could be on both ends Alper: How do they know about the use of the ID? Sri: Option has field Sub-Type, which defines the scope Ryuji: Do you assign ID to the MN which is anchored by same MAG or different MAG? Sri: LMA doing allocation. Could be different MAGs. Then ID is allcoated in LMA scope Ryuji: How can different MAGs use the same group ID? Rajeev: Cut the line Jouni: You said it's bad that LMA assigns the ID. LMA assigns in scope of one or multiple MAGs? Qin: Possible to assign though AAA? Rajeev: Scope of group ID, who manages, lots of interesting questions, use cases, buld refresh, bulk revokation. Please continue discussion on the list. 7. Tunnel Negotiation for Proxy Mobile IPv6 5 Mins I-D: draft-xia-netext-tunnel-negotiation-01.txt Hidetoshi Yokota for Frank Xia JK: What does it change if this is not IPv4? HY: ??? SG: Already specified elsewhere Suresh: The tbit exists, but if you want other types is possible, and I want that BP: Do we need that flexibility in PMIP? There needs to be SA between LMA and MAG, so the knowledge and support of the peer is assumed HY: configuration will change Suresh: even with MPLS provisioning you might need such capability. RK: End of time. Move to mailing list Raj: Do we really need this flexibiity at the current time? Don't see the need now. MAG does not send PBU to random LMA. There is a security association, etc. so there is configuration knowledge Hidetoshi: Operator may change the network Other agenda items not discussed because of a lack of time. +++++++++++++++++++ Next Steps: Raj: Next: 3 main documents to proceed. Reviews are appreciated. Please provide comments