Skip to main content

Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
draft-ietf-mpls-rsvp-te-p2mp-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-04-17
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-04-16
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-04-16
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-04-16
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-04-03
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-29
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-29
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-15
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-02-08
07 (System) IANA Action state changed to In Progress
2007-02-05
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-02-01
07 Amy Vezza IESG state changed to Approved-announcement sent
2007-02-01
07 Amy Vezza IESG has approved the document
2007-02-01
07 Amy Vezza Closed "Approve" ballot
2007-02-01
07 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2007-01-25
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2007-01-24
07 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2007-01-23
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-01-23
07 Russ Housley
[Ballot discuss]
There was a discussion following the SecDir review by Hilarie Orman,
  but none of the text changes that were proposed in that …
[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?
2007-01-23
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-01-23
07 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-07.txt
2006-12-15
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-12-15
07 (System) Removed from agenda for telechat - 2006-12-14
2006-12-14
07 Sam Hartman
[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 …
[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.
"
2006-12-14
07 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2006-12-14
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-12-14
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2006-12-14
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-12-14
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-12-13
07 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2006-12-13
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-12-13
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-12-13
07 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2006-12-13
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-12-12
07 Yoshiko Fong
IANA Last Call Comments:

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


Upon approval of this document the IANA will update the …
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.
2006-12-12
07 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-12-12
07 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2006-12-11
07 Russ Housley
[Ballot discuss]
There was a discussion following the SecDir review by Hilarie Orman,
  but none of the text changes that were proposed in that …
[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.
2006-12-11
07 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2006-12-11
07 Lars Eggert
[Ballot comment]
Section 6.2.1., paragraph 1:
>    Specifically, in the case where the only change being sent in a Resv
>    message is …
[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.)
2006-12-11
07 Lars Eggert
[Ballot discuss]
Section 23.1., paragraph 13:
>    [RFC4461] S. Yasukawa, Editor "Signaling Requirements for
>              Point-to-Multipoint …
[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.
2006-12-11
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2006-12-08
07 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2006-12-08
07 Brian Carpenter
[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 …
[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/
2006-12-08
07 Brian Carpenter [Ballot comment]
Nit from Gen-ART reviewer Vijay K. Gurbani:
S8.2 - s/to the value, that/to the value that/
2006-12-06
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-12-06
07 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2006-12-06
07 Ross Callon Ballot has been issued by Ross Callon
2006-12-06
07 Ross Callon Created "Approve" ballot
2006-12-06
07 Ross Callon Placed on agenda for telechat - 2006-12-14 by Ross Callon
2006-12-05
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman.
2006-11-25
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hilarie Orman
2006-11-25
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hilarie Orman
2006-11-22
07 Amy Vezza Last call sent
2006-11-22
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-11-21
07 Ross Callon Last Call was requested by Ross Callon
2006-11-21
07 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2006-11-21
07 (System) Ballot writeup text was added
2006-11-21
07 (System) Last call text was added
2006-11-21
07 (System) Ballot approval text was added
2006-11-21
07 Ross Callon Intended Status has been changed to Proposed Standard from None
2006-11-04
07 Ross Callon
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 …
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.
2006-11-04
07 Ross Callon Draft Added by Ross Callon in state Publication Requested
2006-08-04
06 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-06.txt
2006-05-09
05 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-05.txt
2006-05-01
04 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-04.txt
2005-10-27
03 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-03.txt
2005-07-19
02 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-02.txt
2005-01-31
01 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-01.txt
2004-11-18
00 (System) New version available: draft-ietf-mpls-rsvp-te-p2mp-00.txt