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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 26 January 2016 07:47 UTC

Return-Path: <jie.dong@huawei.com>
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 E084E1A6F9A; Mon, 25 Jan 2016 23:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wP7B1S0su4NI; Mon, 25 Jan 2016 23:47:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EA61A6F98; Mon, 25 Jan 2016 23:47:20 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDL56945; Tue, 26 Jan 2016 07:47:17 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 07:47:15 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 15:47:12 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, BESS <bess@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [bess] draft-rosen-idr-rfc3107bis-00
Thread-Index: AQHRTi3nNGAWkbeTK0mnYPsI1D9BXJ8NbouA
Date: Tue, 26 Jan 2016 07:47:11 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C92774E1CA15@NKGEML515-MBS.china.huawei.com>
References: <5696933E.1080802@juniper.net>
In-Reply-To: <5696933E.1080802@juniper.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A72486.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 48b7346b462526dc7cd533c204f3535e
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/FyHL4hkbo73CqkQ4uSlNiXnJq24>
Subject: Re: [bess] 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: Tue, 26 Jan 2016 07:47:24 -0000

Hi Eric, 

Thanks for writing this draft, it provides useful clarifications and updates for RFC 3107. 

After reading the draft, I have some comments:

1. For NLRI encoding with single label, this draft says that "the S bit MUST be set to one on transmission". IMO RFC 3107 does not mandate this, and as you said some existing implementations may not set the S bit. To ensure backward compatibility, maybe the requirement on setting the S bit can be relaxed.

2. For NLRI encoding with multiple labels, I guess the beginning of the prefix field is identified based on the S bit of the last label. If a malformed NLRI is received, in which the S bit of the last label is not set, then the prefix cannot be recognized, and the treat-as-withdraw error handling is not applicable. This may be worth mentioned in the draft. 

3. Section 2.5 describes implicit withdrawn and load balancing in detail. One possible issue here is it seems that the same next hop is required for the routes in Update U1 and U2. While section 9 of RFC 4271 specifies:

   "...if the NLRI of the new route is identical to the one the route currently has stored in the Adj-RIB-In, then the new route SHALL replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service."

Thus same next hop is not required for implicit withdrawn. This also applies to the load balancing case with Add_Path, in which the 2 paths used for load balancing may have different next hops.

Best regards,
Jie

> -----Original Message-----
> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Eric C Rosen
> Sent: Thursday, January 14, 2016 2:11 AM
> To: idr@ietf.org; BESS <bess@ietf.org>rg>; mpls@ietf.org
> Subject: [bess] draft-rosen-idr-rfc3107bis-00
> 
> 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
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess