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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/NmfdMi-TuGrjdGeCOgUjIh2jgIE>
Subject: Re: [mpls] [bess] draft-rosen-idr-rfc3107bis-00
Precedence: list

Hi Eric,=20

Thanks for writing this draft, it provides useful clarifications and update=
s for RFC 3107.=20

After reading the draft, I have some comments:

1. For NLRI encoding with single label, this draft says that "the S bit MUS=
T be set to one on transmission". IMO RFC 3107 does not mandate this, and a=
s you said some existing implementations may not set the S bit. To ensure b=
ackward compatibility, maybe the requirement on setting the S bit can be re=
laxed.

2. For NLRI encoding with multiple labels, I guess the beginning of the pre=
fix field is identified based on the S bit of the last label. If a malforme=
d NLRI is received, in which the S bit of the last label is not set, then t=
he prefix cannot be recognized, and the treat-as-withdraw error handling is=
 not applicable. This may be worth mentioned in the draft.=20

3. Section 2.5 describes implicit withdrawn and load balancing in detail. O=
ne possible issue here is it seems that the same next hop is required for t=
he 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 curre=
ntly has stored in the Adj-RIB-In, then the new route SHALL replace the old=
er route in the Adj-RIB-In, thus implicitly withdrawing the older route fro=
m service."

Thus same next hop is not required for implicit withdrawn. This also applie=
s to the load balancing case with Add_Path, in which the 2 paths used for l=
oad 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>; mpls@ietf.org
> Subject: [bess] draft-rosen-idr-rfc3107bis-00
>=20
> Folks,
>=20
> Pardon the cross-post, but I think this may be of interest to all three o=
f
> the IDR, MPLS, and BESS WGs.
>=20
> 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)).
>=20
> The purpose of this draft is the following:
>=20
> - It fixes a number of errors in RFC3107.  It attempts to do so in a way
> that is compatible with existing implementations.
>=20
> - 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.
>=20
> - It is explicit about its applicability to SAFI 128 as well as to SAFI 4=
.
>=20
> - It clarifies the procedures for withdrawing and replacing label binding=
s.
>=20
> - 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 discuss=
es
> these differences.  However, as the draft is not intended to favor any on=
e
> implementation over another, it can't do much more than point out some
> of the differences among implementations.
>=20
> - 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 semanti=
cs
> 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.
>=20
> I hope that those of you who are interested in this topic will provide yo=
ur
> 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.
>=20
> I also removed most of the text that explains why it is a good idea to us=
e
> BGP to distribute label bindings.  That text was important in the '90s, b=
ut
> now seems rather out of date.  However, I would welcome comments on
> whether an updated "motivation/positioning" section should be added.
>=20
> Thanks,
>=20
> Eric
>=20
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess