Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
draft-ietf-l3vpn-ppvpn-mcast-reqts-10

[Note]: 'New document detail thread with author -------- Original Message --------
Subject: Re: draft-ietf-l3vpn-ppvpn-mcast-reqts-09
Date: Fri, 03 Nov 2006 18:02:45 +0100
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
Organization: France Telecom R&D - Orange
To: Mark Townsley <townsley@cisco.com>
CC: l3vpn-chairs@tools.ietf.org
References: <45471814.3000509@cisco.com> Hi Mark; Mark Townsley : > > I think all of these comments are fairly actionable. Could you either > rev the document one more time, or provide a detailed RFC Editor''s Note > with specifics on how to edit the document to comply with these? I will update the document very quickly.
I''ve got a few meta-comments, though (see below inline). Thanks, -Thomas > *Brian Carpenter:*
> *Comment:*
> *[2006-10-09]* My preference would be to use plain English instead of > RFC 2119 language. I think that a significant number of published requirements RFC do
actually use RFC2119 wording. I''d rather keep the document as-is in this
respect, if there is no compelling reason to change it. > *Lars Eggert:*
> *Comment:*
> *[2006-10-11]* Section 2.1., paragraph 7:
>  >      Forwarding table" as defined in [RFC4364], and "VR" to "Virtual
>  >      Router" as defined in [VRs] terminology.
> >  Missing Reference: ''VRs'' is mentioned on line 792, but not defined Agreed. > Section 2.1., paragraph 14:
>  >      Rendez-vous point ([PIM-SM]).
> >  Missing Reference: ''PIM-SM'' is mentioned on line 232, but not defined Agreed. > Section 5.1.12., paragraph 3:
>  >    A committed minimum path MTU size SHOULD be provided to customers.
>  >    Moreover, since Ethernet LAN segments are often located at first and
>  >    last hops, a minimum 1500 bytes IP MTU SHOULD be provided.
> >  This requirement will be hard to meet over an Internet with a much
>  lower minimum PMTU. That is certainly true. The sentence was proposed by a contributor of
the document, I need to get back to him to discuss what would be the
most appropriate requirement. > Section 10.2., paragraph 10:
>  >    [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
>  >              Rendevous Point (RP) mechanism using Protocol Independent
> >  Nit: s/Rendevous/Rendezvous/ This is in fact a typo in the title of the published version of
RFC3446. :-(
It is not possible to correct it when using automatic reference
inclusion with xml2rfc. > Section 10.2., paragraph 17:
>  >    [RFC3353]  Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
>  >              F., and F. Ansari, "Overview of IP Multicast in a Multi-
>  >              Protocol Label Switching (MPLS) Environment", RFC 3353,
>  >              August 2002.
> >  Unused Reference: ''RFC3353'' is defined on line 1502, but not
>  referenced
> > *Dan Romascanu:*
> *Discuss:*
> *[2006-10-12]* 1. Sections 5.1.4 and 5.2.10 refer to  SNMPv2 [RFC1441] > which is historic. Unless there is a very good reason that should be > described, SNMPv3 [RFC3411] is the SNMP version that must be referenced. Agreed. > 2. The IPPM work that needs to be refered is I beleive > http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-01.txt Ack. I will look up this doc and consider referring to it. > 3. Also in Section 5.1.4 and 5.2.10 it would be better to consider a > method of setting watermark threshholds for the SLA parameters that > would allow automatic alarms generation in cases when thresholds are > exceeded like the one defined in RFC2819. That looks very relevant.
I''ll try to add some content to these sections accordingly.' added by Amy Vezza

[Ballot comment]
In Section 5.2.10 instead of

' ... SNMP [RFC3411] MIBs (Management Information Bases) ...'

Better say:

'... SMIv2 [RFC2578] Management Information Base (MIB) modules to be used with SNMP [RFC3411] ...

and add a reference to [RFC2578] ftp://ftp.rfc-editor.org/in-notes/rfc2578.txt.

[Note]: 'New document detail thread with author

-------- Original Message --------
Subject: Re: draft-ietf-l3vpn-ppvpn-mcast-reqts-09
Date: Fri, 03 Nov 2006 18:02:45 +0100
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
Organization: France Telecom R&D - Orange
To: Mark Townsley <townsley@cisco.com>
CC: l3vpn-chairs@tools.ietf.org
References: <45471814.3000509@cisco.com>


Hi Mark;

Mark Townsley :
>
> I think all of these comments are fairly actionable. Could you either
> rev the document one more time, or provide a detailed RFC Editor''s Note
> with specifics on how to edit the document to comply with these?

I will update the document very quickly.
I''ve got a few meta-comments, though (see below inline).

Thanks,

-Thomas


> *Brian Carpenter:*
> *Comment:*
> *[2006-10-09]* My preference would be to use plain English instead of
> RFC 2119 language.

I think that a significant number of published requirements RFC do
actually use RFC2119 wording. I''d rather keep the document as-is in this
respect, if there is no compelling reason to change it.


> *Lars Eggert:*
> *Comment:*
> *[2006-10-11]* Section 2.1., paragraph 7:
>  >      Forwarding table" as defined in [RFC4364], and "VR" to "Virtual
>  >      Router" as defined in [VRs] terminology.
>
>   Missing Reference: ''VRs'' is mentioned on line 792, but not defined

Agreed.

> Section 2.1., paragraph 14:
>  >      Rendez-vous point ([PIM-SM]).
>
>   Missing Reference: ''PIM-SM'' is mentioned on line 232, but not defined


Agreed.

> Section 5.1.12., paragraph 3:
>  >    A committed minimum path MTU size SHOULD be provided to customers.
>  >    Moreover, since Ethernet LAN segments are often located at first and
>  >    last hops, a minimum 1500 bytes IP MTU SHOULD be provided.
>
>   This requirement will be hard to meet over an Internet with a much
>   lower minimum PMTU.

That is certainly true. The sentence was proposed by a contributor of
the document, I need to get back to him to discuss what would be the
most appropriate requirement.


> Section 10.2., paragraph 10:
>  >    [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
>  >              Rendevous Point (RP) mechanism using Protocol Independent
>
>   Nit: s/Rendevous/Rendezvous/

This is in fact a typo in the title of the published version of
RFC3446. :-(
It is not possible to correct it when using automatic reference
inclusion with xml2rfc.


> Section 10.2., paragraph 17:
>  >    [RFC3353]  Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
>  >              F., and F. Ansari, "Overview of IP Multicast in a Multi-
>  >              Protocol Label Switching (MPLS) Environment", RFC 3353,
>  >              August 2002.
>
>   Unused Reference: ''RFC3353'' is defined on line 1502, but not
>   referenced
>
> *Dan Romascanu:*
> *Discuss:*
> *[2006-10-12]* 1. Sections 5.1.4 and 5.2.10 refer to  SNMPv2 [RFC1441]
> which is historic. Unless there is a very good reason that should be
> described, SNMPv3 [RFC3411] is the SNMP version that must be referenced.

Agreed.

> 2. The IPPM work that needs to be refered is I beleive
> http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-01.txt

Ack. I will look up this doc and consider referring to it.


> 3. Also in Section 5.1.4 and 5.2.10 it would be better to consider a
> method of setting watermark threshholds for the SLA parameters that
> would allow automatic alarms generation in cases when thresholds are
> exceeded like the one defined in RFC2819.

That looks very relevant.
I''ll try to add some content to these sections accordingly.


' added by Mark Townsley

[Ballot discuss]
1. Sections 5.1.4 and 5.2.10 refer to  SNMPv2 [RFC1441] which is historic. Unless there is a very good reason that should be described, SNMPv3 [RFC3411] is the SNMP version that must be referenced.
2. The IPPM work that needs to be refered is I beleive http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-01.txt
3. Also in Section 5.1.4 and 5.2.10 it would be better to consider a method of setting watermark threshholds for the SLA parameters that would allow automatic alarms generation in cases when thresholds are exceeded like the one defined in RFC2819.

[Ballot comment]
Section 2.1., paragraph 7:
>      Forwarding table" as defined in [RFC4364], and "VR" to "Virtual
>      Router" as defined in [VRs] terminology.

  Missing Reference: 'VRs' is mentioned on line 792, but not defined


Section 2.1., paragraph 14:
>      Rendez-vous point ([PIM-SM]).

  Missing Reference: 'PIM-SM' is mentioned on line 232, but not defined


Section 5.1.12., paragraph 3:
>    A committed minimum path MTU size SHOULD be provided to customers.
>    Moreover, since Ethernet LAN segments are often located at first and
>    last hops, a minimum 1500 bytes IP MTU SHOULD be provided.

  This requirement will be hard to meet over an Internet with a much
  lower minimum PMTU.


Section 10.2., paragraph 10:
>    [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
>              Rendevous Point (RP) mechanism using Protocol Independent

  Nit: s/Rendevous/Rendezvous/


Section 10.2., paragraph 17:
>    [RFC3353]  Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
>              F., and F. Ansari, "Overview of IP Multicast in a Multi-
>              Protocol Label Switching (MPLS) Environment", RFC 3353,
>              August 2002.

  Unused Reference: 'RFC3353' is defined on line 1502, but not
  referenced

PROTO

Please publish as Informational.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          Ron Bonica has personally reviewed the document and believes
          that it is ready for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          The document has had extensive review and has passed many
          last calls

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

          No. The document has been reviewed by the operator community.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.

          I am comfortable with the document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

          Many individuals commented on the draft and all comments were
          addressed. There is strong consensus to publish.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

          No

  (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

          Nit checkerreports four experimental warnings on references.
          These can be cleaned up in 48 hour review.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          Yes. However, there is one normative reference that is still
          an ID. I believe that this might be made an informative
          informative reference

  (1.i)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
          This document presents a set of functional requirements
          for network solutions that allow the deployment of IP
          multicast within L3 Provider Provisioned virtual private
          networks (PPVPNs).  It specifies requirements both from the
          end user and service provider standpoints.
          It is intended that potential solutions specifying the
          support of IP multicast within such VPNs will use
          these requirements as guidelines.

          Working Group Summary
            There was strong consensus to publish.

          Document Quality
            No problems to note

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Ron Bonica has personally reviewed the document and believes
that it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had extensive review and has passed many
last calls

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No. The document has been reviewed by the operator community.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.

I am comfortable with the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Many individuals commented on the draft and all comments were
addressed. There is strong consensus to publish.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

No

(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

Nit checkerreports four experimental warnings on references.
These can be cleaned up in 48 hour review.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes. However, there is one normative reference that is still
an ID. I believe that this might be made an informative
informative reference

(1.i) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document presents a set of functional requirements
for network solutions that allow the deployment of IP
multicast within L3 Provider Provisioned virtual private
networks (PPVPNs). It specifies requirements both from the
end user and service provider standpoints.
It is intended that potential solutions specifying the
support of IP multicast within such VPNs will use
these requirements as guidelines.

Working Group Summary
There was strong consensus to publish.

Document Quality
No problems to note