Re: [bess] IGMP proxy post WGLC update - please provide feedback

[Gyan Mishra <[e-mail]>]

Mankamana 

What would be the use case for use of leave group 32 bit sequence number usage?  

As you mentioned their maybe some vendors that have implemented and if they did what is the use case?

So the 32 bit field would only be present if the vendor uses it and would not for those that don’t. But for vendors to interoperability they would have to not use the field to work with vendor not using the field.  Is that correct?

Also had a question about this section.

Normally for a selective p-tree S-PMSI mvpn rib would have *,G for ASM and S,G for SSM to receive the selective data MDT constrained multicast so now sure when we would need a multicast Default *,* all multicast join or leave group route.  Since Inclusive PMSI p-tree covers multicast Default MDT to all PEs for low bandwidth streams I would think that covers the default multicast route scenario within the same domain.  I can see maybe going between EVPN multicast domains but not used within the same domain.

9.1.2 Default Selective Multicast Route If there is multicast router connected behind the EVPNdomain, the PE MAY originate a default SMET (*,*) to get all multicast traffic in domain.


Thank you 

Gyan

Sent from my iPhone

> On Nov 1, 2019, at 2:50 PM, Mankamana Mishra (mankamis) <[e-mail]> wrote:
> 
> Hi All,
> 
> Thanks Jorge for catching & provide feedback .  Currently section 9.3 of the draft defines NLRI for Leave Sync Route. Which is defined as 
> 
> https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04#section-9.3
> 
>              +--------------------------------------------------+
>              |  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)                                 |
>              +--------------------------------------------------+
> 
> 
> Currently there is no much detail added about Leave Group Sequence number (4 Octets). After having multiple discussion among authors, we do not think there is real use case for sequence number in this route. And we propose to remove the filed from NLRI. 
> 
> 
> Usual Deployment:  This route is limited to multi-home peer who are part of same ES. Most of deployment would have same vendor peers , so we do not see interop issue between different vendor (one with Sequence number and one without sequence number)
> 
> 
> RR Behavior to accommodate early implementation 
> There may be an implementation which has included Sequence number in implementation. So RR MUST accept both length of NLRI (With sequence number and without sequence number). 
> 
> 
> 
> Change to Draft: 
> Leave Group Synchronization would be removed from section 9.3
> Text would be added that RR MUST accept & reflect EVPN route type 8 with current length and with current length +4
> 
> 
> 
> There is plan to go over this change in room as well in Singapore . 
> 
> Mankamana 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess