Re: [mif] Follow up with BBF proposal

[<[e-mail]>]

Hi Alex,

Actually, IMHO, BBF and NEMO use-cases have similar requirements. In “Hybrid Access for Broadband Networks” (quoting the BBF liaison), the CPE is attached to multiple access networks (e.g. DSL, LTE); and the terminal is connected to the CPE via a single interface (i.e. ingress interface), e.g. Wi-Fi . The problem is to distribute the traffic on the different access networks, but we do not touch the terminal; and there should be no specific requirement on the home network. Traffic distribution schemes can be done either on a packet basis or on an IP flow basis, which is typically an IP flow mobility use-case. So, IMU, the "hybrid access" use-case  is a multihomed mobile router scenario, as described in RFC 4980.

Anyway, as you said, it is worth to remind that a lot of work has been done in the past, regarding IP flow management, of course, but even with respect to the BBF use-case: RFC 4908 (Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO)).

BR,
Pierrick

>-----Message d'origine-----
>De : mif [mailto:[e-mail]] De la part de Alexandru Petrescu
>Envoyé : mardi 11 novembre 2014 07:20
>À : Alper Yegin; Hui Deng
>Cc : 'Brian Haberman'; [e-mail]
>Objet : Re: [mif] Follow up with BBF proposal
>
>Le 11/11/2014 04:59, Alper Yegin a écrit :
>> Sure.
>>
>> I was just reacting to the assumption that anything that mentions 2
>> interfaces automatically falls under the MIF scope :-) Also, before
>> this work gets on a long journey thru the IETF system, people should
>> be aware that Mobile IP WGs did a lot of work for this space and have
>> solutions.
>
>Sure, but here the reqs are different.
>
>Actually I'd go as far as to say that MIP WG did in the past a lot of work without
>requirements, including the flow-based management schemes.
>
>Alex
>
>
>>
>> FYI.
>>
>> Alper
>>
>>
>>
>>
>>
>>
>> On Nov 11, 2014, at 5:52 AM, Hui Deng wrote:
>>
>>> Hi Alper,
>>> This work hasn’t been clarified where it should belong to, presenting
>>> in MIF doesn’t prevent going to any other working group.
>>> Let’s focus on the problem and gap analysis other than where is the
>>> place to discuss it.
>>> Thanks
>>> -Hui
>>> *From:*mif [mailto:[e-mail]]*On Behalf Of*Alper Yegin
>>> *Sent:*Monday, November 10, 2014 5:46 PM *To:*Xueli *Cc:*Brian
>>> Haberman; [e-mail] <mailto:[e-mail]>
>>> *Subject:*Re: [mif] Follow up with BBF proposal Hi Xueli, That's one
>>> of the general statements in the charter. And it covers so many
>>> areas, obviously MIF is not chartered to deal with.
>>> For example, discovery of networks, selection of networks,
>>> authentication, accounting, host configuration, traffic management,
>>> mobility, etc. etc.
>>> The statements I pulled form the charter pin-points the exact scope
>>> of MIF. Anything else is outside the scope, currently.
>>> Alper
>>> On Nov 11, 2014, at 5:20 AM, Xueli wrote:
>>>
>>>
>>> Hello
>>> The MIF charter says like:
>>> */"/**/The purpose of the MIF working group is to describe the
>>> architecture detailing how devices attach to and operate in multiple
>>> networks."
>>> /*I think my presentation cleanly fits this statement...
>>> Best Regards
>>> XUELI
>>> *发件人:*mif [mailto:[e-mail]]*代表*Alper Yegin
>>> *发送时间:*2014年11月11日10:45
>>> *收件人:*Sri Gundavelli
>>> *抄送:*Brian Haberman;[e-mail] <mailto:[e-mail]>
>>> *主题:*Re: [mif] Follow up with BBF proposal MIF focuses on the
>>> following issues, and the issue BBF is bringing up is a totally
>>> separate issue.
>>> It's about how two links can be aggregated for capacity and
>>> reliability boost.
>>> So, I agree with Sri that this is not a MIF WG issue.
>>> The MIF problem statement document [RFC6418
>>> <https://tools.ietf.org/html/rfc6418>] enumerates the problems into 3
>>> categories:
>>>   1. Lack of consistent and distinctive management of configuration
>>> elements, associated with different networks.
>>>   2. Inappropriate mixed use of configuration elements, associated
>>> with different networks, in the course of a particular network
>>> activity / connection.
>>>   3. Use of a particular network, not consistent with the intent of
>>> the scenario / involved parties, leading to connectivity failure and
>>> / or other undesired consequences.
>>> Alper
>>> On Nov 11, 2014, at 3:08 AM, Sri Gundavelli (sgundave) wrote:
>>>
>>>
>>>
>>> Hi Hui,
>>> The BBF requirement as presented in the BBF documents and as
>>> interpreted in draft-seite and draft-lhwxz is about enabling a CPE
>>> device to attach to multiple access network and perform flow
>>> management. However, I look at it, I see this this is a mobility
>>> requirement and is really not in the scope of MIF WG. The BBF
>>> requirement in question is all about flow switching or flow splitting
>>> across access systems. I'm not sure why this work belongs MIF and not
>>> DMM which is chartered to handle all mobility use-cases. We have
>>> discussed this specific use-case of flow splitting during MIF
>>> formation and explicitly disallowed MIF WG from taking up such work.
>>> The following is the quote from the MIF chartered text. Also, the MIF
>>> WG was primarily looking at issues for a host attached to multiple
>>> access networks, but the hybrid access is about a CPE attached to
>>> multiple networks. I really think this work should be done in DMM and
>>> we did present the requirements in the last IETF meeting.
>>> *http://datatracker.ietf.org/wg/mif/charter/*
>>> *No work will be done to enable traffic flows to move from one
>>> interface to another. The group recognizes existing work on
>>> mechanisms that require peer or network support for moving traffic
>>> flows such as RFC 5206, RFC 4980 and the use of multiple care-of
>>> addresses in Mobile IPv6. This group does not work on or impact such
>>> mechanisms. Future work in this area requires rechartering the
>>> working group or asking other, specialized working groups (such as
>>> DHC or 6MAN) to deal with specific issues.* Regards Sri *From:*Hui
>>> Deng <[e-mail] <mailto:[e-mail]>>
>>> *Date:*Friday, October 31, 2014 4:50 AM *To:*Sri Gundavelli
>>> <[e-mail] <mailto:[e-mail]>>, 'Xueli'
>>> <[e-mail] <mailto:[e-mail]>>,
>>> "[e-mail] <mailto:[e-mail]>"
>>> <[e-mail] <mailto:[e-mail]>>, 'Ted
>>> Lemon' <[e-mail]
><mailto:[e-mail]>>,
>>> "'STARK, BARBARA H'" <[e-mail] <mailto:[e-mail]>>,
>>> 'Alexandru Petrescu' <[e-mail]
>>> <mailto:[e-mail]>>
>>> *Cc:*"[e-mail] <mailto:[e-mail]>" <[e-mail]
>>> <mailto:[e-mail]>> *Subject:*Follow up with BBF proposal Hi
>>> everybody I am recommending that Xue Li could help to put down the
>>> slide for the problem statement from BBF.
>>> And MIP/NEMO proponents (Pierrick, Alex, Sri) and Xue Li could kindly
>>> to meet together during IETF meeting to discuss by adding s thelide
>>> about how today solutions meet the requirement or there are some gap
>>> still, and whether that problem should be solvable in IETF.
>>> Chairs will talk with AD whether MIF or somewhere else will consider
>>> to discuss those issues during the f2f session.
>>> Best regards,
>>> -Hui
>>> _______________________________________________
>>> mif mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mif
>>>
>>
>>
>>
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
>>
>
>
>_______________________________________________
>mif mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mif

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.