[netext] Draft minutes of WG meeting minutes from IETF77

[<[e-mail]>]

Please review the minutes and let the chairs know if any change is needed.

-Basavaraj

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


Network-Based Mobility Extensions (netext)
WG meeting minutes from IETF77

Date: March 25, 2010 (1300-1500)

Chairs: Basavaraj Patil ([e-mail])
    Rajeev Koodli ([e-mail])

Minutes by: Ryuji Wakikawa
Jabber scribe: Behcet Sarikaya

Thanks to Ryuji and Behcet for volunteering.

Audio archive:
ftp://videolab.uoregon.edu/pub/videolab/media/ietf77/ietf77-ch8-thur-afnoon.
mp3

Jabber archive: http://www.ietf.org/jabber/logs/netext/2010-03-25.txt

-----------------------------------------------------

- Agenda Bashing

- WG Status

o Charter approved with work items that include flow mobility,
  inter-technology handovers and radius extensions for PMIP6
o Bulk re-reg I-D published as WG doc
o Localized routing PS I-D is fairly stable and we may go to WG LC
  soon. Scope of PS I-D includes scenarios which may be greater than
  what the solution I-D will tackle.

---------------------------------------

1. LMA runtime selection  (Jouni Korhonen)
I-D: draft-ietf-netext-redirect-01

Raj (Chair hat): In order to go for WGLC, we need more reviews from WG
Please review this doc and feedback to authors. Chairs also request
some volunteer for review.
After further improvements to this document, following reviews we will
take it to WGLC.

Suresh Krishnan, Jonne Soininen and,  Qin Wu volunteer for the review
during the meeting.
Raj requests Mohana Jeyatharan to review the I-D.

---------------------------------------

2. Bulk Re-registration for PMIP6 (Fuad Abinader)
I-D: draft-ietf-netext-bulk-re-registration-00

Raj (chair hat): For the bitmap proposal, we should analyze the scenario and
applicability first. We should take that discussion on the list and see
how we can optimize the bulk registration.
As discussed for the previous document, this one also needs review to
improve the document.
Chairs create tracker for this document.

---------------------------------------

3. Radius support for PMIP (Frank Xia)
I-D: draft-xia-netext-radius-00

Chairs: This was a NETLMM chartered item. Chairs of
NETLMM/NETEXT and relevant AD (Jari) discussed it and decided to take
this item in NETEXT.

Raj: We agreed on taking this doc to NETEXT. Any objection to use this
document as a baseline?

Alper: Have you looked at WiMAX attribute?
Frank: Yes, Damjan is co-author and inputs the WiMAX parts to this document.

Chairs: consensus call
Any objection to use this as a baseline?
Clearly no objection.
Raj: WG will take the doc as a WG document after following up on the ML.

---------------------------------------

4.  PMIP6 Local Routing (Suresh Krishnan)
I-D: draft-krishnan-netext-pmip-lr-01

How many people have read the problem statement doc?
About 10-15 in the room

Suresh: Authors have not reached consensus on the A12 scenario.
Sri: In A21, what is the optimized routing path here?
Suresh: The optimized path is bypassing the tunnel.
Sri: For the inter-domain optimization, it requires security relationships
between domains.
Suresh: right

Frank: All solutions assume communication between mobile nodes. Any
consideration of fixed nodes?
Suresh: It's all connecting to the PMIP domain, all the communication go to
LMA.
Rajeev: If LMA does not have a binding (i.e. for fixed nodes), it's
impossible to run LR.

Kent: About scenario A11, Any indication to know whether MAG supports LR.
Suresh: there is mechanism to tell "cannot do it", "don't want to do it".
Kent: At least, there is a mechanism to support the indicator of LR.
Rajeev; other choice is configuration.
Suresh: You don't need to know which MAG support LR. There is a flag
in the signaling.

Jari: This design choice is right one. The minimum amount of info to
configure on LMA/MAG. It supports the scenarios of mixing MAGs supporting
LR or regular MAG. There is no need to negotiate LR dynamically.

Kent: Clarification. When a mobile moves away from MAG, is LR
      implicitly or explicitly  tore down?
Suresh: update or tore down.

Kent: In A11, LMA can explicitly team down LR to MAG1.
Suresh: Yes, explicit tear down from LMA.

Suresh: rough consensus not to support A22 scenario among authors.
Everything we've discussed in PS does not need to be supported in the
solution. More importantly we should quickly finish this work. Now
it's open questions to the room.

Sri: The PMIP protocol assumes clear security assumption between LMA
     and MAG. Putting A22 in Appendix.
Suresh: We don't have any solution. Scenario is captured in the PS
     draft. So no need to discuss it in this doc.

