[netext] IETF85: Netext WG meeting minutes

[Basavaraj Patil <[e-mail]>]

Network-Based Mobility Extensions WG meeting at IETF85 (Atlanta, USA)

Monday, November 5th, 2012
1520-1720 Afternoon Session II

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

These meeting minutes are courtesy of:
1. Byju Pularikkal (byjupg at cisco.com)
2. Carl Williams (carlw at mcsr-labs.org)

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

The meeting was chaired by Basavaraj Patil.
Rajeev Koodli was unable to attend because of a travel conflict.

1. WG Status update

- Two documents published as RFC 6705 & 6757

- SIPTO option-7: AD review

- RFC5149 bis LC completed

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

2. Logical Interface Support for multi-mode IP Hosts
   I-D: draft-ietf-netext-logical-interface-support-06    Sri Gundavelli

Update by Sri on Logical interface support:

Key issues covered:

What is logical interface (Sri explained). To support many Hand off
scenaios we specify 5213. When hand off happens we need to make sure
that host does not se any change as far as IP stack is concerned, We
do not want application to detect any connectivity lost.


Julien: Comment from: Why do u need link identifier on the
original interface? When you have a loop back interface and assign the
IP to it then it should essentially provide . Virtual interface
identifier may not be required when loop back interface is in use.

Sri: From network signaling we always identify the interface using
some interface identifier.

Julien: How is this going to work for IPv4 where there is no link layer
identifier.

Sri: How does the network identify the attachment point with out
virtual t link layer identifier

Sri: You are looking at more as a interconnect between physical
interface and routing. In some access systems we can say that virtual
interface identifier can just map to the physical map.

Conclusion: Virtual interface does not need LLID, physical interface may or
may not have.

Kent: What is the rationale behind LLID, it is not just for pure forwarding

The intention to have a single LLID across several interfaces is it
feasible or not? But also PMIP needs a LLID at least for WiFi and
WiMAX interfaces

Julien: If you have different LLIDs on physical interfaces and some
does not you can always build a system which will work. I don't see
the requirement for virtual LLID

Pete McCann's comment regarding multiple provisioning domains. How
does logical interface deal with it. Sri's explanation,  It will
essentially be a single provisioning domain. Logical interface will
only be applicable to single provisioning domain.

Chairs comment, text too implementation specific: Sri commented this
issue will be addressed.

Juan: It is time to move this document along. got quite a good amount of
feedback.

Raj: <Chairs comment> Fail to understand what is it trying to accomplish.

Sri: A working system has been shown matches what ever proposed.

6> Clarity of the draft

Kostas: Why don't we do a quick editorial round on the document? Why
don't we move the implementation specific aspects into an Appendix?

Brian: One of the things that people push back is, what u describe is
mandatory for interop with another device then completely required to
put in the text; If not, put in appendix.

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

3. Proxy Mobile IPv6 Extensions to Support Flow Mobility
   I-D: draft-ietf-netext-pmipv6-flowmob  CJ Bernardos

- Detailed reviews received from Marcos and Juan

- Draft is ready for WGLC


(1) Comments: Section 3.2.1 has nothing normative. Why do u have that
section. How does prefix delegation affect flow mobility? May be move
that section to appendix or completely remove

RFC 5648 & RFC 6089 comments. Multiple Proxy CoA registration, taking
it to extremes on this. How are we going to use 5648 and 6089 in PMIP?


Raj: Significant progress has been made on this document but just
needs some couple of more reviews. Kent has agreed to review . Only
concern with the draft is linking with the logical interface.


Sri: Are we replicating all the FMI options? Not really replacing
PBU-PBA concept.

Depends up on the scenario, one one case PBU/PBA is used in other
SMI/SMA.

Raj also recommended that a issue tracker be setup for this I-D to
close open issues and progress the draft to WG last call.

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

4. Prefix Delegation for Proxy Mobile IPv6
   I-D: draft-ietf-netext-pd-pmip  Carl Williams

