Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis

Eric C Rosen <erosen@juniper.net> Wed, 03 May 2017 18:25 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA52129A99; Wed, 3 May 2017 11:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgsNl2nNMKz2; Wed, 3 May 2017 11:25:11 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0123.outbound.protection.outlook.com [104.47.38.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10694129B19; Wed, 3 May 2017 11:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XXWT07Ujb5SmCeZlzejM2LfDp0ldfuboDxD0pdiybkk=; b=WpEbxVLS1hWNtm2AhGlJR3EraWecpfeybVxYUmPOBX5pAsBzu8BVH5a0mV6YAo8GdQuahmwCe4qoUSPauAH0A43pPX03RCXd43AtmTI3Y5TKxT3De+tn87tZYn4XKjUogZAv33HAOxTPVyb1G4akOVT/DFtZeHPJL5csOWka7Z0=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.35.213] (66.129.241.14) by BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 18:23:07 +0000
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "draft-ietf-mpls-rfc3107bis@ietf.org" <draft-ietf-mpls-rfc3107bis@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
References: <BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100@BY2PR0201MB1910.namprd02.prod.outlook.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net>
Date: Wed, 03 May 2017 14:23:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100@BY2PR0201MB1910.namprd02.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B904B5417489A850A8D161CD"
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BN6PR1301CA0021.namprd13.prod.outlook.com (10.174.84.162) To BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7a60a971-f7d5-4636-ea42-08d4925172f0
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2184;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 3:fq0dx/bnVtlnzVUATiiGIUCkA43jXrXmQAib/C1+r5nDI/DdKTsUQiaEvLLu31wS+rJk5uiZjzjblnF4Eg24Qmnr6GV/PnjmoppBGM0AzedTjmG2CIpxSFgyNQTenNC/a6kb7P9GcuKve7IWBsDjaP+WhXk4zDnjNs7BVOn5fLXsZe7ueMVH8cX3c8JnQb25Gj+wASBy40pDzwdFViD3TR2ztDM+6sGmOq5Ng6GrJZtLC2JgiuO1j/bhLWE+ZtKfTnMhd25+P+6rCVEAWnldnmuA3zvzUob+gyema1f45OuPmEw6THda1H4oD95gIzbuhPk+kDHTSdV6i180MJtzNL0ESSoxZ9iQSIj6t+ygNAM=; 25:OJg7arre2Okrla7YCrl7yAHPVZXV9MUBisxwm2NxiSrMYRVgZQKAqGMsnsZw7cW6pjo+0laNXSV4G7dLgkO9EPAgoa8e9cBcKDcCS/l24HHn24dGRgxjecG8HI1y0oRx1hmPhuQW4eYYrSFOvn3aicn0b9FdQwUkLSwl+waGLL9YxKx0U0Nive/1NP0gPHvz/wQmib0ZlgkLOCAFvTj/epN0ITXsCckvAJpkSA9WvsZJCVn6P5H5g9AzBjmE8l07KI/6X2ihQcj4CmbNoZqcVeC5VEoqpjLj0QRK0jntH0qvGXLBlPHOFqJZ2C8RWw2u3FJmc4Lds1j+NRg2D4boddo5EbBnXza6DiK2cT0xEKOe+7+p2XcwoH4dclZMRGgAbQCV2DD45jYoQd8IQsJXdRGI+ffGHPLVItcnBZ5v61jE5WDIsEA2r3pTKlHImoMmD83foc/QDC3X7rz0iZBw+sMR9+aQkHrIjC1xk734I9E=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 31:3c73c+V0g7UON6/yCApXBHIeKLjOxt219feva56q8XQj6YzRyi7vr8RikyvfnBx5+z1l/f8Se+f7FCsgrJvQnomqxXRQSTrDPOYQVacON+d+nIc68BCiOpCzJB0Ns+LbdVA03hYcwJMJh7rAXQ99qDEwL9T9fh9tSH0Nig4MmjzJAaKEGxHcxxYHB/qrL+tyd2nmmerBfRYvAdSGrX1UT+575Ba+e1eqIy/Xx+QPEFs=; 20:6WtVyx8A6tqaMdU6PBSkWpGO58j1eeq9ptuZ42MfQfS+WwmpWoNJiXC+tn/AYV9jifVEkjZffcoT7JYGRZIpadNInwxEnofh8LApxwvUy8WeCk1gwUN2cI7oWe9oP+ebv+p80DyLg/C/GEYEZhkziQqwSflj78NiiOIdN6Gz6NTRLyGHVXbM8LQqx7ppJyo+L+Rrslx92M2DBybKMjoZVQpJuWnuzG90ZX6DwwgnW8EvR7tKBobDPAfm3tjsWNBoIqpPm3k0lEX3RqoJ1Fhd3utWr6Z4DnpYe746tRFeBio+uLSz81RgoWXG8jK+W2Fzcn83piKeP8+YbFKsmBmKP58do+8vZaQZAfY+w35g4vAyZy1QrY5CafN+Wg1bDpfsX8jxXLLog/cZwsSpsS6wmg4/xppzUVtJbbZrbdPod4Zr5O1qzOC1215Z768KQTeBDoWA6ZkYycEAvQzKNHMmKnPIxiKMQMNqZqkrFfAjAXZ4n7y15cZQGbKBA6Vu7VRT/vNULnDsH1uJjPqTRc19WzmuIH/OETLO6Tde0AT026VryACdg+qffS6DN4zrypetMh6ay0xQ++3oEsMDhU4JYEgUbcV1E3ssVOWJ38nN8I0=
X-Microsoft-Antispam-PRVS: <BY2PR05MB21843CC098833DEADCF63C11D4160@BY2PR05MB2184.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(35073007944872);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148); SRVR:BY2PR05MB2184; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2184;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 4:/7a2jOKGOHOv63cGXGKL6DkYtpk09Q9tq/IR9iuCV7+ojra7QN24hOxctgqXxFUNMgskAjh0Wui4ZlSNjy6AAP8wXM8b3Gj1Ozs1BEwdhNDRCqb5+GxAR0H4CY5WgurwV0475kUMRMxD0ipyfbgGRv5M4y/u9zMhjQvuIEeeF90Dj842VKjv+N7/HkHsK/X2UwGkx+GCyg/weyTR6lPijKrbebYmpE++nR+H703IerDwIAC/8cU2nHUs1wMMtlGvgqUwyJLXXoHcwPV89ZI5qsrPJ6DFFf+IZKfyFOFSSp/MmxqyFhAR7NJjF5YFX+bMU1bZFVIWwCrcYBd6YEZLXWTRm93j/R4RZhBXrs8/QoyBHNKOPQWHiIB+S9167NQRH9axFoTSkcljdtUU/J7J6ugp0xo1DLcPE8XVCy+EBFt/8DouD6o4XVHmLmvgMXxQGnWucvEYUgNAONJ/FuY7NnPTdZqFxE/l3il9+vaA2YBduTGcopnPeMBhvYnuGCJ7XMa+EdfxmxFMmWevsLs4f6RNfUb0VQ1fBHnqWsNM2eyN5ispzo1c7PEb2xNbriHxVujm6YN6VDaVww5w+FxyzCOjTuWZLhBSDQ/XCbEp+x3BtJzoUZBT8NUWssLh7Y3KxSIifdFCrx41/1kQqhux/FXMuNh7F6hxGtmi3wu8aycJy/PNbA1NZeWLVfDgiKtkxlCIUPV6/ha6rt5JNcNnfQH8zACR9qDJm5+kyW3XO0DMqYOE/Ropj6zYSSQcJp9hsiqT/j5hpXyi9nAYGQ2payovJOSfIG5C0uLKQeDTMY36xGWLSlxQSETlg8ROMB5Xo1c2G42CX4e8d6p2gjyag6loGdAu6lsqDpTrwwWP7pA2qHf96cFlCmiO0li+Q7k6
X-Forefront-PRVS: 029651C7A1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39860400002)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(24454002)(377454003)(76176999)(7736002)(2906002)(512874002)(54356999)(50986999)(229853002)(6666003)(2950100002)(81166006)(8676002)(31686004)(36756003)(42186005)(83506001)(5660300001)(90366009)(31696002)(4326008)(6246003)(33646002)(189998001)(77096006)(2201001)(6486002)(86362001)(230783001)(84326002)(4001350100001)(478600001)(6116002)(3846002)(54896002)(790700001)(2501003)(3260700006)(38730400002)(64126003)(53546009)(53936002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2184; H:[172.29.35.213]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 23:nERmTBuTJnDlMMFMGZFDOhkICKUyIlIpzToliNS80EDGvGo3YIZdEU9tSPgdLR9rlqopXoDnCvSt5/pVlmVr9F7jyJd3SSR9P6YXKiW34CeElpr9em5q/UeiYDW0JzKBP4oqE/sIUsegvUssMvD+L25UK40gL7x4A7Rmt5e6l9Lo1EXX74hRFcKGyeVrCE/uQp7YyffhyqJr288cyLo5DyeroPA2yjNaoH9Z/M9U2WKwXQ7N0BquBLxds8mNIPsUMX03rsBHpH36nNOyLpLzWkDqgZzjp/qYVpVKDBEzSSQewv3vsXSWUqaf0/YfcXBia3y7x7CkeIHxGy4mkWMM5Ffk1RYdaz3bb4c7BFwQc5QKPu4sZ0VxANkRMWEiIvrAzBUlkV5eRLy8XBS9nhXiKyw69OH6OEFT6bUmMGbaBcv/UdV1L8HpJoCHAxhAGci94ySnZ4hypnglz+QeFbhXXNQ0N6UVH+9Ng8YI+DyOZPkGMygaxOLnE4vZ92avNUvuy4mC5W3LDnXaJnRvoaMz+alxzsf7jSDieliHdyYb3sIF3hjSb1/HdvDI6X2l4D03vnM45Cxz85acY/p6bxmRkjND0pIaYuAdMxUiPXLq87T3BPYdlJ1E3+Q/G3UMts7MF+kF6bxeqtS6R8GIg/IJC+wtDtqXgi+QoBf6mfsNcn3wyZ/yqkS2LPNGtr8A9DxLkNnUVT/xcUU+IKGbZnBMp7Xrvtk6lWLaf/XppVFXqaHfqABAUtQbWEkKeW3Rsrp2yg6/wP2CeYzw1yE1MwMLPXzGNPEsPzd5gU6qVl40REOJ73gygCfOo9o7QMqWKttEX0Ala0cdcBGSV1nRrIZ4AZ+cLf0aqfbddaoDmWrX1w3HcfJnipqIHGmMsEWYDXYgic9CSTUvPhwyJGL2HE4RJczql7d3SEOFp3yMAM3eBXTXV+PAbcXg64R7bN/4A5co+FHRdzM/xXbz/N1mKf3T2xiw2LilmyWK/9pcQpVTGDtp4VBaznHSzxE0/T3SH9bO1T1f3yoOyMqVagjJ8GeLZnzSVTloC0MuMYUdx59GCyzEDx+pAZezRzieMCSEcgrao6sM2BQ/WZa1PSi4wDQOTwS+ob38ziGOxoAldVKMD0v2w+qZQCOgGFRuQPpTu4Hf1TbGBivCo3cQWoh9WTPnUswwSohnKEiKMXIfsWmXWaAYw++EokZCQoVhZrvjQQmbZ8bipI9UBXYv1/07WJJxoNkGYHr5zWIoy+As1IBfrQEtc2h85CPhi3QFSVso3Kc55pObHvG582MNblv6a2poow==
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 6:/JA2bKGsTINw7yvBXPvQK2fBDQNSnGwcTxUJ2vVxWaUmeUq/WaVIrzaFPgg7q9tcyeGzpWxNeeFooUoceYfUBmVqiVx3zJAC4NvcVr3hlN99Nw+kwscZAEAJ6wK3ezRLbfbiQmXonQGsC9SFE+pIwWaN4ejUonTq6s4wPva+Otu6TP0g9D+3QyqHd1ADuAjVxlRjJ6HljLmSdbLp8j6OZrQrsnOkcPMxe98moolBE7rAwThNuZ//OB5VmJu6bLv8+jPEoHVdQVRaDA+0km9tpLJsFGGl+tI4MMMGV+y0gkx+fPV+85gEa+oQ7ylpqnddqvB72nXzxrLuNEwrK3SKll0nYK7w3/yc/srScQjzR4GQajg7VXSmy8FoqbaDxPl0cHczIIo9UP38P+3I2oZhXJlw1nC0D71IAY5VOSWrxn3b+3NfCkY9ifLjixTnMGxlmxW7O5yAg8SOOZuUgJkm77nYa2qIDcIIchUGXC6AmNVjIkAvjAmKijzI9KeDtC+NRvUbjfo8XhGSOUEndnKAbSK9XDz2d7x5nNJpNvFZPR4=; 5:GTydr7fEuLR1PA9xmkH/3DwX3Ze4q5ho/xTDBNdso+EEb+lqTOZHS55o67Etfo82mQKXMbX0lqctY5Ahp99vuoakxf2kk0qroV7+S03lBcKYys+jzUilWvW5gMrk8AmRdnGU+cpiRO1OyGK9gjnkDA==; 24:GrRHKc64CQxerTjR6pgTfZayaYXrDHwolQXAqnDwJkUYoSKevk0pSfqIttFMi6Z7nw8C/+9CRzcbJZCaddG8pO0I0X9xiZfFnT8qA0LxoPQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 7:vPo5+KtZO2PWDVDugwWkpYSct84i/hGlm5Zo90MnkwwBBkTF9AOqVLnEnQNV9oHdo80EAmn+Ka5d8a+I1in3aTYEyVfcWZOZsuaBlUVHxCvnUrGLWscXXOk45CX5QGjz70/JJoiNkZ5Uhw8hFvAwtmC4Xtxv8ADHSoJjreZ/2cKqYLUqIfuNnng3zo6I38Xq7TYPBDbdx9SIbO85+UsuPZRdBl7NJRjb40y5/XPwx2HTh8sHpoOotY/gnO1qyL7fpAaJZsvLY9nWHUgAYkIU6lsP3/WRgaSqHRJAKqZnhBxZD0e1irbd5b5vohF4CUqPDdqKzKboyS+hEoIVgkU/5g==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2017 18:23:07.4167 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2184
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Cgt-hNMqbczwSXIIRJMn4zLwVBo>
Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 18:25:14 -0000

Thanks for your review!


On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:
>
> I also spotted a few nits that should be fixed at some point before 
> publication.
>

I have fixed the nits.

> Comments and Questions
>
> 1) In section 2.1 it says:
>
> “   If the Multiple Labels Capability for a given AFI/SAFI had been
>
>    exchanged on the failed session, but is not exchanged on the
>
>    restarted session, then any prefixes advertised in that AFI/SAFI with
>
>    multiple labels MUST be explicitly withdrawn.”
>
> If I have understood this correctly, it requires a speaker to withdraw 
> NLRI that it sent on the previous session but that it has not sent on 
> the restarted session (because the negotiated session capabilities 
> changed).
>
> (a) Why does it need to do that – isn’t the NLRI implicitly withdrawn 
> when the EOR marker is sent?
>

