I agree with Jorge and Mankamana. We don’t need leave group sequence number. I would keep it out for now.
Regards, Keyur From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com> Date: Thursday, April 23, 2020 at 1:18 AM To: "Mankamana Mishra (mankamis)" <mankamis=40cisco....@dmarc.ietf.org>, "bess@ietf.org" <bess@ietf.org> Cc: "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: <saja...@cisco.com>, <stho...@cisco.com>, <ke...@arrcus.com>, <jdr...@juniper.net>, <w...@juniper.net> Resent-Date: Thursday, April 23, 2020 at 1:18 AM Thank you Mankamana. From Nokia’s perspective I confirm your reference below. We implemented it without a Seq number based on what we thought was that agreement among authors pre-IETF106. Just wanted to mention that there were never any procedures specified for the sequence number in the draft. So even if two implementors had attempted to implement that sequence number, there is no guarantee they could have interoperated with each other. So the Sequence number reference must go from the draft anyway. To me, the real discussion is if removing those 4 bytes from the NLRI length will cause issues. My take is that, given the implementations that we have in the field, the proposal for the RR to accept both lengths seems like the better practical option. And since that field cannot be a sequence number anymore, it should be removed from the draft as soon as possible to avoid confusion for future implementors. But I would also like people to share their concerns here. Thanks. Jorge From: BESS <bess-boun...@ietf.org> on behalf of "Mankamana Mishra (mankamis)" <mankamis=40cisco....@dmarc.ietf.org> Date: Thursday, April 23, 2020 at 8:32 AM To: "bess@ietf.org" <bess@ietf.org> Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org> Subject: [bess] IGMP / MLD Proxy Draft update (NLRI change) 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). 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 https://www.ietf.org/mailman/listinfo/bess
