> From: Eric C Rosen [mailto:ero...@juniper.net]
> Sent: Friday, April 01, 2016 1:44 PM
>
> On 3/25/2016 7:25 AM, bruno.decra...@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.
>
> 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 would
need explicit statement from everyone, which looks impossible.
> > 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.
>
> 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.
Agreed. But between 2 3107 speakers, we can determine which implementation has
a bug. Whereas between a 3107 speaker and 3107bis speaker, both implementations
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.
> > If you mean that some non-compliant implementation do not work, well
> let's fix them.
>
> 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.
> 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
implementation 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, this
speaker is not capable of receiving multiple labels (in short skipping labels
until it founds the S bit set)
> Perhaps a reasonable approach for 3107bis would be the following:
>
> - 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
treat-as-withdraw. But this does imply that the 3107bis speaker be always
capable 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 proposing
the following change:
"- Even if the capability is not advertised by both peers, and hence a single
label is expected, all implementations MUST check that the "S" bit (in this
first label) is set to 1. If the bit is cleared, the Prefix MUST be identified
as per RFC 3107/this document and treated as withdraw as defined in RFC 7606."
https://mailarchive.ietf.org/arch/msg/mpls/XNhUSSfwTpnOjNZGlpc7O2j3G1g
> 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 seem
to address my concern.
_