- Authors addressed all the issues. Document is ready for IESG revew:

Alex: Read the updated draft. Some more modification discussions going
on and will raise them on the list.

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

5. Quality of Service Option for Proxy Mobile IPv6
   I-D:draft-ietf-netext-pmip6-qos             Marco Liebsch

Progress:
- Initial draft presented at IETF 82

- Version 1 addresses comments about interpretation of QoS policies.

Kent: Are u speccing non-3GPP access networks as well? Looks like
taking a specific reference for a generic model.
So far it is covered.

Sri: Application function can notify LMA about a new flow and then can
signal QoS. MAg after detecting a new flow can do a PBU/PBA and can
get the QoS signaling info.

There is another way of loading QoS on MAG. S-9 with non-3GPP
access. What is the relationship between that Qos and one in the
draft?

Inband signaling such as described here may be an easy way to implement QoS

There are some updated RFCs is with guidelines about semantics on the DSCP
values

Raj: Really need some reviews and feedback on this document

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

6. Update Notifications for Proxy Mobile IPv6
   I-D: draft-krishnan-netext-update-notifications-01 Suresh Krishnan

Taken care of all the open comments officially requesting the chair to
adopt.

Six or seven people in the room have read the draft.

Kent: Does it allow LMA to send some generic signaling or even some
specific signaling messages?

This is pretty much a notification with reason code and mobility
options. This is more of a framework and we can add semantics later

- LMA to MAG messaging we need some kind of standardization

Kent:  Make sure: Don't duplicate what ever is out there

- 11 people in favor of adopting the document…

- Draft is pretty simple. Accept the review from x number of people
  and then move this forward

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

7. Network Mobility Support using Mobile MAG in PMIP6 domain
   I-D: draft-sijeon-netext-mmag-pmip-00.txt            Seil Jeon

Ahmad:: Is that mMAG just a mobile node? And what is the security
requirement to send the binding update to LMA?

- mMAG is registered with the LMA. mMAG is not seen as mobile node. MAG
  is attached to a fixed MAG.

- mMAG can be considered as a dual entry, Mobile node from fixed MAG
  perspective, and MAG for the mobile nodes connected to mMAG

- What is the difference between this and the mobile node acting as a router

Raj: tends to disagree with the concept of mMAG

Raj: Have a discussion on this document in the working group mailing
list

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

8. MN Status Option for Proxy Mobile IPv6
   I-D: draft-tu-netext-mn-status-option-02  Yangwei Tu

Raj: There are questions about the problem statement itself. We should
discuss whether it is a solution for a problem worth solving

Sri: There is work related to Opcon and othe notifying the radio
congestion to the LMA. MAG is typically not on the access
point. Definitely there is merit in notifying it but don't know how
MAG will know those characteristics

Carlos: LMA can benefit from having additional info from the MAG. Not
only about radio conditions, it is just one of the capabilities. This
is an important issue to address

Raj: Idea is to convey more decisions to LMA , not talking about flow
mobility. Some concerns, who knows about the status of the mobile
node, idle or active etc

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

9. Mapping PMIP Quality of Service in WiFi Network
   I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01     J. Kaipallimalli

- Based up on the comments on version 00 some updates have been made to 01.


Kent: Traffic filters based on IP layer.At AP layer it will be mac
based, how do u address overlapping IP address support?

Raj: Will request additional reviews of the I-D and encourage more
discussion on the list.

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

10. Seamless Handover for Multiple-Access Mobile Node in PMIPv6
    I-D: draft-cui-netext-pmipv6-shpmipv6        Y. Chen

Time ran out and hence this I-D was not discussed at the meeting.

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

Summary and Next steps:

- Three documents will go to LC before the next IETF meeting.

1. pd-pmip
2. logical-interface - to be decided whether ready for last call
3. flow-mobility

Strong consensus to adapt Suresh's draft. Will follow up on the
mailing list.


-- 
Basavaraj Patil