Re: [mpls] [Technical Errata Reported] RFC3107 (4582)

Eric C Rosen <erosen@juniper.net> Wed, 06 January 2016 22:53 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1CD1A1B5E for <mpls@ietfa.amsl.com>; Wed, 6 Jan 2016 14:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 0qgFW1vN9IGX for <mpls@ietfa.amsl.com>; Wed, 6 Jan 2016 14:53:20 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0161D1A1B5A for <mpls@ietf.org>; Wed, 6 Jan 2016 14:53:19 -0800 (PST)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net;
Received: from [172.28.32.102] (66.129.241.14) by SN1PR0501MB2157.namprd05.prod.outlook.com (10.163.229.151) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 22:53:01 +0000
To: RFC Errata System <rfc-editor@rfc-editor.org>, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net
References: <20160106110554.1848F180011@rfc-editor.org>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <568D9AC7.2010303@juniper.net>
Date: Wed, 06 Jan 2016 17:52:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160106110554.1848F180011@rfc-editor.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BY2PR08CA050.namprd08.prod.outlook.com (10.141.248.168) To SN1PR0501MB2157.namprd05.prod.outlook.com (25.163.229.151)
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 2:7dfr3RY4DWNYScH8QR9MmT+93lM7uQ3DVUZJVmZMzsz/6S2JYsEfpaowgV9sq/vo7b5HJ2LjW+XO2SNZ+3inC0Z/Hh/rZ961JU4y3/FOtCuVhE8kp3qApK//gHT3znPZDZSyR/SVocAV+JGYCsDn9g==; 3:PX8NLpTjbAZENxLnEkEr/2478X7ODBp4H5wylZDmo7646GEvk1t3+g0fVjU+d66O/vm723IEo7cHhekZEr6FrFALh3z0hO+2WTq+nvx2yBbnadhyKhOBVZ4vwQzHvu22; 25:vxzNB6CBs8zOMuvsAGUKssBJjOzJ/p4XOc4QVepyBdw3srHnakm5JSrm0d4B9b38kwvabGGtdVLoOjenXIL2JLhngQS1vJr+Uj+dGGBHhGHk7t2SX+7Wc+XaVpVB6IHTqFGhP0elMJBF96FQ6wc7q8ld2vjAps4QdiIjrILJtDB5OMrhziLrFq3wxfj3T894JgCQTHUJyjbmfm1z0CTRUA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2157;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 20:fACQi+TCPcuYOKS/CmacRtELzQAQpAdA2prQMdl4EJjLAzX3gU6KsW90g6IQamta/axEoTH9h0i2CG9rIEbAQfGDTEKXCNvq8NDXOgjwxfeTNntqHD0Vr9fCkXisCYovA2K5j4zhNjFSB6bSRIb4jRVNXRQoGHBpV/7/oaD9B11uyEZlCfs/qJZuSntZxPg9ISKvFTwY77KaCfRgaf3N8TydSob7QKCg7VaLugmJEgo8UmCm42DJAQrwoo53rxk1wpjXQtJzDv/2tfFQD/uC3sSlFEUYZJfWAi+yHfu7DsOFPhuKZxMAzTBClXHCVsdVZz+VFX+ULNJTThISekv//GvVHLm6cPJj3LnYXbTEFwciamCpwRvkyVaqj35pCmLCAI8HBqpSFiGyQRbFUrKDUVIU0t7LohycM+zR5M9AW/eyBPgZ+QGa1J9M+MOJ7f0XiILUS/Oq6ugl2TjGE0YegcMt8uJdP4MyIolJEGAWmluTm2X1pxBiylXNmg0aolVw; 4:ee3XU2O9f+GybnhjpK8BsW20vwDCmX7a1jQXNfsScAYFIgxby+VdW3MoqaA5fPAaX8sUXeqZUNhyjoa+pGBDLgR4FxryhAwQ3I7B2cxFY46lEOAG1nTdzd12uP2F5m35fHK/C4GFS7KdxbWZdZgzvCSyPoKtBhKQumdHhe19wvA/sexbx++v97JNbOLeT9aEI0mlaaH6p3vB12suJ2J4Ul2ViSd5N0+/AxNxuyUl1gugG5BPKDGwXPdeYRnTgWSEi6uyLqJ6m9EeKlvR/IX60Mjr29BVznWDP3l0a2bfIV5AH4o9I98dVdAaWvW3Oe8qjVms+rNWyuo6bhI4I/2s/rpUsSTVARJ7Hux9mG45wODz4Y7thRuPOV69S36il9Bp
X-Microsoft-Antispam-PRVS: <SN1PR0501MB215757491D310DB0A5ACA966D4F40@SN1PR0501MB2157.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:SN1PR0501MB2157; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2157;
X-Forefront-PRVS: 0813C68E65
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(65956001)(92566002)(65806001)(87976001)(65816999)(83506001)(97736004)(1941001)(105586002)(2201001)(2906002)(50466002)(4001450100002)(106356001)(4001350100001)(1096002)(2950100001)(86362001)(101416001)(36756003)(5004730100002)(77096005)(5008740100001)(66066001)(189998001)(80316001)(3846002)(42186005)(47776003)(40100003)(64126003)(122386002)(59896002)(23746002)(6116002)(81156007)(87266999)(33656002)(5001770100001)(5001960100002)(54356999)(230700001)(4326007)(76176999)(50986999)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2157; H:[172.28.32.102]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 23:QTo09kM4cUfCVlLf03LJ5LkcApKlhW9mKnUiOA4ZBs7g/3xnf2AsgWqJgDQevCPKb30JSgJ2chyN7Pi7XtMJv6jkm6CvZUlIucbjKSLZxKEGBy2/EdhfZeL5+m2CO8gNVy/hvzcKjUQEfSk8vGAO1EN12Eupm0tXscBotmA0EusEbaqrvhi9kSD8NAnKc/ofEKB2XzT/DNrUXWQUcgHj6hZT4irf2wDk9mjClia/MS1zPGRRh2u045wm4jG/9P+x0XKKUyhAi7vi0ZTTSL/iaC2o47JdSa5fHvo08/9yg6KNoUiYvAtAWRO0cS5X8fgEUiLci7cGZdtbl7r/HFXAjQCFcXymSTie774SamggdMk82o88EVqu7h+14jJoVo0YvMh9BCFAmj4Yfev16VPkSqxQeeAdMUFsiloWfiqwNTMrz2FGxAnTpYKjfloSV9CmdbB2GOKN0rU//JZaKn2YqMXsi8RVoHIAD5efvWOi4lTSe5OB7Q7IffZvgB3RSq1X2/WWq7y9Adi6QlAeJXHk4j3OpuS2gmYWSoqp129XfNe+iQBK23NLUx2PV+h8N29ezvkgZit9X4VNY9ZkgcEPVWIkO6VEdsFw4kLbtD3P1oYtyY2yADzMLqi08ujRD9sDiW3VPT6ltUldQX7SIHD2ovlLKa3kzAWLzx9c+PgWYF8hKMuR2KwTPxyHtbwwBQOmSsHFZH0OrBi1UsGS3va4lHtM16P1+JGmTPEja2KcfZ+MaEkeIzPwN8MdNdbDlQOX/hvHVhUz5iDxujWVONMbAOsRPLJi0xtClg11D8txnQtvP1eA202lwHN8xb+Z+mNiMzG51gVzi9POP7l/b4yDO8VzGRFVWEsqblzdaoVYNmfdmvxx/HE0eoi0Bnme8XFNZsuSFYZj/3VqdU9ngoKWKkvTi4I+L3zCwnG7dgWWi2nCWRn/CwQftFofZi3gqR/XXEKueFzZsV4vwtlN+UL7bxy8+ynEeAqHy5i+wcaBKDgBw9vSqZG1SuAxoaB5IWwUGvYQnGH15p0OJsvwcM6Z4vzkW/VfYcir4jln+T8kWlLqE5gdDYv6vju1sjUx0h/r4MiTgGYEGCW7aCDAFjheFsxH14y8mETs1b/MW+Eomh9v54rwkNFAyFbS9O3WIYtqQcVEewwIzt/PQMIAY6nIUpAYqoRGeDrhH6es/S0T9fiVzxFlydSppUlItVm8RVgcauwHX2E16vX6h7zaK56mP2Flcb8B+IqOrDesIO2QQCONbDlMeM+aNuFOg+QzymKY
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2157; 5:Sf5Pqcz0TDkOmQZRtJrlUMRHEVBvGarwWNBP3SzgSDY5v+obrRYrXgWTXnjSymq5t2rOctBb4DXtijBBkE5xYx4VJjrPux5lEiXKrVfgIRWUIfTiGS+xwmvEpTRXMOzjj6oLZLR16+UUtoWhzp+NUA==; 24:eLd3bWVy1C8JITJE+kp+uQ5rvY4t3Ja7yfTAySS8htdQXM5k8f0HenbvIigtjrQEY4EuORQcnW965dqIALaEgDPXEW+mhtCReNoC4S4PK+Q=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2016 22:53:01.5927 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2157
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/OUyOjkH6Z2fHmb6LmFhzbXSSjjo>
Cc: equinox@opensourcerouting.org, mpls@ietf.org
Subject: Re: [mpls] [Technical Errata Reported] RFC3107 (4582)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Jan 2016 22:53:26 -0000