The theory here is that the label stack in the stale routes is known to 
be invalid, so you really don't want your peer to hold on to them until 
EOR is received.

> (b) This seems to contradict section 2.4 which says “Note that 
> label/prefix bindings that were not advertised on the given session 
> cannot be withdrawn by this method.”
>

I added the following text to section 2.4 right after the quoted sentence:

      (However, if the bindings were advertised on a previous session
    with the same peer, and the current session is the result of a
    "graceful restart" ([RFC4724]) of the previous session, then this
    withdrawal method may be used.)

>
> 2) In section 2.1 it says:
>
> “A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a 
> given prefix than its peer is capable of receiving” – why isn’t that 
> MUST NOT?
>

Section 2.1 also requires the receiving speaker to apply 
"treat-as-withdraw" to such updates, which does imply that the sending 
speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT".

> 3) In section 2.4 it says:
>
> “To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI 
> attribute.”
>
> Should that be “it MUST send”?
>

I think the non-normative (non-RFC2119) language is fine here.

> 4) In section 5: although some implementations treat SAFI 1 and SAFI 4 
> routes as comparable, I believe that they should always be treated as 
> independent, in the following sense:
>
> Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to 
> the same prefix P.  The SAFI 4 route MUST NOT be treated by the 
> receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 
> subsequently sends an explicit withdraw of the SAFI 4 route, this MUST 
> NOT implicitly withdraw the SAFI 1 route, and vice versa.
>
> Am I correct?  I have seen implementations that violate this so I 
> think it is worth spelling out somewhere in this section.
>

 From Section 1:

    This document also addresses the issue of the how UPDATEs that bind
    labels to a given prefix interact with UPDATEs that advertise paths
    to that prefix but do not bind labels to it. However, for backwards
    compatibility, it declares most of these interactions to be matters
    of local policy.