Marco (via jabber): In A12, what happens if MN2 hands over to a
different MAG? The protocol runs into an out of scope situation. How
do we handle this?

Suresh: Drop LR session. we don't know how to solve A22.
No support this scenario. drop LR session and go back to the regular one.

Yuri: Handover between two LMAs. Prefix allocated to MN will be
      changed. i.e. Inter-LMA handover.
Suresh: we don't go that scenario. no support. However, in A12, we
      have discussed inter-MAG handover.
Yuri: A22 should not include in the solution. This leads complications
      to the solution.
Bechet: why?
Marco: taking out A22 is unclear. What is technical issue.
Suresh: We can do something else. DIME has to support it.
Security relation, when MAG1 and MAG2 in the different domain, how we
      can establish security relationship for the inter-domain.

Consensus call
Raj: A22 is relevant to this document?
     five people. (including jabber)
     not relevant
     10 people

Suresh: what are the chairs calling here?
Rajeev: We should handle what we know well with 5213 as the basis.
Rajeev: Chairs are open to have another document later when there is
enough understanding of this case.

Raj: Do we need MAG1-MAG2 dynamic tunnel establishment. Should we also
specify how to establish tunnels between MAGs. This is open
question. at least we should discuss it.
Suresh: why is it in the scope?

Rajeev: Two distinct function for LR: initiation and termination of
LR, handling HO.

Qin Wu: We should setup a tunnel between MAGs dynamically.
Suresh: do you think we need this LR dynamic support? Or can we assume
the tunnel is there?Do you support dynamic path setup or not?
Raj: LR can use pre-established or configured tunnels between
MAGs. It's straight forward. However this is just one way. Other
option is to introduce a new protocol to establish a tunnel
dynamically with signaling as an ALTERNATIVE solution. what does WG
consider this?
Suresh: as an editor, no need to have dynamic tunnel.

Qin Wu: scalability is issue.
Suresh: what is the benefit.
Qin: you just need to define two messages

Kent: The statically configured tunnel is just a PIPE. In addition to
that, you need something forwarding setup to route the packets to the
pipe. signaling for forwarding is required?
Suresh: Yes, but it is more a local matter. No message exchange is
required.
Kent: we still need some external message to route the packets to the
right tunnels
Suresh: No.
Kent: How to pick up which tunnel should be used for LR?
Suresh: there is a message from LMA.
Kent: Do you say LR is initiated from LMA only when LMA verifies both
MAGs agree on LR? Otherwise, it should not initiate LR
Kent: more window of failure.
Suresh: agree with you. We still need some mechanism to fall back from LR.
Rajeev: packets loss is an issue. we do LR for optimized
performance. we have a protocol for inter-MAG handover. we should have
reference for it. FPMIP.  how does source MAG know the destination
MAG. You need a routing entry for LR.
Suresh: We don't need any message for it. MAG has local database for tunnel.
Suresh: Kent requires 3 way hand-shake (both MAG accepted LR, then
going to LR), confirm both MAGs and initiates LR.
Rajeev: point is "if MAG has one entry it starts forwarding, MAG2 does
not have setting yet?"
Suresh: half-open state is open problem.
Rajeev: talk details offline
Kent: Don't state this half-open state issue.
Raj: open the tracker for this problem. discuss on the list.

Sri: we need consideration section to clarify so many features.
Rajeev: Specify default,  and if needed choose one of optional
features and just configure it.

Raj: We will adapt this as a WG doc.

-----------------------

Rajeev: new topics after rechartering:
    1. logical interface
    2. enable flow mobility and
    3. inter-tech handover.
No host protocol changes is one requirement.

-----------------------


5. Applicability Statement on Logical Interface over Multiple Physical
   Interfaces (Telemaco Melia)
I-D: draft-bernardos-netext-ll-statement-01

Frank: Is it logical or virtual IF?
Rajeev: we use the term "logical interface" in the charter.
Sri: another presentation from Hidetoshi Yokota has clear discussion of
relationship between phy if and virtual IF. This presentation just
gives the higher view of this logical interface.
Yuri: conceptual question. Is this the case when PMIP is connected.
Telmaco: Yes

Kent: PMIP6 domain, two different access networks. assumption is
assignment of the same prefix. Are Prefix1 and Prefix2 the same prefix
during the handover?
Sri: This does not deal with the handover scenario, but the MN
attached to multiple access networks of the same domain.

Julien: The draft is not well fit to what the charter specified. For
example, This document doesn't discuss the MTU, no consideration of
NDP and Neighbor reachability detection, etc.
The desired document should give us recommendation or statement of
possible issues per scenarios.
Rajeev: We can not violate 4831 in any of the possible solutions

