John - Thank you for reminding folks of RFC7120. It exists due to lots of past pain
Bess WG Please go toward the new code point scenario John Scudder describes and RFC7120 recommends. If at some point changes that are not backward compatible are nonetheless required, a decision needs to be made as to whether previously allocated code points must be deprecated (see Section 3.3 for more information on code point deprecation). The considerations include aspects such as the possibility of existing deployments of the older implementations and, hence, the possibility for a collision between older and newer implementations in the field. Let’s not tempt fate for melt-downs. Now, more than ever. I look forward to John’s write-up of the alternative. Sue Hares IDR co-chair. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John Scudder Sent: Friday, April 24, 2020 6:01 PM To: Mankamana Mishra (mankamis) Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; bess@ietf.org Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change) Hi All, Regarding the proposal to remove the Leave Group Synchronization field from the Multicast Leave Synch Route, the current proposal is inadequate. Below I discuss why, and provide an alternate suggestion. For those who don’t want to read my wall of text, my key motivation is simple: - The current proposal is a ticking time bomb because it leaves in the field a situation where two incompatible implementations can exist undetectably. And my proposal boils down to two things: - For the new format NLRI that omits the field, allocate a new code point. Deprecate [*] code point 8 going forward. - Optionally provide a somewhat more sophisticated interworking option for backward compatibility. Nitty-gritty below including considerations for how to transition from code point 8 to the TBD code point. As far as I can tell, there is consensus that the field is not useful. That’s a good start. The customary way of dealing with this would be to mark the field “reserved”, but evidently there are multiple divergent implementations in the field that use different formats for the Multicast Leave Synch Route, some that include the field and some that don’t. (I should disclose here that my employer’s implementation is in the “include” camp.) There is an obvious interoperability problem here: BGP implementations are required to sanity-check the NLRI they receive (see RFC 4271 section 6.3, RFC 4760 section 7, and RFC 7606 section 5.3). This checking is required whether or not there’s a route target present to cause the router to consume the NLRI, the standards require the NLRI to be checked regardless. The consequence of malformed NLRI is a session reset. This turns out to be a difficult problem in BGP, even though we’ve worked to reduce the number of error cases that require a session reset, malformed NLRI are one of the very bad cases we can’t paper over. The IDR WG worked on this very hard during the development of RFC 7606, it is a real problem. When an implementation expects one NLRI format and receives another, that’s a malformed NLRI, and can be expected to cause a session reset. To leave this situation in place would be BGP protocol malpractice. As far as I can tell, this means it is only through dumb luck that we have had two different NLRI formats in the wild without a network meltdown. This seems like a ticking time bomb situation. The implementations are in the field already, we can’t just stamp our feet and say “you should have followed the spec” and make the problem go away. So we have to think about how to migrate to one agreed format, whatever it may be. (The idea that interoperability concerns can be addressed by simply never mixing old and new implementations in the same network can be dismissed out of hand. That amounts to “there are no interoperability problems if there’s no interoperation”, and are we not a standards organization, and is our goal not interoperability?) Let’s take as a given that the agreed format will end up being the one that removes the Leave Group Synchronization field. Since something has to change, it may as well be the thing that removes the vestigial field. The cleanest solution is to keep the format depicted in draft -04 (and its predecessors) on code point 8, and to allocate a new code point for the new format. The old code point would be deprecated, the new code point would be the standardized version. It turns out that moving code points is exactly the strategy prescribed (or at least strongly recommended) by RFC 7120 section 3.2: If at some point changes that are not backward compatible are nonetheless required, a decision needs to be made as to whether previously allocated code points must be deprecated (see Section 3.3 for more information on code point deprecation). The considerations include aspects such as the possibility of existing deployments of the older implementations and, hence, the possibility for a collision between older and newer implementations in the field. There are existing deployments of older implementations in our case, of course, so this advice applies. Keep in mind that RFC 7120 is the process that was used to get code point 8 to begin with, so we pretty much have made a contract to follow its recommendations. Code point migration, from the deprecated value 8 to the TBD standardized value, is a little bit of an annoyance but the general methodology is well-known; this is not rocket science. It looks something like: new implementations have to be able to consume both the old format and the new. By default they generate the old. Once the entire network is known to be upgraded to an RFC-compliant version, the operator configures them to generate the new. In the future, the default can be changed, in the farther future the support for the old code point can be removed (this end state tends to be aspirational in my experience, but we can dream). I think this should be the solution that is standardized. It keeps the standard as simple as possible and provides the format the WG desires (at least, per the email so far). That still leaves open the question of interoperability between the pre-standard implementations currently in the field, the ones that generate NLRI that follows the format specced in -04 and the ones that don't. Mankamana mentions “RR must accept both” as the interoperability solution; I think this is necessary but not sufficient because it still doesn’t protect against the potential for catastrophic failure as I discuss in my first few paragraphs. Rather, I would say that any implementation that wants to interoperate with prestandard versions has to provide a configuration option to tell it what version of the NLRI to emit towards any given peer. It can and should still consume both, but it has to know what kind to emit. I’m not sure whether this needs to go in the standard. Maybe it should go in an appendix. If the WG likes this approach I’d be glad to send text, if wanted. Thanks, —John [*] Note that “deprecate” basically means “you are encouraged to stop using this and start using the standardized code point”. I can find a citation if there’s any dispute about this, but mostly, experience has shown me that people tend to have funny ideas about this word, so I thought I’d put in a line about it. On Apr 23, 2020, at 2:31 AM, Mankamana Mishra (mankamis) <mankamis=40cisco....@dmarc.ietf.org> wrote: [External Email. Be cautious of content] All, Post WGLC before IETF Singapore it came to our notice that there were implementation discrepancies of this draft ( <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04*section-9.3__;Iw!!NEt6yMaO-gk!Wwfj4O6fXrfitRyou2Z56AntEHyd1ekok0U4vGsCrmLsm0RzvCjL0g0DqObMwA$> https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04#section-9.3). Though draft had NLRI definition as +--------------------------------------------------+ | RD (8 octets) | +--------------------------------------------------+ | Ethernet Segment Identifier (10 octets) | +--------------------------------------------------+ | Ethernet Tag ID (4 octets) | +--------------------------------------------------+ | Multicast Source Length (1 octet) | +--------------------------------------------------+ | Multicast Source Address (variable) | +--------------------------------------------------+ | Multicast Group Length (1 octet) | +--------------------------------------------------+ | Multicast Group Address (Variable) | +--------------------------------------------------+ | Originator Router Length (1 octet) | +--------------------------------------------------+ | Originator Router Address (variable) | +--------------------------------------------------+ | Leave Group Synchronization # (4 octets) | +--------------------------------------------------+ | Maximum Response Time (1 octet) | +--------------------------------------------------+ | Flags (1 octet) | +--------------------------------------------------+ Where there was Leave Group Synchronization number as part of NLRI. But two implementation were 1. With this field as part of NLRI 2. Without this field as part of NLRI Implementation survey As of 2019: Since it came to notice that at least there are two implementation which would not interop, we did try to take survey of other implementation. We tried it with IETF & Nanog forum. We reached out to some of vendors directly as well. And implementation were Cisco – Without Seq number Juniper – With Seq number Arista - with and without sequence number Apart from these vendors, we did not get response from any one else who had implemented these routes. Before IETF 106 (Singapore) there were couple of discussion among authors & other vendors. And it was evident that there are two implementation which would not interop as is. And Sequence number for IGMP does not have any value or need. And majority of vendors were ok to remove this field from NLRI as there is no practical use case. So one of the proposal was to remove the field. And to make sure we interop with old version proposal was to 1. Remove Seq number from NLRI 2. RR MUST accept both len of NLRI IETF 106 Update : These changes were presented in IETF 106 Singapore as well. Implementation Changes post IETF106, As of Today: Nokia - Implemented without Seq number, and RR supports both length Cisco - Modified implementation to make sure as RR we support both len Arista - Already had this implementation to support both len. Update in Draft : +--------------------------------------------------+ | RD (8 octets) | +--------------------------------------------------+ | Ethernet Segment Identifier (10 octets) | +--------------------------------------------------+ | Ethernet Tag ID (4 octets) | +--------------------------------------------------+ | Multicast Source Length (1 octet) | +--------------------------------------------------+ | Multicast Source Address (variable) | +--------------------------------------------------+ | Multicast Group Length (1 octet) | +--------------------------------------------------+ | Multicast Group Address (Variable) | +--------------------------------------------------+ | Originator Router Length (1 octet) | +--------------------------------------------------+ | Originator Router Address (variable) | +--------------------------------------------------+ | Leave Group Synchronization # (4 octets) | +--------------------------------------------------+ | Maximum Response Time (1 octet) | +--------------------------------------------------+ | Flags (1 octet) | +--------------------------------------------------+ 1. Removed Seq number from EVPN route type 8 2. Added text stating older version of draft had 4 byte extra and RR MUST accept and reflect both length. WGLC : It had been discussed with chairs, and agreed upon one more short WGLC once changes are posted Before publishing the draft, we wanted to make sure if there are any other vendor have any concern. Mankamana _______________________________________________ BESS mailing list <mailto:BESS@ietf.org> BESS@ietf.org <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Wwfj4O6fXrfitRyou2Z56AntEHyd1ekok0U4vGsCrmLsm0RzvCjL0g0ZRWx4yw$> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Wwfj4O6fXrfitRyou2Z56AntEHyd1ekok0U4vGsCrmLsm0RzvCjL0g0ZRWx4yw$
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
