Early Review of draft-ietf-babel-source-specific-01
review-ietf-babel-source-specific-01-rtgdir-early-halpern-2017-11-04-00

Request Review of draft-ietf-babel-source-specific
Requested rev. no specific revision (document currently at 04)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-11-30
Requested 2017-10-28
Requested by Donald Eastlake
Other Reviews
Comments
QA review.
Review State Completed
Reviewer Joel Halpern
Review review-ietf-babel-source-specific-01-rtgdir-early-halpern-2017-11-04
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/aGrBukurxTbj4MFx_f37zOSf7ao
Reviewed rev. 01 (document currently at 04)
Review result Not Ready
Draft last updated 2017-11-04
Review completed: 2017-11-04

Review
review-ietf-babel-source-specific-01-rtgdir-early-halpern-2017-11-04

This is a routing directorate early review.  It is intended to assist the working group and the routing ADs in processing the advancing document.

This document is nearly ready for publication as a Proposed Standard RFC.

Isses:
Major: N/A

Moderate:
Please address the issues reported by id-nits.  Specifically, repair the abstract and add an explicit reference to RFC 2119

Please add an informative reference to draft-ietf-rtgwg-dst-src-routing indicating the the routing policy described here aligns with the ongoing work in the routing area for how to handle source specific routes.  This could be added in section 4.

The base Babel (bis) specification does not talk about the handling of duplicate sub-TLVs.  Are multiple source-specific sub-TLVs allowed on a given destination prefix advertisement?  Please indicate what the intended / permitted handling is in the text.

Minor:
As far as I can tell, the behavior described in section 3.1 for 0/0 source addresses and their relationship to routes without source addresses is correct and matches draft-ietf-rtgwg-dst-src-routing.  However, the wording is sufficiently different as to cause this reader to wonder about it.  If practical consider additional wording to make the alignment clear.  This would seem to apply to 3.2 as well.  The most obvious fix is to say that a Babel node supporting this extensions treats all advertisements received without a source specific prefix as if they had the 0/0 source prefix?  (The text in section 5.2 says this.  I would like to see it in section 3.1)