Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
draft-kumaki-murai-l3vpn-rsvp-te-09

[Ballot comment]
I'm moving this to a comment, leaving it on the record but not blocking progress at this point.

I see no evidence that there was substantive discussion of this document anywhere, and I don't see that it belongs in the IETF Stream, with any claim to IETF consensus.

The shepherd writeup mentions consideration by the l3vpn WG, but it appears not to have been substantively discussed there.  The IETF 77 minutes show a discussion of what working group it belongs in, but no discussion of the substance of the document.  With a little digging, one finds that it has a predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was proposed to the ccamp WG, but there's no evidence that it was discussed there either.

The only two substantive comments I can find are these:

1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.

2. During IETF Last Call, on the IETF discussion list, Lou Berger had a brief exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html

It's not clear that this resulted in a resolution of Lou's concern.

And that's all.  I think that's light even for an Experimental document.

Given that both ccamp and l3vpn have looked at this and said that they don't want it (but apparently think it's not harmful), and that exactly two people other than the authors have made any comments at all about the substance of the document, I don't think it's reasonable to say that there's IETF consensus on it.

I do think it would have been reasonable to have sent this over to the Independent Stream Editor.

[Ballot comment]
Thanks for addressing my DISCUSS -- cleared.

Comments:
This draft is going for experimental and I would like to know what the test for a successful or not successful outcome of this is. Especially since the drafts says that this should enable experimental research.

I would further add a more explicit clarification that this is only to be used within an operator. This is mentioned in several places, e.g., in Section 3.1.1 "The object  MUST NOT be included in any RSVP-TE message that is sent outside of  the provider's backbone." However, a particular section discussing this would be better. This section could also discuss possible impacts if the above rules is not followed.

[Ballot comment]
Updated after discussions with Adrian.  This is about control plane stuff so my concerns don't apply.

This might be cleared up by addressing PHB's secdir review comment too, but I thought I'd throw this in:

Are there two different mechanisms defined in RFC 2747 and 3097?  I thought 3097 updates 2747 to just clarify which values to use because of a double assignment.  Wouldn't be clearer if you said:

To ensure the integrity of an RSVP request, the RSVP Authentication
mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used.

[Ballot discuss]
This'll probably end up being a placeholder for addressing PHB's secdir review too, but I think this draft needs to better explain the issues when IPsec is employed on VPN1 and VPN2.  RFC 2205 does point to RFC 2207 for some help, but i can't find in the stack of RSVP/RSVP-TE RFCs that say it MUST be used or something else has been adopted since.

[Ballot comment]
This might be cleared up by addressing PHB's secdir review comment too, but I thought I'd throw this in:

Are there two different mechanisms defined in RFC 2747 and 3097?  I thought 3097 updates 2747 to just clarify which values to use because of a double assignment.  Wouldn't be clearer if you said:

To ensure the integrity of an RSVP request, the RSVP Authentication
mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used.

[Ballot comment]

- The authors responded to the secdir review [1] saying they
planned to modify the security considerations section, but I
didn't see any further response and don't see associated
changes in the security considerations.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03538.html

- This cites RFC 4364 which calls for use of TCP-MD5 for
control plane security. [2] Given that this is an
experimental document, would it not be resaonable for it at
least mention that RFC 5925 obsoleted TCP-MD5?

  [2] http://tools.ietf.org/html/rfc4364#section-13.2

[Ballot discuss]
Updated based on Adrian's correction...

I have no problems with the publication of this document, but I agree with Martin that the IANA Considerations section is wrong.  The document is requesting several new RSVP Class Types, which are allocated using the rules defined in RFC 3936.  Specifically, from section 2.3 of 3936:

  For Class Numbers that pre-date this document (specifically, 0, 1,
  3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the
  default assignment policy for new Class Types is Standards Action,
  unless a Standards Track or Best Current Practice RFC supercedes
  this.

[Ballot discuss]
I have no problems with the publication of this document, but I agree with Martin that the IANA Considerations section is wrong.  The document is requesting several new RSVP Class Types, which I believe will come from this IANA registry:

https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#rsvp-parameters-3

It should be noted that the registry has 9 ranges of values for the Class Type, with different registration procedures per range.  Which range fits the need for these new Class Types?

[Ballot comment]
I have no objection to the publication of this document and would ballot "Yes", but I believe that Martin's Discuss needs to be addressed.

[Ballot comment]
(For the IESG; no author action necessary.)

My "No Objection" position notwithstanding, I strongly agree with Barry's DISCUSS comments and would like to hear more about this. Even if we pass this document on for publication, I think the issue of almost entirely unsupported AD-sponsored documents needs to be dealt with. It is certainly within an AD's discretion to personally support the publication of a document he/she feels is important, but I would expect an extensive writeup of why the AD is using that privilege for a document that's gotten virtually no discussion.

[Ballot comment]
This draft is going for experimental and I would like to know what the test for a successful or not successful outcome of this is. Especially since the drafts says that this should enable experimental research.

I would further add a more explicit clarification that this is only to be used within an operator. This is mentioned in several places, e.g., in Section 3.1.1 "The object  MUST NOT be included in any RSVP-TE message that is sent outside of  the provider's backbone." However, a particular section discussing this would be better. This section could also discuss possible impacts if the above rules is not followed.

[Ballot discuss]
The IANA Section has no actions listed but the text has a number of TBA for various C-Types. This seems to be wrong or am I missing something?

If those C-types are to be allocated, what is the policy for those allocations, if the experiment is not successful? E.g., are those C-Types freed afterwards?

[Ballot comment]
This draft is going for experimental and I would like to know what the test for a successful or not successful outcome of this is. Especially since the drafts says that this should enable experimental research.

I would further add a more explicit clarification that this is only to be used within an operator. This is mentioned in several places, e.g., in Section 3.1.1 "The object  MUST NOT be included in any RSVP-TE message that is sent outside of  the provider's backbone."

[Ballot discuss]
This is a "DISCUSS-DISCUSS", for IESG action.
The bottom line first:
I see no evidence that there was substantive discussion of this document anywhere, and I don't see that it belongs in the IETF Stream, with any claim to IETF consensus.

The shepherd writeup mentions consideration by the l3vpn WG, but it appears not to have been substantively discussed there.  The IETF 77 minutes show a discussion of what working group it belongs in, but no discussion of the substance of the document.  With a little digging, one finds that it has a predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was proposed to the ccamp WG, but there's no evidence that it was discussed there either.

The only two substantive comments I can find are these:

1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.

2. During IETF Last Call, on the IETF discussion list, Lou Berger had a brief exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html

It's not clear that this resulted in a resolution of Lou's concern.

And that's all.  I think that's light even for an Experimental document.

Given that both ccamp and l3vpn have looked at this and said that they don't want it (but apparently think it's not harmful), and that exactly two people other than the authors have made any comments at all about the substance of the document, I don't think it's reasonable to say that there's IETF consensus on it.

I do think it would be reasonable to send this over to the Independent Stream Editor.

[Ballot discuss]
This is a "DISCUSS-DISCUSS", for IESG action.
The bottom line first:
I see no evidence that there was substantive discussion of this document
anywhere, and I don't see that it belongs in the IETF Stream, with any claim
to IETF consensus.

The shepherd writeup mentions consideration by the l3vpn WG, but it appears
not to have been substantively discussed there.  The IETF 77 minutes show a
discussion of what working group it belongs in, but no discussion of the
substance of the document.  With a little digging, one finds that it has a
predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was
proposed to the ccamp WG, but there's no evidence that it was discussed
there either.

The only two substantive comments I can find are these:

1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.

2. During IETF Last Call, on the IETF discussion list, Lou Berger had a
brief exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html

It's not clear that this resulted in a resolution of Lou's concern.

And that's all.  I think that's light even for an Experimental document.

Given that both ccamp and l3vpn have looked at this and said that they don't
want it (but apparently think it's not harmful), and that exactly two people
other than the authors have made any comments at all about the substance of
the document, I don't think it's reasonable to say that there's IETF
consensus on it.

I do think it would be reasonable to send this over to the Independent
Stream Editor.

IANA has reviewed draft-kumaki-murai-l3vpn-rsvp-te-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Support for RSVP-TE in L3VPNs) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Support for RSVP-TE in L3VPNs'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  IP Virtual Private Networks (VPNs) provide connectivity between sites
  across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS
  and a single provider edge (PE) node may provide access to multiple
  customer sites belonging to different VPNs.

  The VPNs may support a number of customer services including RSVP and
  RSVP-TE traffic. This document describes how to support RSVP-TE
  between customer sites when a single PE supports multiple VPNs.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ballot/


