Hi Jorge,
i was thinking over your comment on fast leave.  Do we really need text around 
that ? Here are my thoughts

  1.  In case of multihoming it would be expected that user does identical 
configuration on both bridge port.  So immediate leave MUST be configured on 
bridge port on redundant PEs.
  2.  In reality IGMP leave would always hit IGMP snooping first. and then 
route would be processed by EVPN. So why can we not leave it to igmp snooping 
to act on Leave locally . so
     *   If immediate leave is configured, snooping can sync leave as well as 
withdraw the join.
     *   on remote side when you get leave, you would see locally bridge port 
is configured to act immediate leave. so it can process it accordingly.

if you think, it is still not clear, may be we can have quick webex & white 
board. To me looks like, we might not need any extra text , local snooping 
implementation should automatically take care of this.

On Mar 21, 2018, at 8:10 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:

Hi Ali,

Yes, the Fast Leave option is used pretty often, and the caveats are no 
different than what we are discussing here. Only directly connected receivers 
or directly connected proxy-CEs.

I'm good with your replies. We are in synch now.
Looking forward to seeing the next revision.

Thank you!

-----Original Message-----
From: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Wednesday, March 21, 2018 at 11:48 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: About draft-ietf-bess-evpn-igmp-mld-proxy

   Hi Jorge,

   Please refer to my comments inline marked w/ "Ali>"

   On 3/21/18, 1:59 AM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:

       Ali and authors,

       As discussed during the BESS session, these are the points that I think 
should be addressed in draft-ietf-bess-evpn-igmp-mld-proxy before WG LC:

       1) Fast Leave text addition

       There are quite a few igmp-snooping implementations in the market that 
support a “Fast Leave” mechanism. EVPN should incorporate/document this too, 
since it is a pretty common use-case.

       Implementations allow the use of "Fast Leave" when the IGMP host is 
directly connected to the PE/NVE or the directly connected CE does igmp-proxy 
(and only in those cases). Fast Leave is a local administrative option on each 
AC, that, if enabled, allows the removal of a (x,G) state immediately after the 
reception of an IGMP Leave message for the (x,G).

   Ali> But the option of "fast-leave" requires for the PE to do host tracking 
and in case of IGMPv2, if there are more than one hosts is sitting behind an 
AC, it is difficult to do host-tracking because of the report suppression in 
IGMPv2 !! So, if used, it needs to be used with caution for only a single host 
for IGMPv2. I can add this "fast-tracking" as an option (MAY) but with the 
caveats that it has !!

       In the email below, I was suggesting that in some cases the IGMP Leave 
synch route can be avoided; however Mankamana made me see that, in the Fast 
Leave procedure, the PE receiving the IGMP Leave on the ES' AC, should always 
send an IGMP Leave sync route with an indication that the (x,G) state must be 
removed immediately. Mankamana suggested MRT=0 (Max Response Time=0) in the 
route could give that indication to the other PEs in the ES.

   Ali> Yes, fast-leave (if used) still need to be synchronized among 
multi-homing PEs (

       Authors, can you please add text about Fast Leave?

   Ali> Since majority of existing implementation support "fast-leave", we can 
add it as an option (MAY) with the caveats that I described above.

       2) Conflicting text about advertising SMET route when there are local 

       "3.2 PE with mixed of attached hosts/VMs and multicast source

       The main difference in here is that when PE2 receives IGMPv3 Join
          from H7 for (S2,G2), it does not advertises it in BGP because PE2
          knows that S2 is attached to its local AC."

       [JORGE] the above is contradicting this previous statement:

       "When the first hop PE receives an IGMPv3 Join for (S,G) on a given
          BD, it advertises the corresponding EVPN Selective Multicast Ethernet
          Tag (SMET) route regardless of whether the source (S) is attached to
          itself or not in order to facilitate the source move in the future."

       [JORGE] I tend to agree with the latter statement. It simplifies the 

   Ali> Since EVPN inherently supports workload mobility, the latter should be 
