Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 4875

Received changes through RFC Editor sync (changed abstract to 'This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]')

[Ballot discuss]
There was a discussion following the SecDir review by Hilarie Orman,
  but none of the text changes that were proposed in that discussion
  have been made to the document, nor are there RFC Editor notes to make
  the changes.  I consider these unresolved IETF Last Call comments.

  Hilarie> Well, that's an extraordinarily terse response to a
  Hilarie> number of separate issues, but it's better than nothing.

  Hilarie> At the very minimum, please break it into two paragraphs
  Hilarie> and identify what security parameters are the subject of
  Hilarie> the second one.  I assume you mean RSVP security
  Hilarie> parameters?

[Ballot discuss]
Based on a security directorate review.  According to section 21, the
ingress LSR is responsible for determining what the leaves of the P2MP
LSP are based on the needs of the P2MP application.  In order to
provide interoperability there needs to be a mechanism to carry this
information to the LSR.

I propose text similar to the following: "Applications MUST provide a
mechanism to notify the ingress LSR of the appropriate leaves for the
P2MP LSP.  Specifications of applications within the IETF MUST specify
this mechanism in sufficient detail that an ingress LSR from one
vendor can be used with an application implementation provided by
another vendor.  Manual configuration of security parameters when
other parameters are auto-discovered is generally not sufficient to
meet security and interoperability requirements of IETF
specifications.
"

IANA Last Call Comments:

** IANA has two questions in #5 and #6 below. ***


Upon approval of this document the IANA will update the references to
be this document for the following:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"

Create table
50 S2L_SUB_LSP [RFC-rsvp-te-p2mp-06.txt]

Class Types or C-Types:

1 S2L_SUB_LSP_IPv4 [RFC-rsvp-te-p2mp-06.txt]
2 S2L_SUB_LSP_IPv6 [RFC-rsvp-te-p2mp-06.txt]

Action #2:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
table "1 SESSION [RFC2205]"
OLD:
13 unassigned
14 unassigned
NEW:
13 P2MP_LSP_TUNNEL_IPv4 [RFC-rsvp-te-p2mp-06.txt]
14 P2MP_LSP_TUNNEL_IPv4 [RFC-rsvp-te-p2mp-06.txt]


Action #3:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
table "11 SENDER_TEMPLATE [RFC2205]"

12 P2MP_LSP_TUNNEL_IPv4 [RFC-rsvp-te-p2mp-06.txt]
13 P2MP_LSP_TUNNEL_IPv6 [RFC-rsvp-te-p2mp-06.txt]

Action #4:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
table "10 FILTER_SPEC [RFC2205]"

12 P2MP LSP_IPv4 [RFC-rsvp-te-p2mp-06.txt]
13 P2MP LSP_IPv6 [RFC-rsvp-te-p2mp-06.txt]



Action #5:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
Create table
TBD-1 SECONDARY_EXPLICIT_ROUTE [RFC-rsvp-te-p2mp-06.txt]

C-Type
2 P2MP SECONDARY_EXPLICIT_ROUTE [RFC-rsvp-te-p2mp-06.txt]


Note: it is not clear if this object should be registered in any particular
unassigned range. Editors are requested to give guidance otherwise
value from the 26-29 range will be used".


Action #6:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP" registry located at
http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
Create table
TDB-2 "SECONDARY_RECORD_ROUTE" [RFC-rsvp-te-p2mp-06.txt]

C-Type
2 P2MP_SECONDARY_RECORD_ROUTE [RFC-rsvp-te-p2mp-06.txt]


Note: it is not clear if this object should be registered in any particular
unassigned range. Editors are requested to give guidance otherwise
value from the 26-29 range will be used".


Action #7:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes"
Table: "24 Routing Problem [RFC3209]"

OLD:
17-99 = Unassigned

NEW:
17-22 = Unassigned
TDB-23 = Unable to Branch [RFC-rsvp-te-p2mp-06.txt]
TDB-24 = Unsupported LSP Integrity [RFC-rsvp-te-p2mp-06.txt]
TDB-25 = P2MP Remerge Detected [RFC-rsvp-te-p2mp-06.txt]
TDB-26 = P2MP Re-Merge Parameter Mismatch [RFC-rsvp-te-p2mp-06.txt]
TDB-27 = ERO Resulted in Remerge [RFC-rsvp-te-p2mp-06.txt]
28-99 = Unassigned