No IPR declarations have been submitted directly on this I-D.

Due to an error by the sponsoring Area Director, the Last Call on
this document (which completed on 3rd September) incorrectly
stated that this draft was intended that it be published as Informational.
The correct intention (as stated in the draft itself) is that it  be
published as Experimental.

This Last Call is to verify community consensus for publication of
this draft as Experimental.

IANA has reviewed draft-kumaki-murai-l3vpn-rsvp-te-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Support for RSVP-TE in L3VPNs) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Support for RSVP-TE in L3VPNs'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-09-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  IP Virtual Private Networks (VPNs) provide connectivity between sites
  across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS
  and a single provider edge (PE) node may provide access to multiple
  customer sites belonging to different VPNs.

  The VPNs may support a number of customer services including RSVP and
  RSVP-TE traffic. This document describes how to support RSVP-TE
  between customer sites when a single PE supports multiple VPNs.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the proper
type of RFC?  Is this type of RFC indicated in the title page header?

The requested status and indicated in the header status is Experimental. The
document defines a number of extensions for IP VPN (RSVP-TE based)
corner-cases and although had limited support, the document was not adopted
by the working group. Therefore the L3VPN co-chairs recommended that the
document be Experimental and AD Sponsored. 

(2) 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]

IP Virtual Private Networks (VPNs) provide connectivity between sites across
an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS and a single
provider edge (PE) node may provide access to multiple customer sites
belonging to different VPNs.  The VPNs may support a number of customer
services including RSVP and  RSVP-TE traffic. If multiple BGP/MPLS IP-VPNs
are supported at the same PE, new RSVP-TE extensions are required so that
RSVP-TE control messages from the CEs can be appropriately handled by the
PE. draft-kumaki-murai-l3vpn-rsvp-te-06 describes how to support RSVP-TE
between customer site when a single PE supports multiple VPNs.

[Working Group Summary]

The Working Group did not adopt the work, even though prior requirements
exist within another working group document (RFC5824). However the working
group chars felt the work had merit and good support from its co-authors
therefore the document might be progressed as experimental and AD sponsored.

[Document Quality]

The authors mentioned that extensions defined in the document have been
implemented and tested. Although I do think the document would benefit from
a thorough review and I would be willing to do this. The document is
Experimental therefore there are no IANA requests. No MIB currently exists
to manage or report the status of these new protocol mechanisms. 

[Personnel]

Daniel King is the Document Shepard. The Routing Area Directors responsible
for the work are Stuart Bryant and Adrian Farrel. 

(3) Briefly describe the review of this document that was performed by the
Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

Daniel King was asked to provide a proto write-up.  I have personally
reviewed the document, and believe it is close to being ready for
publication as an AD Sponsored document. A few minor NITs exist and some
readability updates would benefit the document.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed? 

No. The document has been presented in the CCAMP and L3VPN WGs on multiple
occasions. Due to the corner case nature of the extensions wide spread
support does not currently exist. However the document addresses
requirements defined in RFC5824. The document also has good support
(including implementation) from its authors (operators and vendors).

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,
XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
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 the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those concerns here.

No specific areas of concern exist. The extensions are relatively minor and
for very specific use cases that are no applicable to a wide audience.
Therefore seeing as the document is AD Sponsored and Experimental, it would
be beneficial to progress the document as there is technical merit and
potential for further implementations in the future.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why.

Yes. I have checked with all the co-authors and contributors. No IPR exists.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.

(9) 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? 

There is no WG consensus. The WG chairs recommended therefore that the
document be progressed as AD sponsored and Experimental.

(10) 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 is publicly available.)

No, not to my knowledge. Having reviewed minutes where the ID was presented
and mailing list discussions, there is no obvious discontent.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

No NITS exist that would prohibit the automatic filing of the current
document.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

No MIB doctor or specialist review is required.

(13) Have all references within this document been identified as either
normative or informative?

Yes. The document has References that have been filed into the relevant
categories.

(14) 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 plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document does not replace or change any prior RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification
of the initial contents for the registry, that allocations procedures for
future registrations are defined, and a reasonable name for the new registry
has been suggested (see RFC 5226).

The documents intended status is Experimental, therefore there are no IANA
requests or recommendations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

No IANA code points or registries are requested.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.

There are no XML, BNF or MIB definitions defined in the document.