Jari: The original idea of this document was to cover the general
things. It should talk about the expectation and type of models,
requirement. What we should consider for Default router selection,
MTU, etc. These discussion must be included in this document.

Raj: MN uses only a logical interface when it is multihomed? When a MN
is attached with a single PHY interface, it is still using the logical
interface?
Sri: Yes.
Raj: We should have Applicability statement of the logical
interface. (flow mobility, inter-tech HO)

Jari: I am confused with this picture.  Ideally hiding the multihomed
phy IF from IP stack, but it exposes multiple prefixes to the IP stack
in the picture.
Expecting some signaling in L2, hiding phy details from IP. From the
IP perspective, it always uses the same default router etc. Is it the
case of this picture?
Telmaco: yes.

Raj: it is basically hiding physical interfaces. It does not mean
hiding the prefix.

Jari: no flow mobility unless you have multiple prefixes. I am against it.
You
can still distribute multiple flows without multiple prefixes.
Rajeev: Right. Same prefix and split the traffic to multiple phy interface.
Sri: this is solution space.
Raj: this figure is not the right one to explain the logical  interface.
one prefix to logical interface. During handover, prefix remains the same

Julien: The slide picture is confusing.

Raj: obviously more work need to be done for this document. I
recommend authors to take these inputs from Julien/Jari to the
document and explain it further.

Sri: About the structure of this document, it should not get into the
solution. high level guideline only.
Kent: It needs to consider the ingress filtering

Yuri: expecting many solutions for this? Why do we need two documents?
Isn't it enough to have a document for the logical interface?
Rajeev: this document just analyze what is the concept and what need
for flow mobility work. As a result, it may turn out to be one document.

Julien: We don't have a charter to hide prefixes by logical interface.
Jari: You are chartered to do explaining general approach and another
charter to work parts for PMIP6, but not charter for middle part (how
to make logical interface work). The first document must be overall
document. It should explain the whole picture.This document is pretty
far from the expectation.
Sri: many protocols are introduced between MAG and LMA, this is the
host side solution.

-----------------------

6. Inter-tech HO with PMIP (Hidetoshi Yokota)
I-D: draft-yokota-netlmm-pmipv6-mn-itho-support-03

Yuri: Application only sees the virtual interface and multiple
      prefixes. Which address shall application pick up?
Sri: Up to source address selection.
Yokota: This document does not discuss which address should be picked.
Dapeng: between L2.5-L3. You should have a control for routing table. You
need some program interface to the IP layer.
Yokota: 2.9? Virtual interface needs to access IP layer somehow.

Dapeng you need to change the application?
Yokota: no, it's about device driver, bonding driver

?? (ETRI): No modifications from the application layer

Julien: Charter review again.
This is all about the implementation detail, MAC ID are out of scope
in this group. We don't need to discuss this here.

Rajeev: Charter said logical interface for flow mobility. we need to
know how it works. anyway, we need to figure out what documents WG
should deliver? We need  some documentation.

Jari; For flow mobility support, what is the host expectation,
limitation, assumption. From my quick view of presentation/document,
it only discusses implementation. It is missing the conceptual part of
this issue. It's only describing the end of idea.  Implication of
what? what is the capability of L2?
One example is, in 3GPP, with multiple physical interfaces, link-layer
aware of these multiple access networks and host only see one
interface.
No charter to develop a new link layer. describing existing
link-layer, and deal with more general issues in the charter.

Rajeev: I don't know we have experts to describe GPRS work.
Jari: No, just explaining the assumption for this logical
interface. assumption to the IP stack?  This documents is only
discussed one solution, We need more focus on implication and
explanation of whole things.
Jari: This is relatively easily to do. It should be short document.

Julien: agree with Jari. We don't need to describe the 3GPP work. When
hiding movement from wifi to 3G, what shall we expose to IP?

Sri: If we don't explain the detail in the document, how can we define
the protocol for the further PMIP extension?
Jari: we need some level of details, you miss the generic implication
to the implementation.
Young (ETRI): virtual interface can be easily implemented on
linux. virtual interafce is generic to handle multihoming. Using
virtual interface for flow mobility, we need more general concept.

--------------

7. Flow mobility for PMIP6

<Out of time to go through the slides proposing various solution
approaches>

Raj: Scope of flow mobility: a node does not involve in any signaling to
direct the flows. Some of the approaches utilize some info from L2 to signal
MAG to direct the flows to specific interfaces. We should not look at
how the MN is doing signaling to control the flows.

Rajeev: The base protocol should look at the LMA and MAG signaling
even if there is L2 signaling from MN to MAG.