Subject: [netext] IETF80: WG meeting minutes

From: <[email-masked]>
Date: Mon, 25 Apr 2011 20:31:25 +0000

Network-Based Mobility Extensions WG meeting at IETF80 (Prague, CZ)

THURSDAY, March 31, 2011
1300-1500 Afternoon Session I (Grand Ballroom)

Chairs:  Basavaraj Patil ([email-masked])
         Rajeev Koodli ([email-masked])

These meeting minutes are courtesy of:
1. Dorothy Stanley ([email-masked])
2. Carl Williams ([email-masked])

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

1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing)

 - See the agenda, http://www.ietf.org/proceedings/80/slides/netext-0.pptx
 - Chair reviewed the agenda, no changes identified

2. Working group status update
-------------------------------

Basavaraj provided an update on working group activities including
working group documents and additional proposals for the working
group.  

Basavaraj stated that the WG made some progress since the last IETF.  The
PMIPv6 localized routing PS has been approved by IESG and is on RFC
editor queue.  Thanks to Marco for quickly reacting to comments.
Basavaraj also stated thanks to people who actually reviewed the
document.  Basavaraj reminded us that the only way to make progress
in the working group is to do reviews and help improve the documents.

Marco said we had a few comments on the LR-PS I-D and would address
them shortly.

The other document that has made progress is the Runtime LMA
Assignment Support for PMIP6 (draft-ietf-netext-redirect).  Good
reviews on document and multiple revisions.  Jouni who is the editor
has addressed all comments and the I-D is in IESG for approval.  Last call
deadline is April 10.

Regarding the Bulk Re-registration for Proxy Mobile IPv6 (draft-ietf-
netext-bulk-re-registration) there has been a chair review. Working
group members have provided comments in the past and draft was
revised.  Chair has done review and found that the quality of
document is not on par to what can be sent to IESG.  Chairs asked
authors to update the I-D. It was noted that some progress was made
on several sections but other sections need addressed. Basavaraj said
that Sri has promised to address those comments as well. We should
probably have a document for last call by mid-April.

Radius support for PMIP6 (draft-ietf-netext-radius-pmip6-00) is a
document required for deploying PMIPv6. One update to I-D based on
implementation experience.  Basavaraj noted that some implementers
identified
some attributes required for Radius messaging for PMIPv6.  That
update has been made.  Basavaraj has requested several reviews of
document before going to IESG.  Need some reviews on document before
he can submit it.  Basavaraj has encouraged authors to find reviewers in
RADEXT and DIME as well to take a look at this document.

Suresh who is editor of Localized routing for
PMIPv6 (draft-ietf-netext-pmip-lr) stated that the document is ready
for Working group last call.  Basavaraj said no review on document
till now.  Author and editor has it in their interest to have reviews
be done.  Basavaraj said he requires 3 reviews on document.  Carlos
said he will review it.  Jouni also will review it.

Basavaraj stated that with respect to Logical Interface support for
multi-mode IP hosts (draft-ietf-netext-logical-interface-support)
that issues are being captured in tracker. Basavaraj stated that the
authors are working through these issues.  In particular at least 6
issues were captured in the tracker on the document.  As soon as we
have resolution on them we can revise the draft and move forward.

Basavaraj stated that he was looking into updating the working group
milestones.  The chairs were considering dropping a couple of
milestones but then stated that he heard some views that we should
keep these milestones.  Basavaraj has not had a chance to update the
deadline for these milestones.  He noted that they are outdated and
he will need to update.
 
Next part of meeting is to discuss the two main topics of logical
interface and flow mobility.

Basavaraj stated that as far as flow mobility is concerned we are
charted for a work on flow mobility and had a lengthy discussion on
mailing list.  Issues had been raised but we have not converged on
solution on mailing list at least.  So we should use our face-to-face
meeting time now to come to conclusion on these issues.

Basavaraj said that we really need to make some forward progress on
the documents.  Basavaraj said that if we cannot reach common
agreement, we will seek WG consensus on proposed solutions for these
issues and decide accordingly.

Those are the two things we will focus on todays meeting.

3. Logical Interface Support for Multi-mode IP hosts
----------------------------------------------------

I-D: draft-ietf-netext-logical-interface-support
Presenter: Sri Gundavelli

Slide 2 - Open Issues summary
Slide 3  Issue 3  Behavior of ND 
- Receive from any/physical interface  WLAN0, Ethernet 0. Don¹t see
  technical issues with this text.
- Julian  Generic comment  don¹t have normative text. Need to
  describe black box operation. This is a requirements document; made a
  conscious decision to avoid IEEE shall/must wording.
- Julian  Insist on the use of requirements language. Logical
  interface mapping  link layer id is an issue.
- Issue is not with keywords. Is ad-hoc. Describe in terms of
  communications model.
- Doc handles those issues, specifies relationship between logical and
  physical interfaces.
- Interface drivers have send and receive vectors. Send out through
  the same path. Marking on some packets.
