Subject: Re: [Gen-art] Gen-ART telechat review of draft-ietf-l3vpn-2547bis-mcast-09

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 16 Dec 2009 11:54:21 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ). 

Please wait for direction from your document shepherd or AD before
posting a new version of the draft. 

Document: draft-ietf-l3vpn-2547bis-mcast-09
Reviewer: Pete McCann
Review Date: 16 Dec 2009
IESG Telechat date: 17 Dec 2009 

Summary: Ready

Major issues: none
Minor issues: 
There was no change to the one minor issue I had pointed out below,
but I think the comment was a misunderstanding on my part.  I am ok
with the current text.

Nits/editorial comments: 

Nits still present:

> Section 10:
>    share tree.
> SHOULD BE:
>    shared tree.

McCann Peter-A001034 wrote:
> Sorry this is a day late...
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).   
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. 
> 
> Document: draft-ietf-l3vpn-2547bis-mcast-08
> Reviewer: Pete McCann
> Review Date: 2009-09-09
> IETF LC End Date: 2009-09-08
> IESG Telechat date: unknown
> 
> Summary: Ready for publication
> 
> Major issues: none
> 
> Minor issues:
> 
> Section 12.1.2, Encapsulation in IP.  This isn't a viable option for
> aggregated PMSIs, right?  You may want to point this out with some
> text.  
> 
> Nits/editorial comments:
> 
> 2.1.2:
>    procedures for carry MVPN data traffic SHOULD BE:
>    procedures for carrying MVPN data traffic
> 
> Section 4:
>    route.If any other
> SHOULD BE:
>    route. If any other
> 
>    sender sites set
> SHOULD BE:
>    Sender Sites set
> 
>    receiver sites set
> SHOULD BE:
>    Receiver Sites set
> 
>    This syntax of this
> SHOULD BE:
>    The syntax of this
> 
>    are are unique
> SHOULD BE:
>    are unique
> 
> Section 5.1.3:
>    This results in a set of pairs of <route, upstream PE, upstream
> RD>. 
> SHOULD BE:
>    This results in a set of triples of <route, upstream PE, upstream
> RD>. 
> 
> Section 5.2.1:
>    as a integral part
> SHOULD BE:
>    as an integral part
> 
> Section 5.3.4:
>    over from some
> SHOULD BE:
>    from some
> 
> Section 6.1.1:
>    to those data packets belong.
> SHOULD BE:
>    to which those data packets belong.
> 
> Section 6.1.2:
>    If the PE tunnel technology requires tunnels to be build SHOULD BE:
>    If the P-tunnel technology requires tunnels to be built
> 
> Section 6.3.2:
>    unwanted MVPNs hat a particular PE
> SHOULD BE:
>    unwanted MVPNs that a particular PE
> 
> Section 6.3.3:
>    originated the ingress PEs.
> SHOULD BE:
>    originated by the ingress PEs.
> 
> Section 6.4.3:
>    used to carry a the set
> SHOULD BE:
>    used to carry the set
> 
> Section 6.4.5:
>    over an Unicast Tunnel
> SHOULD BE:
>    over a Unicast Tunnel
> 
> Section 7:
>    i.e,. for
> SHOULD BE:
>    i.e., for
> 
> Section 7.2:
>    bound to the to the
> SHOULD BE:
>    bound to the
> 
> Section 7.3:
>    not have send
> SHOULD BE:
>    not have sent
> 
> Section 8.1.3.2.1:
>    The F bit is set to 0.
> There is no F bit in the packet diagram.  Is this something inherited
> from the PIM structure?  Suggest adding a reference. 
> 
> Section 8.2.1.1:
>    This RD MUST be
>    of Type 0, MUST embed the autonomous system number of the AS.
> SHOULD BE:
>    This RD MUST be
>    of Type 0, and MUST embed the autonomous system number of the AS.
> 
> Section 8.2.1.2.1:
>    A-D route if
> SHOULD BE:
>    A-D route, if
> 
> Section 8.2.1.2.2:
>    carries a AS MVPN membership tree ,
> SHOULD BE:
>    carries an AS MVPN membership tree,
> 
> Section 10:
>    share tree.
> SHOULD BE:
>    shared tree.
> 
> Section 11:
>    procedures is very complicated,
> SHOULD BE:
>    procedure is very complicated,
> 
> Section 11:
>    the
>    the standard LAN-based DF
> SHOULD BE:
>    then
>    the standard LAN-based DF
> 
> Section 11:
>    that use the
> SHOULD BE:
>    that the
> 
> Section 11.2.2:
>    The the root
> SHOULD BE:
>    If the root
> 
> Section 12.3.2:
>    As will be discussed in section 11,
> SHOULD BE:
>    As was discussed in section 11,
> 
> Section 12.3.2:
>    then unless the procedures of section
>    12.2.3 are being used,
> There is no section 12.2.3.
> 
> Section 12.3.2:
>    the encapsulations of section 11.2 MUST be used.
> Confused - section 11.2 doesn't talk about encapsulations.
> 
> Section 13:
>    BGP MVPN-BGP],
> SHOULD BE:
>    BGP [MVPN-BGP],
> 
> Section 13:
>    the way in that
> SHOULD BE:
>    the way in which
> 
> Section 13:
>    If the amount of customer multicast
>    activity exceed expectations,
> SHOULD BE:
>    If the amount of customer multicast
>    activity exceeds expectations,