Different deployed implementations have different behavior, and I think 
it is better to advance the document as is rather than derail it with 
the inevitable food fight that would occur if we wanted to try to get 
the IETF to say which implementation is better than which other 
implementation.  The deployed implementations have been around for many 
years, and people seem to have adapted to the differences.

> 5) In section 7 it says:
>
> “ If a BGP implementation, not conformant with the current document,
>
> encodes multiple labels in the NLRI but has not sent and received the
>
> "Multiple Labels" Capability, a BGP implementation that does conform
>
> with the current document will likely reset the BGP session.”
>
> Wouldn’t that prevent incremental deployment of this RFC into a 
> network that is initially composed of such implementations?  Because 
> it seems to require that both ends of each BGP session must be 
> upgraded simultaneously, or else the BGP sessions will all reset.
>

This issue was discussed at great length when the draft was first 
submitted.  The vast majority of deployments do not check the S bit.  
That is, the de facto standard is to assume that a received update has 
only one label.   If any existing deployment were transmitting updates 
with multiple labels encoded into the NLRI, it would already be causing 
BGP session resets.

(Even iff this were a real problem, it wouldn't require both ends of a 
session to be upgraded simultaneously.  It would just require one end to 
have a knob allowing it to accept both old and new behavior from its 
peer, and a knob telling it whether to use old or new behavior when 
sending to its peer.  But since the defacto standard doesn't use 
multiple labels, I don't think we have to worry much about this.)