- As a reader, had trouble understanding what you are doing
  here. Should be clear to the reader. Have packet, gets replicated. How
  does DHCP work? 
  - Upper layers should not see a difference.
- Julian issue with multicast, duplication.
- Sri  agree we need to resolve
- Chair  Not specifying the implementation.
- Sri  specifying requiring logical interface.
- Chair  When have logical interface, how does it work? Some cases
  replicated, some not. This isn¹t clear today. Saying how it should
  behave, not how it should be done.
- Julian  Needs to be more detailed  sending and receiving
  algorithm, how it should work externally.
- Jari Arkko  Valuable to have such a description, more useful to
  describe what happens below the interfaces. One way to solve it, may
  be other ways too. Consider alternative implementation approaches.
- Speaker  ND behavior for logical interface  useful outside the
context? 
- Slide 4 - Issue  1, Link layer Id of the Logical Interface. What
  identifier do you project? Pick a random one? Can¹t do this in all
  cases  WiMax for example. Wi-Fi  no issue. Issue is what do we pick?
  Asking for WG guidance. In network environments, link layer identifier
- Speaker  can use VLAN ID, 802.1Qover WLAN.
- Sri  talking about the MAC address. Can change it typically. Want
  consistency between logical and physical interfaces. Pick one, or
  generate it. 
- Jari  This section is too hand-wavy, need more specifics. Case when
  no link identifier  still works, don¹t need to add one. If have link
  layer identifiers, used for a purpose, can¹t use a ransom
  identifier. How does it work with 2 WLANs, only works if both are
  settable. 
- Juan Carlos  Speaking as an author. Issue is on the WiMax side,
  last paragraph addresses this. Copy the WiMax address to the Wi-Fi
  side. Don¹t have virtual identifiers, they are valid values.
- Jari  Need discussion of secure discovery interaction.
- Sri  as long as use is consistent.
- Chair  Is there another way to choose?
- Sri  use across all interfaces when needed. Have an issue when
  logical interface breaks down.
- Julian  Trying to solve all cases in one pass. Pull them apart and
  document each one. The generic case doesn¹t fly.
- Slide 5  Issue 4  Point to Point Links
- Sri reviews issue.
- Julian  Interface appears as a link to the application. Why appear
  as a shared link when it is really a point-to-point link.
- Sri  Can stay silent on this.
- Alex  Application sees logical interface as a shared
  interface. Need to see as any other interface, Then difference is to
  be the default route.
- Sri  agree it needs to appear as any other interface.
- Alex  Implementing mobile Proxy IPv6 in Wi-Fi. Needs modification
  for 802.1Q  logical node in client/mobile node; Looking for point to
  point node in Wi-Fi.
- Sri  is on AP, for VLAN
- Juan-Carlos  Have been discussing this also. LAN  2 peers. Default
  Gateway  is this an issue to resolve?
- Julian  Reviewed proposed text. IOCTL on the AP. Realize a
  point-to-pint link at L2 is not defined here.
- Alex  trying to do something on Wi-Fi that hasn¹t been done.

Slide 6  not yet resolved
Slide 7  Issue 6  MTU considerations for the LI  have proposed text.
- Julian  What if it becomes smaller.
- Sri  can change MTU

Slide 8  Issue 7 UL/DL Packet Processing 
- Sri reviewed issue and proposed text.
- Jari  what are your assumptions on prefixes? How does it know that the
policy
- Sri  from the host perspective, general enough; may have multiple
prefixes. 
- Julian  have not agreed on prefix use.
- Chair  mark as unresolved and move on.

4. Proxy Mobile IPv6 Extensions to Support Flow Mobility
--------------------------------------------------------

   I-D: draft-bernardos-netext-pmipv6-flowmob-02
   - Summarize the discussion on the ML     Raj
   - Discussion of issues raised      

http://www.ietf.org/proceedings/80/slides/netext-2.pdf
http://www.ietf.org/proceedings/80/slides/netext-3.pptx

Presenter: Carlos Bernardos

Slide 2  Background and charter
Slide 3  Background and Draft History
Slide 4  Overview of the current solution
Slide 5  Overview of basic concepts

Slide 6  Issue 1  Lack of customers for the work; disagree- interest
      expressed on the mailing list

Slide 7  Issue 2  Policy consistency/coherence at LMA and NM  can
      have static pre-configuration or add mechanisms to endure dynamic
      consistency. 

Slide 8 Issue 3  Dependency on layer 2 signaling triggers. Note that
      Layer 2 triggers is not the same as layer 2 signaling.

Slide 9  Issue 4 - dynamic prefix management versus dynamic
      attachment of interfaces from sessions

Slide 10  Issue 5  Knowledge of mobile node¹s signal condition at the LMA

Discussion  
- Stefano  Commend authors on slides  very creative. Slide on policy
   slide 7. Real scenario today, device at enterprise, device purchased
  from service provider. Enterprise to tell SP how to configure LMA?
