Early Review of draft-ietf-mpls-seamless-mcast-15

Request Review of draft-ietf-mpls-seamless-mcast
Requested rev. no specific revision (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-02-03
Requested 2015-01-26
Authors Yakov Rekhter, Eric Rosen, Rahul Aggarwal, Thomas Morin, Irene Grosclaude, Nicolai Leymann, Samir Saad
Draft last updated 2015-02-03
Completed reviews Genart Last Call review of -15 by Vijay Gurbani (diff)
Secdir Last Call review of -15 by Joseph Salowey (diff)
Rtgdir Early review of -15 by Stig Venaas (diff)
Assignment Reviewer Stig Venaas 
State Completed
Review review-ietf-mpls-seamless-mcast-15-rtgdir-early-venaas-2015-02-03
Reviewed rev. 15 (document currently at 17)
Review result Has Issues
Review completed: 2015-02-03



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 ‚Äč 


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 

Last Call comments that you receive, and strive to resolve them through 

discussion or by updating the draft.

Document: draft-ietf-mpls-seamless-mcast-15
Reviewer: Stig Venaas
Review Date: 2 February 2015
IETF LC End Date: 2 February 2015
Intended Status: Proposed Standard

The document is fairly well written. I only found minor editorial
issues, plus potentially a missing IANA action.

The document states in e.g.
6.2.2. Leaf A-D Route for Global Table Multicast
that the RD in the MCAST-VPN NLRI is set to all 1s for (*,G)-state.
Is this use of RD defined in another document? Shouldn't RD type
65535 then be assigned for this purpose in


Minor issues:

Section 3:
The reader is suppose to be familiar with MVPN procedures and

although this by no means imply that this alternative

5.1.2. Routes re-avertise by PE or ASBR
5.2.2. Routes re-avertise by PE or ASBR