From: <bruno.decraene@orange.com>
To: Eric C Rosen <erosen@juniper.net>
Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis
Thread-Index: AQHRjDXCqHf38G7z/0eG06bIad1uvp96Udrw
Date: Mon, 4 Apr 2016 21:28:37 +0000
Message-ID: <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
 <56F42E71.9020201@juniper.net>
 <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup>
 <56FEA566.8070605@juniper.net>
In-Reply-To: <56FEA566.8070605@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
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/px4NIW4xH2Uz4E2uesfCROywmPY>
Cc: "idr@ietf.org" <idr@ietf.org>, BESS <bess@ietf.org>,
 "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis
Precedence: list

> From: Eric C Rosen [mailto:erosen@juniper.net]
> Sent: Friday, April 01, 2016 1:44 PM
>=20
> On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote:
> >> I'm quite sure you have deployed  implementations, from several
> >> prominent vendors, that will not properly handle this case.
> > I'm waiting for this/these implementation(s) to make a public statement
> in this thread / IETF WGs. Then we can discuss whether the issue comes
> from RFCF3107 or from the implementation.
> > If none make a public statement, we should assume that all
> implementations are capable of receiving multiple labels, as per RFC 3107.
> I strongly disagree with this.  We should not ignore the facts just
> because you don't like the way the facts were gathered.
>=20
> A better approach would be to have operators state whether they have any
> deployments in which the "multiple labels" feature is used in a
> multi-vendor environment.  It is very useful when working on a "bis"
> draft to determine which features have been proven to work in a
> multi-vendor environment and which have not.

Asking operators or vendors is equally fine for me.
My issue is how do we prove that _nobody_ is using it? Proving the negative=
 is hard, and silence is not part of the proof. To prove the negative, we w=
ould need explicit statement from everyone, which looks impossible.
=20
> > Any non-compliant implementation may create interoperability issues and
> unpredictable results.
> >  From an IETF standpoint, the question is whether a RFC 3107
> implementation would create interoperability issues, up to shutting down
> the BGP session.
>=20
> There are deployed 3107 implementations which always assume that the
> NLRI contains a single label.  If you tried to interwork these with 3107
> implementations that send multiple labels , you will experience the kind
> of disruption.=20

Agreed. But between 2 3107 speakers, we can determine which implementation =
has a bug. Whereas between a 3107 speaker and 3107bis speaker, both impleme=
ntations may be compliant, but still the BGP session would go done.

> 3107bis tries to allow the use of multiple labels while
> preventing this sort of disruption from occurring.

Agreed. I support this.
=20
> > If you mean that some non-compliant implementation do not work, well
> let's fix them.
>=20
> The situation is that there is a commonly deployed "bug" in old
> implementations, but it is not seen because the bug is in a feature that
> no one has been using.  If new implementations use that feature, the bug
> will be seen, and network disruption will occur. One could say "fix all
> the old implementations", but it seems wiser to have new implementations
> avoid tickling the bug.   The Capability is not proposed  for the
> purpose of helping the vendors, it's there to help the operators.

I support the capability.
=20
> I'm not sure why you think there would be BGP session drops due to
> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis
> implementation, I think the 3107bis implementation would do
> "treat-as-withdraw" rather than "drop the session".

"treat-as-withdraw" would be fine for me. But this requires the 3107bis imp=
lementation to be able to parse the stack of (multiple) labels, in order to=
 identify the IP prefix and treat it as withdraw. However, by hypothesis, t=
his speaker is not capable of receiving multiple labels (in short skipping =
labels until it founds the S bit set)

=20
> Perhaps a reasonable approach for 3107bis would be the following:
>=20=20
> - A 3107bis implementation will not send multiple labels to a peer
> unless the Capability has been received from that peer.  (This prevents
> 3107bis implementations from tickling the 'bug' in 3107 implementations.)

Good for me.

> - A 3107bis implementation will accept multiple labels from a peer even
> in the absence of the Capability.

Good for me.
Note that I'm not asking for this route to be installed: I'm fine with trea=
t-as-withdraw. But this does imply that the 3107bis speaker be always capab=
le of parsing a stack of multiple labels, in order to skip the MPLS stack, =
identify the IP prefix, and treat it as withdraw.

Your approach seems along the line of my original email where I was proposi=
ng the following change:
"- Even if the capability is not advertised by both peers, and hence a sing=
le label is expected, all implementations MUST check that the "S" bit (in t=
his first label) is set to 1. If the bit is cleared, the Prefix MUST be ide=
ntified as per RFC 3107/this document and treated as withdraw as defined in=
 RFC 7606."
https://mailarchive.ietf.org/arch/msg/mpls/XNhUSSfwTpnOjNZGlpc7O2j3G1g

=20
> Another approach would be to have a knob that determines whether the
> Capability needs to be used before multiple labels are advertised.

I'm may be missing what you mean, but that alternative approach does not se=
em to address my concern.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.