Skip to main content

Last Call Review of draft-ietf-bess-evpn-irb-mcast-07
review-ietf-bess-evpn-irb-mcast-07-rtgdir-lc-lindem-2022-11-17-00

Request Review of draft-ietf-bess-evpn-irb-mcast-07
Requested revision 07 (document currently at 11)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-11-07
Requested 2022-06-24
Requested by Andrew Alston
Authors Wen Lin , Zhaohui (Jeffrey) Zhang , John Drake , Eric C. Rosen , Jorge Rabadan , Ali Sajassi
I-D last updated 2022-11-17
Completed reviews Intdir Telechat review of -09 by Brian Haberman (diff)
Genart Last Call review of -09 by Stewart Bryant (diff)
Secdir Last Call review of -08 by Tirumaleswar Reddy.K (diff)
Rtgdir Last Call review of -07 by Acee Lindem (diff)
Comments
Requesting security and routing area directorate reviews on this one before I push it into last call.
Assignment Reviewer Acee Lindem
State Completed
Request Last Call review on draft-ietf-bess-evpn-irb-mcast by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/P9tSvo7VUcBDCoBVBif1_PqLTDs
Reviewed revision 07 (document currently at 11)
Result Has issues
Completed 2022-11-17
review-ietf-bess-evpn-irb-mcast-07-rtgdir-lc-lindem-2022-11-17-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-irb-mcast-07.txt
Reviewer: Acee Lindem
Review Date: Nov 15th, 2022
IETF LC End Date: Nov 7, 2022
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

The draft is readable per se but the subject matter, Optimized Inter-Subnet
Multicast, is quite complex. The draft covers the mechanisms and procedures for
multicast advertisement and forwarding between tenant-BDs. Additionally, a
single line in the abstract includes procedures to accommodate multicast
traffic external to the tenant domain results in very dense specification of
various interworking with other multicast domains. These interworking scenarios
build on the OISM gateway functionality specified early in the document. The
cascaded complexity probably explains the number of directorate members who
declined the review request. Given the complexity, this is a document that
could really benefit from implementation experience.

Major Issues: None

Minor Issues:

   1. The concept of multicast packets and, in some cases, advertisements being
   sent
      "Up" or "Down" the IRB interface seemed confusing to me. I'd of thought
      the IRB interfaces would be described in terms of transmission or
      reception by the IRB L3 Routing instance. In any case, the usage must be
      described in the terminology
     section is not intuitive even though one can reverse engineer what is
     meant.

   2. The Section 6 interworking scenarios could benefit from some ASCII art for
       visual reference of the various gateway and domain scenarios.

   3. Since this is Last Call review, it seems references to topics that may be
      covered in future revisions of the draft should be removed.

   4. In section 4.1.1, why are ACs that are not using IGMP/MLD automatically
      added to the OIF list for all flows? I'd think an administrator would
      have to run IGMP/MLD on ACs on which multicast traffic is desired.

   5. In section 4.2, how can one lookup S in the MAC-VRF(s) of a tenant domain?
      S is the IP address of the source - not a MAC address. This needs to be
      clarified.

   6. In section 6.1.2.2.1, it seems a bit odd to have the MEG import and export
      unicast routes dependent on whether or not there are hosts in the EVPN
      transmitting multicast flows? What route should be exported – a host route
      to the source or the corresponding subnet route from the EVPN IP RIB? Why
      isn't the AC source route covered by a subnet route for the corresponding
      tenant BD?

   7. Section 6.2, I reworded some text that didn't parse at all. I rewrote as:

      Furthermore, even if a particular AC is part of that BD, the PE SHOULD NOT
      transmit an IGMP/MLD Join on that AC unless there is an external PIM route
      attached via that AC

Nits:

   1. Saying a route is "about" a BD is awkward. Please use "pertains to" or
      "associated with".

   2. Avoid the usage of "we" and use the infinitive instead. For example,
      "It is RECOMMENDED", rather than "We RECOMMEND". I didn’t fix all these
      In the diff.

   3. Avoid putting extra parentheses around single references - I've fixed this
      in the diffs.

   4. The draft uses various terms for assuring reception of multicast
      traffic - "draw", "pull", and "must see".  I'd use "receive" consistently
      as in the diff.

   5. Use "sent on ..." rather than "sent out ...".

See attached RFC diff for more suggested editorial changes.

Thanks,
Acee