From internet-drafts@ietf.org Sun Dec 1 22:12:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376D31AE2FE; Sun, 1 Dec 2013 22:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAEbxJnvuA-m; Sun, 1 Dec 2013 22:12:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8CF1AE0BE; Sun, 1 Dec 2013 22:12:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202061214.21247.19128.idtracker@ietfa.amsl.com> Date: Sun, 01 Dec 2013 22:12:14 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-oam-configuration-fwk-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:12:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE extensions for OAM Configuration Author(s) : Attila Takacs Don Fedyk Jia He Filename : draft-ietf-ccamp-oam-configuration-fwk-11.txt Pages : 21 Date : 2013-12-01 Abstract: Operations, Administration and Maintenance is an integral part of transport connections, hence it is required that Operations, Administration and Maintenance functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, Operations, Administration and Maintenance entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure Operations, Administration and Maintenance entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of Operations, Administration and Maintenance entities along with Label Switched Path signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-oam-configuration-fwk-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Attila.Takacs@ericsson.com Sun Dec 1 22:17:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A653B1AE192 for ; Sun, 1 Dec 2013 22:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0x3orMja9ns for ; Sun, 1 Dec 2013 22:17:28 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 218191AE2FD for ; Sun, 1 Dec 2013 22:17:26 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-fe-529c25f4ca76 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 31.92.22496.4F52C925; Mon, 2 Dec 2013 07:17:24 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.240]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 07:17:23 +0100 From: Attila Takacs To: "adrian@olddog.co.uk" , 'CCAMP WG' Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-oam-configuration-fwk Thread-Index: Ac7krbrBAUSlQM6hTp61kHtymhwAjAKd9KJQ Date: Mon, 2 Dec 2013 06:17:23 +0000 Message-ID: References: <030901cee4ad$c2a484c0$47ed8e40$@olddog.co.uk> In-Reply-To: <030901cee4ad$c2a484c0$47ed8e40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre4X1TlBBpP/Cln86LnBbPFkzg0W ByaPJUt+Mnms2LySMYApissmJTUnsyy1SN8ugSvj7rE5jAUrZzJW3J//mb2BcVF+FyMnh4SA icTxh31MELaYxIV769m6GLk4hAROMEqsXnqRCcJZzCix9MNLFpAqNgEDiQvNk5lBbBEBH4n/ L5rZQGxhAQ+Jr5u/QcU9JRofrWKDsI0kHndMB7NZBFQkzuxpBZrDwcEr4Cvx+WECSFhIwEpi +rplYK2cAtYSb9euBStnBDro+6k1YMcxC4hL3HoyH+pQAYkle84zQ9iiEi8f/2OFsJUkVmy/ xAhRryOxYPcnNghbW2LZwtdg9bwCghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRsni1OLi 3HQjA73c9NwSvdSizOTi4vw8veLUTYzAiDm45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwNg8o39lBPc2gwhVU+H9YbJvohtuCOUc67lYfvG7/SvDN5PX PJ33bkmn985bXTcFPcWkAtxCH3u69P3X/p12IjHVPGMKY9Y9Dsl+hzsxu4s+5OX+NvwmNNmM dY/P7P9r724xudNX6HZ5V+apBV8TLaaE/dBsKF+tWHzjtVLN/vvy1fNW3ZrtfUSJpTgj0VCL uag4EQAC/7GlZgIAAA== Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-oam-configuration-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:17:30 -0000 Hi Adrian, all, Thanks for the review!=20 We have updated the document to address your comments. You can also find be= low the updates we have made to resolve your comments, look for [at]. Thanks, Attila -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, November 18, 2013 2:30 PM To: draft-ietf-ccamp-oam-configuration-fwk.all@tools.ietf.org Cc: 'CCAMP WG' Subject: [CCAMP] AD review of draft-ietf-ccamp-oam-configuration-fwk Thank you for this document. I think it is well written and clear. It is ve= ry nearly ready to be advanced for publication, but we need to do a little = work on the IANA section to make it completely clear for IANA. I suggest th= e following, but please review it carefully because I have introduced new m= aterial that you did not have in your original text. I also have some smaller nits and editorial comments, and a few places wher= e it would be really helpful to clarify the text. I've moved the I-D status to show I expect to see a revision, but please di= scuss these points with me if you like. Thanks for the work. Adrian =3D=3D=3D OLD 5. IANA Considerations Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs to be allocated in the ADMIN_STATUS Object. Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") needs to be allocated in the LSP Attributes Flags Registry. This document specifies one new TLV to be carried in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv messages: OAM Configuration TLV. One new Error Code: "OAM Problem" and a set of new values: "MEP establishment not supported", "MIP establishment not supported", "Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch" and "Unsupported OAM Function" needs to be assigned. IANA is requested to open a new registry: "RSVP-TE OAM Configuration Registry" that maintains the "OAM Type" code points, an associated sub-TLV space, and the allocations of "OAM Function Flags" within the OAM Configuration TLV. RSVP-TE OAM Configuration Registry OAM Type Description ------------ ------------------ 0-255 Reserved Sub-TLV Type Description ------------ ------------------------------------ 0 Reserved 1 OAM Function Flags Sub-TLV 2-31 Reserved for generic Sub-TLVs 32- Reserved for technology specific Sub-TLVs OAM Function Flag bit# Description ---------------------- ------------------------------- 0 Continuity Check (CC) 1 Connectivity Verification (CV) 2 Fault Management Signal (FMS) 3 Performance Monitoring/Loss (PM/Loss) 4 Performance Monitoring/Delay (PM/Delay) 5 Performance Monitoring/Throughput Measurement (PM/Throughput) 6- Reserved NEW 5. IANA Considerations 5.1. ADMIN_STATUS Object Bit Flags IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" with a sub-registry called "Administrative Status Information Flags". IANA is requested to allocate two new flags as follows: Bit Number | Hex Value | Name | Reference -----------+------------+--------------------------+----------------=20 TBA | TBA | OAM Alarms Enabled (O) | [This.ID] TBA | TBA | OAM Flows Enabled" (M) | [This.ID] =20 5.2. LSP Attributes Flags IANA maintains a registry called "Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Parameters" with a subregistry called "Attribute Flags". IANA is requested to allocate two new flags as follows: Bit | Name | Attribute | Attribute | RRO | Ref No | | Flags Path | Flags Resv | | ----+--------------------------+------------+------------+-----+----- TBA | OAM MEP entities desired | Yes | No | Yes | TBA | OAM MIP entities desired | Yes | No | Yes | 5.3. New LSP Attributes IANA maintains a registry called "Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Parameters" with a subregistry called "Attributes TLV Space" =20 IANA is requested to allocate one new TLV type as follows: Type | Name | Allowed on | Allowed on | Ref | | LSP_ATTRIBUTES | LSP_REQUIRED_ | | | | ATTRIBUTES | -----+-----------------------+----------------+---------------+------ TBA | OAM Configuration TLV | Yes | Yes | =20 5.4. RSVP Error Code IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". IANA is requested to allocate one new Error Code as follows: Error Code | Meaning | Reference =20 -----------+-------------+------------- TBA | OAM Problem | [This.ID] The value is to be selected from the range 0-239. The following Error Value sub-codes are defined for this new Error Code as follows: Value | Description | Reference ------+---------------------------------+-------------- 1 | MEP establishment not supported | [This.ID] 2 | MIP establishment not supported | [This.ID]=20 3 | Unsupported OAM Type | [This.ID]=20 4 | Configuration Error | [This.ID]=20 5 | OAM Type Mismatch | [This.ID]=20 6 | Unsupported OAM Function | [This.ID]=20 5.5. RSVP-TE OAM Configuration Registry IANA is requested to create a new registry called "RSVP-TE OAM Configuration Registry".=20 IANA is requested to create sub-registries as defined in the following subsections: =20 5.5.1. OAM Types Sub-Registry IANA is requested to create the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Registration Procedures -------+------------------------- 0-255 | IETF Review There are no initial values in this registry. IANA should show the registry as follows: OAM Type Number | OAM Type Description | Reference ----------------+----------------------+-------------- 0-255 | Not allocated | 5.5.2. OAM Sub-TLVs Sub-Registry IANA is requested to create the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Purpose | Registration Procedures -------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65534 | Technology-specific Sub-TLVs | IETF Review 65535-65536 | Experimental Sub-TLVs | Experimental IANA is requested to populate the registry as follows: Sub-TLV Type | Description | Reference -------------+----------------------------+------- 0 | Reserved | [This.ID] 1 | OAM Function Flags Sub-TLV | [This.ID] 2-31 | Not allocated | 32-65534 | Not allocated | 5.5.3. OAM Function Flags Sub-Registry IANA is requested to create the "OAM Function Flags Sub-Registry"=20 sub-registry of the "RSVP-TE OAM Configuration Registry". New values in the registry are allocated by "IETF Review". There is no top value to the range. Bits are counted from bit 0 as the first bit transmitted. IANA is requested to populate the registry as follows. OAM Function Flag | Description=20 bit number | =20 ------------------+--------------------------------------------- 0 | Continuity Check (CC) 1 | Connectivity Verification (CV) 2 | Fault Management Signal (FMS) 3 | Performance Monitoring/Loss (PM/Loss) 4 | Performance Monitoring/Delay (PM/Delay) 5 | Performance Monitoring/Throughput Measurement | (PM/Throughput) 6-... | Not allocated END [at] Thanks, I have updated the IANA section with the suggested text. --- Please expand OAM and LSP in the Abstract. [at] Done. --- In Section 3 you have some terms defined (MP, ME, MIP, MEP). Some of these = terms are consistent with the use of terms in draft-ietf-mpls-tp- rosetta-s= tone and some are not. Is there a specific reason why you have diverged fro= m this other draft? If not, you should align this work. [at] Aligned to rosetta-stone --- Section 3.1 When using the GMPLS control plane, establishment and enabling of OAM functions MUST be bound to RSVP-TE message exchanges. I think you mean... When using the GMPLS control plane for both LSP establishment and to enable OAM functions on the LSPs, the control of both processes is bound to RSVP-TE message exchanges. [at] Thanks, changed to the suggested text. --- Section 4.1 If the "OAM MEP entities desired" bit is set it is indicating that the establishment of OAM MEP entities are required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported an error MUST be generated: "OAM Problem/MEP establishment not supported". I can see how this works for an implementation of this document that choose= s not to (or cannot) support OAM on a given LSP. I do not understand how it= works when a node that does not support this document receives the "OAM ME= P entities desired" bit set - it cannot return the desired response because= it doesn't support this document. To handle this, I think you need to split the two cases. 1. Does not support the establishment of MEPs on this specific LSP 2. Does = not support any establishment of MEPs. In the second case you need to determine how this will be made to work. Since 5420 specifies that the unknown bit in an LSP_ATTRIBUTE object will b= e silently ignored, you need to use the absence of a positive acknowledgeme= nt to indicate to the ingress that the function is not supported. See also Section 4.4. [at] The use of OAM Configuration information in the Resv message is descri= bed in Section 3. To clarify the operation in the above case I have added t= he following paragraph to Section 3.1: In case an egress LSR does not support the extensions defined in this document, according to RFC5420, it will sile= ntly ignore the new LSP Attributes Flags as well as the TLVs carrying additional= OAM configuration information, and therefore no error will be ra= ised that would notify the ingress LSR about the missing OAM configuration actions on the egress side. However, as described above, an egress LSR conformant to the specificati= on of this document will set the LSP Attributes Flags and inclu= de the OAM Configuration TLV in the Resv message indicating the configuration of the OAM mechanisms, therefore an ingress LS= R by detecting the missing information in the Resv message wil= l be able to recognize that the remote end does not support th= e OAM configuration functionality and therefore it SHOULD tear down the LSP, and if appropriate signal the LSP without any = OAM configuration information. --- Section 4.1 This bit MUST only be set if the "OAM MEP entities desired" bit is set. This is a rather unusual construction. I think you may mean... If the "OAM MEP entities desired" bit is not set then this bit MUST NOT be set. [at] Thanks, changed to the suggested text. --- Section 4.1 If the establishment of a MIP is not supported an error MUST be generated: "OAM Problem/MIP establishment not supported". Exactly the same problem as described for "OAM MEP entities desired" above except for the additional behavior if used on LSP_REQUIRED_ATTRIBUTES= . (See also 4.4) [at] I added the following clarification. If an intermediate LSR does not support the extensions defined in this document it will not recognize the "OAM MIP entities desired" flag and although the LSP_REQUIRED_ATTRIBUTES object was used it will not configure MIP entities and will not raise any errors. If LSRs that are not supporting this document are to be assumed in the network, the ingress LSR SHOULD collect per-hop information about the LSP Attributes utilizing the LSP Attributes sub-object of the Record Route Object as defined in RFC5420.=20 When the Record Route object is received the ingress SHOULD check whether all intermediate LSRs set the "OAM MIP entities desired" flag indicating support of the function, if not, depending on operator policy the LSP MAY need to be torn down. --- Section 4.2 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to assign). If this is a specific request that the value 3 is assigned, you should refl= ect this in Section 5. [at] removed "(3)" --- Section 4.2 When carried in the LSP_ATTRIBUTES Object, intermediate nodes not supporting the OAM Type pass the object forward unchanged as specified in [RFC5420], and only Label Edge Nodes MUST generate an error if the OAM Type is not supported at the LSP end-point. There are a couple of issues here. You have defined a "Label Edge Node". You also have another "only MUST" construction. How about... When carried in the LSP_ATTRIBUTES Object, intermediate nodes not supporting the OAM Type pass the object forward unchanged as specified in [RFC5420]. Ingress and egress nodes that support the OAM Configuration TLV but that do not=20 support a specific OAM Type MUST respond with an error indicating "OAM Problem/Unsupported OAM Type". [at] Thanks, changed to the suggested text. --- Section 4.2 Can multiple copies of the OAM configuration TLV be present in one LSP_ATTR= IBUTES object? [at] Only one, changed text: OLD The OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path= and Resv messages. NEW One OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path= and Resv messages. --- I think section 4.2 needs to mention the generic sub-TLVs. Reading the text= as it stands, it appears that all sub-TLVs are for technology- specific OA= M. So you need: - To explain generic sub-TLVs so that future sub-TLVs can be defined - To include a forward pointer to 4.2.1 [at] added the following paragraph for clarification. Two groups of TLVs are defined: generic sub-TLVs and technology specific sub-TLVs. Generic sub-TLVs carry information that are applicable independent of the actual OA= M technology, while technology specific sub-TLVs are providing configuration parameters for specific OAM technologies. This document defines one generic sub-TLV, see Section 4.2.1, whi= le it is foreseen that technology specific sub-TLVs will be defined b= y separate documents. --- Section 4.2.1 As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be included in the "OAM Configuration TLV". I think you mean: The "OAM Configuration TLV" MUST always include a single instance of=20 the "OAM Function Flags Sub-TLV" and it MUST always be the first sub- TLV. [at] Thanks, changed to the suggested text. --- Section 4.2.1 You need to reiterate that the Length field counts octets (because for a va= riable length bitmap someone might easily think it is a count of bits) and = then you need to explain how to set the length field and how to handle padd= ing. [at] Added the text below. The TLV is padded to 4-octet alignment. The Length field indicates the size of the padded TLV in octets. --- Section 4.2.2 One technology specific sub-TLV MAY be defined for each "OAM Type". This sub-TLV MUST contain any further OAM configuration information for that specific "OAM Type". The technology specific sub-TLV, when used, MUST be carried within the OAM Configuration TLV. IANA is requested to maintain the OAM technology specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry". The use of 2119 language here is odd. It is really meant for implementation= instructions, not to constrain future specifications. How about saying: If technology-specific configuration information is needed for a specific "OAM Type", then this information is carried in a technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM Configuration TLV MUST NOT contain more than one technology- specific sub-TLV. IANA is requested to maintain the OAM technology specific sub-TLV space in the new "RSVP-TE OAM Configuration=20 Registry". [at] Thanks, changed to the suggested text. --- Section 4.3 s/are allocated by this draft/are allocated by this document/ [at] done. --- Section 4.3 When the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is cleared, no OAM packets are emitted. When the bit is sent, is that MAY, SHOULD, or MUST send OAM packets? If clear, I think that is MUST NOT be sent. Why do you say "OAM packets"? Doesn't this I-D apply to all OAM mechanisms? [at] Changed to "When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled." --- Section 4.3 When the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled and associated consequent actions are executed including the notification to the management system. When this bit is cleared, alarms are suppressed and no action is executed and the management system is not notified. I understand "When this bit is cleared, alarms are suppressed" and "the man= agement system is not notified", but I don't understand "no action is execu= ted." If there is no action on OAM detecting some issue, then why run OAM? = There is clearly something you had in mind when you created two separate ad= min statuses, but the purpose is not clear in your document. [at] The operation and use of these two bits are described in Section 3. T= o highlight this I added a note saying: "For a detailed description of the = use of these flags see Section 3." _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Wed Dec 11 03:24:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF79F1A1F7D; Wed, 11 Dec 2013 03:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F55VnMYxauUJ; Wed, 11 Dec 2013 03:24:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F42381ABBB1; Wed, 11 Dec 2013 03:24:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211112423.17432.99756.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 03:24:23 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:24:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Fatai Zhang Sergio Belotti Rajan Rao John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt Pages : 35 Date : 2013-12-11 Abstract: This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Wed Dec 11 03:26:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78601AC82B for ; Wed, 11 Dec 2013 03:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETYrJN1TnQjY for ; Wed, 11 Dec 2013 03:26:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8761AC441 for ; Wed, 11 Dec 2013 03:26:34 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-8c-52a84be3b0a6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 91.97.23787.3EB48A25; Wed, 11 Dec 2013 12:26:28 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.241]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 12:26:27 +0100 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt Thread-Index: AQHO9mOeszcEUE1OHkWOW6FcLig8W5pO2pAw Date: Wed, 11 Dec 2013 11:26:26 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812648BC4@ESESSMB301.ericsson.se> References: <20131211112423.17432.99756.idtracker@ietfa.amsl.com> In-Reply-To: <20131211112423.17432.99756.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvre4T7xVBBpsnslk8mXODxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGaeObGAu2CpQcWfzH9YGxgc8XYycHBICJhKbTs1hhbDFJC7c W8/WxcjFISRwiFFi8eqjTBDOEkaJX+s/A2U4ONgErCSeHPIBaRAR0JXYu/E6cxcjO4ewgJfE 7FCIqLfEsx1H2CBsI4mWi8vAxrMIqErMfj+fCaSaV8BX4n4wSFRIwFHi9JvXTCA2p4CTRFv7 T7BORgFZiQm7FzGC2MwC4hK3nsxngjhSQGLJnvPMELaoxMvH/6COV5Rof9oAVa8ncWPqFDYI W1ti2cLXYPW8AoISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkb23MTMnPRyw02MwHA/uOW3 7g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRef30MPeuXR6d t7b2//nrdk1A8W7yhInNVWcyz+gcV9zw3iy61mjboas9r3g0vy44XjlHy+imT8gSeQ29y39d Jsy2rLr8Mft3Kpe6ocU6oymcjV2GRzf1S2RVel4wWfQy4NzWpa+jazIlDkzOP807I+zZKdMl 8bPNWV1tSpcfropfM1N5WqGeEktxRqKhFnNRcSIAVG0ms0UCAAA= Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:26:45 -0000 Dear OTNers, Just an update to fix some GEN art review comments I missed in v12. BR Daniele (&autohors) -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: mercoled=EC 11 dicembre 2013 12:24 To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Fatai Zhang Sergio Belotti Rajan Rao John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt Pages : 35 Date : 2013-12-11 Abstract: This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From iesg-secretary@ietf.org Wed Dec 11 05:03:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0232A1AD9AB; Wed, 11 Dec 2013 05:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37pgaegjCs3Z; Wed, 11 Dec 2013 05:03:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 407871AD93D; Wed, 11 Dec 2013 05:03:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131211130331.13897.17518.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 05:03:31 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (GMPLS RSVP-TE extensions for OAM Configuration) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:03:33 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'GMPLS RSVP-TE extensions for OAM Configuration' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-1-5 (this last call is extended slightly to cover the holiday period). Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Operations, Administration and Maintenance is an integral part of transport connections, hence it is required that Operations, Administration and Maintenance functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, Operations, Administration and Maintenance entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure Operations, Administration and Maintenance entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of Operations, Administration and Maintenance entities along with Label Switched Path signaling. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1021/ http://datatracker.ietf.org/ipr/1623/ From iesg-secretary@ietf.org Wed Dec 11 07:21:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8451ADF6B; Wed, 11 Dec 2013 07:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLF9crfJmI_4; Wed, 11 Dec 2013 07:21:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6F91ADF9E; Wed, 11 Dec 2013 07:21:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211152131.16480.99806.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 07:21:31 -0800 Cc: ccamp mailing list , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks' to Proposed Standard (draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:21:36 -0000 The IESG has approved the following document: - 'Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks' (draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt) as Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/ Technical Summary This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. This document is one of four informational and standards track documents going through the publication process as a set. Working Group Summary There were many points of discussion, some more "intense" than others. At this point there does not appear to be any notable discontent with the documented solution. Document Quality The base GMPLS OSPF-TE mechanisms are implemented and deployed. Implementation status of the extensions defined in this document has not been publicly disclosed, but several implementations are expected. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd Adrian Farrel (Adrian@olddog.co.uk) is the Responsible AD From wwwrun@rfc-editor.org Thu Dec 12 07:21:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049DB1ADE88 for ; Thu, 12 Dec 2013 07:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwFTk6mlSPjQ for ; Thu, 12 Dec 2013 07:21:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 06EC91ADF47 for ; Thu, 12 Dec 2013 07:21:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4338E7FC397; Thu, 12 Dec 2013 07:21:38 -0800 (PST) To: tnadeau@cisco.com, adrian@olddog.co.uk, stbryant@cisco.com, adrian@olddog.co.uk, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20131212152138.4338E7FC397@rfc-editor.org> Date: Thu, 12 Dec 2013 07:21:38 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC4803 (3831) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 15:21:47 -0000 The following errata report has been submitted for RFC4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=3831 -------------------------------------- Type: Editorial Reported by: Adrian Farrel Section: 6 Original Text ------------- In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x00000012, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00000016, mplsXCOutSegmentIndex = 0x00000013, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } Corrected Text -------------- In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x00000012, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000016, mplsXCOutSegmentIndex = 0x00000013, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } Notes ----- The entries in the mplsXCTable are indexed by {mplsXCIndex, mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same LSP should share a common value of mplsXCIndex because mplsTunnelXCPointer can be set to point to the first entry and then all of the other entries can be found. The error in the example in Section 6 is that it shows a different value of mplsXCIndex for the reverse direction cross-connects. It should be set to the same value as is used for the forward direction cross-connect. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) -------------------------------------- Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Publication Date : February 2007 Author(s) : T. Nadeau, Ed., A. Farrel, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From adrian@olddog.co.uk Thu Dec 12 10:55:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB51AE3E2 for ; Thu, 12 Dec 2013 10:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAsnKjf3zaAW for ; Thu, 12 Dec 2013 10:55:37 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D6E961AE3E0 for ; Thu, 12 Dec 2013 10:55:36 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBCItTgp023085 for ; Thu, 12 Dec 2013 18:55:30 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBCItTIr023077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 12 Dec 2013 18:55:29 GMT From: "Adrian Farrel" To: "'CCAMP WG'" References: <20131212152138.4338E7FC397@rfc-editor.org> In-Reply-To: <20131212152138.4338E7FC397@rfc-editor.org> Date: Thu, 12 Dec 2013 18:55:28 -0000 Message-ID: <03e101cef76b$ba04a130$2e0de390$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHfDs/oVJUszfG12P8Pr8wpVwKth5owuEUg Content-Language: en-gb Subject: [CCAMP] FW: [Editorial Errata Reported] RFC4803 (3831) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:55:40 -0000 BTW, I have passed this to Stewart for resolution, so any comments should be copied to him. Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 12 December 2013 15:22 > To: tnadeau@cisco.com; adrian@olddog.co.uk; stbryant@cisco.com; > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > Cc: adrian@olddog.co.uk; ccamp@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC4803 (3831) > > The following errata report has been submitted for RFC4803, > "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) > Management Information Base". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=3831 > > -------------------------------------- > Type: Editorial > Reported by: Adrian Farrel > > Section: 6 > > Original Text > ------------- > In mplsXCTable: > { > mplsXCIndex = 0x01, > mplsXCInSegmentIndex = 0x00000015, > mplsXCOutSegmentIndex = 0x00000012, > mplsXCLspId = 0x0102 -- unique ID > mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > mplsXCRowStatus = createAndGo(4) > } > > In mplsXCTable: > { > mplsXCIndex = 0x02, > mplsXCInSegmentIndex = 0x00000016, > mplsXCOutSegmentIndex = 0x00000013, > mplsXCLspId = 0x0102 -- unique ID > mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > mplsXCRowStatus = createAndGo(4) > } > > > Corrected Text > -------------- > In mplsXCTable: > { > mplsXCIndex = 0x01, > mplsXCInSegmentIndex = 0x00000015, > mplsXCOutSegmentIndex = 0x00000012, > mplsXCLspId = 0x0102 -- unique ID > mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > mplsXCRowStatus = createAndGo(4) > } > > In mplsXCTable: > { > mplsXCIndex = 0x01, > mplsXCInSegmentIndex = 0x00000016, > mplsXCOutSegmentIndex = 0x00000013, > mplsXCLspId = 0x0102 -- unique ID > mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > mplsXCRowStatus = createAndGo(4) > } > > > Notes > ----- > The entries in the mplsXCTable are indexed by {mplsXCIndex, > mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same LSP > should share a common value of mplsXCIndex because mplsTunnelXCPointer can > be set to point to the first entry and then all of the other entries can be found. > > The error in the example in Section 6 is that it shows a different value of > mplsXCIndex for the reverse direction cross-connects. It should be set to the > same value as is used for the forward direction cross-connect. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) > -------------------------------------- > Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching > Router (LSR) Management Information Base > Publication Date : February 2007 > Author(s) : T. Nadeau, Ed., A. Farrel, Ed. > Category : PROPOSED STANDARD > Source : Common Control and Measurement Plane > Area : Routing > Stream : IETF > Verifying Party : IESG From lberger@labn.net Fri Dec 13 08:25:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFAD1AE22D for ; Fri, 13 Dec 2013 08:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uULdWhpW7ZWL for ; Fri, 13 Dec 2013 08:25:30 -0800 (PST) Received: from alt-proxy33.mail.unifiedlayer.com (alt-proxy33.mail.unifiedlayer.com [70.40.209.146]) by ietfa.amsl.com (Postfix) with SMTP id 6A4661AE325 for ; Fri, 13 Dec 2013 08:25:30 -0800 (PST) Received: (qmail 26690 invoked by uid 0); 13 Dec 2013 16:24:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 13 Dec 2013 16:24:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=9VoOlyaVqGIlWf8Edxrww37ZAQTpknQt6/9neU8k3lU=; b=p3Hx0Y5a05C5426T6oWv8EDhpevHRuFtwgWpYX3+vgLJZtaM5gNvGJIoK2socHlyjbgAs3zQwixHDpTsuN5jqDf7cqyq86L5XSSIRYvySqNay1ahy2uSmQJbfTZBrchX; Received: from box313.bluehost.com ([69.89.31.113]:53134 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VrVXq-0004w6-A9; Fri, 13 Dec 2013 09:24:54 -0700 Message-ID: <52AB34D3.3040806@labn.net> Date: Fri, 13 Dec 2013 11:24:51 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'CCAMP WG' References: <20131212152138.4338E7FC397@rfc-editor.org> <03e101cef76b$ba04a130$2e0de390$@olddog.co.uk> In-Reply-To: <03e101cef76b$ba04a130$2e0de390$@olddog.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] FW: [Editorial Errata Reported] RFC4803 (3831) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:25:33 -0000 This correction looks fine to me, but I haven't implemented it myself. Implementors? Anyone care to comment? Thanks, Lou On 12/12/2013 01:55 PM, Adrian Farrel wrote: > BTW, I have passed this to Stewart for resolution, so any comments should be > copied to him. > > Adrian > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 12 December 2013 15:22 >> To: tnadeau@cisco.com; adrian@olddog.co.uk; stbryant@cisco.com; >> adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com >> Cc: adrian@olddog.co.uk; ccamp@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC4803 (3831) >> >> The following errata report has been submitted for RFC4803, >> "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router > (LSR) >> Management Information Base". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=3831 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Adrian Farrel >> >> Section: 6 >> >> Original Text >> ------------- >> In mplsXCTable: >> { >> mplsXCIndex = 0x01, >> mplsXCInSegmentIndex = 0x00000015, >> mplsXCOutSegmentIndex = 0x00000012, >> mplsXCLspId = 0x0102 -- unique ID >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label >> mplsXCRowStatus = createAndGo(4) >> } >> >> In mplsXCTable: >> { >> mplsXCIndex = 0x02, >> mplsXCInSegmentIndex = 0x00000016, >> mplsXCOutSegmentIndex = 0x00000013, >> mplsXCLspId = 0x0102 -- unique ID >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label >> mplsXCRowStatus = createAndGo(4) >> } >> >> >> Corrected Text >> -------------- >> In mplsXCTable: >> { >> mplsXCIndex = 0x01, >> mplsXCInSegmentIndex = 0x00000015, >> mplsXCOutSegmentIndex = 0x00000012, >> mplsXCLspId = 0x0102 -- unique ID >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label >> mplsXCRowStatus = createAndGo(4) >> } >> >> In mplsXCTable: >> { >> mplsXCIndex = 0x01, >> mplsXCInSegmentIndex = 0x00000016, >> mplsXCOutSegmentIndex = 0x00000013, >> mplsXCLspId = 0x0102 -- unique ID >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label >> mplsXCRowStatus = createAndGo(4) >> } >> >> >> Notes >> ----- >> The entries in the mplsXCTable are indexed by {mplsXCIndex, >> mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same LSP >> should share a common value of mplsXCIndex because mplsTunnelXCPointer can >> be set to point to the first entry and then all of the other entries can be > found. >> >> The error in the example in Section 6 is that it shows a different value of >> mplsXCIndex for the reverse direction cross-connects. It should be set to the >> same value as is used for the forward direction cross-connect. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) >> -------------------------------------- >> Title : Generalized Multiprotocol Label Switching (GMPLS) Label > Switching >> Router (LSR) Management Information Base >> Publication Date : February 2007 >> Author(s) : T. Nadeau, Ed., A. Farrel, Ed. >> Category : PROPOSED STANDARD >> Source : Common Control and Measurement Plane >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From wwwrun@rfc-editor.org Mon Dec 23 06:03:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11571AE097; Mon, 23 Dec 2013 06:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gb0P6DGvMF8; Mon, 23 Dec 2013 06:03:51 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3D1AE08D; Mon, 23 Dec 2013 06:03:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A8D897FC392; Mon, 23 Dec 2013 06:03:47 -0800 (PST) To: adrian@olddog.co.uk, tnadeau@cisco.com, adrian@olddog.co.uk From: RFC Errata System Message-Id: <20131223140347.A8D897FC392@rfc-editor.org> Date: Mon, 23 Dec 2013 06:03:47 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [CCAMP] [Errata Verified] RFC4803 (3831) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 14:03:52 -0000 The following errata report has been verified for RFC4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=3831 -------------------------------------- Status: Verified Type: Editorial Reported by: Adrian Farrel Date Reported: 2013-12-12 Verified by: Stewart Bryant (IESG) Section: 6 Original Text ------------- In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x00000012, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } In mplsXCTable: { mplsXCIndex = 0x02, mplsXCInSegmentIndex = 0x00000016, mplsXCOutSegmentIndex = 0x00000013, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } Corrected Text -------------- In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000015, mplsXCOutSegmentIndex = 0x00000012, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } In mplsXCTable: { mplsXCIndex = 0x01, mplsXCInSegmentIndex = 0x00000016, mplsXCOutSegmentIndex = 0x00000013, mplsXCLspId = 0x0102 -- unique ID mplsXCLabelStackIndex = 0x00, -- only a single outgoing label mplsXCRowStatus = createAndGo(4) } Notes ----- The entries in the mplsXCTable are indexed by {mplsXCIndex, mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same LSP should share a common value of mplsXCIndex because mplsTunnelXCPointer can be set to point to the first entry and then all of the other entries can be found. The error in the example in Section 6 is that it shows a different value of mplsXCIndex for the reverse direction cross-connects. It should be set to the same value as is used for the forward direction cross-connect. -------------------------------------- RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) -------------------------------------- Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Publication Date : February 2007 Author(s) : T. Nadeau, Ed., A. Farrel, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Mon Dec 23 15:12:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2441AE32A; Mon, 23 Dec 2013 15:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAmHC1C1zKzg; Mon, 23 Dec 2013 15:12:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA111AE069; Mon, 23 Dec 2013 15:12:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131223231241.10535.47988.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2013 15:12:41 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 23:12:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : OSPF-TE Extensions for General Network Element Co= nstraints Authors : Fatai Zhang Young Lee Jianrui Han Greg Bernstein Yunbin Xu Filename : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt Pages : 13 Date : 2013-12-23 Abstract: Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-general-constraints= -ospf-te/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-= te-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-general-constrain= ts-ospf-te-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leeyoung@huawei.com Mon Dec 23 15:32:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A91AE25A for ; Mon, 23 Dec 2013 15:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2IGKRLN9gBK for ; Mon, 23 Dec 2013 15:32:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3061AE235 for ; Mon, 23 Dec 2013 15:32:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBS77360; Mon, 23 Dec 2013 23:32:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 23:31:57 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Dec 2013 23:32:45 +0000 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 15:32:40 -0800 From: Leeyoung To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt Thread-Index: AQHPADSTU91/cirvAUKsTgLHXf/W75pibXDQ Date: Mon, 23 Dec 2013 23:32:40 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA5098@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 23:32:54 -0000 Hi Lou, To avoid the expiration of the draft, we have updated this draft. In doing = so, I believe we resolved most of the pending issues you and Acee raised du= ring the WG LC process.=20 Regards, Young -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, December 23, 2013 5:13 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-osp= f-te-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : OSPF-TE Extensions for General Network Element Co= nstraints Authors : Fatai Zhang Young Lee Jianrui Han Greg Bernstein Yunbin Xu Filename : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.tx= t Pages : 13 Date : 2013-12-23 Abstract: Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-general-constraints= -ospf-te/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-= te-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-general-constrain= ts-ospf-te-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Mon Dec 23 16:35:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE41AE0CF for ; Mon, 23 Dec 2013 16:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGZen59vNQL3 for ; Mon, 23 Dec 2013 16:35:04 -0800 (PST) Received: from alt-proxy6.mail.unifiedlayer.com (alt-proxy6.mail.unifiedlayer.com [66.147.245.65]) by ietfa.amsl.com (Postfix) with SMTP id 808DA1AE33D for ; Mon, 23 Dec 2013 16:35:04 -0800 (PST) Received: (qmail 5818 invoked by uid 0); 24 Dec 2013 00:34:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.mail.unifiedlayer.com with SMTP; 24 Dec 2013 00:34:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=goC9to0P18ulbi6vLjrk3DYiwayDorHacPfyryk8mj0=; b=e/p5TEowV0knZvDG9UcrcpSKwakLM0DTPAT6x2Q8FcCrucJAL/TXoKBm32gqW1R30SbU7I87WkIUiawQ5cTaWIHBt66majVIfWSWSDcBBLBAA29nr5139guw/n3AsELd; Received: from box313.bluehost.com ([69.89.31.113]:51887 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VvFxa-0007NX-6M; Mon, 23 Dec 2013 17:34:59 -0700 From: Lou Berger To: Leeyoung Date: Mon, 23 Dec 2013 19:34:56 -0500 Message-ID: <143220693c8.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA5098@dfweml510-mbx.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA5098@dfweml510-mbx.china.huawei.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.5.10 (build: 2100360) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 00:35:07 -0000 Thank you Young. I'm hoping we hear about the pending IPR disclosure sometime soon... Lou On December 23, 2013 6:32:40 PM Leeyoung wrote: > Hi Lou, > > To avoid the expiration of the draft, we have updated this draft. In doing > so, I believe we resolved most of the pending issues you and Acee raised > during the WG LC process. > Regards, > Young > > > > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, December 23, 2013 5:13 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: > draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > Title : OSPF-TE Extensions for General Network Element Constraints > Authors : Fatai Zhang > Young Lee > Jianrui Han > Greg Bernstein > Yunbin Xu > Filename : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06.txt > Pages : 13 > Date : 2013-12-23 > > Abstract: > Generalized Multiprotocol Label Switching (GMPLS) can be used to > control a wide variety of technologies including packet switching > (e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport > Network (OTN)), wavelength (lambdas), and spatial switching (e.g., > incoming port or fiber to outgoing port or fiber). In some of these > technologies, network elements and links may impose additional > routing constraints such as asymmetric switch connectivity, non- > local label assignment, and label range limitations on links. This > document describes Open Shortest Path First (OSPF) routing protocol > extensions to support these kinds of constraints under the control > of GMPLS. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-general-constraints-ospf-te/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-general-constraints-ospf-te-06 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From adrian@olddog.co.uk Tue Dec 24 10:05:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39561AE02F for ; Tue, 24 Dec 2013 10:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqnQwC0U2bBN for ; Tue, 24 Dec 2013 10:05:41 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E75B51AE025 for ; Tue, 24 Dec 2013 10:05:40 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBOI5Z0I022455; Tue, 24 Dec 2013 18:05:35 GMT Received: from 950129200 (AGrenoble-651-1-569-5.w90-52.abo.wanadoo.fr [90.52.233.5]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBOI3WRa021975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Dec 2013 18:05:30 GMT From: "Adrian Farrel" To: "'Lou Berger'" , "'CCAMP WG'" References: <20131212152138.4338E7FC397@rfc-editor.org> <03e101cef76b$ba04a130$2e0de390$@olddog.co.uk> <52AB34D3.3040806@labn.net> In-Reply-To: <52AB34D3.3040806@labn.net> Date: Tue, 24 Dec 2013 18:03:40 -0000 Message-ID: <021901cf00d2$c0d991d0$428cb570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHfDs/oVJUszfG12P8Pr8wpVwKthwI4C0rXAe9B1vKaIMI8QA== Content-Language: en-gb Subject: Re: [CCAMP] FW: [Editorial Errata Reported] RFC4803 (3831) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 18:05:43 -0000 Lou, Long ago and far away I was close to an implementation that acted according to the specification in 4803 and so would have yielded an example as fixed by my proposed Errata Report. Longer ago and further away I implemented something very similar, but it was pre-standard by some distance. Cheers, Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 13 December 2013 16:25 > To: adrian@olddog.co.uk; 'CCAMP WG' > Subject: Re: [CCAMP] FW: [Editorial Errata Reported] RFC4803 (3831) > > This correction looks fine to me, but I haven't implemented it myself. > > Implementors? Anyone care to comment? > > Thanks, > Lou > > On 12/12/2013 01:55 PM, Adrian Farrel wrote: > > BTW, I have passed this to Stewart for resolution, so any comments should be > > copied to him. > > > > Adrian > > > >> -----Original Message----- > >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >> Sent: 12 December 2013 15:22 > >> To: tnadeau@cisco.com; adrian@olddog.co.uk; stbryant@cisco.com; > >> adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > >> Cc: adrian@olddog.co.uk; ccamp@ietf.org; rfc-editor@rfc-editor.org > >> Subject: [Editorial Errata Reported] RFC4803 (3831) > >> > >> The following errata report has been submitted for RFC4803, > >> "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router > > (LSR) > >> Management Information Base". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=3831 > >> > >> -------------------------------------- > >> Type: Editorial > >> Reported by: Adrian Farrel > >> > >> Section: 6 > >> > >> Original Text > >> ------------- > >> In mplsXCTable: > >> { > >> mplsXCIndex = 0x01, > >> mplsXCInSegmentIndex = 0x00000015, > >> mplsXCOutSegmentIndex = 0x00000012, > >> mplsXCLspId = 0x0102 -- unique ID > >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > >> mplsXCRowStatus = createAndGo(4) > >> } > >> > >> In mplsXCTable: > >> { > >> mplsXCIndex = 0x02, > >> mplsXCInSegmentIndex = 0x00000016, > >> mplsXCOutSegmentIndex = 0x00000013, > >> mplsXCLspId = 0x0102 -- unique ID > >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > >> mplsXCRowStatus = createAndGo(4) > >> } > >> > >> > >> Corrected Text > >> -------------- > >> In mplsXCTable: > >> { > >> mplsXCIndex = 0x01, > >> mplsXCInSegmentIndex = 0x00000015, > >> mplsXCOutSegmentIndex = 0x00000012, > >> mplsXCLspId = 0x0102 -- unique ID > >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > >> mplsXCRowStatus = createAndGo(4) > >> } > >> > >> In mplsXCTable: > >> { > >> mplsXCIndex = 0x01, > >> mplsXCInSegmentIndex = 0x00000016, > >> mplsXCOutSegmentIndex = 0x00000013, > >> mplsXCLspId = 0x0102 -- unique ID > >> mplsXCLabelStackIndex = 0x00, -- only a single outgoing label > >> mplsXCRowStatus = createAndGo(4) > >> } > >> > >> > >> Notes > >> ----- > >> The entries in the mplsXCTable are indexed by {mplsXCIndex, > >> mplsXCInSegmentIndex, mplsOutSegmentIndex}. All XC entries for the same > LSP > >> should share a common value of mplsXCIndex because mplsTunnelXCPointer > can > >> be set to point to the first entry and then all of the other entries can be > > found. > >> > >> The error in the example in Section 6 is that it shows a different value of > >> mplsXCIndex for the reverse direction cross-connects. It should be set to the > >> same value as is used for the forward direction cross-connect. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) > >> -------------------------------------- > >> Title : Generalized Multiprotocol Label Switching (GMPLS) Label > > Switching > >> Router (LSR) Management Information Base > >> Publication Date : February 2007 > >> Author(s) : T. Nadeau, Ed., A. Farrel, Ed. > >> Category : PROPOSED STANDARD > >> Source : Common Control and Measurement Plane > >> Area : Routing > >> Stream : IETF > >> Verifying Party : IESG > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > From david.black@emc.com Sun Dec 29 18:47:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697C61AE38A; Sun, 29 Dec 2013 18:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayRjMxZa9NAR; Sun, 29 Dec 2013 18:47:49 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9E1AE389; Sun, 29 Dec 2013 18:47:49 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBU2k63t019756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Dec 2013 21:46:06 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rBU2k63t019756 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1388371567; bh=wToxVx8qTcL6vsqjC/ga06Wojto=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qfGlCORIGwB6qlaDmI46tgEGZCUNWkzCCOrfdzlGUWFktPe2txMdTT2DAr2ctxIxI Heew31Mw8LdTYYH/MzgCFPRc4kNymhKfm+uVJb9zDfeLL5K0JefgycQ189ygWIuFhc xoeVm2VcbTiMY+XLYMZ6IiK/QnTNs0W/LyMSfQQw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rBU2k63t019756 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Sun, 29 Dec 2013 18:45:58 -0800 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBU2jv32002201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Dec 2013 21:45:57 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Sun, 29 Dec 2013 21:45:56 -0500 From: "Black, David" To: "General Area Review Team (gen-art@ietf.org)" , "attila.takacs@ericsson.com" , "donald.fedyk@alcatel-lucent.com" , "hejia@huawei.com" Date: Sun, 29 Dec 2013 21:45:55 -0500 Thread-Topic: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 Thread-Index: Ac8FCULxJlQ5F8h9QISxvng85TrjLQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public, Resumes Cc: "Black, David" , "ccamp@ietf.org" , "ietf@ietf.org" Subject: [CCAMP] Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 02:47:51 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-oam-configuration-fwk-11 Reviewer: David L. Black Review Date: December 29, 2013 IETF LC End Date: January 5, 2014 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes the GMPLS framework for signaling OAM configuration, and specifies additional RSVP elements to support that signaling. Knowledg= e of RSVP, and specifically RSVP-TE is assumed; beyond that, the draft is complete, although it is very detailed - see editorial comment below on Section 3. Nits/editorial comments: Sections 3.1-3.3 dive into the details very quickly. They would be easier = to understand if there was an overview paragraph near the start of Section 3 t= hat describes the roles of the two ADMIN_STATUS flags and the two LSP Attribute= s flags in OAM configuration (establishment, change/adjustment, deletion) bef= ore the current text that contains the details of RSVP message processing. There are a number of instances of "(IANA to assign)" in section 4 that the RFC Editor will need to remove - an RFC Editor note to that effect should be inserted at the start of Section 4. Section 4.5 is necessarily incomplete on P2MP considerations, because (as it says) "P2MP OAM mechanisms are very specific to the data plane technolog= y". It would be helpful if section 4.5 contained language indicating what a specific data plane specification should include to completely specify P2MP OAM configuration for that data plane. idnits 2.13.01 didn't find anything that needs attention. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Sun Dec 29 18:51:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7443B1AE392; Sun, 29 Dec 2013 18:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sAkMi29VB2; Sun, 29 Dec 2013 18:50:59 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 046B31AE390; Sun, 29 Dec 2013 18:50:58 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBU2ofnw027592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Dec 2013 21:50:41 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rBU2ofnw027592 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1388371841; bh=uethKt9UXdL3YpMxSTY2gO1Nb5M=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oQDf/sUQsjri8E4IYebgZdm0PivZe9E/1xlcHjnHdHSivWv6Zr1ienhEMJCt3y63Z MqaPOXS8SF2D0/iAwjKQoraFGrbalDCC2KAEegdaiHQExoCp7Jmqo2sGkhyKLczjlx iAuhojlx+tFnuTV2QPyeWac3CJrx5SVkG4VyT1WA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com rBU2ofnw027592 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sun, 29 Dec 2013 21:50:36 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBU2oaJU014314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Dec 2013 21:50:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Sun, 29 Dec 2013 21:50:35 -0500 From: "Black, David" To: "General Area Review Team (gen-art@ietf.org)" , "attila.takacs@ericsson.com" , "donald.fedyk@alcatel-lucent.com" , "hejia@huawei.com" Date: Sun, 29 Dec 2013 21:50:34 -0500 Thread-Topic: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 Thread-Index: Ac8FCULxJlQ5F8h9QISxvng85TrjLQAAIYDA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D8@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, Resumes Cc: "ccamp@ietf.org" , "ietf@ietf.org" Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 02:51:01 -0000 One additional nit - Don Fedyk's email address listed in the draft does not= work. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Sunday, December 29, 2013 9:46 PM > To: General Area Review Team (gen-art@ietf.org); attila.takacs@ericsson.c= om; > donald.fedyk@alcatel-lucent.com; hejia@huawei.com > Cc: Black, David; adrian@olddog.co.uk; ccamp@ietf.org; ietf@ietf.org > Subject: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-ccamp-oam-configuration-fwk-11 > Reviewer: David L. Black > Review Date: December 29, 2013 > IETF LC End Date: January 5, 2014 >=20 > Summary: This draft is basically ready for publication, but has nits that > should be fixed before publication. >=20 > This draft describes the GMPLS framework for signaling OAM configuration, > and specifies additional RSVP elements to support that signaling. Knowle= dge > of RSVP, and specifically RSVP-TE is assumed; beyond that, the draft is > complete, although it is very detailed - see editorial comment below on > Section 3. >=20 > Nits/editorial comments: >=20 > Sections 3.1-3.3 dive into the details very quickly. They would be easie= r to > understand if there was an overview paragraph near the start of Section 3= that > describes the roles of the two ADMIN_STATUS flags and the two LSP Attribu= tes > flags in OAM configuration (establishment, change/adjustment, deletion) b= efore > the current text that contains the details of RSVP message processing. >=20 > There are a number of instances of "(IANA to assign)" in section 4 that t= he > RFC Editor will need to remove - an RFC Editor note to that effect should > be inserted at the start of Section 4. >=20 > Section 4.5 is necessarily incomplete on P2MP considerations, because (as > it says) "P2MP OAM mechanisms are very specific to the data plane technol= ogy". > It would be helpful if section 4.5 contained language indicating what a > specific data plane specification should include to completely specify > P2MP OAM configuration for that data plane. >=20 > idnits 2.13.01 didn't find anything that needs attention. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From adrian@olddog.co.uk Mon Dec 30 02:00:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12CB1AE297; Mon, 30 Dec 2013 02:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yESVwlWKjX3k; Mon, 30 Dec 2013 02:00:19 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8511ADD02; Mon, 30 Dec 2013 02:00:19 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBU9xxVA010319; Mon, 30 Dec 2013 09:59:59 GMT Received: from 950129200 (15.21.90.92.rev.sfr.net [92.90.21.15]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBU9xttQ010294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Dec 2013 09:59:57 GMT From: "Adrian Farrel" To: "'Black, David'" , "'General Area Review Team'" , , , References: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ECD43D7@MX15A.corp.emc.com> Date: Mon, 30 Dec 2013 10:00:02 -0000 Message-ID: <073b01cf0545$ea551300$beff3900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLIxQeO/C2R4ojIkjKX9U68TfcVfph5AZyA Content-Language: en-gb X-TM-AS-MML: No Cc: ccamp@ietf.org, ietf@ietf.org Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 10:00:22 -0000 Thanks David, Stored for future updates. Adrian > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: 30 December 2013 02:46 > To: General Area Review Team (gen-art@ietf.org); = attila.takacs@ericsson.com; > donald.fedyk@alcatel-lucent.com; hejia@huawei.com > Cc: Black, David; adrian@olddog.co.uk; ccamp@ietf.org; ietf@ietf.org > Subject: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-ccamp-oam-configuration-fwk-11 > Reviewer: David L. Black > Review Date: December 29, 2013 > IETF LC End Date: January 5, 2014 >=20 > Summary: This draft is basically ready for publication, but has nits = that > should be fixed before publication. >=20 > This draft describes the GMPLS framework for signaling OAM = configuration, > and specifies additional RSVP elements to support that signaling. = Knowledge > of RSVP, and specifically RSVP-TE is assumed; beyond that, the draft = is > complete, although it is very detailed - see editorial comment below = on > Section 3. >=20 > Nits/editorial comments: >=20 > Sections 3.1-3.3 dive into the details very quickly. They would be = easier to > understand if there was an overview paragraph near the start of = Section 3 that > describes the roles of the two ADMIN_STATUS flags and the two LSP = Attributes > flags in OAM configuration (establishment, change/adjustment, = deletion) before > the current text that contains the details of RSVP message processing. >=20 > There are a number of instances of "(IANA to assign)" in section 4 = that the > RFC Editor will need to remove - an RFC Editor note to that effect = should > be inserted at the start of Section 4. >=20 > Section 4.5 is necessarily incomplete on P2MP considerations, because = (as > it says) "P2MP OAM mechanisms are very specific to the data plane = technology". > It would be helpful if section 4.5 contained language indicating what = a > specific data plane specification should include to completely specify > P2MP OAM configuration for that data plane. >=20 > idnits 2.13.01 didn't find anything that needs attention. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ----------------------------------------------------