From lberger@labn.net Tue Feb 1 12:15:37 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4032D3A6D99 for ; Tue, 1 Feb 2011 12:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXRuCEW+zWsl for ; Tue, 1 Feb 2011 12:15:35 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id A8F0A3A6C86 for ; Tue, 1 Feb 2011 12:15:35 -0800 (PST) Received: (qmail 7795 invoked by uid 0); 1 Feb 2011 20:18:52 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 1 Feb 2011 20:18:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=I0dcj8oAwZ2rhXc9Z2FNKNeV6II71hxTL/opA4ORJTttwpgSbx6rRFXV0Uj3we3YcXbWi105NqTnAtGIfCy5EpZNq+0dfCP4aKjo1b4no/OIeGQoxDW2RX0WavXCXhOp; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PkMge-00037D-E6; Tue, 01 Feb 2011 13:18:52 -0700 Message-ID: <4D486AAF.1010206@labn.net> Date: Tue, 01 Feb 2011 15:18:55 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julien Meuric References: <4D474BA3.7020803@orange-ftgroup.com> In-Reply-To: <4D474BA3.7020803@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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} Cc: "rtg-dir@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:15:37 -0000 Julien, Thank you for the comments! Please see below for responses. On 1/31/2011 6:54 PM, Julien Meuric wrote: > 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. 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-ccamp-mpls-tp-cp-framework-05 > Reviewer: Julien Meuric > Review Date: 31 January 2011 > IETF LC End Date: 31 January 2011 > Intended Status: Informational > > *Summary:* > I have some minor concerns about this document that I think should be > resolved before publication. > > *Comments:* > This document is clearly written and easy to understand, even if the > reader does not go over the numerous references. > > *Major Issues:* > No major issues found. > > > *Minor Issues:* (leaving out acronym expansion or references to add > already highlighted by the AD) > ---------- > Section 1.3 > Quoting Adrian (by the way: congratulations!): "A reference to > draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of > UNIs and NNIs." Indeed, but it requires more than a reference: since the > aforementioned I-D only defines "service interfaces", a little > elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework > is needed. I'm not sure what you're looking for here. The revised 1.3 now reads: 1.3. Reference Model The control plane reference model is based on the general MPLS-TP reference model as defined in the MPLS-TP framework [RFC5921] and further refined in MPLS-TP User-to-Network and Network-to-Network Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic routing within an MPLS-TP domain. The draft also says: 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) The majority of GMPLS control plane related RFCs define the control plane from the context of an internal network-to-network interface (I-NNI). In the MPLS-TP context, some operators may choose to deploy signaled interfaces across user-to-network (UNI) interfaces and across inter-provider, external network-to-network (E-NNI), interfaces. Such support is embodied in [RFC4208] for UNIs and [RFC5787] for routing areas in support of E-NNIs. This work may require extensions in order to meet the specific needs of an MPLS-TP UNI and E-NNI. What else would you like to see covered? > ---------- > Section 2.1 > Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 > clarifies the intend, but I am not sure it is needed here more than "A > control plane must not be required to support coffee making". Given the number of times the optional nature of CP in TP, it seems appropriate to have [RFC5654, requirement 19] reflected in this document. Would you like to suggest alternate phrasing or can you live with what's there? > > Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" > domains, but I do not think it is defined. Would my domain with all my > 640 Mb/s switching capacity nodes be homogeneous? > I agree with your comment, but it really applies to RFC5654 as we're just quoting that RFC. > I believe requirement 24 also covers 27.C from RFC 5654. > agreed! > Requirement 39 mentions ASON: I thought the scope of ASON was > circuit-switched technologies, has it been extended for packet-switched? > This too is directly from RFC 5654. How about "ASON(control plane) architecture."? > Requirement 62 states "this should be the default": I guess "this" > refers to bidirectional, but I believe the wording should be improved. > Okay, rephrased: The MPLS-TP control plane must support 1:n bidirectional protection for P2P transport paths. Bidirectional 1:n protection should be the default for 1:n protection [RFC5654, requirement 67 A]. > Requirement 65 says "the control plane may support extra-traffic": not > sure what is means (extra traffic over the control network?). Okay, rephrased: The MPLS-TP control plane may support the control of extra-traffic type traffic [RFC5654, note after requirement 67]. > ---------- > Section 4.2.1 > It is consistent to section 2 of RFC 5951: an explicit reference could > be added, especially when considering the title of that RFC... okay, reference added. > ---------- > Section 4.3 and 5.2 > Not sure about the dashes following the numbers: should not they be in > the right column instead of the left one? > I think the current is clear as hyphens typically are at the trailing end of a line break. But I also can't get excited about so will add leading (in addition to trailing) if you think it's needed. > It is a bit surprising to see explicitly "proper vendor implementation" > while it is should be implicit for any standard specification... This was added after a specific discussion. Unfortunately, I really don't recall the specifics of the discussion/objection. I suspect it was rooted in the differences in scope between ITU and IETF specifications. > ---------- > Section 5.3.2: "If the control plane is physically separated... > information". > I do not believe this paragraph is needed here: no other section > mentions that sub-case (which might be in the scope of the ForCES WG). Agreed! > ---------- > Section 4.2.1 focuses on "Management Plane Support" within the "4. TE > LSPs" section. The same kind of paragraph is expected in the "5. > Pseudowires" section but is currently missing. > ---------- > Okay, will add something... > > *Nits:* > ---------- > Section 1.2 > s/over LSP based/over LSP-based/ okay. > ---------- > Section 2.3 > s/customer/client/ RFC5860 says "customer" > ---------- > Section 4.1.1 > s/control (and management) planes/control (and management) plane(s)/ I think the original is correct, but will defer to the RFC editor. > ---------- > Section 4.1.2 > s/and consequently, MPLS-TP uses/and consequently MPLS-TP, uses/ okay. > s/control (and management) planes/control (and management) plane(s)/ see above. > ---------- > Section 4.1.4.1 (interesting concepts) > s/(PCE) Based approaches/(PCE)-based approaches/ okay > s/PCE requests and responses/requests to and responses from PCE/ s/PCE requests and responses/ PCE related requests and responses/ > ---------- > Section 4.1.9 > s/LSPs as discussed in [TP-SURVIVE], is/LSPs, as discussed in > [TP-SURVIVE], is/ okay > ---------- > Section 4.2.1.2 > s/the life, (traffic hit/the life (traffic hit/ okay > ---------- > Section 4.4.4 > s/but nonetheless, must/but nonetheless must/ s/but nonetheless, must/but, nonetheless, must/ > ---------- > Section 4.4.5 > s/OAM related/OAM-related/ (twice) sure > ---------- > Section 4.4.6 > s/Diffserv enable/Diffserv-enabled/transport > s/Diffserv related/Diffserv-related/ sure. > ---------- > Section 4.4.8 > s/entity related/entity-related/ ditto > ---------- > Section 5.3.1 > s/to be, theoretically, a straightforward exercise/to be a > straightforward exercise/ (unless there is a strong reason to keep it > theoretical) well, until we actually do the work, one cannot be sure. (Left as written.) > ---------- > Section 5.3.5 > s/transport service require OAM/transport service requires OAM/ thanks. > s/performance related monitor/performance-related monitor/ > ---------- sure. > Section 6 > s/MPLS and GMPLS related/MPLS- and GMPLS-related/ > ---------- Okay. Much thanks, Lou > > Regards, > > Julien > > > > > From julien.meuric@orange-ftgroup.com Wed Feb 2 16:46:05 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAB83A659B for ; Wed, 2 Feb 2011 16:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwzwc2lrl7Q5 for ; Wed, 2 Feb 2011 16:46:04 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 390B13A657C for ; Wed, 2 Feb 2011 16:46:04 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A0C1FC4003; Thu, 3 Feb 2011 01:49:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 15C87FC4002; Thu, 3 Feb 2011 01:49:28 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 01:49:23 +0100 Received: from [10.193.116.25] ([10.193.116.25]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 01:49:22 +0100 Message-ID: <4D49FB8F.5030909@orange-ftgroup.com> Date: Thu, 03 Feb 2011 01:49:19 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lou Berger References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> In-Reply-To: <4D486AAF.1010206@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Feb 2011 00:49:22.0726 (UTC) FILETIME=[32C29C60:01CBC33C] Cc: "rtg-dir@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:46:05 -0000 Hi Lou. I think we agree on all the nits (the RFC editor will act as an arbitror for the brackets), so please find below my answers on remaining comments. Regards, Julien Le 01/02/2011 21:18, Lou Berger a écrit : > Julien, > Thank you for the comments! Please see below for responses. > > On 1/31/2011 6:54 PM, Julien Meuric wrote: [...] >> *Minor Issues:* (leaving out acronym expansion or references to add >> already highlighted by the AD) >> ---------- >> Section 1.3 >> Quoting Adrian (by the way: congratulations!): "A reference to >> draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of >> UNIs and NNIs." Indeed, but it requires more than a reference: since the >> aforementioned I-D only defines "service interfaces", a little >> elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework >> is needed. > > I'm not sure what you're looking for here. The revised 1.3 now reads: > > 1.3. Reference Model > > The control plane reference model is based on the general MPLS-TP > reference model as defined in the MPLS-TP framework [RFC5921] and > further refined in MPLS-TP User-to-Network and Network-to-Network > Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP > framework [RFC5921], the MPLS-TP control plane is based on GMPLS with > RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both > cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic > routing within an MPLS-TP domain. > > The draft also says: > > > 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) > > The majority of GMPLS control plane related RFCs define the control > plane from the context of an internal network-to-network interface > (I-NNI). In the MPLS-TP context, some operators may choose to deploy > signaled interfaces across user-to-network (UNI) interfaces and > across inter-provider, external network-to-network (E-NNI), > interfaces. Such support is embodied in [RFC4208] for UNIs and > [RFC5787] for routing areas in support of E-NNIs. This work may > require extensions in order to meet the specific needs of an MPLS-TP > UNI and E-NNI. > > What else would you like to see covered? I think everything is covered, it is more a matter of clarification (in the spirit of the explicit "proper vendor implementation" below). [RFC5921] and [TP-UNI] define "Transport Service Interface", "NNI service interface" or "Transport Path CP"; whereas in the 3rd paragraph of your section 1.3 you introduce an "LSP NNI". Even though the latter self-describes, I think it deserves a (short) explicit explanation/definition. What is more [TP-UNI] mentions only signaling over NNI: maybe it should be updated to actually be a consistent model for the CP framework... (Who in the routing directorate was in charge of reviewing that?) > >> ---------- >> Section 2.1 >> Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 >> clarifies the intend, but I am not sure it is needed here more than "A >> control plane must not be required to support coffee making". > > Given the number of times the optional nature of CP in TP, it seems > appropriate to have [RFC5654, requirement 19] reflected in this > document. Would you like to suggest alternate phrasing or can you > live with what's there? > I feel the phrasing in RFC 5654 is clearer. An alternative could be: "The presence of a control plane must not be required for static provisioning." >> >> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >> domains, but I do not think it is defined. Would my domain with all my >> 640 Mb/s switching capacity nodes be homogeneous? >> > > I agree with your comment, but it really applies to RFC5654 as we're > just quoting that RFC. > Indeed. Do you or the AD think I should submit new RFC errata? I fear it may not remove the homogeneous fog... >> I believe requirement 24 also covers 27.C from RFC 5654. >> > > agreed! > >> Requirement 39 mentions ASON: I thought the scope of ASON was >> circuit-switched technologies, has it been extended for packet-switched? >> > > This too is directly from RFC 5654. How about "ASON(control plane) > architecture."? > It would not change much, but would be better anyway. >> Requirement 62 states "this should be the default": I guess "this" >> refers to bidirectional, but I believe the wording should be improved. >> > > Okay, rephrased: > > The MPLS-TP control plane must support 1:n bidirectional > protection for P2P transport paths. Bidirectional 1:n protection > should be the default for 1:n protection [RFC5654, requirement 67 > A]. > Perfect! > >> Requirement 65 says "the control plane may support extra-traffic": not >> sure what is means (extra traffic over the control network?). > > Okay, rephrased: > The MPLS-TP control plane may support the control of extra-traffic > type traffic [RFC5654, note after requirement 67]. > "the control of extra-traffic" would be enough to address my comment, but if you like. >> ---------- >> Section 4.2.1 >> It is consistent to section 2 of RFC 5951: an explicit reference could >> be added, especially when considering the title of that RFC... > > okay, reference added. > >> ---------- >> Section 4.3 and 5.2 >> Not sure about the dashes following the numbers: should not they be in >> the right column instead of the left one? >> > > I think the current is clear as hyphens typically are at the trailing > end of a line break. But I also can't get excited about so will add > leading (in addition to trailing) if you think it's needed. > Leading might improve the reading. >> It is a bit surprising to see explicitly "proper vendor implementation" >> while it is should be implicit for any standard specification... > > This was added after a specific discussion. Unfortunately, I really > don't recall the specifics of the discussion/objection. I suspect it > was rooted in the differences in scope between ITU and IETF > specifications. > No harm done by writing it anyway (just unusual in IETF). [...] From ben@niven-jenkins.co.uk Wed Feb 2 18:02:42 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777EB3A679C for ; Wed, 2 Feb 2011 18:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.203 X-Spam-Level: X-Spam-Status: No, score=-104.203 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJmFonLg5ycz for ; Wed, 2 Feb 2011 18:02:41 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id 58F353A659A for ; Wed, 2 Feb 2011 18:02:41 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pkoa8-0005tI-SV; Thu, 03 Feb 2011 02:06:01 +0000 References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> In-Reply-To: <4D49FB8F.5030909@orange-ftgroup.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Thu, 3 Feb 2011 02:05:55 +0000 To: Julien Meuric X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, Lou Berger , andrew.g.malis@verizon.com, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 02:02:42 -0000 Julien, Lou, Let me see if I can help clarify this point: On 3 Feb 2011, at 00:49, Julien Meuric wrote: > Le 01/02/2011 21:18, Lou Berger a =E9crit : >>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>> domains, but I do not think it is defined. Would my domain with all = my >>> 640 Mb/s switching capacity nodes be homogeneous? >>>=20 >>=20 >> I agree with your comment, but it really applies to RFC5654 as we're = just quoting that RFC. >>=20 > Indeed. Do you or the AD think I should submit new RFC errata? I fear = it may not remove the homogeneous fog... >=20 In this context it means that the domains that are homogeneous with one = another, not that the nodes within a single domain are homogeneous. Requirement 25 in 5654 is meant to convey that it MUST be possible to = set up E2E transport paths across multiple MPLS-TP domains where each = all the domains are homogeneous, i.e. they all use (a separate instance = of) the same control plane protocols. Requirement 26 in 5654 is meant to convey that it SHOULD be possible to = set up E2E transport paths across multiple MPLS-TP domains where all the = domains are not homogeneous, i.e. they do not all use (a separate = instance of) the same control plane protocols, e.g. some may use a = control plane and other may use a management plane. Requirement 26 was inserted at the request of Andy (on behalf of = Verizon) and Greg Mirsky asked for clarification on the meaning in this = e-mail thread: = http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html=20 >>> Requirement 39 mentions ASON: I thought the scope of ASON was >>> circuit-switched technologies, has it been extended for = packet-switched? I am not an ASON expert and wasn't involved in the development of the = ASON Recommendations but my understanding is that prior to "ASON" the = architecture was referred to as ASTN (Automatically Switched Transport = Network), at some point ITU updated the Recommendation and also changed = the terminology to ASON but the change from "Transport" to "Optical" = wasn't meant to imply a limitation of the scope of the architecture and = it is my understanding that ITU-T considers ASON an appropriate = architecture for all transport networks be they optical, circuit = switched or packet switched. If you want song and verse on the history then someone like Italo or = Maarten Vissers can probably provide it or point you to someone who was = involved at the time and can provide the full history and assumed = applicability. HTH Ben From lufang@cisco.com Wed Feb 2 18:08:26 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A663A3A6765 for ; Wed, 2 Feb 2011 18:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTpXrmoqtRau for ; Wed, 2 Feb 2011 18:08:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5C7603A659A for ; Wed, 2 Feb 2011 18:08:25 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkICAL+dSU2tJV2c/2dsb2JhbACWSY5ic6BkmzCFUwSEeIoa Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 02:11:45 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p132BjKL001856; Thu, 3 Feb 2011 02:11:45 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 20:11:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2011 20:11:42 -0600 Message-ID: <238542D917511A45B6B8AA806E875E250463A67A@XMB-RCD-201.cisco.com> In-Reply-To: <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework Thread-Index: AcvDRwNgzLVp0dwUQnq20rNKzKh2cAAAI+KA References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> From: "Luyuan Fang (lufang)" To: "Benjamin Niven-Jenkins" , "Julien Meuric" X-OriginalArrivalTime: 03 Feb 2011 02:11:45.0605 (UTC) FILETIME=[B4F21750:01CBC347] X-Mailman-Approved-At: Thu, 03 Feb 2011 03:33:26 -0800 Cc: rtg-dir@ietf.org, Lou Berger , andrew.g.malis@verizon.com, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 02:08:26 -0000 Ben, Thanks a lot for the clarification. Luyuan -----Original Message----- From: Benjamin Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: Wednesday, February 02, 2011 9:06 PM To: Julien Meuric Cc: Lou Berger; rtg-dir@ietf.org; = draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org; = rtg-ads@tools.ietf.org; andrew.g.malis@verizon.com Subject: Re: [RTG-DIR] RtgDir Review: = draft-ietf-ccamp-mpls-tp-cp-framework Julien, Lou, Let me see if I can help clarify this point: On 3 Feb 2011, at 00:49, Julien Meuric wrote: > Le 01/02/2011 21:18, Lou Berger a =E9crit : >>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>> domains, but I do not think it is defined. Would my domain with all = my >>> 640 Mb/s switching capacity nodes be homogeneous? >>>=20 >>=20 >> I agree with your comment, but it really applies to RFC5654 as we're = just quoting that RFC. >>=20 > Indeed. Do you or the AD think I should submit new RFC errata? I fear = it may not remove the homogeneous fog... >=20 In this context it means that the domains that are homogeneous with one = another, not that the nodes within a single domain are homogeneous. Requirement 25 in 5654 is meant to convey that it MUST be possible to = set up E2E transport paths across multiple MPLS-TP domains where each = all the domains are homogeneous, i.e. they all use (a separate instance = of) the same control plane protocols. Requirement 26 in 5654 is meant to convey that it SHOULD be possible to = set up E2E transport paths across multiple MPLS-TP domains where all the = domains are not homogeneous, i.e. they do not all use (a separate = instance of) the same control plane protocols, e.g. some may use a = control plane and other may use a management plane. Requirement 26 was inserted at the request of Andy (on behalf of = Verizon) and Greg Mirsky asked for clarification on the meaning in this = e-mail thread: = http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html=20 >>> Requirement 39 mentions ASON: I thought the scope of ASON was >>> circuit-switched technologies, has it been extended for = packet-switched? I am not an ASON expert and wasn't involved in the development of the = ASON Recommendations but my understanding is that prior to "ASON" the = architecture was referred to as ASTN (Automatically Switched Transport = Network), at some point ITU updated the Recommendation and also changed = the terminology to ASON but the change from "Transport" to "Optical" = wasn't meant to imply a limitation of the scope of the architecture and = it is my understanding that ITU-T considers ASON an appropriate = architecture for all transport networks be they optical, circuit = switched or packet switched. If you want song and verse on the history then someone like Italo or = Maarten Vissers can probably provide it or point you to someone who was = involved at the time and can provide the full history and assumed = applicability. HTH Ben From lberger@labn.net Thu Feb 3 14:51:27 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050F93A6B2F for ; Thu, 3 Feb 2011 14:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TXWMHFxx0DM for ; Thu, 3 Feb 2011 14:51:25 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 6A5FE3A6A17 for ; Thu, 3 Feb 2011 14:51:25 -0800 (PST) Received: (qmail 21714 invoked by uid 0); 3 Feb 2011 22:54:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Feb 2011 22:54:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=QBT0/dU8BRkCNTrt+nGjGugzOJ8ProgjIJshs5ICPwBDtHvnbzOMPCbbMGynQ7s6E1yjdJjc9FI/nTiqchPQJkYAvRmXPtM8foJ8aH9uy5TskvzO6mXiQICTM3n3mkXR; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pl84e-0006uQ-FX; Thu, 03 Feb 2011 15:54:48 -0700 Message-ID: <4D4B323E.6040200@labn.net> Date: Thu, 03 Feb 2011 17:54:54 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julien Meuric References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> In-Reply-To: <4D49FB8F.5030909@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; 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: "rtg-dir@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:51:27 -0000 Julien, See below. On 2/2/2011 7:49 PM, Julien Meuric wrote: > Hi Lou. > > I think we agree on all the nits (the RFC editor will act as an arbitror > for the brackets), so please find below my answers on remaining comments. > > Regards, > > Julien > > > Le 01/02/2011 21:18, Lou Berger a écrit : >> Julien, >> Thank you for the comments! Please see below for responses. >> >> On 1/31/2011 6:54 PM, Julien Meuric wrote: > [...] >>> *Minor Issues:* (leaving out acronym expansion or references to add >>> already highlighted by the AD) >>> ---------- >>> Section 1.3 >>> Quoting Adrian (by the way: congratulations!): "A reference to >>> draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of >>> UNIs and NNIs." Indeed, but it requires more than a reference: since the >>> aforementioned I-D only defines "service interfaces", a little >>> elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework >>> is needed. >> >> I'm not sure what you're looking for here. The revised 1.3 now reads: >> >> 1.3. Reference Model >> >> The control plane reference model is based on the general MPLS-TP >> reference model as defined in the MPLS-TP framework [RFC5921] and >> further refined in MPLS-TP User-to-Network and Network-to-Network >> Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP >> framework [RFC5921], the MPLS-TP control plane is based on GMPLS with >> RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both >> cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic >> routing within an MPLS-TP domain. >> >> The draft also says: >> >> >> 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) >> >> The majority of GMPLS control plane related RFCs define the control >> plane from the context of an internal network-to-network interface >> (I-NNI). In the MPLS-TP context, some operators may choose to deploy >> signaled interfaces across user-to-network (UNI) interfaces and >> across inter-provider, external network-to-network (E-NNI), >> interfaces. Such support is embodied in [RFC4208] for UNIs and >> [RFC5787] for routing areas in support of E-NNIs. This work may >> require extensions in order to meet the specific needs of an MPLS-TP >> UNI and E-NNI. >> >> What else would you like to see covered? > I think everything is covered, it is more a matter of clarification (in > the spirit of the explicit "proper vendor implementation" below). > [RFC5921] and [TP-UNI] define "Transport Service Interface", "NNI > service interface" or "Transport Path CP"; whereas in the 3rd paragraph > of your section 1.3 you introduce an "LSP NNI". Even though the latter > self-describes, I think it deserves a (short) explicit > explanation/definition. Humm, I'm not sure what an LSP NNI is, so now just reads NNI to be consistent with 5921. > What is more [TP-UNI] mentions only signaling over NNI: maybe it should > be updated to actually be a consistent model for the CP framework... > (Who in the routing directorate was in charge of reviewing that?) no idea. >> >>> ---------- >>> Section 2.1 >>> Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 >>> clarifies the intend, but I am not sure it is needed here more than "A >>> control plane must not be required to support coffee making". >> >> Given the number of times the optional nature of CP in TP, it seems >> appropriate to have [RFC5654, requirement 19] reflected in this >> document. Would you like to suggest alternate phrasing or can you >> live with what's there? >> > I feel the phrasing in RFC 5654 is clearer. An alternative could be: > "The presence of a control plane must not be required for static > provisioning." now says: The presence of a control plane must not be required for static provisioning of MPLS-TP transport paths. [RFC5654, requirement 19]. > >>> >>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>> domains, but I do not think it is defined. Would my domain with all my >>> 640 Mb/s switching capacity nodes be homogeneous? >>> >> >> I agree with your comment, but it really applies to RFC5654 as we're >> just quoting that RFC. >> > Indeed. Do you or the AD think I should submit new RFC errata? I fear it > may not remove the homogeneous fog... > See response from Ben. >>> I believe requirement 24 also covers 27.C from RFC 5654. >>> >> >> agreed! >> >>> Requirement 39 mentions ASON: I thought the scope of ASON was >>> circuit-switched technologies, has it been extended for packet-switched? >>> >> >> This too is directly from RFC 5654. How about "ASON(control plane) >> architecture."? >> > It would not change much, but would be better anyway. > >>> Requirement 62 states "this should be the default": I guess "this" >>> refers to bidirectional, but I believe the wording should be improved. >>> >> >> Okay, rephrased: >> >> The MPLS-TP control plane must support 1:n bidirectional >> protection for P2P transport paths. Bidirectional 1:n protection >> should be the default for 1:n protection [RFC5654, requirement 67 >> A]. >> > Perfect! > >> >>> Requirement 65 says "the control plane may support extra-traffic": not >>> sure what is means (extra traffic over the control network?). >> >> Okay, rephrased: >> The MPLS-TP control plane may support the control of extra-traffic >> type traffic [RFC5654, note after requirement 67]. >> > "the control of extra-traffic" would be enough to address my comment, > but if you like. > >>> ---------- >>> Section 4.2.1 >>> It is consistent to section 2 of RFC 5951: an explicit reference could >>> be added, especially when considering the title of that RFC... >> >> okay, reference added. >> >>> ---------- >>> Section 4.3 and 5.2 >>> Not sure about the dashes following the numbers: should not they be in >>> the right column instead of the left one? >>> >> >> I think the current is clear as hyphens typically are at the trailing >> end of a line break. But I also can't get excited about so will add >> leading (in addition to trailing) if you think it's needed. >> > Leading might improve the reading. > >>> It is a bit surprising to see explicitly "proper vendor implementation" >>> while it is should be implicit for any standard specification... >> >> This was added after a specific discussion. Unfortunately, I really >> don't recall the specifics of the discussion/objection. I suspect it >> was rooted in the differences in scope between ITU and IETF >> specifications. >> > No harm done by writing it anyway (just unusual in IETF). > > [...] Much thanks! Lou From lberger@labn.net Thu Feb 3 15:35:15 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592D13A6B37 for ; Thu, 3 Feb 2011 15:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n+CvMrEK4+A for ; Thu, 3 Feb 2011 15:35:14 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 0027F3A6B36 for ; Thu, 3 Feb 2011 15:35:13 -0800 (PST) Received: (qmail 23121 invoked by uid 0); 3 Feb 2011 23:38:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com.bluehost.com with SMTP; 3 Feb 2011 23:38:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=nxKP61cpI66BSWK4QuX1fNjytfRnT0efRlpVOK+0/aFR81dg/BKXROp4NBHOuJdbLtOtMBGpVNbrwN4Wa48+p0pnCR8hR8yPbH3JNtuDKarzBErIb+sSTcGOAquX5J8I; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pl8l3-0002x9-AG; Thu, 03 Feb 2011 16:38:37 -0700 Message-ID: <4D4B3C83.4070401@labn.net> Date: Thu, 03 Feb 2011 18:38:43 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Benjamin Niven-Jenkins References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> In-Reply-To: <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; 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: rtg-dir@ietf.org, Julien Meuric , andrew.g.malis@verizon.com, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:35:15 -0000 Ben, This is really helpful. does this reflect your intent: 21. The MPLS-TP control plane must work across multiple homogeneous domains [RFC5654, requirement 25], i.e., all domains use the same MPLS-TP control plane. 22. The MPLS-TP control plane should work across multiple non- homogeneous domains [RFC5654, requirement 26], i.e., some domains use the same control plane and other domains use static provisioning. Lou On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: > Julien, Lou, > > Let me see if I can help clarify this point: > > On 3 Feb 2011, at 00:49, Julien Meuric wrote: >> Le 01/02/2011 21:18, Lou Berger a écrit : >>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>> domains, but I do not think it is defined. Would my domain with all my >>>> 640 Mb/s switching capacity nodes be homogeneous? >>>> >>> >>> I agree with your comment, but it really applies to RFC5654 as we're just quoting that RFC. >>> >> Indeed. Do you or the AD think I should submit new RFC errata? I fear it may not remove the homogeneous fog... >> > > In this context it means that the domains that are homogeneous with one another, not that the nodes within a single domain are homogeneous. > > Requirement 25 in 5654 is meant to convey that it MUST be possible to set up E2E transport paths across multiple MPLS-TP domains where each all the domains are homogeneous, i.e. they all use (a separate instance of) the same control plane protocols. > > Requirement 26 in 5654 is meant to convey that it SHOULD be possible to set up E2E transport paths across multiple MPLS-TP domains where all the domains are not homogeneous, i.e. they do not all use (a separate instance of) the same control plane protocols, e.g. some may use a control plane and other may use a management plane. > > Requirement 26 was inserted at the request of Andy (on behalf of Verizon) and Greg Mirsky asked for clarification on the meaning in this e-mail thread: http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html > >>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>> circuit-switched technologies, has it been extended for packet-switched? > > > I am not an ASON expert and wasn't involved in the development of the ASON Recommendations but my understanding is that prior to "ASON" the architecture was referred to as ASTN (Automatically Switched Transport Network), at some point ITU updated the Recommendation and also changed the terminology to ASON but the change from "Transport" to "Optical" wasn't meant to imply a limitation of the scope of the architecture and it is my understanding that ITU-T considers ASON an appropriate architecture for all transport networks be they optical, circuit switched or packet switched. > > If you want song and verse on the history then someone like Italo or Maarten Vissers can probably provide it or point you to someone who was involved at the time and can provide the full history and assumed applicability. > > HTH > Ben > > > > > From ben@niven-jenkins.co.uk Thu Feb 3 16:27:31 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B393C3A635F for ; Thu, 3 Feb 2011 16:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.025 X-Spam-Level: X-Spam-Status: No, score=-104.025 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkvbzSsLrlW1 for ; Thu, 3 Feb 2011 16:27:30 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 6835C3A6B09 for ; Thu, 3 Feb 2011 16:27:30 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pl9Zc-00013W-TK; Fri, 04 Feb 2011 00:30:53 +0000 References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> <4D4B3C83.4070401@labn.net> In-Reply-To: <4D4B3C83.4070401@labn.net> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <51ED19AC-59BF-414A-AF17-CFFB09FA4DF5@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Fri, 4 Feb 2011 00:30:48 +0000 To: Lou Berger X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, Julien Meuric , andrew.g.malis@verizon.com, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:27:31 -0000 On 3 Feb 2011, at 23:38, Lou Berger wrote: >=20 > Ben, >=20 > This is really helpful. does this reflect your intent: >=20 > 21. The MPLS-TP control plane must work across multiple = homogeneous > domains [RFC5654, requirement 25], i.e., all domains use the > same MPLS-TP control plane. >=20 > 22. The MPLS-TP control plane should work across multiple non- > homogeneous domains [RFC5654, requirement 26], i.e., some > domains use the same control plane and other domains use = static > provisioning. >=20 Yes, but... How much ambiguity/accuracy do you wish to avoid Vs how wordy (and = possibly unwieldy) do you want to make the requirement which itself = risks additional ambiguity? What I mean is "same MPLS-TP control plane" is really "same (but = different instances of) MPLS-TP control plane" because if it was just = the "same control plane" then it would be a single (control plane) = domain. However, that makes the wording and sentence construction start to = become ugly and risks causing more confusion than it clarifies, so maybe = I shouldn't have opened that can of worms... Anyway, I'm OK with your proposal, but I would have been OK with the = wording in 5654 as well :-) I guess it's really up to Julien & the ADs and I'll point out that = Adrian is normally pretty good at wordsmithing this sort of thing if = that's the route you want to take. Ben "call me pedant" N-J > Lou >=20 > On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: >> Julien, Lou, >>=20 >> Let me see if I can help clarify this point: >>=20 >> On 3 Feb 2011, at 00:49, Julien Meuric wrote: >>> Le 01/02/2011 21:18, Lou Berger a =E9crit : >>>>> Requirements 21 and 22 refers to "homogeneous" and "non = homogeneous" >>>>> domains, but I do not think it is defined. Would my domain with = all my >>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>>=20 >>>>=20 >>>> I agree with your comment, but it really applies to RFC5654 as = we're just quoting that RFC. >>>>=20 >>> Indeed. Do you or the AD think I should submit new RFC errata? I = fear it may not remove the homogeneous fog... >>>=20 >>=20 >> In this context it means that the domains that are homogeneous with = one another, not that the nodes within a single domain are homogeneous. >>=20 >> Requirement 25 in 5654 is meant to convey that it MUST be possible to = set up E2E transport paths across multiple MPLS-TP domains where each = all the domains are homogeneous, i.e. they all use (a separate instance = of) the same control plane protocols. >>=20 >> Requirement 26 in 5654 is meant to convey that it SHOULD be possible = to set up E2E transport paths across multiple MPLS-TP domains where all = the domains are not homogeneous, i.e. they do not all use (a separate = instance of) the same control plane protocols, e.g. some may use a = control plane and other may use a management plane. >>=20 >> Requirement 26 was inserted at the request of Andy (on behalf of = Verizon) and Greg Mirsky asked for clarification on the meaning in this = e-mail thread: = http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html >>=20 >>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>> circuit-switched technologies, has it been extended for = packet-switched? >>=20 >>=20 >> I am not an ASON expert and wasn't involved in the development of the = ASON Recommendations but my understanding is that prior to "ASON" the = architecture was referred to as ASTN (Automatically Switched Transport = Network), at some point ITU updated the Recommendation and also changed = the terminology to ASON but the change from "Transport" to "Optical" = wasn't meant to imply a limitation of the scope of the architecture and = it is my understanding that ITU-T considers ASON an appropriate = architecture for all transport networks be they optical, circuit = switched or packet switched. >>=20 >> If you want song and verse on the history then someone like Italo or = Maarten Vissers can probably provide it or point you to someone who was = involved at the time and can provide the full history and assumed = applicability. >>=20 >> HTH >> Ben >>=20 >>=20 >>=20 >>=20 >>=20 From andrew.g.malis@verizon.com Thu Feb 3 16:36:01 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4DF3A694C for ; Thu, 3 Feb 2011 16:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL9O-pxUXk3U for ; Thu, 3 Feb 2011 16:36:00 -0800 (PST) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id EFB3B3A65A5 for ; Thu, 3 Feb 2011 16:35:59 -0800 (PST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id p140VTbX004113; Thu, 3 Feb 2011 19:32:38 -0500 (EST) X-AuditID: 8a53433a-b7b45ae000007b4c-3b-4d4b4aab3483 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 54.5C.31564.BAA4B4D4; Thu, 3 Feb 2011 19:39:07 -0500 (EST) Received: from FHDP1LUMXC7HB01.us.one.verizon.com (fhdp1lumxc7hb01.verizon.com [166.68.59.188]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id p140d6Qm012132; Thu, 3 Feb 2011 19:39:06 -0500 (EST) Received: from fhdp1lumxc7v22.us.one.verizon.com ([fe80::30d0:a653:fa92:eedb]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Thu, 3 Feb 2011 19:39:05 -0500 From: "Malis, Andrew G. (Andy)" To: Lou Berger , Benjamin Niven-Jenkins Date: Thu, 3 Feb 2011 19:39:03 -0500 Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework Thread-Index: AcvD+4IjJFyXgW2OSX+REcFhiD6RnQACGmm3 Message-ID: In-Reply-To: <4D4B3C83.4070401@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 04 Feb 2011 02:49:07 -0800 Cc: "rtg-dir@ietf.org" , Julien Meuric , "draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 00:36:01 -0000 Lou, With regards to 22, there are probably three cases that we'll see in practice: 1. Fully dynamic GMPLS control plane for LSP setup, very similar to how MPLS-TE is now used in conjunction with external planning tools, or perhaps MPLS-TP LSP setup initiated as a result of UNI signaling. 2. An equivalent to ATM SPVCs, where an operator initiates, via an NMS command, an MPLS-TP LSP that either just specifies the endpoints, or a loos= e source route, and GMPLS signaling actually instantiates the LSP in the network. 3. NMS-controlled PVC setup, perhaps by using SNMP or another management protocol to install state in every cross-connect in the LSP path, or some other static provisioning mechanism. The point of #22 is that if operator A is using one of these three methods for LSP setup, and operator B is using a different method, it should still be possible to set up LSPs that span both networks. Cheers, Andy On 2/3/11 18:38 , "Lou Berger" wrote: >=20 > Ben, >=20 > This is really helpful. does this reflect your intent: >=20 > 21. The MPLS-TP control plane must work across multiple homogeneous > domains [RFC5654, requirement 25], i.e., all domains use the > same MPLS-TP control plane. >=20 > 22. The MPLS-TP control plane should work across multiple non- > homogeneous domains [RFC5654, requirement 26], i.e., some > domains use the same control plane and other domains use static > provisioning. >=20 > Lou >=20 > On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: >> Julien, Lou, >>=20 >> Let me see if I can help clarify this point: >>=20 >> On 3 Feb 2011, at 00:49, Julien Meuric wrote: >>> Le 01/02/2011 21:18, Lou Berger a =E9crit : >>>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>>> domains, but I do not think it is defined. Would my domain with all m= y >>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>>=20 >>>>=20 >>>> I agree with your comment, but it really applies to RFC5654 as we're j= ust >>>> quoting that RFC. >>>>=20 >>> Indeed. Do you or the AD think I should submit new RFC errata? I fear i= t may >>> not remove the homogeneous fog... >>>=20 >>=20 >> In this context it means that the domains that are homogeneous with one >> another, not that the nodes within a single domain are homogeneous. >>=20 >> Requirement 25 in 5654 is meant to convey that it MUST be possible to se= t up >> E2E transport paths across multiple MPLS-TP domains where each all the >> domains are homogeneous, i.e. they all use (a separate instance of) the = same >> control plane protocols. >>=20 >> Requirement 26 in 5654 is meant to convey that it SHOULD be possible to = set >> up E2E transport paths across multiple MPLS-TP domains where all the dom= ains >> are not homogeneous, i.e. they do not all use (a separate instance of) t= he >> same control plane protocols, e.g. some may use a control plane and othe= r may >> use a management plane. >>=20 >> Requirement 26 was inserted at the request of Andy (on behalf of Verizon= ) and >> Greg Mirsky asked for clarification on the meaning in this e-mail thread= : >> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html >>=20 >>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>> circuit-switched technologies, has it been extended for packet-switch= ed? >>=20 >>=20 >> I am not an ASON expert and wasn't involved in the development of the AS= ON >> Recommendations but my understanding is that prior to "ASON" the archite= cture >> was referred to as ASTN (Automatically Switched Transport Network), at s= ome >> point ITU updated the Recommendation and also changed the terminology to= ASON >> but the change from "Transport" to "Optical" wasn't meant to imply a >> limitation of the scope of the architecture and it is my understanding t= hat >> ITU-T considers ASON an appropriate architecture for all transport netwo= rks >> be they optical, circuit switched or packet switched. >>=20 >> If you want song and verse on the history then someone like Italo or Maa= rten >> Vissers can probably provide it or point you to someone who was involved= at >> the time and can provide the full history and assumed applicability. >>=20 >> HTH >> Ben >>=20 >>=20 >>=20 >>=20 >>=20 From lberger@labn.net Fri Feb 4 07:05:33 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6003A6975 for ; Fri, 4 Feb 2011 07:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkTFZCgBjzfN for ; Fri, 4 Feb 2011 07:05:32 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 234323A68E9 for ; Fri, 4 Feb 2011 07:05:32 -0800 (PST) Received: (qmail 9952 invoked by uid 0); 4 Feb 2011 15:08:57 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 4 Feb 2011 15:08:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=2dsHAH1nM/aL3ZpWLx4s6cYIonBnN4m96h9b84tdVhr8uGLhI6kpM9EhX/LxzhpRplfnnlOVhlISIzmzPQLkj4mSB2C8GAwnO4epeM3lQzGR9rTjDv4rqeUvAZuooCaU; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PlNHM-0002QL-Fn; Fri, 04 Feb 2011 08:08:56 -0700 Message-ID: <4D4C168F.7050408@labn.net> Date: Fri, 04 Feb 2011 10:09:03 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Malis, Andrew G. (Andy)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Benjamin Niven-Jenkins , Julien Meuric , "rtg-ads@tools.ietf.org" , "draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:05:33 -0000 Andy, So you're saying we have SVCs, PVCs, and SPVCs. I agree. But note that from an inter-domain perspective, there's no difference between the latter two cases as both use static provisioning at the domain boundary. How about: 22. The MPLS-TP control plane should work across multiple non- homogeneous domains [RFC5654, requirement 26], i.e., some domains use the same control plane and other domains use static provisioning at the domain boundary. Lou On 2/3/2011 7:39 PM, Malis, Andrew G. (Andy) wrote: > Lou, > > With regards to 22, there are probably three cases that we'll see in > practice: > > 1. Fully dynamic GMPLS control plane for LSP setup, very similar to how > MPLS-TE is now used in conjunction with external planning tools, or perhaps > MPLS-TP LSP setup initiated as a result of UNI signaling. > > 2. An equivalent to ATM SPVCs, where an operator initiates, via an NMS > command, an MPLS-TP LSP that either just specifies the endpoints, or a loose > source route, and GMPLS signaling actually instantiates the LSP in the > network. > > 3. NMS-controlled PVC setup, perhaps by using SNMP or another management > protocol to install state in every cross-connect in the LSP path, or some > other static provisioning mechanism. > > The point of #22 is that if operator A is using one of these three methods > for LSP setup, and operator B is using a different method, it should still > be possible to set up LSPs that span both networks. > > Cheers, > Andy > > > On 2/3/11 18:38 , "Lou Berger" wrote: > >> >> Ben, >> >> This is really helpful. does this reflect your intent: >> >> 21. The MPLS-TP control plane must work across multiple homogeneous >> domains [RFC5654, requirement 25], i.e., all domains use the >> same MPLS-TP control plane. >> >> 22. The MPLS-TP control plane should work across multiple non- >> homogeneous domains [RFC5654, requirement 26], i.e., some >> domains use the same control plane and other domains use static >> provisioning. >> >> Lou >> >> On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: >>> Julien, Lou, >>> >>> Let me see if I can help clarify this point: >>> >>> On 3 Feb 2011, at 00:49, Julien Meuric wrote: >>>> Le 01/02/2011 21:18, Lou Berger a écrit : >>>>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>>>> domains, but I do not think it is defined. Would my domain with all my >>>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>>> >>>>> >>>>> I agree with your comment, but it really applies to RFC5654 as we're just >>>>> quoting that RFC. >>>>> >>>> Indeed. Do you or the AD think I should submit new RFC errata? I fear it may >>>> not remove the homogeneous fog... >>>> >>> >>> In this context it means that the domains that are homogeneous with one >>> another, not that the nodes within a single domain are homogeneous. >>> >>> Requirement 25 in 5654 is meant to convey that it MUST be possible to set up >>> E2E transport paths across multiple MPLS-TP domains where each all the >>> domains are homogeneous, i.e. they all use (a separate instance of) the same >>> control plane protocols. >>> >>> Requirement 26 in 5654 is meant to convey that it SHOULD be possible to set >>> up E2E transport paths across multiple MPLS-TP domains where all the domains >>> are not homogeneous, i.e. they do not all use (a separate instance of) the >>> same control plane protocols, e.g. some may use a control plane and other may >>> use a management plane. >>> >>> Requirement 26 was inserted at the request of Andy (on behalf of Verizon) and >>> Greg Mirsky asked for clarification on the meaning in this e-mail thread: >>> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html >>> >>>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>>> circuit-switched technologies, has it been extended for packet-switched? >>> >>> >>> I am not an ASON expert and wasn't involved in the development of the ASON >>> Recommendations but my understanding is that prior to "ASON" the architecture >>> was referred to as ASTN (Automatically Switched Transport Network), at some >>> point ITU updated the Recommendation and also changed the terminology to ASON >>> but the change from "Transport" to "Optical" wasn't meant to imply a >>> limitation of the scope of the architecture and it is my understanding that >>> ITU-T considers ASON an appropriate architecture for all transport networks >>> be they optical, circuit switched or packet switched. >>> >>> If you want song and verse on the history then someone like Italo or Maarten >>> Vissers can probably provide it or point you to someone who was involved at >>> the time and can provide the full history and assumed applicability. >>> >>> HTH >>> Ben >>> >>> >>> >>> >>> > > > > > From julien.meuric@orange-ftgroup.com Fri Feb 4 07:51:21 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0443B3A6962 for ; Fri, 4 Feb 2011 07:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7xiVlU8xJsw for ; Fri, 4 Feb 2011 07:51:20 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 83BD73A6923 for ; Fri, 4 Feb 2011 07:51:19 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D1C106C000A; Fri, 4 Feb 2011 16:55:13 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C16CA6C0007; Fri, 4 Feb 2011 16:55:13 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 16:54:43 +0100 Received: from [10.193.71.237] ([10.193.71.237]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 16:54:43 +0100 Message-ID: <4D4C2143.8050700@orange-ftgroup.com> Date: Fri, 04 Feb 2011 16:54:43 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lou Berger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Feb 2011 15:54:43.0337 (UTC) FILETIME=[D6C7CF90:01CBC483] Cc: Benjamin Niven-Jenkins , "rtg-ads@tools.ietf.org" , "Malis, Andrew G. \(Andy\)" , "draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:51:21 -0000 Hi Lou. I also feel it is clearer this way. Thanks, Julien Le 04/02/2011 16:15, Malis, Andrew G. (Andy) a écrit : > Lou, > > That sounds good to me, thanks. > > Cheers, > Andy > > On 2/4/11 10:09 , "Lou Berger" wrote: > >> Andy, >> So you're saying we have SVCs, PVCs, and SPVCs. I agree. But note >> that from an inter-domain perspective, there's no difference between the >> latter two cases as both use static provisioning at the domain boundary. >> >> How about: >> >> 22. The MPLS-TP control plane should work across multiple non- >> homogeneous domains [RFC5654, requirement 26], i.e., some >> domains use the same control plane and other domains use static >> provisioning at the domain boundary. >> >> Lou >> >> On 2/3/2011 7:39 PM, Malis, Andrew G. (Andy) wrote: >>> Lou, >>> >>> With regards to 22, there are probably three cases that we'll see in >>> practice: >>> >>> 1. Fully dynamic GMPLS control plane for LSP setup, very similar to how >>> MPLS-TE is now used in conjunction with external planning tools, or perhaps >>> MPLS-TP LSP setup initiated as a result of UNI signaling. >>> >>> 2. An equivalent to ATM SPVCs, where an operator initiates, via an NMS >>> command, an MPLS-TP LSP that either just specifies the endpoints, or a loose >>> source route, and GMPLS signaling actually instantiates the LSP in the >>> network. >>> >>> 3. NMS-controlled PVC setup, perhaps by using SNMP or another management >>> protocol to install state in every cross-connect in the LSP path, or some >>> other static provisioning mechanism. >>> >>> The point of #22 is that if operator A is using one of these three methods >>> for LSP setup, and operator B is using a different method, it should still >>> be possible to set up LSPs that span both networks. >>> >>> Cheers, >>> Andy >>> >>> >>> On 2/3/11 18:38 , "Lou Berger" wrote: >>> >>>> Ben, >>>> >>>> This is really helpful. does this reflect your intent: >>>> >>>> 21. The MPLS-TP control plane must work across multiple homogeneous >>>> domains [RFC5654, requirement 25], i.e., all domains use the >>>> same MPLS-TP control plane. >>>> >>>> 22. The MPLS-TP control plane should work across multiple non- >>>> homogeneous domains [RFC5654, requirement 26], i.e., some >>>> domains use the same control plane and other domains use static >>>> provisioning. >>>> >>>> Lou >>>> >>>> On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: >>>>> Julien, Lou, >>>>> >>>>> Let me see if I can help clarify this point: >>>>> >>>>> On 3 Feb 2011, at 00:49, Julien Meuric wrote: >>>>>> Le 01/02/2011 21:18, Lou Berger a écrit : >>>>>>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>>>>>> domains, but I do not think it is defined. Would my domain with all my >>>>>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>>>>> >>>>>>> I agree with your comment, but it really applies to RFC5654 as we're just >>>>>>> quoting that RFC. >>>>>>> >>>>>> Indeed. Do you or the AD think I should submit new RFC errata? I fear it >>>>>> may >>>>>> not remove the homogeneous fog... >>>>>> >>>>> In this context it means that the domains that are homogeneous with one >>>>> another, not that the nodes within a single domain are homogeneous. >>>>> >>>>> Requirement 25 in 5654 is meant to convey that it MUST be possible to set >>>>> up >>>>> E2E transport paths across multiple MPLS-TP domains where each all the >>>>> domains are homogeneous, i.e. they all use (a separate instance of) the >>>>> same >>>>> control plane protocols. >>>>> >>>>> Requirement 26 in 5654 is meant to convey that it SHOULD be possible to set >>>>> up E2E transport paths across multiple MPLS-TP domains where all the >>>>> domains >>>>> are not homogeneous, i.e. they do not all use (a separate instance of) the >>>>> same control plane protocols, e.g. some may use a control plane and other >>>>> may >>>>> use a management plane. >>>>> >>>>> Requirement 26 was inserted at the request of Andy (on behalf of Verizon) >>>>> and >>>>> Greg Mirsky asked for clarification on the meaning in this e-mail thread: >>>>> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html >>>>> >>>>>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>>>>> circuit-switched technologies, has it been extended for packet-switched? >>>>> >>>>> I am not an ASON expert and wasn't involved in the development of the ASON >>>>> Recommendations but my understanding is that prior to "ASON" the >>>>> architecture >>>>> was referred to as ASTN (Automatically Switched Transport Network), at some >>>>> point ITU updated the Recommendation and also changed the terminology to >>>>> ASON >>>>> but the change from "Transport" to "Optical" wasn't meant to imply a >>>>> limitation of the scope of the architecture and it is my understanding that >>>>> ITU-T considers ASON an appropriate architecture for all transport networks >>>>> be they optical, circuit switched or packet switched. >>>>> >>>>> If you want song and verse on the history then someone like Italo or >>>>> Maarten >>>>> Vissers can probably provide it or point you to someone who was involved at >>>>> the time and can provide the full history and assumed applicability. >>>>> >>>>> HTH >>>>> Ben >>>>> From julien.meuric@orange-ftgroup.com Fri Feb 4 08:06:22 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EFB3A67F7 for ; Fri, 4 Feb 2011 08:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjlVyfqTxkhw for ; Fri, 4 Feb 2011 08:06:21 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 1762E3A6962 for ; Fri, 4 Feb 2011 08:06:21 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2C676768003; Fri, 4 Feb 2011 17:14:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 21912760002; Fri, 4 Feb 2011 17:14:48 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:09:45 +0100 Received: from [10.193.71.237] ([10.193.71.237]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:09:44 +0100 Message-ID: <4D4C24C8.7020704@orange-ftgroup.com> Date: Fri, 04 Feb 2011 17:09:44 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Benjamin Niven-Jenkins References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> In-Reply-To: <4919C220-3AD1-4B70-89C9-32A67B8A58F4@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Feb 2011 16:09:44.0815 (UTC) FILETIME=[F01A6FF0:01CBC485] Cc: rtg-dir@ietf.org, Lou Berger , andrew.g.malis@verizon.com, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:06:22 -0000 Hi Ben. It is nice to have the editor of RFC 5654 on this thread. About the homogeneity, I believe Lou's latest proposal will address the issue. About ASON, my initial comment was not based on the title. If you look at [ITU.g8080.2006], the section "scope" says: "applicable to SDH transport networks, as defined in ITU-T Rec. G.803, and Optical Transport Networks, as defined in ITU-T Rec. G.872". However, I had a check on [ITU.g8080.2008] since your feedback and found: "applicable to connection-oriented circuit or packet transport networks, as defined in [ITU-T G.805]". In other words: my comment was irrelevant, but the answer does not lie in the titles (more a matter of releases). I think we're even, aren't we? One beer for each! ;-) Cheers, Julien Le 03/02/2011 03:05, Benjamin Niven-Jenkins a écrit : > Julien, Lou, > > Let me see if I can help clarify this point: > > On 3 Feb 2011, at 00:49, Julien Meuric wrote: > > Le 01/02/2011 21:18, Lou Berger a écrit : > >>> Requirements 21 and 22 refers to "homogeneous" and "non > >>> homogeneous" domains, but I do not think it is defined. Would > >>> my domain with all my 640 Mb/s switching capacity nodes be > >>> homogeneous? > >>> > >> > >> I agree with your comment, but it really applies to RFC5654 as > >> we're just quoting that RFC. > >> > > Indeed. Do you or the AD think I should submit new RFC errata? I > > fear it may not remove the homogeneous fog... > > > > In this context it means that the domains that are homogeneous with > one another, not that the nodes within a single domain are > homogeneous. > > Requirement 25 in 5654 is meant to convey that it MUST be possible to > set up E2E transport paths across multiple MPLS-TP domains where each > all the domains are homogeneous, i.e. they all use (a separate > instance of) the same control plane protocols. > > Requirement 26 in 5654 is meant to convey that it SHOULD be possible > to set up E2E transport paths across multiple MPLS-TP domains where > all the domains are not homogeneous, i.e. they do not all use (a > separate instance of) the same control plane protocols, e.g. some may > use a control plane and other may use a management plane. > > Requirement 26 was inserted at the request of Andy (on behalf of > Verizon) and Greg Mirsky asked for clarification on the meaning in > this e-mail thread: > http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html > > >>> Requirement 39 mentions ASON: I thought the scope of ASON was > >>> circuit-switched technologies, has it been extended for > >>> packet-switched? > > > I am not an ASON expert and wasn't involved in the development of the > ASON Recommendations but my understanding is that prior to "ASON" the > architecture was referred to as ASTN (Automatically Switched > Transport Network), at some point ITU updated the Recommendation and > also changed the terminology to ASON but the change from "Transport" > to "Optical" wasn't meant to imply a limitation of the scope of the > architecture and it is my understanding that ITU-T considers ASON an > appropriate architecture for all transport networks be they optical, > circuit switched or packet switched. > > If you want song and verse on the history then someone like Italo or > Maarten Vissers can probably provide it or point you to someone who > was involved at the time and can provide the full history and assumed > applicability. > > HTH Ben > > From julien.meuric@orange-ftgroup.com Fri Feb 4 08:11:41 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A878F3A69D3 for ; Fri, 4 Feb 2011 08:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv1aV5mzPaZd for ; Fri, 4 Feb 2011 08:11:32 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 493933A697E for ; Fri, 4 Feb 2011 08:11:30 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8B66B760003; Fri, 4 Feb 2011 17:19:57 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 81C37760002; Fri, 4 Feb 2011 17:19:57 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:14:54 +0100 Received: from [10.193.71.237] ([10.193.71.237]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:14:54 +0100 Message-ID: <4D4C25FE.2050903@orange-ftgroup.com> Date: Fri, 04 Feb 2011 17:14:54 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lou Berger References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4D4B323E.6040200@labn.net> In-Reply-To: <4D4B323E.6040200@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Feb 2011 16:14:54.0626 (UTC) FILETIME=[A8C3D820:01CBC486] Cc: "rtg-dir@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:11:41 -0000 Hi again Lou. It looks like my comments on your I-D were addressed. Let us defer to the ADs about my question on updating draft-ietf-mpls-tp-uni-nni... Thanks, Julien Le 03/02/2011 23:54, Lou Berger a écrit : > Julien, > See below. > > On 2/2/2011 7:49 PM, Julien Meuric wrote: >> Hi Lou. >> >> I think we agree on all the nits (the RFC editor will act as an arbitror >> for the brackets), so please find below my answers on remaining >> comments. >> >> Regards, >> >> Julien >> >> >> Le 01/02/2011 21:18, Lou Berger a écrit : >>> Julien, >>> Thank you for the comments! Please see below for responses. >>> >>> On 1/31/2011 6:54 PM, Julien Meuric wrote: >> [...] >>>> *Minor Issues:* (leaving out acronym expansion or references to add >>>> already highlighted by the AD) >>>> ---------- >>>> Section 1.3 >>>> Quoting Adrian (by the way: congratulations!): "A reference to >>>> draft-ietf-mpls-tp-uni-nni might be appropriate to aid the >>>> discussion of >>>> UNIs and NNIs." Indeed, but it requires more than a reference: >>>> since the >>>> aforementioned I-D only defines "service interfaces", a little >>>> elaboration on the use of "NNI" in >>>> draft-ietf-ccamp-mpls-tp-cp-framework >>>> is needed. >>> >>> I'm not sure what you're looking for here. The revised 1.3 now reads: >>> >>> 1.3. Reference Model >>> >>> The control plane reference model is based on the general MPLS-TP >>> reference model as defined in the MPLS-TP framework [RFC5921] and >>> further refined in MPLS-TP User-to-Network and Network-to-Network >>> Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP >>> framework [RFC5921], the MPLS-TP control plane is based on GMPLS >>> with >>> RSVP-TE for LSP signaling and targeted LDP for PW signaling. In >>> both >>> cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic >>> routing within an MPLS-TP domain. >>> >>> The draft also says: >>> >>> >>> 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) >>> >>> The majority of GMPLS control plane related RFCs define the control >>> plane from the context of an internal network-to-network interface >>> (I-NNI). In the MPLS-TP context, some operators may choose to >>> deploy >>> signaled interfaces across user-to-network (UNI) interfaces and >>> across inter-provider, external network-to-network (E-NNI), >>> interfaces. Such support is embodied in [RFC4208] for UNIs and >>> [RFC5787] for routing areas in support of E-NNIs. This work may >>> require extensions in order to meet the specific needs of an >>> MPLS-TP >>> UNI and E-NNI. >>> >>> What else would you like to see covered? >> I think everything is covered, it is more a matter of clarification (in >> the spirit of the explicit "proper vendor implementation" below). >> [RFC5921] and [TP-UNI] define "Transport Service Interface", "NNI >> service interface" or "Transport Path CP"; whereas in the 3rd paragraph >> of your section 1.3 you introduce an "LSP NNI". Even though the latter >> self-describes, I think it deserves a (short) explicit >> explanation/definition. > > Humm, I'm not sure what an LSP NNI is, so now just reads NNI to be > consistent with 5921. > >> What is more [TP-UNI] mentions only signaling over NNI: maybe it should >> be updated to actually be a consistent model for the CP framework... >> (Who in the routing directorate was in charge of reviewing that?) > > no idea. > >>> >>>> ---------- >>>> Section 2.1 >>>> Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 >>>> clarifies the intend, but I am not sure it is needed here more than "A >>>> control plane must not be required to support coffee making". >>> >>> Given the number of times the optional nature of CP in TP, it seems >>> appropriate to have [RFC5654, requirement 19] reflected in this >>> document. Would you like to suggest alternate phrasing or can you >>> live with what's there? >>> >> I feel the phrasing in RFC 5654 is clearer. An alternative could be: >> "The presence of a control plane must not be required for static >> provisioning." > > now says: > The presence of a control plane must not be required for static > provisioning of MPLS-TP transport paths. [RFC5654, requirement > 19]. > >> >>>> >>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>> domains, but I do not think it is defined. Would my domain with all my >>>> 640 Mb/s switching capacity nodes be homogeneous? >>>> >>> >>> I agree with your comment, but it really applies to RFC5654 as we're >>> just quoting that RFC. >>> >> Indeed. Do you or the AD think I should submit new RFC errata? I fear it >> may not remove the homogeneous fog... >> > > See response from Ben. > >>>> I believe requirement 24 also covers 27.C from RFC 5654. >>>> >>> >>> agreed! >>> >>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>> circuit-switched technologies, has it been extended for >>>> packet-switched? >>>> >>> >>> This too is directly from RFC 5654. How about "ASON(control plane) >>> architecture."? >>> >> It would not change much, but would be better anyway. >> >>>> Requirement 62 states "this should be the default": I guess "this" >>>> refers to bidirectional, but I believe the wording should be improved. >>>> >>> >>> Okay, rephrased: >>> >>> The MPLS-TP control plane must support 1:n bidirectional >>> protection for P2P transport paths. Bidirectional 1:n protection >>> should be the default for 1:n protection [RFC5654, requirement 67 >>> A]. >>> >> Perfect! >> >>> >>>> Requirement 65 says "the control plane may support extra-traffic": not >>>> sure what is means (extra traffic over the control network?). >>> >>> Okay, rephrased: >>> The MPLS-TP control plane may support the control of extra-traffic >>> type traffic [RFC5654, note after requirement 67]. >>> >> "the control of extra-traffic" would be enough to address my comment, >> but if you like. >> >>>> ---------- >>>> Section 4.2.1 >>>> It is consistent to section 2 of RFC 5951: an explicit reference could >>>> be added, especially when considering the title of that RFC... >>> >>> okay, reference added. >>> >>>> ---------- >>>> Section 4.3 and 5.2 >>>> Not sure about the dashes following the numbers: should not they be in >>>> the right column instead of the left one? >>>> >>> >>> I think the current is clear as hyphens typically are at the trailing >>> end of a line break. But I also can't get excited about so will add >>> leading (in addition to trailing) if you think it's needed. >>> >> Leading might improve the reading. >> >>>> It is a bit surprising to see explicitly "proper vendor >>>> implementation" >>>> while it is should be implicit for any standard specification... >>> >>> This was added after a specific discussion. Unfortunately, I really >>> don't recall the specifics of the discussion/objection. I suspect it >>> was rooted in the differences in scope between ITU and IETF >>> specifications. >>> >> No harm done by writing it anyway (just unusual in IETF). >> >> [...] > > Much thanks! > > Lou > From lberger@labn.net Fri Feb 4 08:16:02 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B3E3A6969 for ; Fri, 4 Feb 2011 08:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoWfS8qBHIgI for ; Fri, 4 Feb 2011 08:16:01 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id D4EEE3A6903 for ; Fri, 4 Feb 2011 08:16:00 -0800 (PST) Received: (qmail 10314 invoked by uid 0); 4 Feb 2011 16:19:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy2.bluehost.com with SMTP; 4 Feb 2011 16:19:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=mtveQpE10ejfZf32xHK4RHFVhJSfwsg4OkE8NbG6NpfyFFKEtlchyC94QkgJmcNkNo0abxImHCZoVnrY2LDmefEc5vn3iHYjs4Z0NaThxXQ5NV96fobIsgTmyPVEhBXA; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PlONZ-00012n-Rr; Fri, 04 Feb 2011 09:19:26 -0700 Message-ID: <4D4C2714.7010102@labn.net> Date: Fri, 04 Feb 2011 11:19:32 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julien Meuric References: <4D474BA3.7020803@orange-ftgroup.com> <4D486AAF.1010206@labn.net> <4D49FB8F.5030909@orange-ftgroup.com> <4D4B323E.6040200@labn.net> <4D4C25FE.2050903@orange-ftgroup.com> In-Reply-To: <4D4C25FE.2050903@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; 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: "rtg-dir@ietf.org" , "Malis, Andrew G. \(Andy\)" , Benjamin Niven-Jenkins , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:16:02 -0000 All (including co-authors), A version with all edits to date is available at http://labn.net/docs/. The diff version is at: http://labn.net/docs/draft-ietf-ccamp-mpls-tp-cp-framework-06-preview-2011-02-04-from-5.diff.html I will submit on Tuesday AM if if no comments / changes are received. Lou On 2/4/2011 11:14 AM, Julien Meuric wrote: > Hi again Lou. > > It looks like my comments on your I-D were addressed. Let us defer to > the ADs about my question on updating draft-ietf-mpls-tp-uni-nni... > > Thanks, > > Julien > > > Le 03/02/2011 23:54, Lou Berger a écrit : >> Julien, >> See below. >> >> On 2/2/2011 7:49 PM, Julien Meuric wrote: >>> Hi Lou. >>> >>> I think we agree on all the nits (the RFC editor will act as an arbitror >>> for the brackets), so please find below my answers on remaining >>> comments. >>> >>> Regards, >>> >>> Julien >>> >>> >>> Le 01/02/2011 21:18, Lou Berger a écrit : >>>> Julien, >>>> Thank you for the comments! Please see below for responses. >>>> >>>> On 1/31/2011 6:54 PM, Julien Meuric wrote: >>> [...] >>>>> *Minor Issues:* (leaving out acronym expansion or references to add >>>>> already highlighted by the AD) >>>>> ---------- >>>>> Section 1.3 >>>>> Quoting Adrian (by the way: congratulations!): "A reference to >>>>> draft-ietf-mpls-tp-uni-nni might be appropriate to aid the >>>>> discussion of >>>>> UNIs and NNIs." Indeed, but it requires more than a reference: >>>>> since the >>>>> aforementioned I-D only defines "service interfaces", a little >>>>> elaboration on the use of "NNI" in >>>>> draft-ietf-ccamp-mpls-tp-cp-framework >>>>> is needed. >>>> >>>> I'm not sure what you're looking for here. The revised 1.3 now reads: >>>> >>>> 1.3. Reference Model >>>> >>>> The control plane reference model is based on the general MPLS-TP >>>> reference model as defined in the MPLS-TP framework [RFC5921] and >>>> further refined in MPLS-TP User-to-Network and Network-to-Network >>>> Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP >>>> framework [RFC5921], the MPLS-TP control plane is based on GMPLS >>>> with >>>> RSVP-TE for LSP signaling and targeted LDP for PW signaling. In >>>> both >>>> cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic >>>> routing within an MPLS-TP domain. >>>> >>>> The draft also says: >>>> >>>> >>>> 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) >>>> >>>> The majority of GMPLS control plane related RFCs define the control >>>> plane from the context of an internal network-to-network interface >>>> (I-NNI). In the MPLS-TP context, some operators may choose to >>>> deploy >>>> signaled interfaces across user-to-network (UNI) interfaces and >>>> across inter-provider, external network-to-network (E-NNI), >>>> interfaces. Such support is embodied in [RFC4208] for UNIs and >>>> [RFC5787] for routing areas in support of E-NNIs. This work may >>>> require extensions in order to meet the specific needs of an >>>> MPLS-TP >>>> UNI and E-NNI. >>>> >>>> What else would you like to see covered? >>> I think everything is covered, it is more a matter of clarification (in >>> the spirit of the explicit "proper vendor implementation" below). >>> [RFC5921] and [TP-UNI] define "Transport Service Interface", "NNI >>> service interface" or "Transport Path CP"; whereas in the 3rd paragraph >>> of your section 1.3 you introduce an "LSP NNI". Even though the latter >>> self-describes, I think it deserves a (short) explicit >>> explanation/definition. >> >> Humm, I'm not sure what an LSP NNI is, so now just reads NNI to be >> consistent with 5921. >> >>> What is more [TP-UNI] mentions only signaling over NNI: maybe it should >>> be updated to actually be a consistent model for the CP framework... >>> (Who in the routing directorate was in charge of reviewing that?) >> >> no idea. >> >>>> >>>>> ---------- >>>>> Section 2.1 >>>>> Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 >>>>> clarifies the intend, but I am not sure it is needed here more than "A >>>>> control plane must not be required to support coffee making". >>>> >>>> Given the number of times the optional nature of CP in TP, it seems >>>> appropriate to have [RFC5654, requirement 19] reflected in this >>>> document. Would you like to suggest alternate phrasing or can you >>>> live with what's there? >>>> >>> I feel the phrasing in RFC 5654 is clearer. An alternative could be: >>> "The presence of a control plane must not be required for static >>> provisioning." >> >> now says: >> The presence of a control plane must not be required for static >> provisioning of MPLS-TP transport paths. [RFC5654, requirement >> 19]. >> >>> >>>>> >>>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" >>>>> domains, but I do not think it is defined. Would my domain with all my >>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>> >>>> >>>> I agree with your comment, but it really applies to RFC5654 as we're >>>> just quoting that RFC. >>>> >>> Indeed. Do you or the AD think I should submit new RFC errata? I fear it >>> may not remove the homogeneous fog... >>> >> >> See response from Ben. >> >>>>> I believe requirement 24 also covers 27.C from RFC 5654. >>>>> >>>> >>>> agreed! >>>> >>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>> circuit-switched technologies, has it been extended for >>>>> packet-switched? >>>>> >>>> >>>> This too is directly from RFC 5654. How about "ASON(control plane) >>>> architecture."? >>>> >>> It would not change much, but would be better anyway. >>> >>>>> Requirement 62 states "this should be the default": I guess "this" >>>>> refers to bidirectional, but I believe the wording should be improved. >>>>> >>>> >>>> Okay, rephrased: >>>> >>>> The MPLS-TP control plane must support 1:n bidirectional >>>> protection for P2P transport paths. Bidirectional 1:n protection >>>> should be the default for 1:n protection [RFC5654, requirement 67 >>>> A]. >>>> >>> Perfect! >>> >>>> >>>>> Requirement 65 says "the control plane may support extra-traffic": not >>>>> sure what is means (extra traffic over the control network?). >>>> >>>> Okay, rephrased: >>>> The MPLS-TP control plane may support the control of extra-traffic >>>> type traffic [RFC5654, note after requirement 67]. >>>> >>> "the control of extra-traffic" would be enough to address my comment, >>> but if you like. >>> >>>>> ---------- >>>>> Section 4.2.1 >>>>> It is consistent to section 2 of RFC 5951: an explicit reference could >>>>> be added, especially when considering the title of that RFC... >>>> >>>> okay, reference added. >>>> >>>>> ---------- >>>>> Section 4.3 and 5.2 >>>>> Not sure about the dashes following the numbers: should not they be in >>>>> the right column instead of the left one? >>>>> >>>> >>>> I think the current is clear as hyphens typically are at the trailing >>>> end of a line break. But I also can't get excited about so will add >>>> leading (in addition to trailing) if you think it's needed. >>>> >>> Leading might improve the reading. >>> >>>>> It is a bit surprising to see explicitly "proper vendor >>>>> implementation" >>>>> while it is should be implicit for any standard specification... >>>> >>>> This was added after a specific discussion. Unfortunately, I really >>>> don't recall the specifics of the discussion/objection. I suspect it >>>> was rooted in the differences in scope between ITU and IETF >>>> specifications. >>>> >>> No harm done by writing it anyway (just unusual in IETF). >>> >>> [...] >> >> Much thanks! >> >> Lou >> > > > > From andrew.g.malis@verizon.com Fri Feb 4 07:13:16 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4053A697F for ; Fri, 4 Feb 2011 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH5cDtObCD3V for ; Fri, 4 Feb 2011 07:13:15 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 2C1823A6975 for ; Fri, 4 Feb 2011 07:13:14 -0800 (PST) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p14FEiVi016907; Fri, 4 Feb 2011 10:16:06 -0500 (EST) X-AuditID: 8a532265-b7bb6ae0000003c7-a8-4d4c1831f76a Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 0F.16.00967.1381C4D4; Fri, 4 Feb 2011 09:16:01 -0600 (CST) Received: from FHDP1LUMXC7HB03.us.one.verizon.com (fhdp1lumxc7hb03.verizon.com [166.68.59.190]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id p14FG0pE012477; Fri, 4 Feb 2011 10:16:00 -0500 (EST) Received: from fhdp1lumxc7v22.us.one.verizon.com ([fe80::30d0:a653:fa92:eedb]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Fri, 4 Feb 2011 10:16:00 -0500 From: "Malis, Andrew G. (Andy)" To: Lou Berger Date: Fri, 4 Feb 2011 10:15:58 -0500 Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework Thread-Index: AcvEfXTjcrJh2bUCTgOfavTtiLl4AgAAPfgx Message-ID: In-Reply-To: <4D4C168F.7050408@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 04 Feb 2011 08:44:28 -0800 Cc: Benjamin Niven-Jenkins , Julien Meuric , "rtg-ads@tools.ietf.org" , "draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:13:16 -0000 Lou, That sounds good to me, thanks. Cheers, Andy On 2/4/11 10:09 , "Lou Berger" wrote: > Andy, > So you're saying we have SVCs, PVCs, and SPVCs. I agree. But note > that from an inter-domain perspective, there's no difference between the > latter two cases as both use static provisioning at the domain boundary. >=20 > How about: >=20 > 22. The MPLS-TP control plane should work across multiple non- > homogeneous domains [RFC5654, requirement 26], i.e., some > domains use the same control plane and other domains use static > provisioning at the domain boundary. >=20 > Lou >=20 > On 2/3/2011 7:39 PM, Malis, Andrew G. (Andy) wrote: >> Lou, >>=20 >> With regards to 22, there are probably three cases that we'll see in >> practice: >>=20 >> 1. Fully dynamic GMPLS control plane for LSP setup, very similar to how >> MPLS-TE is now used in conjunction with external planning tools, or perh= aps >> MPLS-TP LSP setup initiated as a result of UNI signaling. >>=20 >> 2. An equivalent to ATM SPVCs, where an operator initiates, via an NMS >> command, an MPLS-TP LSP that either just specifies the endpoints, or a l= oose >> source route, and GMPLS signaling actually instantiates the LSP in the >> network. >>=20 >> 3. NMS-controlled PVC setup, perhaps by using SNMP or another management >> protocol to install state in every cross-connect in the LSP path, or som= e >> other static provisioning mechanism. >>=20 >> The point of #22 is that if operator A is using one of these three metho= ds >> for LSP setup, and operator B is using a different method, it should sti= ll >> be possible to set up LSPs that span both networks. >>=20 >> Cheers, >> Andy >>=20 >>=20 >> On 2/3/11 18:38 , "Lou Berger" wrote: >>=20 >>>=20 >>> Ben, >>>=20 >>> This is really helpful. does this reflect your intent: >>>=20 >>> 21. The MPLS-TP control plane must work across multiple homogene= ous >>> domains [RFC5654, requirement 25], i.e., all domains use the >>> same MPLS-TP control plane. >>>=20 >>> 22. The MPLS-TP control plane should work across multiple non- >>> homogeneous domains [RFC5654, requirement 26], i.e., some >>> domains use the same control plane and other domains use sta= tic >>> provisioning. >>>=20 >>> Lou >>>=20 >>> On 2/2/2011 9:05 PM, Benjamin Niven-Jenkins wrote: >>>> Julien, Lou, >>>>=20 >>>> Let me see if I can help clarify this point: >>>>=20 >>>> On 3 Feb 2011, at 00:49, Julien Meuric wrote: >>>>> Le 01/02/2011 21:18, Lou Berger a =E9crit : >>>>>>> Requirements 21 and 22 refers to "homogeneous" and "non homogeneous= " >>>>>>> domains, but I do not think it is defined. Would my domain with all= my >>>>>>> 640 Mb/s switching capacity nodes be homogeneous? >>>>>>>=20 >>>>>>=20 >>>>>> I agree with your comment, but it really applies to RFC5654 as we're= just >>>>>> quoting that RFC. >>>>>>=20 >>>>> Indeed. Do you or the AD think I should submit new RFC errata? I fear= it >>>>> may >>>>> not remove the homogeneous fog... >>>>>=20 >>>>=20 >>>> In this context it means that the domains that are homogeneous with on= e >>>> another, not that the nodes within a single domain are homogeneous. >>>>=20 >>>> Requirement 25 in 5654 is meant to convey that it MUST be possible to = set >>>> up >>>> E2E transport paths across multiple MPLS-TP domains where each all the >>>> domains are homogeneous, i.e. they all use (a separate instance of) th= e >>>> same >>>> control plane protocols. >>>>=20 >>>> Requirement 26 in 5654 is meant to convey that it SHOULD be possible t= o set >>>> up E2E transport paths across multiple MPLS-TP domains where all the >>>> domains >>>> are not homogeneous, i.e. they do not all use (a separate instance of)= the >>>> same control plane protocols, e.g. some may use a control plane and ot= her >>>> may >>>> use a management plane. >>>>=20 >>>> Requirement 26 was inserted at the request of Andy (on behalf of Veriz= on) >>>> and >>>> Greg Mirsky asked for clarification on the meaning in this e-mail thre= ad: >>>> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00997.html >>>>=20 >>>>>>> Requirement 39 mentions ASON: I thought the scope of ASON was >>>>>>> circuit-switched technologies, has it been extended for packet-swit= ched? >>>>=20 >>>>=20 >>>> I am not an ASON expert and wasn't involved in the development of the = ASON >>>> Recommendations but my understanding is that prior to "ASON" the >>>> architecture >>>> was referred to as ASTN (Automatically Switched Transport Network), at= some >>>> point ITU updated the Recommendation and also changed the terminology = to >>>> ASON >>>> but the change from "Transport" to "Optical" wasn't meant to imply a >>>> limitation of the scope of the architecture and it is my understanding= that >>>> ITU-T considers ASON an appropriate architecture for all transport net= works >>>> be they optical, circuit switched or packet switched. >>>>=20 >>>> If you want song and verse on the history then someone like Italo or >>>> Maarten >>>> Vissers can probably provide it or point you to someone who was involv= ed at >>>> the time and can provide the full history and assumed applicability. >>>>=20 >>>> HTH >>>> Ben >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From david.sinicrope@ericsson.com Fri Feb 4 10:22:07 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4433A68AF; Fri, 4 Feb 2011 10:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aBqfx6jIsdO; Fri, 4 Feb 2011 10:22:06 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 2454D3A69DC; Fri, 4 Feb 2011 10:22:06 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p14J8Kbj007065; Fri, 4 Feb 2011 13:08:21 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 4 Feb 2011 13:25:25 -0500 From: David Sinicrope To: "mpls@ietf.org" , "rtg-dir@ietf.org" Date: Fri, 4 Feb 2011 13:25:20 -0500 Thread-Topic: Routing Directorate review of G.8110.1 Thread-Index: AcvEmOOi133uE5ZRTFWlJbSR8G8OgQ== Message-ID: In-Reply-To: <09c301cbc2d6$bb613150$322393f0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [RTG-DIR] Routing Directorate review of G.8110.1 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:22:08 -0000 I have been selected as the Routing Directorate reviewer for this document. 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 Document: https://datatracker.ietf.org/documents/LIAISON/file1155.pdf Reviewer: David Sinicrope Review Date: 31 January 2011 IETF LC End Date: N/A Intended Status: N/A *Summary and General Comments* In general the document should be progressed pending satisfactory response to the comments below. The document eliminates Penultimate Hop Popping in several places while saying it is an option in Annex A. I believe Penultimate Hop Popping is allowed, although as Annex A points out, it is not the preferred mode of operation. Given this the text must not mandate that it cannot be used. It would be helpful to the reader if its use was addressed in the modeling. *Major Comments* - Summary, Paragraph 2, 2nd sentence - "In the event of a difference between this ITU-T Recommendation and any of the normatively referenced IETF RFCs, the RFCs will take precedence." The RFCs should take precedence in all cases. Change the text to read: "In the event of a difference between this ITU-T Recommendation and any of the referenced IETF RFCs, the RFCs take precedence." - Section 10 MPLS-TP DiffServ Architecture, paragraph 3 states: "The setting of the traffic class (TC) field is as defined in [IETF RFC 3270] and [IETF RFC 5462] for the short-pipe and uniform models with no Penultimate Hop Popping (PHP)." However Annex A allows PHP. Please change the text to "The setting of the traffic class (TC) field is as defined in [IETF RFC 3270] and [IETF RFC 5462] for the short-pipe and uniform models." - Section 10 MPLS-TP DiffServ Architecture, paragraph 5 states: "In order to support short-pipe and uniform tunnelling modes, as defined in [IETF RFC 3270], the Server/MT_A_So function is configured, on individual MT_CP basis, to encode the TC field based on one of the following QoS Encoding Modes: - QoS Encoding Mode A where the TC field is encoded according to the outgoing PHB information; - QoS Encoding Mode B where the TC field is encoded with any value (representing non-meaningful Diff-Serv information)." The TC field must never be used for any purposed other than encoding traffic class information. Please remove Mode B and add the following text "The TC field is encoded and used for QoS indications or, if not used, is silently ignored." - Section 10.1.1 Short Pipe Model, 1st sentence: "The transport processing functions and processes for the short-pipe model (without penultimate hop popping) are described in Figure 10-1. Remove "(without penultimate hop popping)" from the sentence per the inconsistency with Annex A highlighted in the comment above. Please add a second figure showing the PHP case for consistency with Annex A. - Section 10.1.2 Uniform Model, 1st sentence: "The transport processing functions and processes for the Uniform model (without penultimate hop popping) are described in Figure 10-2. Remove "(without penultimate hop popping)" from the sentence per the inconsistency with Annex A highlighted in the comment above. Please add a second figure showing the PHP case for consistency with Annex A. *Minor Comments* - Section 1 Scope, paragraph 6 - "MPLS-TP is a connection-oriented packet-switched transport layer network technology that uses MPLS-TP LSPs and PWs" Should read "MPLS-TP is a connection-oriented packet-switched transport layer network technology that uses PWs and MPLS-TP LSPs per the definition in section 1.3.4 of RFC 5921]" There is no definition of an MPLS-TP PW, and the text should be clear on the definition of an MPLS-TP LSP. - Section 1 Scope, paragraph 6 - "... allows consistent operations with other transport technologies" should be "... allows operation consistent with other transport technologies." - Section 2 References - What is the reason for moving the Survivability framework draft reference (top of page 8) to the Bibliography (bottom of page 46)? It is still listed in the "Scope" clause (1), Functional architecture clause (6), MPLS-TP MEG clause (8.1.3), MPLS-TP survivability techniques clause (9) and Security aspects clause (12). Since the referenced document has now been approved for publication as an RFC, it would make sense to move this reference back to the References section from the Bibliography. - Section 6.1 MPLS-TP Network Layered Structure - No definition of "the MPLS-TP network architecture". Please provide a reference to the definition of the architecture. Reference section 1.3 of RFC 5921. - Section 6.1 MPLS-TP Network Layered Structure - "PWs in MPLS-TP can only be carried over MPLS-TP LSPs." should be "While PWs can only be carried over MPLS LSPs, this document only addresses the case where PWs are carried over MPLS-TP LSPs." The structure as defined is overly restrictive. - Section 6.1 MPLS-TP Network Layered Structure - "The MPLS architecture does not have a minimum packet length. When MPLS packets are transmitted over a non-MPLS-TP server layer with a minimum frame size, the Server/MPLS-TP adaptation function will pad these packets to the minimum frame size of that non-MPLS-TP server layer. This padding is removed at the adaptation sink of the non-MPLS client. The mechanisms for mapping clients over MPLS-TP provide appropriate information (e.g. the length field in the Control Word) to remove the padding at that MPLS-TP/Client adaptation sink function." This paragraph discusses MPLS client adaptation to non-MPLS-TP server layers. Please explain the relevance to MPLS-TP Network Layered Structure. - Figure 6-5 see comment on Section 1 Scope paragraph 6. - Section 6.1.2/6.2.3.1 MPLS Trail Termination section 6.1.2 states "the assignment of the S and TTL fields in the LSP or PW Label Stack Entry (LSE) of a G-ACh packet is defined in the MPLS-TP Trail Termination (MT_TT) function" however, nothing is mentioned about the S bit in section 6.2.3.1. - Section 6.1.2 MPLS-TP Characteristic Information - States "The MT_CI traffic units (MT_CI_D) are accompanied by the MT_CI_iPHB, MT_CI_oPHB, MT_CI_SSF and optional MT_CI_APS signals." There is no definition of MT_CI_APS that I can find in G.8110 or other ITU-T documents. Please add specific normative references to the definition of MT_CI_APS. - Section 6.4 MPLS-TP Network Topology Last sentence before section 6.4.1 "The control plane aspects are out of the scope of this Recommendation." should read "The control plane aspects are not prohibited, but are outside the scope of this Recommendation." Control plane function is part of the MPLS-TP requirements. - Section 6.4.1 Unidirectional and bidirectional connections and trails - Need to clarify this text. It sounds like unidirectional connections in the server layer cannot be combined to carry bidirectional MPLS-TP connections. If this is the intention of the text, it should be brought out more strongly. However, it seems like an unnecessary restriction. - Figure 6-9 - Point to multipoint MPLS-TP subnetwork connection - The previous paragraph states the traffic is broadcast from the root to the leaves. Yet in this figure there are some leaves not receiving the broadcast. Is the traffic multicast instead of broadcast and if so what is the criteria of the multicast? Also if the traffic is sent from root to leaf, what are the horizontal inter leaf communications in the figure? The horizontal lines are labeled "MPLS-TP LC" which may indicate to the reader the exit from the subnetwork, however it is unclear whether they indicate this or communication paths. - Section 6.5 MPLS-TP Label Behavior, 1st sentence - It would be good to provide some specifics here. This sentence references hundreds of pages of documentation not all of which is relevant to label allocation and behavior. - Section 6.5.2 last paragraph before 6.5.3 states "When a request is made to a label manager, a particular label value can be suggested. However there is no guarantee that the suggested label value would be allocated." How is a particular label suggested? If done via management this function is outside the scope of the recommendation. If done via the control plane, this is also outside the scope of the recommendation. In either case, this is an internal function and should be removed from the text. - Section 7 Server/Client Associations states "- MT/client adaptation, where the client is not MPLS-TP. - MT/MT adaptation, for supporting hierarchical MPLS-TP LSPs." - See comment on section 1 regarding "MPLS-TP LSPs". It is not clear whether MPLS is included or excluded as a client in the context of MPLS-TP LSPs. Please clarify. - Section 7.1.1 MT/ETH adaptation, 3rd paragraph, 1st bullet - The text says "Insert the CW word..." Insert between what? It isn't clear what the starting data is for these steps. - Section 7.1.1 MT/ETH adaptation, 3rd paragraph, after 1st bullet - Add "If required, the CW is inserted between and . The sequence number processing may be performed." Without this text it is inconsistent with the 4th paragraph last bullet. and should indicate the points of insertion that will be clarified by the comment above. - Section 7.2 MT/MT adaptation, 3rd paragraph, 3rd bullet - What protocol is the CI_APS based? Please provide a specific normative reference for the definition and details of CI_APS. - Section 7.3 Server/MT adaptation states: "Further definition of the processes to adapt MPLS-TP to server layers is outside the scope of this Recommendation and will be described in [b-ITU-T G.8121]." Shouldn't this say "is described in [b-ITU-T G.8121]"? - Section 8 MPLS-TP OAM Architecture - States "The MPLS-TP OAM mechanisms and implementation are outside the scope of this Recommendation." Change this text to "The MPLS-TP OAM mechanisms are defined in the IETF RFCs and are outside the scope of this Recommendation." *Editorial Comments* - Section 6.2.1.3 MPLS-TP Link uses the access group term before it is defined in 6.2.1.4. It is recommended to swap these sections in the document order. - Figure 6-8 - The arrow should point to MT LC vs. TM LC. - Section 10.1 seems to be missing. The text jumps from section 10 to 10.1.1. From acee.lindem@ericsson.com Thu Feb 10 10:27:30 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D0C3A6981 for ; Thu, 10 Feb 2011 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tquctZt8lQ2U for ; Thu, 10 Feb 2011 10:27:29 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 1FF043A67EE for ; Thu, 10 Feb 2011 10:27:28 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1AJBnP9009377; Thu, 10 Feb 2011 13:11:50 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 10 Feb 2011 13:27:32 -0500 From: Acee Lindem To: "Adrian.Farrel@huawei.com" Date: Thu, 10 Feb 2011 13:27:29 -0500 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt Thread-Index: AcvJUC4OGMw6cAsMRxi7GCOdARDD+g== Message-ID: <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> In-Reply-To: <059a01cbb37d$33bbf130$9b33d390$@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-103--919813897"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org" , "rtg-dir@ietf.org" , "Joel M. Halpern" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:27:30 -0000 --Apple-Mail-103--919813897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joel, Adrian,=20 Let me be devil's advocate - since RFC 3442 provides similar function = for IPv4, why would we want to do more ask for an similar applicability = and scaling caveats?=20 Thanks, Acee On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: > Hi, >=20 > Of course, the I-D is not in WG last call and has, in fact, only just = been > adopted by the WG, but I asked for an early Routing Directorate review = because > the Abstract of the I-D worried me. >=20 > Can we (authors, WG chairs, ADs, and Routing Directorate) have a = discussion > about the question Joel asks, and see whether this idea constitutes = "dynamic > configuration of static routes on a host" or something more scary? >=20 > Many thanks, > Adrian >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 13 January 2011 23:46 >> To: rtg-ads@tools.ietf.org >> Cc: rtg-dir@ietf.org; = draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt >>=20 >> Hello, >>=20 >> 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. 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 >>=20 >> 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. >>=20 >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt >> Reviewer: Joel M. Halpern >> Review Date: 13-Jan-2011 >> IETF LC End Date: N/A >> Intended Status: Standards Track >>=20 >> Summary: I have significant concerns about this document and = recommend >> that the Routing ADs discuss these issues further with the authors. >>=20 >> Comments: >>=20 >> Major Issues: >> Given the existence of RFC 3442, I will not investigate the >> question of whether this is a sensible strategy for directing hosts. = I >> do understand that there are good reasons for wanting to do this. >> However, it seems to me that there needs to be a discussion of how = this >> will be made consistent with routing. A configured preference of = this >> sort could easily cause a host to send messages into a long-lived >> temporary black hole, even when there is another path. Is there an >> expectation that this will somehow be synchronized with teh routing >> system? If so, how? If not, what are the consequences if things get >> de-synchronized. >>=20 >> Minor Issues: >> I presume that the reason there is no discussion of size issues, = as >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? = It >> would seem that even if this is a non-issue, this document should say >> why it is a non-issue. (It seems likely that excessive use of this >> option by an administrator could cause difficulties.) >>=20 >> Nits: >> The introduction begins with the phrasing "The Neighbor Discovery >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the = same >> as ICMPv6. The parenthetical is misleading rather than helpful. = Please >> remove it. >> In contrast, it would be helpful if the beginning of the next >> sentence, "Extensions to the protocol defined in [RFC4191]" actually >> included the words "Router Advertisement" in the text, since that is >> what protocol is referred to without being named. >>=20 >> It would seem a good idea to include a reference to the current >> specification of DHCPv6 the first time it is mentioned. >>=20 >> It would be clearer (not technically different, but clearer) if = the >> first and second sentence in section 4 each indicated what message >> (presumably request and response respectively) is being used to carry >> this information. Even if obvious, it would also be good if the = second >> sentence referred to whatever option holder the response message = uses, >> in parallel with the construction of the first sentence. >>=20 >> The text in section 4.1 as written makes it appear that routes = are >> sent individually, rather than the description of the first part of >> section 4 or the actual description of the format of the >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of >> next-hops and routes, which is clearly not what you actually intend.) >>=20 >> Yours, >> Joel M. Halpern >=20 --Apple-Mail-103--919813897 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxMDE4MjcyOVowIwYJKoZI hvcNAQkEMRYEFBZHvVuHzAthJ5gsXoUBPNAud5c/MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDdSzUVNBzEax+Vt53yYJME1F+H+emp9yU863Gt6MQfFoklcoH4U70uOO4Mllo9Y laDAkhMiqJzHEhsHe40rtYQurDy1krpuPQsz4NfUP7r2SzVTjazIOr8FHnFCamAchEQN7cAxPhnv AiZUksOnaEbqFj9787DOTd4CtgmgGPnEAAAAAAAA --Apple-Mail-103--919813897-- From lberger@labn.net Fri Feb 18 13:37:08 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673443A6E55 for ; Fri, 18 Feb 2011 13:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf0siLejD6Yw for ; Fri, 18 Feb 2011 13:37:07 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 374B23A6AAE for ; Fri, 18 Feb 2011 13:37:07 -0800 (PST) Received: (qmail 27789 invoked by uid 0); 18 Feb 2011 21:37:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 18 Feb 2011 21:37:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=LKfv8eimXR0oPZn3MAhzIsNi/zKSc0NeKnPgABbnn7Mlhp/L7cOhrsQ+KbJFFtgC2jhvJGwzO0lLXgtl7LoxYtGxihn4FIfClLpxvx51QspzwTe23MrOGtLbOFmVr/G7; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PqY1F-0000Wf-4s; Fri, 18 Feb 2011 14:37:41 -0700 Message-ID: <4D5EE6A5.9040305@labn.net> Date: Fri, 18 Feb 2011 16:37:41 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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} Cc: rtg-dir@ietf.org, draft-ietf-pce-inter-layer-req@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-req-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 21:37:08 -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. 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-pce-inter-layer-req-15.txt Reviewer: Lou Berger Review Date: 2/18/2011 IETF LC End Date: 2011-01-07 (requested review by 2/18/2011) Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: I found this to be a solid draft overall with no major deficiencies or nits. I do have a number of minor points/questions that I think are worth resolving before publication. The draft passes ID nits with warnings that I believe can be disregarded. Line numbers obtained from http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pce-inter-layer-req-15.txt will be used in this review. Major Issues: No major issues found. Minor Issues: I'll start with general comments/questions and then move into text/section specific points. - General comment/question: In reading the document I found a number of places where the text seemed to imply that the PCC was always the layer/region boundary, which is inconsistent with RFC5623. Is this intentional? Examples from the document include: 257 An ingress LSR for the higher-layer LSP, or a PCC, needs to 258 know whether triggered signaling is required or not. While this is true for the boundary LSR, I'm not sure how it fits into this document. Isn't such determination made by the boundary LSR per RFCs 4206 and 6001? If so, the sentence is out of scope of this document. If you do keep it, I suggest replacing " An ingress LSR for the higher-layer LSP, or a PCC," with something along the lines of "A layer boundary LSR". 275 Also note that an ingress LSR may be present in multiple layers. Is "ingress LSR" mean "a layer boundary LSR", or "the PCC LSR"? 299 3.1.4. Adaptation Capability 301 It MUST be possible for the path computation request to indicate the 302 desired adaptation function at the end points of the lower-layer LSP 303 that is being computed. This will be particularly important where the 304 ingress and egress LSR participate in more than one layer network but 305 may not be capable of all associated adaptations. This section cases me concern a number of levels. The first is that "adaptation function" is not defined in this document, nor is it used in the other MRN documents. Furthermore, is it reasonable to have adaptation indicated by a PCC when the layer/region boundary is at an intermediate LSR? Perhaps this paragraph is only intended to apply to a multi-layer PCC/LSR? In either case, the scope and intent of this paragraph really needs to be clarified. - Now on to specific points/comments: 126 [RFC4657] and [RFC4674]. Suggest adding ", and the framework provided in [RFC5623]." 271 virtual TE links from regular TE links, it MUST be understood that a Who MUST understand this? If this is the reader/implementer/user then this should be "must". If there are protocol implications, they should be made more explicit, i.e., they're not clear. 276 Thus, when a mono-layer path is requested or supplied, PCEP MUST be 277 able to indicate the required/provided path layer. Doesn't this requirement also apply to multi-layer paths? (Consider case where ingress/PCC is present in multiple layers.) 330 purpose, the PCE discovery mechanism MAY support the disclosure of As this applies to the mechanism and not a particular implementation, shouldn't this be a "MUST"? 333 path-computation-related PCE capabilities: Should supported layers be included in the advertised capability list? 350 4.1. Control of Function and Policy Do you want to add a reference to 5394? That's it! Lou From yaakov_s@rad.com Sun Feb 20 06:24:10 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA5F3A6CCA; Sun, 20 Feb 2011 06:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.007 X-Spam-Level: X-Spam-Status: No, score=-101.007 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtHIk-STbAI2; Sun, 20 Feb 2011 06:23:59 -0800 (PST) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 52C013A6D69; Sun, 20 Feb 2011 06:23:55 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 20 Feb 2011 16:24:04 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 20 Feb 2011 16:23:33 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 20 Feb 2011 16:22:39 +0200 From: Yaakov Stein To: "rtg-ads@tools.ietf.org" , "draft-ietf-pwer-fc-encap-14.all@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-pwer-fc-encap-14.txt Thread-Index: AQHL0QnAgbrWgjrJ7EGVdx4tUkTaHQ== Date: Sun, 20 Feb 2011 14:23:32 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC903D0BA3F@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {DCC56578-D1B0-4F0D-8B6E-A3ECD46923F5} x-cr-hashedpuzzle: Css= I7If MMLn R2mq T9Gi UEnN Ux9F VkSD WBo1 XFAh coYL dfcg lCdR l9G8 z3cx 0aHM; 5; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAdwBlAHIALQBmAGMALQBlAG4AYwBhAHAALQAxADQALgBhAGwAbABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AHAAdwBlADMAQABpAGUAdABmAC4AbwByAGcAOwByAHQAZwAtAGEAZABzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAcgB0AGcALQBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DCC56578-D1B0-4F0D-8B6E-A3ECD46923F5}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Sun, 20 Feb 2011 14:23:22 GMT; UgB0AGcARABpAHIAIAByAGUAdgBpAGUAdwA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAdwBlAHIALQBmAGMALQBlAG4AYwBhAHAALQAxADQALgB0AHgAdAA= x-originating-ip: [172.17.170.37] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 20 Feb 2011 23:21:43 -0800 Cc: "rtg-dir@ietf.org" , Alexander Vainshtein , "pwe3@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pwer-fc-encap-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 14:24:10 -0000 --_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: * rtg-ads@tools.ietf.org * draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: * rtg-dir@ietf.org * pwe3@ietf.org Subject: * RtgDir review: draft-ietf-pwer-fc-encap-14.txt Hello, We (Yaakov and Sasha) have been selected as the Routing Directorate reviewe= rs for this draft. The Routing Directorate seeks to review all routing or r= outing-related drafts as they pass through IETF last call and IESG review. = 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 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-pwer-fc-encap-14.txt Reviewers: Alexander ("Sasha") Vainshtein and Yaakov (Jonathan) Stein Review Date: 2011/02/20 IETF LC End Date: Intended Status: Standard Track Summary: We have some concerns about this document that we believe need to be addres= sed before publication. Comments: 1. The two of us (Sasha and Yaakov) have decided to write a single joint= review, in order to reduce contradictory recommendations. 2. In order to further reduce turnaround time, we have taken the slightl= y unorthodox approach of holding direct talks with one of the draft editors= (David Black). As will be seen in the following, this approach has proven = to be highly productive. 3. The draft includes multiple references to Fibre Channel (FC) standard= s, which hinder comprehension for those not expert in the technology. The s= tatus of these references is also somewhat problematic: * [FC-BB-6] (Normative) triggers circular normative referencing betw= een IETF and T11: * It is currently a T11 working document waiting for approval. * It can only be accessed by the interested IETF participants by sen= ding a direct request to David Black, who is both co-editor of this draft a= nd T11's official liaison to the IETF. * It uses this draft as a Normative reference and hence will be appr= oved by T11 only after an RFC number has been assigned to this draft. * As this is not intended to be a downref, the responsible AD will n= eed to explain the situation to the RFC Editor once the draft is approved f= or publication. * [FC-FS-2] (Normative) is an approved T11 standard that can be acce= ssed by interested IETF participants by sending a request to David Black (d= avid.black@emc.com) in his official capacity as= T11 liaison to IETF. * [FC-SP] is listed as a Normative reference. However, it describes= the FC Security Protocol that is, according to the draft, transparent to = the FC PW. Hence it makes sense to redefine it as an Informational referenc= e. * All these references are flagged as warnings by the latest IETF ni= ts tool. 4. We would like to thank the authors for resolving in version 14 many i= ssues that we had raised in the past regarding the K-codes, timing constrai= nts, and specifically the operation of the NSP. Major Issues: 1. The draft refers in several places to the "reliable transport... prov= ided by MPLS-TE/MPLS-TP". This terminology is inappropriate in the IETF whe= re "reliable" is used in a completely different sense, especially as the dr= aft compares the FC PW to transport of FC over TCP/IP that has been defined= in RFC 3821. The problem is aggravated by the fact that the common PWE3 t= echnique that allows detection of lost and/or reordered PW packets (sequenc= ing) is intentionally disabled (in Section 3.1 the draft states that the se= quence number MUST be set to 0 by the sender and MUST be ignored by the rec= eiver). We have discussed this point with the one of the draft editors and = obtained agreement that the usage of the term "reliable" in this context is= inappropriate. We highly recommend that the authors modify the present tex= t by replacing the term "reliable" with the actual expectations regarding d= elivery of the FC PW packets (low drop rate, low chance of reordering). We = also suggest adding text on the handling of lost, re-ordered and duplicate = FC PW packets to the Applicability section. 2. The draft proposes usage of "sub-rating" of FC Primitive Sequences, w= ithout specifying acceptable sub-rating factors and without explaining whet= her these values require coordination between the two PEs. One of the docum= ent editors has assured us that coordination is not required, but that ther= e are limitations on sub-rating in order to avoid timeouts. We strongly sug= gest that the authors add some text explaining this, providing guidance reg= arding suitable sub-rating values. 3. The draft requests IANA to reserve four Interface Parameter sub-TLV v= alues for functionality that has been dropped from the draft after having b= een rejected by the PWE3 WG, in order to accommodate the possibility of thi= s functionality being reintroduced at some future time. This request would = be justified if there were multiple deployed pre-standard implementations s= upporting this functionality (as was the case for the "Martini mode" of the= Frame Relay PWs). As far as we know, there is at most only one such pre-st= andard implementation. We suggest that the responsible AD decide on the pro= per course of action. Minor Issues: 1. In contrast to the rest of the PWE3 documents, a dedicated Native Ser= vice Processor (NSP) block is mandatory for implementing (and even understa= nding) the draft. We would like to thank the authors for the much improved = explanation of this NSP in the present version. However, some of the functi= onality of the NSP operation is similar to functions that are not considere= d NSP functions in other PWE3 encapsulation documents e.g.: * Suppression of idle codes (in contrast, suppression of idle ATM ce= lls is not considered as an NSP function in RFC 4717) * Removal of 8b/10b encoding (in contrast, the same operation is not= considered as an NSP function in RFC 4448). We believe that a note should be added clarifying this point. 2. The draft refers to MTU issues associated with the FC PW, but does no= t state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, ...,= or MUST NOT be included in the Label Mapping message during the FC PW setu= p. Since all FC interfaces have the same MTU, this parameter is not really = needed during the setup. We suggest that the authors explicitly indicate th= at the Interface MTU parameter MUST NOT appear in the FC PW setup protocol = exchange. (Aside: This is based on experience with RFC 5287 where the fact = that it was not specified that the Interface MTU parameter MUST NOT appear = in the TDM PW setup eventually led to interoperability issues). We have sen= t the authors proposed text to deal with this issue. 3. The draft defines that the CRC of the FC frames MUST always be includ= ed in the PW encapsulation. However, its handling differs from the handling= of FCS per RFC 4720; in particular, FC frames received with CRC errors mus= t be transmitted over the PW. It would be nice to explicitly note this diff= erence, and for the signaling procedure to explicitly specify non-usage of = the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the a= uthors proposed text to deal with this issue. Regards, Y(J)S and Sasha --_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Sun Feb 20 08:43:00 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89233A6CCA; Sun, 20 Feb 2011 08:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-u9FYoan65i; Sun, 20 Feb 2011 08:42:49 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 190943A6CBF; Sun, 20 Feb 2011 08:42:47 -0800 (PST) X-AuditID: 93eaf2e7-b7c4aae000007a4b-6d-4d6144af156a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 98.C3.31307.FA4416D4; Sun, 20 Feb 2011 18:43:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 20 Feb 2011 18:43:24 +0200 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" , "draft-ietf-pwer-fc-encap-14.all@tools.ietf.org" Date: Sun, 20 Feb 2011 18:43:22 +0200 Thread-Topic: RtgDir review: draft-ietf-pwer-fc-encap-14.txt Thread-Index: AQHL0QnAgbrWgjrJ7EGVdx4tUkTaHZQKl8VQ Message-ID: References: <07F7D7DED63154409F13298786A2ADC903D0BA3F@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAABBci5UoXcZZxF3JOVhdyU1s= X-Mailman-Approved-At: Sun, 20 Feb 2011 23:21:42 -0800 Cc: "rtg-dir@ietf.org" , Yaakov Stein , "pwe3@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwer-fc-encap-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:43:01 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I confirm that the text of the review sent by Yaakov represents our common = position. I hope that this unorthodox approach to reviewing the draft is acceptable. Regards, Sasha From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Sunday, February 20, 2011 4:24 PM To: rtg-ads@tools.ietf.org; draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org; Alexander Vainshtein Subject: RtgDir review: draft-ietf-pwer-fc-encap-14.txt To: * rtg-ads@tools.ietf.org * draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: * rtg-dir@ietf.org * pwe3@ietf.org Subject: * RtgDir review: draft-ietf-pwer-fc-encap-14.txt Hello, We (Yaakov and Sasha) have been selected as the Routing Directorate reviewe= rs for this draft. The Routing Directorate seeks to review all routing or r= outing-related drafts as they pass through IETF last call and IESG review. = 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 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-pwer-fc-encap-14.txt Reviewers: Alexander ("Sasha") Vainshtein and Yaakov (Jonathan) Stein Review Date: 2011/02/20 IETF LC End Date: Intended Status: Standard Track Summary: We have some concerns about this document that we believe need to be addres= sed before publication. Comments: 1. The two of us (Sasha and Yaakov) have decided to write a single joint = review, in order to reduce contradictory recommendations. 2. In order to further reduce turnaround time, we have taken the slightly= unorthodox approach of holding direct talks with one of the draft editors = (David Black). As will be seen in the following, this approach has proven t= o be highly productive. 3. The draft includes multiple references to Fibre Channel (FC) standards= , which hinder comprehension for those not expert in the technology. The st= atus of these references is also somewhat problematic: * [FC-BB-6] (Normative) triggers circular normative referencing betwe= en IETF and T11: * It is currently a T11 working document waiting for approval. * It can only be accessed by the interested IETF participants by se= nding a direct request to David Black, who is both co-editor of this draft = and T11's official liaison to the IETF. * It uses this draft as a Normative reference and hence will be app= roved by T11 only after an RFC number has been assigned to this draft. * As this is not intended to be a downref, the responsible AD will = need to explain the situation to the RFC Editor once the draft is approved = for publication. * [FC-FS-2] (Normative) is an approved T11 standard that can be acces= sed by interested IETF participants by sending a request to David Black (da= vid.black@emc.com) in his official capacity as = T11 liaison to IETF. * [FC-SP] is listed as a Normative reference. However, it describes = the FC Security Protocol that is, according to the draft, transparent to t= he FC PW. Hence it makes sense to redefine it as an Informational reference= . * All these references are flagged as warnings by the latest IETF nit= s tool. 4. We would like to thank the authors for resolving in version 14 many i= ssues that we had raised in the past regarding the K-codes, timing constrai= nts, and specifically the operation of the NSP. Major Issues: 1. The draft refers in several places to the "reliable transport... prov= ided by MPLS-TE/MPLS-TP". This terminology is inappropriate in the IETF whe= re "reliable" is used in a completely different sense, especially as the dr= aft compares the FC PW to transport of FC over TCP/IP that has been defined= in RFC 3821. The problem is aggravated by the fact that the common PWE3 t= echnique that allows detection of lost and/or reordered PW packets (sequenc= ing) is intentionally disabled (in Section 3.1 the draft states that the se= quence number MUST be set to 0 by the sender and MUST be ignored by the rec= eiver). We have discussed this point with the one of the draft editors and = obtained agreement that the usage of the term "reliable" in this context is= inappropriate. We highly recommend that the authors modify the present tex= t by replacing the term "reliable" with the actual expectations regarding d= elivery of the FC PW packets (low drop rate, low chance of reordering). We = also suggest adding text on the handling of lost, re-ordered and duplicate = FC PW packets to the Applicability section. 2. The draft proposes usage of "sub-rating" of FC Primitive Sequences, w= ithout specifying acceptable sub-rating factors and without explaining whet= her these values require coordination between the two PEs. One of the docum= ent editors has assured us that coordination is not required, but that ther= e are limitations on sub-rating in order to avoid timeouts. We strongly sug= gest that the authors add some text explaining this, providing guidance reg= arding suitable sub-rating values. 3. The draft requests IANA to reserve four Interface Parameter sub-TLV v= alues for functionality that has been dropped from the draft after having b= een rejected by the PWE3 WG, in order to accommodate the possibility of thi= s functionality being reintroduced at some future time. This request would = be justified if there were multiple deployed pre-standard implementations s= upporting this functionality (as was the case for the "Martini mode" of the= Frame Relay PWs). As far as we know, there is at most only one such pre-st= andard implementation. We suggest that the responsible AD decide on the pro= per course of action. Minor Issues: 1. In contrast to the rest of the PWE3 documents, a dedicated Native Serv= ice Processor (NSP) block is mandatory for implementing (and even understan= ding) the draft. We would like to thank the authors for the much improved e= xplanation of this NSP in the present version. However, some of the functio= nality of the NSP operation is similar to functions that are not considered= NSP functions in other PWE3 encapsulation documents e.g.: * Suppression of idle codes (in contrast, suppression of idle ATM cel= ls is not considered as an NSP function in RFC 4717) * Removal of 8b/10b encoding (in contrast, the same operation is not = considered as an NSP function in RFC 4448). We believe that a note should be added clarifying this point. 2. The draft refers to MTU issues associated with the FC PW, but does no= t state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, ...,= or MUST NOT be included in the Label Mapping message during the FC PW setu= p. Since all FC interfaces have the same MTU, this parameter is not really = needed during the setup. We suggest that the authors explicitly indicate th= at the Interface MTU parameter MUST NOT appear in the FC PW setup protocol = exchange. (Aside: This is based on experience with RFC 5287 where the fact = that it was not specified that the Interface MTU parameter MUST NOT appear = in the TDM PW setup eventually led to interoperability issues). We have sen= t the authors proposed text to deal with this issue. 3. The draft defines that the CRC of the FC frames MUST always be includ= ed in the PW encapsulation. However, its handling differs from the handling= of FCS per RFC 4720; in particular, FC frames received with CRC errors mus= t be transmitted over the PW. It would be nice to explicitly note this diff= erence, and for the signaling procedure to explicitly specify non-usage of = the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the a= uthors proposed text to deal with this issue. Regards, Y(J)S and Sasha --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To:

·&nbs= p;       <= a href=3D"mailto:rtg-ads@tools.ietf.org">rtg-ads@tools.ietf.org

Cc:

·&nbs= p;       <= a href=3D"mailto:rtg-dir@ietf.org">rtg-dir@ietf.org

Subject= :

·&nbs= p;       R= tgDir review: draft-ietf-pwer-fc-encap-14.txt

 

Hello,

We (Yaakov and Sasha) have been selected a= s the Routing Directorate reviewers 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. The purpose of the review is t= o provide assistance to the Routing ADs. For more information about the Rou= ting Directorate, please see http://www.ie= tf.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 receiv= e, and strive to resolve them through discussion or by updating the draft.<= o:p>

Document: draft-ietf-pwer-fc-encap-14.txt
Reviewers: Alexander (“Sasha”) Vainshtein and Yaakov (Jonathan)= Stein
Review Date:  2011/02/20
IETF LC End Date:
Intended Status: Standard Track

 

Summary:

We have some concerns about this document that we believe need= to be addressed before publication.

Comments:

  1. The two of us (Sasha and Yaakov) have decided to write a single= joint review, in order to reduce contradictory recommendations.=
  2. In order to further reduce turnaround time, we have taken the s= lightly unorthodox approach of holding direct talks with one of the draft e= ditors (David Black). As will be seen in the following, this approach has proven to be highly productive.
    3. <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto; mso-list:l3 level1 lfo4"> The draft includes multiple references to Fibre Channel (FC) st= andards, which hinder comprehension for those not expert in the technology.= The status of these references is also somewhat problematic:
    • [FC-BB-6] (Normative) triggers circular normative referencing between IETF and T11:

·&nbs= p;       I= t is currently a T11 working document waiting for approval.

·&nbs= p;       I= t can only be accessed by the interested IETF participants by sending a dir= ect request to David Black, who is both co-editor of this draft and T11's official liaison to the IETF.

·&nbs= p;       I= t uses this draft as a Normative reference and hence will be approved by T1= 1 only after an RFC number has been assigned to this draft.

·&nbs= p;       As this is no= t intended to be a downref, the responsible AD will need to explain the situation to the RFC Editor once the draft is approve= d for publication.

    • [FC-FS-2] (No= rmative) is an approved T11 standard that can be accessed by interested IET= F participants by sending a request to David Black (david.black@emc.com) in his official capacity a= s T11 liaison to IETF.
    • [FC-SP]  is listed a= s a Normative reference. However, it describes the FC  Security Protoc= ol that is, according to the draft, transparent to the FC PW. Hence it make= s sense to redefine it as an Informational reference.
    • All these references are = flagged as warnings by the latest IETF nits tool.

= 4.    We would like= to thank the authors for resolving in version 14 many issues that we had r= aised in the past regarding the K-codes, timing constraints, and specifically the operation of the NSP.<= /p>

 

Major Issues:

1.  &nb= sp; T= he draft refers in several places to the “reliable transport… p= rovided by MPLS-TE/MPLS-TP”. This terminology is inappropriate in the IETF where &quo= t;reliable" is used in a completely different sense, especially as the= draft compares the FC PW to transport of FC over TCP/IP that has been defined in RFC 3821.  The problem is = aggravated by the fact that the common PWE3 technique that allows detection= of lost and/or reordered PW packets (sequencing) is intentionally disabled (in Section 3.1 the draft state= s that the sequence number MUST be set to 0 by the sender and MUST be ignor= ed by the receiver). We have discussed t= his point with the one of the draft editors and obtained agreement that the usage of the term “reliable&= #8221; in this context is inappropriate. We highly recommend that the authors mod= ify the present text by replacing the term “relia= ble” with the actual expectations regarding delivery of the FC= PW packets (low drop rate, low chance of reordering). We also suggest addi= ng text on the handling of lost, re-ordered and duplicate FC PW packets to the Applicability secti= on.

2.    The draft pro= poses usage of “sub-rating” of FC Primitive Sequences, without = specifying acceptable sub-rating factors and without explaining whether these values require coordination between the two PEs. One of the = document editors has assured us that coordination is not required, but that= there are limitations on sub-rating in order to avoid timeouts. We strongl= y suggest that the authors add some text explaining this, providing guidance regarding suitable sub-rating val= ues.

3.  &nb= sp; The draft req= uests IANA to reserve four Interface Parameter sub-TLV values for functiona= lity that has been dropped from the draft after having been rejected by the PWE3 WG, in order to accommodate the possibili= ty of this functionality being reintroduced at some future time. This reque= st would be justified if there were multiple deployed pre-standard implemen= tations supporting this functionality (as was the case for the “Martini mode” of the Frame Relay PWs). As far as we know, there is at most only one such pre-standard implementation. We suggest that the responsible = AD decide on the proper course of action.

Minor Issues:

  1. In contrast to the rest of= the PWE3 documents, a dedicated Native Service Processor (NSP) block is ma= ndatory for implementing (and even understanding) the draft. We would like to thank the authors for = the much improved explanation of this NSP in the present version. However, = some of the functionality of the NSP operation is similar to functions that are not considered NSP functions in other PWE3 encapsula= tion documents e.g.:
    • Suppression o= f idle codes (in contrast, suppression of idle ATM cells is not= considered as an NSP function in RFC 4717)
    • Removal= of 8b/10b encoding (in contrast, the same operation is not considered as a= n NSP function in RFC 4448).

We believe that a n= ote should be added clarifying this point.

2.    T= he draft refers to MTU issues associated with the FC PW, but does= not state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, &= #8230;, or MUST NOT be included in the Label Mapping message during the FC PW setup. Since all FC interfaces have the same MTU, this parameter is not really needed during the setup. = We suggest that the authors explicitly indicate that the Interface MTU para= meter MUST NOT appear in the FC PW setup protocol exchange. (Aside: This is based on experience wit= h RFC 5287 where the fact that it was not specified that the Interface MTU = parameter MUST NOT appear in the TDM PW setup eventually led to interoperab= ility issues). We have sent the authors proposed text to deal with this issue.

3.    The draft def= ines that the CRC of the FC frames MUST always be included in the PW encaps= ulation. However, its handling differs from the handling of FCS per RFC 4720; in particular, FC frames received with CRC e= rrors must be transmitted over the PW. It would be nice to explicitly note = this difference, and for the signaling procedure to explicitly specify non-= usage of the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the authors proposed text to dea= l with this issue.

 

Regards,

     Y(J)S and Sash= a

 

Hi all,

I confirm that the text of the review sent by Yaakov rep= resents our common position.

I hope that this unorthodox approach to reviewing= the draft is acceptable.

 

Regards,

     Sasha

 

From: Yaakov Ste= in [mailto:yaakov_s@rad.com]
Sent: Sunday, February 20, 2011 4:2= 4 PM
To: rtg-ads@tools.ietf.org; draft-ietf-pwer-fc-encap-14.all@= tools.ietf.org
Cc: rtg-dir@ietf.org; pwe3@ietf.org; Alexander Vai= nshtein
Subject: RtgDir review: draft-ietf-pwer-fc-encap-14.txt

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto'>To:

·         = rtg-ads@tools.ietf.org

Cc:

·         rtg-dir@ietf.org

    <= li class=3DMsoNormal style=3D'color:black;mso-margin-top-alt:auto;mso-margi= n-bottom-alt:auto;mso-list:l5 level1 lfo2'>pwe3@ie= tf.org

Subject:

·=      =     RtgDir review: draft-ietf-pwer-fc-encap-14.txt

 

Hello,

We (Yaakov and Sasha) have been selected as the Routing Directorat= e reviewers for this draft. The Routing Directorate seeks to review all rou= ting or routing-related drafts as they pass through IETF last call and IESG= review. 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

Althoug= h 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 comm= ents that you receive, and strive to resolve them through discussion or by = updating the draft.

Document: draft-ietf-pw= er-fc-encap-14.txt
Reviewers: Alexander (“Sasha”) Vainshtei= n and Yaakov (Jonathan) Stein
Review Date:  2011/02/20
IETF LC = End Date:
Intended Status: Standard Track

<= span style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif";color:blac= k'> 

Summary:

We have some concerns about th= is document that we believe need to be addressed before publication.

Comments:

=
  1. The two of us (Sasha and Yaa= kov) have decided to write a single joint review, in order to reduce contra= dictory recommendations.
  2. In = order to further reduce turnaround time, we have taken the slightly unortho= dox approach of holding direct talks with one of the draft editors (David B= lack). As will be seen in the following, this approach has proven to be hig= hly productive.
  3. The draft in= cludes multiple references to Fibre Channel (FC) standards, which hinder co= mprehension for those not expert in the technology. The status of these ref= erences is also somewhat problematic:<= /span> <= o:p>
    • [FC-BB-6] (Normative) triggers circular normative referenci= ng between IETF and T11:

<= span style=3D'font-size:9.5pt;font-family:Symbol;color:black'>·&= nbsp;        It is currently a T11 working document waiti= ng for approval.

= ·   &nbs= p;     <= /span>It can only be accessed by the interested IETF participants by se= nding a direct request to David Black, who is both co-editor of this draft = and T11's official liaison to the IETF.

·         It uses this draft as a Normative referenc= e and hence will be approved by T11 only after an RFC number has been assig= ned to this draft.

·   &n= bsp;     = As this is not intended to be a downref, the re= sponsible AD will need to explain the situation to the RFC Editor once the dra= ft is approved for publication.

    • [FC-FS-2] (No= rmative) is an approved T11 standard that can be accessed by interested IET= F participants by sending a request to David Black (david.black@em= c.com) in his official capacity as T11 liaison to IETF. <= span style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif"'>
    • [FC-SP]  is listed a= s a Normative reference. However, it describes the FC  Security Protoc= ol that is, according to the draft, transparent to the FC PW. Hence it make= s sense to redefine it as an Informational reference.
    • All these references are flagged as wa= rnings by the latest IETF nits tool.

4.    We would like to thank the authors for resolving in version 14 man= y issues that we had raised in the past regarding the K-codes, timing const= raints, and specifically the operation of the NSP.

 

<= b>Major Issues:

1. =    The = draft refers in several places to the “reliable transport… prov= ided by MPLS-TE/MPLS-TP”. This terminology is inappropriate in the IET= F where "reliable" is used in a completely different sense, espec= ially as the draft compares the FC PW to transp= ort of FC over TCP/IP that has been defined in RFC 3821.  The problem = is aggravated by the fact that the common PWE3 technique that allows detect= ion of lost and/or reordered PW packets (sequencing) is intentionally disabled (in Section 3.1 the draft states tha= t the sequence number MUST be set to 0 by the sender and MUST be ignored by= the receiver). We have discussed this p= oint with the one of the draft editors and obtained agreement that the usag= e of the term “reliable” in this context is inappropriate. We highly recommend that the authors modify = the present text by replacing the term &= #8220;reliable” with the actual expectations regarding deliver= y of the FC PW packets (low drop rate, low chance of reordering). We also s= uggest adding text on the handling of lost, re-= ordered and duplicate FC PW packets to the Applicability section.

2.    The draft proposes usage of “sub-rating” of FC Primi= tive Sequences, without specifying acceptable sub-rating factors and withou= t explaining whether these values require coordination between the two PEs.= One of the document editors has assured us that coordination is not requir= ed, but that there are limitations on sub-rating in order to avoid timeouts= . We strongly suggest that the authors add some text explaining this, provi= ding guidance regarding suitable sub-rating values.

3.    The draft requests IANA to reserve four Interface Parameter sub-TLV values= for functionality that has been dropped from the draft after having been r= ejected by the PWE3 WG, in order to accommodate the possibility of this fun= ctionality being reintroduced at some future time. This request would be ju= stified if there were multiple deployed pre-standard implementations suppor= ting this functionality (as was the case for the “Martini mode”= of the Frame Relay PWs). As far as we k= now, there is at most only one such pre-= standard implementation. We suggest that the responsible AD decide on the p= roper course of action.

Minor I= ssues:

  1. In contrast to the rest of the PWE3 documents, a dedicated = Native Service Processor (NSP) block is mandatory for implementing (and eve= n understanding) the draft. We would like to thank the auth= ors for the much improved explanation of this NSP in the present version. H= owever, some of the functionality of the NSP operation is similar to functi= ons that are not considered NSP functions in other PWE3 encapsulation docum= ents e.g.:
    • Suppression of idle codes (in contrast, suppression of idle ATM= cells is not considered as an NSP function in RFC 4717) <= /li>
    • Removal of = 8b/10b encoding (in contrast, the same operation is not considered as an NS= P function in RFC 4448).

We believe that a note should be added clarifying t= his point.

2.    The draft refers to MTU issues associated wit= h the FC PW, but does not state whether the MTU interface parameter sub-TLV= MUST, SHOULD, MAY, …, or MUST NOT be included in the Label Mapping m= essage during the FC PW setup. Since all FC interfaces have the same MTU, this parameter is not really needed during the s= etup. We suggest that the authors explicitly indicate that the Interface MT= U parameter MUST NOT appear in the FC PW setup protocol exchange. (<= i>Aside: This is based on experience with RFC 5287 where the fact that it w= as not specified that the Interface MTU parameter MUST NOT appear in the TD= M PW setup eventually led to interoperability issues). We have sent the= authors proposed text to deal with this issue.

3. = ;   The draft defin= es that the CRC of the FC frames MUST always be included in the PW encapsul= ation. However, its handling differs from the handling of FCS per RFC 4720;= in particular, FC frames received with CRC errors must be transmitted over= the PW. It would be nice to explicitly note this difference, and for the s= ignaling procedure to explicitly specify non-usage of the FCS Retention Ind= icator Interface Parameter sub-TLV. We have sent the authors proposed text = to deal with this issue.

=  

Regards,

     Y(J)S and Sasha

 

= --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_--