Re: [bess] [Idr] draft-rosen-idr-rfc3107bis-00

Loa Andersson <loa@pi.nu> Fri, 15 January 2016 06:49 UTC

Return-Path: <loa@pi.nu>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478491B29FF; Thu, 14 Jan 2016 22:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 EUpsbX48mwBz; Thu, 14 Jan 2016 22:49:55 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FFA1B2A29; Thu, 14 Jan 2016 22:49:55 -0800 (PST)
Received: from [192.168.1.13] (unknown [49.149.213.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2F77E18013CB; Fri, 15 Jan 2016 07:49:51 +0100 (CET)
To: Eric C Rosen <erosen@juniper.net>, idr@ietf.org, BESS <bess@ietf.org>, mpls@ietf.org
References: <5696933E.1080802@juniper.net>
From: Loa Andersson <loa@pi.nu>
Message-ID: <56989686.2000100@pi.nu>
Date: Fri, 15 Jan 2016 14:49:42 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <5696933E.1080802@juniper.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/QJGuiZjd_RQOOct9QWfOZzV3Buc>
Subject: Re: [bess] [Idr] draft-rosen-idr-rfc3107bis-00
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2016 06:49:59 -0000

Eric,

In this particular case I think "cross-posting" is necessary.

One small reflection for what it is worth.

If there is no strong reason to put this in one working group or
another, there is probably no strong reason to change the home of a
draft either.

/Loa

On 2016-01-14 02:11, Eric C Rosen wrote:
> Folks,
>
> Pardon the cross-post, but I think this may be of interest to all three
> of the IDR, MPLS, and BESS WGs.
>
> I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS
> Labels to Address Prefixes"), which is intended of course to obsolete
> RFC 3107 ("Carrying Label Information in BGP").  (While I put "idr" in
> the name of the draft, it's not completely obvious which WG should own
> this draft (assuming it progresses)).
>
> The purpose of this draft is the following:
>
> - It fixes a number of errors in RFC3107.  It attempts to do so in a way
> that is compatible with existing implementations.
>
> - It removes the material about "Advertising Multiple Routes to a
> Destination".  This is a feature that was never implemented as
> specified, and the text about it just causes confusion.  The
> functionality that this feature was intended to provide can now be
> better provided by using add-paths; this is discussed in the draft.
>
> - It is explicit about its applicability to SAFI 128 as well as to SAFI 4.
>
> - It clarifies the procedures for withdrawing and replacing label bindings.
>
> - It discusses the relationship between SAFI-1 routes and SAFI-4 routes,
> which is very unclear in RFC3107.  Different implementations have
> treated the SAFI-1/SAFI-4 interactions differently, and the draft
> discusses these differences.  However, as the draft is not intended to
> favor any one implementation over another, it can't do much more than
> point out some of the differences among implementations.
>
> - RFC 3107 provides an encoding that allows BGP to assign multiple
> labels (i.e., a label stack) to a given prefix.  However, it provides no
> semantics for this, and this feature has been only rarely implemented.
> In fact, it is believed that some implementations will not parse the
> Updates correctly if they encode multiple labels in the NLRI.  Therefore
> the draft only allows a label stack to be assigned to a given prefix if
> a new Capability has been exchanged.  It also discusses the semantics of
> assigning a label stack, and gives some examples of how this might be used.
>
> I hope that those of you who are interested in this topic will provide
> your comments.  I've tried to make the draft compatible with existing
> implementations and deployments, so if anyone sees anything that
> negatively impacts an existing implementation, please comment on that.
>
> I also removed most of the text that explains why it is a good idea to
> use BGP to distribute label bindings.  That text was important in the
> '90s, but now seems rather out of date.  However, I would welcome
> comments on whether an updated "motivation/positioning" section should
> be added.
>
> Thanks,
>
> Eric
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr