Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-07

[Ballot comment]
Thanks very much for addressing so much of my Discuss and Comment. We made very substantial progress and improved the document significantly.

I have cleared my Discuss and relegated my issue to a Comment.

My remaining issue is mainly philosophy, and I will probably continue to
disagree on this point regardless of further discussions.

At least it is now clear to me what the purpose and objectives are. IMHO, there is no need for this feature.  My view is that it is possible to identify the state and RSVP addressing context from the existing RSVP message, the incoming interface, and the IP header. IMHO, no further additions are necessary.

But I see that the proposed extension is not mandatory so people can continue to deploy RSVP over MPLS L3VPN without using it. That is good enough for me.

Substantial discuss is in place. The authors has not responded to the raised issues yet. Putting this in revised ID need to reflect the most likely outcome and make it clear it is the authors that needs action.

[Ballot comment]
Section 3.1

> Use of the VPN-IPv4
> RSVP_HOP object enables RSVP control plane reachability between any
> two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in
> AS2), regardless of whether they have IP reachability to each other.

This isn't the case. Since the RSVP message is an IP encapsulated
message, if there was no IP reachability, the message would not get
there!

What you are doing is allowing a very narrow IP control plane channel
in band with the payload data of the MPLS VPN. In other words, you
are encapsulating IP/RSVP packets onto the LSP.

That is the thing that enables control plane reachability.

Your new object enables determination of VPN disambiguation at the PE
and CE. But that is not what is described.

---

It would be really nice if the desciptive text in Section 3 could make
direct reference to the steps in Section 2.1.

[Ballot discuss]
I have some signigicant concerns about the reasoning for the protocol
extensions proposed in this document.

I understand that this draft was last called in both the TSVWG and the
L3VPN WG. That would mean that my Discuss points are going against the
consensus of two working groups, however when I scan the archives I
cannot see any comments of support made during the last call. In view
of this, and examining the small number of emails about this work on the
list, I don't feel that there is evidence of strong consensus, and so I
am not worried about voicing my concerns.

In section 1, three key challenges are presented to be overcome in order
to extend intra-VPN RSVP to operate over the PE-CE links. These are as
follows:

> o  RSVP Path message processing depends on routers recognizing the
>    router alert option in the IP header.  However, packets traversing
>    the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the
>    router alert option is not normally visible to the egress PE.

It is unclear why the router alert option would not be visible to the
egress PE. The full IP header of all packets arriving on an LSP across
is available for inspection. Indeed, the address fields are used for VRF
lookup, and other header fields may be used for hashing if there are two
parallel links between PE and CE.

This doesn't seem to be a realistic motivation for the work.

It may be that some implementations have difficulty in inspecting the
router alert option at the end of an LSP, but that it not something to
solve through modifications to the protocol specifications.

It may be that the use of the router alert option is no longer
considered a good idea for intercepting RSVP packets. This may be a
valid concer, but it has already been addressed in RSVP-TE and requires
a change to the core RSVP specificaiton to allow IP packets to be
targeted at specific transit hops (not at the ultimate destination).

> o  BGP/MPLS VPNs support non-unique addressing of customer networks.
>    Thus a PE at the ingress or egress of the provider backbone may be
>    called upon to process Path messages from different customer VPNs 
>    with non-unique destination addresses.

This is true, but it is exactly the case for normal data IP packets.
In fact, the whole point about RSVP packets is that they are forwarded
along the same path as the data packets, so it is no suprise that if
data packets can be correctly delivered, so can RSVP packets.

This issue does not appear to be a reason for this work.

It may be that some implementations have an issue linking in correctly
with the per-VPN router state, but that is not cause for changing the
protocol specifications.

> o  A PE at the ingress of the provider's backbone may receive Resv
>    messages corresponding to different customer VPNs from other PEs,
>    and needs to be able to associate those Resv messages with the
>    appropriate customer VPNs.

This is exactly the same issue as or handling Path messages. The Resv
will arrive on an LSP that will identify the VPN to which the Resv
applies. This can be used to find the associated Path state, determine
the next hop for the Resv, and identify the correct VRF for routing the
Resv.

Again, this is not a reason for these protocol extensions.


Section 1 goes on to say that:

> Additionally, it may be desirable to perform admission control over
> the provider's backbone on behalf of one or more L3VPN customers.
> Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for
> customer routes, and thus cannot natively process RSVP messages for
> customer flows.  Also the core is a shared resource that carries
> traffic for many customers, so issues of resource allocation among
> customers and trust (or lack thereof) must also be addressed.  This
> draft also specifies procedures for supporting such a scenario.

If resources need to be reserved in the core network for LSPs then the
RSVP messages must follow the same paths as the LSPs (and clearly not
be encapsulated in the LSPs). This case does open up a variety of
addressing and resource sharing (policy) issues within the core of the
network. Such issues are easily solved by using RSVP-TE to establish
the LSPs across the core.


I am left, therefore, with the feeling that, while this work might not
be significantly harmful, it is also not very useful and may be a
distraction.



I have two supplementary issues


1. Document Shepherd write-up template that can be found at
  http://www.ietf.org/IESG/content/Doc-Writeup.html asks...

  > Are there existing implementations of the protocol?  Have a
  > significant number of vendors indicated their plan to
  > implement the specification?

  Having such implementations or plans is not a requirement for
  publication. Answering the questions, however, would be a
  great help in understanding the value of this work.

  For example, perhaps it should be Experimental since it describes
  changes for running RSVP in core networks. Or perhaps it should
  be Informaitonal because it describes one vendor's (IPR disclosed)
  implementation.

2. The L3VPN working group is working on a draft on "Requirements for
  supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN" (see
  draft=ietf-l3vpn-e2e-rsvp-te-reqts).

  Section 7.4 of this draft seems to acknowledge the existence of the
  L3VPN WG work, but discount it...

  > The requirements specified in that draft are similar
  > to those addressed by this document, in that both address the issue
  > of handling RSVP requests from customers in a VPN context.  It is
  > possible that the solution described here could be adapted to meet
  > the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts].  To the
  > extent that this draft uses signalling extensions described in
  > [RFC3473] which have already been used for GMPLS/TE, we expect that
  > CE-CE RSVP/TE will be incremental work built on these extensions.
  > These extensions will be considered in a separate document.

  It does not seem right to me to push these protocol extensions in the
  knowledge that is is only "possible" that they could be adapted to
  meet the requirements or the generic situation.

  It would be more reasonable to identify the full set of requirements
  for the problem space and then work on a solution that was either:
  - generally applicable
  or
  - applicable to a liited subset of the requirements with a clear
    explanation of why a single solution was not developed.

[Ballot comment]
3.6.  Other RSVP Messages

Comment: not using RFC 2119 keywords? The same comment probably applies to
other sections, but this is where I've noticed.

IANA comments:

Upon approval of this document, IANA will make the following
changes in "Resource Reservation Protocol (RSVP) Parameters" at
http://www.iana.org/assignments/rsvp-parameters

========
[sub-registry "Class Names, Class Numbers, and Class Types"]

NEW:

Class
Number Class Name Reference
------ ----------------------- ---------

1 SESSION [RFC2205]

Class Types or C-Types:

19 VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
20 VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]
21 AGGREGATE-VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
22 AGGREGATE-VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]
23 GENERIC-AGGREGATE-VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
24 GENERIC-AGGREGATE-VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]

3 RSVP_HOP [RFC2205]

Class Types or C-Types:

5 VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
6 VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]


10 FILTER_SPEC [RFC2205]

Class Types or C-Types:

14 VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
15 VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]
16 AGGREGATE-VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
17 AGGREGATE-VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]


11 SENDER_TEMPLATE [RFC2205]

Class Types or C-Types:

14 VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
15 VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]
16 AGGREGATE-VPN-IPv4 [RFC-tsvwg-rsvp-l3vpn-02]
17 AGGREGATE-VPN-IPv6 [RFC-tsvwg-rsvp-l3vpn-02]

========
[sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes"]

NEW:

Error Code Meaning

34 RSVP over MPLS Problem [RFC-tsvwg-rsvp-l3vpn-02]

This Error Code has the following globally-defined Error
Value sub-codes:

1 = RSVP_HOP not reachable across VPN [RFC-tsvwg-rsvp-l3vpn-02]

An addition to the writeup!

Magnus Westerlund skrev:
>    (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 the WG has discussed those issues and has indicated
>          that it still wishes to advance the document, detail those
>          concerns here. Has an IPR disclosure related to this document
>          been filed? If so, please include a reference to the
>          disclosure and summarize the WG discussion and conclusion on
>          this issue.
>
> No concerns or issues.
>

Here I went a bit to fast. There is an IPR statement on this document:
https://datatracker.ietf.org/ipr/989/

The WG was informed and no one has raised any concerns over the statement.

Doc shepherd writeup for draft-ietf-tsvwg-rsvp-l3vpn requested to be published as proposed standard by Magnus Westerlund

    (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?
         
Document shepherd is Magnus Westerlund who has reviewed version 01 and
believes it ready with a few exceptions that can be handed as AD evaluation comments.         

    (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?
         
This document has gotten review from both TSVWG RSVP expert and L3VPN WG people. No concerns over the level of review.

    (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.         

    (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 the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
         
No concerns or issues.         

    (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?
         
It has strong consensus from the RSVP interested in the WG.         

    (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 is
          entered into the ID Tracker.)
         
No.         

    (1.g) Has the Document Shepherd personally 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. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?
         
Yes. ID-nits give some warnings due to that it was submitted prior to boiler plate changes.         

    (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. No downward references.         

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
         
Yes, IANA section seems to be in order.         

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
There is no formal language.         

    (1.k) 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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.
           
Technical Summary

  RFC 4364 and RFC 4659 define an approach to building provider-
  provisioned Layer 3 VPNs for IPv4 and IPv6.  It may be desirable to
  use RSVP to perform admission control on the links between CE and PE
  routers.  This document specifies procedures by which RSVP messages
  travelling from CE to CE across an L3VPN may be appropriately handled
  by PE routers so that admission control can be performed on PE-CE
  links.  Optionally, admission control across the provider's backbone
  may also be supported.
 
Working Group Summary

  This document has been last called in both TSVWG and L3VPN. There is
  strong consensus from the RSVP intrested in this document to publish
  it.
 
Document Quality
 
  This document has gotten reviews from key people in TSVWG and L3VPN.   

Personel
 
  Document Shepherd and Responsible AD Magnus Westerlund

Doc shepherd writeup for draft-ietf-tsvwg-rsvp-l3vpn requested to be published as proposed standard by Magnus Westerlund

    (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?
         
Document shepherd is Magnus Westerlund who has reviewed version 01 and
believes it ready with a few exceptions that can be handed as AD evaluation comments.         

    (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?
         
This document has gotten review from both TSVWG RSVP expert and L3VPN WG people. No concerns over the level of review.

    (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.         

    (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 the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
         
No concerns or issues.         

    (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?
         
It has strong consensus from the RSVP interested in the WG.         

    (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 is
          entered into the ID Tracker.)
         
No.         

    (1.g) Has the Document Shepherd personally 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. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?
         
Yes. ID-nits give some warnings due to that it was submitted prior to boiler plate changes.         

    (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. No downward references.         

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
         
Yes, IANA section seems to be in order.         

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
There is no formal language.         

    (1.k) 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
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.
           
Technical Summary

  RFC 4364 and RFC 4659 define an approach to building provider-
  provisioned Layer 3 VPNs for IPv4 and IPv6.  It may be desirable to
  use RSVP to perform admission control on the links between CE and PE
  routers.  This document specifies procedures by which RSVP messages
  travelling from CE to CE across an L3VPN may be appropriately handled
  by PE routers so that admission control can be performed on PE-CE
  links.  Optionally, admission control across the provider's backbone
  may also be supported.
 
Working Group Summary

  This document has been last called in both TSVWG and L3VPN. There is
  strong consensus from the RSVP intrested in this document to publish
  it.
 
Document Quality
 
  This document has gotten reviews from key people in TSVWG and L3VPN.   

Personel
 
  Document Shepherd and Responsible AD Magnus Westerlund