Protocol Action: 'GMPLS Based Segment Recovery' to Proposed Standard
The IESG <iesg-secretary@ietf.org> Mon, 15 January 2007 21:49 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZhZ-0007pC-Ou for ccamp-archive@ietf.org; Mon, 15 Jan 2007 16:49:13 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZhY-0001Th-7m for ccamp-archive@ietf.org; Mon, 15 Jan 2007 16:49:13 -0500
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1H6ZSp-0005nC-JR for ccamp-data@psg.com; Mon, 15 Jan 2007 21:33:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7
Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from <ietf@ietf.org>) id 1H6ZSj-0005mh-NP for ccamp@ops.ietf.org; Mon, 15 Jan 2007 21:33:57 +0000
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A090A26F0C; Mon, 15 Jan 2007 21:33:52 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6ZSi-0005Ck-Hb; Mon, 15 Jan 2007 16:33:52 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, ccamp mailing list <ccamp@ops.ietf.org>, ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Protocol Action: 'GMPLS Based Segment Recovery' to Proposed Standard
Message-Id: <E1H6ZSi-0005Ck-Hb@stiedprstage1.ietf.org>
Date: Mon, 15 Jan 2007 16:33:52 -0500
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7
The IESG has approved the following document: - 'GMPLS Based Segment Recovery ' <draft-ietf-ccamp-gmpls-segment-recovery-03.txt> as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-03.txt Technical Summary This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects. Working Group Summary No dissent reported. Good WG consensus. Protocol Quality Ross Callon has reviewed this for the IESG. There are multiple implementations and deployment. Note to RFC Editor Note, this document and one other document (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt) should be progressed together. This document references the other document. Progressing together will ensure the RFC Ed can sort out details, including cross-references between the two documents. There is an IANA nit that will need to be fixed (see IANA note below). Also, the reference to draft-lang-ccamp-gmpls-recovery-e2e-signaling should be corrected to draft-ietf-ccamp-gmpls-recovery-e2e-signaling IANA Note There is an IANA nit that will need to be fixed. In particular: sections 9.3 and 9.4 suggest the same value (198) for the SECONDARY_EXPLICIT_ROUTE and SECONDARY_RECORD_ROUTE objects. Also, I am told that this value has already (recently) been assigned to an unrelated object. Thus, the IANA will need to straighten this out. These and related IANA considerations have been cleared up by Adrian Farrel's email to the IANA on Thu, 14 Dec 2006 10:52:16. His explanation of IANA considerations are (cut and pasted from the attachment to Adrian's email): IANA requests for [e2e] draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt [seg] draft-ietf-ccamp-gmpls-segment-recovery-03.txt All other references are provided for information and context. ==================================================== Registry: RSVP Class Names, Class Numbers, and Class Types 20 EXPLICIT_ROUTE [RFC3209] Class Types or C-Types: 1 Type 1 Explicit Route [RFC3209] Sub-object type 1 IPv4 prefix [RFC3209] 2 IPv6 prefix [RFC3209] 3 Label [RFC3473] 4 Unnumbered Interface ID [RFC3477] 32 Autonomous system number [RFC3209] 37 Reserved [seg] 21 ROUTE_RECORD [RFC3209] (also known as RECORD_ROUTE) Class Types or C-Types: 1 Type 1 Route Record [RFC3209] Sub-object type 1 IPv4 address [RFC3209] 2 IPv6 address [RFC3209] 3 Label [RFC3473] 4 Unnumbered Interface ID [RFC3477] 5 RRO Attributes [RFC4420] 37 Reserved [seg] 37 PROTECTION [RFC3473] Class Types or C-Types: 1 Type 1 Protection [RFC3473] 2 Type 2 [e2e] 38 PRIMARY PATH ROUTE [e2e] Class Types or C-Types: 1 Type 1 Primary Path Route [e2e] 198 ALARM_SPEC [RFC4783] Class Types or C-Types: 1 Type 1 RESERVED [RFC4783] 2 Type 2 RESERVED [RFC4783] 3 IPv4 IF_ID ALARM_SPEC [RFC4783] 4 IPv6 IF_ID ALARM_SPEC [RFC4783] 199 ASSOCIATION [e2e] Class Types or C-Types: 1 Type 1 IPv4 Association [e2e] 2 Type 2 IPv6 Association [e2e] 200 SECONDARY_EXPLICIT_ROUTE [seg] Same C-Type values as EXPLICIT_ROUTE object (C-Num 20) with the following additions: For Class 1, C-Type 1, the following additional Sub-object type is defined: Sub-object type 37 Protection [seg] 201 SECONDARY_RECORD_ROUTE [seg] Same C-Type values as EXPLICIT_ROUTE object (C-Num 20) with the following additions: For Class 1, C-Type 1, the following additional Sub-object type is defined: Sub-object type 37 Protection [seg] ============================================================ Registry: GMPLS Signaling Parameters Interface_ID Types Type Length Format Description Reference ---- ------ ---------- -------------------------- --------- 512 8 See below REFERENCE_COUNT [RFC4783] 513 8 See below SEVERITY [RFC4783] 514 8 See below GLOBAL_TIMESTAMP [RFC4783] 515 8 See below LOCAL_TIMESTAMP [RFC4783] 516 varies See below ERROR_STRING [RFC4783] ============================================================ Registry: GMPLS Signaling Parameters Administrative Status Information Flags Value Name Reference ----------- -------------------------------- --------- 0x80000000 Reflect (R) [RFC3473][RFC3471] 0x00000020 Lockout (L) [e2e] 0x00000010 Inhibit Alarm Communication (I) [RFC4783] 0x00000004 Testing (T) [RFC3473][RFC3471] 0x00000002 Administratively down (A) [RFC3473][RFC3471] 0x00000001 Deletion in progress (D) [RFC3473][RFC3471] ============================================================ Registry: RSVP Error Codes and Values Error Code Meaning 01 Admission Control Failure [RFC2205] The sixteen bits of the Error Value field are ssur cccc cccc cccc as defined in [RFC2205] The following globally-defined sub-codes may appear in the low- order 12 bits when ssur = 0000: Sub-code Meaning Reference -------- ------------------------------ --------- 1 Delay bound cannot be met [RFC2205] 2 Requested bandwidth unavailable [RFC2205] 3 MTU in flowspec larger than [RFC2205] interface MTU 4 LSP Admission Failure [e2e] 5 Bad Association Type [e2e] 02 Policy Control Failure [RFC2205] This Error Code has the following globally-defined Error Value sub-codes: 0 = Information reporting [RFC2750] 1 = Warning [RFC2750] 2 = Reason unknown [RFC2750] 3 = Generic Policy Rejection [RFC2750] 4 = Quota or Accounting violation [RFC2750] 5 = Flow was preempted [RFC2750] 6 = Previously installed policy expired [RFC2750] (not refreshed) 7 = Previous policy data was replaced & [RFC2750] caused rejection 8 = Policies could not be merged [RFC2750] (multicast) 9 = PDP down or non functioning [RFC2750] 10 = Third Party Server (e.g., Kerberos) [RFC2750] unavailable 11 = POLICY_DATA object has bad syntax [RFC2750] 12 = POLICY_DATA object failed Integrity [RFC2750] Check 13 = POLICY_ELEMENT object has bad syntax [RFC2750] 14 = Mandatory PE Missing (Empty PE is in [RFC2750] the PD object) 15 = PEP Out of resources to handle [RFC2750] policies. 16 = PDP encountered bad RSVP objects or [RFC2750] syntax 17 = Service type was rejected [RFC2750] 18 = Reservation Style was rejected [RFC2750] 19 = FlowSpec was rejected (too large) [RFC2750] 20 = Hard Pre-empted [e2e] 24 Routing Problem [RFC3209] This Error Code has the following globally-defined Error Value sub-codes: 1 = Bad EXPLICIT_ROUTE object [RFC3209] : (snip) 16 = Unknown Interface Index [RFC3477] 17 = Unsupported LSP Protection [e2e] 18 = PROTECTION object not applicable [e2e] 19 = Bad PRIMARY PATH_ROUTE object [e2e] 20 = PRIMARY PATH_ROUTE object not [e2e] applicable 21 = LSP Segment Protection Failed [seg] 25 Notify Error [RFC3209] This Error Code has the following globally-defined Error Value sub-codes: 1 = RRO too large for MTU [RFC3209] 2 = RRO Notification [RFC3209] 3 = Tunnel locally repaired [RFC3209] 4 = Control Channel Active State [RFC3473] 5 = Control Channel Degraded State [RFC3473] 6 = Preferable path exists [RFC4736] 7 = Local link maintenance required [RFC4736] 8 = Local node maintenance required [RFC4736] 9 = LSP Failure [e2e] 10 = LSP Recovered [e2e] 11 = LSP Locally Failed [e2e] 31 Alarms [RFC4783] The Error Value sub-codes for this Error Code have values and meanings identical to the values and meanings defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. ============================================================ Registry: GMPLS Signaling Parameters Association Type (This is a new registry) Assignment by IANA are subject to IETF expert review process i.e. IETF Standards Track RFC Action. Value Type Reference ----- ----------------- --------- 0 Reserved [e2e] 1 Recovery (R) [e2e] 2 Resource Sharing (R) [seg]