Re: [multrans] [MBONED] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Fri, 16 December 2011 21:09 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9B021F8A7E; Fri, 16 Dec 2011 13:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALaE7r-vlKx6; Fri, 16 Dec 2011 13:09:33 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE69621F8A71; Fri, 16 Dec 2011 13:09:31 -0800 (PST)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBGL9cY2022061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2011 15:09:41 -0600 (CST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBGL9IYc020719; Fri, 16 Dec 2011 13:09:18 -0800 (PST)
Received: from XCH-MWHT-04.mw.nos.boeing.com (xch-mwht-04.mw.nos.boeing.com [134.57.113.164]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBGL9H1r020698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 16 Dec 2011 13:09:17 -0800 (PST)
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-04.mw.nos.boeing.com ([134.57.113.164]) with mapi; Fri, 16 Dec 2011 15:09:16 -0600
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: "Cathy Zhou(Qian)" <cathy.zhou@huawei.com>, "multrans@ietf.org" <multrans@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Date: Fri, 16 Dec 2011 15:09:15 -0600
Thread-Topic: [MBONED] [multrans] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting
Thread-Index: Acy7xRu42eaFbqKLQxOkBaNs0wVlAgAcTe2g
Message-ID: <B0147C3DD45E42478038FC347CCB65FE02B3445BEF@XCH-MW-08V.mw.nos.boeing.com>
References: <A6A061BEE5DDC94A9692D9D81AF776DF0AB265EF@szxeml527-mbx.china.huawei.com>
In-Reply-To: <A6A061BEE5DDC94A9692D9D81AF776DF0AB265EF@szxeml527-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B0147C3DD45E42478038FC347CCB65FE02B3445BEFXCHMW08Vmwnos_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 16 Dec 2011 13:41:41 -0800
Subject: Re: [multrans] [MBONED] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>, <mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2011 21:09:35 -0000

I'm all in favor of this sort of approach. In fact, it's something I've been expecting to have to implement in our systems, even without an RFC to describe the process. Much like was the case with RFC 4605, where we had already been doing IGMP proxying, to solve a specific problem we encountered (in our case, it had to do with security requirements).

Bert

From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf Of Cathy Zhou(Qian)
Sent: Friday, December 16, 2011 2:34 AM
To: multrans@ietf.org; mboned@ietf.org
Subject: [MBONED] [multrans] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting


Dear all,

Here is a new draft to work from for the 4th item " Specification of an adaptation function between the receiver and the network" of the interim meeting.

http://tools.ietf.org/html/draft-zhou-multrans-af1-specification-00





Abstract:

   Discussion of the problem of multicast transition has brought out a

   number of scenarios that are the most likely to be encountered in

   practice.  In some of these scenarios the IP version supported by the

   multicast receiver differs from that supported by the provider

   network to which it is attached.  In such cases an adaptation

   function is required between the receiver and the network, to mediate

   the signalling and data flows between them.  This memo uses the term

   &quot;Type 1 Adaptation Function&quot; (AF1) for such a function.  It is

   written for the purpose of specifying the functions performed by an

   AF1.



   The scope of this memo is limited to the case where flows are

   unidirectional, from a designated set of sources to a designated (and

   normally much more numerous) set of receivers.  The IP television

   (IPTV) case falls within this scope.

Comments are welcome.

Best Regards,
Cathy ZHOU & Tom Taylor