Subject: Review of draft-ietf-l3vpn-mvpn-considerations

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 28 Feb 2010 11:36:28 -0800

I reviewed the document draft-ietf-l3vpn-mvpn-considerations in general

and for its operational impact.

Operations directorate reviews are solicited primarily to help the area

directors improve their efficiency, particularly when preparing for IESG

telechats, and allowing them to focus on documents requiring their attention

and spend less time on the trouble-free ones.

Improving the documents is important, but clearly a secondary purpose.

A third purpose is to broaden the OpsDir reviewers' exposure to work going

on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to

raise issue with a document. The reviews may, however, convince individual

IESG members to raise concern over a particular document requiring further

discussion. The reviews, particularly those conducted in last call and

earlier, may also help the document editors improve their documents.

--

Review Summary: 

Intended status:  Doesn't say 

   More that one set of mechanisms to support multicast in a layer 3

   BGP/MPLS VPN has been defined.  These are presented in the documents

   that define them as optional building blocks.

   To enable interoperability between implementations, this document

   defines a subset of features that is considered mandatory for a

   multicast BGP/MPLS VPN implementation.  This will help implementers

   and deployers understand which L3VPN multicast requirements are best

   satisfied by each option.

Is the document readable?

   Yes. 

Does it contain nits?

   While there were no errors, idnits did spit out quite a few warnings:

idnits 2.12.01 

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt:

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(366): Found possible IPv4
address '3.4.1.1' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(369): Found possible IPv4
address '3.4.1.2' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(372): Found possible IPv4
address '3.4.1.3' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(531): Line has weird
spacing: '...   or   the us...'

  Checking boilerplate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):

----------------------------------------------------------------------------

  == You're using the IETF Trust Provisions' Section 6.b License Notice from

     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See

     http://trustee.ietf.org/license-info/)

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed

     Standard

  Checking nits according to http://www.ietf.org/id-info/checklist :

----------------------------------------------------------------------------

  == There are 3 instances of lines with non-RFC3330-compliant IPv4
addresses

     in the document.  If these are example addresses, they should be
changed.

  Miscellaneous warnings:

----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references

     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC4364' is mentioned on line 747, but not

     defined

     'Options A, B and C (as described in section 10 of [RFC4364]) are...'

  == Outdated reference: A later version (-10) exists of

     draft-ietf-l3vpn-2547bis-mcast-09

  == Outdated reference: A later version (-13) exists of

     draft-rosen-vpn-mcast-12

  == Outdated reference: A later version (-10) exists of

     draft-ietf-pim-sm-linklocal-08

     Summary: 0 errors (**), 7 warnings (==), 0 comments (--).

Is the document class appropriate?

   No class is stated, so I can't tell.   

Is the problem well stated?

   Yes. 

Is the problem really a problem?

   Yes. 

Does the document consider existing solutions?

   Yes.  The document is devoted to evaluating existing solutions

   against the requirements. 

Does the solution break existing technology?

   No.  The document attempts to make the best choice among

   competing alternatives for each requirement.  

Does the solution preclude future activity?

   No. 

Is the solution sufficiently configurable?

   The goal of this document is reduce potential interoperability

   problems, so that it is necessary to reduce "choice" in the service

   of that goal.  I don't believe that there has been any meaningful

   loss in configurability as a result of that.  

Can performance be measured? How?

   Mechanisms for measuring multicast routing and forwarding performance

   should be applicable here. 

Does the solution scale well?

   The document does discuss intra as well as inter-AS deployment options,

   and even gets into discussion of inter-provider multicast VPNs in Section

   3.5.  So the recommendations span a variety of deployment scenarios and

   usage scales.  

Is Security Management discussed? 

   While there is no security considerations section to speak of, 

   Section 3.3.5 does get into discussion of security and robustness

   issues. 

------------------------------------------------

From: Tina TSOU [mailto:[email-masked]] 
Sent: Thursday, February 25, 2010 8:01 PM
To: [email-masked]
Cc: Ron Bonica; Dan Romascanu
Subject: Operations Directorate Review

Hello,

As a member of the Operations Directorate you are being asked to review the

following IESG work item for it's operational impact.

IETF Last Call:

http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-considerations-06.
txt

Please provide comments and review to the Ops-dir mailing list

( <mailto:[email-masked]> [email-masked]) before the next IESG telechat,
and include the authors of the

draft as well.

The IESG telechat agenda is below, you could find the exact date, i.e. the
expected deadline for the feedback of your review.

https://datatracker.ietf.org/iesg/agenda/

For a list of questions to be answered in an OPS-DIR review see Appendix A
in  <http://tools.ietf.org/html/rfc5706> RFC 5706. Note that not all
questions may apply to all documents, and some other items may be identified
by the OPS-DIR reviews.

The status of Operations Directorate Review could be found

http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates

You could wiki it when you finish the review.

Thank you,

Tina

http://tinatsou.weebly.com/contact.html