Subject: Re: [Banana] Problem Statement: Bandwidth Aggregation for Internet Access (was RE: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt)

From: Margaret Cullen <[email-masked]>
Date: Thu, 22 Oct 2015 06:42:39 -0400

Hi Mingui,

On Oct 21, 2015, at 3:24 AM, Mingui Zhang <[email-masked]> wrote:
> Home users want their traffic to be split across different connections in a per-packet manner. [This is use case 1.]

I don't think that most home users are thinking in these terms.  In fact, I don't think that most home users know the difference between per-packet and per-flow demultiplexing.  I would state this more like:

Home users want faster and more reliable Internet service.  When they are paying for two (or more) connections, they would like the bandwidth of both connections to be used to their advantage.  They would like to realize this advantage for applications that use a single, long-lived, high bandwidth connection (such as video streaming), as well as for applications that use many shorter-lived connections (i.e. web browsing).
> 
> The per-packet load distribution may cause the out-of-sequence issue. [This is problem 1.]
> 
> Customers require the packets to be delivered in order. [This is a requirement.] 

By "Customers", are you talking about service providers or end-users?  Either way, I am not sure that "packets must be delivered in order" is a first order requirement.  I think the first order requirement would be something like "Customers would like the bandwidth of both connections to be used as efficiently as possible".  Packet ordering derives from that first-order requirement, because out-of-order packets cause retransmissions and delays, thus reducing the efficiency of bandwidth use.

Margaret

