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).
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.
Authors, can you please add text about Fast Leave?
--------------------------------------------------------------------------------
2) Conflicting text about advertising SMET route when there are local sources
"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 procedure.
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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!
Jorge
-----Original Message-----
From: "Rabadan, Jorge (Nokia - US)" <jorge.raba...@nokia.com>
Date: Thursday, February 9, 2017 at 8:30 AM
To: Thomas Morin <thomas.mo...@orange.com>, "bess@ietf.org" <bess@ietf.org>
Cc: "draft-sajassi-bess-evpn-igmp-mld-pr...@ietf.org"
<draft-sajassi-bess-evpn-igmp-mld-pr...@ietf.org>
Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01
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 too.
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:
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#pmsi-tunnel-types
Thank you.
Jorge
On 1/31/17, 3:58 PM, "BESS on behalf of Thomas Morin"
<bess-boun...@ietf.org on behalf of 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 item.
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 that
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 please
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 from
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 yet
been disclosed in conformance with IETF rules.
Thank you,
Martin & Thomas
bess chairs
[1]
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