the default mode of operation. I guess, we can have an option (MAY) for the 
former one.

       3) Confusing text in section 7.1.1 about local-bias:

       "The Originator Router Address is the IP address of Router Originating
          the prefix. It should be noted that using the "Originating Router's
          IP address" field is needed for local-bias procedures and may be
          needed for building inter-AS multicast underlay tunnels where BGP
          next hop can get over written."

       While I agree with the need for this field in Inter-AS, but why would 
you need to check the SMET originating-ip for local bias?

   Ali> It is just inter-AS.

       4) Minor one: description of Maximum Response Time and Sequence number 
missing in section 7.3 and 7.3.1.

       Although both are roughly explained in section 4.2, the description of 
the fields and allowed values is missing in the section that describes the IGMP 
Leave synch route.

   Ali> We'll add it.



       The below email captures the points I made during the adoption, but they 
are no longer valid anyway, so please, disregard. However the above points are 
the ones I think should be addressed now.

       Thank you!

       -----Original Message-----
       From: "Rabadan, Jorge (Nokia - US)" 
       Date: Thursday, February 9, 2017 at 8:30 AM
       To: Thomas Morin 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
       Subject: Re: [bess] Call for adoption: 

           I support this document for WG adoption.

           Having said that, I made a few observations to the authors, and I 
believe they agreed to make some changes in the next revision. The main things 
that I believe should be reflected in the next rev after WG adoption are:

           1- Simplified BGP route encoding
           I discussed with the authors that the Join and Leave synch behavior 
may have been achieved with a single route type, as opposed to the proposed two 
types (type 7 and 8).
           The authors believe it is better to keep both, which is ok, but:
           a) the route type 8 – IGMP leave synch route – should be simplified: 
the max response time and sequence number fields in the route introduce an 
unnecesary complexity and should be removed.
           b) Route type 8 should be optional since: i) It is actually not 
needed for IGMPv1 and 2) It is not needed either if a fast leave mechanism is 
used (see point 2).

           2- Fast Leave addition to the draft
           There are quite a few igmp-snooping implementations in the market 
that support a “Fast Leave” mechanism. EVPN should incorporate/document this 
           Implementations allow the use of "Fast Leave" when the IGMP host is 
directly connected to the PE/NVE and, only in that case is recommended. Fast 
Leave is a local administrative option on the PE, that, if enabled, allows the 
removal of a (x,G) state immediately after the reception of an IGMP Leave 
message for the (x,G). In the case of an ES AC, Fast Leave is only allowed in 
the case that a single IGMP host is multi-homed to the PEs in the ES. When Fast 
Leave is configured in an ES AC, the reception of an IGMP Leave message will 
remove the (x,G) state for the ES AC immediately and will trigger the 
withdrawal of the IGMP State Synch route. Assuming the remote PE is configured 
for "Fast Leave" too, the reception of the (x,G) route withdrawal for the ES 
will remove the (x,G) state completely.

           3- Multicast Flags EC
           The Tunnel Type field looks not big enough for the different tunnel 
types that EVPN can use. I would recommend taking more space from the reserved 
bits and include all the allocated tunnel types in here: 

           Thank you.

           On 1/31/17, 3:58 PM, "BESS on behalf of Thomas Morin" 
<bess-boun...@ietf.org<mailto:bess-boun...@ietf.org> on behalf of 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> wrote:

               Hello working group,

               This email starts a two-week poll on adopting
               draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group 

               Please send comments to the list and state if you support 
adoption or
               not (in the later case, please also state the reasons).

               This poll runs until **February 14th**.

               *Coincidentally*, we are also polling for knowledge of any IPR 
               applies to this draft, to ensure that IPR has been disclosed in
               compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 
5378 for
               more details).

               ==> *If* you are listed as a document author or contributor 
               respond to this email and indicate whether or not you are aware 
of any
               relevant IPR.

               The draft will not be adopted until a response has been received 
               each author and contributor.

               If you are not listed as an author or contributor, then please
               explicitly respond only if you are aware of any IPR that has not 
               been disclosed in conformance with IETF rules.

               Thank you,

               Martin & Thomas
               bess chairs


               BESS mailing list

BESS mailing list

BESS mailing list

Reply via email to