[netext] Draft minutes of WG meeting at IETF75

[<[e-mail]>]

Minutes of :
Network-Based Mobility Extensions (netext)
At: IETF75 (Stockholm)
THURSDAY, July 30, 2009 from 1300-1500 

Chairs: Basavaraj Patil <[e-mail]> 
	Rajeev Koodli <[e-mail]> 

Credit for these minutes:

1. Marco Liebsch <[e-mail]>
2. Juan Carlos Zuniga <[e-mail]>

============================================================

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