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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 08 January 2016 23:12 UTC

Return-Path: <alexander.okonnikov@gmail.com>
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 0B5EF1B2C8E for <mpls@ietfa.amsl.com>; Fri, 8 Jan 2016 15:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 XoFscEnP-gO5 for <mpls@ietfa.amsl.com>; Fri, 8 Jan 2016 15:12:04 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305941B2C89 for <mpls@ietf.org>; Fri, 8 Jan 2016 15:12:04 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id m198so36874102lfm.0 for <mpls@ietf.org>; Fri, 08 Jan 2016 15:12:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=qxtxbwef+FC7XFHnKpYQ962ENdm8tc/Q3jOAhXVO/BU=; b=gPOzHdbOkTkxegsWlv+TOTytD5HU0TkAhO7iECdApmYc3eHjLUQ4uxcSd6w2JKx3r7 OEbuq2EuKYe5bEq+/mQl/KJHLtu3LGpB6NmnNOpFbd+JdkJQno3QjTw3UwpatLKJZW+L HIX194HNd+fgj8VlyYEg5uHZ41c6h2bsnDeu9m7dVQ5T4vizF0+RjvAHbeAyFl6/0Rnr jos06Z5IDUSg3zKDl+bFG2xWyNm7eQUa6hxwRXN/i0Gk+5FEkbVHPkGPAnnEww19NZdV FQaAaALqR8/hrzhKl1fko4fGQNLi8tJ0ghoNlLcWTGpZlreNOOCPFscni6pnheCjhWmy gonw==
X-Received: by 10.112.199.105 with SMTP id jj9mr40181676lbc.131.1452294722466; Fri, 08 Jan 2016 15:12:02 -0800 (PST)
Received: from [10.0.1.5] (85-114-21-254.obit.ru. [85.114.21.254]) by smtp.googlemail.com with ESMTPSA id k64sm13657923lfi.23.2016.01.08.15.12.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 15:12:01 -0800 (PST)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: erosen@juniper.net, rfc-editor@rfc-editor.org, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net
Message-ID: <56904241.7070006@gmail.com>
Date: Sat, 09 Jan 2016 02:12:01 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/qalOcPQrDq39qlSlWMDbMA4pTEI>
Cc: mpls@ietf.org, equinox@opensourcerouting.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: Fri, 08 Jan 2016 23:12:06 -0000

Using terms "NLRI" and "Prefix" interchangeably is a root of confusion. 
I saw good example of how clarification could be done to distinguish 
them. Follow example is from RFC 7432, section 7.1:

"... For the purpose of BGP route key processing, only the Ethernet 
Segment Identifier and the Ethernet Tag ID are considered to be part of 
the prefix in the NLRI. The MPLS Label field is to be treated as a route 
attribute as opposed to being part of the route. ..."

Indeed, in SAFI 4 NLRI label is attribute of prefix rather than part of 
prefix itself. This was implicitly assumed in RFC 3107, but was not 
stated explicitly.

Agree with deprecation of capability type 4, because a) we have 
add-paths mechanism now and b) this capability could pose some problems 
and thus is unreliable, for example, when two routes have the same label 
value.

Using 0x800000 though is not in line with rule of label stack encoding, 
but perhaps only solution for backward compatibility. May be it makes 
sense to deprecate encoding BoS (due to deprecation of multiple routes).

Thank you.