Action #8:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Class"
Table "67 LSP_REQUIRED_ATTRIBUTES [RFC4420] "

OLD:
1 LSP Required Attributess TLVs [RFC4420]

NEW:
1 LSP Required Attributess TLVs [RFC4420]

sub-object bits
TDB-3 LSP Integrity Required [RFC-rsvp-te-p2mp-06.txt]


Action #9:
Upon approval of this document, the IANA will make the following
assignments in the "RSVP" registry located at

http://www.iana.org/assignments/rsvp-parameters
sub-registry "Message Types"
OLD:
3 = PathErr [RFC2205]
4 = ResvErr [RFC2205]

NEW:
3 = PathErr [RFC2205, RFC-rsvp-te-p2mp-06.txt]
4 = ResvErr [RFC2205, RFC-rsvp-te-p2mp-06.txt]

We understand the above to be the only IANA Action for this document.

[Ballot discuss]
There was a discussion following the SecDir review by Hilarie Orman,
  but none of the text changes that were proposed in that discussion
  have been made to the document, nor are there RFC Editor notes to make
  the changes.  I consider these unresolved IETF Last Call comments.

[Ballot comment]
Section 6.2.1., paragraph 1:
>    Specifically, in the case where the only change being sent in a Resv
>    message is in one or more SRRO objects, the branch node SHOULD
>    transmit the Resv message only after a delay time has passed since
>    the transmission of the previous Resv message for the same session.
>    This delayed Resv message SHOULD include SRROs for all branches. A
>    suggested value for the delay time is thirty seconds. Specific
>    mechanisms for Resv message throttling and delay timer settings are
>    implementation dependent and are outside the scope of this document.

  Can a lower bound be identified below which delay times are not
  useful? ("A suggested value for the delay time is thirty seconds, and
  delay times SHOULD generally be longer than X", where X is that lower
  bound.)

[Ballot discuss]
Section 23.1., paragraph 13:
>    [RFC4461] S. Yasukawa, Editor "Signaling Requirements for
>              Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.

  DISCUSS: This is a DOWNREF.

[Ballot comment]
Did the WG discuss scaling limits? Section 10 indicates how
multipoint signaling can be cut up into smaller pieces, but
doesn't really give a sense of where the scaling limit is.

This document appears to use ABNF without a reference.

Nit from Gen-ART reviewer Vijay K. Gurbani:
S8.2 - s/to the value, that/to the value that/

The proto-write by Loa and George:


1. Have the chairs personally reviewed this version of the Internet
  Draft (ID), and in particular, do they believe this ID is ready
  to forward to the IESG for publication?


  Yes, the draft has been well reviewed by both the working group
  chairs, and we think it is ready to be reviewed by the IESG to
  become a RFC on the standards track.


2. Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?


  Yes, the draft has been very well reviewed. We have no doubts
  about the quality of the review undertaken for this draft.


3. Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?


  No - the involvement of people with operational expereince has
  been good. From a security perspective this draft does not
  introduce other security concerns other than what is the case
  when using RSVP-TE for setting p2p LSPs.


4. Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or have concerns whether there really is a need for it. In any
  event, if your issues have been discussed in the WG and the WG
  has indicated it that it still wishes to advance the document,
  detail those concerns in the write-up.


  None - other than that the difference between multicast and
  P2MP TE needs to be pointed out.


5. 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?


  This document has a very strong support in the working group. The
  work in this draft has also been done based on requirements from
  the GMPLS p2mp TE. The draft also has a strong support in the
  ccamp working group.




6. Has anyone threatened an appeal or otherwise indicated extreme
  discontent? If so, please summarise the areas of conflict in
  separate email to the Responsible Area Director.


  No.


7. Have the chairs verified that the document adheres to all of the
  ID Checklist items ?


  Yes - idnits 1.114 list no problems what so ever.


8. Is the document split into normative and informative references?
  Are there normative references to IDs, where the IDs are not also
  ready for advancement or are otherwise in an unclear state? (note
  here that the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs
  are also ready for publication as RFCs.)


  All normative references are RFCs, with one exception
  draft-ietf-ccamp-gmpls-segment-recovery, which is in IESG review.
  There are informative refrences.



9. What is the intended status of the document?


  Proposed Standard.