draft-ietf-ccamp-assoc-info-02.txt   draft-ietf-ccamp-assoc-info-03.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Category: Informational Category: Informational
Expiration Date: November 1, 2011 Expiration Date: April 25, 2012
May 1, 2011 October 25, 2011
Usage of The RSVP Association Object Usage of The RSVP Association Object
draft-ietf-ccamp-assoc-info-02.txt draft-ietf-ccamp-assoc-info-03.txt
Abstract Abstract
The RSVP ASSOCIATION object was defined in the context of GMPLS The RSVP ASSOCIATION object was defined in the context of GMPLS
(Generalized Multi-Protocol Label Switching) controlled label (Generalized Multi-Protocol Label Switching) controlled label
switched paths (LSPs). In this context, the object is used to switched paths (LSPs). In this context, the object is used to
associate recovery LSPs with the LSP they are protecting. This associate recovery LSPs with the LSP they are protecting. This
document reviews how association is to be provided in the context document reviews how association is to be provided in the context
of GMPLS recovery. No new procedures or mechanisms are of GMPLS recovery. No new procedures or mechanisms are
defined by this document and it is strictly informative in nature. defined by this document and it is strictly informative in nature.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 1, 2011 This Internet-Draft will expire on April 25, 2012
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 18 skipping to change at page 7, line 18
cases. The 3 additional requirements are, by [RFC4872] Section cases. The 3 additional requirements are, by [RFC4872] Section
number: number:
o Section 7.3 -- "The Association ID MUST be set by default to the o Section 7.3 -- "The Association ID MUST be set by default to the
LSP ID of the protected LSP corresponding to N = 1." LSP ID of the protected LSP corresponding to N = 1."
When considering this statement together with the 3 cases When considering this statement together with the 3 cases
enumerated above, it can be seen that this statement clarifies enumerated above, it can be seen that this statement clarifies
which LSP ID value should be used when a single shared protection which LSP ID value should be used when a single shared protection
LSP is established simultaneously with (case 3), or after (case LSP is established simultaneously with (case 3), or after (case
2), more than one LSP to be protected. 2), and more than one LSP to be protected.
o Section 8.3 -- "Secondary protecting LSPs are signaled by setting o Section 8.3 -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated the ASSOCIATION object, the Association ID to the associated
primary working LSP ID, which MUST be known before signaling of primary working LSP ID, which MUST be known before signaling of
the secondary LSP." the secondary LSP."
This requirement clarifies that the Rerouting without Extra- This requirement clarifies that when using the Rerouting without
Traffic type of recovery is required to follow either case 1 or Extra-Traffic type of recovery it is required to follow either
3, but not 2, as enumerated above. case 1 or 3, but not 2, as enumerated above.
o Section 9.3 -- "Secondary protecting LSPs are signaled by setting o Section 9.3 -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated the ASSOCIATION object, the Association ID to the associated
primary working LSP ID, which MUST be known before signaling of primary working LSP ID, which MUST be known before signaling of
the secondary LSP." the secondary LSP."
This requirement clarifies that the Shared-Mesh Restoration type This requirement clarifies that when using the Shared-Mesh
of recovery is required to follow either case 1 or 3, but not 2, Restoration type of recovery it is required to follow either case
as enumerated above. 1 or 3, but not 2, as enumerated above.
o Section 11.1 -- "In both cases, the Association ID of the o Section 11.1 -- "In both cases, the Association ID of the
ASSOCIATION object MUST be set to the LSP ID value of the ASSOCIATION object MUST be set to the LSP ID value of the
signaled LSP." signaled LSP."
This requirement clarifies that when using the LSP Rerouting type This requirement clarifies that when using the LSP Rerouting type
of recovery is required to follow either case 1 or 3, but not 2, of recovery it is required to follow either case 1 or 3, but not
as enumerated above. 2, as enumerated above.
2.3. Segment Recovery LSP Association 2.3. Segment Recovery LSP Association
GMPLS segment recovery is defined in [RFC4873]. Segment recovery GMPLS segment recovery is defined in [RFC4873]. Segment recovery
reuses the LSP association mechanisms, including the Association Type reuses the LSP association mechanisms, including the Association Type
field value, defined in [RFC4872]. The primary text to this effect field value, defined in [RFC4872]. The primary text to this effect
in [RFC4873] is: in [RFC4873] is:
3.2.1. Recovery Type Processing 3.2.1. Recovery Type Processing
skipping to change at page 10, line 29 skipping to change at page 10, line 29
No additional behavior is needed in order to support changes in the No additional behavior is needed in order to support changes in the
set of ASSOCIATION objects included in an LSP, as long as the change set of ASSOCIATION objects included in an LSP, as long as the change
represents either a new association or a change in identifiers made represents either a new association or a change in identifiers made
as described in Section 2.2. as described in Section 2.2.
4. Security Considerations 4. Security Considerations
This document reviews procedures defined in [RFC4872] and [RFC4873] This document reviews procedures defined in [RFC4872] and [RFC4873]
and does not define any new procedures. As such, no new security and does not define any new procedures. As such, no new security
considerations are introduced in this document.. considerations are introduced in this document.
5. IANA Considerations 5. IANA Considerations
There are no new IANA considerations introduced by this document. There are no new IANA considerations introduced by this document.
6. Acknowledgments 6. Acknowledgments
This document formalizes the explanation provided in an e-mail to the This document formalizes the explanation provided in an e-mail to the
working group authored by Adrian Farrel, see [AF-EMAIL]. This working group authored by Adrian Farrel, see [AF-EMAIL]. This
document was written in response to questions raised in the CCAMP document was written in response to questions raised in the CCAMP
skipping to change at line 499 skipping to change at line 499
http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html, http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html,
November 18, 2008. November 18, 2008.
8. Author's Addresses 8. Author's Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Generated on: Mon, May 02, 2011 10:15:27 AM Generated on: Tue, Oct 25, 2011 4:01:38 PM
 End of changes. 10 change blocks. 
14 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/