Hi Ali, Your option 1 is substantially what I proposed, the sole difference being that I propose following normal IETF procedure and moving to a new code point. Without moving to a new code point, the only thing standing in the way of a catastrophe is luck and good operational procedures, hardly a robust option. With moving to a new code point, there’s literally no way to trigger this scenario.
It’s the safer thing to do and the right thing to do. The code’s not hard, I’m tempted to call it trivial. We do this kind of thing all the time — one code point for prestandard, another for the standardized version. I see no downside, all upside. Regarding RT-constrain, I don’t follow your reasoning for how it guarantees safety in a mixed network. —John On Apr 26, 2020, at 3:21 PM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: John, Thanks for your insightful input and suggestion. We have had other situations similar to this in the past and we have resolved them by the consensus and without having a “ticking time bomb” to cause a network meltdown. One such situation was the need to extend RT-4 to add the originator router’s address which changed the length of RT-4 route. At the time there were pre-RFC implementation from several vendors already deployed in different networks and the vendors decided to go with the new RT-4 format and upgrade to it and making sure the interoperability is based on standard RFC and not pre-standard version. That worked fine as I and other colleagues from other vendors (including yours) are not aware of any issues regarding that update. We have a lesser situation in here because of the following implementation status: 1. Some vendors have implemented both format 2. Some vendors have allowed for both lengths (including my vendor) to avoid malformed NLRI. Allowing for both length doesn’t mean supporting both format but rather both lengths so that the PE that doesn’t need to import the route, doesn’t interpret the old format as malformed. 3. Vendors that haven’t implemented it, prefer new format 4. AFAIK, there is only a single vendor that implemented the v4-only format So, based on the current data, I think we can have the following two options that IMO are simpler: 1. Just go with the new format and for multi-vendor deployment, making sure the new format is used. Considering the current deployments situations where intra-DCs and intra-sites are done using a single vendor but different vendors are used for different sites and DCs, this can be feasible. Maybe that’s why we haven’t run into the interop issues because for the current deployment model. 2. Accommodate both lengths (i.e., bullet b) above) and turn on RT-constraint on the PEs that support old RT-8 format. This way, the RR can properly reflect both RT-8 formats. The PEs supporting the new format can be inserted into the network without issue. And the PEs supporting the old format can be gradually migrated to the new format. I should just mention that for RT-4 changes that all the vendors did long time ago, the approach (1) was adopted. Regards, Ali From: John Scudder <j...@juniper.net> Date: Friday, April 24, 2020 at 3:01 PM To: "Mankamana Mishra (mankamis)" <manka...@cisco.com> Cc: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org> Subject: Re: [bess] IGMP / MLD Proxy Draft update (NLRI change) Resent-From: <alias-boun...@ietf.org> Resent-To: Cisco Employee <saja...@cisco.com>, <stho...@cisco.com>, <ke...@arrcus.com>, <jdr...@juniper.net>, <w...@juniper.net> Resent-Date: Friday, April 24, 2020 at 3:01 PM 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<mailto: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://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04#section-9.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04*section-9.3__;Iw!!NEt6yMaO-gk!Wwfj4O6fXrfitRyou2Z56AntEHyd1ekok0U4vGsCrmLsm0RzvCjL0g0DqObMwA$>). 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 BESS@ietf.org<mailto: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
