Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

"Ali C. Begen (abegen)" <abegen@cisco.com> Mon, 22 April 2013 06:11 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B90C21F8B16 for <avt@ietfa.amsl.com>; Sun, 21 Apr 2013 23:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 VwjxdWkVx8qE for <avt@ietfa.amsl.com>; Sun, 21 Apr 2013 23:11:41 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 647DC21F8ADC for <avt@ietf.org>; Sun, 21 Apr 2013 23:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8322; q=dns/txt; s=iport; t=1366611101; x=1367820701; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XXfPn9UFXH1rROaCqt82Ex5yy1tuXSZHxGjpNv7yJYg=; b=dMeVPmpYtxyUmfqa9Ni3COeFTbArJXZvZV0OSbYDKvhJVHA1JCwhYxAz asxjTLTxKzIpoRl7BMyUsMG3LUl2Lxs0iYVCOs81OV0v+n5jVYxNb6EzT RC0D0+T3hhgTuDAbaKccoEF11dsQU+InfR2bSBI2ymCAs4vH8wm1MWVAi o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0FANDTdFGtJV2a/2dsb2JhbABPgmUhNkSCE1q9Tw12FnSCHwEBAQQBAQEJFxFFDAIEAQYCEQMBAgECAgYdAwIEGQwLFAEICAIEDgUIAYgLAQYFjjebB5FqBIEfjWsWGwcGgi4yYQOYOI93gwyCKA
X-IronPort-AV: E=Sophos;i="4.87,524,1363132800"; d="scan'208";a="201169645"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 22 Apr 2013 06:11:40 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3M6BeG3016471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 06:11:40 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 01:11:40 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt
Thread-Index: AQHOODKPqSyveEg+S0yJ9MQm6MP6c5jUfWGAgALkiQCAC1jhAA==
Date: Mon, 22 Apr 2013 06:11:39 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940D00BCE3@xmb-aln-x01.cisco.com>
In-Reply-To: <516BCE60.6050707@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.21.148.112]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D128F822BCCA6642BB91273A9B0FC3BB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2013 06:11:44 -0000

Hi Magnus,

I am not that knowledgeable about how the virtualization products deal
with their networking interfaces. While I am not comfortable to make a
generalization and somewhat blame such products for improper selection of
mac addresses, what about the following change?

After the following bullet in section 4.2:

To produce a short-term persistent RTCP CNAME, an RTP endpoint
      MUST either (a) use the numeric representation of the layer-2
      (Media Access Control (MAC)) address of the interface that is used
      to initiate the initial set of RTP sessions as the "host" part of
      its RTCP CNAME or (b) generate and use an identifier by following
      the procedure described in Section 5.  In either case, the
      procedure is performed once per initialization of the software.
      After obtaining an identifier in case of (a), the 48 bits are
      converted to the standard colon-separated hexadecimal format
      [RFC5342], e.g., "00:23:32:af:9b:aa", resulting in a 17-octet
      printable string representation.  In case of (b), minimally the
      least significant 96 bits SHOULD be converted to ASCII using
      Base64 encoding [RFC4648] (to compromise between packet size and
      uniqueness - refer to Section 6.1).  If 96 bits are used, the
      resulting string will be 16 octets.


Add the following text?

"In some environments (for example, a virtualized operating system), the
MAC address may not be unique as expected. In these cases, using option
(b) above is RECOMMENDED."

-acbegen


-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Monday, April 15, 2013 6:54 PM
To: "Ali C. Begen" <abegen@cisco.com>
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

>Hi,
>(as individual)
>
>
>I realize one part of my first issue was the question of how commonly
>MAC addresses are going to be having the intended uniqueness properties.
>This got a bit lost dealing with the equally important aspect that you
>need to keep the one you have generated across any mobility event etc.
>
>The comment from Steve Underwood, do raise this as being a genuine issue
>in some cases. What I believe would be good, is to make it clear that an
>implementation may have issues with using MAC address in certain types
>of environments, like virtulazation. I think the simple fix is to press
>that using a stored random value might have better properties.
>
>Cheers
>
>Magnus
>
>
>
>
>On 2013-04-13 12:44, Ali C. Begen (abegen) wrote:
>> I think we got all the essential WGLC comments addressed in this
>>revision.
>> If there is something we skipped, please let us know.
>> 
>> -acbegen
>> 
>> -----Original Message-----
>> From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>> Date: Saturday, April 13, 2013 1:34 PM
>> To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
>> Cc: "avt@ietf.org" <avt@ietf.org>
>> Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt
>> 
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Audio/Video Transport Core Maintenance
>>> Working Group of the IETF.
>>>
>>> 	Title           : Guidelines for Choosing RTP Control Protocol (RTCP)
>>> Canonical Names (CNAMEs)
>>> 	Author(s)       : Ali Begen
>>>                          Colin Perkins
>>>                          Dan Wing
>>>                          Eric Rescorla
>>> 	Filename        : draft-ietf-avtcore-6222bis-02.txt
>>> 	Pages           : 10
>>> 	Date            : 2013-04-13
>>>
>>> Abstract:
>>>   The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
>>>   persistent transport-level identifier for an RTP endpoint.  While the
>>>   Synchronization Source (SSRC) identifier of an RTP endpoint may
>>>   change if a collision is detected or when the RTP application is
>>>   restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
>>>   endpoints can be uniquely identified and associated with their RTP
>>>   media streams.
>>>
>>>   For proper functionality, RTCP CNAMEs should be unique within the
>>>   participants of an RTP session.  However, the existing guidelines for
>>>   choosing the RTCP CNAME provided in the RTP standard are insufficient
>>>   to achieve this uniqueness.  RFC 6222 was published to update those
>>>   guidelines to allow endpoints to choose unique RTCP CNAMEs.
>>>   Unfortunately, later investigations showed that some parts of the new
>>>   algorithms were unnecessarily complicated and/or ineffective.  This
>>>   document addresses these concerns and replaces RFC 6222.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-02
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>> 
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>> 
>
>
>-- 
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
>
>