A proposed 3107bis draft will be available shortly.  The draft will deal 
with the issues you've raised, as well as other issues with RFC3107.

Meanwhile ...

As far as I know, no one has ever implemented Capability 4, and I 
believe 3107bis should propose to deprecate it.

Section 4 of RFC3107 is intended to apply only when Capability 4 has 
been used.  So you can just ignore that section.

However, I think it is perfectly valid to use add-paths to advertise two 
routes whose respective NLRIs have different labels but the same prefix. 
This is like having two different paths to the same prefix, and each 
path may have a different label.

Bestpath selection should choose the best path to a given prefix, 
without considering the labels.

Section 3 is,  as you observe,  very sloppy in its use of the terms 
"NLRI" and "Prefix".
> I have not checked what other implementations do;
You're very brave ;-)
> Quagga (which only implements this as route reflector):
> - does not implement SAFI 4, but applies the behavior on SAFI 128 (VPN)
I can't comment on whether your implementation needs SAFI-4 support, but 
the 3107bis draft will make it clear that most of the draft applies to 
SAFI-128 as well.
> - does not advertise capability 4
Good.
> - excludes the label value from all comparisons
Right.
> - will only keep the last label value received
I assume you mean this to be in the context of a given prefix, as 
advertised on a given BGP session.  But remember that if add-paths is 
being used to advertise two paths to a given prefix, each path may have 
a different label.
> - will set the label on withdraws to all zeroes (ignoring the recommended value)
When you receive a withdraw, the best strategy might be to ignore the 
value of the label field.  When sending a withdraw, setting the label 
field to all zeroes is risking an interoperability problem. It might be 
safer to set the value to 0x800000, as RFC3107 says.