Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis

[<[e-mail]>]

> From: Eric C Rosen [mailto:[e-mail]]
> Sent: Friday, April 01, 2016 1:44 PM
> 
> On 3/25/2016 7:25 AM, [e-mail] 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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.