> 
> 
> 
>> -----Original Message-----
>> From: Alexandre Petrescu [mailto:[email-masked]]
>> Sent: Tuesday, October 20, 2015 9:23 PM
>> To: Sri Gundavelli (sgundave); Mingui Zhang; [email-masked];
>> [email-masked]; BOUCADAIR Mohamed IMT/OLN; [email-masked]
>> Cc: JACQUENET Christian IMT/OLN
>> Subject: Re: [Banana] Problem Statement: Bandwidth Aggregation for Internet
>> Access (was RE: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt)
>> 
>> 
>> 
>> Le 20/10/2015 08:51, Sri Gundavelli (sgundave) a écrit :
>>>> Start from the problem statement, we can design the protocols.
>>> 
>>> But, I do not see any new technical requirements in that spec. This is
>>> stating the obvious. Unfortunately, our starting point in all the
>>> discussions that I¹ve seen so far "appears" to be that we need to
>>> create a new protocol and a new working group. That¹s how I¹m reading
>>> it. But, looking at the technical consideration, I don¹t see any thing
>>> new.  The aspect of link aggregation for realizing a larger logical
>>> pipe, discussion around per-packet/per-flow/weighted per packet
>>> distribution or policy rules around path selection on a flow basic
>>> ..are all the topics that IETF had spent significant amount of time.
>>> Starting with the recent MPTCP, or the MIP work with RFC7629, RFC6088,
>>> RFC6089 Š have all investigated this problem.
>>> 
>>> What we are discussing is a system/solution requirement which is for
>>> the SDO¹s to define and state a protocol requirement, or gaps that
>>> IETF needs to address. BBF is not willing to make a request to IETF to
>>> work on any problem and so I wonder what are we solving ? I¹m not
>>> objecting to this approach, but I don¹t believe we will produce any
>>> thing useful to the community. It will be  just re-stating the
>>> existing work as a new requirement, and if it goes forward, we will
>>> invent a new protocol which will exactly look some other existing
>>> protocol, but won¹t be producing any thing valuable to the industry by any
>> measure.
>> 
>> So I guess we need to define that measure.
>> 
>> That measure could be a criterion which tells that applications are offered 2x
>> more bandwidth when 2 interfaces are used.  Ideally n more interfaces would
>> lead to n times more bandwidth.
>> 
>> And that should augment bandwidth for _any_ application (in the same manner
>> as Mobile IP offers mobility for any  application not just TCP).
>> 
>> And that could use an intermediary gateway.
>> 
>> But hey, these are requirements, not problem statement :-)
>> 
>> Alex
>> 
>> 
>>> 
>>> 
>>> Sri
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 10/19/15, 11:15 PM, "Banana on behalf of Mingui Zhang"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> I think the discussion on-going here leads to the following problem
>>>> statement draft which we just submitted. Start from the problem
>>>> statement, we can design the protocols.
>>>> 
>>>> Problem Statement: Bandwidth Aggregation for Internet Access
>>>> 
>>>> Abstract
>>>> 
>>>>   Bandwidth aggregation for Internet access can increase the access
>>>>   bandwidth and reliability. It has become a desirable network
>>>>   function, especially for those Service Providers who operates
>>>>   multiple heterogeneous networks.
>>>> 
>>>>   This document describes the issues with bandwidth aggregation for
>>>>   Internet access. The required network functions to be supported are
>>>>   specified. Several candidate solutions had been considered to support
>>>>   bandwidth aggregation for Internet access in IETF. These techniques
>>>>   are investigated.
>>>> 
>>>> https://tools.ietf.org/html/draft-zhang-banana-problem-statement-00
>>>> 
>>>> Questions? Comments?
>>>> 
>>>> Mingui
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mingui Zhang
>>>>> Sent: Monday, October 19, 2015 5:38 PM
>>>>> To: [email-masked]'; [email-masked]; BOUCADAIR
>>>>> Mohamed IMT/OLN; [email-masked]
>>>>> Cc: JACQUENET Christian IMT/OLN
>>>>> Subject: RE: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
>>>>> 
>>>>> Hi Pierrick,
>>>>> 
>>>>> The classification of the BBF work and IETF work is exact and helpful.
>>>>> I think we
>>>>> are having a promising common view.
>>>>> 
>>>>> Thanks,
>>>>> Mingui
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Banana [mailto:[email-masked]] On Behalf Of
>>>>>> [email-masked]
>>>>>> Sent: Monday, October 19, 2015 4:54 PM
>>>>>> To: [email-masked]; Mingui Zhang; BOUCADAIR Mohamed
>>>>> IMT/OLN;
>>>>>> [email-masked]
>>>>>> Cc: JACQUENET Christian IMT/OLN
>>>>>> Subject: Re: [Banana] I-D Action:
>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> No doubt that agreement on building blocks is a key step for a
>>>>>> common system design... I couldn't agree more... But, AFAIK, this
>>>>>> is currently discussed in BBF; why not starting from there (i.e.
>>>>>> leave system design to BBF and focus on protocols)?
>>>>>> 
>>>>>> BR,
>>>>>> Pierrick
>>>>>> 
>>>>>>> -----Message d'origine-----
>>>>>>> De : Banana [mailto:[email-masked]] De la part de
>>>>>>> [email-masked] Envoyé : lundi 19 octobre 2015 09:02 À :
>>>>>>> [email-masked]; BOUCADAIR Mohamed IMT/OLN;
>>>>>> [email-masked] Cc
>>>>>>> : JACQUENET Christian IMT/OLN Objet : Re: [Banana] I-D Action:
>>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> [Mingui] It sounds more and more interesting. That logic would be
>>>>>>>> an essential part for the bonding service arch. I think it's
>>>>>>>> worthwhile to agree on a common model where all those necessary
>>>>>>>> parts (load distribution,
>>>>>>> reordering, congestion control, etc) could be integrated into one
>>>>> system.
>>>>>>> I agree. As far as I recall during the Bar BoF in Prague we
>>>>>>> discussed that it would be a good approach to identify those
>>>>> "building
>>>>> blocks"
>>>>>>> which are common to the existing solutions. Having such a common
>>>>>>> model/architecture will probably help to identify the necessary
>>>>> parts.
>>>>>>> 
>>>>>>> 
>>>>>>>   Best regards
>>>>>>> 
>>>>>>>      Nic
>>>>>>> 
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Banana [mailto:[email-masked]] On Behalf Of
>>>>>>>> [email-masked]
>>>>>>>> Sent: Friday, October 16, 2015 2:44 PM
>>>>>>>> To: Mingui Zhang; [email-masked]
>>>>>>>> Cc: JACQUENET Christian IMT/OLN
>>>>>>>> Subject: Re: [Banana] I-D Action:
>>>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>> 
>>>>>>>> Hi Mingui,
>>>>>>>> 
>>>>>>>> Please see inline.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Med
>>>>>>>> 
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : Banana [mailto:[email-masked]] De la part de
>>>>>>>>> Mingui Zhang Envoyé : mercredi 14 octobre 2015 10:12 À :
>>>>>>>>> BOUCADAIR Mohamed IMT/OLN; [email-masked] Cc : JACQUENET
>>>>>>>>> Christian
>>>>>> IMT/OLN Objet : Re:
>>>>>>>>> [Banana] I-D Action: draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>>> 
>>>>>>>>> Hi Med,
>>>>>>>>> 
>>>>>>>>> Please see my responses inline below.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Mingui
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked]
>>>>>>>>>> [mailto:[email-masked]]
>>>>>>>>>> Sent: Tuesday, October 13, 2015 11:13 PM
>>>>>>>>>> To: Mingui Zhang; [email-masked]
>>>>>>>>>> Cc: JACQUENET Christian IMT/OLN
>>>>>>>>>> Subject: RE: I-D Action:
>>>>>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>>>> 
>>>>>>>>>> Hi Mingui,
>>>>>>>>>> 
>>>>>>>>>> Thank you for sharing the comments.
>>>>>>>>>> 
>>>>>>>>>> Please see inline.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Med
>>>>>>>>>> 
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : Mingui Zhang [mailto:[email-masked]] Envoyé :
>>>>>>>>>>> jeudi
>>>>>>>>>>> 24 septembre 2015 09:32 À : BOUCADAIR Mohamed IMT/OLN;
>>>>>>>>>> [email-masked] Cc
>>>>>>>>>>> : JACQUENET Christian IMT/OLN Objet : RE: I-D Action:
>>>>>>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>>>>> 
>>>>>>>>>>> Hi Med,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for the sharing.
>>>>>>>>>>> 
>>>>>>>>>>> The draft details the addressing issue which is definitely an
>>>>>>>>>>> important issue that falls in the problem space of the bonding
>>>>>>>>>>> service. In particular, the solution for NAT-pass-through
>>>>>>>>>>> issue is described. It assumes the tunneling techniques cannot
>>>>>>>>>>> support NAT-pass-through
>>>>> between the
>>>>> CPE and the Concentrator.
>>>>>>>>>>> This document addresses that issue. I guess this is the major
>>>>>>>>>>> motivation for
>>>>>>>>> proposing the
>>>>>>>>>> "plain" mode.
>>>>>>>>>> 
>>>>>>>>>> [Med] Yes. Other goals are get rid of the encapsulation
>>>>>>>>>> overhead and
>>>>>>>>> reuse the
>>>>>>>>>> same solution for UDP-based traffic. The plain mode allows to
>>>>>>>>>> easily
>>>>>>>>> reuse
>>>>>>>>>> service functions (e.g., DPI) that are deployed at the network
>>>>>>>>>> side
>>>>>>>>> without
>>>>>>>>>> requiring any update to those to support the encap scheme.
>>>>>>>>> 
>>>>>>>>> [Mingui] I guess this kind of reuse is feasible given that the
>>>>>>>>> end systems are changed a little bit: in
>>>>>>>>> draft-boucadair-mptcp-dhc-01, it reads
>>>>>>>>> 
>>>>>>>>>    "This document focuses on the explicit deployment
>>>>>>>>>    scheme where the identity of the MPTCP Concentrator(s) is
>>>>> explicitly
>>>>>>>>>    configured on connected hosts."
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> [Med] Yes.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Here, I would
>>>>>>>>>>> like to add another way to solve the same issue: the tunnel
>>>>>>>>>>> encapsulated packet can be wrapped with a UDP header, which
>>>>>>>>>>> forms a tunnel-over-UDP. By doing that, NAT-pass-through can
>>>>>>>>>>> be addressed as
>>>>>>>>> well.
>>>>>>>>>> 
>>>>>>>>>> [Med] That's another option, indeed. Beside the encapsulation
>>>>>>>>>> overhead,
>>>>>>>>> there
>>>>>>>>>> may be some side effects if intermediate functions are needed
>>>>>>>>>> to be
>>>>>>>>> invoked
>>>>>>>>>> (e.g., TCP acceleration engine).
>>>>>>>>> 
>>>>>>>>> [Mingui] Yes, there would be some gaps. If an intermediate
>>>>>>>>> function becomes clearly required, it need be integrated into
>>>>>>>>> the overlay
>>>>>> model.
>>>>>>>>> 
>>>>>>>>> The bonding service is sometimes regarded as a pure
>>>>>>>>> load-balance-among- multipaths use case so it's natural to have
>>>>>>>>> the idea of reusing MPTCP which is designed to handle this use
>>>>> case.
>>>>>>>>> However, I doubt the traditional load-balance-among-multipaths
>>>>>>>>> use case does not fully match the bonding service. MPTCP has to
>>>>> be
>>>>> adapted.
>>>>>>>>> 
>>>>>>>>> Customers of the bonding service would discriminate the
>>>>>>>>> heterogeneous connections. For example, the alternative
>>>>>>>>> connection would not be used unless the primary connection is
>>>>>>>>> saturated; some application types need be recognized by the
>>>>>>>>> bonding devices and be transported only on a primary connection;
>>>>>>>>> load generated by home users usually contains sparse
>>>>>>>>> applications types, therefore per-packet load distribution is
>>>>>>>>> required to achieve a fine-grained load distribution on the
>>>>>>>>> multiple
>>>>>>>> connections.
>>>>>>>>> There is no flow to be managed.
>>>>>>>>> 
>>>>>>>>> I agree the flow & congestion control functions developed in
>>>>>>>>> MPTCP could be reused in the bonding service architecture. The
>>>>>>>>> question is whether it's feasible to integrated those necessary
>>>>>>>>> functions _into_ the
>>>>>>>> tunnel?
>>>>>>>>> We've already seen that the Point-to-Point Tunneling Protocol
>>>>>>>>> (PPTP) [RFC2637] has integrated quite some of them, right?
>>>>>>>> 
>>>>>>>> [Med] I hear you. Several strategies to optimize the use of
>>>>>>>> multiple paths can be considered in addition to the ones that
>>>>>>>> were considered so far in
>>>>>>> MPTCP.
>>>>>>>> This is exactly the reason why I do think there is some value in
>>>>>>>> separating the load distribution logic from the actual transport
>>>>>>>> mechanism. This is particularly valid for the UDP case.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Traffic distribution issue is another important issue for the
>>>>>>>>>>> bonding service. This had ever been discussed on the list. I
>>>>>>>>>>> know MPTCP can well support flow based traffic
>>>>> distribution.
>>>>>>>>>>> However, I remember it was mentioned somewhere that MPTCP
>> can
>>>>>>>>>>> be adapted to support per-packet load sharing among the
>>>>> multipaths.
>>>>>>>>>>> Will this direction be
>>>>>>>>>> considered?
>>>>>>>>>> 
>>>>>>>>>> [Med] The per-packet distribution is not excluded by this
>>>>> draft.
>>>>>>>>>> We do
>>>>>>>>> think that
>>>>>>>>>> the load distribution logic can even be separated from the
>>>>>>>>>> actual
>>>>>>>>> mechanism
>>>>>>>>>> used to transport data over multiple paths, but I must admit
>>>>>>>>>> this is out
>>>>>>>>> of scope
>>>>>>>>>> of this draft.
>>>>>>>>> 
>>>>>>>>> [Mingui] Thanks for the clarification. For home users, the
>>>>>>>>> per-packet load distribution is desired so I hope it would be
>>>>>>>>> covered in some other drafts.
>>>>>>>> 
>>>>>>>> [Med] I do see interest too to have those aspects discussed in an
>>>>> I-D.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> A clarification questions: from Figure 1, it is clear that one
>>>>>>>>>>> peer of the MPTCP proxy will be deployed on the CPE.
>>>>>>>>>>> What is not clear to me is where the other end is to be
>>>>>>>>>>> deployed? Will the
>>>>>>>>>>> L4 capable Concentrator be deployed on physical routers or
>>>>> servers?
>>>>>>>>>> 
>>>>>>>>>> [Med] The concentrator can be on physical routers, dedicated
>>>>>>>>>> servers,
>>>>>>>>> etc. This
>>>>>>>>>> is really deployment-specific.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Mingui
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Banana [mailto:[email-masked]] On Behalf Of
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> Sent: Tuesday, September 22, 2015 3:55 PM
>>>>>>>>>>>> To: [email-masked]
>>>>>>>>>>>> Cc: JACQUENET Christian IMT/OLN
>>>>>>>>>>>> Subject: [Banana] TR: I-D Action:
>>>>>>>>>>>> draft-boucadair-mptcp-plain-mode-
>>>>>>>>>>> 00.txt
>>>>>>>>>>>> 
>>>>>>>>>>>> Dear all,
>>>>>>>>>>>> 
>>>>>>>>>>>> We submitted this I-D to discuss a proposal that aims to get
>>>>>>>>>>>> rid of the encapsulation when aggregating multiple network
>>>>>> attachments.
>>>>>>>>>>>> 
>>>>>>>>>>>> Comments are more than welcome.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Med
>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Message d'origine----- De : I-D-Announce
>>>>>>>>>>>>> [mailto:[email-masked]] De la part de
>>>>>>>>>>>>> [email-masked] Envoyé : lundi 21 septembre
>>>>>>>>>>>>> 2015
>>>>>>>>> 15:31
>>>>>>>>>> À :
>>>>>>>>>>>>> [email-masked] Objet : I-D Action:
>>>>>>>>>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>>>>>>> Internet-Drafts directories.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         Title           : An MPTCP Option for
>>>>>> Network-Assisted
>>>>>>>>>> MPTCP
>>>>>>>>>>>>> Deployments: Plain Transport Mode
>>>>>>>>>>>>>         Authors         : Mohamed Boucadair
>>>>>>>>>>>>>                           Christian Jacquenet
>>>>>>>>>>>>> 	Filename        :
>>>>> draft-boucadair-mptcp-plain-mode-00.txt
>>>>>>>>>>>>> 	Pages           : 12
>>>>>>>>>>>>> 	Date            : 2015-09-21
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Abstract:
>>>>>>>>>>>>>    One of the promising deployment scenarios for Multipath
>>>>>>>>>>>>> TCP
>>>>>>>>>> (MPTCP)
>>>>>>>>>>>>>    is to enable a Customer Premises Equipment (CPE) that is
>>>>>>>>>>>>> connected
>>>>>>>>>>> to
>>>>>>>>>>>>>    multiple networks (e.g., DSL, LTE, WLAN) to optimize the
>>>>>>>>>>>>> usage of
>>>>>>>>>>> its
>>>>>>>>>>>>>    network attachments.  Because of the lack of MPTCP
>>>>>>>>>>>>> support at
>>>>>>>>> the
>>>>>>>>>>>>>    server side, some service providers now consider a
>>>>>>>>>>>>> "network-
>>>>>>>>>>> assisted
>>>>>>>>>>>>>    mode" that relies upon the activation of a dedicated
>>>>>>>>>>>>> function
>>>>>>>>>>> called
>>>>>>>>>>>>>    MPTCP Concentrator.  This document focuses on a
>>>>>>>>>>>>> deployment
>>>>>>>>>> scheme
>>>>>>>>>>>>>    where the identity of the MPTCP Concentrator(s) is
>>>>> explicitly
>>>>>>>>>>>>>    configured on connected hosts.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>    This document specifies an MPTCP option that is used to
>>>>>>>>>>>>> get rid of
>>>>>>>>>>> an
>>>>>>>>>>>>>    encapsulation scheme between the CPE and the MPTCP
>>>>>>>>>> Concentrator.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-p
>>>>>>>>>>>>> lain
>>>>>>>>>>>>> -m
>>>>>>>>>>>>> ode/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There's also a htmlized version available at:
>>>>>>>>>>>>> https://tools.ietf.org/html/draft-boucadair-mptcp-plain-
>>>>>>>>>>>>> mode
>>>>>>>>>>>>> -0
>>>>>>>>>>>>> 0
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please note that it may take a couple of minutes from the
>>>>>>>>>>>>> time of submission until the htmlized version and diff are
>>>>>>>>>>>>> available at tools.ietf.org.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> I-D-Announce mailing list [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>>>>>> Internet-Draft directories:
>>>>>>>>>>>>> http://www.ietf.org/shadow.html or
>>>>>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Banana mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Banana mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Banana mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Banana mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Banana mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>>>> 
>>>>>> 
>>>>> 
>> ________________________________________________________________
>>>>>> _________________________________________________________
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Banana mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/banana
>>>> 
>>>> _______________________________________________
>>>> Banana mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/banana
>>> 
>>> _______________________________________________
>>> Banana mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/banana
>>> 
> 
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana