From acee.lindem@ericsson.com Sat Nov 9 12:59:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F6121E80B7; Sat, 9 Nov 2013 12:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_05=-1.11, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy7Uw4TBoJp8; Sat, 9 Nov 2013 12:59:24 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7821F9FCA; Sat, 9 Nov 2013 12:59:18 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-0f-527ea2230df2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 93.BD.23183.322AE725; Sat, 9 Nov 2013 21:59:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sat, 9 Nov 2013 15:59:10 -0500 From: Acee Lindem To: Daniele Ceccarelli Thread-Topic: RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Thread-Index: AQHOxJCn0+iFqto7ekGiQXMkyXw9jZn0UizAgAPB1YCAByQB8IALb5KAgAE+r/CAEXtdgA== Date: Sat, 9 Nov 2013 20:59:09 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030D94A5@eusaamb101.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4817FBE0@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030D94A5eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonSldlUV2Qwa21fBZP5txgsfjb8JrF 4vmcmSwWC9Y8ZXdg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mm7OmMJecHguZ8XRj4/Z GxhPvmXvYuTkkBAwkfi/bwIrhC0mceHeerYuRi4OIYEjjBLXmnZDOcsYJdqX7mMBqWIT0JF4 /ugfM4gtImAh0XXsMStIEbPAY0aJTxueM4IkhAW6GCUW7WUHSYgIdDNKbL68F6ojTGLxo3Ym EJtFQEVizaN/YFN5BXwlZr/vA4tzCvhIdPzewAZiMwLd9P3UGrA4s4C4xK0n85kgbhWQWLLn PDOELSrx8vE/sB9EBfQkumcth/pHWWLJk/0sEL35Etu/3GGD2CUocXLmE5YJjKKzkIydhaRs FpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0l5nz8x4KsZgEjxypGjtLi1LLcdCODTYzA WDwmwaa7g3HPS8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYExRWsl3 4zKf3wGn9RkXUjnXLWe2rtzld2LSTU2dBRGVB5tVv5wWi3j671Qs75sLek+nCXVkl/dp1rIt PRjmtnV1QeJER/4t0TZvLofscY4WKNh3LWzm0Qlh9f5dGqrdpfXTFS02zux65PKY48DK2R1r Hu2xnlNtIum0skTA4vBOJ9Ew0yUz5ymxFGckGmoxFxUnAgBxWtFmkwIAAA== Cc: "rtg-dir@ietf.org" , CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:59:30 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030D94A5eusaamb101erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Daniele, The changes look good to me and I'm happy with the draft. You are correct t= hat RFC 6837 is the wrong reference. Sorry for the confusion. I meant that = RFC 6827 is a good model for a "Security Considerations" sections in a GMP= LS specific draft. Of course, you'd remove the text specific to ASON and re= place it with OTN. 9. Security Considerations This document specifies the contents and processing of OSPFv2 TE LSAs [RFC3630] and [RFC4202]. The TE LSA extensions defined in this document are not used for Shortest Path First (SPF) computation and have no direct effect on IP routing. Additionally, ASON routing domains are delimited by the usual administrative domain boundaries. Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] [RFC5709]) can be used to provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 packets by making use of the Hashed Message Authentication Code (HMAC) algorithm in conjunction with the SHA family of cryptographic hash functions. RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised. This is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached. The "Analysis of OSPF Security According to KARP Design Guide" [OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3 security relative to the requirements specified in [RFC6518]. Thanks, Acee From: Daniele Ceccarelli > Date: Tuesday, October 29, 2013 8:35 AM To: Ericsson > Cc: "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" >, = "rtg-dir@ietf.org" >, CCAMP >, "rtg-ads@tools= .ietf.org" > Subject: RE: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Acee, Please find the version solving (hopefully) the last issues attached. It wi= ll be updated on Nov 4th. Also, please find my comments in line. Many thanks Daniele From: Acee Lindem Sent: luned=EC 28 ottobre 2013 17:01 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, I looked at the update and it is greatly improved. I'd still recommend the = following issues be addressed. 1. In section 4, you state the malformed LSA, TLV, or Sub-TLV is igno= red. Since this specification describes sub-TLVs, does that imply that only= the sub-TLVs are ignored when malformed? This is how I'd interpret it. [[DC]] correct. Fixed as you suggested below in 369,373c367,370, just chang= ed a bit to reflect the fact that only sub-TLVs are defined in this documen= t: When a received LSA includes a sub-TLV not formatted accordingly to the= precise specifications in this document, the problem SHOULD be logged and the wrongly formatted sub-TLV MUST NOT be used for path computation. 2. In examples where you used "X" to denote that the field is not appl= icable, you should state that. Or at least state it somewhere. [[DC]] OK. T, S and TS granularity fields are not relevant to this example (filled wit= h Xs) Also some edits on the new text: 130c130,131 < provided in [OTN-INFO]. --- > provided in [OTN-INFO]. The reader is assumed to be familiar with > both of these documents. 136,138d136 < The reader is supposed to be familiar with OTN framework [OTN-FWK] < and GMPLS evaluation against OTN [OTN-INFO]. < 320c318 < is shown in the table below (please note that there are 1000 bits in --- > are shown in the table below (please note that there are 1000 bits in 369,373c367,370 < In case a recived LSA is not formatted accordingly to the < requirements indicated in this document, the problem SHOULD be logged < and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT be used for < the path computation until a newer version correctly formatted is < received. --- > When a received LSA is not formatted accordingly to the precise > specifications in this document, the problem SHOULD be logged > and the wrongly formatted LSA, TLV, or Sub-TLV MUST NOT be used for > path computation. 1561c1558 < flooding frequency. Moreover the design of the encoding has been --- > flooding frequency. Moreover, the design of the encoding has been 1573c1570 < priorities is advertised --- > priorities are advertised. 1575,1578c1572,1575 < - With respect of fixed containers, only the number of available < containers is advertised instead of available bandwidth so to use < only 16 bits per container instead of 32 (as per former GMPLS < encoding --- > - With respect to fixed containers, only the number of available > containers is advertised instead of available bandwidth so that > only 16 bits per container are used instead of 32 (as per the > former GMPLS encoding). 1580c1577 < In order to further reduce the amount of data advertised it is --- > In order to further reduce the amount of data advertised, it is Thanks, Acee P.S. I still think it would be better not to reference RFC 2154 in the "Sec= urity Considerations". RFC 6837 has a much better example for OSPF TE than = RFC 3630. [[DC]] Reference to RFC2154 removed but I think RFC6837 is not the one you= wanted to point to (A Not-so-novel Endpoint ID (EID) to Routing Locator (R= LOC) Database). On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wrote: Hi Acee, Since today it is the deadline for draft submission we uploaded a version w= ith the changes agreed up to now and the ones proposed in line below. Furth= er modifications, if needed, will be deferred to a new version on Monday No= v 4th. Thanks once again for your review Daniele + Co-authors. From: Acee Lindem Sent: mercoled=EC 16 ottobre 2013 22:20 To: Daniele Ceccarelli Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org Subject: Re: RtgDir Review: "Traffic Engineering Extensions to OSPF for Gen= eralized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hi Daniele, See inline. On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrote: Hi Acee, Thanks for the careful review and please find comments/replies in line. BR Daniele (&co-authors) From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: mercoled=EC 9 ottobre 2013 03:41 To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org Cc: rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.or= g Subject: RtgDir Review: "Traffic Engineering Extensions to OSPF for General= ized MPLS (GMPLS) Control of Evolving G.709 OTN Networks" Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-ospf-g709v3-09.txt Reviewer: Acee Lindem Review Date: October 15th, 2013 IETF LC End Date: October 16, 2013 Intended Status: Proposed Standard Summary: The document is missing some key sections and requires some clarif= ication prior to publication. Comments: Major Issues: The document lacks several critical pieces of information. 1. There is no discussion of OSPF scaling or flooding freq= uency. Even if it not expected that G709 GMPLS signaling will not present any problems, this n= eeds to be stated and justified. Refer to section 8 in RFC 6827 for an example of such a discus= sion. [[Authors]] How about adding a section saying: OSPFv2 scalability considerations and requirements are in line with section= 8 of [RFC6827]. In addition please note that OTN extensions in this docume= nt have been designed taking into consideration optimization criteria ident= ified in [OTN-INFO] It isn't obvious to me that these two extensions are comparable. I think a = separate section pertaining to the OTN extensions would make more sense. [[DC]] The following section has been added: This document does not introduce OSPF scalability issues with respect to existing GMPLS encoding and does not require any modification to flooding frequency. Moreover the design of the encoding has been carried out taking into account bandwidth optimization, and in particular: - Only unreserved and MAX LSP Bandwidth related to supported priorities is advertised - With respect of fixed containers, only the number of available containers is advertised instead of available bandwidth so to use only 16 bits per container instead of 32 (as per former GMPLS encoding In order to further reduce the amount of data advertised it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6. 2. The document includes lots of normative text indicating= precisely how sub-TLVs MUST be formatted. However, there is no indication of what th= e action to be taken if the TLVs do not follow the strict conventions. [[Authors]] Good comment. Looking at previous OSPF and OSPF-TE drafts we di= dn=92t find any text on handling of bad TLV formatting. Any suggestion on h= ow to deal with that is more than welcome. In the past, I've stated that the problem should be logged and the LSA, TLV= , or Sub-TLV MUST NOT be used for TE/GMPLS path computation. It all depends= on what makes sense for the encoding violation and at what level it should= be resolved. One generic solution would be to NOT use any LSAs with encodi= ng violations for GMPLS path computation. [[DC]] This piece of text has been added at the end of section 4: In case a recived LSA is not formatted accordingly to the requir= ements indicated in this document, the problem SHOULD be logged and the wrongly form= atted LSA, TLV or Sub-TLV MUST NOT be used for the path computation until a newer version correc= tly formatted is received. 3. The document jumps down into details of G.709 technolog= y without adequate explanation (particularly in the examples). Either t= hese details need to be removed or a statement of prerequisite knowledge is required. [[Authors]] The reader is supposed to have read [OTN-FWK] and [OTN-INFO]. W= e can add a sentence at the end of the abstract or intro. This is the minimum. Minor Issues: The document had a large number of editorial errors. 1. The bit numbering on all the figures was off by 1 colum= n. If you look at RFC 4203, this will be obvious. [[Author]] Correct. Fixed. 2. The table on page 7 is incomprehensible with the given = columns and headings. Spaces rather than commas in numbers are annoying. [[Author]] Spaces substituted with commas. As per comment above having read= [OTN-FWK] and [OTN-INFO] is a prerequisite. Does it add anything to this document if one needs to look at OTN-FWK and O= TN-INFO anyway? It is much less relevant than, say, a discussion of adverti= sement and scaling ;^) For example, what does 239/238 mean? Is this 239 or 238 separate tributary = slots - why is it variable? What does GFP-F mean - it is not defined here. [[DC]] Table 7 is needed to fill the common header of the ISCD. E.g. when i= ndicating ODU4, the related max lsp bandwidth in the common header of the I= SCD needs to be filled with 0x504331E3. The first and third columns of the table are needed for that, while the sec= ond one explains how the value is Byte/sec is retrieved (i.e. the nominal b= it rate of each ODU). The =93239/238=94 does not mean 239 OR 238 but means = 239 divided by 238. The meaning of GFP-F is explained in the fwk document (defined in G.7041) a= nd stands for Generic Framing Procedure. In addition to the various ODUs th= ere are three more ODU types that need to be advertised, namely: i) ODUflex= for CBR client signals, ii) ODUflex for GFP-F mapped client signal and iii= ) ODU flex resizable. 3. The distinction between TLVs and sub-TLVs is not consis= tent throughout the document. Again, refer to RFC 6827 for an example of consistent= referral. [[Authors]] Good catch. We=92re defining only sub-tlvs. Fixed. 4. Figures 8 and 9 have the T and S fields offset from the= bit numbering. Also, it took some time to realize that T1 meant a value of 1. [[Authors]] T and S were left intentionally to make the reading easier but = maybe it=92s not the case. Only 0 and 1 are there now. 5. Figures 11-15 are very inconsistent in that these are examples yet the v= alues for T, S, and sometime TSG are not specified. Rather, the example in= cludes the letters. [[Authors]] The focus of those examples is not T,S and TSG but e.g. ODUflex= advertisement, single stage muxing etc. For each example there is a discla= imer saying: =93T, S and TS granularity fields are not relevant to this exa= mple=94. Then wouldn't X's be more relevant than missing discrete values and field l= abels in the same figure? [[DC]] OK. X=92s used. 6. Security section - RFC 2154 is an experimental RFC that= has heretofore never been commercially implemented or deployed. It is time to q= uit referencing it in draft "Security Considerations". [[Authors]] How about the following? OLD [RFC3630] suggests mechanisms such = as [RFC2154] to protect the transmission of this information=85 NEW [RFC3630] suggests mechanisms to pr= otect the transmission of this information=85 It would be great with me. There are plenty of reviewers who will nit pick = the security section... Nits: 1. The proper punctuation is "i.e., " and "e.g. ,". [[Authors]] OK Also, sentences should not start with either. See http://www.rfc-editor.org/rfc-style-guide/rfc-sty= le 2. Page 7, "Switching Capability-Specific Information (SCSI)? [[Authors]] OK 3. Suggest formatting the document so that the figures are= on separate pages rather than split across pages. [[Authors]] I don=92t know how to do that with the .xml file. Maybe this is= a comment we can leave for the RFC editor? Ok. I have been able to do this with [[DC]] It works fine with all figures except fig 14. It=92s longer than a p= age. 3. Replace all occurrences of "non " with "non-" and do not end lines= with "non ". [[Authors]] OK 4. I thought the examples included many run-on sentences t= hat were hard to parse and lacked needed punctuation. I tried to edit but I'm not even = sure if I retained the same meaning. You can get a flavor for what I mean by the diffs below. [[Authors]] OK to all. All modifications you suggest have been implemented. Thanks - I'll look for the update. Thanks, Acee Thanks, Acee 132,133c132,133 < Routing information for Optical Channel Layer (OCh) (i.e. wavelength) < is out of the scope of this document. Please refer to [RFC6163] and --- > Routing information for Optical Channel Layer (OCh) (i.e., wavelength) > is beyond the scope of this document. Please refer to [RFC6163] and 157c157 < As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so --- > As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended 159c159 < related to each different ODUj and ODUk/OTUk (Optical Transport Unit) --- > of each different ODUj and ODUk/OTUk (Optical Transport Unit) 176c176 < In the following we will use ODUj to indicate a service type that is --- > In the following, we will use ODUj to indicate a service type that is 179c179 < the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and --- > the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and 184c184 < multiplexing levels. In the following the term "multiplexing tree" --- > multiplexing levels. In the following, the term "multiplexing tree" 191c191 < If for example a multiplexing hierarchy like the following one is --- > For example, If a multiplexing hierarchy like the following one is 251c251 < one hop case multiple hop TE-links advertise ODU switching capacity. --- > one hop case, multiple hop TE-links advertise ODU switching capacity. 296,297c296,297 < Both for fixed and flexible ODUs the same switching type and encoding < values MUST be used. When Switching Capability and Encoding fields --- > The same switching type and encoding values must be used for both fixe= d > and flexible ODUs. When Switching Capability and Encoding fields 303,304c303,304 < The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= =3D < MAX LSP Bandwidth <=3D ODUk/OTUk and intermediate values are those on --- > The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <= =3D > MAX LSP Bandwidth <=3D ODUk/OTUk, and intermediate values are those on 306,307c306,307 < E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP < Bandwidth for some priorities, ODU3 for others, ODU2 for some others --- > For example, in the OTU4 link it could be possible to have ODU4 as MAX= LSP > Bandwidth for some priorities, ODU3 for others, ODU2 for some others, 397,398c397,398 < Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non < resizable. Each MUST always be advertised in separate Type 2 TLVs as --- > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non-resizable. Each MUST always be advertised in separate Type 2 TLVs= as 400c400 < both GFP-F resizable and non resizable (i.e. 21 and 22) are --- > both GFP-F resizable and non-resizable (i.e. 21 and 22) are 535c535 < (i.e. a non OTN client). --- > (i.e., a non-OTN client). 540c540 < - Priority (8 bits): a bitmap used to indicate which priorities --- > - Priority (8 bits): A bitmap used to indicate which priorities 542,543c542,543 < leftmost bit representing priority level 0 (i.e. the highest) and < the rightmost bit representing priority level 7 (i.e. the lowest). --- > leftmost bit representing priority level 0 (i.e., the highest) and > the rightmost bit representing priority level 7 (i.e., the lowest). 666c666 < Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0 --- > Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 676,678c676,678 < At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX < LSP Bandwidth is still equal to the ODU4 bandwidth, while for < priorities from 2 to 7 (excluding the non supported ones) the MAX LSP --- > At time T1, an ODU3 at priority 2 is set-up, so for priority 0 the > MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for > priorities from 2 to 7 (excluding the non-supported ones) the MAX LSP 680c680 < next supported ODUj in the hierarchy is ODU3.The advertisement is --- > next supported ODUj in the hierarchy is ODU3. The advertisement is 710c710 < Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1 --- > Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 712,714c712,714 < At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no < longer available since T1 as it was kept by the ODU3 LSP, while the < second is no more available and just 3 ODU2 are left in it. ODU2 is --- > At time T2, an ODU2 at priority 4 is set-up. The first ODU3 is no > longer available since T1, as it was kept by the ODU3 LSP, while the > second is no more available and just 3 ODU2s are left in it. ODU2 is 758c758 < Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2 --- > Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 762c762 < In this example an interface with Tributary Slot Type 1.25Gbps and --- > In this example, an interface with Tributary Slot Type 1.25Gbps and 766c766 < switched or terminated, the ODU2 can only be terminated and the ODU1 --- > switched or terminated, the ODU2 can only be terminated, and the ODU1 768c768 < advertised to support ODU0 the value of is "ignored" (TS --- > advertised to support ODU0, the value of is "ignored" (TS 770c770 < interface a single ISCD is used and its format is as follows: --- > interface, a single ISCD is used and its format is as follows: 819c819 < In this example two interfaces with homogeneous hierarchies but --- > In this example, two interfaces with homogeneous hierarchies but 822,824c822,824 < one a G.709-2012 interface with fallback procedure disabled (TS < granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy and < priorities 0 and 3. T and S bits values are not relevant to this --- > one supports G.709-2012 interface with fallback procedure disabled > (TS granularity=3D3). Both of them support ODU1->ODU2->ODU3 hierarchy > and priorities 0 and 3. T and S bits values are not relevant to this 826,827c826,827 < interfaces two different ISCDs are used and the format of their SCSIs < is as follows: --- > interfaces, two different ISCDs are used and the format of their > SCSIs is as follows: 903,908c903,908 < with different exported TS granularity MUST be considered as non < homogenous hierarchies is the case in which an H-LPS and the client < LSP are terminated on the same egress node. What can happen is that < a loose Explicit Route Object (ERO) is used at the hop where the < signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate < hop of the LSP). --- > with different exported TS granularity MUST be considered as > non-homogenous hierarchies. This is the case in which an H-LPS and > the client LSP are terminated on the same egress node. What can > happen is that a loose Explicit Route Object (ERO) is used at the > hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) > (penultimate hop of the LSP). 912,915c912,915 < if2. In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a < TS=3D2.5Gbps and the service LSP being signaled needs a 1.25Gbps < tributary slot, only the H-LSP on if1 can be used to reach node E. < For further details please see section 4.1 of the [OTN-INFO]. --- > if2. In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a > TS=3D2.5Gbps, the service LSP being signaled needs a 1.25Gbps > tributary slot, and only the H-LSP on if1 can be used to reach node E. > For further details, please see section 4.1 of the [OTN-INFO]. 939,943c939,943 < In this example the advertisement of an ODUflex->ODU3 hierarchy is < shown. In case of ODUflex advertisement the MAX LSP Bandwidth needs < to be advertised and in some cases also information about the < Unreserved bandwidth could be useful. The amount of Unreserved < bandwidth does not give a clear indication of how many ODUflex LSP --- > In this example, the advertisement of an ODUflex->ODU3 hierarchy is > shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth > needs to be advertised and, in some cases, information about the > Unreserved bandwidth could also be useful. The amount of Unreserved > bandwidth does not give a clear indication of how many ODUflex LSPs 959,962c959,962 < Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved < Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex < LSPs of 10 GBps each, have to be restored, for sure only one can be < restored along Link B and it is probable (but not sure) that two of --- > Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Unreserv= ed > Bandwidth are available on Link A, 10Gbps on Link B, and 3 ODUflex > LSPs of 10 GBps each have to be restored, for sure only one can be > restored along Link B and it is probable, but not certain, that two of 966c966 < In the case of ODUflex advertisement the Type 2 Bandwidth TLV is --- > In the case of ODUflex advertisement, the Type 2 Bandwidth TLV is 1073c1073 < simplicity we assume that also in this case only priorities 0 and 3 --- > simplicity, we also assume that only priorities 0 and 3 1294c1294 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1388c1388 < In this example 2 OTU4 component links with the same supported TS --- > In this example, 2 OTU4 component links with the same supported TS 1506c1506 < All implementations of this document MAY support also advertisement --- > All implementations of this document MAY also support advertisement 1518c1518 < based on policy and is out of scope of the document. This enables --- > based on policy and beyond the scope of this document. This enables 1537c1537 < [RFC5920] . --- > [RFC5920]. --_000_94A203EA12AECE4BA92D42DBFFE0AE47030D94A5eusaamb101erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <050FC0571DFF084099993E4FD6BC6C39@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Daniele, 
The changes look good to me and I'm happy with the draft. You are corr= ect that RFC 6837 is the wrong reference. Sorry for the confusion. I meant = that RFC 6827 is a good model for a  "Security Considerations&quo= t; sections in a GMPLS specific draft. Of course, you'd remove the text specific to ASON and replace it with OTN.  

9.  Security Considerations

   This document specifies the contents and processing of OSPFv2 TE LSAs
   [RFC3630] and [RFC4202].  The TE LSA extensions defined in this
   document are not used for Shortest Path First (SPF) computation and
   have no direct effect on IP routing.  Additionally, ASON routing
   domains are delimited by the usual administrative domain boundaries.

   Any mechanisms used for securing the exchange of normal OSPF LSAs can
   be applied equally to all TE LSAs used in the ASON context.
   Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic
   authentication [RFC2328] [RFC5709]) can be used to provide
   significant protection against active attacks.  [RFC5709] defines a
   mechanism for authenticating OSPFv2 packets by making use of the
   Hashed Message Authentication Code (HMAC) algorithm in conjunction
   with the SHA family of cryptographic hash functions.

   RCs implementing export/import of ASON routing information between
   RAs MUST also include policy control of both the maximum amount of
   information advertised between RAs and the maximum rate at which it
   is advertised.  This is to isolate the consequences of an RC being
   compromised to the RAs to which that subverted RC is attached.

   The "Analysis of OSPF Security According to KARP Design Guide"
   [OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3
   security relative to the requirements specified in [RFC6518].

Thanks,
Acee

From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.co= m>
Date: Tuesday, October 29, 2013 8:3= 5 AM
To: Ericsson <acee.lindem@ericsson.com>
Cc: "draft-ietf-ccamp-gmpls-ospf-g70= 9v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.or= g>, "rtg-dir@ietf.org" <<= a href=3D"mailto:rtg-dir@ietf.org">rtg-dir@ietf.org>, CCAMP <ccamp@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: RE: RtgDir Review: "T= raffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control = of Evolving G.709 OTN Networks"

Hi Acee,

 

Please find the version solving (h= opefully) the last issues attached. It will be updated on Nov 4th.

 

Also, please find my comments in l= ine.

 

Many thanks

Daniele

 

 

From: Acee Lindem
Sent: luned=EC 28 ottobre 2013 17:01
To: Daniele Ceccarelli
Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org
Subject: Re: RtgDir Review: "Traffic Engineering Extensions to = OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks&qu= ot;

 

Hi Daniele, 

I looked at the update and it is greatly improved. I= 'd still recommend the following issues be addressed. 

 

1.   = ;   In section 4, you state the malformed LSA, TLV,= or Sub-TLV  is ignored. Since this specification describes sub-TLVs, = does that imply that only the sub-TLVs are ignored when malformed? This is = how I'd interpret it. 

 

[[DC]] correct. Fixed as you= suggested below in 369,373c367,370, just changed a bit to reflect the fact= that only sub-TLVs are defined in this document:

 =

    When a received LSA includes a sub-TLV not formatted ac= cordingly to the precise

    specifications in this document, the problem SHOUL= D be logged

    and the wrongly formatted sub-TLV MUST NOT be used for<= o:p>

    path comp= utation.

 

<= o:p> 

2.   = ;   In examples where you used "X" to den= ote that the field is not applicable, you should state that. Or at least st= ate it somewhere. 

 

[[DC]] OK.

T, S and TS granularity fields are not relevant to this example (fil= led with Xs)

 

Also some edits on the new text:

 

 

130c130,131

<    provided in [OTN-INFO].=

---

>    provided in [OTN-INFO].  The = reader is assumed to be familiar with

>    both of these documents. 

136,138d136

<    The reader is supposed to be famil= iar with OTN framework [OTN-FWK]

<    and GMPLS evaluation against OTN [= OTN-INFO].

< 

320c318

<    is shown in the table below (pleas= e note that there are 1000 bits in

---

>    are shown in the table below (plea= se note that there are 1000 bits in

369,373c367,370

<    In case a recived LSA is not forma= tted accordingly to the

<    requirements indicated in this doc= ument, the problem SHOULD be logged

<    and the wrongly formatted LSA, TLV= or Sub-TLV MUST NOT be used for

<    the path computation until a newer= version correctly formatted is

<    received.

---

>    When a received LSA is not formatt= ed accordingly to the precise 

>    specifications in this document, t= he problem SHOULD be logged

>    and the wrongly formatted LSA, TLV= , or Sub-TLV MUST NOT be used for

>    path computation.

1561c1558

<    flooding frequency.  Moreover= the design of the encoding has been

---

>    flooding frequency.  Moreover= , the design of the encoding has been

1573c1570

<       priorities is advertised

---

>       priorities are advertised.=

1575,1578c1572,1575

<       - With respect of fixed co= ntainers, only the number of available

<       containers is advertised i= nstead of available bandwidth so to use

<       only 16 bits per container= instead of 32 (as per former GMPLS

<       encoding

---

>       - With respect to fixed co= ntainers, only the number of available

>       containers is advertised i= nstead of available bandwidth so that

>       only 16 bits per container= are used instead of 32 (as per the

>       former GMPLS encoding).

1580c1577

<    In order to further reduce the amo= unt of data advertised it is

---

>    In order to further reduce the amo= unt of data advertised, it is

 

 

Thanks,

Acee

P.S. I still think it would be better not to referen= ce RFC 2154 in the "Security Considerations". RFC 6837 has a much= better example for OSPF TE than RFC 3630.

[[DC]] Reference to RFC2154 r= emoved but I think  RFC6837 is not the one you wanted to point to (A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database).

 

On Oct 21, 2013, at 10:29 AM, Daniele Ceccarelli wro= te:



Hi Acee,

 

Since today it is the deadline for= draft submission we uploaded a version with the changes agreed up to now a= nd the ones proposed in line below. Further modifications, if needed, will be deferred to a new version on Mon= day Nov 4th.

 

Thanks once again for your review<= /span>

 

Daniele + Co-authors.

 

From: Acee Lindem 
Sent: mercoled=EC = 16 ottobre 2013 22:20
To: Daniele Ceccar= elli
Cc: draft-ietf-ccamp-gmp= ls-ospf-g709v3@tools.ietf.org;&nb= sp;rtg-dir@ietf.org; CCAMP; rtg-ads@tools.ietf.org
Subject: Re: RtgDi= r Review: "Traffic Engineering Extensions to OSPF for Generalized MPLS= (GMPLS) Control of Evolving G.709 OTN Networks"

 

Hi Daniele,

See inline. 

 

On Oct 15, 2013, at 4:21 AM, Daniele Ceccarelli wrot= e:




Hi Acee,

 

Thanks for the careful review and = please find comments/replies in line.

 

BR
Daniele (&co-authors)

 

From: Acee Lindem [mailto:acee.lindem@eri= csson.com] 
Sent: mercoled=EC = 9 ottobre 2013 03:41
To: draft-ietf-ccamp-gmp= ls-ospf-g709v3@tools.ietf.org
Cc: rtg-dir@ietf.org; CCAMP; rtg-ads= @tools.ietf.org
Subject: RtgDir Re= view: "Traffic Engineering Extensions to OSPF for Generalized MPLS (GM= PLS) Control of Evolving G.709 OTN Networks"

 

Hello,

 

I have been selected as the Routing Directorate reviewer = for this draft. The Routing Directorate seeks to review all routing or rout= ing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please seehttp://www.ietf.org/iesg/directorate= /routing.html

 

Although these comments are primarily for the use of the = Routing ADs, it would be helpful if you could consider them along with any = other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the = draft.

 

Document: dr= aft-ietf-ccamp-ospf-g709v3-09.txt

Reviewer: Acee Lindem

Review Date: October 15th, 2013

IETF LC End Date: October 16, 2013

Intended Status: Proposed Standard 

 

Summary: The document is missing some key sections and re= quires some clarification prior to publication. 

 

Comments:

 

Major Issues: The document lacks several critical pieces = of information.   

 

                &= nbsp;1. There is no discussion of OSPF scaling or flooding frequency. Even = if it not expected that G709 

                &= nbsp;     GMPLS signaling will not present any problems, thi= s needs to be stated and justified. Refer to

                &= nbsp;     section 8 in RFC 6827 for an example of such a discussi= on. 

[[Authors]] How about adding= a section saying:

 

It isn't obvious to me that these two extensions are= comparable. I think a separate section pertaining to the OTN extensions wo= uld make more sense. 

 

[[DC]] The following section= has been added:

 

This docume= nt does not introduce OSPF scalability issues with respect
   to existing GMPLS encoding and does not require any modificati= on to
   flooding frequency.  Moreover the design of the encoding = has been
   carried out taking into account bandwidth optimization, and in=
   particular:


  = ;    - Only unreserved and MAX LSP Bandwidth related to supp= orted
      priorities is advertised

      - With respect of fixed containers, only the= number of available
      containers is advertised instead of availabl= e bandwidth so to use
      only 16 bits per container instead of 32 (as= per former GMPLS
      encoding

   In order to further reduce the amount of data advertised it is=
   RECOMMENDED to bundle component links with homogeneous hierarc= hies as
   described in [RFC4201] and illustrated in Section 5.6.<= span style=3D"font-size:10.5pt;font-family:Consolas">

 




                &= nbsp;2. The document includes lots of normative text indicating precis= ely how sub-TLVs MUST be 

                &= nbsp;     formatted. However, there is no indication of what= the action to be taken if the TLVs do

                &= nbsp;     not follow the strict conventions. 

[[Authors]] Good comment. Lo= oking at previous OSPF and OSPF-TE drafts we didn=92t find any text on hand= ling of bad TLV formatting. Any suggestion on how to deal with that is more than welcome.

 

In the past, I've stated that the problem should be = logged and the LSA, TLV, or Sub-TLV MUST NOT be used for TE/GMPLS path comp= utation. It all depends on what makes sense for the encoding violation and = at what level it should be resolved. One generic solution would be to NOT use any LSAs with encoding violations= for GMPLS path computation. 

 

 

[[DC]] This piece of text ha= s been added at the end of section 4:

 

    &nbs= p;      In case a recived LSA is not formatted acc= ordingly to the requirements indicated in

    &nbs= p;      this document, the problem SHOULD be logge= d and the wrongly formatted LSA, TLV or Sub-TLV MUST NOT

    &nbs= p;         be used for the path com= putation until a newer version correctly formatted is received.<= /b>




                &= nbsp;3. The document jumps down into details of G.709 technology without ad= equate 

                &= nbsp;      explanation (particularly in the examples). = Either these details need to be removed or a 

                &= nbsp;     statement of prerequisite knowledge is required. <= /span>

[[Authors]] The reader is su= pposed to have read [OTN-FWK] and [OTN-INFO]. We can add a sentence at the = end of the abstract or intro.

 

This is the minimum. 




 

Minor Issues: The document had a large number of editoria= l errors.

 

                &= nbsp;1. The bit numbering on all the figures was off by 1 column. If you lo= ok at RFC 4203, 

                &= nbsp;     this will be obvious. 

[[Author]] Correct. Fixed.

                &= nbsp;2. The table on page 7 is incomprehensible with the given columns and = headings. Spaces 

                &= nbsp;     rather than commas in numbers are annoying. 

 

 

[[Author]] Spaces substitute= d with commas. As per comment above having read [OTN-FWK] and [OTN-INFO] is= a prerequisite.

 

Does it add anything to this document if one needs t= o look at OTN-FWK and OTN-INFO anyway? It is much less relevant than, say, = a discussion of advertisement and scaling ;^) 

 

For example, what does 239/238 mean? Is this 239 or = 238 separate tributary slots - why is it variable? What does GFP-F mean - i= t is not defined here. 

 

[[DC]] Tabl=
e 7 is needed to fill the common header of the ISCD. E.g. when indicating O=
DU4, the related max lsp bandwidth in the common header of the ISCD needs t=
o be filled with  0x504331E3.
The first and thi=
rd columns of the table are needed for that, while the second one explains =
how the value is Byte/sec is retrieved (i.e. the nominal bit rate of each O=
DU). The =93239/238=94 does not mean 239 OR 238 but means 239 divided by 23=
8.
The meaning of GF=
P-F is explained in the fwk document (defined in G.7041) and stands for Gen=
eric Framing Procedure. In addition to the various ODUs there are three mor=
e ODU types that need to be advertised, namely: i) ODUflex for CBR client s=
ignals, ii) ODUflex for GFP-F mapped client signal and iii) ODU flex resiza=
ble.

                &= nbsp;3. The distinction between TLVs and sub-TLVs is not consistent through= out the document. 

                &= nbsp;     Again, refer to RFC 6827 for an example of consistent r= eferral.

[[Authors]] Good catch. We= =92re defining only sub-tlvs. Fixed.

                &= nbsp;4. Figures 8 and 9 have the T and S fields offset from the bit numberi= ng. Also, it took 

                &= nbsp;     some time to realize that T1 meant a value of 1. <= /span>

[[Authors]] T and S were lef= t intentionally to make the reading easier but maybe it=92s not the case. O= nly 0 and 1 are there now.

5. Figures 11-15 are very inc= onsistent in that these are examples yet the values for T, S, and  som= etime TSG are not specified. Rather, the example includes the letters.  

[[Authors]]=
 The focus of those examples is not T,S and TSG but e.g. ODUflex advertisem=
ent, single stage muxing etc. For each example there is a disclaimer saying=
: =93T, S and T=
S granularity fields are not relevant to this example=94.

 

Then wouldn't X's be more relevant than missing disc= rete values and field labels in the same figure? 

 

[[DC]] OK. X=92s used.




 

                &= nbsp;6. Security section - RFC 2154 is an experimental RFC that has heretof= ore never been 

                &= nbsp;     commercially implemented or deployed. It is time t= o quit referencing it in draft 

                &= nbsp;     "Security Considerations". <= /o:p>

[[Authors]] How about the fo= llowing?

OLD

    [RFC3630] suggests mechanisms such as [RFC21=
54] to protect

   the transmission of = this information=85

NEW

    [RFC3630] suggests mechanisms to protect

   the transmission of = this information=85

 

It would be great with me. There are plenty of revie= wers who will nit pick the security section... 

 




 

  Nits:

1.       The proper punctuation is "i.e., " and "e.g. ,".  

[[Authors]] OK

Also, sentences should not start with either. 

                &= nbsp;     See http://www.rfc-editor.org/rfc-style-guide/rfc-style

2.       Page 7, "Switching Capability-Specific Information (SCSI)? 

[[Authors]] OK

                &= nbsp;3. Suggest formatting the document so that the figures are on separate= pages rather than 

                &= nbsp;     split across pages. 

[[Authors]] I don=92t know h= ow to do that with the .xml file. Maybe this is a comment we can leave for = the RFC editor?

 

Ok. I have been able to do this with 

 

<vspace blankLines=3D"100" />

 

 

[[DC]] It works fine with al= l figures except fig 14. It=92s longer than a page.




3.       Replace all occurrences of "non " with "non-" and do not end l= ines with "non ". 

[[Authors]] OK

                &= nbsp;4. I thought the examples included many run-on sentences that were har= d to parse and lacked

                &= nbsp;     needed punctuation. I tried to edit but I'm not even su= re if I retained the same meaning. You 

                &= nbsp;     can get a flavor for what I mean by the diffs below.&nb= sp;

[[Authors]] OK to all. All m= odifications you suggest have been implemented.

 

Thanks - I'll look for the update. <= /p>

 

Thanks,

Acee 

 




 

 

Thanks,

Acee 

132,133c132,133

<    Routin= g information for Optical Channel Layer (OCh) (i.e. wavelength)

<    is out= of the scope of this document.  Please refer to [RFC6163] and<= /span>

---

>    Routin= g information for Optical Channel Layer (OCh) (i.e., wavelength)

>    is bey= ond the scope of this document.  Please refer to [RFC6163] and<= /span>

 

157c157

<    As dis= cussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so

---

>    As dis= cussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended<= o:p>

 

159c159

<    relate= d to each different ODUj and ODUk/OTUk (Optical Transport Unit)

---

>    of eac= h different ODUj and ODUk/OTUk (Optical Transport Unit)<= /o:p>

176c176

<    In the= following we will use ODUj to indicate a service type that is

---

>    In the= following, we will use ODUj to indicate a service type that is

179c179

<    the OT= Uk.  Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and=

---

>    the OT= Uk.  Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj and

184c184

<    multip= lexing levels.  In the following the term "multiplexing tree"= ;

---

>    multip= lexing levels.  In the following, the term "multiplexing tree&quo= t;

191c191

<    If for= example a multiplexing hierarchy like the following one is

---

>    For ex= ample, If a multiplexing hierarchy like the following one is<= o:p>

251c251

<    one ho= p case multiple hop TE-links advertise ODU switching capacity.

---

>    one ho= p case, multiple hop TE-links advertise ODU switching capacity.

296,297c296,297

<    Both f= or fixed and flexible ODUs the same switching type and encoding

<    values= MUST be used.  When Switching Capability and Encoding fields

---

>    The sa= me switching type and encoding values must be used for both fixed

>    and fl= exible ODUs.  When Switching Capability and Encoding fields

303,304c303,304

<    The MA= X LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <=3D=

<    MAX LS= P Bandwidth <=3D ODUk/OTUk and intermediate values are those on

---

>    The MA= X LSP Bandwidth field is used according to [RFC4203]: i.e., 0 <=3D

>    MAX LS= P Bandwidth <=3D ODUk/OTUk, and intermediate values are those on<= /span>

306,307c306,307

<    E.g. i= n the OTU4 link it could be possible to have ODU4 as MAX LSP<= o:p>

<    Bandwi= dth for some priorities, ODU3 for others, ODU2 for some others

---

>    For ex= ample, in the OTU4 link it could be possible to have ODU4 as MAX LSP=

>    Bandwi= dth for some priorities, ODU3 for others, ODU2 for some others, 

397,398c397,398

<    Proced= ure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non

<    resiza= ble.  Each MUST always be advertised in separate Type 2 TLVs as=

---

>    Proced= ure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) 

>    non-re= sizable.  Each MUST always be advertised in separate Type 2 TLVs as

400c400

<    both G= FP-F resizable and non resizable (i.e. 21 and 22) are

---

>    both G= FP-F resizable and non-resizable (i.e. 21 and 22) are

535c535

<   =     (i.e. a non OTN client).

---

>   =     (i.e., a non-OTN client).

540c540

<      = ; - Priority (8 bits): a bitmap used to indicate which priorities

---

>      = ; - Priority (8 bits): A bitmap used to indicate which priorities

542,543c542,543

<      = ; leftmost bit representing priority level 0 (i.e. the highest) and<= /span>

<      = ; the rightmost bit representing priority level 7 (i.e. the lowest).=

---

>      = ; leftmost bit representing priority level 0 (i.e., the highest) and=

>      = ; the rightmost bit representing priority level 7 (i.e., the lowest).

666c666

<      = ; Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0

---

>      = ; Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0

676,678c676,678

<    At tim= e T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX

<    LSP Ba= ndwidth is still equal to the ODU4 bandwidth, while for<= /o:p>

<    priori= ties from 2 to 7 (excluding the non supported ones) the MAX LSP

---

>    At tim= e T1, an ODU3 at priority 2 is set-up, so for priority 0 the<= o:p>

>    MAX LS= P Bandwidth is still equal to the ODU4 bandwidth, while for

>    priori= ties from 2 to 7 (excluding the non-supported ones) the MAX LSP

680c680

<    next s= upported ODUj in the hierarchy is ODU3.The advertisement is

---

>    next s= upported ODUj in the hierarchy is ODU3. The advertisement is<= o:p>

710c710

<      = ; Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1

---

>      = ; Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1

712,714c712,714

<    At tim= e T2 an ODU2 at priority 4 is set-up.  The first ODU3 is no

<    longer= available since T1 as it was kept by the ODU3 LSP, while the=

<    second= is no more available and just 3 ODU2 are left in it.  ODU2 is<= /span>

---

>    At tim= e T2, an ODU2 at priority 4 is set-up.  The first ODU3 is no

>    longer= available since T1, as it was kept by the ODU3 LSP, while the

>    second= is no more available and just 3 ODU2s are left in it.  ODU2 is=

758c758

<      = ; Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2

---

>      = ; Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2

762c762

<    In thi= s example an interface with Tributary Slot Type 1.25Gbps and<= o:p>

---

>    In thi= s example, an interface with Tributary Slot Type 1.25Gbps and=

766c766

<    switch= ed or terminated, the ODU2 can only be terminated and the ODU1

---

>    switch= ed or terminated, the ODU2 can only be terminated, and the ODU1

768c768

<    advert= ised to support ODU0 the value of is "ignored" (TS<= o:p>

---

>    advert= ised to support ODU0, the value of is "ignored" (TS=

770c770

<    interf= ace a single ISCD is used and its format is as follows:<= /o:p>

---

>    interf= ace, a single ISCD is used and its format is as follows:=

819c819

<    In thi= s example two interfaces with homogeneous hierarchies but

---

>    In thi= s example, two interfaces with homogeneous hierarchies but

822,824c822,824

<    one a = G.709-2012 interface with fallback procedure disabled (TS

<    granul= arity=3D3).  Both of them support ODU1->ODU2->ODU3 hierarchy and=

<    priori= ties 0 and 3.  T and S bits values are not relevant to this

---

>    one su= pports G.709-2012 interface with fallback procedure disabled<= o:p>

>    (TS gr= anularity=3D3).  Both of them support ODU1->ODU2->ODU3 hierarchy=

>    and pr= iorities 0 and 3.  T and S bits values are not relevant to this=

826,827c826,827

<    interf= aces two different ISCDs are used and the format of their SCSIs

<    is as = follows:

---

>    interf= aces, two different ISCDs are used and the format of their 

>    SCSIs = is as follows:

903,908c903,908

<    with d= ifferent exported TS granularity MUST be considered as non

<    homoge= nous hierarchies is the case in which an H-LPS and the client=

<    LSP ar= e terminated on the same egress node.  What can happen is that<= /span>

<    a loos= e Explicit Route Object (ERO) is used at the hop where the

<    signal= ed LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate

<    hop of= the LSP).

---

>    with d= ifferent exported TS granularity MUST be considered as <= o:p>

>    non-ho= mogenous hierarchies. This is the case in which an H-LPS and 

>    the cl= ient LSP are terminated on the same egress node.  What can 

>    happen= is that a loose Explicit Route Object (ERO) is used at the 

>    hop wh= ere the signaled LSP is nested into the Hierarchical-LSP (H-LSP)

>    (penul= timate hop of the LSP).

912,915c912,915

<    if2. &= nbsp;In case the H-LSP on if1 exports a TS=3D1.25Gbps and if2 a

<    TS=3D2= .5Gbps and the service LSP being signaled needs a 1.25Gbps

<    tribut= ary slot, only the H-LSP on if1 can be used to reach node E.<= o:p>

<    For fu= rther details please see section 4.1 of the [OTN-INFO].<= /o:p>

---

>    if2. &= nbsp;In this case, the H-LSP on if1 exports a TS=3D1.25Gbps, if2 a

>    TS=3D2= .5Gbps, the service LSP being signaled needs a 1.25Gbps<= /o:p>

>    tribut= ary slot, and only the H-LSP on if1 can be used to reach node E.

>    For fu= rther details, please see section 4.1 of the [OTN-INFO].=

939,943c939,943

<    In thi= s example the advertisement of an ODUflex->ODU3 hierarchy is

<    shown.=  In case of ODUflex advertisement the MAX LSP Bandwidth needs<= /span>

<    to be = advertised and in some cases also information about the<= /o:p>

<    Unrese= rved bandwidth could be useful.  The amount of Unreserved

<    bandwi= dth does not give a clear indication of how many ODUflex LSP<= o:p>

---

>    In thi= s example, the advertisement of an ODUflex->ODU3 hierarchy is

>    shown.=  In the case of ODUflex advertisement, the MAX LSP Bandwidth

>    needs = to be advertised and, in some cases, information about the

>    Unrese= rved bandwidth could also be useful.  The amount of Unreserved<= /span>

>    bandwi= dth does not give a clear indication of how many ODUflex LSPs=

959,962c959,962

<    Bandwi= dth equal to 10 Gbps each.  In case 50Gbps of Unreserved=

<    Bandwi= dth are available on Link A, 10Gbps on Link B and 3 ODUflex

<    LSPs o= f 10 GBps each, have to be restored, for sure only one can be=

<    restor= ed along Link B and it is probable (but not sure) that two of=

---

>    Bandwi= dth equal to 10 Gbps each.  In the case where 50Gbps of Unreserved

>    Bandwi= dth are available on Link A, 10Gbps on Link B, and 3 ODUflex<= o:p>

>    LSPs o= f 10 GBps each have to be restored, for sure only one can be<= o:p>

>    restor= ed along Link B and it is probable, but not certain, that two of

966c966

<    In the= case of ODUflex advertisement the Type 2 Bandwidth TLV is

---

>    In the= case of ODUflex advertisement, the Type 2 Bandwidth TLV is

1073c1073<= o:p>

<    simpli= city we assume that also in this case only priorities 0 and 3=

---

>    simpli= city, we also assume that only priorities 0 and 3<= /p>

1294c1294<= o:p>

<    In thi= s example 2 OTU4 component links with the same supported TS

---

>    In thi= s example, 2 OTU4 component links with the same supported TS<= o:p>

1388c1388<= o:p>

<    In thi= s example 2 OTU4 component links with the same supported TS

---

>    In thi= s example, 2 OTU4 component links with the same supported TS<= o:p>

1506c1506<= o:p>

<    All im= plementations of this document MAY support also advertisement=

---

>    All im= plementations of this document MAY also support advertisement=

1518c1518<= o:p>

<    based = on policy and is out of scope of the document.  This enables

---

>    based = on policy and beyond the scope of this document.  This enables<= /span>

1537c1537<= o:p>

<    [RFC59= 20] .

---

>    [RFC59= 20].

 

 

               &n= bsp;

               &n= bsp;

 

 

 

 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030D94A5eusaamb101erics_-- From ben@niven-jenkins.co.uk Wed Nov 20 03:46:10 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275821ADBFF; Wed, 20 Nov 2013 03:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Vlsqe0AtTpKN; Wed, 20 Nov 2013 03:46:07 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7431AD73F; Wed, 20 Nov 2013 03:46:07 -0800 (PST) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Vj6EK-0003Qs-9n; Wed, 20 Nov 2013 11:46:00 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Nov 2013 11:45:57 +0000 Message-Id: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, cdni@ietf.org, draft-ietf-cdni-requirements.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-cdni-requirements-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 11:46:10 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-cdni-requirements-12.txt=20 Reviewer: Ben Niven-Jenkins Review Date: 20 November 2013 IETF LC End Date: 26 November 2013=20 Intended Status: Informational Summary: No issues found. This document is ready for publication. The document is well written and the requirements are individually = labelled and assigned a relative priority (high/medium/low). Major issues: None Minor issues: None Nits: Some acronyms are not expanded before first usage, e.g. CSP in the = introduction. CI-11 seems to have an extraneous '>' on the end of the first line. Ben From kleung@cisco.com Wed Nov 20 09:45:01 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A371AE4F1; Wed, 20 Nov 2013 09:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 6QmyCKb10Vcb; Wed, 20 Nov 2013 09:44:59 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 31B001AE4E3; Wed, 20 Nov 2013 09:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1888; q=dns/txt; s=iport; t=1384969493; x=1386179093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q1pQp15dj5R+lGqmfqoiGWpnaPcy6LU3OVXIfOVY290=; b=cklbbaG39mfPaZbnGwtqg/Gi1lGviuTKVVmFKD2s8MLhE7SMd9MfMh3s C2dszParHcgImN5qhwpITE0BpE7laQV0CFZmN167fvjcwtwemGTYFa2CG iT2k6WxgUyZtjAGh5SwglpAbUFlbxvB3wmXaromrVhe5R+IcvQ4h2NTvL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAP/zjFKtJV2Z/2dsb2JhbABZgwc4U71tgRoWdIIlAQEBBAEBATc0AgkMBAIBCBEDAQEBCxQJBycLFAkIAgQBDQUIAYd4DcB6F48mMQIFBoMagRIDqh+DKIIq X-IronPort-AV: E=Sophos;i="4.93,738,1378857600"; d="scan'208";a="974476" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 20 Nov 2013 17:44:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAKHiqXf003905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 17:44:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 11:44:52 -0600 From: "Kent Leung (kleung)" To: Ben Niven-Jenkins , "rtg-ads@tools.ietf.org" Thread-Topic: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 Thread-Index: AQHO5eYa1bqj9TDFj06Dc5TerDpuVZouX/VQ Date: Wed, 20 Nov 2013 17:44:51 +0000 Message-ID: References: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> In-Reply-To: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.100.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Nov 2013 10:54:48 -0800 Cc: "rtg-dir@ietf.org" , "cdni@ietf.org" , "draft-ietf-cdni-requirements.all@tools.ietf.org" Subject: Re: [RTG-DIR] [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:45:01 -0000 Hi Ben. Thank you for the review. The two items in the "Nits" will be fixed= in the next version. Kent -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Wednesday, November 20, 2013 3:46 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; cdni@ietf.org; draft-ietf-cdni-requirements.all@tools= .ietf.org Subject: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-cdni-requirements-12.txt=20 Reviewer: Ben Niven-Jenkins Review Date: 20 November 2013 IETF LC End Date: 26 November 2013=20 Intended Status: Informational Summary: No issues found. This document is ready for publication. The document is well written and the requirements are individually labelled= and assigned a relative priority (high/medium/low). Major issues: None Minor issues: None Nits: Some acronyms are not expanded before first usage, e.g. CSP in the introduc= tion. CI-11 seems to have an extraneous '>' on the end of the first line. Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni