I'm OK with the changes mentioned below (remove the field and require RR to accept both lengths).
I think RR accepting both lengths should be a SHOULD rather than a MUST (it would be more accommodative of implementations), but I could probably live with the MUST. Anoop On Thu, Apr 23, 2020 at 1:16 PM Keyur Patel <[email protected]> wrote: > 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)" < > [email protected]> > *Date: *Thursday, April 23, 2020 at 1:18 AM > *To: *"Mankamana Mishra (mankamis)" <[email protected]>, > "[email protected]" <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *Subject: *Re: [bess] IGMP / MLD Proxy Draft update (NLRI change) > *Resent-From: *<[email protected]> > *Resent-To: *<[email protected]>, <[email protected]>, <[email protected]>, > <[email protected]>, <[email protected]> > *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 <[email protected]> on behalf of "Mankamana Mishra > (mankamis)" <[email protected]> > *Date: *Thursday, April 23, 2020 at 8:32 AM > *To: *"[email protected]" <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
