============================================================================== NETEXT2 BOF Meeting minutes TUESDAY, July 28, 2009 1300-1500 Afternoon Session I ------------------------------------------------------------------------------ Minute taker: Telemaco Melia ------------------------------------------------------------------------------ Agenda 1. Blue sheets, scribe, agenda bashing Chairs - 5 min 2. Problem scope Jonne & Marcelo - 20 min 3. Overview of types of solutions Julien & Suresh - 30 min 4. Requirements Raj & Rajeev - 50 min 5. Next steps ADs - 15 min ------------------------------------------------------------------------------ Problem space Marcelo introduces the problem space ------------------------------------------------------------------------------ Overview of types of solutions Julien presents the solution space document Carlos: Uplink requires changes to the MN, in any case you need something handling sending uplink packets Julien: You need to decide where traffic is sent Carlos: you need something anyway Marcelo: Julien means something related to mobility George: if one interface goes down you cannot handle this Christian: you need co-ordination between network and MN Sri: are you using in case you use MIP you have one address, in PMIP two, are you making this differences? Rajeev: are we having the discussion on MN changes now? There are changes that are beyond this Bof, we should stick to this. Sri: who is the controlling entity? Julien: you need signalling between MN and MAG, this is the only thing I want to say Sri: this MN MAG SA is a new requirement Marcelo: this is not a new requirement, this slide is Julien’s view on the issue Greg Leb: the stuff on PMIPv6 would be part of the charter if the WG is going to be formed? Marcelo: Yes ------------------------------------------------------------------------------ Requirements Rajeev presents the document George: this is the same mobile; you are not saying if access 2 replaces access 1 Raj: even with the base 5213 you could attach to access 2 but it would be considered as a new session, you need a mechanism to maintain that session Rajeev: exactly, here the access type changes, the MN needs to state if this is a new network entry or a handover George: what do you mean LMA manages MN mobility? Rajeev: specifications RFC 5213, MN has no clue Jonne: you are describing how PMIPv6 works, right? Rajeev: Yes, and this should be the same for beyond PMIPv6 George: the fact that the MN brings up and down interfaces makes the protocol to react, the protocol is the result of MN actions Marcelo: this is one of the requirements, check it carefully. We are going to ask what changes you would do to this list of requirements. George: you seem determined to come up with this list of requirement, are you ready to accept that there is nothing to do? Ralph Droms: multi-homing, you are talking to move all the flow from IF1 to IF2? Rajeev: inter-tech and multi-homing are two different things Jonne: are we talking v4 or v6? Jari(jabber): do you agree that we need signalling MN to MAG? Are these host changes? Rajeev: we need to be careful about host changes, it could mean configurations, virtual interfaces or new stuff Marcelo: what is the requirement? Rajeev: the MN does not engage in any protocol mobility, but it can provide indications to the MAG. We need to agree if this is in scope. Host changes are indications to the MAG to distinguish attach from handover. Jonne: it means that there is change to the node? Raj: you are jumping to the solution Marcelo: this is a very clear requirement saying that you do not change the MN. Do we need to change the MN or NOT? Rajeev: are you going to say that if you use DNA it requires host change? Jonne: you expect that there is something needed Rajeev: I am not thinking about a new protocol Jonne: it seems you do need something Ralph: it seems that we are moving forward. There is a great scale of changes to the MN. The first condition is that if we need changes or not at all. Then the range of changes might be really large. Adding one bit to a protocol is not really a change. Gregory: is the use that when you move from old MAG to new MAG there is always a L2 change? Rajeev: we do change L3 interface Julien: what is the reason for requirement 2? Rajeev: is there an SA between the MN and the LMA? Jonne: why do we want this? Rajeev: simply because we do not want the operator to manage and provision the SA Rajeev: your deployment will have authentication access anyway, SA between MAG and MN is not a requirement. I can see why I do not want an SA between the LMA and the MN Ralph: the SA stuff is orthogonal to the issue to the inter-technology or multi-homing Rajeev: not really Jonne: this is a requirement that we consider for the solution Suresh: why is it harder to have a SA between the MN and MAG than have an SA between the SA and LMA George: access authentication is between the MN and other entities, SA is between the MN and the MAG. If you want protocol operations you need to have an SA between MN and MAG. Rajeev: why do I need to keep per MN SA state? Julien: I disagree with you, there is no overhead to have a SA between MN and LMA. This requirement should not be there. Kent: We can come up with a solution that does not require an additional solution between the MN and the LMA Suresh: we should clearly write the requirements and agree on this Jonne: this is the exercise we are trying to do here Sri: we do not want to change this requirement since the LMA is not known by the MN Ralph: I would suggest to move on George: is this a complete list of proposed requirements? The first one is not really a requirement. Rajeev: this is a requirement, we need PMIP to enable inter-tech and multi-homing George: the first one is not a requirement, second one we discussed, third one we touched, fourth one could you clarify? Rajeev: let’s go back to the last one, if this is not a requirement why are we here? Fourth requirement means moving flows. Christian: we should rephrase requirements in a high level way Marcelo: sorry but the current list is clear Jonne: are you proposing new requirements? Christian: I support the first one Suresh: we need to clarify what we mean by additional mobility signalling Rajeev: you need to say that the MAG needs the information about the handover Julien: the problem is that you say that the MN cannot handle his own mobility Rajeev: how would you put DNA versus MobileIP? I do not see how indications are mobility signalling. Ralph: first bullet is a set of goals. We need to be able to clearly state the flow mobility requirement. LMA controls flow mobility, would be better to split these requirements. We need to re-work requirement 3. Sri: hints are not mobility signalling Marcelo: we need to know if we agree on the requirements or not. Jonne: do the requirements capture the discussion or not? Suresh: number 3 is insufficient, I can propose text George: requirements are too few and too vague, are we extending L3 signalling, are we proposing new L3 signalling or we rely on L2? Jari: we have to work in an agnostic solution manner, work to be done on the requirements Rajeev: how long are we going to iterate this? We need some clarity. Marcelo: we need to understand the problem Ralph: based on the interest here, we need a set of requirements that everybody can read and understand. And then we need to choose a direction of how to solve the problems. Gregory: are you saying that they need to refine the requirements first or that they need to refine the problem statement? Marcelo: this work needs to show to the Ads what we need to re-charter NEtext. Jonne: the outcome can be that there is not an agreement Gregory: are you open to the idea that there is nothing to do on this? We should ask if we agree that there is a problem to work on and if we can come up with a list of requirements to work on this Marcelo: the AD suggested to come back to the requirement list Juan Carlos: I would suggest to split the last requirement Suresh: try to get feedback on the mailing list about the requirement list Rujy: there should be a trade-off between MN modifications and requirements Charlie: my understanding is that there are 3GPP deployments addressing multi-homing ------------------------------------------------------------------------------