- Carlos  Have text for this. Also allow the MN to ignore the advice.
- Stefano  not a good design
- Carlos  see as a last resort; assume policies are thee and consistent.
- Stefano  If assumptions are not realistic, then designing something
  that is not realistic.
- Carlos  Disagree that this is not realistic.
- Rajiv  Policy is an overloaded term; how it¹s configured is
  irrelevant here. Use experience  far from that now. Mobile node knows
  conditions  agree. Haven¹t captured  LMA asking to move a
  flow. Mobile doesn¹t see the aggregate flow. Have scenarios from
  mobile and network perspectives. Ask ³can I move this flow for a
  certain number of seconds.² If MAC says ok, then can move the flow.
- Jari  Have policy assumptions  important. IETF view into this
  operation; at least do no harm. Potential issue to think about  what
  if the other end isn¹t doing flow mobility? What happens then? Need to
  be failsafe in those situations?
- Carlos  have text for this.
- Rajiv - There is a draft re: EAP-AKA, mobile device indicates its
  ability and willingness to accept dual mobility. LMA goes through AAA
  to get characteristics.
- Jari  Accept that. Might be other similar failure nodes.
- Julian  Slide 8 says no assumption of L2 signaling. Where is the
  baseline? Need layer 2 triggers. Think it is a kludge. Use l2
  signaling. EAP-AKA signaling there anyway. Mobile node should decide,
  it is the only one that knows.
- Carlos  Disagree. Current draft doesn¹t assume L2 signaling, may
  need to modify this. May be other ways  test/probe. Investigate
  further. 
- Rajiv  Need to be very clear of what you mean by L2
  signaling. EAP-AKA provides one such mechanism  document this. Assume
  there is authentication, a database to query.
- Jari  Don¹t think database is sufficient. Must either have no
  failure modes where packets get dropped, and know when you can do the
  additional mechanisms. Idea of having the mobile decide, and reflect
  that choice back to the network.
- Rajiv  Need to know how to know that the mobile node can support
  this. Agree that mobile node knows the conditions. Need to capture the
  network intentions also. Approach should be network friendly also.
- Chair  can¹t get data from a static profile, need to get from
  device in operation.
- Julian  can we agree that layer 2 signaling to indicate the
  capability and willingness of the mobile to do flow mobility?
- Jari  Mobile to network perspective, Mobile may need info about the
  network first. Network to mobile perspective  can both ask and
  test. Pretty much the design space.
- Sri  How is this assumption changing anything? Be clear about when
  and what assumptions are made.
- Chair  As Jari stated. Need to know that a logical interface is
implemented. 
- Rajiv  can be more than one way of knowing the mobile¹s willingness
  to support flow mobility, document at least one.
- Stephano  need to be consistency on the policy. Minute this.
- Chair  Flow mobility is what we are defining. How this gets
  indicated as part of policy is out of scope. How can the flows be
  moved, once there is policy.
- Stefano  asking to have it captured that the assumption is that
  there must be coherence between the policies. Capture as one of the
  assumptions for this draft.
- Chair  What do you mean
- If the LMA and MN want to do opposite operations, doesn¹t work.
- Sri  Consistency for the policy assumption.
- Speaker  Does this draft support moving a flow initiated from the
  MN and from the LMA? Yes. If MN  then that indicated support of
   flow. 
- Chair  resolution on unmutable prefix set assigned to MN at attach.
- Julian  Was on Stephano¹s slide. Also, can we agree that L2
  signaling is required? Proposed solution not genetic. No need to
  assign prefix on the fly.
- Rajiv  Either there is a single BCE on the LMA. Rely on AKA, have
  one session. Don¹t want to rule out other options. Combine capability
  of the MN to accept traffic from multiple prefixes.
- Julian  Different session cases; only need to describe one.
- Chair  on Logical interfaces  have proposed resolutions.
- Flow mobility document  getting closer, summarize issues resolved,
  work on remaining, then ask authors to produce a new draft, get WG
  consensus to adopt that draft.
- Meeting adjourned.

********************************************************

Agenda items: No time to discuss.

5. Bulk re-registration updates  5 Mins
   I-D: draft-ietf-netext-bulk-re-registration

6. Access Network Information Option for PMIP6  10 Mins
   I-D: draft-gundavelli-netext-access-network-option-00.txt
   Presenter: Sri Gundavelli

See http://www.ietf.org/proceedings/80/slides/netext-4.ppt

7. Policy Signaling for Multi-access Mobility  10 Mins
   I-D: draft-koodli-policy-multiaccess-mobility-00.txt
   Presenter: Rajeev Koodli

See http://www.ietf.org/proceedings/80/slides/netext-5.ppt

8. Prefix delegation for PMIPv6    7 mins
   I-D: draft-zhou-netext-pd-pmip-00.txt
   Presenter: Joy Zhou

See http://www.ietf.org/proceedings/80/slides/netext-6.pptx