> From: Eric C Rosen [mailto:[email protected]] > Sent: Thursday, March 24, > 2016 7:14 PM > On 3/24/2016 11:17 AM, [email protected] wrote: > > I don't see why the IETF would want to create a bis which is not > compatible with the original RFC, > > It's typical in a bis draft to remove features that haven't been used.
- Not by making it non backward compatible with the current RFC, in a way which is very disruptive (BGP session shut and the session will stay down or keep cycling) - On a side note, rfc3107bis does not remove the feature to advertise multiple labels. > > especially since this incompatibility may be very disruptive in existing > networks. > > My belief is that existing deployments don't use or support the multiple > labels feature, Do you have data that support this? i.e. there are no deployments and no single implementation which advertise multiple labels? That sounds very hard to prove. Hence there will be a risk, and this risk is bared by network operators. I don't see a reason why I would take that risk. > and that any attempt to use it as specified in RFC3107 > will itself be disruptive to existing networks, IMHO RFC3107 is clear enough with respect to the encoding of multiple labels inside the BGP UPDATE. I fail to see which point would not be clear to someone. But this is a theoretical discussion since so far, AFAIK, no major implementation has stated that they would not be able to understand NLRI received with multiple labels, and hence would shutdown the BGP session. So I'm waiting for those hypothetical implementations to declare themselves. Then we'll see if they are compliant with RFC 3107 or if this is rather an implementation issue. > because it will have > interoperability issues and unpredictable results. 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. > Adding the "multiple > labels" capability is a way to make the feature deployable without > causing disruption. I agree with this point. (although one could also discuss this, at it seems a way to accommodate non-compliant implementation) > > "As far as I know" all the implementations claim to be compliant with RFC > 3107, i.e. are expected to be able to receive multiple labels. > 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. And hence there is no need to make a 3107bis which is non backward compatible with RFC 3107. > If you do have a deployed implementation that can receive multiple > labels, what would you expect it to do with those labels? A priori, the sender said "For FEC X, uses this label stack", so any behavior compliant with this information e.g. what is described in your bis draft https://tools.ietf.org/html/draft-rosen-idr-rfc3107bis-00#section-4 > RFC 3107 > doesn't say anything about what to do in this case, it just provides an > encoding. RFC3107 describes the BGP encoding, aka "bits on the wire". It does describe how to send and receive multiple labels from a BGP standpoint. This does not involve shutting down the BGP session when multiple labels are received. > Have you ever tried to use the "multiple labels" feature? If you mean by following RFC 3107, I'm not seeing why the BGP session would need to be shutdown. If you mean that some non-compliant implementation do not work, well let's fix them. And I don't see how making a rfc3107bis non backward compatible with RFC 3107 would improve the situation. _________________________________________________________________________________________________________________________ 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. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
