From zhangfatai@huawei.com Mon Sep 2 02:26:55 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7411E81D1; Mon, 2 Sep 2013 02:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp3A4DF+dXnz; Mon, 2 Sep 2013 02:26:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A57011E8125; Mon, 2 Sep 2013 02:26:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY76901; Mon, 02 Sep 2013 09:26:39 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Sep 2013 10:26:03 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Sep 2013 10:26:11 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.152]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0146.000; Mon, 2 Sep 2013 17:26:03 +0800 From: Fatai Zhang To: Tomonori TAKEDA , "rtg-ads@tools.ietf.org" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.txt Thread-Index: AQHOpURpDaQpK4moZEOR/PL1Q09//JmyLenw Date: Mon, 2 Sep 2013 09:26:01 +0000 Message-ID: References: <201308300547.r7U5l5MQ014566@imail2.m.ecl.ntt.co.jp> In-Reply-To: <201308300547.r7U5l5MQ014566@imail2.m.ecl.ntt.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 02 Sep 2013 02:53:56 -0700 Cc: "rtg-dir@ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org" Subject: Re: [RTG-DIR] [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:26:55 -0000 Hi Tomonori, Thanks for your comments. I think the changes should be very minor per your comments, and I would def= er to ADs/WG chairs to decide if we need update the draft before publicatio= n.=20 See more for your points. Point 1: Yes, this is specific to OTN and please see the [OTN-OSPF] draft f= or the priority information.=20 Point 2: Yes, it refers to ODU multiplexing. The legacy OTN here includes [= RFC4328] and Pre-[RFC4328] (but there is no IETF draft for Pre-[RFC4328]), = and Pre-[RFC4328] could not support multiplexing hierarchy, so I think we c= an change the original text to "since multiplexing hierarchy may not be sup= ported by the legacy OTN ". Point 3: I think we can remove "Note that..." sentence because it is about = solution specific, which has been described in solution drafts. All nits should be accepted.=20 Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of T= omonori TAKEDA Sent: Friday, August 30, 2013 1:47 PM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709-framework= .all@tools.ietf.org Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.tx= t Hello,=20 I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see=20 http://www.ietf.org/iesg/directorate/routing.html=20 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.=20 Document: draft-ietf-ccamp-gmpls-g709-framework-14.txt =20 Reviewer: Tomonori Takeda Review Date: 30 August 2013=20 IETF LC End Date: 02 September 2013=20 Intended Status: Informational=20 o Summary:=20 This document describes framework for GMPLS/PCE control of OTN and impacts = on GMPLS/PCE protocols. Overview of OTN is mentioned, which is helpful to u= nderstand the document. o Comments:=20 I have some minor concerns about this document that I think should be resol= ved before publication. (I think these are mostly related to clarification questions.) o Major Issues:=20 No major issues found.=20 o Minor Issues:=20 1) In Section 5.3., it says the following requirement for GMPLS routing. - Support different priorities for resource reservation I think this is a valid requirement, but I do not think this is specific to= OTN. Does this imply the need for protocol extensions or just the usage of proto= cols? 2) Section 5.4., it says: Furthermore, since multiplexing hierarchy was not allowed=20 by the legacy OTN referenced by [RFC4328], .... By reading RFC4328 section 2, it refers to ODU multiplexing. Am I missing s= omething? 3) In Section 5.5., it says. Note that this case is supported by the procedures defined in [RFC3473] as a different Switching Capability/Type value is=20 used for the different control plane versions. I am not sure which part of RFC3473 metions such procedures. Could you plea= se point it? o Nits:=20 Section 4.1 s/Lo ODU/LO ODU/=20 Section 4.1 s/substitute/substituted Section 5.6 s/section 5.2.1/section 5.2 Thanks, Tomonori _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lizho.jin@gmail.com Mon Sep 2 09:24:05 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C1B11E8102; Mon, 2 Sep 2013 09:24:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrr8shpRJ5wy; Mon, 2 Sep 2013 09:24:04 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D481A11E8101; Mon, 2 Sep 2013 09:24:03 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id k8so2141677qcq.14 for ; Mon, 02 Sep 2013 09:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jrNazSix7Gi/uz7Usa8XfCBPB6R7qQbQcajEjCBv+gc=; b=AziIs7vsUI0IEbfj2ulKt7n5oqS9WfzoAGui4I6PaCJk9fWLusaChiQRVVAEnIyIu5 s0bdxt7Erk/L1CdjTWHCEQAD5Mm1sz9v6WFxMOxQtN62oQa6JEl91/ZWXdPT6yntD/KU kSs8TaZBzTPge4AHuIlx7fEbKJwM3qyKN3oC5DqfCRa0wbcRvV8tmTskB0QuDBkIptcc 5zkoTjY8Ia/dbJyr+sd8tvxYCCzScJYPaSMgv+w5sIBAtIU1Tu4ZNhdsgw00ZaHa9jRA OZBD2i+kbm2m4e3Rh8saeU7pKmfFoupeX55CpSILDLCx49t7ESfGDsyHBHdbROJDklpL 0lvg== MIME-Version: 1.0 X-Received: by 10.229.129.3 with SMTP id m3mr30219917qcs.13.1378139042053; Mon, 02 Sep 2013 09:24:02 -0700 (PDT) Received: by 10.49.3.226 with HTTP; Mon, 2 Sep 2013 09:24:01 -0700 (PDT) Date: Tue, 3 Sep 2013 00:24:01 +0800 Message-ID: From: Lizhong Jin To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1132e5ac0da45e04e569006d Cc: rtg-dir@ietf.org, draft-ietf-mpls-targeted-mldp.all@tools.ietf.org, mpls@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 16:24:05 -0000 --001a1132e5ac0da45e04e569006d Content-Type: text/plain; charset=ISO-8859-1 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-mpls-targeted-mldp-03.txt Reviewer: Lizhong Jin Review Date: 2 September 2013 IETF LC End Date: 05 September 2013 Intended Status: Standards Track o Summary: I have some minor concerns about this document that I think should be resolved before publication. o Comments: This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. It is clearly written. I only have some minor issues which need to be clarified. o Major Issues: No major issues found. o Minor Issues: 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to define the specification, not overview introduction. It is suggest to have a separate section to describe the introduction. 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allows this, please check. 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there is targeted LDP session between U and D? This is possible in some deployments. 4. Section 1.2.1, line 188, is there a precedence among the different methods, and the operator could define the precedence? 5. Section 3, line 356, how does D know to send label request, not label mapping message? Multicast or unicast from U to D is determined by U, and D could not get this information automatically. Then is there any static configuration required here? 6. Section 3, line 358, the label request messages mentioned in the text should be upstream label request message. It is better to explicit to say this. 7. Section 3, line 382, it is said: While it is possible to do this, it is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I do not quite understand this statement. This specification does not describe the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the upstream label uniqueness among different upstream nodes. It should be caution to have this recommendations here. Regards Lizhong --001a1132e5ac0da45e04e569006d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts 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 a= bout 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 discuss= ion or by updating the draft.

Document: draft-ietf-mpls-targeted-mldp-03.txt
Reviewer: Lizhong Ji= n
Review Date:=A02=A0September 2013
IETF LC End Date: 05 September 20= 13
Intended Status: Standards Track
=A0
o Summary:
I have some minor concerns about this document that I th= ink should be resolved before publication.
=A0
o Comments:
This document provides the specification for using the LDP P2MP/MP2MP = extensions over a Targeted LDP session. It is clearly written. I only have = some minor issues which need to be clarified.

o Major Issues:
No major issues found.
=A0
o Minor Issues:
=A0
1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to=A0defi= ne the specification, not overview introduction. It is suggest to have a se= parate section to describe the introduction.
2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not [R= FC6388] (same for [LDP-UP]). I am not quite sure IETF template allows this,= please check.
3. Section 1.2.1, line 176, what if there is IGP neighbors, and there = is targeted LDP session between U and D? This is possible in some deploymen= ts.
4. Section 1.2.1, line 188, is there a precedence among the different = methods, and the operator could define the precedence?
5. Section 3, line 356, how does D know to send label request, not lab= el mapping message? Multicast or unicast from U to D is determined by U, an= d D could not get this information automatically. Then is there any static = configuration required here?
6. Section 3, line 358, the label request messages mentioned in the te= xt should be upstream=A0label request message. It is better to explicit to = say this.
7. Section 3, line 382, it is said: While it is possible to do this, i= t is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I d= o not quite understand this statement. This specification does not describe= the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my vie= w, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the upstream = label uniqueness among different upstream nodes. It=A0should be caution to = have this recommendations here.
=A0
Regards
Lizhong
=A0
=A0
=A0
--001a1132e5ac0da45e04e569006d-- From cpignata@cisco.com Mon Sep 2 16:53:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25A21F9A97; Mon, 2 Sep 2013 16:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb-TiJz2fChv; Mon, 2 Sep 2013 16:53:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5D27421F9D69; Mon, 2 Sep 2013 16:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17677; q=dns/txt; s=iport; t=1378166004; x=1379375604; h=from:to:cc:subject:date:message-id:mime-version; bh=BEc0wRfGceVV4JR1QCUyJPE72uom5qY9DByLAsrig+Y=; b=Cwv4lJw7dJwDRVL3nuSdLv1lts7iwh/IPowzTeDBz3jVmRIymUUDRH2u 4TfN/E2KNcDqP9k7YprNsOrS5iwL0zHgftMw5aB3ygw5H18CgUecvj+Io T6wG7oL+yTU5Lu95r0FXyWFgnAGNcpNJCs+bSVKqUx4kq5g/Bmewkkh5a o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADckJVKtJV2Z/2dsb2JhbABagwc1UcBxgSkWdIImAQRHIAsHEgEcDlYnBA4NAQUNh2cMqySNeY9FIBECgyKBAAOQI4EumAqDIIIq X-IronPort-AV: E=Sophos;i="4.89,1009,1367971200"; d="asc'?scan'208";a="251704132" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 02 Sep 2013 23:53:23 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r82NrNO6022451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Sep 2013 23:53:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 2 Sep 2013 18:53:23 -0500 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOqDebrKO6OJQx3ESbiGHTNfRsNw== Date: Mon, 2 Sep 2013 23:53:22 +0000 Message-ID: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.105] Content-Type: multipart/signed; boundary="Apple-Mail=_5E1126B0-F232-4E09-8450-6BC2363C7268"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 23:53:29 -0000 --Apple-Mail=_5E1126B0-F232-4E09-8450-6BC2363C7268 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Reviewer: Carlos Pignataro Review Date: 02 September 2013 IETF LC End Date: 04 September 2013 Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend that the = Routing ADs discuss these issues further with the authors. Comments: This document defines useful functionality. It is also generally well = written and is fairly detailed and comprehensive. At the same time, for a set of extensions that attempts to provide more = determinism in a failure detection protocol, I believe there is still = significant ambiguity in a few underspecified elements and behaviors. Although I have marked a number of "major" issues, some of them should = be relatively easy to fix. Others, however, pose somewhat fundamental = questions. I hope these review comments are clear and useful! Major Issues: The first major issue that I would like to have discussed is the usage = of these extensions for BFD for MPLS bootstrapping. The Abstract in this = document sets to prove that the extensions thereby defined can be used = for BFD for MPLS bootstrapping. However, I believe that the document is = underdefined to make that claim in the Abstract. There is somewhat of a contradiction in that, to make BFD for MPLS = bootstrapping using these extensions work, specific protocol definitions = (i.e., 2119 language in the BFD for MPLS bootstrapping state machine) = need to take place in BFD, as per draft-chen-mpls-bfd-enhancement. = However, that document is only an Informative reference in this = document. It appears to me that, without = draft-chen-mpls-bfd-enhancement, the claim of the Abstract cannot be = fulfilled. By way of process, I also believe this might have not been = tested with the BFD working group. In any case, the only mention of BFD for MPLS bootstrapping in this = document is by passing as an example in Section 3.3.1. Due to all of = these reasons, I believe this doc should remove the goal of BFD = improvements al together or majorly qualify and downgrade the usage with = BFD. A second major issue is a question: Given how RFC 4379 defines the reply = mode 4 ("Reply via application level control channel"). Given a = bidirectional LSP. Doesn't using GAL+GACh and Reply Mode #4 solve this = whole problem? Why is that one not discussed? Basically, RFC 4379 uses = RFC 5085 as the reference example of reply mode #4. Since RFC 5586 = generalizes the VCCV associated channel to LSPs, then we have a generic = control channel to be used with reply mode #4. Also, what's the relationship to RFC 6426 and TLV 16? Another return = path? A third major issue has to do with the treatment of Inter-AS scenarios = in this draft. In Sections 2.1 and 2.2, this draft is implicitly = presented as a solution for MPLS Echo in "inter-domain LSPs" and = "inter-domain/inter-AS LSP". The problems in these cases are more = convoluted than what this draft describes, and includes lack of = addressing context and initiator address unknown (not only that the IP = Router Alert label might not work in the boundary). I believe that this = draft should not call those cases since are not solved by the addition = of a new reply mode. A fourth major issue has to do with the use of IP Path versus LSP Path, = as per a number of Minor issues described below that, together, amount = to a major. See minor issues section. A fifth major issue concerns itself with ECMP upon return. Saying that = the response should be sent over the LSP with target FEC Stack of LDP = IPv4 prefix of 192.0.2.27/32 is not enough, as there are potentially = multiple paths throughout. I believe this topic should be discussed. In = the Echo direction, this is solved with the Downstream Mapping = mechanics. That is overkill for the response, but again, multi path can = give false negatives the same deeming the whole solution unusable (since = at the end it cannot provide the prescriptiveness). A last major issue concerns itself with Security considerations. Using = these extensions, a node can instruct another node to send replies out = of any LSP, including LSPs that do not go back to the source. Further, = an attacker can send MPLS Echo nodes to many nodes vectoring responses = to a node target of a DDoS attack. The security considerations briefly = touches this point and says that "the return path LSP MUST have = destination to the same node where the forward path is from". However, = it is not clear how a node can actually evaluate and actually verify and = enforce this MUST. It is quite possible that this check is not possible = to make. Minor Issues: Does this document update RFC 4379? 1. Introduction The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document. I am note sure if this is major or minor -- but separating traceroute = mode as out of scope seems like a huge gap. Are there specific issues = with using these extensions in traceroute mode? The last hop of a = traceroute is equivalent to a ping -- can these extensions be used = there? The defined extensions can also be utilized for creating a single Bidirectional Forwarding Detection (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a pair of unidirectional LSPs (one for each direction). For BFD for bidirectional LSPs, there is no need to use LSP Ping = bootstrapping, since the context of the session can be directly gleaned = as defined in RFC 5885. In other words, single-hop BFD initialization is = enough -- why would someone want to use bootstrapping with LSP Ping, and = then specific extensions, when the context of the BFD discriminators is = understood from the label (again, as per RFC 5885)? In this document, the term bidirectional LSP includes the co-routed bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction), and which are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and MPLS Transport Profile (MPLS-TP) scenarios. Two key questions: 1. What about Pseudowires? 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP = control plane (to run LSP Ping)? 2. Problem Statements and Solution Overview MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data path failures in all MPLS LSPs, and was originally designed for unidirectional LSPs. Where does RFC4379 limits its scope to unidirectional LSPs? And in any case, the use modes 2 or 3 cannot guarantee the delivery of echo responses through an IP network that is fundamentally unreliable. The failure to deliver echo response messages can lead to false negatives making it appear that the LSP has failed. Allowing the ingress LSR to control the path used for echo reply messages, and in particular forcing those messages to use an LSP rather than being sent through the IP network, enables an operator to apply an extra level of deterministic process to the LSP Ping test. These two paragraphs seems to show a gross misconception on how reply = works. =46rom 4379, the reply with mode #1 does not need to be sent over = IP without MPLS. It can very well be sent over an LSP. In fact, given = the right source IP address in the LSP Ping Echo, the right return LSP = can be chosen. This needs to be better explained so as not to "hype" the = solution presented in the document. 3. Extensions In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class (TC) [RFC5462] TLV, are defined in this document.=20 Given that the "Reply Path TLV" specifies an LSP and not a Path, I = strongly suggest the TLV be renamed to more specifically describe its = functionality. 0x0004 The specified Reply Path was not found, the echo reply was sent via other LSP 0x0005 The specified Reply Path was not found, the echo reply was sent via IP path It is not clear what an IP path is, when sending an LSP Echo response as = an IP datagram can be sent labeled as an LSP. Also, I assume these are = without Router Alert, right? A (Alternative path): the egress LSR MUST select a non-default path as the return path. This is very useful when reverse default path problems are suspected which can be confirmed when the echo reply is forced to follow a non-default return path. Here, the default path refers to the path that the egress LSR will use to send the echo reply when the return path is not explicitly specified as defined in this document. If A bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored. Do all implementations understand the same thing as "Default"? This = seems underspecified. Also, say that an LSP Ping is sent with source IP address as 192.0.2.1 = over an LSP. A "default" return LSP is perhaps an LSP where 192.0.2.1/32 = points to. How would a non-default be in this case? Send it to a wrong = LSR? What should responding router choose in this case? How can it = choose a non-default without the specification of an actual LSP? B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP. If B bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored. Is this default or non-default when this TLV is not used (pre-this = spec)? 3.2. Reply Path (RP) TLV When reply mode (!=3D 5) and Reply Path TLV is received, which takes = precedence and what is the procedure? 3.3. Reply Path sub-TLVs In addition, this document defines three new sub-TLVs: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. It is not clear why these are specified. The text does not seem to = explain the need, nor why these do not need to be specified for the TLV = 1.=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero |S|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Further, "primary" and "secondary" are not defined. Which specifications = explains what is a primary and a secondary? 3.3.3. Static Tunnel sub-TLV Again, why is this not specified for the Echo as well? 4. Theory of Operation When the echo reply message is intended to test the return MPLS LSP path(when the A bit is not set in the previous received echo request message), the destination IP address of the echo reply message MUST never be used in a forwarding decision. Is this really the meaning of the "A-bit"? To avoid this possibility the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost label MUST be set to 255.=20 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be = 0:0:0:0:0:FFFF:7F00/104 or 0:0:0:0:0:FFFF:127.0.0.0/104 Of course when the echo reply message is not intended for testing the specified return path (when the A bit is set in the previous received echo request message) , the procedures defined in [RFC4379] (the destination IP address is copied from the source IP address) apply unchanged. Does this mean that "Alternate" and "Non Default" are actually to follow = the *Default* procedures from RFC 4379? 4.3. Sending an Echo Reply and the IP TTL MUST be set to 1, the TTL in the outermost label MUST be set to 255.=20 Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv? 6.4. Reply Path Return Code There seems to be a contradiction in this: 0x0006-0xfffb Not allocated, allocated via Standard Action 0xfffc-0xffff Experimental Use The range of 0x0008-0xfffb is not allocated and reserved for future extensions and is allocated via Standard Action, the range of 0xfffc- 0xffff is for Experimental Use. Overall -- what is the interaction with draft-ietf-mpls-remote-lsp-ping? = Note also that document specifies a reply mode with the same value of = "5". Also, this document does not seem to define backward compatibility = considerations. What happens if a pre-specification router receives a = Reply Mode #5? The generic behavior of RFC 4379 is to respond with a = generic "malformed echo" error -- should there be a sub-code for Unknown = reply mode -- in which case it's a bit ironic to reply by some other = mode -- to signal the specific issue for future reply codes? A final minor issue: this specification defines a new behavior for an = echo reply in which the Echo Reply message is destined to a loopback IP = Address. If the return path is broken, a middle router will think the = packet is destined to itself (because of the loopback) -- the behavior = in this case is undefined and can result in funny behaviors, for example = an ICMP port unreachable sent to the source or weirder. A last minor issue relates the IANA requests -- section 6.2 is already = fairly complex, yet it does not speak to the following: What happens = when sub-TLVs for TLV1 are defined? What is checked to make sure that = this new sub-TLV applies to TLV21, and how? Does this update IANA = allocations for RFC 4379? Also, a sub-TLV with sub-Type 16384 can be = assigned to TLV1 with specification required, but needs Standards action = for TLV 21? And from which of these eight ranges are sub-Types of = Section 6.2.1 assigned, and why are not applicable to TLV Type 1 and = Type 16? I would include in the IANA instructions details within TLV 1 about the = changes and "directly copied" to TLV21. Nits:=20 Abstract This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. The abstract is key in that its legibility sets for the whole document. = These same comments apply to the Introduction. First, to be consistent with RFC4379, I'd qualify adding "=85extensions = to the *data-plane* failure-detection protocol=85". Second, this is a very long sentence that reads better split in two: = "known as "LSP Ping". These extensions allow selection of the" The Reply via Specified Path mode is used to request that the remote LSR receiving the LSP Ping echo request message sends back the echo reply message along the specified paths carried in the Reply Path TLV. There is no such a thing as "LSP Ping echo request message" in RFC 4379. = The same happens throughout the document, and should be fixed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Path TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Path return code | Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These are "Flags" (plural). 0x0002 One or more of the sub-TLVs in Reply Path TLV was not understood s/was/were/ Additionally, idnits 2.12.17 finds the following: ** There is 1 instance of too long lines in the document, the longest = one being 1 character in excess of 72. =3D=3D Unused Reference: 'RFC6426' is defined on line 873, but no = explicit reference was found in the text I hope these are clear and useful! Thank you, Carlos Pignataro. --Apple-Mail=_5E1126B0-F232-4E09-8450-6BC2363C7268 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIlJPIACgkQtfDPGTp3USweFgCglCAMlmLJiSvyMRZ9l5ZdNVSa 9cUAoKUUAaxsFAU5B2+9dr/vVgjR7ZG3 =8oYp -----END PGP SIGNATURE----- --Apple-Mail=_5E1126B0-F232-4E09-8450-6BC2363C7268-- From mach.chen@huawei.com Tue Sep 3 20:53:31 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8660821E8167; Tue, 3 Sep 2013 20:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfG0EUX8oU87; Tue, 3 Sep 2013 20:53:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90321E8166; Tue, 3 Sep 2013 20:53:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWW50754; Wed, 04 Sep 2013 03:53:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 04:52:38 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 04:52:51 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.175]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Wed, 4 Sep 2013 11:52:43 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , "" Thread-Topic: RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOqDebrKO6OJQx3ESbiGHTNfRsN5mzQBzQ Date: Wed, 4 Sep 2013 03:52:43 +0000 Message-ID: References: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 03 Sep 2013 20:56:24 -0700 Cc: "" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 03:53:32 -0000 Hi Carlos, Many thanks for your detailed review and comments! Please my reply inline... > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Carlos Pignataro (cpignata) > Sent: Tuesday, September 03, 2013 7:53 AM > To: > Cc: ; > draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org; mpls@i= etf.org > Subject: [mpls] RtgDir review: > draft-ietf-mpls-return-path-specified-lsp-ping-12.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, and sometimes on special req= uest. > The purpose of the review is to provide assistance to the Routing ADs. Fo= r 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-mpls-return-path-specified-lsp-ping-12.txt > Reviewer: Carlos Pignataro > Review Date: 02 September 2013 > IETF LC End Date: 04 September 2013 > Intended Status: Proposed Standard >=20 > Summary: >=20 > I have significant concerns about this document and recommend that the Ro= uting > ADs discuss these issues further with the authors. >=20 > Comments: >=20 > This document defines useful functionality. It is also generally well wri= tten and is > fairly detailed and comprehensive. >=20 > At the same time, for a set of extensions that attempts to provide more > determinism in a failure detection protocol, I believe there is still sig= nificant > ambiguity in a few underspecified elements and behaviors. >=20 > Although I have marked a number of "major" issues, some of them should be > relatively easy to fix. Others, however, pose somewhat fundamental questi= ons. >=20 > I hope these review comments are clear and useful! >=20 >=20 > Major Issues: >=20 > The first major issue that I would like to have discussed is the usage of= these > extensions for BFD for MPLS bootstrapping. The Abstract in this document = sets to > prove that the extensions thereby defined can be used for BFD for MPLS > bootstrapping. However, I believe that the document is underdefined to ma= ke > that claim in the Abstract. >=20 > There is somewhat of a contradiction in that, to make BFD for MPLS > bootstrapping using these extensions work, specific protocol definitions = (i.e., > 2119 language in the BFD for MPLS bootstrapping state machine) need to ta= ke > place in BFD, as per draft-chen-mpls-bfd-enhancement. However, that > document is only an Informative reference in this document. It appears to= me > that, without draft-chen-mpls-bfd-enhancement, the claim of the Abstract > cannot be fulfilled. By way of process, I also believe this might have no= t been > tested with the BFD working group. >=20 > In any case, the only mention of BFD for MPLS bootstrapping in this docum= ent is > by passing as an example in Section 3.3.1. Due to all of these reasons, I= believe > this doc should remove the goal of BFD improvements al together or majorl= y > qualify and downgrade the usage with BFD. We are fine to remove the goal of BFD from the Abstract and Introduction se= ction.=20 >=20 > A second major issue is a question: Given how RFC 4379 defines the reply = mode 4 > ("Reply via application level control channel"). Given a bidirectional LS= P. Doesn't > using GAL+GACh and Reply Mode #4 solve this whole problem? Why is that on= e > not discussed? Basically, RFC 4379 uses RFC 5085 as the reference example= of > reply mode #4. Since RFC 5586 generalizes the VCCV associated channel to = LSPs, > then we have a generic control channel to be used with reply mode #4. To solve which problem you refer to here? ( By using the Reply Mode 4 and G= AL+GACh) >=20 > Also, what's the relationship to RFC 6426 and TLV 16? Another return path= ? TLV 16 is designed to verify the return path, but the return path selection= is still a local decision of the egress (in RFC6426, it states the return = path MUST be the reverse LSP of a bidirectional LSP) as defined in RFC4379.= The Reply Path TLV is designed to specify the return path, they are differ= ent and there is no relationship to TLV 16. >=20 > A third major issue has to do with the treatment of Inter-AS scenarios in= this draft. > In Sections 2.1 and 2.2, this draft is implicitly presented as a solution= for MPLS > Echo in "inter-domain LSPs" and "inter-domain/inter-AS LSP". The problems= in > these cases are more convoluted than what this draft describes, and inclu= des lack > of addressing context and initiator address unknown (not only that the IP= Router > Alert label might not work in the boundary). I believe that this draft sh= ould not > call those cases since are not solved by the addition of a new reply mode= . Section 2.1, bullet 2 talks about inter-AS; for inter-as LSP, with RFC4379,= in order to check the reverse LSP, the LSP Ping has to be initiated from t= he other end reside in other AS, this may not possible since the other AS m= ay belong to different administrative domain. With this new reply mode, an = LSP Ping could detect both the forward and reverse LSP of the bidirectional= LSP, or an LSP Ping detects the forward direction of an LSP and the revers= e direction of another LSP ( for example, using a deemed workable LSP to se= nd echo request, and specifying a suspect LSP as the return path hence to t= est it) , the operator does not need to initiate two LSP Pings from both en= ds separately. The new reply mode is mainly designed to achieve this.=20 Section 2.2 mainly talks about the "Limitations of Existing Mechanisms for = Handling Unreliable Return Paths", mention inter-domain is to explain one o= f the cases where the echo reply cannot be delivered back even with router = alert mode.=20 As the draft states, it provides an extra level of deterministic process to= deliver the echo reply back by specifying a more deterministic path (e.g.,= TE LSP). =20 "Allowing the ingress LSR to control the path used for echo reply messages, and in particular forcing those messages to use an LSP rather than being sent through the IP network, enables an operator to apply an extra level of deterministic process to the LSP Ping test." >=20 > A fourth major issue has to do with the use of IP Path versus LSP Path, a= s per a > number of Minor issues described below that, together, amount to a major.= See > minor issues section. Please see my relies in Minor issues part. >=20 > A fifth major issue concerns itself with ECMP upon return. Saying that th= e > response should be sent over the LSP with target FEC Stack of LDP IPv4 pr= efix of > 192.0.2.27/32 is not enough, as there are potentially multiple paths thro= ughout. I > believe this topic should be discussed. In the Echo direction, this is so= lved with > the Downstream Mapping mechanics. That is overkill for the response, but = again, > multi path can give false negatives the same deeming the whole solution > unusable (since at the end it cannot provide the prescriptiveness). Indeed, Downstream Mapping mechanics is overkill here for response.=20 Section 4.3 Sending an Echo Reply Second Para talks about how to set the destination address that will affect= the ECMP path selection. How about this? Old: "When the echo reply is intended to test the return path (the A is not set in the previous received echo request), the destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this problem, the IP destination address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set to 1, the TTL in the outermost label MUST be set to 255." New=20 "When the echo reply is intended to test the return path (the A is not set in the previous received echo request), the destination IP address of the echo reply message MUST never be used in a forwarding decision. *In addition, there may be ECMP paths for a specified FEC, in case always select a failure path*, the IP destination address of the echo reply message that is transmitted along the specified return path MUST be set to an address *(random chosen)* from the range 127/8 fo= r IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set to 1, the TTL in the outermost label MUST be set to 255." >=20 > A last major issue concerns itself with Security considerations. Using th= ese > extensions, a node can instruct another node to send replies out of any L= SP, > including LSPs that do not go back to the source. Further, an attacker ca= n send > MPLS Echo nodes to many nodes vectoring responses to a node target of a D= DoS > attack. The security considerations briefly touches this point and says t= hat "the > return path LSP MUST have destination to the same node where the forward > path is from". However, it is not clear how a node can actually evaluate = and > actually verify and enforce this MUST. It is quite possible that this che= ck is not > possible to make. Since the echo request carries the source address/identifier of the ingress= /initiator, when received a specified return path, the return path should a= lso have the destination address/identifier point to the ingress/initiator = , with these two addresses/identifiers, the egress should be able to perfor= m the above check IMHO.=20 >=20 >=20 > Minor Issues: >=20 > Does this document update RFC 4379? >=20 > 1. Introduction >=20 > The procedures defined in this document > currently only apply to "ping" mode. The "traceroute" mode is out of > scope for this document. >=20 > I am note sure if this is major or minor -- but separating traceroute mod= e as out > of scope seems like a huge gap. Are there specific issues with using thes= e > extensions in traceroute mode? The last hop of a traceroute is equivalent= to a > ping -- can these extensions be used there? The procedures can easily apply to traceroute when only tracing the forward= direction; but for reverse direction, the procedures will become complicat= e, something like proxy traceroute, the egress will be the proxy, more cons= ideration and mechanisms are needed. Thus, we leave it future study. >=20 >=20 > The defined extensions can also be > utilized for creating a single Bidirectional Forwarding Detection > (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a > pair of unidirectional LSPs (one for each direction). >=20 > For BFD for bidirectional LSPs, there is no need to use LSP Ping bootstra= pping, > since the context of the session can be directly gleaned as defined in RF= C 5885. In > other words, single-hop BFD initialization is enough -- why would someone= want > to use bootstrapping with LSP Ping, and then specific extensions, when th= e > context of the BFD discriminators is understood from the label (again, as= per RFC > 5885)? As described in RFC5884, Section 5 " A BFD session may be established for a FEC associated with an MPLS LSP. As described above, in the case of PHP or when the egress LSR distributes an explicit null label to the penultimate hop router, or next-hop label allocation, the BFD Control packet received by the egress LSR does not contain sufficient information to associate it with a BFD session." Even for bidirectional LSP, only if there are PHP, explicit null label, or = next-hop label allocation situations, LSP Ping bootstrapping is needed IMHO= .=20 >=20 > In this document, the term bidirectional LSP includes the co-routed > bidirectional LSP defined in [RFC3945] and the associated > bidirectional LSP that is constructed from a pair of unidirectional > LSPs (one for each direction), and which are associated with one > another at the LSP's ingress/egress points [RFC5654]. The mechanisms > defined in this document can apply to both IP/MPLS and MPLS Transport > Profile (MPLS-TP) scenarios. >=20 > Two key questions: > 1. What about Pseudowires? Theoretically, PW can be treated as an associated bidirectional LSP, so it'= s possible to specify another PW other than the reverse PW. > 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP contro= l > plane (to run LSP Ping)? For MPLS-TP (non-control plane), the only difference is the encapsulation, = the GAL+GACh can also be used as defined RFC6426. Maybe we could add some t= ext to state this. >=20 >=20 > 2. Problem Statements and Solution Overview >=20 > MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data > path failures in all MPLS LSPs, and was originally designed for > unidirectional LSPs. >=20 > Where does RFC4379 limits its scope to unidirectional LSPs? RFC 4379 does not explicitly state this, but from procedures it defined, si= nce the echo rely does not carry any FEC stack information, the verificatio= n is only for forward direction, not for reverse direction.=20 Maybe it more proper to state: "...and was mainly designed for unidirection= al LSPs." >=20 > And in any case, the use modes 2 or 3 cannot guarantee the delivery > of echo responses through an IP network that is fundamentally > unreliable. The failure to deliver echo response messages can lead > to false negatives making it appear that the LSP has failed. >=20 > Allowing the ingress LSR to control the path used for echo reply > messages, and in particular forcing those messages to use an LSP > rather than being sent through the IP network, enables an operator to > apply an extra level of deterministic process to the LSP Ping test. >=20 > These two paragraphs seems to show a gross misconception on how reply wor= ks. > From 4379, the reply with mode #1 does not need to be sent over IP withou= t > MPLS. It can very well be sent over an LSP. In fact, given the right sour= ce IP > address in the LSP Ping Echo, the right return LSP can be chosen. This ne= eds to be > better explained so as not to "hype" the solution presented in the docume= nt. We will consider this, it's great if you have some suggested text.=20 >=20 > 3. Extensions >=20 > In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class > (TC) [RFC5462] TLV, are defined in this document. >=20 > Given that the "Reply Path TLV" specifies an LSP and not a Path, I strong= ly suggest > the TLV be renamed to more specifically describe its functionality. In Section 3.3.1-3, it defines tunnel (not a particular LSP) to be as the r= eturn path, so the return path includes LSP and Tunnel; it seems "Path" is = more suitable. >=20 >=20 > 0x0004 The specified Reply Path was not found, the echo > reply was sent via other LSP > 0x0005 The specified Reply Path was not found, the echo > reply was sent via IP path >=20 > It is not clear what an IP path is, when sending an LSP Echo response as = an IP > datagram can be sent labeled as an LSP. Also, I assume these are without = Router > Alert, right? Yes. Here the IP path refers to pure IP forwarding path, not the LSP. >=20 > A (Alternative path): the egress LSR MUST select a non-default path > as the return path. This is very useful when reverse default path > problems are suspected which can be confirmed when the echo reply is > forced to follow a non-default return path. Here, the default path > refers to the path that the egress LSR will use to send the echo > reply when the return path is not explicitly specified as defined in > this document. If A bit is set, there is no need to carry any > specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD > be ignored. >=20 > Do all implementations understand the same thing as "Default"? This seems > underspecified. The draft defines: "the default path refers to the path that the egress LSR will use to send = the echo reply when the return path is not explicitly specified as defined = in this document."=20 I think this definition is straightforward and clear:-) Do you have any sug= gestion? >=20 > Also, say that an LSP Ping is sent with source IP address as 192.0.2.1 ov= er an LSP. A > "default" return LSP is perhaps an LSP where 192.0.2.1/32 points to. How = would a > non-default be in this case? Send it to a wrong LSR? What should respondi= ng > router choose in this case? How can it choose a non-default without the > specification of an actual LSP? Of cause, send to wrong LSR is allowable, for this case, the non-default pa= th could be either an IP path or other LSPs (for example, a TE LSP). If the= re is non-default path, return code 0x0003 should be returned: 0x0003 The echo reply was sent successfully using the specified Reply Path >=20 > B (Bidirectional): the return path is required to follow the reverse > direction of the tested bidirectional LSP. If B bit is set, there is > no need to carry any specific reply path sub-TLVs, and when received, > the sub-TLVs SHOULD be ignored. >=20 > Is this default or non-default when this TLV is not used (pre-this spec)? It's implementation depend. RFC 4379 does not specify this;RFC6426 specifies the echo reply MUST be alo= ng the reverse direction, but have to use GAL+GACh (application channel mod= e).=20 >=20 > 3.2. Reply Path (RP) TLV >=20 > When reply mode (!=3D 5) and Reply Path TLV is received, which takes prec= edence > and what is the procedure? Per RFC4379, Malformed Error should be returned.=20 >=20 >=20 > 3.3. Reply Path sub-TLVs >=20 > In addition, this document defines three new sub-TLVs: IPv4 RSVP > Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. >=20 > It is not clear why these are specified. The text does not seem to explai= n the > need, nor why these do not need to be specified for the TLV 1. Sometime, using tunnel other that specific LSP is more suitable, for exampl= e, when performing a long time ping for an TE LSP (as stated in RFC5884, se= ction 3.2), it could avoid the impact of the changes of LSP ID (e.g.,Make-B= efore-Break, LSP ID may change, but tunnel ID will not). Another usage is f= or BFD, it is stated in Section 3.3.1. How about this:(new text is in **) The IPv4 RSVP Tunnel sub-TLV is used in the Reply Path TLV to allow the operator to specify a more generic tunnel FEC other than a particular LSP as the return path. According to the bits set in the Flag field, the egress LSR will then choose an LSP from the specified Tunnel as the return path. One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD session on an MPLS Tunnel that has primary and secondary LSPs, especially when Make-Before-Break (MBB) is deployed. The usage is discussed in Section 4.2 of [I-D.chen-mpls-bfd-enhancement]. *Another usage is when LSP Ping is used to periodically verify the control plane against the data plane [RF= C5884], using Tunnel other than particular LSP can avoid the impact of LSP chang= ing when MBB is deployed.* =20 =20 It may apply to TLV 1, if the WG agree, I am fine to apply this to TLV 1. T= hen the IANA allocation could be easier.=20 >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MUST be zero |S|P| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Further, "primary" and "secondary" are not defined. Which specifications > explains what is a primary and a secondary? RFC4872 Section 4.2.1 defines the primary and secondary, we will add a refe= rence there.=20 >=20 > 3.3.3. Static Tunnel sub-TLV >=20 > Again, why is this not specified for the Echo as well? Same as above. >=20 > 4. Theory of Operation >=20 > When the echo reply message is intended to test the return MPLS LSP > path(when the A bit is not set in the previous received echo request > message), the destination IP address of the echo reply message MUST > never be used in a forwarding decision. >=20 > Is this really the meaning of the "A-bit"? The "A-bit" is as it defined in 3.2, here we just borrow the "A-bit" to ind= icate whether need to test the return path. The logic here is that since th= e "A-bit" is to choose an alternate path hence to deliver the echo reply ba= ck, test the return path is normally not intention here. And the path could= either IP or MPLS path, verify the IP path does not make sense.=20 >=20 > To avoid this possibility > the destination IP address of the echo reply message that is > transmitted along the specified return path MUST be set to numbers > from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and > the IP TTL MUST be set 1, and the TTL in the outermost label MUST be > set to 255. >=20 > 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be 0:0:0:0:0:FFFF:7F00= /104 or > 0:0:0:0:0:FFFF:127.0.0.0/104 OK. >=20 > Of course when the echo reply message is not intended > for testing the specified return path (when the A bit is set in the > previous received echo request message) , the procedures defined in > [RFC4379] (the destination IP address is copied from the source IP > address) apply unchanged. >=20 > Does this mean that "Alternate" and "Non Default" are actually to follow = the > *Default* procedures from RFC 4379? Yes.=20 >=20 > 4.3. Sending an Echo Reply >=20 > and the IP TTL MUST be set to 1, the > TTL in the outermost label MUST be set to 255. >=20 > Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv? Since the draft-ietf-mpls-lsp-ping-ttl-tlv(segment ping) only apply to MS-P= W and co-routed bidirectional LSP, hence to make sure the TLL is determined= . Specify a different return path other than the reverse path is not workab= le. IMHO, this draft may not apply to the segment ping. >=20 > 6.4. Reply Path Return Code >=20 > There seems to be a contradiction in this: >=20 > 0x0006-0xfffb Not allocated, allocated via Standard Action > 0xfffc-0xffff Experimental Use >=20 > The range of 0x0008-0xfffb is not allocated and reserved for future > extensions and is allocated via Standard Action, the range of 0xfffc- > 0xffff is for Experimental Use. >=20 > Overall -- what is the interaction with draft-ietf-mpls-remote-lsp-ping? = Note also > that document specifies a reply mode with the same value of "5". There is no interaction with draft-ietf-mpls-remote-lsp-ping yet. I think t= his is the result that defining a particular value without the confirmation= of IANA other than using TBD. I believe that this issue will be solved by = authors, chairs and IANA. >=20 > Also, this document does not seem to define backward compatibility > considerations. What happens if a pre-specification router receives a Rep= ly Mode > #5? The generic behavior of RFC 4379 is to respond with a generic "malfor= med > echo" error -- should there be a sub-code for Unknown reply mode -- in wh= ich > case it's a bit ironic to reply by some other mode -- to signal the speci= fic issue for > future reply codes? "malformed echo" error should be the right choice, a sub-code for unknown r= eply is better, but the RFC4379 does not specify this behavior.=20 >=20 > A final minor issue: this specification defines a new behavior for an ech= o reply in > which the Echo Reply message is destined to a loopback IP Address. If the= return > path is broken, a middle router will think the packet is destined to itse= lf (because > of the loopback) -- the behavior in this case is undefined and can result= in funny > behaviors, for example an ICMP port unreachable sent to the source or wei= rder. The same situation will happen for Echo Request:-). Section 2.1 of RFC4379= says: "RFC 1122 allocates the 127/8 as "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded." So, I think this issue is already solved by RFC4379.=20 >=20 > A last minor issue relates the IANA requests -- section 6.2 is already fa= irly > complex, yet it does not speak to the following: What happens when sub-TL= Vs > for TLV1 are defined? What is checked to make sure that this new sub-TLV = applies > to TLV21, and how? The same as TLV 16, TLV 21 will reuse all existing and future defined sub-T= LVs. Roni also raised this question, we proposed the following text: " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are=20 copied from the assignments made for TLV Type 1 and kept the same as that for TLV Type 1. All sub-TLVs in these ranges (include existing and future defined) defined for TLV Type 1 apply to TLV Type 21.=20 Assignments of sub-..." > Does this update IANA allocations for RFC 4379? Also, a > sub-TLV with sub-Type 16384 can be assigned to TLV1 with specification re= quired, > but needs Standards action for TLV 21? And from which of these eight rang= es are > sub-Types of Section 6.2.1 assigned, and why are not applicable to TLV Ty= pe 1 and > Type 16? The LSP Ping IANA structure has been updated, please refer to: https://www.= iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtm= l#downstream-mapping. It specifies the 16384-31743 "Specification Required, Experimental RFC need= ed", and this draft is the Experimental "RFC". >=20 > I would include in the IANA instructions details within TLV 1 about the c= hanges > and "directly copied" to TLV21. I am fine with this. >=20 >=20 > Nits: >=20 > Abstract >=20 > This document defines extensions to the failure-detection protocol > for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > known as "LSP Ping" that allow selection of the LSP to use for the > echo reply return path. >=20 > The abstract is key in that its legibility sets for the whole document. T= hese same > comments apply to the Introduction. >=20 > First, to be consistent with RFC4379, I'd qualify adding "...extensions t= o the > *data-plane* failure-detection protocol...". >=20 > Second, this is a very long sentence that reads better split in two: "kno= wn as "LSP > Ping". These extensions allow selection of the" OK, thanks for the suggestion. >=20 >=20 > The Reply via Specified Path mode is used to request that the remote > LSR receiving the LSP Ping echo request message sends back the echo > reply message along the specified paths carried in the Reply Path > TLV. >=20 > There is no such a thing as "LSP Ping echo request message" in RFC 4379. = The > same happens throughout the document, and should be fixed. OK, will look through the document to make them consistent with RFC 4379. >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reply Path TLV Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reply Path return code | Flag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > These are "Flags" (plural). OK. >=20 > 0x0002 One or more of the sub-TLVs in Reply Path TLV > was not understood >=20 > s/was/were/ OK. >=20 >=20 > Additionally, idnits 2.12.17 finds the following: >=20 > ** There is 1 instance of too long lines in the document, the longest o= ne > being 1 character in excess of 72. OK. >=20 > =3D=3D Unused Reference: 'RFC6426' is defined on line 873, but no expli= cit > reference was found in the text OK. >=20 >=20 > I hope these are clear and useful! Very useful! Many thanks Mach >=20 > Thank you, >=20 > Carlos Pignataro. From leeyoung@huawei.com Wed Sep 4 09:27:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B512321F9A17; Wed, 4 Sep 2013 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRm3558UTBkV; Wed, 4 Sep 2013 09:27:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5EEE21F99F3; Wed, 4 Sep 2013 09:27:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB05601; Wed, 04 Sep 2013 16:27:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 17:27:25 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 17:27:39 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.204]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 09:27:13 -0700 From: Leeyoung To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt Thread-Index: Ac6pi5m1FJsl/u7ZR96gB1yUrsn1pg== Date: Wed, 4 Sep 2013 16:27:11 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291BA6E8@dfweml511-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.174.74] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E17291BA6E8dfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-dir@ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-signaling-g709v3.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:27:49 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E17291BA6E8dfweml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t 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-ccamp-gmpls-signaling-g709v3-11.txt Reviewer: Young Lee Review Date: 4 September 2013 IETF LC End Date: Intended Status: Standard Track Summary: This document is basically ready for publication, but has some minor issues= and nits that should be considered prior to publication. Comments: This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for "the evolving G.709 OTN control" which may b= e referred to as "G709v3" in the document to be aligned with the draft name= (draft-ietf-ccamp-gmpls-singaling-g709v3). Major Issues: No major issues found. Minor Issues: Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT is= sue. Section 4: The clause "via 1.25G TS granularity, 2.5G TS granularity or any= one of them (i.e., TS granularity Auto-Negotiation is enabled)" is a bit c= onfusing. Section 5: The first paragraph can be clearer by associating the objects me= ntioned with the Path or Resv Message. Please consider to change to: "The t= raffic Parameters for OTN-TDM capable Switching Type are carried in the OTN= -TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in= the Resv Message." Section 6.2: "In such case" is not clear. Is that meant: "When the TPN was = not assigned by the ingress node"? Section 8, the fourth bullet mentioned of "Ingress" nodes may select the pr= ocedure either from RFC4328 or this document. How about the egress nodes? I= s it assumed to follow what the ingress has chosen? (Just a clarification q= uestion) Nits: Section 3, when the term "Tributary Slot" is first used (i.e,. A new Tribut= ary Slot granularity (i.e., 1.25Gbps) is also described...), please add the= abbreviation. Section 3 s/legacy interfaces/the legacy interfaces/ Section 4 s/[RFC4328] extends/[RFC4328] extended/ Section 5: Spell NVC. Section 5.2: For Table 2, align the column dividers Section 5.2 s/MUST equal to/MUST equal/ or /MUST be equal to/ Section 6.2: delete "out" before "outgoing" in the first sentence of the th= ird paragraph. Section 6.2: s/accordingly to/according to/ (6th paragraph) Thanks. Young --_000_7AEB3D6833318045B4AE71C2C87E8E17291BA6E8dfweml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts 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, pl= ease 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 discuss= ion or by updating the draft.

Document: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt
Reviewer: Young Lee
Review Date: 4 September 2013
IETF LC End Date: 
Intended Status: Standard Track

Summary:
This document is basically ready for publicatio= n, but has some minor issues and nits that should be considered prior to pu= blication.

Comments:
This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for “the evolving G.709 OTN control”= which may be referred to as “G709v3” in the document to be aligned with the draft name (draft-ietf-ccamp-gmpls-singali= ng-g709v3).

Major Issues:
No major issues found.

Minor Issues:
Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT issue.

Section 4: The clause “via 1.25G TS granularity, 2.5G TS granulari= ty or any one of them (i.e., TS granularity Auto-Negotiation is enabled)= 221; is a bit confusing.

Section 5: The first paragraph can be clearer by associating the objects= mentioned with the Path or Resv Message. Please consider to change to: = 220;The traffic Parameters for OTN-TDM capable Switching Type are carried i= n the OTN-TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in the Resv Message.” =

Section 6.2: “In such case” is not clear. Is that meant: = 220;When the TPN was not assigned by the ingress node”?

Section 8, the fourth bullet mentioned of “Ingress” nodes ma= y select the procedure either from RFC4328 or this document. How about the = egress nodes? Is it assumed to follow what the ingress has chosen? (Just a = clarification question)

Nits:

Section 3, when the term “Tributary Slot” is first used (i.e= ,. A new Tributary Slot granularity (i.e., 1.25Gbps) is also described̷= 0;), please add the abbreviation.

Section 3
s/legacy interfaces/the legacy interfaces/

Section 4

s/[RFC4328] extends/[RFC4328]= extended/

Section 5: Spell NVC.

Section 5.2: For Table 2, align the column dividers

Section 5.2

s/MUST equal to/MUST equal/ o= r /MUST be equal to/

Section 6.2: delete “out” before “outgoing” in t= he first sentence of the third paragraph.

Section 6.2: s/accordingly to/according to/ (6th paragraph)

Thanks.

Young

 

--_000_7AEB3D6833318045B4AE71C2C87E8E17291BA6E8dfweml511mbschi_-- From erosen@cisco.com Wed Sep 4 09:09:21 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8756F21F8FF5; Wed, 4 Sep 2013 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ct1nNrDPeqS; Wed, 4 Sep 2013 09:09:16 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 377C121F8C93; Wed, 4 Sep 2013 09:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1378310955; x=1379520555; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-transfer-encoding:date:message-id; bh=P2rbgUY+UPhWCHGsci6MzPEYLjioao2nU5n3GEWTctw=; b=YfPGEG7plGol6t7Y0imVbMm7mFdkakAxceneo4TcsLAPFV2exWwzeDxc vAXKH9MLG3t6oAaTh6MP3cbSr7qtA5FMaEg9hkbVha0s00yFVEHte5roI rik10mpKO1ayZtoeu/B3hDd4fcUHojZyi2UIz+3jywIcl2LjnFtsJ2dUC A=; X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="88456374" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Sep 2013 16:09:09 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r84G97Mo018457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 16:09:08 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r84G97vh031220; Wed, 4 Sep 2013 12:09:07 -0400 From: Eric Rosen To: Lizhong Jin In-reply-to: Your message of Tue, 03 Sep 2013 00:24:01 +0800. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Sep 2013 12:09:07 -0400 Message-ID: <31219.1378310947@erosen-linux> X-Mailman-Approved-At: Wed, 04 Sep 2013 16:50:48 -0700 Cc: rtg-dir@ietf.org, draft-ietf-mpls-targeted-mldp.all@tools.ietf.org, mpls@ietf.org, erosen@cisco.com, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:09:21 -0000 Thank you for taking a close look at this draft again. > 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to=A0define = the > specification, not overview introduction. It is suggest to have a separate > section to describe the introduction. Fair enough. Sections 1.2, 1.3, and 1.4 will be "promoted" to sections 2, 3, and 4 respectively, leaving the old section 1.1 as the introduction. > 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not > [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allows > this, please check This style of cross-reference is very commonly used. > 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there is > targeted LDP session between U and D? This is possible in some > deployments. The cited text: - U is the "BGP next hop" on D's path to R, where U and D are not IGP neighbors, and where there is a Targeted LDP session between U and D. In this case, we allow D to select U as the "upstream LSR" for . suggests that the targeted session cannot be used in this case. Probably it is best to leave the handling of this case as a choice for the SP, so I will change it to ""where U and D are not necessarily IGP neighbors". This would allow the targeted session to be used if so chosen. > 4. Section 1.2.1, line 188, is there a precedence among the different > methods, and the operator could define the precedence? I think it is best to just say (as it does) "the method is chosen by provisioning". Whether it is possible for an operator to configure an ordered list of methods to try is a local matter (i.e., doesn't have to be specified in the RFC). > 5. Section 3, line 356, how does D know to send label request, not label > mapping message? Multicast or unicast from U to D is determined by U, and > D could not get this information automatically. Then is there any static > configuration required here? As stated in section 1.3 (section 3 in the next revision): "the choice between unicast replication and multicast tunneling is determined by provisioning, or by other methods that are outside the scope of this specification. It is presupposed that all nodes will have a priori knowledge of whether to use unicast replication or to use multicast tunneling. If the latter, it is presupposed that all nodes will have a priori knowledge of the type of multicast tunneling to use." > 6. Section 3, line 358, the label request messages mentioned in the text > should be upstream=A0label request message. It is better to explicit to s= ay > this. =20=20=20 I'll add that D1 and D2 follow the procedures of Section 4 of [LDP-UP] when requesting U to assign the label. > 7. Section 3, line 382, it is said: While it is possible to do this, it is > highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I do > not quite understand this statement. This specification does not describe > the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my > view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the > upstream label uniqueness among different upstream nodes. It should be > caution to have this recommendations here. Perhaps it would be best just to say: Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are outside the scope of this document.=20 From adrian@olddog.co.uk Wed Sep 4 17:48:14 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E611E8150; Wed, 4 Sep 2013 17:48:14 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVXLHk2eVyLl; Wed, 4 Sep 2013 17:48:04 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2E521F92E7; Wed, 4 Sep 2013 17:47:49 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r850lfx0011934; Thu, 5 Sep 2013 01:47:41 +0100 Received: from 950129200 (98-28-103-175.static.broadbandsolutions.com.au [175.103.28.98] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r850lZFj011909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Sep 2013 01:47:38 +0100 From: "Adrian Farrel" To: "'Fatai Zhang'" , "'Tomonori TAKEDA'" , References: <201308300547.r7U5l5MQ014566@imail2.m.ecl.ntt.co.jp> In-Reply-To: Date: Thu, 5 Sep 2013 01:47:36 +0100 Message-ID: <056801cea9d1$8750edd0$95f2c970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJVOU0nh0b9AhunXzrR9nq53jiIgKqENLkmKuoRyA= Content-Language: en-gb Cc: rtg-dir@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-gmpls-g709-framework.all@tools.ietf.org Subject: Re: [RTG-DIR] [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 00:48:14 -0000 Thanks Fatai and Tomonori. I have entered Tomonori's review into my comment in the IESG evaluation. We will pick them up after the rest of the IESG has done their review. Cheers, Adrian > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Fatai Zhang > Sent: 02 September 2013 10:26 > To: Tomonori TAKEDA; rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework.all@tools.ietf.org > Subject: Re: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework- > 14.txt > > Hi Tomonori, > > Thanks for your comments. > > I think the changes should be very minor per your comments, and I would defer > to ADs/WG chairs to decide if we need update the draft before publication. > > See more for your points. > > Point 1: Yes, this is specific to OTN and please see the [OTN-OSPF] draft for the > priority information. > > Point 2: Yes, it refers to ODU multiplexing. The legacy OTN here includes > [RFC4328] and Pre-[RFC4328] (but there is no IETF draft for Pre-[RFC4328]), and > Pre-[RFC4328] could not support multiplexing hierarchy, so I think we can change > the original text to "since multiplexing hierarchy may not be supported by the > legacy OTN ". > > Point 3: I think we can remove "Note that..." sentence because it is about > solution specific, which has been described in solution drafts. > > All nits should be accepted. > > > Best Regards > > Fatai > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Tomonori TAKEDA > Sent: Friday, August 30, 2013 1:47 PM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-g709- > framework.all@tools.ietf.org > Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-g709-framework-14.txt > > 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-gmpls-g709-framework-14.txt > Reviewer: Tomonori Takeda > Review Date: 30 August 2013 > IETF LC End Date: 02 September 2013 > Intended Status: Informational > > o Summary: > This document describes framework for GMPLS/PCE control of OTN and impacts > on GMPLS/PCE protocols. Overview of OTN is mentioned, which is helpful to > understand the document. > > o Comments: > I have some minor concerns about this document that I think should be resolved > before publication. > (I think these are mostly related to clarification questions.) > > o Major Issues: > No major issues found. > > o Minor Issues: > > 1) In Section 5.3., it says the following requirement for GMPLS routing. > - Support different priorities for resource reservation > > I think this is a valid requirement, but I do not think this is specific to OTN. > Does this imply the need for protocol extensions or just the usage of protocols? > > 2) Section 5.4., it says: > > Furthermore, since multiplexing hierarchy was not allowed > by the legacy OTN referenced by [RFC4328], .... > > By reading RFC4328 section 2, it refers to ODU multiplexing. Am I missing > something? > > 3) In Section 5.5., it says. > > Note that this case is supported by the procedures defined in > [RFC3473] as a different Switching Capability/Type value is > used for the different control plane versions. > > I am not sure which part of RFC3473 metions such procedures. Could you please > point it? > > o Nits: > Section 4.1 > s/Lo ODU/LO ODU/ > > Section 4.1 > s/substitute/substituted > > Section 5.6 > s/section 5.2.1/section 5.2 > > > Thanks, > Tomonori > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lizho.jin@gmail.com Wed Sep 4 19:06:33 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB711E8237; Wed, 4 Sep 2013 19:06:33 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk0RWSUMX4Bi; Wed, 4 Sep 2013 19:06:32 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0711E8155; Wed, 4 Sep 2013 19:06:32 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so642128qeb.2 for ; Wed, 04 Sep 2013 19:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OuuLprFv+Vx8NujXMpcj2Qs1eOll5oRoSdPMToKkRkg=; b=ETApS8iHdc7qMIPDvScSWudzi9Yy3bECoqWWD8RE3BLuoR5SRidIp9ayixviJWA9vi pJsqiV1WPad26R20sQKkQ29R/EKzg+pMDfzzJ+KYcJSrojQ887gsrZOowoWZXnfkR+EU IzKj4aLFqZ+wmzXfdj1m3R/Rfadp7qTv76ZTKIOo2dZ9JeUN0YhQ8eWRW5Qhh5ZRJpnw CPzvUhr8Pw1FkGi5jmc8viwMjiuCsCqfMVg0yXwexzz6J+RLZKuVwLWKGXgH/ZiiKhT9 5uujw5SXQtR0cJgKbfsJkK+Mb8LCWQicwbd40nmVW+sIU2tXQ2pEB1UVyr3W2pZipopq V97Q== MIME-Version: 1.0 X-Received: by 10.229.185.68 with SMTP id cn4mr7041215qcb.5.1378346791794; Wed, 04 Sep 2013 19:06:31 -0700 (PDT) Received: by 10.49.3.225 with HTTP; Wed, 4 Sep 2013 19:06:31 -0700 (PDT) Date: Thu, 5 Sep 2013 10:06:31 +0800 Message-ID: From: Lizhong Jin To: erosen@cisco.com Content-Type: multipart/alternative; boundary=001a1134a474e6fc9504e5995ee2 Cc: rtg-dir@ietf.org, draft-ietf-mpls-targeted-mldp.all@tools.ietf.org, "mpls@ietf.org" , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 02:06:33 -0000 --001a1134a474e6fc9504e5995ee2 Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, I am OK with all your reply and clarification. Thanks Lizhong On Thu, Sep 5, 2013 at 12:09 AM, Eric Rosen wrote: > Thank you for taking a close look at this draft again. > [Lizhong] my pleasure to reivew again. :) > > > 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to define > the > > specification, not overview introduction. It is suggest to have a > separate > > section to describe the introduction. > > Fair enough. Sections 1.2, 1.3, and 1.4 will be "promoted" to sections 2, > 3, and 4 respectively, leaving the old section 1.1 as the introduction. > [Lizhong] good. > > > 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not > > [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allows > > this, please check > > This style of cross-reference is very commonly used. > [Lizhong] I am OK now. > > > 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there is > > targeted LDP session between U and D? This is possible in some > > deployments. > > The cited text: > > - U is the "BGP next hop" on D's path to R, where U and D are not > IGP neighbors, and where there is a Targeted LDP session between > U and D. In this case, we allow D to select U as the "upstream > LSR" for . > > suggests that the targeted session cannot be used in this case. Probably > it > is best to leave the handling of this case as a choice for the SP, so I > will > change it to ""where U and D are not necessarily IGP neighbors". This > would > allow the targeted session to be used if so chosen. > [Lizhong] I am OK now. > > > 4. Section 1.2.1, line 188, is there a precedence among the different > > methods, and the operator could define the precedence? > > I think it is best to just say (as it does) "the method is chosen by > provisioning". Whether it is possible for an operator to configure an > ordered list of methods to try is a local matter (i.e., doesn't have to be > specified in the RFC). > [Lizhong] OK now. > > > 5. Section 3, line 356, how does D know to send label request, not label > > mapping message? Multicast or unicast from U to D is determined by U, and > > D could not get this information automatically. Then is there any static > > configuration required here? > > As stated in section 1.3 (section 3 in the next revision): > > "the choice between unicast replication and multicast tunneling is > determined by provisioning, or by other methods that are outside the > scope of this specification. It is presupposed that all nodes will have > a priori knowledge of whether to use unicast replication or to use > multicast tunneling. If the latter, it is presupposed that all nodes > will have a priori knowledge of the type of multicast tunneling to use." > [Lizhong] OK, I missed this. > > > 6. Section 3, line 358, the label request messages mentioned in the text > > should be upstream label request message. It is better to explicit to say > > this. > > I'll add that D1 and D2 follow the procedures of Section 4 of [LDP-UP] when > requesting U to assign the label. > [Lizhong] OK. > > > 7. Section 3, line 382, it is said: While it is possible to do this, it > is > > highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I do > > not quite understand this statement. This specification does not describe > > the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my > > view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the > > upstream label uniqueness among different upstream nodes. It should be > > caution to have this recommendations here. > > Perhaps it would be best just to say: > > Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are > outside the scope of this document. > > [Lizhong] Agree --001a1134a474e6fc9504e5995ee2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,
I am OK with all your reply and clarification.
=A0
Thanks
Lizhong

On Thu, Sep 5, 2013 at 12:0= 9 AM, Eric Rosen <erosen@cisco.com> wrote:
Thank you for taking a close look at this draft again.
[Lizhong] my pleasure to reivew again. :)=A0

> 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to=A0defi= ne the
> specification, not overview introduction. It is suggest to have a sepa= rate
> section to describe the introduction.

Fair enough. =A0Sections 1.2, 1.3, and 1.4 will be "promoted&quo= t; to sections 2,
3, and 4 respectively, leaving the old section 1.1 as the introduction.
=
[Lizhong] good.=A0

> 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not > [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allow= s
> this, please check

This style of cross-reference is very commonly used.
=
[Lizhong]=A0I am OK now.=A0

> 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there = is
> targeted LDP session between U and D? This is possible in some
> deployments.

The cited text:

=A0 =A0 =A0- U is the "BGP next hop" on D's path to R, where = U and D are not
=A0 =A0 =A0 =A0IGP neighbors, and where there is a Targeted LDP session bet= ween
=A0 =A0 =A0 =A0U and D. =A0In this case, we allow D to select U as the &quo= t;upstream
=A0 =A0 =A0 =A0LSR" for <R,X>.

suggests that the targeted session cannot be used in this case. =A0Probably= it
is best to leave the handling of this case as a choice for the SP, so I wil= l
change it to ""where U and D are not necessarily IGP neighbors&qu= ot;. =A0This would
allow the targeted session to be used if so chosen.
= =A0[Lizhong] I am OK now.

> 4. Section 1.2.1, line 188, is there a precedence among the different<= br> > methods, and the operator could define the precedence?

I think it is best to just say (as it does) "the method is chose= n by
provisioning". =A0Whether it is possible for an operator to configure = an
ordered list of methods to try is a local matter (i.e., doesn't have to= be
specified in the RFC).
[Lizhong]=A0OK now.=A0

> 5. Section 3, line 356, how does D know to send label request, not lab= el
> mapping message? Multicast or unicast from U to D is determined by U, = and
> D could not get this information automatically. Then is there any stat= ic
> configuration required here?

As stated in section 1.3 (section 3 in the next revision):

=A0 =A0"the choice between unicast replication and multicast tunneling= is
=A0 =A0determined by provisioning, or by other methods that are outside the=
=A0 =A0scope of this specification. =A0It is presupposed that all nodes wil= l have
=A0 =A0a priori knowledge of whether to use unicast replication or to use =A0 =A0multicast tunneling. =A0If the latter, it is presupposed that all no= des
=A0 =A0will have a priori knowledge of the type of multicast tunneling to u= se."
[Lizhong]=A0OK,=A0I missed this.=A0

> 6. Section 3, line 358, the label request messages mentioned in the te= xt
> should be upstream=A0label request message. It is better to explicit t= o say
> this.

I'll add that D1 and D2 follow the procedures of Section 4 of [LD= P-UP] when
requesting U to assign the label.
[Lizhong] OK.=A0=A0<= /div>

> 7. Section 3, line 382, it is said: While it is possible to do this, i= t is
> highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I d= o
> not quite understand this statement. This specification does not descr= ibe
> the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my=
> view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the > upstream label uniqueness among different upstream nodes. It should be=
> caution to have this recommendations here.

Perhaps it would be best just to say:

=A0 =A0 =A0Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs a= re
=A0 =A0 =A0outside the scope of this document.

[Lizhong]=A0Agree=A0

--001a1134a474e6fc9504e5995ee2-- From cpignata@cisco.com Thu Sep 5 06:25:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519F211E8197; Thu, 5 Sep 2013 06:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqefkqc-ZYPf; Thu, 5 Sep 2013 06:25:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0D74D11E8191; Thu, 5 Sep 2013 06:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85792; q=dns/txt; s=iport; t=1378387530; x=1379597130; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e3aKU9Z0URv85zdYQkGAuJq3m9RMZcWO2PYl9Ra8iPI=; b=eSSEFDOWUVMtSsTtGSCg6DwQj+YKk6pgMB/kLxJufcMdSbUllvlNjcM/ aTICNkuRWqpWv0pPaiesKhWDh8wS28I0vE7W542snkZwo6aglyFVXyYOx VB7ZWFwiVzu58ZleYrR0oBbQYBp4hJmCPaCzhgkoy5FswUUrG9Ql/0maA c=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEuFKFKtJXG+/2dsb2JhbABbgwc1UYYLuz2BKBZ0giQBAQEDARoBLCAFBgQDBQcEAgEIEQMBAQELFgEGBzIUCQgCBA4FCAEFDYdhBgysS41Ejy8gDQQHBoMXgQADhSCLA4EugkqPb4VRgTuBZYFqJBw X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="asc'?scan'208,217";a="255971981" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 05 Sep 2013 13:25:26 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r85DPPWh032174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 13:25:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 08:25:25 -0500 From: "Carlos Pignataro (cpignata)" To: Mach Chen Thread-Topic: RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOqSJv0nBIsFqmvEajNLMfUh+FNpm3eEyA Date: Thu, 5 Sep 2013 13:25:24 +0000 Message-ID: <95067C434CE250468B77282634C96ED325ECA2C8@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_3DFCD649-144E-4207-B729-5CCB0BABB91E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" , "mpls@ietf.org" , "" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:25:43 -0000 --Apple-Mail=_3DFCD649-144E-4207-B729-5CCB0BABB91E Content-Type: multipart/alternative; boundary="Apple-Mail=_371865F7-3995-4ABD-87B7-685CAC5AECB5" --Apple-Mail=_371865F7-3995-4ABD-87B7-685CAC5AECB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Mach, Many thanks for the prompt response! Glad these are useful -- please = find some follow-ups inline. On Sep 3, 2013, at 11:52 PM, Mach Chen wrote: > Hi Carlos, >=20 > Many thanks for your detailed review and comments! >=20 > Please my reply inline... >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> Carlos Pignataro (cpignata) >> Sent: Tuesday, September 03, 2013 7:53 AM >> To: >> Cc: ; >> draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org; = mpls@ietf.org >> Subject: [mpls] RtgDir review: >> draft-ietf-mpls-return-path-specified-lsp-ping-12.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, and sometimes on special = request. >> The purpose of the review is to provide assistance to the Routing = ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >>=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-mpls-return-path-specified-lsp-ping-12.txt >> Reviewer: Carlos Pignataro >> Review Date: 02 September 2013 >> IETF LC End Date: 04 September 2013 >> Intended Status: Proposed Standard >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the Routing >> ADs discuss these issues further with the authors. >>=20 >> Comments: >>=20 >> This document defines useful functionality. It is also generally well = written and is >> fairly detailed and comprehensive. >>=20 >> At the same time, for a set of extensions that attempts to provide = more >> determinism in a failure detection protocol, I believe there is still = significant >> ambiguity in a few underspecified elements and behaviors. >>=20 >> Although I have marked a number of "major" issues, some of them = should be >> relatively easy to fix. Others, however, pose somewhat fundamental = questions. >>=20 >> I hope these review comments are clear and useful! >>=20 >>=20 >> Major Issues: >>=20 >> The first major issue that I would like to have discussed is the = usage of these >> extensions for BFD for MPLS bootstrapping. The Abstract in this = document sets to >> prove that the extensions thereby defined can be used for BFD for = MPLS >> bootstrapping. However, I believe that the document is underdefined = to make >> that claim in the Abstract. >>=20 >> There is somewhat of a contradiction in that, to make BFD for MPLS >> bootstrapping using these extensions work, specific protocol = definitions (i.e., >> 2119 language in the BFD for MPLS bootstrapping state machine) need = to take >> place in BFD, as per draft-chen-mpls-bfd-enhancement. However, that >> document is only an Informative reference in this document. It = appears to me >> that, without draft-chen-mpls-bfd-enhancement, the claim of the = Abstract >> cannot be fulfilled. By way of process, I also believe this might = have not been >> tested with the BFD working group. >>=20 >> In any case, the only mention of BFD for MPLS bootstrapping in this = document is >> by passing as an example in Section 3.3.1. Due to all of these = reasons, I believe >> this doc should remove the goal of BFD improvements al together or = majorly >> qualify and downgrade the usage with BFD. >=20 > We are fine to remove the goal of BFD from the Abstract and = Introduction section.=20 OK. What about the mention in Section 3.3.1? It says "One usage of this = generic RSVP Tunnel sub-TLV is for bootstrapping BFD session..." but = this cannot be achieved without I-D.chen-mpls-bfd-enhancement. I think = this is not harmful but not too useful either. >=20 >>=20 >> A second major issue is a question: Given how RFC 4379 defines the = reply mode 4 >> ("Reply via application level control channel"). Given a = bidirectional LSP. Doesn't >> using GAL+GACh and Reply Mode #4 solve this whole problem? Why is = that one >> not discussed? Basically, RFC 4379 uses RFC 5085 as the reference = example of >> reply mode #4. Since RFC 5586 generalizes the VCCV associated channel = to LSPs, >> then we have a generic control channel to be used with reply mode #4. >=20 > To solve which problem you refer to here? ( By using the Reply Mode 4 = and GAL+GACh) I meant in a use similar to RFC 6426 actually. See below also. >=20 >>=20 >> Also, what's the relationship to RFC 6426 and TLV 16? Another return = path? >=20 > TLV 16 is designed to verify the return path, but the return path = selection is still a local decision of the egress (in RFC6426, it states = the return path MUST be the reverse LSP of a bidirectional LSP) as = defined in RFC4379. The Reply Path TLV is designed to specify the return = path, they are different and there is no relationship to TLV 16. >=20 I understand. My question is more related to the following scenarios: If an Echo request with the R global flag is set, and with TLV21 is = received, should the response include duplicate redundant information in = TLV16 and TLV21? If an Echo request with the R global flag is set, and with TLV21 = specifying a non-reverse LSP of a bidirectional LSP, should the = responder honor the MUST of RFC 6426 or the MUST of this document (since = they appear to be mutually contradicting)? Or more generically, should this document build from TLV16 or define its = own TLV? >>=20 >> A third major issue has to do with the treatment of Inter-AS = scenarios in this draft. >> In Sections 2.1 and 2.2, this draft is implicitly presented as a = solution for MPLS >> Echo in "inter-domain LSPs" and "inter-domain/inter-AS LSP". The = problems in >> these cases are more convoluted than what this draft describes, and = includes lack >> of addressing context and initiator address unknown (not only that = the IP Router >> Alert label might not work in the boundary). I believe that this = draft should not >> call those cases since are not solved by the addition of a new reply = mode. >=20 > Section 2.1, bullet 2 talks about inter-AS; for inter-as LSP, with = RFC4379, in order to check the reverse LSP, the LSP Ping has to be = initiated from the other end reside in other AS, this may not possible = since the other AS may belong to different administrative domain. With = this new reply mode, an LSP Ping could detect both the forward and = reverse LSP of the bidirectional LSP, or an LSP Ping detects the forward = direction of an LSP and the reverse direction of another LSP ( for = example, using a deemed workable LSP to send echo request, and = specifying a suspect LSP as the return path hence to test it) , the = operator does not need to initiate two LSP Pings from both ends = separately. The new reply mode is mainly designed to achieve this.=20 >=20 I am not totally clear on this scenario -- in an inter-as LSP, are you = saying that a return LSP is always known from the other AS? And is this somewhat of a proxy ping functionality? > Section 2.2 mainly talks about the "Limitations of Existing Mechanisms = for Handling Unreliable Return Paths", mention inter-domain is to = explain one of the cases where the echo reply cannot be delivered back = even with router alert mode.=20 > As the draft states, it provides an extra level of deterministic = process to deliver the echo reply back by specifying a more = deterministic path (e.g., TE LSP). >=20 > "Allowing the ingress LSR to control the path used for echo reply > messages, and in particular forcing those messages to use an LSP > rather than being sent through the IP network, enables an operator = to > apply an extra level of deterministic process to the LSP Ping test." >=20 >>=20 >> A fourth major issue has to do with the use of IP Path versus LSP = Path, as per a >> number of Minor issues described below that, together, amount to a = major. See >> minor issues section. >=20 > Please see my relies in Minor issues part. >=20 >>=20 >> A fifth major issue concerns itself with ECMP upon return. Saying = that the >> response should be sent over the LSP with target FEC Stack of LDP = IPv4 prefix of >> 192.0.2.27/32 is not enough, as there are potentially multiple paths = throughout. I >> believe this topic should be discussed. In the Echo direction, this = is solved with >> the Downstream Mapping mechanics. That is overkill for the response, = but again, >> multi path can give false negatives the same deeming the whole = solution >> unusable (since at the end it cannot provide the prescriptiveness). >=20 > Indeed, Downstream Mapping mechanics is overkill here for response.=20 >=20 > Section 4.3 Sending an Echo Reply >=20 > Second Para talks about how to set the destination address that will = affect the ECMP path selection. >=20 > How about this? >=20 > Old: > "When the echo reply is intended to test the return path (the A is not > set in the previous received echo request), the destination IP > address of the echo reply message MUST never be used in a forwarding > decision. To avoid this problem, the IP destination address of the > echo reply message that is transmitted along the specified return > path MUST be set to numbers from the range 127/8 for IPv4 or > 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set to 1, = the > TTL in the outermost label MUST be set to 255." >=20 > New=20 > "When the echo reply is intended to test the return path (the A is not > set in the previous received echo request), the destination IP > address of the echo reply message MUST never be used in a forwarding > decision. *In addition, there may be ECMP paths for a specified FEC, = in > case always select a failure path*, the IP destination address of = the > echo reply message that is transmitted along the specified return > path MUST be set to an address *(random chosen)* from the range = 127/8 for IPv4 or > 0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST be set to 1, = the > TTL in the outermost label MUST be set to 255." >=20 I do not think this addresses the issue. First, because that paragraph = covers the "A is not set" case, and this is when you are using a = destination of 127/8. With a destination of the source of the echo = message you can have the same phenomenon. If you send 4 LSP Pings and = the fact that they have different source UDP port result in the = responder choosing different ECMPs (for a *chosen* FEC), would that = confuse more? That should be covered outside of A-bit set vs. not set. >>=20 >> A last major issue concerns itself with Security considerations. = Using these >> extensions, a node can instruct another node to send replies out of = any LSP, >> including LSPs that do not go back to the source. Further, an = attacker can send >> MPLS Echo nodes to many nodes vectoring responses to a node target of = a DDoS >> attack. The security considerations briefly touches this point and = says that "the >> return path LSP MUST have destination to the same node where the = forward >> path is from". However, it is not clear how a node can actually = evaluate and >> actually verify and enforce this MUST. It is quite possible that this = check is not >> possible to make. >=20 > Since the echo request carries the source address/identifier of the = ingress/initiator, when received a specified return path, the return = path should also have the destination address/identifier point to the = ingress/initiator , with these two addresses/identifiers, the egress = should be able to perform the above check IMHO.=20 >=20 This seems to assume that the initiator has a single address. If for = troubleshooting purposes, an echo is sent with a source address of an = interface, and the return path specified is a prefix FEC with a = loopback/32 of the same node. How does the responder know it's the same = node and not a victim? >>=20 >>=20 >> Minor Issues: >>=20 >> Does this document update RFC 4379? >>=20 >> 1. Introduction >>=20 >> The procedures defined in this document >> currently only apply to "ping" mode. The "traceroute" mode is out = of >> scope for this document. >>=20 >> I am note sure if this is major or minor -- but separating traceroute = mode as out >> of scope seems like a huge gap. Are there specific issues with using = these >> extensions in traceroute mode? The last hop of a traceroute is = equivalent to a >> ping -- can these extensions be used there? >=20 > The procedures can easily apply to traceroute when only tracing the = forward direction; but for reverse direction, the procedures will become = complicate, something like proxy traceroute, the egress will be the = proxy, more consideration and mechanisms are needed. Thus, we leave it = future study. I did not mean to trace the reverse direction, but rather, perform a = regular LSP Trace but specifying the reply path. >=20 >>=20 >>=20 >> The defined extensions can also be >> utilized for creating a single Bidirectional Forwarding Detection >> (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a >> pair of unidirectional LSPs (one for each direction). >>=20 >> For BFD for bidirectional LSPs, there is no need to use LSP Ping = bootstrapping, >> since the context of the session can be directly gleaned as defined = in RFC 5885. In >> other words, single-hop BFD initialization is enough -- why would = someone want >> to use bootstrapping with LSP Ping, and then specific extensions, = when the >> context of the BFD discriminators is understood from the label = (again, as per RFC >> 5885)? >=20 > As described in RFC5884, Section 5 >=20 > " A BFD session may be established for a FEC associated with an MPLS > LSP. As described above, in the case of PHP or when the egress LSR > distributes an explicit null label to the penultimate hop router, or > next-hop label allocation, the BFD Control packet received by the > egress LSR does not contain sufficient information to associate it > with a BFD session." >=20 > Even for bidirectional LSP, only if there are PHP, explicit null = label, or next-hop label allocation situations, LSP Ping bootstrapping = is needed IMHO.=20 I am still concerned about this usage of this draft for BFD = bootstrapping. What is the LSP Ping bootstrap Echo's reply used for? =46rom RFC 5884 = (emphasis added by me with "*" markers): *On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR*, if the validation of the FEC in the LSP Ping Echo request message succeeds. This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. *The egress LSR MAY respond with an LSP Ping Echo reply message* that carries the local discriminator assigned by it = for the BFD session. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR. The responder responds with BFD and *MAY* respond with LSP Ping Echo = reply. What do you gain by using this new TLV in the bootstrap? You do = not gain anything on the LSP Ping bootstrap side of it. If, on the other hand, what you gain is that the BFD packets on the = return path need to be sent in this specified path, then that = functionality is underspecified and should not be called out as = something to do. Has the BFD WG looked into this? That needs BFD state = and protocol machinery changes, and not something to mention in passing. = There are levels of details, like if BFD stores this new return path and = then routing or forwarding changes, etc. And yes, if context is lost on receipt then you need to bootstrap and = not use 1hop initialization. Net-net: I do not see a good reason to keep any BFD mention, this should = be a separate piece of work and have BFD WG input. What do you think? >=20 >>=20 >> In this document, the term bidirectional LSP includes the co-routed >> bidirectional LSP defined in [RFC3945] and the associated >> bidirectional LSP that is constructed from a pair of unidirectional >> LSPs (one for each direction), and which are associated with one >> another at the LSP's ingress/egress points [RFC5654]. The = mechanisms >> defined in this document can apply to both IP/MPLS and MPLS = Transport >> Profile (MPLS-TP) scenarios. >>=20 >> Two key questions: >> 1. What about Pseudowires? >=20 > Theoretically, PW can be treated as an associated bidirectional LSP, = so it's possible to specify another PW other than the reverse PW. >=20 >> 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP = control >> plane (to run LSP Ping)? >=20 > For MPLS-TP (non-control plane), the only difference is the = encapsulation, the GAL+GACh can also be used as defined RFC6426. Maybe = we could add some text to state this. Sounds good -- thank you. >>=20 >>=20 >> 2. Problem Statements and Solution Overview >>=20 >> MPLS LSP Ping is defined in [RFC4379]. It can be used to detect = data >> path failures in all MPLS LSPs, and was originally designed for >> unidirectional LSPs. >>=20 >> Where does RFC4379 limits its scope to unidirectional LSPs? >=20 > RFC 4379 does not explicitly state this, but from procedures it = defined, since the echo rely does not carry any FEC stack information, = the verification is only for forward direction, not for reverse = direction.=20 >=20 > Maybe it more proper to state: "...and was mainly designed for = unidirectional LSPs." >=20 Instead of the design intent, I would call out something similar to you = said: not that the echo reply does not carry target FEC stack because = that's not correct -- but that "The FEC Stack TLV from the echo request = MAY be copied to the reply." >=20 >>=20 >> And in any case, the use modes 2 or 3 cannot guarantee the delivery >> of echo responses through an IP network that is fundamentally >> unreliable. The failure to deliver echo response messages can lead >> to false negatives making it appear that the LSP has failed. >>=20 >> Allowing the ingress LSR to control the path used for echo reply >> messages, and in particular forcing those messages to use an LSP >> rather than being sent through the IP network, enables an operator = to >> apply an extra level of deterministic process to the LSP Ping test. >>=20 >> These two paragraphs seems to show a gross misconception on how reply = works. >> =46rom 4379, the reply with mode #1 does not need to be sent over IP = without >> MPLS. It can very well be sent over an LSP. In fact, given the right = source IP >> address in the LSP Ping Echo, the right return LSP can be chosen. = This needs to be >> better explained so as not to "hype" the solution presented in the = document. >=20 > We will consider this, it's great if you have some suggested text.=20 This is a bit tricky. Note RFC 4379 says by way of example: If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header MUST contain the Router Alert IP option. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [LABEL-STACK]). Which implies that "reply via IPv4 UDP packet with/without RA" does not = mean MUST be unlabeled IPv4 packet. If there's an LSP towards source/32, = it would go labeled. >=20 >>=20 >> 3. Extensions >>=20 >> In addition, two new TLVs, the Reply Path TLV and Reply Traffic = Class >> (TC) [RFC5462] TLV, are defined in this document. >>=20 >> Given that the "Reply Path TLV" specifies an LSP and not a Path, I = strongly suggest >> the TLV be renamed to more specifically describe its functionality. >=20 > In Section 3.3.1-3, it defines tunnel (not a particular LSP) to be as = the return path, so the return path includes LSP and Tunnel; it seems = "Path" is more suitable. >=20 OK, just a suggestion. >>=20 >>=20 >> 0x0004 The specified Reply Path was not found, the echo >> reply was sent via other LSP >> 0x0005 The specified Reply Path was not found, the echo >> reply was sent via IP path >>=20 >> It is not clear what an IP path is, when sending an LSP Echo response = as an IP >> datagram can be sent labeled as an LSP. Also, I assume these are = without Router >> Alert, right? >=20 > Yes. >=20 > Here the IP path refers to pure IP forwarding path, not the LSP. >=20 If I understand these set of rules correctly, this says that when the = Reply Path is not found, then the LSP Ping reply can be sent IP = unlabeled. Reading Sections 3.2 and 3.3, the Reply Paths field is = specified when A is not set. However, Section 4.3 says: When the echo reply is intended to test the return path (the A is not set in the previous received echo request), the destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this problem, the IP destination address of the echo reply message that is transmitted along the=20 meaning if A is not set, the reply cannot be sent over IP. By the way, I think that "MUST never" should really be "MUST NOT" in = 2119 language. >>=20 >> A (Alternative path): the egress LSR MUST select a non-default path >> as the return path. This is very useful when reverse default path >> problems are suspected which can be confirmed when the echo reply = is >> forced to follow a non-default return path. Here, the default path >> refers to the path that the egress LSR will use to send the echo >> reply when the return path is not explicitly specified as defined = in >> this document. If A bit is set, there is no need to carry any >> specific reply path sub-TLVs, and when received, the sub-TLVs = SHOULD >> be ignored. >>=20 >> Do all implementations understand the same thing as "Default"? This = seems >> underspecified. >=20 > The draft defines: > "the default path refers to the path that the egress LSR will use to = send the echo reply when the return path is not explicitly specified as = defined in this document."=20 >=20 > I think this definition is straightforward and clear:-) Do you have = any suggestion? One element that is not clear to me is that the path that the LSR sends = back the reply depends upon the Reply Mode value. If you are defining in = this document a new Reply Mode value, what is "default"? Assuming Reply = Mode 1, 2, 3, or 4? Another thing that is not clear is whether default = makes any assumptions of labeled versus unlabeled. >=20 >>=20 >> Also, say that an LSP Ping is sent with source IP address as = 192.0.2.1 over an LSP. A >> "default" return LSP is perhaps an LSP where 192.0.2.1/32 points to. = How would a >> non-default be in this case? Send it to a wrong LSR? What should = responding >> router choose in this case? How can it choose a non-default without = the >> specification of an actual LSP? >=20 > Of cause, send to wrong LSR is allowable, for this case, the = non-default path could be either an IP path or other LSPs (for example, = a TE LSP). If there is non-default path, return code 0x0003 should be = returned: >=20 > 0x0003 The echo reply was sent successfully using the > specified Reply Path >=20 >>=20 >> B (Bidirectional): the return path is required to follow the = reverse >> direction of the tested bidirectional LSP. If B bit is set, there = is >> no need to carry any specific reply path sub-TLVs, and when = received, >> the sub-TLVs SHOULD be ignored. >>=20 >> Is this default or non-default when this TLV is not used (pre-this = spec)? >=20 > It's implementation depend. >=20 > RFC 4379 does not specify this;RFC6426 specifies the echo reply MUST = be along the reverse direction, but have to use GAL+GACh (application = channel mode).=20 >=20 >>=20 >> 3.2. Reply Path (RP) TLV >>=20 >> When reply mode (!=3D 5) and Reply Path TLV is received, which takes = precedence >> and what is the procedure? >=20 > Per RFC4379, Malformed Error should be returned.=20 Does this conflict with the following? 3.2. Reply Path (RP) TLV The Reply Path (RP) TLV is an optional TLV within the LSP Ping protocol. >=20 >>=20 >>=20 >> 3.3. Reply Path sub-TLVs >>=20 >> In addition, this document defines three new sub-TLVs: IPv4 RSVP >> Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel = sub-TLV. >>=20 >> It is not clear why these are specified. The text does not seem to = explain the >> need, nor why these do not need to be specified for the TLV 1. >=20 > Sometime, using tunnel other that specific LSP is more suitable, for = example, when performing a long time ping for an TE LSP (as stated in = RFC5884, section 3.2), it could avoid the impact of the changes of LSP = ID (e.g.,Make-Before-Break, LSP ID may change, but tunnel ID will not). = Another usage is for BFD, it is stated in Section 3.3.1. >=20 >=20 > How about this:(new text is in **) >=20 > The IPv4 RSVP Tunnel sub-TLV is used in the Reply Path TLV to allow > the operator to specify a more generic tunnel FEC other than a > particular LSP as the return path. According to the bits set in the > Flag field, the egress LSR will then choose an LSP from the = specified > Tunnel as the return path. One usage of this generic RSVP Tunnel > sub-TLV is for bootstrapping BFD session on an MPLS Tunnel that has > primary and secondary LSPs, especially when Make-Before-Break (MBB) > is deployed. The usage is discussed in Section 4.2 of > [I-D.chen-mpls-bfd-enhancement]. *Another usage is when LSP Ping is > used to periodically verify the control plane against the data plane = [RFC5884], > using Tunnel other than particular LSP can avoid the impact of LSP = changing > when MBB is deployed.* >=20 >=20 > It may apply to TLV 1, if the WG agree, I am fine to apply this to TLV = 1. Then the IANA allocation could be easier.=20 I think this should be the other way around. If this is a functionality that requires a Target FEC Stack definition = (like you propose to have an RSVP IPv4 LSP without the LSP ID), then it = should be defined for TLV1 and inherited.=20 I have concerns that these sub-TLVs apply to TLV21 only. Now, specifically to the paragraph that you propose: 1. I do not think = the BFD case justifies these TLVs. 2. I think that the MBB use case can = not only happen on the return way but also on the forward way. >=20 >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | MUST be zero |S|P| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Further, "primary" and "secondary" are not defined. Which = specifications >> explains what is a primary and a secondary? >=20 > RFC4872 Section 4.2.1 defines the primary and secondary, we will add a = reference there.=20 This is great as far as the S and P definition. Thank you. However, RFC 4872 Section 4.1 uses the LSP ID. >=20 >>=20 >> 3.3.3. Static Tunnel sub-TLV >>=20 >> Again, why is this not specified for the Echo as well? >=20 > Same as above. >=20 Same as above. >>=20 >> 4. Theory of Operation >>=20 >> When the echo reply message is intended to test the return MPLS LSP >> path(when the A bit is not set in the previous received echo = request >> message), the destination IP address of the echo reply message MUST >> never be used in a forwarding decision. >>=20 >> Is this really the meaning of the "A-bit"? >=20 > The "A-bit" is as it defined in 3.2, here we just borrow the "A-bit" = to indicate whether need to test the return path. The logic here is that = since the "A-bit" is to choose an alternate path hence to deliver the = echo reply back, test the return path is normally not intention here. = And the path could either IP or MPLS path, verify the IP path does not = make sense.=20 I apologize I still do not understand. The A-bit means Alternate return = path. What does "intended to test the return MPLS LSP path" mean? Do you = meant "the *default* return path"? With a-bit set, it is also intended = to test *a* return path. >=20 >>=20 >> To avoid this possibility >> the destination IP address of the echo reply message that is >> transmitted along the specified return path MUST be set to numbers >> from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, = and >> the IP TTL MUST be set 1, and the TTL in the outermost label MUST = be >> set to 255. >>=20 >> 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be = 0:0:0:0:0:FFFF:7F00/104 or >> 0:0:0:0:0:FFFF:127.0.0.0/104 >=20 > OK. >=20 >>=20 >> Of course when the echo reply message is not intended >> for testing the specified return path (when the A bit is set in the >> previous received echo request message) , the procedures defined in >> [RFC4379] (the destination IP address is copied from the source IP >> address) apply unchanged. >>=20 >> Does this mean that "Alternate" and "Non Default" are actually to = follow the >> *Default* procedures from RFC 4379? >=20 > Yes.=20 I believe I am getting lost somewhere on this section. When the A-bit is = set, that means Alternate non-default path. Is that to apply the default = path? >=20 >>=20 >> 4.3. Sending an Echo Reply >>=20 >> and the IP TTL MUST be set to 1, the >> TTL in the outermost label MUST be set to 255. >>=20 >> Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv? >=20 > Since the draft-ietf-mpls-lsp-ping-ttl-tlv(segment ping) only apply to = MS-PW and co-routed bidirectional LSP, hence to make sure the TLL is = determined. Specify a different return path other than the reverse path = is not workable. IMHO, this draft may not apply to the segment ping. >=20 >>=20 >> 6.4. Reply Path Return Code >>=20 >> There seems to be a contradiction in this: >>=20 >> 0x0006-0xfffb Not allocated, allocated via Standard Action >> 0xfffc-0xffff Experimental Use >>=20 >> The range of 0x0008-0xfffb is not allocated and reserved for future >> extensions and is allocated via Standard Action, the range of = 0xfffc- >> 0xffff is for Experimental Use. >>=20 >> Overall -- what is the interaction with = draft-ietf-mpls-remote-lsp-ping? Note also >> that document specifies a reply mode with the same value of "5". >=20 > There is no interaction with draft-ietf-mpls-remote-lsp-ping yet. I = think this is the result that defining a particular value without the = confirmation of IANA other than using TBD. I believe that this issue = will be solved by authors, chairs and IANA. >=20 >>=20 >> Also, this document does not seem to define backward compatibility >> considerations. What happens if a pre-specification router receives a = Reply Mode >> #5? The generic behavior of RFC 4379 is to respond with a generic = "malformed >> echo" error -- should there be a sub-code for Unknown reply mode -- = in which >> case it's a bit ironic to reply by some other mode -- to signal the = specific issue for >> future reply codes? >=20 > "malformed echo" error should be the right choice, a sub-code for = unknown reply is better, but the RFC4379 does not specify this behavior.=20= Do you need to add a new sub-code? >=20 >>=20 >> A final minor issue: this specification defines a new behavior for an = echo reply in >> which the Echo Reply message is destined to a loopback IP Address. If = the return >> path is broken, a middle router will think the packet is destined to = itself (because >> of the loopback) -- the behavior in this case is undefined and can = result in funny >> behaviors, for example an ICMP port unreachable sent to the source or = weirder. >=20 > The same situation will happen for Echo Request:-). Section 2.1 of = RFC4379 says: >=20 > "RFC 1122 allocates the 127/8 as "Internal host loopback address" and > states: "Addresses of this form MUST NOT appear outside a host." > Thus, the default behavior of hosts is to discard such packets. = This > helps to ensure that if a diagnostic packet is misdirected to a = host, > it will be silently discarded." >=20 > So, I think this issue is already solved by RFC4379.=20 No. The intent of using a 127/8 destination in the echo request is = two-fold: 1. to prevent reaching the Target destination outside the LSP, in an = IP-only mode. 2. to allow for traceroute to work, with each hop consuming the = datagram. On the reply, neither of those apply. 1. the LSP Ping reached its intended destination and now you want the = reply back 2. no traceroute on the way back. What does a node do with a reply destined to it, that it did not = initiate? Seems also like a security consideration. >=20 >>=20 >> A last minor issue relates the IANA requests -- section 6.2 is = already fairly >> complex, yet it does not speak to the following: What happens when = sub-TLVs >> for TLV1 are defined? What is checked to make sure that this new = sub-TLV applies >> to TLV21, and how? > The same as TLV 16, TLV 21 will reuse all existing and future defined = sub-TLVs. Roni also raised this question, we proposed the following = text: >=20 > " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 > are made directly for TLV Type 21, sub-TLVs in these ranges are=20 > copied from the assignments made for TLV Type 1 and kept the same > as that for TLV Type 1. All sub-TLVs in these ranges (include = existing > and future defined) defined for TLV Type 1 apply to TLV Type 21.=20 > Assignments of sub-..." >=20 It is not clear to me which Target FEC stack sub-TLV would apply to = TLV21 but not to TLV1. >=20 >> Does this update IANA allocations for RFC 4379? Also, a >> sub-TLV with sub-Type 16384 can be assigned to TLV1 with = specification required, >> but needs Standards action for TLV 21? And from which of these eight = ranges are >> sub-Types of Section 6.2.1 assigned, and why are not applicable to = TLV Type 1 and >> Type 16? >=20 > The LSP Ping IANA structure has been updated, please refer to: = https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-pa= rameters.xhtml#downstream-mapping. >=20 > It specifies the 16384-31743 "Specification Required, Experimental RFC = needed", and this draft is the Experimental "RFC". >=20 >=20 >>=20 >> I would include in the IANA instructions details within TLV 1 about = the changes >> and "directly copied" to TLV21. >=20 > I am fine with this. >=20 >>=20 >>=20 >> Nits: >>=20 >> Abstract >>=20 >> This document defines extensions to the failure-detection protocol >> for Multiprotocol Label Switching (MPLS) Label Switched Paths = (LSPs) >> known as "LSP Ping" that allow selection of the LSP to use for the >> echo reply return path. >>=20 >> The abstract is key in that its legibility sets for the whole = document. These same >> comments apply to the Introduction. >>=20 >> First, to be consistent with RFC4379, I'd qualify adding = "...extensions to the >> *data-plane* failure-detection protocol...". >>=20 >> Second, this is a very long sentence that reads better split in two: = "known as "LSP >> Ping". These extensions allow selection of the" >=20 > OK, thanks for the suggestion. >=20 >=20 >>=20 >>=20 >> The Reply via Specified Path mode is used to request that the = remote >> LSR receiving the LSP Ping echo request message sends back the echo >> reply message along the specified paths carried in the Reply Path >> TLV. >>=20 >> There is no such a thing as "LSP Ping echo request message" in RFC = 4379. The >> same happens throughout the document, and should be fixed. >=20 > OK, will look through the document to make them consistent with RFC = 4379. >=20 >>=20 >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reply Path TLV Type | Length = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reply Path return code | Flag = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> These are "Flags" (plural). >=20 > OK. >=20 >>=20 >> 0x0002 One or more of the sub-TLVs in Reply Path TLV >> was not understood >>=20 >> s/was/were/ >=20 > OK. >=20 >>=20 >>=20 >> Additionally, idnits 2.12.17 finds the following: >>=20 >> ** There is 1 instance of too long lines in the document, the = longest one >> being 1 character in excess of 72. >=20 > OK. >=20 >>=20 >> =3D=3D Unused Reference: 'RFC6426' is defined on line 873, but no = explicit >> reference was found in the text >=20 > OK. >=20 >>=20 >>=20 >> I hope these are clear and useful! >=20 > Very useful! >=20 > Many thanks Thanks to you! -- Carlos. >=20 > Mach >>=20 >> Thank you, >>=20 >> Carlos Pignataro. >=20 --Apple-Mail=_371865F7-3995-4ABD-87B7-685CAC5AECB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Mach,

Many thanks for the prompt response! Glad these = are useful -- please find some follow-ups = inline.

On Sep 3, 2013, at 11:52 PM, Mach Chen = <mach.chen@huawei.com> = wrote:

Hi Carlos,

Many thanks for your detailed review and = comments!

Please my reply inline...

-----Original Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] = On Behalf Of
Carlos Pignataro (cpignata)
Sent: Tuesday, September = 03, 2013 7:53 AM
To: <rtg-ads@tools.ietf.org>
C= c: <rtg-dir@ietf.org>;
draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org<= /a>; mpls@ietf.org
Subject: = [mpls] RtgDir = review:
draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

He= llo,

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

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

Document: = draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
Reviewer: = Carlos Pignataro
Review Date: 02 September 2013
IETF LC End Date: = 04 September 2013
Intended Status: Proposed = Standard

Summary:

I have significant concerns about this = document and recommend that the Routing
ADs discuss these issues = further with the authors.

Comments:

This document defines = useful functionality. It is also generally well written and is
fairly = detailed and comprehensive.

At the same time, for a set of = extensions that attempts to provide more
determinism in a failure = detection protocol, I believe there is still significant
ambiguity in = a few underspecified elements and behaviors.

Although I have = marked a number of "major" issues, some of them should be
relatively = easy to fix. Others, however, pose somewhat fundamental = questions.

I hope these review comments are clear and = useful!


Major Issues:

The first major issue that I = would like to have discussed is the usage of these
extensions for BFD = for MPLS bootstrapping. The Abstract in this document sets to
prove = that the extensions thereby defined can be used for BFD for = MPLS
bootstrapping. However, I believe that the document is = underdefined to make
that claim in the Abstract.

There is = somewhat of a contradiction in that, to make BFD for = MPLS
bootstrapping using these extensions work, specific protocol = definitions (i.e.,
2119 language in the BFD for MPLS bootstrapping = state machine) need to take
place in BFD, as per = draft-chen-mpls-bfd-enhancement. However, that
document is only an = Informative reference in this document. It appears to me
that, = without draft-chen-mpls-bfd-enhancement, the claim of the = Abstract
cannot be fulfilled. By way of process, I also believe this = might have not been
tested with the BFD working group.

In any = case, the only mention of BFD for MPLS bootstrapping in this document = is
by passing as an example in Section 3.3.1. Due to all of these = reasons, I believe
this doc should remove the goal of BFD = improvements al together or majorly
qualify and downgrade the usage = with BFD.

We are fine to remove the goal of BFD from = the Abstract and Introduction section. =

OK.

What = about the mention in Section 3.3.1? It says "One usage of this generic = RSVP Tunnel sub-TLV is for bootstrapping BFD session..." but this cannot = be achieved without I-D.chen-mpls-bfd-enhancement. I think this is = not harmful but not too useful either.



A second major issue is = a question: Given how RFC 4379 defines the reply mode 4
("Reply via = application level control channel"). Given a bidirectional LSP. = Doesn't
using GAL+GACh and Reply Mode #4 solve this whole problem? = Why is that one
not discussed? Basically, RFC 4379 uses RFC 5085 as = the reference example of
reply mode #4. Since RFC 5586 generalizes = the VCCV associated channel to LSPs,
then we have a generic control = channel to be used with reply mode #4.

To solve = which problem you refer to here? ( By using the Reply Mode 4 and = GAL+GACh)

I meant in a use similar = to RFC 6426 actually. See below also.



Also, what's the = relationship to RFC 6426 and TLV 16? Another return = path?

TLV 16 is designed to verify the return path, = but the return path selection is still a local decision of the egress = (in RFC6426, it states the return path MUST be the reverse LSP of a = bidirectional LSP) as defined in RFC4379. The Reply Path TLV is designed = to specify the return path, they are different and there is no = relationship to TLV 16.


I = understand. My question is more related to the following = scenarios:
  • If an Echo request = with the R global flag is set, and with TLV21 is received, should the = response include duplicate redundant information in TLV16 and = TLV21?
  • If an Echo request with the R global flag is set, and = with TLV21 specifying a non-reverse LSP of a bidirectional LSP, should = the responder honor the MUST of RFC 6426 or the MUST of this document = (since they appear to be mutually contradicting)?
  • Or more = generically, should this document build from TLV16 or define its own = TLV?


A third major issue has to do with the treatment of = Inter-AS scenarios in this draft.
In Sections 2.1 and 2.2, this draft = is implicitly presented as a solution for MPLS
Echo in "inter-domain = LSPs" and "inter-domain/inter-AS LSP". The problems in
these cases = are more convoluted than what this draft describes, and includes = lack
of addressing context and initiator address unknown (not only = that the IP Router
Alert label might not work in the boundary). I = believe that this draft should not
call those cases since are not = solved by the addition of a new reply mode.

Section = 2.1, bullet 2 talks about inter-AS; for inter-as LSP, with RFC4379, in = order to check the reverse LSP, the LSP Ping has to be initiated from = the other end reside in other AS, this may not possible since the other = AS may belong to different administrative domain. With this new reply = mode, an LSP Ping could detect both the forward and reverse LSP of the = bidirectional LSP, or an LSP Ping detects the forward direction of an = LSP and the reverse direction of another LSP ( for example, using a = deemed workable LSP to send echo request, and specifying a suspect LSP = as the return path hence to test it) , the operator does not need to = initiate two LSP Pings from both ends separately. The new reply mode is = mainly designed to achieve this. =


I am not totally clear on this = scenario -- in an inter-as LSP, are you saying that a return LSP is = always known from the other AS?
And is this somewhat of a = proxy ping functionality?

Section 2.2 mainly talks about the "Limitations of = Existing Mechanisms for Handling Unreliable Return Paths", mention = inter-domain is to explain one of the cases where the echo reply cannot = be delivered back even with router alert mode.
As the draft states, = it provides an extra level of deterministic process to deliver the echo = reply back by specifying a more deterministic path (e.g., TE = LSP).

"Allowing the ingress LSR to control the path used for echo = reply
  messages, and in particular forcing those messages = to use an LSP
  rather than being sent through the IP = network, enables an operator to
  apply an extra level of = deterministic process to the LSP Ping test."


A fourth major issue has to do with the use of IP Path = versus LSP Path, as per a
number of Minor issues described below = that, together, amount to a major. See
minor issues = section.

Please see my relies in Minor issues = part.


A fifth major issue concerns = itself with ECMP upon return. Saying that the
response should be sent = over the LSP with target FEC Stack of LDP IPv4 prefix = of
192.0.2.27/32 is not enough, as there are potentially multiple = paths throughout. I
believe this topic should be discussed. In the = Echo direction, this is solved with
the Downstream Mapping mechanics. = That is overkill for the response, but again,
multi path can give = false negatives the same deeming the whole solution
unusable (since = at the end it cannot provide the = prescriptiveness).

Indeed, Downstream Mapping = mechanics is overkill here for response.

Section 4.3 Sending an = Echo Reply

Second Para talks about how to set the destination = address that will affect the ECMP path selection.

How about = this?

Old:
"When the echo reply is intended to test the return = path (the A is not
  set in the previous received echo = request), the destination IP
  address of the echo reply = message MUST never be used in a forwarding
  decision. =  To avoid this problem, the IP destination address of the
=   echo reply message that is transmitted along the specified = return
  path MUST be set to numbers from the range 127/8 = for IPv4 or
  0:0:0:0:0:FFFF:127/104 for IPv6, and the IP = TTL MUST be set to 1, the
  TTL in the outermost label = MUST be set to 255."

New
"When the echo reply is intended to = test the return path (the A is not
  set in the previous = received echo request), the destination IP
  address of = the echo reply message MUST never be used in a forwarding
=   decision. *In addition, there may be ECMP paths for a = specified FEC, in
  case always select a failure path*, = the IP destination address of the
  echo reply message = that is transmitted along the specified return
  path MUST = be set to an address *(random chosen)* from the range 127/8 for IPv4 = or
  0:0:0:0:0:FFFF:127/104 for IPv6, and the IP TTL MUST = be set to 1, the
  TTL in the outermost label MUST be set = to 255."


I do not think this = addresses the issue. First, because that paragraph covers the "A is not = set" case, and this is when you are using a destination of 127/8. With a = destination of the source of the echo message you can have the same = phenomenon. If you send 4 LSP Pings and the fact that they have = different source UDP port result in the responder choosing different = ECMPs (for a *chosen* FEC), would that confuse more? That should be = covered outside of A-bit set vs. not set.


A last major issue concerns = itself with Security considerations. Using these
extensions, a node = can instruct another node to send replies out of any LSP,
including = LSPs that do not go back to the source. Further, an attacker can = send
MPLS Echo nodes to many nodes vectoring responses to a node = target of a DDoS
attack. The security considerations briefly touches = this point and says that "the
return path LSP MUST have destination = to the same node where the forward
path is from". However, it is not = clear how a node can actually evaluate and
actually verify and = enforce this MUST. It is quite possible that this check is = not
possible to make.

Since the echo request = carries the source address/identifier of the ingress/initiator, when = received a specified return path, the return path should also have the = destination address/identifier point to the ingress/initiator , with = these two addresses/identifiers, the egress should be able to perform = the above check IMHO.


This = seems to assume that the initiator has a single address. If for = troubleshooting purposes, an echo is sent with a source address of an = interface, and the return path specified is a prefix FEC with a = loopback/32 of the same node. How does the responder know it's the same = node and not a victim?



Minor Issues:

Does this document update RFC = 4379?

1. Introduction

  The procedures defined = in this document
  currently only apply to "ping" mode. =  The "traceroute" mode is out of
  scope for this = document.

I am note sure if this is major or minor -- but = separating traceroute mode as out
of scope seems like a huge gap. Are = there specific issues with using these
extensions in traceroute mode? = The last hop of a traceroute is equivalent to a
ping -- can these = extensions be used there?

The procedures can easily = apply to traceroute when only tracing the forward direction; but for = reverse direction, the procedures will become complicate, something like = proxy traceroute, the egress will be the proxy, more consideration and = mechanisms are needed. Thus, we leave it future = study.

I did not mean to trace the = reverse direction, but rather, perform a regular LSP Trace but = specifying the reply path.




  The = defined extensions can also be
  utilized for creating a = single Bidirectional Forwarding Detection
=   (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or = for a
  pair of unidirectional LSPs (one for each = direction).

For BFD for bidirectional LSPs, there is no need to = use LSP Ping bootstrapping,
since the context of the session can be = directly gleaned as defined in RFC 5885. In
other words, single-hop = BFD initialization is enough -- why would someone want
to use = bootstrapping with LSP Ping, and then specific extensions, when = the
context of the BFD discriminators is understood from the label = (again, as per RFC
5885)?

As described in = RFC5884, Section 5

" A BFD session may be established for a FEC = associated with an MPLS
  LSP.  As described above, = in the case of PHP or when the egress LSR
  distributes an = explicit null label to the penultimate hop router, or
=   next-hop label allocation, the BFD Control packet received = by the
  egress LSR does not contain sufficient = information to associate it
  with a BFD = session."

Even for bidirectional LSP, only if there are PHP, = explicit null label, or next-hop label allocation situations, LSP Ping = bootstrapping is needed IMHO.

I am = still concerned about this usage of this draft for BFD = bootstrapping.

What is the LSP Ping bootstrap = Echo's reply used for? =46rom RFC 5884 (emphasis added by me with "*" = markers):

   *On receipt of the = LSP Ping Echo request message, the egress LSR MUST
  =  send a BFD Control packet to the ingress LSR*, if the validation = of
   the FEC in the LSP Ping Echo request message = succeeds.  This BFD
   Control packet MUST set = the Your Discriminator field to the
   discriminator = received from the ingress LSR in the LSP Ping Echo
  =  request message.  *The egress LSR MAY respond with an LSP = Ping Echo
   reply message* that carries the local = discriminator assigned by it for
   the BFD session. =  The local discriminator assigned by the egress = LSR
   MUST be used as the My Discriminator field in = the BFD session packets
   sent by the egress = LSR.

The responder responds with BFD and = *MAY* respond with LSP Ping Echo reply. What do you gain by using this = new TLV in the bootstrap? You do not gain anything on the LSP Ping = bootstrap side of it.

If, on the other hand, = what you gain is that the BFD packets on the return path need to be sent = in this specified path, then that functionality is underspecified and = should not be called out as something to do. Has the BFD WG looked = into this? That needs BFD state and protocol machinery changes, and = not something to mention in passing. There are levels of details, like = if BFD stores this new return path and then routing or forwarding = changes, etc.

And yes, if context is lost on = receipt then you need to bootstrap and not use 1hop = initialization.

Net-net: I do not see a good = reason to keep any BFD mention, this should be a separate piece of work = and have BFD WG input. What do you think?



  In this = document, the term bidirectional LSP includes the co-routed
=   bidirectional LSP defined in [RFC3945] and the = associated
  bidirectional LSP that is constructed from a = pair of unidirectional
  LSPs (one for each direction), = and which are associated with one
  another at the LSP's = ingress/egress points [RFC5654].  The mechanisms
=   defined in this document can apply to both IP/MPLS and MPLS = Transport
  Profile (MPLS-TP) scenarios.

Two key = questions:
1. What about = Pseudowires?

Theoretically, PW can be treated as an = associated bidirectional LSP, so it's possible to specify another PW = other than the reverse PW.

2. How can = this apply to MPLS-TP when MPLS-TP might not have an IP control
plane = (to run LSP Ping)?

For MPLS-TP (non-control plane), = the only difference is the encapsulation, the GAL+GACh can also be used = as defined RFC6426. Maybe we could add some text to state = this.

Sounds good -- thank = you.



2. Problem Statements and Solution = Overview

  MPLS LSP Ping is defined in [RFC4379]. =  It can be used to detect data
  path failures in all = MPLS LSPs, and was originally designed for
=   unidirectional LSPs.

Where does RFC4379 limits its = scope to unidirectional LSPs?

RFC 4379 does not = explicitly state this, but from procedures it defined, since the echo = rely does not carry any FEC stack information, the verification is only = for forward direction, not for reverse direction.

Maybe it more = proper to state: "...and was mainly designed for unidirectional = LSPs."


Instead of the design = intent, I would call out something similar to you said: not that the = echo reply does not carry target FEC stack because that's not correct -- = but that "The FEC Stack TLV from the echo request MAY be copied to = the reply."



  And in any case, the use modes 2 or 3 = cannot guarantee the delivery
  of echo responses through = an IP network that is fundamentally
  unreliable. =  The failure to deliver echo response messages can lead
=   to false negatives making it appear that the LSP has = failed.

  Allowing the ingress LSR to control the path = used for echo reply
  messages, and in particular forcing = those messages to use an LSP
  rather than being sent = through the IP network, enables an operator to
  apply an = extra level of deterministic process to the LSP Ping test.

These = two paragraphs seems to show a gross misconception on how reply = works.
=46rom 4379, the reply with mode #1 does not need to be sent = over IP without
MPLS. It can very well be sent over an LSP. In fact, = given the right source IP
address in the LSP Ping Echo, the right = return LSP can be chosen. This needs to be
better explained so as not = to "hype" the solution presented in the document.

We = will consider this, it's great if you have some suggested text. =

This is a bit tricky. Note RFC 4379 = says by way of example:

   If = the Reply Mode in the echo request is "Reply via an
  =  IPv4 UDP packet with Router Alert", then the IP header MUST = contain
   the Router Alert IP option.  If the = reply is sent over an LSP, the
   topmost label MUST = in this case be the Router Alert label (1) (see
  =  [LABEL-STACK]).

Which implies that = "reply via IPv4 UDP packet with/without RA" does not mean MUST be = unlabeled IPv4 packet. If there's an LSP towards source/32, it would go = labeled.



3. Extensions

  In addition, two new = TLVs, the Reply Path TLV and Reply Traffic Class
  (TC) = [RFC5462] TLV, are defined in this document.

Given that the = "Reply Path TLV" specifies an LSP and not a Path, I strongly = suggest
the TLV be renamed to more specifically describe its = functionality.

In Section 3.3.1-3, it defines tunnel = (not a particular LSP) to be as the return path, so the return path = includes LSP and Tunnel; it seems "Path" is more = suitable.


OK, just a = suggestion.



  0x0004 =        The specified Reply Path was = not found, the echo
=             &n= bsp;   reply was sent via other LSP
=   0x0005        The = specified Reply Path was not found, the echo
=             &n= bsp;   reply was sent via IP path

It is not clear = what an IP path is, when sending an LSP Echo response as an = IP
datagram can be sent labeled as an LSP. Also, I assume these are = without Router
Alert, right?

Yes.

Here the = IP path refers to pure IP forwarding path, not the = LSP.


If I understand these set = of rules correctly, this says that when the Reply Path is not found, = then the LSP Ping reply can be sent IP unlabeled. Reading Sections 3.2 = and 3.3, the Reply Paths field is specified when A is not = set.

However, Section 4.3 = says:

   When the echo reply is = intended to test the return path (the A is not
  =  set in the previous received echo request), the destination = IP
   address of the echo reply message MUST never = be used in a forwarding
   decision.  To avoid = this problem, the IP destination address of the
  =  echo reply message that is transmitted along = the 

meaning if A is not set, the reply = cannot be sent over IP.


By the = way, I think that "MUST never" should really be "MUST NOT" in 2119 = language.


  A (Alternative path): the egress LSR MUST = select a non-default path
  as the return path.  This = is very useful when reverse default path
  problems are = suspected which can be confirmed when the echo reply is
=   forced to follow a non-default return path.  Here, the = default path
  refers to the path that the egress LSR will = use to send the echo
  reply when the return path is not = explicitly specified as defined in
  this document. =  If A bit is set, there is no need to carry any
=   specific reply path sub-TLVs, and when received, the = sub-TLVs SHOULD
  be ignored.

Do all = implementations understand the same thing as "Default"? This = seems
underspecified.

The draft defines:
"the = default path refers to the path that the egress LSR will use to send the = echo reply when the return path is not explicitly specified as defined = in this document."

I think this definition is straightforward = and clear:-) Do you have any = suggestion?

One element that is not = clear to me is that the path that the LSR sends back the reply depends = upon the Reply Mode value. If you are defining in this document a new = Reply Mode value, what is "default"? Assuming Reply Mode 1, 2, 3, or 4? = Another thing that is not clear is whether default makes any assumptions = of labeled versus unlabeled.



Also, say that an LSP = Ping is sent with source IP address as 192.0.2.1 over an LSP. = A
"default" return LSP is perhaps an LSP where 192.0.2.1/32 points = to. How would a
non-default be in this case? Send it to a wrong LSR? = What should responding
router choose in this case? How can it choose = a non-default without the
specification of an actual = LSP?

Of cause, send to wrong LSR is allowable, for = this case, the non-default path could be either an IP path or other LSPs = (for example, a TE LSP). If there is non-default path, return code = 0x0003 should be returned:

  0x0003 =        The echo reply was sent = successfully using the
=             &n= bsp;   specified Reply Path


  B (Bidirectional): the return path is = required to follow the reverse
  direction of the tested = bidirectional LSP.  If B bit is set, there is
  no = need to carry any specific reply path sub-TLVs, and when received,
=   the sub-TLVs SHOULD be ignored.

Is this default or = non-default when this TLV is not used (pre-this = spec)?

It's implementation depend.

RFC 4379 = does not specify this;RFC6426 specifies the echo reply MUST be along the = reverse direction, but have to use GAL+GACh (application channel mode). =


3.2. Reply Path (RP) = TLV

When reply mode (!=3D 5) and Reply Path TLV is received, = which takes precedence
and what is the = procedure?

Per RFC4379, Malformed Error should be = returned.

Does this conflict with = the following?

3.2.  Reply Path (RP) = TLV

   The Reply Path (RP) TLV is an optional TLV = within the LSP Ping
  =  protocol.





3.3. Reply Path = sub-TLVs

  In addition, this document defines three = new sub-TLVs: IPv4 RSVP
  Tunnel sub-TLV, IPv6 RSVP Tunnel = sub-TLV, and Static Tunnel sub-TLV.

It is not clear why these are = specified. The text does not seem to explain the
need, nor why these = do not need to be specified for the TLV 1.

Sometime, = using tunnel other that specific LSP is more suitable, for example, when = performing a long time ping for an TE LSP (as stated in RFC5884, section = 3.2), it could avoid the impact of the changes of LSP ID = (e.g.,Make-Before-Break, LSP ID may change, but tunnel ID will not). = Another usage is for BFD, it is stated in Section 3.3.1.


How = about this:(new text is in **)

  The IPv4 RSVP Tunnel = sub-TLV is used in the Reply Path TLV to allow
  the = operator to specify a more generic tunnel FEC other than a
=   particular LSP as the return path.  According to the = bits set in the
  Flag field, the egress LSR will then = choose an LSP from the specified
  Tunnel as the return = path.  One usage of this generic RSVP Tunnel
=   sub-TLV is for bootstrapping BFD session on an MPLS Tunnel = that has
  primary and secondary LSPs, especially when = Make-Before-Break (MBB)
  is deployed.  The usage is = discussed in Section 4.2 of
=   [I-D.chen-mpls-bfd-enhancement]. *Another usage is when LSP = Ping is
  used to periodically verify the control plane = against the data plane [RFC5884],
  using Tunnel other = than particular LSP can avoid the impact of LSP changing
=   when MBB is deployed.*


It may apply to TLV 1, if = the WG agree, I am fine to apply this to TLV 1. Then the IANA allocation = could be easier.

I think this = should be the other way around.

If this is a = functionality that requires a Target FEC Stack definition (like you = propose to have an RSVP IPv4 LSP without the LSP ID), then it should be = defined for TLV1 and inherited. 

I have = concerns that these sub-TLVs apply to TLV21 = only.

Now, specifically to the paragraph that = you propose: 1. I do not think the BFD case justifies these TLVs. 2. I = think that the MBB use case can not only happen on the return way but = also on the forward way.



=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | =         MUST be zero =      |S|P|
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Further, "primary" = and "secondary" are not defined. Which specifications
explains what = is a primary and a secondary?

RFC4872 Section 4.2.1 = defines the primary and secondary, we will add a reference there. =

This is great as far as the S and P = definition. Thank you.

However, RFC 4872 = Section 4.1 uses the LSP ID.



3.3.3. Static Tunnel = sub-TLV

Again, why is this not specified for the Echo as = well?

Same as = above.


Same as = above.


4.= Theory of Operation

  When the echo reply message is = intended to test the return MPLS LSP
  path(when the A bit = is not set in the previous received echo request
=   message), the destination IP address of the echo reply = message MUST
  never be used in a forwarding = decision.

Is this really the meaning of the = "A-bit"?

The "A-bit" is as it defined in 3.2, here = we just borrow the "A-bit" to indicate whether need to test the return = path. The logic here is that since the "A-bit" is to choose an alternate = path hence to deliver the echo reply back, test the return path is = normally not intention here. And the path could either IP or MPLS path, = verify the IP path does not make sense. =

I apologize I still do not = understand. The A-bit means Alternate return path. What does "intended = to test the return MPLS LSP path" mean? Do you meant "the *default* = return path"? With a-bit set, it is also intended to test *a* return = path.



  To avoid this possibility
=   the destination IP address of the echo reply message that = is
  transmitted along the specified return path MUST be = set to numbers
  from the range 127/8 for IPv4 or = 0:0:0:0:0:FFFF:127/104 for IPv6, and
  the IP TTL MUST be = set 1, and the TTL in the outermost label MUST be
  set to = 255.

0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be = 0:0:0:0:0:FFFF:7F00/104 = or
0:0:0:0:0:FFFF:127.0.0.0/104

OK.


  Of course when the echo reply message = is not intended
  for testing the specified return path = (when the A bit is set in the
  previous received echo = request message) , the procedures defined in
  [RFC4379] = (the destination IP address is copied from the source IP
=   address) apply unchanged.

Does this mean that = "Alternate" and "Non Default" are actually to follow the
*Default* = procedures from RFC 4379?

Yes. =

I believe I am getting lost = somewhere on this section. When the A-bit is set, that means Alternate = non-default path. Is that to apply the default = path?



4.3. Sending an Echo Reply

  and the = IP TTL MUST be set to 1, the
  TTL in the outermost label = MUST be set to 255.

Should this follow = draft-ietf-mpls-lsp-ping-ttl-tlv?

Since the = draft-ietf-mpls-lsp-ping-ttl-tlv(segment ping) only apply to MS-PW and = co-routed bidirectional LSP, hence to make sure the TLL is determined. = Specify a different return path other than the reverse path is not = workable. IMHO, this draft may not apply to the segment = ping.


6.4. Reply Path Return = Code

There seems to be a contradiction in this:

=   0x0006-0xfffb Not allocated, allocated via Standard = Action
  0xfffc-0xffff Experimental Use

=   The range of 0x0008-0xfffb is not allocated and reserved for = future
  extensions and is allocated via Standard Action, = the range of 0xfffc-
  0xffff is for Experimental = Use.

Overall -- what is the interaction with = draft-ietf-mpls-remote-lsp-ping? Note also
that document specifies a = reply mode with the same value of "5".

There is no = interaction with draft-ietf-mpls-remote-lsp-ping yet. I think this is = the result that defining a particular value without the confirmation of = IANA other than using TBD. I believe that this issue will be solved by = authors, chairs and IANA.


Also, = this document does not seem to define backward = compatibility
considerations. What happens if a pre-specification = router receives a Reply Mode
#5? The generic behavior of RFC 4379 is = to respond with a generic "malformed
echo" error -- should there be a = sub-code for Unknown reply mode -- in which
case it's a bit ironic to = reply by some other mode -- to signal the specific issue for
future = reply codes?

"malformed echo" error should be the = right choice, a sub-code for unknown reply is better, but the RFC4379 = does not specify this behavior.

Do = you need to add a new sub-code?



A final minor issue: = this specification defines a new behavior for an echo reply in
which = the Echo Reply message is destined to a loopback IP Address. If the = return
path is broken, a middle router will think the packet is = destined to itself (because
of the loopback) -- the behavior in this = case is undefined and can result in funny
behaviors, for example an = ICMP port unreachable sent to the source or = weirder.

The same situation will happen for Echo = Request:-).  Section 2.1 of RFC4379 says:

"RFC 1122 = allocates the 127/8 as "Internal host loopback address" and
=   states: "Addresses of this form MUST NOT appear outside a = host."
  Thus, the default behavior of hosts is to discard = such packets.  This
  helps to ensure that if a = diagnostic packet is misdirected to a host,
  it will be = silently discarded."

So, I think this issue is already solved by = RFC4379.

No. The intent of using a = 127/8 destination in the echo request is two-fold:
1. to = prevent reaching the Target destination outside the LSP, in an IP-only = mode.
2. to allow for traceroute to work, with each hop = consuming the datagram.

On the reply, neither = of those apply.
1. the LSP Ping reached its intended = destination and now you want the reply back
2. no traceroute = on the way back.

What does a node do with a = reply destined to it, that it did not initiate? Seems also like a = security consideration.



A last minor issue relates the IANA requests -- = section 6.2 is already fairly
complex, yet it does not speak to the = following: What happens when sub-TLVs
for TLV1 are defined? What is = checked to make sure that this new sub-TLV applies
to TLV21, and = how?
The same as TLV 16, TLV 21 will reuse all existing = and future defined sub-TLVs. Roni also raised this question, we proposed = the following text:

" No assignments of sub-TLVs in the range of = 0-16383 and 32768-49161
   are made directly for TLV = Type 21, sub-TLVs in these ranges are
   copied from = the assignments made for TLV Type 1 and kept the same
=    as that for TLV Type 1. All sub-TLVs in these ranges = (include existing
   and future defined) defined for = TLV Type 1 apply to TLV Type 21.
   Assignments of = sub-..."


It is not clear to me = which Target FEC stack sub-TLV would apply to TLV21 but not to = TLV1.


Does this update IANA allocations for RFC 4379? Also, = a
sub-TLV with sub-Type 16384 can be assigned to TLV1 with = specification required,
but needs Standards action for TLV 21? And = from which of these eight ranges are
sub-Types of Section 6.2.1 = assigned, and why are not applicable to TLV Type 1 and
Type = 16?

The LSP Ping IANA structure has been updated, = please refer to: https://www.iana.org/assignment= s/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#downstream-mappi= ng.

It specifies the 16384-31743 "Specification Required, = Experimental RFC needed", and this draft is the Experimental = "RFC".



I would include in the = IANA instructions details within TLV 1 about the changes
and = "directly copied" to TLV21.

I am fine with = this.



Nits:

Abstract

  This = document defines extensions to the failure-detection protocol
=   for Multiprotocol Label Switching (MPLS) Label Switched = Paths (LSPs)
  known as "LSP Ping" that allow selection of = the LSP to use for the
  echo reply return = path.

The abstract is key in that its legibility sets for the = whole document. These same
comments apply to the = Introduction.

First, to be consistent with RFC4379, I'd qualify = adding "...extensions to the
*data-plane* failure-detection = protocol...".

Second, this is a very long sentence that reads = better split in two: "known as "LSP
Ping". These extensions allow = selection of the"

OK, thanks for the = suggestion.




=   The Reply via Specified Path mode is used to request that = the remote
  LSR receiving the LSP Ping echo request = message sends back the echo
  reply message along the = specified paths carried in the Reply Path
=   TLV.

There is no such a thing as "LSP Ping echo = request message" in RFC 4379. The
same happens throughout the = document, and should be fixed.

OK, will look through = the document to make them consistent with RFC 4379.



       0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
=        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
      | =     Reply Path TLV Type =       | =          Length =             &n= bsp; |
=       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
      | =    Reply Path return code     | =             &n= bsp;Flag =             |<= br> =       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+

These are "Flags" = (plural).

OK.


=   0x0002        One or more = of the sub-TLVs in Reply Path TLV
=             &n= bsp;   was not = understood

s/was/were/

OK.



Additionally, idnits 2.12.17 finds the = following:

 ** There is 1 instance of too long lines in the = document, the longest one
    being 1 character = in excess of 72.

OK.


 =3D=3D Unused Reference: 'RFC6426' is defined = on line 873, but no explicit
    reference was = found in the text

OK.



I hope these are clear and = useful!

Very useful!

Many = thanks

Thanks to = you!

-- Carlos.


Mach

Thank = you,

Carlos = Pignataro.


= --Apple-Mail=_371865F7-3995-4ABD-87B7-685CAC5AECB5-- --Apple-Mail=_3DFCD649-144E-4207-B729-5CCB0BABB91E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIohkMACgkQtfDPGTp3USyo+gCgrww9QcEn8E60RRIbQXrBR2c/ cY8AnR+I74ul307Yvn+otgqh5U4fmAxL =/HMQ -----END PGP SIGNATURE----- --Apple-Mail=_3DFCD649-144E-4207-B729-5CCB0BABB91E-- From zhangfatai@huawei.com Thu Sep 5 01:03:25 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D934811E80E2; Thu, 5 Sep 2013 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsx6i-XcF19q; Thu, 5 Sep 2013 01:03:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF4011E80DC; Thu, 5 Sep 2013 01:03:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB55913; Thu, 05 Sep 2013 08:03:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 09:02:47 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 09:02:53 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.152]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 16:02:41 +0800 From: Fatai Zhang To: Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt Thread-Index: AQHOqg5K2IUjQYV0ckGMj1OW7u5h2w== Date: Thu, 5 Sep 2013 08:02:40 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E17291BA6E8@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17291BA6E8@dfweml511-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CA61930SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 05 Sep 2013 08:13:07 -0700 Cc: "rtg-dir@ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-signaling-g709v3.all@tools.ietf.org" Subject: Re: [RTG-DIR] [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:03:26 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CA61930SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young and all, Thanks for your comments. All Nits should be accepted. Please see more in-line to check if you are happy with the proposed updates= and the clarification. Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= eeyoung Sent: Thursday, September 05, 2013 12:27 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signaling-g709= v3.all@tools.ietf.org Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.= txt Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t 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-ccamp-gmpls-signaling-g709v3-11.txt Reviewer: Young Lee Review Date: 4 September 2013 IETF LC End Date: Intended Status: Standard Track Summary: This document is basically ready for publication, but has some minor issues= and nits that should be considered prior to publication. Comments: This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for "the evolving G.709 OTN control" which may b= e referred to as "G709v3" in the document to be aligned with the draft name= (draft-ietf-ccamp-gmpls-singaling-g709v3). Major Issues: No major issues found. Minor Issues: Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT is= sue. [Fatai] Your comment has been addressed in Section 6.3 in detail way. Section 4: The clause "via 1.25G TS granularity, 2.5G TS granularity or any= one of them (i.e., TS granularity Auto-Negotiation is enabled)" is a bit c= onfusing. [Fatai]Agree. I think we can use "ODU-any defined below" to replace "any o= ne of them (i.e., TS granularity Auto-Negotiation is enabled)". Section 5: The first paragraph can be clearer by associating the objects me= ntioned with the Path or Resv Message. Please consider to change to: "The t= raffic Parameters for OTN-TDM capable Switching Type are carried in the OTN= -TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in= the Resv Message." [Fatai]Agree and accept. Section 6.2: "In such case" is not clear. Is that meant: "When the TPN was = not assigned by the ingress node"? [Fatai] No, but your comment makes sense. I think we can use "When the TPN = is assigned by the ingress node" to replace "In this case". Section 8, the fourth bullet mentioned of "Ingress" nodes may select the pr= ocedure either from RFC4328 or this document. How about the egress nodes? I= s it assumed to follow what the ingress has chosen? (Just a clarification q= uestion) [Fatai] There is nothing with egress nodes. There is this bullet because th= e ingress nodes have chance to select the procedure (either from RFC4328 or= this document). Nits: Section 3, when the term "Tributary Slot" is first used (i.e,. A new Tribut= ary Slot granularity (i.e., 1.25Gbps) is also described...), please add the= abbreviation. Section 3 s/legacy interfaces/the legacy interfaces/ Section 4 s/[RFC4328] extends/[RFC4328] extended/ Section 5: Spell NVC. Section 5.2: For Table 2, align the column dividers Section 5.2 s/MUST equal to/MUST equal/ or /MUST be equal to/ Section 6.2: delete "out" before "outgoing" in the first sentence of the th= ird paragraph. Section 6.2: s/accordingly to/according to/ (6th paragraph) Thanks. Young --_000_F82A4B6D50F9464B8EBA55651F541CF85CA61930SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young and all,

 

Thanks for your comments.

 

All Nits should be accepted.  

 

Please see more in-line to check if you are happy with the propos= ed updates and the clarification.

 

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of Leeyoung
Sent: Thursday, September 05, 2013 12:27 AM
To: rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signali= ng-g709v3.all@tools.ietf.org
Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g70= 9v3-11.txt

 

Hello,

I have been selected as the Routing Directorate rev= iewer for this draft. The Routing Directorate seeks to review all routing o= r routing-related drafts as they pass through IETF last call and IESG revie= w. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Rout= ing Directorate, please see http://www.ietf.org/iesg/directorate/routing.ht= ml

Although these comments are primarily for the use o= f the Routing ADs, it would be helpful if you could consider them along wit= h 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-gmpls-signaling-g709v3-1= 1.txt
Reviewer: Young Lee
Review Date: 4 September 2013
IETF LC End Date: 
Intended Status: Standard Track

Summary:
This document is basically ready for publicatio= n, but has some minor issues and nits that should be considered prior to pu= blication.

Comments:
This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for “the evolving G.709 OTN control”= which may be referred to as “G709v3” in the document to be aligned with the draft name (draft-ietf-ccamp-gmpls-singali= ng-g709v3).

Major Issues:
No major issues found.

Minor Issues:
Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT issue.

[Fatai] Your comment has been = addressed in Section 6.3 in detail way.

Section 4: The clause “via 1.25G TS granulari= ty, 2.5G TS granularity or any one of them (i.e., TS granularity Auto-Negot= iation is enabled)” is a bit confusing.

[Fatai]Agree.  I think we= can use “ODU-any defined below” to replace “any one of t= hem (i.e., TS granularity Auto-Negotiation is enabled)”.

Section 5: The first paragraph can be clearer by as= sociating the objects mentioned with the Path or Resv Message. Please consi= der to change to: “The traffic Parameters for OTN-TDM capable Switchi= ng Type are carried in the OTN-TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in the Resv Message= .”

[Fatai]Agree and accept.<= /o:p>

Section 6.2: “In such case” is not clea= r. Is that meant: “When the TPN was not assigned by the ingress node&= #8221;?

[Fatai] No, but your comment m= akes sense. I think we can use “When the TPN is assigned by the ingre= ss node” to replace “In this case”.

Section 8, the fourth bullet mentioned of “In= gress” nodes may select the procedure either from RFC4328 or this doc= ument. How about the egress nodes? Is it assumed to follow what the ingress= has chosen? (Just a clarification question)

[Fatai] There is nothing with = egress nodes. There is this bullet because the ingress nodes have chance to= select the procedure (either from RFC4328 or this document).

Nits: =

Section 3, when the term “Tributary Slot̶= 1; is first used (i.e,. A new Tributary Slot granularity (i.e., 1.25Gbps) i= s also described…), please add the abbreviation.

Section 3
s/legacy interfaces/the legacy interfaces/

Section = 4

s/[RFC43= 28] extends/[RFC4328] extended/

Section 5: Spell NVC.

Section 5.2: For Table 2, align the column dividers=

Section = 5.2

s/MUST e= qual to/MUST equal/ or /MUST be equal to/

Section 6.2: delete “out” before “= ;outgoing” in the first sentence of the third paragraph.

Section 6.2: s/accordingly to/according to/ (6= th paragraph)

Thanks.

Young

 

--_000_F82A4B6D50F9464B8EBA55651F541CF85CA61930SZXEMA504MBSchi_-- From leeyoung@huawei.com Thu Sep 5 08:16:24 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F212A21E80D6; Thu, 5 Sep 2013 08:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7JEpZyx4VoP; Thu, 5 Sep 2013 08:16:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8721E80C3; Thu, 5 Sep 2013 08:16:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB95251; Thu, 05 Sep 2013 15:16:10 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 16:15:24 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 16:15:42 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.204]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 08:15:34 -0700 From: Leeyoung To: Fatai Zhang , "rtg-ads@tools.ietf.org" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt Thread-Index: AQHOqg5TB/BSDVgzBUiD4+42YtKDgZm3QSpA Date: Thu, 5 Sep 2013 15:15:33 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291BAA4A@dfweml511-mbs.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E17291BA6E8@dfweml511-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.173] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E17291BAA4Adfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-dir@ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-signaling-g709v3.all@tools.ietf.org" Subject: Re: [RTG-DIR] [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 15:16:24 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E17291BAA4Adfweml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai, Thanks for your quick resolution. I have no further issue pending after you= r proposed changes. Regards, Young From: Fatai Zhang Sent: Thursday, September 05, 2013 3:03 AM To: Leeyoung; rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signaling-g709= v3.all@tools.ietf.org Subject: RE: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3= -11.txt Hi Young and all, Thanks for your comments. All Nits should be accepted. Please see more in-line to check if you are happy with the proposed updates= and the clarification. Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, September 05, 2013 12:27 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signaling-g709v3.all@tools.ietf.org Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.= txt Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t 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-ccamp-gmpls-signaling-g709v3-11.txt Reviewer: Young Lee Review Date: 4 September 2013 IETF LC End Date: Intended Status: Standard Track Summary: This document is basically ready for publication, but has some minor issues= and nits that should be considered prior to publication. Comments: This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for "the evolving G.709 OTN control" which may b= e referred to as "G709v3" in the document to be aligned with the draft name= (draft-ietf-ccamp-gmpls-singaling-g709v3). Major Issues: No major issues found. Minor Issues: Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT is= sue. [Fatai] Your comment has been addressed in Section 6.3 in detail way. Section 4: The clause "via 1.25G TS granularity, 2.5G TS granularity or any= one of them (i.e., TS granularity Auto-Negotiation is enabled)" is a bit c= onfusing. [Fatai]Agree. I think we can use "ODU-any defined below" to replace "any o= ne of them (i.e., TS granularity Auto-Negotiation is enabled)". Section 5: The first paragraph can be clearer by associating the objects me= ntioned with the Path or Resv Message. Please consider to change to: "The t= raffic Parameters for OTN-TDM capable Switching Type are carried in the OTN= -TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in= the Resv Message." [Fatai]Agree and accept. Section 6.2: "In such case" is not clear. Is that meant: "When the TPN was = not assigned by the ingress node"? [Fatai] No, but your comment makes sense. I think we can use "When the TPN = is assigned by the ingress node" to replace "In this case". Section 8, the fourth bullet mentioned of "Ingress" nodes may select the pr= ocedure either from RFC4328 or this document. How about the egress nodes? I= s it assumed to follow what the ingress has chosen? (Just a clarification q= uestion) [Fatai] There is nothing with egress nodes. There is this bullet because th= e ingress nodes have chance to select the procedure (either from RFC4328 or= this document). Nits: Section 3, when the term "Tributary Slot" is first used (i.e,. A new Tribut= ary Slot granularity (i.e., 1.25Gbps) is also described...), please add the= abbreviation. Section 3 s/legacy interfaces/the legacy interfaces/ Section 4 s/[RFC4328] extends/[RFC4328] extended/ Section 5: Spell NVC. Section 5.2: For Table 2, align the column dividers Section 5.2 s/MUST equal to/MUST equal/ or /MUST be equal to/ Section 6.2: delete "out" before "outgoing" in the first sentence of the th= ird paragraph. Section 6.2: s/accordingly to/according to/ (6th paragraph) Thanks. Young --_000_7AEB3D6833318045B4AE71C2C87E8E17291BAA4Adfweml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai,

 

Thanks for your quick = resolution. I have no further issue pending after your proposed changes.

 

Regards,

Young

 

From: Fatai Zh= ang
Sent: Thursday, September 05, 2013 3:03 AM
To: Leeyoung; rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signali= ng-g709v3.all@tools.ietf.org
Subject: RE: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling= -g709v3-11.txt

 

Hi Yo= ung and all,

=  

Thank= s for your comments.

=  

All N= its should be accepted.  

=  

Pleas= e see more in-line to check if you are happy with the proposed updates and = the clarification.

=  

 

 

 

 

Best Regards

 

Fatai

=  

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, September 05, 2013 12:27 AM
To: rtg-ads@tools.ietf.org=
Cc: rtg-dir@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-gmpls-signaling-g709v3.all@tools.ietf.org
Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g70= 9v3-11.txt

 

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts 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, pl= ease 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 receive, and strive to resolve them through discuss= ion or by updating the draft.

Document: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt
Reviewer: Young Lee
Review Date: 4 September 2013
IETF LC End Date: 
Intended Status: Standard Track

Summary:
This document is basically ready for publicatio= n, but has some minor issues and nits that should be considered prior to pu= blication.

Comments:
This document is clearly written and easy to understand, but there are a fe= w places that can be improved. The document title refers this extension as = GMPLS Signaling Extensions for “the evolving G.709 OTN control”= which may be referred to as “G709v3” in the document to be aligned with the draft name (draft-ietf-ccamp-gmpls-singali= ng-g709v3).

Major Issues:
No major issues found.

Minor Issues:
Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not suppo= rted by [G709-2012], please add some comment for the readers if this docume= nt or other document deals with such extension or that work remains to be w= orked out in the future. It was not clear why you mentioned of this VCAT issue.

[Fatai] Your comment has been addressed in Se= ction 6.3 in detail way.

Section 4: The clause “via 1.25G TS granularity, 2.5G TS granulari= ty or any one of them (i.e., TS granularity Auto-Negotiation is enabled)= 221; is a bit confusing.

[Fatai]Agree.  I think we can use “= ;ODU-any defined below” to replace “any one of them (i.e., TS g= ranularity Auto-Negotiation is enabled)”.

Section 5: The first paragraph can be clearer by associating the objects= mentioned with the Path or Resv Message. Please consider to change to: = 220;The traffic Parameters for OTN-TDM capable Switching Type are carried i= n the OTN-TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in the Resv Message.” =

[Fatai]Agree and accept.

Section 6.2: “In such case” is not clear. Is that meant: = 220;When the TPN was not assigned by the ingress node”?

[Fatai] No, but your comment makes sense. I t= hink we can use “When the TPN is assigned by the ingress node” = to replace “In this case”.

Section 8, the fourth bullet mentioned of “Ingress” nodes ma= y select the procedure either from RFC4328 or this document. How about the = egress nodes? Is it assumed to follow what the ingress has chosen? (Just a = clarification question)

[Fatai] There is nothing with egress nodes. T= here is this bullet because the ingress nodes have chance to select the pro= cedure (either from RFC4328 or this document).

Nits:

Section 3, when the term “Tributary Slot” is first used (i.e= ,. A new Tributary Slot granularity (i.e., 1.25Gbps) is also described̷= 0;), please add the abbreviation.

Section 3
s/legacy interfaces/the legacy interfaces/

Section 4

s/[RFC4328] extends/[RFC4328]= extended/

Section 5: Spell NVC.

Section 5.2: For Table 2, align the column dividers

Section 5.2

s/MUST equal to/MUST equal/ o= r /MUST be equal to/

Section 6.2: delete “out” before “outgoing” in t= he first sentence of the third paragraph.

Section 6.2: s/accordingly to/according to/ (6th paragraph)

Thanks.

Young

 

--_000_7AEB3D6833318045B4AE71C2C87E8E17291BAA4Adfweml511mbschi_-- From jmh@joelhalpern.com Mon Sep 9 05:15:21 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03421E819D; Mon, 9 Sep 2013 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOH8gDOC0+mp; Mon, 9 Sep 2013 05:15:07 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68B21E8199; Mon, 9 Sep 2013 05:14:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E741B1BCBA58; Mon, 9 Sep 2013 05:14:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DC8621BCBA53; Mon, 9 Sep 2013 05:14:53 -0700 (PDT) Message-ID: <522DBBBC.7050103@joelhalpern.com> Date: Mon, 09 Sep 2013 08:14:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org, CCAMP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:15:21 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-otn-g709-info-model-11.txt Reviewer: Joel Halpern Review Date: 9-September-2013 IETF LC End Date: 19-Sept-2013 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: In general, the document needs to be consistently clear as to what gaps it identifies. Many cases are quite clear, and some are not. I will try to identify the less clear cases in the comments below. The last paragraph of section 3.2 is clear and explicit, and what I expected at the end of each section. The previous paragraph ("Specific information could be defined") is much less helpful. Moderate Issues: It is unclear if there are gaps or requirements identified by sections 3.1.1 or 3.1.2. Given that this document is about mapping to G.709, it is unclear what is intended by the usage of "LSP". My guess is that it is intended to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. It should be stated explicitly. Minor Issues: All acronyms should be expanded upon first use. In section 2 particularly, the OCh (Optical Channel?) should also be clear how that relates to the OTU and ODU being discussed. Figure 4 uses the abbreviation TSG, which is not defined, and not used elsewhere. If it is needed in the figure, it might suffice to follow "TS granularity" in the caption with "(TSG)". Section 8 on Maximum LSP Bandwdith seems to be objecting to too much information leading to a "waste of bits". While possibly of interest to the WG, that does not seem to fit a gap analysis. Similarly, section 10 on Priority Support reads as implementation advice rather than a gap needing protocol changes. Nit: From ietf@thomasclausen.org Fri Sep 13 05:41:20 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6011E81F0; Fri, 13 Sep 2013 05:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3yWNaEwVQNs; Fri, 13 Sep 2013 05:41:15 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9C021F9FB6; Fri, 13 Sep 2013 05:41:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 9E0FA1C88249; Fri, 13 Sep 2013 05:41:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id B92931C88194; Fri, 13 Sep 2013 05:41:11 -0700 (PDT) Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10B329) Message-Id: Date: Fri, 13 Sep 2013 14:41:09 +0200 Content-Transfer-Encoding: quoted-printable To: "rtg-ads@tools.ietf.org" X-Mailman-Approved-At: Fri, 13 Sep 2013 06:11:04 -0700 Cc: "rtg-dir@ietf.org" , "draft-kelsey-intarea-mesh-link-establishment.all@tools.ietf.org" , ietf@ietf.org Subject: [RTG-DIR] RtgDir Review: draft-kelsey-intarea-mesh-link-establishment-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:41:20 -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 a= s they pass through IETF last call and IESG review, and sometimes on special= request. The purpose of the review is to provide assistance to the Routing A= Ds. For more information about the Routing Directorate, please see http://ww= w.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wou= ld 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-draft-kelsey-intarea-mesh-link-establishment-05.txt=20 Reviewer: Thomas Clausen Review Date: 2013-09-13 IETF LC End Date: 2013-09-16=20 Intended Status: Proposed Standard Summary: =3D=3D=3D=3D=3D=3D=3D=3D I have some minor concerns about this document that I think should be resolv= ed before publication. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D This document is generally well written, and easy to read. I especially appreciate the the last paragraph of Section 15 "Security Consi= derations"; while it is not a new technique (as is called out), it is always= of educational value to have such "tricks" called out and explained. The document specifies several message types (or rather, one message type wi= th different "commands" - effectively, being "different message types sharin= g a similar frame format"), TLV types, and other code-points, with "mini IAN= A sections" scattered throughout the text defining these. While there is an I= ANA section in the end of the document, I would much prefer seeing mnemonics= used for code points through the text, and with the IANA section assigning v= alues for these in a single location. It makes it easier to read "FooBar mes= sage" rather than "message 42" ( or "message 42 (foobar)" ), easier to code,= and less prone to editorial snafu's. Also, as the document specifies a number of TLVs, which MAY/MUST be included= in different messages, would it be possible to provide an overview/table ce= ntralizing this information? If I was to go implement this protocol, my incl= ination would be to have the parser "know" the required/forbidden TLVs for e= ach given message type, and reject on parsing based on that - and such a tab= le/overview would help. Major Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3, "Applicability": I have an issue with the mention of MLE being blanket-applicable to also "ot= her radio standards" here. I find it to be too broad when stated unqualified= . It would be of great value if the applicability statement could point out th= e boundaries within which MLE applies. What I am getting at is, if MLE appli= es to simply /any/ L2, or if there are L2s where it either can't operate -- o= r, L2s where it can't bring any benefit. Not in terms of "it works for IEEE X= XX but not for IEEE YYY", but in terms of "If a radio standard has the chara= cteristics ZZZ and WWW, MLE applies - but if it has the characteristics QQQ,= then it doesn't". A secondary question here would be "why /radio/ standards"? Is there somethi= ng inherent in /radio/ that wouldn't also apply in - say - PLC, and which wo= uld render MLE inappropriate there? The reliance of the 802.15.4 security suite seems to indicate that there are= some requirements from an underlaying L2 that could be brought forward, for= example.... An alternative would be to scope this document narrowly to 802.15.4, which I= understand to be the targeted usecase, e.g.: "This applies to 802.15.4. It m= ay also be applicable elsewhere, but we do not know that, or how, yet." Section 8 "Message Transmission": Last paragraph before table with parameter states "Because MLE messages do n= ot require complex processing and are not relayed"....yet two paragraphs abo= ve, it was stated "...allow update messages to be forwarded multiple hops" -= does that not exactly imply that some MLE messages /are/ indeed relayed? La= ter (Section 11, 2nd paragraph) it is even specified that for that relaying,= "simple flooding" is sufficient.=20 Minor Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3 "Applicability": While the motivation for MLE, given in previous sections, is clear, it is a l= ittle unclear (by the use of the word "extends") here, in which fashion it i= s for the IETF to "extend" a L2 protocol. Would it be possible to say something like a variation over "This protocol p= rovides a support mechanism for using IEEE 802.15.4 for IPv6-based multi-hop= mesh networks". Section 4 "Overview": The first bullet point has to do with "links", presumably as defined by "pai= rs of interfaces" (although, that's not entirely clear?). The last bullet po= int, then, talks about devices. How about devices with multiple interfaces on the same radio channel? Take t= he simple case of two devices A (with interfaces a1, a2) and B (with interfa= ces b2, b2), and where links being unidirectional (or, at least, useful in a= meaningful fashion only in one direction) a1->b1 and b2->a2. Bi-directional= communication between A and B is (in principle) possible, despite no single= bidirectional link between A and B. Is this case handled by MLE, or is that= a condition where MLE doesn't / can't /shouldn't apply? Later in the docume= nt, it appears that MLE explicitly excludes non-bidirectional links, if so, c= alling that out here would be helpful. Section 4.3 and Section 12 hint at, b= ut doesn't clarify, this issue entirely. Section 5 and onwards: While this protocol may follow the usual "custom" of byte order, endianness a= nd alignment/padding, and it is, occasionally, specified for some fields in s= ome messages/TLVs, I would suggest that what is used should be stated explic= itly, once, and up-front. Section 10 "Link Configuration" and Section 11 "Parameter Dissemination": I am a little surprised by the use of "SHOULD" in this, and the following, s= ections; it would appear to me that most of the "SHOULD" really ought to be "= MUST", as they govern when messages are sent and what proper responses to th= ose messages are by receivers. Is there a subtlety that I am missing? Nits: =3D=3D=3D=3D=3D Section 7.7 "Link quality": Suggest, for RES, "MUST be set to 000 on transmission, and SHOULD be ignored= on receipt" Section 11 "Parameter Dissemination": In 2nd paragraph, it is suggested that simple flooding is sufficient for dis= semination of these messages. That is quite likely true. If I may, I would s= uggest explicitly calling out the need for implementing duplicate detection f= or the flooding operation; it won't impact interoperability how exactly such= is done (unless doing so requires adding, say, an additional sequence numbe= r to messages - if an existing and always available sequence number can be u= sed, it might help to call that out), but it will be harmful if a less-than-= vigilant implementer forgets this point. From cpignata@cisco.com Tue Sep 17 14:17:46 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84311E80FC; Tue, 17 Sep 2013 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuPzFXlRiQXU; Tue, 17 Sep 2013 14:17:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 504FF11E822A; Tue, 17 Sep 2013 14:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20821; q=dns/txt; s=iport; t=1379452661; x=1380662261; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wHvP3GCODRZKJK/58etpDxRdZSzLBOycsvAEyS6poq8=; b=NRYHn2A3lVYuMWhbb3QPxeQre0z/nd1NQ8ZIZYkwg3UUU/mLJ+bn4Wb0 vNkxc9VhoOxwlnsUcUB+ZydmHsUVTYCxOd37OVRhps7qQKAU4FGP6ka8Y ZVxtM98LR8f+glk09c38Y2Pd04nPjSi2GysWkHDjM+JXFzAJDhkTOXkXT c=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAFvGOFKtJXG+/2dsb2JhbABagwc4UsEqgR8WdIIlAQEBAwFHIAsHBQcEAgEIEQMBAQELHQcyFAkIAgQOBQgBBQ2HYgYMrFqNdo82IBECBQaDGIEAA5AmgS+HVZBFgySCKg X-IronPort-AV: E=Sophos;i="4.90,926,1371081600"; d="asc'?scan'208";a="261041042" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2013 21:17:40 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8HLHeEJ003603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Sep 2013 21:17:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 16:17:39 -0500 From: "Carlos Pignataro (cpignata)" To: Mach Chen Thread-Topic: RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOs3GDgXZdl1FtvUiXYoRKr6ztMZnKw5oA Date: Tue, 17 Sep 2013 21:17:39 +0000 Message-ID: <95067C434CE250468B77282634C96ED325F49905@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_AF168BB6-FD03-48D1-A0CC-8EEEDEB06C08"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" , "mpls@ietf.org" , "" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:17:46 -0000 --Apple-Mail=_AF168BB6-FD03-48D1-A0CC-8EEEDEB06C08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you very much for these updates, Mach! Note that the update #3 also implies a simplification of the IANA = instructions, because now you do not have any sub-TLVs that are defined = for TLV21 and not for TLV1. This resolves all my comments, thanks again! -- Carlos. On Sep 17, 2013, at 2:44 AM, Mach Chen wrote: > Hi Carlos and all, >=20 > We just uploaded a revision that mainly based on your comments. >=20 > Here are the related links of the new draft: >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp= -ping=20 >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-= 13=20 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-l= sp-ping-13=20 >=20 >=20 > The summary of the updates: > 1. BFD and inter-AS related text removed;=20 > 2. refine the definition of the "A" bit, decouple the relationship = between the "A" bit and whether test the return path; > 3. apply the tunnel sub-TLVs to TLV type 1;=20 > 4. and other editorial changes to solve the minor comments; >=20 >=20 > Hope this resolve your comments. >=20 > Many thanks > Mach >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of >> Carlos Pignataro (cpignata) >> Sent: Tuesday, September 03, 2013 7:53 AM >> To: >> Cc: ; >> draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org; = mpls@ietf.org >> Subject: [mpls] RtgDir review: >> draft-ietf-mpls-return-path-specified-lsp-ping-12.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, and sometimes on special = request. >> The purpose of the review is to provide assistance to the Routing = ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >>=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-mpls-return-path-specified-lsp-ping-12.txt >> Reviewer: Carlos Pignataro >> Review Date: 02 September 2013 >> IETF LC End Date: 04 September 2013 >> Intended Status: Proposed Standard >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the Routing >> ADs discuss these issues further with the authors. >>=20 >> Comments: >>=20 >> This document defines useful functionality. It is also generally well = written and is >> fairly detailed and comprehensive. >>=20 >> At the same time, for a set of extensions that attempts to provide = more >> determinism in a failure detection protocol, I believe there is still = significant >> ambiguity in a few underspecified elements and behaviors. >>=20 >> Although I have marked a number of "major" issues, some of them = should be >> relatively easy to fix. Others, however, pose somewhat fundamental = questions. >>=20 >> I hope these review comments are clear and useful! >>=20 >>=20 >> Major Issues: >>=20 >> The first major issue that I would like to have discussed is the = usage of these >> extensions for BFD for MPLS bootstrapping. The Abstract in this = document sets to >> prove that the extensions thereby defined can be used for BFD for = MPLS >> bootstrapping. However, I believe that the document is underdefined = to make >> that claim in the Abstract. >>=20 >> There is somewhat of a contradiction in that, to make BFD for MPLS >> bootstrapping using these extensions work, specific protocol = definitions (i.e., >> 2119 language in the BFD for MPLS bootstrapping state machine) need = to take >> place in BFD, as per draft-chen-mpls-bfd-enhancement. However, that >> document is only an Informative reference in this document. It = appears to me >> that, without draft-chen-mpls-bfd-enhancement, the claim of the = Abstract >> cannot be fulfilled. By way of process, I also believe this might = have not been >> tested with the BFD working group. >>=20 >> In any case, the only mention of BFD for MPLS bootstrapping in this = document is >> by passing as an example in Section 3.3.1. Due to all of these = reasons, I believe >> this doc should remove the goal of BFD improvements al together or = majorly >> qualify and downgrade the usage with BFD. >>=20 >> A second major issue is a question: Given how RFC 4379 defines the = reply mode 4 >> ("Reply via application level control channel"). Given a = bidirectional LSP. Doesn't >> using GAL+GACh and Reply Mode #4 solve this whole problem? Why is = that one >> not discussed? Basically, RFC 4379 uses RFC 5085 as the reference = example of >> reply mode #4. Since RFC 5586 generalizes the VCCV associated channel = to LSPs, >> then we have a generic control channel to be used with reply mode #4. >>=20 >> Also, what's the relationship to RFC 6426 and TLV 16? Another return = path? >>=20 >> A third major issue has to do with the treatment of Inter-AS = scenarios in this draft. >> In Sections 2.1 and 2.2, this draft is implicitly presented as a = solution for MPLS >> Echo in "inter-domain LSPs" and "inter-domain/inter-AS LSP". The = problems in >> these cases are more convoluted than what this draft describes, and = includes lack >> of addressing context and initiator address unknown (not only that = the IP Router >> Alert label might not work in the boundary). I believe that this = draft should not >> call those cases since are not solved by the addition of a new reply = mode. >>=20 >> A fourth major issue has to do with the use of IP Path versus LSP = Path, as per a >> number of Minor issues described below that, together, amount to a = major. See >> minor issues section. >>=20 >> A fifth major issue concerns itself with ECMP upon return. Saying = that the >> response should be sent over the LSP with target FEC Stack of LDP = IPv4 prefix of >> 192.0.2.27/32 is not enough, as there are potentially multiple paths = throughout. I >> believe this topic should be discussed. In the Echo direction, this = is solved with >> the Downstream Mapping mechanics. That is overkill for the response, = but again, >> multi path can give false negatives the same deeming the whole = solution >> unusable (since at the end it cannot provide the prescriptiveness). >>=20 >> A last major issue concerns itself with Security considerations. = Using these >> extensions, a node can instruct another node to send replies out of = any LSP, >> including LSPs that do not go back to the source. Further, an = attacker can send >> MPLS Echo nodes to many nodes vectoring responses to a node target of = a DDoS >> attack. The security considerations briefly touches this point and = says that "the >> return path LSP MUST have destination to the same node where the = forward >> path is from". However, it is not clear how a node can actually = evaluate and >> actually verify and enforce this MUST. It is quite possible that this = check is not >> possible to make. >>=20 >>=20 >> Minor Issues: >>=20 >> Does this document update RFC 4379? >>=20 >> 1. Introduction >>=20 >> The procedures defined in this document >> currently only apply to "ping" mode. The "traceroute" mode is out = of >> scope for this document. >>=20 >> I am note sure if this is major or minor -- but separating traceroute = mode as out >> of scope seems like a huge gap. Are there specific issues with using = these >> extensions in traceroute mode? The last hop of a traceroute is = equivalent to a >> ping -- can these extensions be used there? >>=20 >>=20 >> The defined extensions can also be >> utilized for creating a single Bidirectional Forwarding Detection >> (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a >> pair of unidirectional LSPs (one for each direction). >>=20 >> For BFD for bidirectional LSPs, there is no need to use LSP Ping = bootstrapping, >> since the context of the session can be directly gleaned as defined = in RFC 5885. In >> other words, single-hop BFD initialization is enough -- why would = someone want >> to use bootstrapping with LSP Ping, and then specific extensions, = when the >> context of the BFD discriminators is understood from the label = (again, as per RFC >> 5885)? >>=20 >> In this document, the term bidirectional LSP includes the co-routed >> bidirectional LSP defined in [RFC3945] and the associated >> bidirectional LSP that is constructed from a pair of unidirectional >> LSPs (one for each direction), and which are associated with one >> another at the LSP's ingress/egress points [RFC5654]. The = mechanisms >> defined in this document can apply to both IP/MPLS and MPLS = Transport >> Profile (MPLS-TP) scenarios. >>=20 >> Two key questions: >> 1. What about Pseudowires? >> 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP = control >> plane (to run LSP Ping)? >>=20 >>=20 >> 2. Problem Statements and Solution Overview >>=20 >> MPLS LSP Ping is defined in [RFC4379]. It can be used to detect = data >> path failures in all MPLS LSPs, and was originally designed for >> unidirectional LSPs. >>=20 >> Where does RFC4379 limits its scope to unidirectional LSPs? >>=20 >> And in any case, the use modes 2 or 3 cannot guarantee the delivery >> of echo responses through an IP network that is fundamentally >> unreliable. The failure to deliver echo response messages can lead >> to false negatives making it appear that the LSP has failed. >>=20 >> Allowing the ingress LSR to control the path used for echo reply >> messages, and in particular forcing those messages to use an LSP >> rather than being sent through the IP network, enables an operator = to >> apply an extra level of deterministic process to the LSP Ping test. >>=20 >> These two paragraphs seems to show a gross misconception on how reply = works. >> =46rom 4379, the reply with mode #1 does not need to be sent over IP = without >> MPLS. It can very well be sent over an LSP. In fact, given the right = source IP >> address in the LSP Ping Echo, the right return LSP can be chosen. = This needs to be >> better explained so as not to "hype" the solution presented in the = document. >>=20 >> 3. Extensions >>=20 >> In addition, two new TLVs, the Reply Path TLV and Reply Traffic = Class >> (TC) [RFC5462] TLV, are defined in this document. >>=20 >> Given that the "Reply Path TLV" specifies an LSP and not a Path, I = strongly suggest >> the TLV be renamed to more specifically describe its functionality. >>=20 >>=20 >> 0x0004 The specified Reply Path was not found, the echo >> reply was sent via other LSP >> 0x0005 The specified Reply Path was not found, the echo >> reply was sent via IP path >>=20 >> It is not clear what an IP path is, when sending an LSP Echo response = as an IP >> datagram can be sent labeled as an LSP. Also, I assume these are = without Router >> Alert, right? >>=20 >> A (Alternative path): the egress LSR MUST select a non-default path >> as the return path. This is very useful when reverse default path >> problems are suspected which can be confirmed when the echo reply = is >> forced to follow a non-default return path. Here, the default path >> refers to the path that the egress LSR will use to send the echo >> reply when the return path is not explicitly specified as defined = in >> this document. If A bit is set, there is no need to carry any >> specific reply path sub-TLVs, and when received, the sub-TLVs = SHOULD >> be ignored. >>=20 >> Do all implementations understand the same thing as "Default"? This = seems >> underspecified. >>=20 >> Also, say that an LSP Ping is sent with source IP address as = 192.0.2.1 over an LSP. A >> "default" return LSP is perhaps an LSP where 192.0.2.1/32 points to. = How would a >> non-default be in this case? Send it to a wrong LSR? What should = responding >> router choose in this case? How can it choose a non-default without = the >> specification of an actual LSP? >>=20 >> B (Bidirectional): the return path is required to follow the = reverse >> direction of the tested bidirectional LSP. If B bit is set, there = is >> no need to carry any specific reply path sub-TLVs, and when = received, >> the sub-TLVs SHOULD be ignored. >>=20 >> Is this default or non-default when this TLV is not used (pre-this = spec)? >>=20 >> 3.2. Reply Path (RP) TLV >>=20 >> When reply mode (!=3D 5) and Reply Path TLV is received, which takes = precedence >> and what is the procedure? >>=20 >>=20 >> 3.3. Reply Path sub-TLVs >>=20 >> In addition, this document defines three new sub-TLVs: IPv4 RSVP >> Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel = sub-TLV. >>=20 >> It is not clear why these are specified. The text does not seem to = explain the >> need, nor why these do not need to be specified for the TLV 1. >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | MUST be zero |S|P| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Further, "primary" and "secondary" are not defined. Which = specifications >> explains what is a primary and a secondary? >>=20 >> 3.3.3. Static Tunnel sub-TLV >>=20 >> Again, why is this not specified for the Echo as well? >>=20 >> 4. Theory of Operation >>=20 >> When the echo reply message is intended to test the return MPLS LSP >> path(when the A bit is not set in the previous received echo = request >> message), the destination IP address of the echo reply message MUST >> never be used in a forwarding decision. >>=20 >> Is this really the meaning of the "A-bit"? >>=20 >> To avoid this possibility >> the destination IP address of the echo reply message that is >> transmitted along the specified return path MUST be set to numbers >> from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, = and >> the IP TTL MUST be set 1, and the TTL in the outermost label MUST = be >> set to 255. >>=20 >> 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be = 0:0:0:0:0:FFFF:7F00/104 or >> 0:0:0:0:0:FFFF:127.0.0.0/104 >>=20 >> Of course when the echo reply message is not intended >> for testing the specified return path (when the A bit is set in the >> previous received echo request message) , the procedures defined in >> [RFC4379] (the destination IP address is copied from the source IP >> address) apply unchanged. >>=20 >> Does this mean that "Alternate" and "Non Default" are actually to = follow the >> *Default* procedures from RFC 4379? >>=20 >> 4.3. Sending an Echo Reply >>=20 >> and the IP TTL MUST be set to 1, the >> TTL in the outermost label MUST be set to 255. >>=20 >> Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv? >>=20 >> 6.4. Reply Path Return Code >>=20 >> There seems to be a contradiction in this: >>=20 >> 0x0006-0xfffb Not allocated, allocated via Standard Action >> 0xfffc-0xffff Experimental Use >>=20 >> The range of 0x0008-0xfffb is not allocated and reserved for future >> extensions and is allocated via Standard Action, the range of = 0xfffc- >> 0xffff is for Experimental Use. >>=20 >> Overall -- what is the interaction with = draft-ietf-mpls-remote-lsp-ping? Note also >> that document specifies a reply mode with the same value of "5". >>=20 >> Also, this document does not seem to define backward compatibility >> considerations. What happens if a pre-specification router receives a = Reply Mode >> #5? The generic behavior of RFC 4379 is to respond with a generic = "malformed >> echo" error -- should there be a sub-code for Unknown reply mode -- = in which >> case it's a bit ironic to reply by some other mode -- to signal the = specific issue for >> future reply codes? >>=20 >> A final minor issue: this specification defines a new behavior for an = echo reply in >> which the Echo Reply message is destined to a loopback IP Address. If = the return >> path is broken, a middle router will think the packet is destined to = itself (because >> of the loopback) -- the behavior in this case is undefined and can = result in funny >> behaviors, for example an ICMP port unreachable sent to the source or = weirder. >>=20 >> A last minor issue relates the IANA requests -- section 6.2 is = already fairly >> complex, yet it does not speak to the following: What happens when = sub-TLVs >> for TLV1 are defined? What is checked to make sure that this new = sub-TLV applies >> to TLV21, and how? Does this update IANA allocations for RFC 4379? = Also, a >> sub-TLV with sub-Type 16384 can be assigned to TLV1 with = specification required, >> but needs Standards action for TLV 21? And from which of these eight = ranges are >> sub-Types of Section 6.2.1 assigned, and why are not applicable to = TLV Type 1 and >> Type 16? >>=20 >> I would include in the IANA instructions details within TLV 1 about = the changes >> and "directly copied" to TLV21. >>=20 >>=20 >> Nits: >>=20 >> Abstract >>=20 >> This document defines extensions to the failure-detection protocol >> for Multiprotocol Label Switching (MPLS) Label Switched Paths = (LSPs) >> known as "LSP Ping" that allow selection of the LSP to use for the >> echo reply return path. >>=20 >> The abstract is key in that its legibility sets for the whole = document. These same >> comments apply to the Introduction. >>=20 >> First, to be consistent with RFC4379, I'd qualify adding = "...extensions to the >> *data-plane* failure-detection protocol...". >>=20 >> Second, this is a very long sentence that reads better split in two: = "known as "LSP >> Ping". These extensions allow selection of the" >>=20 >>=20 >> The Reply via Specified Path mode is used to request that the = remote >> LSR receiving the LSP Ping echo request message sends back the echo >> reply message along the specified paths carried in the Reply Path >> TLV. >>=20 >> There is no such a thing as "LSP Ping echo request message" in RFC = 4379. The >> same happens throughout the document, and should be fixed. >>=20 >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reply Path TLV Type | Length = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reply Path return code | Flag = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> These are "Flags" (plural). >>=20 >> 0x0002 One or more of the sub-TLVs in Reply Path TLV >> was not understood >>=20 >> s/was/were/ >>=20 >>=20 >> Additionally, idnits 2.12.17 finds the following: >>=20 >> ** There is 1 instance of too long lines in the document, the = longest one >> being 1 character in excess of 72. >>=20 >> =3D=3D Unused Reference: 'RFC6426' is defined on line 873, but no = explicit >> reference was found in the text >>=20 >>=20 >> I hope these are clear and useful! >>=20 >> Thank you, >>=20 >> Carlos Pignataro. >=20 --Apple-Mail=_AF168BB6-FD03-48D1-A0CC-8EEEDEB06C08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlI4xvIACgkQtfDPGTp3USxLrwCfU+XpJpeouMWKx3a9cNbfdv50 XCYAn1F4sjY/Iht0msMIJsSMLWLw6Ltk =GEKT -----END PGP SIGNATURE----- --Apple-Mail=_AF168BB6-FD03-48D1-A0CC-8EEEDEB06C08-- From mach.chen@huawei.com Mon Sep 16 23:44:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B943211E8211; Mon, 16 Sep 2013 23:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mpYPYqRvvoS; Mon, 16 Sep 2013 23:44:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7436911E81FD; Mon, 16 Sep 2013 23:44:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVN63113; Tue, 17 Sep 2013 06:44:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 17 Sep 2013 07:43:49 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 17 Sep 2013 07:44:16 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.31]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Tue, 17 Sep 2013 14:44:08 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , "" Thread-Topic: RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOqDebrKO6OJQx3ESbiGHTNfRsN5nJj1dA Date: Tue, 17 Sep 2013 06:44:08 +0000 Message-ID: References: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED325E86B07@xmb-aln-x02.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 25 Sep 2013 08:06:18 -0700 Cc: "" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 06:44:29 -0000 Hi Carlos and all, We just uploaded a revision that mainly based on your comments. Here are the related links of the new draft: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping=20 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-1= 3=20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-13=20 The summary of the updates: 1. BFD and inter-AS related text removed;=20 2. refine the definition of the "A" bit, decouple the relationship between = the "A" bit and whether test the return path; 3. apply the tunnel sub-TLVs to TLV type 1;=20 4. and other editorial changes to solve the minor comments; Hope this resolve your comments. Many thanks Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Carlos Pignataro (cpignata) > Sent: Tuesday, September 03, 2013 7:53 AM > To: > Cc: ; > draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org; mpls@i= etf.org > Subject: [mpls] RtgDir review: > draft-ietf-mpls-return-path-specified-lsp-ping-12.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, and sometimes on special req= uest. > The purpose of the review is to provide assistance to the Routing ADs. Fo= r 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-mpls-return-path-specified-lsp-ping-12.txt > Reviewer: Carlos Pignataro > Review Date: 02 September 2013 > IETF LC End Date: 04 September 2013 > Intended Status: Proposed Standard >=20 > Summary: >=20 > I have significant concerns about this document and recommend that the Ro= uting > ADs discuss these issues further with the authors. >=20 > Comments: >=20 > This document defines useful functionality. It is also generally well wri= tten and is > fairly detailed and comprehensive. >=20 > At the same time, for a set of extensions that attempts to provide more > determinism in a failure detection protocol, I believe there is still sig= nificant > ambiguity in a few underspecified elements and behaviors. >=20 > Although I have marked a number of "major" issues, some of them should be > relatively easy to fix. Others, however, pose somewhat fundamental questi= ons. >=20 > I hope these review comments are clear and useful! >=20 >=20 > Major Issues: >=20 > The first major issue that I would like to have discussed is the usage of= these > extensions for BFD for MPLS bootstrapping. The Abstract in this document = sets to > prove that the extensions thereby defined can be used for BFD for MPLS > bootstrapping. However, I believe that the document is underdefined to ma= ke > that claim in the Abstract. >=20 > There is somewhat of a contradiction in that, to make BFD for MPLS > bootstrapping using these extensions work, specific protocol definitions = (i.e., > 2119 language in the BFD for MPLS bootstrapping state machine) need to ta= ke > place in BFD, as per draft-chen-mpls-bfd-enhancement. However, that > document is only an Informative reference in this document. It appears to= me > that, without draft-chen-mpls-bfd-enhancement, the claim of the Abstract > cannot be fulfilled. By way of process, I also believe this might have no= t been > tested with the BFD working group. >=20 > In any case, the only mention of BFD for MPLS bootstrapping in this docum= ent is > by passing as an example in Section 3.3.1. Due to all of these reasons, I= believe > this doc should remove the goal of BFD improvements al together or majorl= y > qualify and downgrade the usage with BFD. >=20 > A second major issue is a question: Given how RFC 4379 defines the reply = mode 4 > ("Reply via application level control channel"). Given a bidirectional LS= P. Doesn't > using GAL+GACh and Reply Mode #4 solve this whole problem? Why is that on= e > not discussed? Basically, RFC 4379 uses RFC 5085 as the reference example= of > reply mode #4. Since RFC 5586 generalizes the VCCV associated channel to = LSPs, > then we have a generic control channel to be used with reply mode #4. >=20 > Also, what's the relationship to RFC 6426 and TLV 16? Another return path= ? >=20 > A third major issue has to do with the treatment of Inter-AS scenarios in= this draft. > In Sections 2.1 and 2.2, this draft is implicitly presented as a solution= for MPLS > Echo in "inter-domain LSPs" and "inter-domain/inter-AS LSP". The problems= in > these cases are more convoluted than what this draft describes, and inclu= des lack > of addressing context and initiator address unknown (not only that the IP= Router > Alert label might not work in the boundary). I believe that this draft sh= ould not > call those cases since are not solved by the addition of a new reply mode= . >=20 > A fourth major issue has to do with the use of IP Path versus LSP Path, a= s per a > number of Minor issues described below that, together, amount to a major.= See > minor issues section. >=20 > A fifth major issue concerns itself with ECMP upon return. Saying that th= e > response should be sent over the LSP with target FEC Stack of LDP IPv4 pr= efix of > 192.0.2.27/32 is not enough, as there are potentially multiple paths thro= ughout. I > believe this topic should be discussed. In the Echo direction, this is so= lved with > the Downstream Mapping mechanics. That is overkill for the response, but = again, > multi path can give false negatives the same deeming the whole solution > unusable (since at the end it cannot provide the prescriptiveness). >=20 > A last major issue concerns itself with Security considerations. Using th= ese > extensions, a node can instruct another node to send replies out of any L= SP, > including LSPs that do not go back to the source. Further, an attacker ca= n send > MPLS Echo nodes to many nodes vectoring responses to a node target of a D= DoS > attack. The security considerations briefly touches this point and says t= hat "the > return path LSP MUST have destination to the same node where the forward > path is from". However, it is not clear how a node can actually evaluate = and > actually verify and enforce this MUST. It is quite possible that this che= ck is not > possible to make. >=20 >=20 > Minor Issues: >=20 > Does this document update RFC 4379? >=20 > 1. Introduction >=20 > The procedures defined in this document > currently only apply to "ping" mode. The "traceroute" mode is out of > scope for this document. >=20 > I am note sure if this is major or minor -- but separating traceroute mod= e as out > of scope seems like a huge gap. Are there specific issues with using thes= e > extensions in traceroute mode? The last hop of a traceroute is equivalent= to a > ping -- can these extensions be used there? >=20 >=20 > The defined extensions can also be > utilized for creating a single Bidirectional Forwarding Detection > (BFD)[RFC5880], [RFC5884] session for a bidirectional LSP or for a > pair of unidirectional LSPs (one for each direction). >=20 > For BFD for bidirectional LSPs, there is no need to use LSP Ping bootstra= pping, > since the context of the session can be directly gleaned as defined in RF= C 5885. In > other words, single-hop BFD initialization is enough -- why would someone= want > to use bootstrapping with LSP Ping, and then specific extensions, when th= e > context of the BFD discriminators is understood from the label (again, as= per RFC > 5885)? >=20 > In this document, the term bidirectional LSP includes the co-routed > bidirectional LSP defined in [RFC3945] and the associated > bidirectional LSP that is constructed from a pair of unidirectional > LSPs (one for each direction), and which are associated with one > another at the LSP's ingress/egress points [RFC5654]. The mechanisms > defined in this document can apply to both IP/MPLS and MPLS Transport > Profile (MPLS-TP) scenarios. >=20 > Two key questions: > 1. What about Pseudowires? > 2. How can this apply to MPLS-TP when MPLS-TP might not have an IP contro= l > plane (to run LSP Ping)? >=20 >=20 > 2. Problem Statements and Solution Overview >=20 > MPLS LSP Ping is defined in [RFC4379]. It can be used to detect data > path failures in all MPLS LSPs, and was originally designed for > unidirectional LSPs. >=20 > Where does RFC4379 limits its scope to unidirectional LSPs? >=20 > And in any case, the use modes 2 or 3 cannot guarantee the delivery > of echo responses through an IP network that is fundamentally > unreliable. The failure to deliver echo response messages can lead > to false negatives making it appear that the LSP has failed. >=20 > Allowing the ingress LSR to control the path used for echo reply > messages, and in particular forcing those messages to use an LSP > rather than being sent through the IP network, enables an operator to > apply an extra level of deterministic process to the LSP Ping test. >=20 > These two paragraphs seems to show a gross misconception on how reply wor= ks. > From 4379, the reply with mode #1 does not need to be sent over IP withou= t > MPLS. It can very well be sent over an LSP. In fact, given the right sour= ce IP > address in the LSP Ping Echo, the right return LSP can be chosen. This ne= eds to be > better explained so as not to "hype" the solution presented in the docume= nt. >=20 > 3. Extensions >=20 > In addition, two new TLVs, the Reply Path TLV and Reply Traffic Class > (TC) [RFC5462] TLV, are defined in this document. >=20 > Given that the "Reply Path TLV" specifies an LSP and not a Path, I strong= ly suggest > the TLV be renamed to more specifically describe its functionality. >=20 >=20 > 0x0004 The specified Reply Path was not found, the echo > reply was sent via other LSP > 0x0005 The specified Reply Path was not found, the echo > reply was sent via IP path >=20 > It is not clear what an IP path is, when sending an LSP Echo response as = an IP > datagram can be sent labeled as an LSP. Also, I assume these are without = Router > Alert, right? >=20 > A (Alternative path): the egress LSR MUST select a non-default path > as the return path. This is very useful when reverse default path > problems are suspected which can be confirmed when the echo reply is > forced to follow a non-default return path. Here, the default path > refers to the path that the egress LSR will use to send the echo > reply when the return path is not explicitly specified as defined in > this document. If A bit is set, there is no need to carry any > specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD > be ignored. >=20 > Do all implementations understand the same thing as "Default"? This seems > underspecified. >=20 > Also, say that an LSP Ping is sent with source IP address as 192.0.2.1 ov= er an LSP. A > "default" return LSP is perhaps an LSP where 192.0.2.1/32 points to. How = would a > non-default be in this case? Send it to a wrong LSR? What should respondi= ng > router choose in this case? How can it choose a non-default without the > specification of an actual LSP? >=20 > B (Bidirectional): the return path is required to follow the reverse > direction of the tested bidirectional LSP. If B bit is set, there is > no need to carry any specific reply path sub-TLVs, and when received, > the sub-TLVs SHOULD be ignored. >=20 > Is this default or non-default when this TLV is not used (pre-this spec)? >=20 > 3.2. Reply Path (RP) TLV >=20 > When reply mode (!=3D 5) and Reply Path TLV is received, which takes prec= edence > and what is the procedure? >=20 >=20 > 3.3. Reply Path sub-TLVs >=20 > In addition, this document defines three new sub-TLVs: IPv4 RSVP > Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. >=20 > It is not clear why these are specified. The text does not seem to explai= n the > need, nor why these do not need to be specified for the TLV 1. >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MUST be zero |S|P| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Further, "primary" and "secondary" are not defined. Which specifications > explains what is a primary and a secondary? >=20 > 3.3.3. Static Tunnel sub-TLV >=20 > Again, why is this not specified for the Echo as well? >=20 > 4. Theory of Operation >=20 > When the echo reply message is intended to test the return MPLS LSP > path(when the A bit is not set in the previous received echo request > message), the destination IP address of the echo reply message MUST > never be used in a forwarding decision. >=20 > Is this really the meaning of the "A-bit"? >=20 > To avoid this possibility > the destination IP address of the echo reply message that is > transmitted along the specified return path MUST be set to numbers > from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127/104 for IPv6, and > the IP TTL MUST be set 1, and the TTL in the outermost label MUST be > set to 255. >=20 > 0:0:0:0:0:FFFF:127/104 is ambiguous. This needs to be 0:0:0:0:0:FFFF:7F00= /104 or > 0:0:0:0:0:FFFF:127.0.0.0/104 >=20 > Of course when the echo reply message is not intended > for testing the specified return path (when the A bit is set in the > previous received echo request message) , the procedures defined in > [RFC4379] (the destination IP address is copied from the source IP > address) apply unchanged. >=20 > Does this mean that "Alternate" and "Non Default" are actually to follow = the > *Default* procedures from RFC 4379? >=20 > 4.3. Sending an Echo Reply >=20 > and the IP TTL MUST be set to 1, the > TTL in the outermost label MUST be set to 255. >=20 > Should this follow draft-ietf-mpls-lsp-ping-ttl-tlv? >=20 > 6.4. Reply Path Return Code >=20 > There seems to be a contradiction in this: >=20 > 0x0006-0xfffb Not allocated, allocated via Standard Action > 0xfffc-0xffff Experimental Use >=20 > The range of 0x0008-0xfffb is not allocated and reserved for future > extensions and is allocated via Standard Action, the range of 0xfffc- > 0xffff is for Experimental Use. >=20 > Overall -- what is the interaction with draft-ietf-mpls-remote-lsp-ping? = Note also > that document specifies a reply mode with the same value of "5". >=20 > Also, this document does not seem to define backward compatibility > considerations. What happens if a pre-specification router receives a Rep= ly Mode > #5? The generic behavior of RFC 4379 is to respond with a generic "malfor= med > echo" error -- should there be a sub-code for Unknown reply mode -- in wh= ich > case it's a bit ironic to reply by some other mode -- to signal the speci= fic issue for > future reply codes? >=20 > A final minor issue: this specification defines a new behavior for an ech= o reply in > which the Echo Reply message is destined to a loopback IP Address. If the= return > path is broken, a middle router will think the packet is destined to itse= lf (because > of the loopback) -- the behavior in this case is undefined and can result= in funny > behaviors, for example an ICMP port unreachable sent to the source or wei= rder. >=20 > A last minor issue relates the IANA requests -- section 6.2 is already fa= irly > complex, yet it does not speak to the following: What happens when sub-TL= Vs > for TLV1 are defined? What is checked to make sure that this new sub-TLV = applies > to TLV21, and how? Does this update IANA allocations for RFC 4379? Also, = a > sub-TLV with sub-Type 16384 can be assigned to TLV1 with specification re= quired, > but needs Standards action for TLV 21? And from which of these eight rang= es are > sub-Types of Section 6.2.1 assigned, and why are not applicable to TLV Ty= pe 1 and > Type 16? >=20 > I would include in the IANA instructions details within TLV 1 about the c= hanges > and "directly copied" to TLV21. >=20 >=20 > Nits: >=20 > Abstract >=20 > This document defines extensions to the failure-detection protocol > for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > known as "LSP Ping" that allow selection of the LSP to use for the > echo reply return path. >=20 > The abstract is key in that its legibility sets for the whole document. T= hese same > comments apply to the Introduction. >=20 > First, to be consistent with RFC4379, I'd qualify adding "...extensions t= o the > *data-plane* failure-detection protocol...". >=20 > Second, this is a very long sentence that reads better split in two: "kno= wn as "LSP > Ping". These extensions allow selection of the" >=20 >=20 > The Reply via Specified Path mode is used to request that the remote > LSR receiving the LSP Ping echo request message sends back the echo > reply message along the specified paths carried in the Reply Path > TLV. >=20 > There is no such a thing as "LSP Ping echo request message" in RFC 4379. = The > same happens throughout the document, and should be fixed. >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reply Path TLV Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reply Path return code | Flag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > These are "Flags" (plural). >=20 > 0x0002 One or more of the sub-TLVs in Reply Path TLV > was not understood >=20 > s/was/were/ >=20 >=20 > Additionally, idnits 2.12.17 finds the following: >=20 > ** There is 1 instance of too long lines in the document, the longest o= ne > being 1 character in excess of 72. >=20 > =3D=3D Unused Reference: 'RFC6426' is defined on line 873, but no expli= cit > reference was found in the text >=20 >=20 > I hope these are clear and useful! >=20 > Thank you, >=20 > Carlos Pignataro. From sergio.belotti@alcatel-lucent.com Thu Sep 26 01:50:34 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32CD21E804B; Thu, 26 Sep 2013 01:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71UKlAygK2Jc; Thu, 26 Sep 2013 01:50:28 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09A21E8096; Thu, 26 Sep 2013 01:50:26 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8Q8oLOo025645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Sep 2013 03:50:22 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8Q8oKoe003204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 10:50:20 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 26 Sep 2013 10:50:20 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: "Joel M. Halpern" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Thread-Index: AQHOrVZHxRDnDyHdEEyWPohPw9hLvZnXx7Ag Date: Thu, 26 Sep 2013 08:50:19 +0000 Message-ID: References: <522DBBBC.7050103@joelhalpern.com> In-Reply-To: <522DBBBC.7050103@joelhalpern.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Thu, 26 Sep 2013 01:56:45 -0700 Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 08:50:34 -0000 Hello Joel, thanks for your comments. Below in line our reply, marked "authors". Best Regards The authors Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Joe= l M. Halpern Inviato: luned=EC 9 settembre 2013 14:15 A: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-ccamp-otn-g709-info= -model.all@tools.ietf.org; CCAMP WG Oggetto: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Hello, I have been selected as the Routing Directorate reviewer for this draft.=20 The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-otn-g709-info-model-11.txt Reviewer: Joel Halpern Review Date: 9-September-2013 IETF LC End Date: 19-Sept-2013 Intended Status: Informational Summary: I have some minor concerns about this document that I think should= be resolved before publication. Comments: In general, the document needs to be consistently clear as to what gap= s it identifies. Many cases are quite clear, and some are not. I will try= to identify the less clear cases in the comments below. The last paragraph= of section 3.2 is clear and explicit, and what I expected at the end of ea= ch section. The previous paragraph ("Specific information could be defined= ") is much less helpful. Moderate Issues: It is unclear if there are gaps or requirements identified by sections= 3.1.1 or 3.1.2. Authors> The scope of both paragraph are not to suggest gaps or requirement= s but to describe data plane characteristics that are useful in the follow = of the doc. Particularly they introduce the relationship between payload ty= pe concept in OTN and the Tributary Slot granularity, and this relation is = reported in the session 3.2 in which specific CP requirements are defined. Given that this document is about mapping to G.709, it is unclear what= is intended by the usage of "LSP". My guess is that it is intended to mea= n Label Switch Paths set up by GMPLS to carry OTU/UDU elements.=20 It should be stated explicitly. Authors> We can specify this as you suggest even if we considered not neces= sary to specify the usage of LSP in relation to data plane specific. Encodi= ng type should cope with this issue.=20 Minor Issues: All acronyms should be expanded upon first use. Authors> OK In section 2 particularly, the OCh (Optical Channel?) should also be c= lear how that relates to the OTU and ODU being discussed. Authors> OK, you're right Figure 4 uses the abbreviation TSG, which is not defined, and not used= elsewhere. If it is needed in the figure, it might suffice to follow "TS = granularity" in the caption with "(TSG)". Authors> We can add TSG at the beginning of chapter 3.2 when TS granularity= is mentioned Section 8 on Maximum LSP Bandwdith seems to be objecting to too much i= nformation leading to a "waste of bits". While possibly of interest to the= WG, that does not seem to fit a gap analysis. Similarly, section 10 on Priority Support reads as implementation advi= ce rather than a gap needing protocol changes. Authors> The basic scope of the draft is to underline gaps, and even if wha= t described in Ch.8 and 10, do not prevent routing to work , it is suggeste= d here an requirement for optimization based on OTN requirements (e.g. no n= eed to advertise fixed ODU container Max LSP BW since implicit in the signa= l type.) Nit: _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From matthew.bocci@alcatel-lucent.com Thu Sep 26 07:57:32 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C7411E8107; Thu, 26 Sep 2013 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Ioh4I-2TQG; Thu, 26 Sep 2013 07:56:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3B54421F90FD; Thu, 26 Sep 2013 07:56:49 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8QEujd0023581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Sep 2013 09:56:46 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r8QEuiQu029784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 16:56:44 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 26 Sep 2013 16:56:44 +0200 From: "Bocci, Matthew (Matthew)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt Thread-Index: AQHOusidkjPsQsSshkKENDZ/YCqdgQ== Date: Thu, 26 Sep 2013 14:56:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_CE6A09B851BF0matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-mcast@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:57:32 -0000 --_000_CE6A09B851BF0matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Since IETF LC has ended for this draft, I am primarily providing comments t= o aid the ADs, and I hope the authors will also take them into consideration = to improve the readability of the draft. Document: draft-ietf-l2vpn-vpls-mcast-14.txt Reviewer: Matthew Bocci Review Date: 26 September 2013 IETF LC End Date: date-if-known Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: The draft appears to be complete and accurate form a technical perspective.= However, the style of the draft and the density of the text make it quite difficult = to read at times. It took several passes of some sections of the document, and= returning to earlier sections, to properly follow the text. I believe this is because= the basic multicast architecture could be better-explained earlier in the draft. Major Issues: No major issues found. Minor Issues: 1) The draft contains both introductory architectural / framework descriptions, and more detailed specifications of the protocols required to efficiently support multicast in VPLS. However, the introductory sectio= ns (e.g. the overview in section 5) are presented in the form of extremely dense text, = and while they seem to be trying to explain architectural concepts, they do not use = a single diagram to help the reader visualise the solutions in the draft. In fact, = the first figures illustrating the protocol hierarchies and relationships do not app= ear until the label stacks are described in Section 13 on page 43. I think inserting some figures in section 5 to illustrate the different mu= lticast schemes, and also moving the data forwarding section earlier in the docume= nt, would greatly help the reader. 2) Cross-references in the text use the title of the referenced section, bu= t do not include a section number. Personally, I found that this made the draft much= more difficult to navigate than it should be. It would help to add section numbers to each= instance of a cross reference. Nits: Abstract, 2nd paragraph, 1st sentence: s/solution/solutions Section 3: This section would be clearer of it was in tabular form, in a si= milar manner to other RFCs. You could also add short (one sentence) definitions of 'Inclusive Trees', '= Selective Trees', and 'Aggregation'. Sec 4. Introduction: 3rd para: s/when large/when a large Sec 4. Introduction: 5th para: s/RSVP-PE/RSVP-TE Sec 5.2. BGP-Based VPLS Membership Auto-Discovery: 1st para: s/that have membership these/that have membership of these Sec 5.4 Advertising P-Multicast..., 2nd para: Grammar: The decision to bind a set of VPLS instances or customer multicast= group is local to the ingress PE matter, / The decision to bind a set of VPLS instan= ces or customer multicast groups is a local matter for the ingress PE , Sec 5.4 Advertising P-Multicast..., 3rd para: s/be included. / be included Section 5.5 Aggregation: The following algorithm is hard to parse: + ((Average number of VPLS instances on a PE / Aggregation Factor) * number of PEs) / (Average number of P-Multicast trees that transit a given P router) I think this could be restated in a more readable manner. Just as an exampl= e: AveVPLS NPE ------- X -------- Aggr AvePTree Where: AveVPLS is the average number of VPLS instances on a PE Aggr is the aggregation factor NPE is the number of PEs AvePTree is the average number of P-multicast that transit a giv= en P-router Section 6: Inter-AS Inclusive P-Multicast..., 5th Paragraph This paragraph mentions FEC128 and FEC 129. It would be better to call thes= e by their formal names used in RFC4447 i.e. The PWid FEC and the Generalized PWid FEC --_000_CE6A09B851BF0matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0DEE01CFF6B6B543AB429FA4AECEFD2A@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hello,

I have been selected as the Routing Directorate reviewer for this draf= t.
The Routing Directorate seeks to review all routing or routing-related=
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide<= /div>
assistance to the Routing ADs. For more information about the Routing<= /div>
Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Since IETF LC has ended for this draft, I am primarily providing comme= nts to 
aid the ADs, and I hope the authors will also take them into considera= tion to improve 
the readability  of the draft.

Document: draft-ietf-l2vpn-vpls-mcast-14.txt
Reviewer: Matthew Bocci 
Review Date: 26 September 2013
IETF LC End Date: date-if-known 
Intended Status: Proposed Standard 

Summary:

I have some minor concerns about this document that I think should be = resolved before
publication. 

Comments:

The draft appears to be complete and accurate form a technical perspec= tive. However,
the style of the draft and the density of the text make it quite diffi= cult to 
read at times. It took several passes of some sections of the document= , and returning 
to earlier sections, to properly follow the text. I believe this is be= cause the basic
multicast architecture could be better-explained earlier in the draft.=

Major Issues:

No major issues found. 

Minor Issues:

1) The draft contains both introductory architectural / framework = ;
descriptions, and more detailed specifications of the protocols requir= ed
to efficiently support multicast in VPLS.  However, the introduct= ory sections (e.g. the
 overview in section 5) are presented in the form of extremely de= nse text, and while 
 they seem to be trying to explain architectural concepts, they d= o not use a single 
 diagram to help the reader visualise the solutions in the draft.= In fact, the first
 figures illustrating the protocol hierarchies and relationships = do not appear until the
 label stacks are described in Section 13 on page 43. 
 
 I think inserting some figures in section 5 to illustrate the di= fferent multicast 
 schemes, and also moving the data forwarding section earlier in = the document, would 
 greatly help the reader.  

2) Cross-references in the text use the title of the referenced sectio= n, but do not
include a section number. Personally, I found that this made the draft= much more difficult 
to navigate than it should be. It would help to add section numbers to= each instance of
a cross reference.

 
Nits:

Abstract, 2nd paragraph, 1st sentence:
s/solution/solutions

Section 3: This section would be clearer of it was in tabular form, in= a similar manner 
to other RFCs. 

You could also add short (one sentence) definitions of 'Inclusive Tree= s', 'Selective 
Trees', and 'Aggregation'.


Sec 4. Introduction: 3rd para:
s/when large/when a large

Sec 4. Introduction: 5th para:
s/RSVP-PE/RSVP-TE

Sec 5.2. BGP-Based VPLS Membership Auto-Discovery: 1st para:
s/that have membership these/that have membership of these

Sec 5.4 Advertising P-Multicast..., 2nd para:
Grammar: The decision to bind a set of VPLS instances or customer mult= icast group is 
local to the ingress PE matter, / The decision to bind a set of VPLS i= nstances or 
customer multicast groups is a local matter for the ingress PE ,

Sec 5.4 Advertising P-Multicast..., 3rd para:
s/be included. / be included

Section 5.5 Aggregation:

The following algorithm is hard to parse:
+ ((Average number of VPLS instances on a PE / Aggregation Factor)=
       * number of PEs) / (Average number of P-Mul= ticast trees that
       transit a given P router)
       
I think this could be restated in a more readable manner. Just as an e= xample:
      AveVPLS            = NPE
      -------    X    --------
        Aggr          Ave= PTree 
        
    Where: AveVPLS is the average number of VPLS instances o= n a PE
           Aggr is the aggregation facto= r
           NPE is the number of PEs
           AvePTree is the average numbe= r of P-multicast that transit a given P-router
           
Section 6: Inter-AS Inclusive P-Multicast..., 5th Paragraph
This paragraph mentions FEC128 and FEC 129. It would be better to call= these by their
formal names used in RFC4447 i.e. The PWid FEC and the Generalized PWi= d FEC   

           



--_000_CE6A09B851BF0matthewboccialcatellucentcom_-- From lberger@labn.net Fri Sep 27 10:38:33 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86B21F9CDF for ; Fri, 27 Sep 2013 10:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.931 X-Spam-Level: X-Spam-Status: No, score=-101.931 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLekBl1DrJwH for ; Fri, 27 Sep 2013 10:38:28 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 48FE921E8096 for ; Fri, 27 Sep 2013 10:38:25 -0700 (PDT) Received: (qmail 10745 invoked by uid 0); 27 Sep 2013 17:37:57 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.mail.unifiedlayer.com with SMTP; 27 Sep 2013 17:37:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=p3+STk2vAr9incfOEdaLPDQTj5TyKcJk8B1qKCcRVYA=; b=NFYnZrpP+udxswD8Gq71PrSLLPSJWdo6gZ2nBx+Wtd2IibGahswqYHUO5Swj8JukZd8zfMksEGQoVGmev5gUD1IbzHCdjq0dTSksy1A4K1nkq4TsylcehxdF9z8GkmfL; Received: from box313.bluehost.com ([69.89.31.113]:50241 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VPbzJ-00068M-Mj; Fri, 27 Sep 2013 11:37:57 -0600 Message-ID: <5245C274.6090707@labn.net> Date: Fri, 27 Sep 2013 13:37:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" , "Joel M. Halpern" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" References: <522DBBBC.7050103@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "rtg-dir@ietf.org" , CCAMP WG , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 17:38:33 -0000 Joel/Authors, I thought I might jump in on two points: On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hello Joel, > > thanks for your comments. > Below in line our reply, marked "authors". > ... > Given that this document is about mapping to G.709, it is unclear what is intended by the usage of "LSP". My guess is that it is intended to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. > It should be stated explicitly. > > Authors> We can specify this as you suggest even if we considered not necessary to specify the usage of LSP in relation to data plane specific. Encoding type should cope with this issue. > Joel, I suspect that the usage of LSP in the absence of the MPLS data plane is what's causing confusion here. Is this correct? If so, I think GMPLS referencing controlled data paths (circuits) by the common name of Label Switched Path (LSP) is sufficiently established that this document doesn't need to revisit it. In any case, the document already provides context: GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS control of OTN networks based on the 2001 revision of the G.709 specification. and Background information and a framework for the GMPLS protocol extensions need to support [G.709-2012] is provided in [OTN-FWK]. [OTN-FWK] has the often repeated concept: GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time division multiplexing (TDM) networks (e.g., Synchronous Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in [RFC3945], If this doesn't cover the comment, can you elaborate on what you want explicitly stated? > ... > > Section 8 on Maximum LSP Bandwdith seems to be objecting to too much information leading to a "waste of bits". While possibly of interest to the WG, that does not seem to fit a gap analysis. > Similarly, section 10 on Priority Support reads as implementation advice rather than a gap needing protocol changes. > > Authors> The basic scope of the draft is to underline gaps, and even if what described in Ch.8 and 10, do not prevent routing to work , it is suggested here an requirement for optimization based on OTN requirements (e.g. no need to advertise fixed ODU container Max LSP BW since implicit in the signal type.) > Authors, I completely agree with Joel on this point, furthermore sections 10 and 8 overlap. One approach to address his point would be to simply drop both sections. An alternative is try to rephrase them to address Joel's points. I've taken a pass at the latter below, but won't object if the authors prefer the former. Here's a suggested wording change if you choose to keep the sections: OLD: 8. Maximum LSP Bandwidth Maximum LSP bandwidth is currently advertised in the common part of the ISCD and advertised per priority, while in OTN networks it is only required for ODUflex advertising. This leads to a significant waste of bits inside each LSA. and NEW 8. Maximum LSP Bandwidth Maximum LSP bandwidth is currently advertised per priority in the common part of the ISCD. Section 5 reviews some of the implications of advertising OTN network information using ISCDs, and identifies the need for a more optimized solution. While strictly not required, such an optimization effort should also consider the optimization of the per priority maximum LSP bandwidth advertisement of both fixed and variable ODU types. OLD 10. Priority Support [RFC4202] defines 8 priorities for resource availability and usage. All of them have to be advertised independently on the number of priorities supported by the implementation. Considering that the advertisement of all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported priorities. NEW 10. Priority Support [RFC4202] defines 8 priorities for resource availability and usage. As defined, each is advertised independent of the number of priorities supported by a network. As is the case in Section 8, addressing any inefficiency with such advertisements is not required to support OTN networks. But any such inefficiency should also be considered as part of the optimization effort identified in Section 5. Also please replace "Bw" with "Bandwidth" in the document. Lou From jmh@joelhalpern.com Fri Sep 27 11:30:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28D21F9A6D; Fri, 27 Sep 2013 11:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhKogBPK8u1A; Fri, 27 Sep 2013 11:30:43 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D867F21F9FC3; Fri, 27 Sep 2013 11:30:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B76D5120899; Fri, 27 Sep 2013 11:30:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 06C55120890; Fri, 27 Sep 2013 11:30:41 -0700 (PDT) Message-ID: <5245CED2.5020400@joelhalpern.com> Date: Fri, 27 Sep 2013 14:30:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lou Berger References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> In-Reply-To: <5245C274.6090707@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \(SERGIO\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:30:49 -0000 Lou, thanks for stepping in. With your explanation I can live with the LSP text as it is. I look forward to further conversation on the other point. Yours, Joel On 9/27/13 1:37 PM, Lou Berger wrote: > Joel/Authors, > > I thought I might jump in on two points: > > > On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hello Joel, >> >> thanks for your comments. >> Below in line our reply, marked "authors". >> > > ... > >> Given that this document is about mapping to G.709, it is unclear what is intended by the usage of "LSP". My guess is that it is intended to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. >> It should be stated explicitly. >> >> Authors> We can specify this as you suggest even if we considered not necessary to specify the usage of LSP in relation to data plane specific. Encoding type should cope with this issue. >> > > Joel, > > I suspect that the usage of LSP in the absence of the MPLS data plane is > what's causing confusion here. Is this correct? > > If so, I think GMPLS referencing controlled data paths (circuits) by the > common name of Label Switched Path (LSP) is sufficiently established > that this document doesn't need to revisit it. In any case, the > document already provides context: > > GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], > [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS > control of OTN networks based on the 2001 revision of the G.709 > specification. > and > Background information and a framework for the GMPLS protocol > extensions need to support [G.709-2012] is provided in [OTN-FWK]. > > [OTN-FWK] has the often repeated concept: > > GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time > division multiplexing (TDM) networks (e.g., Synchronous Optical > NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous > Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching > optical networks, and spatial switching (e.g., incoming port or fiber > to outgoing port or fiber). The GMPLS architecture is provided in > [RFC3945], > > If this doesn't cover the comment, can you elaborate on what you want > explicitly stated? > >> ... >> >> Section 8 on Maximum LSP Bandwdith seems to be objecting to too much information leading to a "waste of bits". While possibly of interest to the WG, that does not seem to fit a gap analysis. >> Similarly, section 10 on Priority Support reads as implementation advice rather than a gap needing protocol changes. >> >> Authors> The basic scope of the draft is to underline gaps, and even if what described in Ch.8 and 10, do not prevent routing to work , it is suggested here an requirement for optimization based on OTN requirements (e.g. no need to advertise fixed ODU container Max LSP BW since implicit in the signal type.) >> > > Authors, > I completely agree with Joel on this point, furthermore sections 10 and > 8 overlap. One approach to address his point would be to simply drop > both sections. An alternative is try to rephrase them to address Joel's > points. I've taken a pass at the latter below, but won't object if the > authors prefer the former. > > Here's a suggested wording change if you choose to keep the sections: > OLD: > 8. Maximum LSP Bandwidth > > Maximum LSP bandwidth is currently advertised in the common part of > the ISCD and advertised per priority, while in OTN networks it is > only required for ODUflex advertising. This leads to a significant > waste of bits inside each LSA. > and > > NEW > 8. Maximum LSP Bandwidth > > Maximum LSP bandwidth is currently advertised per priority in the > common part of the ISCD. Section 5 reviews some of the implications > of advertising OTN network information using ISCDs, and > identifies the need for a more optimized solution. While strictly > not required, such an optimization effort should also consider the > optimization of the per priority maximum LSP bandwidth advertisement > of both fixed and variable ODU types. > > OLD > 10. Priority Support > > [RFC4202] defines 8 priorities for resource availability and usage. > All of them have to be advertised independently on the number of > priorities supported by the implementation. Considering that the > advertisement of all the different supported signal types will > originate large LSAs, it is advised to advertise only the information > related to the really supported priorities. > NEW > 10. Priority Support > > [RFC4202] defines 8 priorities for resource availability and usage. > As defined, each is advertised independent of the number of > priorities supported by a network. As is the case in Section 8, > addressing any inefficiency with such advertisements is not required > to support OTN networks. But any such inefficiency should also be > considered as part of the optimization effort identified in Section > 5. > > Also please replace "Bw" with "Bandwidth" in the document. > > Lou > From lberger@labn.net Fri Sep 27 12:01:20 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5385321E804C for ; Fri, 27 Sep 2013 12:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.151 X-Spam-Level: X-Spam-Status: No, score=-101.151 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl85ZOwcbjGv for ; Fri, 27 Sep 2013 12:01:09 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id EA40A21E8105 for ; Fri, 27 Sep 2013 12:00:59 -0700 (PDT) Received: (qmail 11255 invoked by uid 0); 27 Sep 2013 19:00:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 27 Sep 2013 19:00:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Bq15L1zE588IiVrAucc2XoNRKit2Rvos3ng8nma2teI=; b=hipj7TBZx5igpqpEcPocx+J1QoO6VOpenKPaN8zoVt9sE76Otmpj1iPsEeHh/BobgV72MH3R8kZcWFuFF4j4Z9xgRGCyZe/GGqTDumfKrjjwbWCmANhUl4/bAjpLCWdH; Received: from box313.bluehost.com ([69.89.31.113]:36938 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VPdHI-0005mu-Q0; Fri, 27 Sep 2013 13:00:36 -0600 Message-ID: <5245D5D3.2070303@labn.net> Date: Fri, 27 Sep 2013 15:00:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> In-Reply-To: <5245CED2.5020400@joelhalpern.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \(SERGIO\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:01:22 -0000 Joel, Does the proposed altnerate text address your comment (assuming the author's want to keep the sections)? If not, can you suggest changes? Thanks, Lou On 09/27/2013 02:30 PM, Joel M. Halpern wrote: > Lou, thanks for stepping in. > With your explanation I can live with the LSP text as it is. > > I look forward to further conversation on the other point. > > Yours, > Joel > > On 9/27/13 1:37 PM, Lou Berger wrote: >> Joel/Authors, >> >> I thought I might jump in on two points: >> >> >> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>> Hello Joel, >>> >>> thanks for your comments. >>> Below in line our reply, marked "authors". >>> >> >> ... >> >>> Given that this document is about mapping to G.709, it is >>> unclear what is intended by the usage of "LSP". My guess is that it >>> is intended to mean Label Switch Paths set up by GMPLS to carry >>> OTU/UDU elements. >>> It should be stated explicitly. >>> >>> Authors> We can specify this as you suggest even if we considered not >>> necessary to specify the usage of LSP in relation to data plane >>> specific. Encoding type should cope with this issue. >>> >> >> Joel, >> >> I suspect that the usage of LSP in the absence of the MPLS data plane is >> what's causing confusion here. Is this correct? >> >> If so, I think GMPLS referencing controlled data paths (circuits) by the >> common name of Label Switched Path (LSP) is sufficiently established >> that this document doesn't need to revisit it. In any case, the >> document already provides context: >> >> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >> [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS >> control of OTN networks based on the 2001 revision of the G.709 >> specification. >> and >> Background information and a framework for the GMPLS protocol >> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >> >> [OTN-FWK] has the often repeated concept: >> >> GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time >> division multiplexing (TDM) networks (e.g., Synchronous Optical >> NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous >> Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching >> optical networks, and spatial switching (e.g., incoming port or fiber >> to outgoing port or fiber). The GMPLS architecture is provided in >> [RFC3945], >> >> If this doesn't cover the comment, can you elaborate on what you want >> explicitly stated? >> >>> ... >>> >>> Section 8 on Maximum LSP Bandwdith seems to be objecting to too >>> much information leading to a "waste of bits". While possibly of >>> interest to the WG, that does not seem to fit a gap analysis. >>> Similarly, section 10 on Priority Support reads as >>> implementation advice rather than a gap needing protocol changes. >>> >>> Authors> The basic scope of the draft is to underline gaps, and even >>> if what described in Ch.8 and 10, do not prevent routing to work , it >>> is suggested here an requirement for optimization based on OTN >>> requirements (e.g. no need to advertise fixed ODU container Max LSP >>> BW since implicit in the signal type.) >>> >> >> Authors, >> I completely agree with Joel on this point, furthermore sections >> 10 and >> 8 overlap. One approach to address his point would be to simply drop >> both sections. An alternative is try to rephrase them to address Joel's >> points. I've taken a pass at the latter below, but won't object if the >> authors prefer the former. >> >> Here's a suggested wording change if you choose to keep the sections: >> OLD: >> 8. Maximum LSP Bandwidth >> >> Maximum LSP bandwidth is currently advertised in the common part of >> the ISCD and advertised per priority, while in OTN networks it is >> only required for ODUflex advertising. This leads to a significant >> waste of bits inside each LSA. >> and >> >> NEW >> 8. Maximum LSP Bandwidth >> >> Maximum LSP bandwidth is currently advertised per priority in the >> common part of the ISCD. Section 5 reviews some of the implications >> of advertising OTN network information using ISCDs, and >> identifies the need for a more optimized solution. While strictly >> not required, such an optimization effort should also consider the >> optimization of the per priority maximum LSP bandwidth advertisement >> of both fixed and variable ODU types. >> >> OLD >> 10. Priority Support >> >> [RFC4202] defines 8 priorities for resource availability and usage. >> All of them have to be advertised independently on the number of >> priorities supported by the implementation. Considering that the >> advertisement of all the different supported signal types will >> originate large LSAs, it is advised to advertise only the information >> related to the really supported priorities. >> NEW >> 10. Priority Support >> >> [RFC4202] defines 8 priorities for resource availability and usage. >> As defined, each is advertised independent of the number of >> priorities supported by a network. As is the case in Section 8, >> addressing any inefficiency with such advertisements is not required >> to support OTN networks. But any such inefficiency should also be >> considered as part of the optimization effort identified in Section >> 5. >> >> Also please replace "Bw" with "Bandwidth" in the document. >> >> Lou >> > From jmh@joelhalpern.com Fri Sep 27 12:26:21 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0821F9F8F; Fri, 27 Sep 2013 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhvauI1Ay+dc; Fri, 27 Sep 2013 12:26:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4784121F9E00; Fri, 27 Sep 2013 12:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 32307122669; Fri, 27 Sep 2013 12:26:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 459A4122668; Fri, 27 Sep 2013 12:26:11 -0700 (PDT) Message-ID: <5245DBD4.8000301@joelhalpern.com> Date: Fri, 27 Sep 2013 15:26:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lou Berger References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> <5245D5D3.2070303@labn.net> In-Reply-To: <5245D5D3.2070303@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \(SERGIO\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:26:21 -0000 The proposed alternative text would suffice, although personally I would just remove the two sections. Yours, Joel On 9/27/13 3:00 PM, Lou Berger wrote: > Joel, > Does the proposed altnerate text address your comment (assuming the > author's want to keep the sections)? If not, can you suggest changes? > > Thanks, > Lou > > On 09/27/2013 02:30 PM, Joel M. Halpern wrote: >> Lou, thanks for stepping in. >> With your explanation I can live with the LSP text as it is. >> >> I look forward to further conversation on the other point. >> >> Yours, >> Joel >> >> On 9/27/13 1:37 PM, Lou Berger wrote: >>> Joel/Authors, >>> >>> I thought I might jump in on two points: >>> >>> >>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>> Hello Joel, >>>> >>>> thanks for your comments. >>>> Below in line our reply, marked "authors". >>>> >>> >>> ... >>> >>>> Given that this document is about mapping to G.709, it is >>>> unclear what is intended by the usage of "LSP". My guess is that it >>>> is intended to mean Label Switch Paths set up by GMPLS to carry >>>> OTU/UDU elements. >>>> It should be stated explicitly. >>>> >>>> Authors> We can specify this as you suggest even if we considered not >>>> necessary to specify the usage of LSP in relation to data plane >>>> specific. Encoding type should cope with this issue. >>>> >>> >>> Joel, >>> >>> I suspect that the usage of LSP in the absence of the MPLS data plane is >>> what's causing confusion here. Is this correct? >>> >>> If so, I think GMPLS referencing controlled data paths (circuits) by the >>> common name of Label Switched Path (LSP) is sufficiently established >>> that this document doesn't need to revisit it. In any case, the >>> document already provides context: >>> >>> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >>> [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS >>> control of OTN networks based on the 2001 revision of the G.709 >>> specification. >>> and >>> Background information and a framework for the GMPLS protocol >>> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >>> >>> [OTN-FWK] has the often repeated concept: >>> >>> GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time >>> division multiplexing (TDM) networks (e.g., Synchronous Optical >>> NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous >>> Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching >>> optical networks, and spatial switching (e.g., incoming port or fiber >>> to outgoing port or fiber). The GMPLS architecture is provided in >>> [RFC3945], >>> >>> If this doesn't cover the comment, can you elaborate on what you want >>> explicitly stated? >>> >>>> ... >>>> >>>> Section 8 on Maximum LSP Bandwdith seems to be objecting to too >>>> much information leading to a "waste of bits". While possibly of >>>> interest to the WG, that does not seem to fit a gap analysis. >>>> Similarly, section 10 on Priority Support reads as >>>> implementation advice rather than a gap needing protocol changes. >>>> >>>> Authors> The basic scope of the draft is to underline gaps, and even >>>> if what described in Ch.8 and 10, do not prevent routing to work , it >>>> is suggested here an requirement for optimization based on OTN >>>> requirements (e.g. no need to advertise fixed ODU container Max LSP >>>> BW since implicit in the signal type.) >>>> >>> >>> Authors, >>> I completely agree with Joel on this point, furthermore sections >>> 10 and >>> 8 overlap. One approach to address his point would be to simply drop >>> both sections. An alternative is try to rephrase them to address Joel's >>> points. I've taken a pass at the latter below, but won't object if the >>> authors prefer the former. >>> >>> Here's a suggested wording change if you choose to keep the sections: >>> OLD: >>> 8. Maximum LSP Bandwidth >>> >>> Maximum LSP bandwidth is currently advertised in the common part of >>> the ISCD and advertised per priority, while in OTN networks it is >>> only required for ODUflex advertising. This leads to a significant >>> waste of bits inside each LSA. >>> and >>> >>> NEW >>> 8. Maximum LSP Bandwidth >>> >>> Maximum LSP bandwidth is currently advertised per priority in the >>> common part of the ISCD. Section 5 reviews some of the implications >>> of advertising OTN network information using ISCDs, and >>> identifies the need for a more optimized solution. While strictly >>> not required, such an optimization effort should also consider the >>> optimization of the per priority maximum LSP bandwidth advertisement >>> of both fixed and variable ODU types. >>> >>> OLD >>> 10. Priority Support >>> >>> [RFC4202] defines 8 priorities for resource availability and usage. >>> All of them have to be advertised independently on the number of >>> priorities supported by the implementation. Considering that the >>> advertisement of all the different supported signal types will >>> originate large LSAs, it is advised to advertise only the information >>> related to the really supported priorities. >>> NEW >>> 10. Priority Support >>> >>> [RFC4202] defines 8 priorities for resource availability and usage. >>> As defined, each is advertised independent of the number of >>> priorities supported by a network. As is the case in Section 8, >>> addressing any inefficiency with such advertisements is not required >>> to support OTN networks. But any such inefficiency should also be >>> considered as part of the optimization effort identified in Section >>> 5. >>> >>> Also please replace "Bw" with "Bandwidth" in the document. >>> >>> Lou >>> >> > > From lberger@labn.net Fri Sep 27 12:55:23 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0553021F9F6C for ; Fri, 27 Sep 2013 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KThn1i1yupd3 for ; Fri, 27 Sep 2013 12:55:14 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 8E17121F9EED for ; Fri, 27 Sep 2013 12:55:14 -0700 (PDT) Received: (qmail 29812 invoked by uid 0); 27 Sep 2013 19:54:50 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 27 Sep 2013 19:54:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:Content-Transfer-Encoding:Date:MIME-Version:Message-ID:References:Cc:To:Subject:From; bh=CQVp5ynAXOys2FhoH7wOPB9K2TroreRHMx86xOXe98o=; b=NF5VAnRXq8uWnf1U9zTWAr98UfcZVSD3xk60maHc+RhUEqhMVlY76T3VtNorpnhYW1k8Zy25Js6geUc7FP0zlpsJ4lnGVASTYuakXdFDD3wdXftzCPGUsEo0oF7X+7Zw; Received: from [69.89.31.113] (port=46453 helo=localhost) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VPe7m-0008VS-Cw; Fri, 27 Sep 2013 13:54:50 -0600 From: Lou Berger To: "Joel M. Halpern" References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> <5245D5D3.2070303@labn.net> Message-ID: <752ffcd2.1380311568091@mail.labn.net> MIME-Version: 1.0 Date: Fri, 27 Sep 2013 15:54:43 -0400 (EDT) User-Agent: ProfiMailGo/4.14.00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 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" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \\\(SERGIO\\\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:55:24 -0000 Great. So you and I are in agreement. We'll see what the authors have to sa= y... On 3:26pm, September 27, 2013, Joel M. Halpern wrote: > The proposed alternative text would suffice, although personally I would= =20 > just remove the two sections. >=20 > Yours, > Joel >=20 > On 9/27/13 3:00 PM, Lou Berger wrote: > > Joel, > > Does the proposed altnerate text address your comment (assuming the > > author's want to keep the sections)?=C2=A0 If not, can you suggest chan= ges? > >=20 > > Thanks, > > Lou > >=20 > > On 09/27/2013 02:30 PM, Joel M. Halpern wrote: > > > Lou, thanks for stepping in. > > > With your explanation I can live with the LSP text as it is. > > >=20 > > > I look forward to further conversation on the other point. > > >=20 > > > Yours, > > > Joel > > >=20 > > > On 9/27/13 1:37 PM, Lou Berger wrote: > > > > Joel/Authors, > > > >=20 > > > > I thought I might jump in on two points: > > > >=20 > > > >=20 > > > > On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: > > > > > Hello Joel, > > > > >=20 > > > > > thanks for your comments. > > > > > Below in line our reply, marked "authors". > > > > >=20 > > > >=20 > > > > ... > > > >=20 > > > > > Given that this document is about mapping to G.709, it is > > > > > unclear what is intended by the usage of "LSP".=C2=A0 My guess is= that it > > > > > is intended to mean Label Switch Paths set up by GMPLS to carry > > > > > OTU/UDU elements. > > > > > It should be stated explicitly. > > > > >=20 > > > > > Authors> We can specify this as you suggest even if we considered= not > > > > > necessary to specify the usage of LSP in relation to data plane > > > > > specific. Encoding type should cope with this issue. > > > > >=20 > > > >=20 > > > > Joel, > > > >=20 > > > > I suspect that the usage of LSP in the absence of the MPLS data pla= ne is > > > > what's causing confusion here.=C2=A0 Is this correct? > > > >=20 > > > > If so, I think GMPLS referencing controlled data paths (circuits) b= y the > > > > common name of Label Switched Path (LSP) is sufficiently establishe= d > > > > that this document doesn't need to revisit it.=C2=A0 In any case, t= he > > > > document already provides context: > > > >=20 > > > > GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], > > > > [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS > > > > control of OTN networks based on the 2001 revision of the G.709 > > > > specification. > > > > and > > > > Background information and a framework for the GMPLS protocol > > > > extensions need to support [G.709-2012] is provided in [OTN-FWK]. > > > >=20 > > > > [OTN-FWK] has the often repeated concept: > > > >=20 > > > > GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass ti= me > > > > division multiplexing (TDM) networks (e.g., Synchronous Optical > > > > NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronou= s > > > > Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching > > > > optical networks, and spatial switching (e.g., incoming port or fib= er > > > > to outgoing port or fiber).=C2=A0 The GMPLS architecture is provide= d in > > > > [RFC3945], > > > >=20 > > > > If this doesn't cover the comment, can you elaborate on what you wa= nt > > > > explicitly stated? > > > >=20 > > > > > ... > > > > >=20 > > > > > Section 8 on Maximum LSP Bandwdith seems to be objecting to too > > > > > much information leading to a "waste of bits".=C2=A0 While possib= ly of > > > > > interest to the WG, that does not seem to fit a gap analysis. > > > > > Similarly, section 10 on Priority Support reads as > > > > > implementation advice rather than a gap needing protocol changes. > > > > >=20 > > > > > Authors> The basic scope of the draft is to underline gaps, and e= ven > > > > > if what described in Ch.8 and 10, do not prevent routing to work = , it > > > > > is suggested here an requirement for optimization based on OTN > > > > > requirements (e.g. no need to advertise fixed ODU container Max L= SP > > > > > BW since implicit in the signal type.) > > > > >=20 > > > >=20 > > > > Authors, > > > > I completely agree with Joel on this point, furthermore sections > > > > 10 and > > > > 8 overlap.=C2=A0 One approach to address his point would be to simp= ly drop > > > > both sections.=C2=A0 An alternative is try to rephrase them to addr= ess Joel's > > > > points.=C2=A0 I've taken a pass at the latter below, but won't obje= ct if the > > > > authors prefer the former. > > > >=20 > > > > Here's a suggested wording change if you choose to keep the section= s: > > > > OLD: > > > > 8. Maximum LSP Bandwidth > > > >=20 > > > > Maximum LSP bandwidth is currently advertised in the common part of > > > > the ISCD and advertised per priority, while in OTN networks it is > > > > only required for ODUflex advertising.=C2=A0 This leads to a signif= icant > > > > waste of bits inside each LSA. > > > > and > > > >=20 > > > > NEW > > > > 8. Maximum LSP Bandwidth > > > >=20 > > > > Maximum LSP bandwidth is currently advertised per priority in the > > > > common part of the ISCD.=C2=A0 Section 5 reviews some of the implic= ations > > > > of advertising OTN network information using=C2=A0 ISCDs, and > > > > identifies the need for a more optimized solution.=C2=A0 While stri= ctly > > > > not required, such an optimization effort should also consider the > > > > optimization of the per priority maximum LSP bandwidth advertisemen= t > > > > of both fixed and variable ODU types. > > > >=20 > > > > OLD > > > > 10. Priority Support > > > >=20 > > > > [RFC4202] defines 8 priorities for resource availability and usage. > > > > All of them have to be advertised independently on the number of > > > > priorities supported by the implementation.=C2=A0 Considering that = the > > > > advertisement of all the different supported signal types will > > > > originate large LSAs, it is advised to advertise only the informati= on > > > > related to the really supported priorities. > > > > NEW > > > > 10. Priority Support > > > >=20 > > > > [RFC4202] defines 8 priorities for resource availability and usage. > > > > As defined, each is advertised independent of the number of > > > > priorities supported by a network.=C2=A0 As is the case in Section = 8, > > > > addressing any inefficiency with such advertisements is not require= d > > > > to support OTN networks.=C2=A0 But any such inefficiency should als= o be > > > > considered as part of the optimization effort identified in Section > > > > 5. > > > >=20 > > > > Also please replace "Bw" with "Bandwidth" in the document. > > > >=20 > > > > Lou > > > >=20 > > >=20 > >=20 > >=20 >=20 From adrian@olddog.co.uk Sat Sep 28 15:44:26 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41211E8127 for ; Sat, 28 Sep 2013 15:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql9xeTclVgEe for ; Sat, 28 Sep 2013 15:44:20 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87611E8107 for ; Sat, 28 Sep 2013 15:44:19 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8SMiHao022247; Sat, 28 Sep 2013 23:44:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8SMiG6T022239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Sep 2013 23:44:16 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" References: <5221E516.5010907@pi.nu> In-Reply-To: <5221E516.5010907@pi.nu> Date: Sat, 28 Sep 2013 23:44:16 +0100 Message-ID: <056601cebc9c$439dd3e0$cad97ba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGl+pm+pRdUm+ecghYUuawPc6Qfb5otPv+Q Content-Language: en-gb Cc: rtg-dir@ietf.org, draft-cotton-rfc4020bis.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] rtg-dir review of draft-cotton-rfc4020bis-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 22:44:26 -0000 Hi Loa, Thanks for doing the review. > The document is very well written and clear. There is one thing I've > thought about marking registries as open for early allocation. Some > registries, e.g.: >=20 > BGP Error Subcodes RFC 4271 > Standards Action (Early Allocation available per RFC 4020) >=20 > Are marked that they are available that they are open for early > allocation. >=20 > While others - that I understand is also open for early allocation = e.g.: >=20 > MPLS Fault OAM Flag Registry RFC 6427 > Standards Action >=20 > are not. >=20 > I wonder if we wonder if we should request that IANA mark all > registries (or part of the registries) that are open for early > allocation the same way. In fact, one of the changes (not highlighted) resulting from this = document is that registries do not need to be specially marked. Thus any = registry that satisfies 2a can support early allocation. So the result of the point you make is that IANA should clean up and = remove the flag from those registries that carry it. Thus, a new = paragraph in Section 4 This document removes the need for registries to be marked as specifically allowing early allocation. IANA is requested to clean up the registries by removing any such markings. > Major Issues: >=20 > Section 3.2 "Expiry" >=20 > I've recently shepherded a document for which the temporary allocation > were made 2007 and was supposed expire 20078; however the allocations > are still there. And no harm done. Existing practice is that the early > allocation stays until permanently allocated or until the working = group > chairs to delete them. I think it would be better to document the > existing practice. >=20 > I think it would be enough if the expiry section says: >=20 > "Once an temporary assignment is made it stays in the registry until > the document for which they were made becomes an RFC, or until they > are removed by working group chairs or the ADs. >=20 > IANA may request from working groups chairs if an early allocation > should remain in the registry or not." There are two things you are saying here. 1. The "temporary entry" should remain in the registry until explicitly = removed. In fact, this is exactly what happens if the process described = in the document is followed: the entry remains, but its date shows it = has expired. Someone worried about the status could contact the chairs = who would say "ooops I should have renewed that." 2. IANA should poke the chairs: the chairs should not have to track = this. I can see the value in that, and we can discuss it further with = IANA, but I suspect it would require IANA to run a tracking tool and it = is outside the current scope of work for IANA. Maybe next time the IANA = contract is reviewed we could suggest that change. > Minor Issues: >=20 > There has been some comments on the IETF mailing list; >=20 > SM stumbled over the same words in section 2 as I did '"Specification > Required" (where an RFC will be used as the stable reference)' > I support Barry Leiba's resolution of that comment. Yup we have been polishing this. > Eric Rosen has also commented on the draft; however I believe that the > draft the right approach as it is today. You'll see a loooong response from me to Eric. I suspect you could have = a great discussion with him about SDOs and codepoint squatting. > Section 1 - line 3-4: > "Many of these code point spaces have registries..." > Comment: I find it hard to follow the nomenclature sometimes, > registry - name space - code point space. What are the relationships > and differences. I've asked Michelle to include a terminology section in 5226bis which is = currently open on her desk. Many thanks, Adrian From loa@pi.nu Sat Sep 28 22:06:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20E11E8116 for ; Sat, 28 Sep 2013 22:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SOHCl4yQrkv for ; Sat, 28 Sep 2013 22:06:18 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 197B321E80B7 for ; Sat, 28 Sep 2013 22:06:15 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.49.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DB7291802038; Sun, 29 Sep 2013 07:06:12 +0200 (CEST) Message-ID: <5247B542.6030906@pi.nu> Date: Sun, 29 Sep 2013 13:06:10 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <5221E516.5010907@pi.nu> <056601cebc9c$439dd3e0$cad97ba0$@olddog.co.uk> In-Reply-To: <056601cebc9c$439dd3e0$cad97ba0$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, draft-cotton-rfc4020bis.all@tools.ietf.org Subject: Re: [RTG-DIR] rtg-dir review of draft-cotton-rfc4020bis-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 05:06:29 -0000 Adrian, A comment on your comment on my comment on expiry inline. I fine with the rest. On 2013-09-29 06:44, Adrian Farrel wrote: >> Major Issues: >> >> Section 3.2 "Expiry" >> >> I've recently shepherded a document for which the temporary allocation >> were made 2007 and was supposed expire 20078; however the allocations >> are still there. And no harm done. Existing practice is that the early >> allocation stays until permanently allocated or until the working group >> chairs to delete them. I think it would be better to document the >> existing practice. >> >> I think it would be enough if the expiry section says: >> >> "Once an temporary assignment is made it stays in the registry until >> the document for which they were made becomes an RFC, or until they >> are removed by working group chairs or the ADs. >> >> IANA may request from working groups chairs if an early allocation >> should remain in the registry or not." > > There are two things you are saying here. > 1. The "temporary entry" should remain in the registry until explicitly removed. In fact, this is exactly what happens if the process described in the document is followed: the entry remains, but its date shows it has expired. Someone worried about the status could contact the chairs who would say "ooops I should have renewed that." Well, yes but I think it would be better to have the date when the entry was included in the registry. An old date would be an indication to wg chairs that they need to push on the document authors to deliver. If we indicate an expiry I know that this dives the wrong signal to some implementers. There is a difference to see a statement that says "Early allocation Nov 2007" from an entry that says "Expires Nov 2008". I think I prefer the first. Since we can't remove it if it been implemented and deploy, there is no reason that 2nd generation should feel uncertain about using code points that were "early" rather than "temporarily" allocated. > 2. IANA should poke the chairs: the chairs should not have to track > this. No that is not exactly what I say, what I say is that IANA is allowed to poke the chairs if they find a reason to do it, but it is not required that thay do it. > I can see the value in that, and we can discuss it further with IANA, but I suspect it would require IANA to run a tracking tool and it is outside the current scope of work for IANA. Well - we could put it in the data-tracker for the document; generates a mail that tells the working group chairs that says "It now one year since the following code points were "early" allocated". Do you want them to remain in the registry. The working group chairs goes into the and clicks and clicks on a button that says "refresh" or "remove". Maybe next time the IANA contract is reviewed we could suggest that change. That would work for me, but I think the tracking responsibility should really be on the wg chairs, with IANA having the possibility to act as triggers if they see the need. /Loa > /Loa > I've asked Michelle to include a terminology section in 5226bis which is currently open on her desk. > > Many thanks, > Adrian > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Sun Sep 29 12:55:08 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E273611E810A for ; Sun, 29 Sep 2013 12:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOyrLE-bO-pa for ; Sun, 29 Sep 2013 12:55:02 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E332721F93E4 for ; Sun, 29 Sep 2013 12:54:58 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8TJsnks010234; Sun, 29 Sep 2013 20:54:49 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8TJslXj010220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Sep 2013 20:54:47 +0100 From: "Adrian Farrel" To: "Loa Andersson" References: <5221E516.5010907@pi.nu> <056601cebc9c$439dd3e0$cad97ba0$@olddog.co.uk>, <5247B542.6030906@pi.nu> <93d4ef9670a242118c0559dcdd6bf24a@BN1PR05MB156.namprd05.prod.outlook.com> In-Reply-To: <93d4ef9670a242118c0559dcdd6bf24a@BN1PR05MB156.namprd05.prod.outlook.com> Date: Sun, 29 Sep 2013 20:54:47 +0100 Message-ID: <05dd01cebd4d$c08ed280$41ac7780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGl+pm+pRdUm+ecghYUuawPc6QfbwLfXbMNATqfQvQC5kdbWZn2odkw Content-Language: en-gb Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, draft-cotton-rfc4020bis.all@tools.ietf.org Subject: Re: [RTG-DIR] rtg-dir review of draft-cotton-rfc4020bis-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 19:55:08 -0000 Hi again Loa, > >> Section 3.2 "Expiry" > >> > >> I've recently shepherded a document for which the temporary allocation > >> were made 2007 and was supposed expire 20078; however the allocations > >> are still there. And no harm done. Existing practice is that the early > >> allocation stays until permanently allocated or until the working group > >> chairs to delete them. I think it would be better to document the > >> existing practice. > >> > >> I think it would be enough if the expiry section says: > >> > >> "Once an temporary assignment is made it stays in the registry until > >> the document for which they were made becomes an RFC, or until they > >> are removed by working group chairs or the ADs. > >> > >> IANA may request from working groups chairs if an early allocation > >> should remain in the registry or not." > > > > There are two things you are saying here. > > 1. The "temporary entry" should remain in the registry until explicitly > > removed. In fact, this is exactly what happens if the process > > described in the document is followed: the entry remains, but > > its date shows it has expired. Someone worried about the status > > could contact the chairs who would say "ooops I should have > > renewed that." > > Well, yes but I think it would be better to have the date when the > entry was included in the registry. The current draft says (section 3.1): 6. IANA makes an allocation from the appropriate registry, marking it as "Temporary", valid for a period of one year from the date of allocation. The date of first allocation the date of expiry should also be recorded in the registry and made visible to the public. There is a punctuation typo here we are fixing, but the net is that both dates will be recorded: the date of first allocation and the date of next expiry. [snip] > > 2. IANA should poke the chairs: the chairs should not have to track > > this. > > No that is not exactly what I say, what I say is that IANA is allowed to > poke the chairs if they find a reason to do it, but it is not required > that they do it. Oh, I see. Well, yes. There is no restriction on IANA sending emails to people. > I think the tracking responsibility should > really be on the wg chairs, with IANA having the possibility to act > as triggers if they see the need. OK. Well you can raise it as a nice-to-have feature for the tools team to put into the tracker. A From loa@pi.nu Sun Sep 29 20:23:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A821F9BD8 for ; Sun, 29 Sep 2013 20:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5N3QtlCBeeR for ; Sun, 29 Sep 2013 20:23:24 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0355A21F8415 for ; Sun, 29 Sep 2013 20:23:23 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.49.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 715A018014F6; Mon, 30 Sep 2013 05:23:20 +0200 (CEST) Message-ID: <5248EEA6.3070406@pi.nu> Date: Mon, 30 Sep 2013 11:23:18 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <5221E516.5010907@pi.nu> <056601cebc9c$439dd3e0$cad97ba0$@olddog.co.uk>, <5247B542.6030906@pi.nu> <93d4ef9670a242118c0559dcdd6bf24a@BN1PR05MB156.namprd05.prod.outlook.com> <05dd01cebd4d$c08ed280$41ac7780$@olddog.co.uk> In-Reply-To: <05dd01cebd4d$c08ed280$41ac7780$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, draft-cotton-rfc4020bis.all@tools.ietf.org Subject: Re: [RTG-DIR] rtg-dir review of draft-cotton-rfc4020bis-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 03:23:30 -0000 Adrian, hello again :) ! On 2013-09-30 03:54, Adrian Farrel wrote: > Hi again Loa, > >>>> Section 3.2 "Expiry" >>>> >>>> I've recently shepherded a document for which the temporary allocation >>>> were made 2007 and was supposed expire 20078; however the allocations >>>> are still there. And no harm done. Existing practice is that the early >>>> allocation stays until permanently allocated or until the working group >>>> chairs to delete them. I think it would be better to document the >>>> existing practice. >>>> >>>> I think it would be enough if the expiry section says: >>>> >>>> "Once an temporary assignment is made it stays in the registry until >>>> the document for which they were made becomes an RFC, or until they >>>> are removed by working group chairs or the ADs. >>>> >>>> IANA may request from working groups chairs if an early allocation >>>> should remain in the registry or not." >>> >>> There are two things you are saying here. >>> 1. The "temporary entry" should remain in the registry until explicitly >>> removed. In fact, this is exactly what happens if the process >>> described in the document is followed: the entry remains, but >>> its date shows it has expired. Someone worried about the status >>> could contact the chairs who would say "ooops I should have >>> renewed that." >> >> Well, yes but I think it would be better to have the date when the >> entry was included in the registry. > > The current draft says (section 3.1): > > 6. IANA makes an allocation from the appropriate registry, marking > it as "Temporary", valid for a period of one year from the date > of allocation. The date of first allocation the date of expiry > should also be recorded in the registry and made visible to the > public. > > There is a punctuation typo here we are fixing, but the net is that both dates > will be recorded: the date of first allocation and the date of next expiry. > Well - I guess I have to explain to implementers that the code has not gone away just because we are past the expiry date. > [snip] > >>> 2. IANA should poke the chairs: the chairs should not have to track >>> this. >> >> No that is not exactly what I say, what I say is that IANA is allowed to >> poke the chairs if they find a reason to do it, but it is not required >> that they do it. > > Oh, I see. Well, yes. There is no restriction on IANA sending emails to people. Understood. > >> I think the tracking responsibility should >> really be on the wg chairs, with IANA having the possibility to act >> as triggers if they see the need. > > OK. Well you can raise it as a nice-to-have feature for the tools team to put > into the tracker. This was not about the tool for tracking - I still think that we should say that the responsibility to track early allocations rests with the wg chairs. If we need tools for that, so be it. /Loa > > A > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From yakov@juniper.net Sun Sep 29 17:07:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F80811E8102; Sun, 29 Sep 2013 17:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.238 X-Spam-Level: X-Spam-Status: No, score=-103.238 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaXxIdtPqPHT; Sun, 29 Sep 2013 17:07:31 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4263821F9FA5; Sun, 29 Sep 2013 17:07:31 -0700 (PDT) Received: from mail201-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.22; Mon, 30 Sep 2013 00:07:30 +0000 Received: from mail201-db9 (localhost [127.0.0.1]) by mail201-db9-R.bigfish.com (Postfix) with ESMTP id 14B0BE00A3; Mon, 30 Sep 2013 00:07:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zzec9I1432Idbf2izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah1de097h186068h1d68deh8275dhz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail201-db9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail201-db9 (localhost.localdomain [127.0.0.1]) by mail201-db9 (MessageSwitch) id 1380499647738838_711; Mon, 30 Sep 2013 00:07:27 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.250]) by mail201-db9.bigfish.com (Postfix) with ESMTP id A64E0140258; Mon, 30 Sep 2013 00:07:27 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 30 Sep 2013 00:07:27 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 29 Sep 2013 17:07:25 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r8U07ML16896; Sun, 29 Sep 2013 17:07:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201309300007.r8U07ML16896@magenta.juniper.net> To: "Bocci, Matthew (Matthew)" In-Reply-To: References: X-MH-In-Reply-To: "Bocci, Matthew (Matthew)" message dated "Thu, 26 Sep 2013 14:56:43 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78461.1380499641.1@juniper.net> Date: Sun, 29 Sep 2013 17:07:21 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 30 Sep 2013 01:21:52 -0700 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , yakov@juniper.net, "draft-ietf-l2vpn-vpls-mcast@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-mcast-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 00:07:39 -0000 Matthew, > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Since IETF LC has ended for this draft, I am primarily providing comments t= > o > aid the ADs, and I hope the authors will also take them into consideration = > to improve > the readability of the draft. Thanks for your review and comments. > Document: draft-ietf-l2vpn-vpls-mcast-14.txt > Reviewer: Matthew Bocci > Review Date: 26 September 2013 > IETF LC End Date: date-if-known > Intended Status: Proposed Standard > > Summary: > > I have some minor concerns about this document that I think should > be resolved before publication. > > Comments: > > The draft appears to be complete and accurate form a technical perspective.= > However, > the style of the draft and the density of the text make it quite difficult = > to > read at times. It took several passes of some sections of the document, and= > returning > to earlier sections, to properly follow the text. I believe this is because= > the basic > multicast architecture could be better-explained earlier in the draft. > > Major Issues: > > No major issues found. > > Minor Issues: > > 1) The draft contains both introductory architectural / framework > descriptions, and more detailed specifications of the protocols required > to efficiently support multicast in VPLS. However, the introductory sections > (e.g. the overview in section 5) are presented in the form of extremely > dense text, and while > they seem to be trying to explain architectural concepts, they do not use > a single diagram to help the reader visualise the solutions in the draft. > In fact, the first > figures illustrating the protocol hierarchies and relationships do not > appear until the > label stacks are described in Section 13 on page 43. > > I think inserting some figures in section 5 to illustrate the different > multicast schemes, and also moving the data forwarding section earlier in > the document, would greatly help the reader. Wrt "inserting some figures in section 5", I would be glad to do this, provided you elaborate a bit on what specific figures you would like to insert. Wrt moving the data forwarding section earlier in the document, the placement of the data forwarding section follows the structure of rfc6513. > 2) Cross-references in the text use the title of the referenced section, bu= > t do not > include a section number. Personally, I found that this made the draft much= > more difficult > to navigate than it should be. It would help to add section numbers to each= > instance of > a cross reference. This will be fixed as part of the RFC Editor process. > Nits: > > Abstract, 2nd paragraph, 1st sentence: > s/solution/solutions Fixed. > Section 3: This section would be clearer of it was in tabular form, > in a similar manner to other RFCs. I would prefer to keep it in the present form, as there are plenty of other RFCs that have similar form. > You could also add short (one sentence) definitions of 'Inclusive Trees', '= > Selective Trees', and 'Aggregation'. Will do. > Sec 4. Introduction: 3rd para: > s/when large/when a large Fixed. > Sec 4. Introduction: 5th para: > s/RSVP-PE/RSVP-TE Fixed. > Sec 5.2. BGP-Based VPLS Membership Auto-Discovery: 1st para: > s/that have membership these/that have membership of these Fixed. > Sec 5.4 Advertising P-Multicast..., 2nd para: > Grammar: The decision to bind a set of VPLS instances or customer multicast= > group is > local to the ingress PE matter, / The decision to bind a set of VPLS instan= > ces or > customer multicast groups is a local matter for the ingress PE , Fixed. > Sec 5.4 Advertising P-Multicast..., 3rd para: > s/be included. / be included Fixed. > Section 5.5 Aggregation: > > The following algorithm is hard to parse: > + ((Average number of VPLS instances on a PE / Aggregation Factor) > * number of PEs) / (Average number of P-Multicast trees that > transit a given P router) > > I think this could be restated in a more readable manner. Just as an exampl= > e: > AveVPLS NPE > ------- X -------- > Aggr AvePTree > > Where: AveVPLS is the average number of VPLS instances on a PE > Aggr is the aggregation factor > NPE is the number of PEs > AvePTree is the average number of P-multicast that transit a giv= en P-router > Will fix. > Section 6: Inter-AS Inclusive P-Multicast..., 5th Paragraph > This paragraph mentions FEC128 and FEC 129. It would be better to call thes= > e by their > formal names used in RFC4447 i.e. The PWid FEC and the Generalized PWid FEC Will fix. Yakov. From daniele.ceccarelli@ericsson.com Mon Sep 30 06:59:43 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6C21F85BB; Mon, 30 Sep 2013 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.029 X-Spam-Level: X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[AWL=-1.430, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3nmwC9Er6r4; Mon, 30 Sep 2013 06:59:36 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DF75A21F9C72; Mon, 30 Sep 2013 06:59:35 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-2f-524983c6cf43 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.34.25272.6C389425; Mon, 30 Sep 2013 15:59:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Mon, 30 Sep 2013 15:59:34 +0200 From: Daniele Ceccarelli To: Lou Berger , "Joel M. Halpern" Thread-Topic: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Thread-Index: AQHOu7PtE6wgbzLAaEOxMZqZF3LxBJnZ/5zigAROm9A= Date: Mon, 30 Sep 2013 13:59:33 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4815B30C@ESESSMB301.ericsson.se> References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> <5245D5D3.2070303@labn.net> <752ffcd2.1380311568091@mail.labn.net> In-Reply-To: <752ffcd2.1380311568091@mail.labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvre6xZs8ggx3LzC2ezLnBYrFszn4m i4+n3jBZdDS/ZbF4Pmcmi8WCNU/ZLZZt/s3uwO7R+mwvq8eSJT+ZPM5N+c7o8WFTM5vHl8uf 2QJYo7hsUlJzMstSi/TtErgyDn3uYCtYEVpxuUOigXFCcBcjJ4eEgInE2dWvGCFsMYkL99az dTFycQgJHGWUeL5rPQuEs4RRov/JRyCHg4NNwEriySEfkAYRAS+Jt8deMYHUMAvsYJJ4t3oH WI2wQJzE1TPKEDXxEq83fmGCsK0k9r1fyApiswioSlzvXMcOYvMKeEtsfraFGWJXO5PE7UVb wIo4BYwl2vqfsIDYjAKyEhN2LwK7lFlAXOLWk/lMEFcLSCzZc54ZwhaVePn4HyuErSix82w7 M8g9zAKaEut36UO0KkpM6X4ItVdQ4uTMJywTGMVmIZk6C6FjFpKOWUg6FjCyrGLkKE4tTspN NzLYxAiMuINbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GHcmRzaKzn92f3OZdqLLBoWjh1wi2nt/+Hx1njb1fNbFbpfLm9NX+Hg+W6BknjZH9Lfdj/Yr rxqm5O5+Xxjd3WXyQNtqntNbwx0TdzjGn/iS9u+KSXzE3ldVGpH5Alt0JC88OXvDJ3BVeq/O 86xvG7muNwp36l9eYJA6j/28aMu2jfWrWl5/11JiKc5INNRiLipOBABV48+/hgIAAA== X-Mailman-Approved-At: Mon, 30 Sep 2013 07:13:39 -0700 Cc: "rtg-dir@ietf.org" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \\\(SERGIO\\\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 13:59:43 -0000 TG91LCBKb2VsLA0KDQpUaGUgdGV4dCBwcm9wb3NlZCBzb3VuZHMgZ29vZCBidXQgaXQgb25seSBz dGF0ZXMgdGhlIHByb2JsZW0gd2l0aG91dCBhbnkgaGludCBvbiB0aGUgc29sdXRpb25zIChpLmUu IHNheXMgdGhlcmUgaXMgYW4gaW5lZmZpY2llbmN5IGJ1dCBkb2VzbuKAmXQgc2F5IHRoYXQgYWR2 ZXJ0aXNpbmcgb25seSBzdXBwb3J0ZWQgcHJpb3JpdGllcyBpcyBhIHdheSB0byBhZGRyZXNzIHN1 Y2ggaW5lZmZpY2llbmN5KS4NClRoZXJlIGFyZSB0d28gb3B0aW9uczoNCjEuIEltcHJvdmUgdGhl IHRleHQgKHRoZSBORVcgb25lKSBzYXlpbmcgZS5nLiBvbmx5IHRoZSBhZHZlcnRpc2VtZW50IG9m IGJhbmR3aWR0aCBmb3Igc3VwcG9ydGVkIHByaW9yaXRpZXMgaXMgbmVlZGVkDQoyLiBBZG9wdCB0 aGUgTkVXIHRleHQgYXMgaXQgaXMgYW5kIG1vdmUgdGhlIHJlbWFpbmluZyBwYXJ0IG9mIHRoZSB0 ZXh0IHRvIHRoZSBPU1BGIGRyYWZ0ICh3aGVyZSB3ZSBzYXkgZS5nLiB0aGF0IG9ubHkgYmFuZHdp ZHRoIGZvciBzdXBwb3J0ZXIgcHJpb3JpdGllcyBuZWVkIHRvIGJlIGFkdmVydGlzZWQgYnV0IGRv bid0IHNheSB3aHkpLg0KDQpSZSBhbGwgdGhlIG90aGVyIGNvbW1lbnRzL3N1Z2dlc3Rpb24gd2Un cmUgb2sgYW5kIHdpbGwgZml4IHRoZW0gYXMgc3VnZ2VzdGVkLg0KDQpCUg0KQXV0aG9ycw0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzps YmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiB2ZW5lcmTDrCAyNyBzZXR0ZW1icmUgMjAxMyAyMTo1 NQ0KPiBUbzogSm9lbCBNLiBIYWxwZXJuDQo+IENjOiBydGctZGlyQGlldGYub3JnOyBDQ0FNUCBX RzsgZHJhZnQtaWV0Zi1jY2FtcC1vdG4tZzcwOS1pbmZvLQ0KPiBtb2RlbC5hbGxAdG9vbHMuaWV0 Zi5vcmc7IEJFTE9UVEksIFNFUkdJTyBcKFNFUkdJT1wpOyBydGctYWRzQHRvb2xzLmlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbUlRHLURJUl0gUjogW0NDQU1QXSBSdGdEaXIgcmV2aWV3OiBkcmFm dC1pZXRmLWNjYW1wLW90bi1nNzA5LQ0KPiBpbmZvLW1vZGVsLTExLnR4dA0KPiANCj4gR3JlYXQu IFNvIHlvdSBhbmQgSSBhcmUgaW4gYWdyZWVtZW50LiBXZSdsbCBzZWUgd2hhdCB0aGUgYXV0aG9y cyBoYXZlIHRvDQo+IHNheS4uLg0KPiANCj4gDQo+IE9uIDM6MjZwbSwgU2VwdGVtYmVyIDI3LCAy MDEzLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gVGhlIHByb3Bvc2VkIGFsdGVybmF0aXZl IHRleHQgd291bGQgc3VmZmljZSwgYWx0aG91Z2ggcGVyc29uYWxseSBJDQo+ID4gd291bGQganVz dCByZW1vdmUgdGhlIHR3byBzZWN0aW9ucy4NCj4gPg0KPiA+IFlvdXJzLA0KPiA+IEpvZWwNCj4g Pg0KPiA+IE9uIDkvMjcvMTMgMzowMCBQTSwgTG91IEJlcmdlciB3cm90ZToNCj4gPiA+IEpvZWws DQo+ID4gPiBEb2VzIHRoZSBwcm9wb3NlZCBhbHRuZXJhdGUgdGV4dCBhZGRyZXNzIHlvdXIgY29t bWVudCAoYXNzdW1pbmcgdGhlDQo+ID4gPiBhdXRob3IncyB3YW50IHRvIGtlZXAgdGhlIHNlY3Rp b25zKT/CoCBJZiBub3QsIGNhbiB5b3Ugc3VnZ2VzdCBjaGFuZ2VzPw0KPiA+ID4NCj4gPiA+IFRo YW5rcywNCj4gPiA+IExvdQ0KPiA+ID4NCj4gPiA+IE9uIDA5LzI3LzIwMTMgMDI6MzAgUE0sIEpv ZWwgTS4gSGFscGVybiB3cm90ZToNCj4gPiA+ID4gTG91LCB0aGFua3MgZm9yIHN0ZXBwaW5nIGlu Lg0KPiA+ID4gPiBXaXRoIHlvdXIgZXhwbGFuYXRpb24gSSBjYW4gbGl2ZSB3aXRoIHRoZSBMU1Ag dGV4dCBhcyBpdCBpcy4NCj4gPiA+ID4NCj4gPiA+ID4gSSBsb29rIGZvcndhcmQgdG8gZnVydGhl ciBjb252ZXJzYXRpb24gb24gdGhlIG90aGVyIHBvaW50Lg0KPiA+ID4gPg0KPiA+ID4gPiBZb3Vy cywNCj4gPiA+ID4gSm9lbA0KPiA+ID4gPg0KPiA+ID4gPiBPbiA5LzI3LzEzIDE6MzcgUE0sIExv dSBCZXJnZXIgd3JvdGU6DQo+ID4gPiA+ID4gSm9lbC9BdXRob3JzLA0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gSSB0aG91Z2h0IEkgbWlnaHQganVtcCBpbiBvbiB0d28gcG9pbnRzOg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiA5LzI2LzIwMTMgNDo1MCBBTSwgQkVMT1RUSSwgU0VS R0lPIChTRVJHSU8pIHdyb3RlOg0KPiA+ID4gPiA+ID4gSGVsbG8gSm9lbCwNCj4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+ID4gPiA+ID4gPiBCZWxv dyBpbiBsaW5lIG91ciByZXBseSwgbWFya2VkICJhdXRob3JzIi4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiAuLi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gR2l2ZW4gdGhhdCB0 aGlzIGRvY3VtZW50IGlzIGFib3V0IG1hcHBpbmcgdG8gRy43MDksIGl0IGlzDQo+ID4gPiA+ID4g PiB1bmNsZWFyIHdoYXQgaXMgaW50ZW5kZWQgYnkgdGhlIHVzYWdlIG9mICJMU1AiLsKgIE15IGd1 ZXNzIGlzDQo+ID4gPiA+ID4gPiB0aGF0IGl0IGlzIGludGVuZGVkIHRvIG1lYW4gTGFiZWwgU3dp dGNoIFBhdGhzIHNldCB1cCBieSBHTVBMUw0KPiA+ID4gPiA+ID4gdG8gY2FycnkgT1RVL1VEVSBl bGVtZW50cy4NCj4gPiA+ID4gPiA+IEl0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseS4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBdXRob3JzPiBXZSBjYW4gc3BlY2lmeSB0aGlzIGFzIHlv dSBzdWdnZXN0IGV2ZW4gaWYgd2UNCj4gPiA+ID4gPiA+IEF1dGhvcnM+IGNvbnNpZGVyZWQgbm90 DQo+ID4gPiA+ID4gPiBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdXNhZ2Ugb2YgTFNQIGluIHJl bGF0aW9uIHRvIGRhdGENCj4gPiA+ID4gPiA+IHBsYW5lIHNwZWNpZmljLiBFbmNvZGluZyB0eXBl IHNob3VsZCBjb3BlIHdpdGggdGhpcyBpc3N1ZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBKb2VsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBzdXNwZWN0IHRoYXQgdGhlIHVz YWdlIG9mIExTUCBpbiB0aGUgYWJzZW5jZSBvZiB0aGUgTVBMUyBkYXRhDQo+ID4gPiA+ID4gcGxh bmUgaXMgd2hhdCdzIGNhdXNpbmcgY29uZnVzaW9uIGhlcmUuwqAgSXMgdGhpcyBjb3JyZWN0Pw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSWYgc28sIEkgdGhpbmsgR01QTFMgcmVmZXJlbmNpbmcgY29u dHJvbGxlZCBkYXRhIHBhdGhzDQo+ID4gPiA+ID4gKGNpcmN1aXRzKSBieSB0aGUgY29tbW9uIG5h bWUgb2YgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBpcw0KPiA+ID4gPiA+IHN1ZmZpY2llbnRs eSBlc3RhYmxpc2hlZCB0aGF0IHRoaXMgZG9jdW1lbnQgZG9lc24ndCBuZWVkIHRvDQo+ID4gPiA+ ID4gcmV2aXNpdCBpdC7CoCBJbiBhbnkgY2FzZSwgdGhlIGRvY3VtZW50IGFscmVhZHkgcHJvdmlk ZXMgY29udGV4dDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEdNUExTIHJvdXRpbmcgYW5kIHNpZ25h bGluZywgYXMgZGVmaW5lZCBieSBbUkZDNDIwM10sIFtSRkM1MzA3XSwNCj4gPiA+ID4gPiBbUkZD MzQ3M10gYW5kIFtSRkM0MzI4XSwgcHJvdmlkZXMgdGhlIG1lY2hhbmlzbXMgZm9yIGJhc2ljIEdN UExTDQo+ID4gPiA+ID4gY29udHJvbCBvZiBPVE4gbmV0d29ya3MgYmFzZWQgb24gdGhlIDIwMDEg cmV2aXNpb24gb2YgdGhlIEcuNzA5DQo+ID4gPiA+ID4gc3BlY2lmaWNhdGlvbi4NCj4gPiA+ID4g PiBhbmQNCj4gPiA+ID4gPiBCYWNrZ3JvdW5kIGluZm9ybWF0aW9uIGFuZCBhIGZyYW1ld29yayBm b3IgdGhlIEdNUExTIHByb3RvY29sDQo+ID4gPiA+ID4gZXh0ZW5zaW9ucyBuZWVkIHRvIHN1cHBv cnQgW0cuNzA5LTIwMTJdIGlzIHByb3ZpZGVkIGluIFtPVE4tRldLXS4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFtPVE4tRldLXSBoYXMgdGhlIG9mdGVuIHJlcGVhdGVkIGNvbmNlcHQ6DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBHTVBMUyBleHRlbmRzIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGlu ZyAoTVBMUykgdG8gZW5jb21wYXNzDQo+ID4gPiA+ID4gdGltZSBkaXZpc2lvbiBtdWx0aXBsZXhp bmcgKFRETSkgbmV0d29ya3MgKGUuZy4sIFN5bmNocm9ub3VzDQo+ID4gPiA+ID4gT3B0aWNhbCBO RVR3b3JrIChTT05FVCkvIFN5bmNocm9ub3VzIERpZ2l0YWwgSGllcmFyY2h5IChTREgpLA0KPiA+ ID4gPiA+IFBsZXNpb2Nocm9ub3VzIERpZ2l0YWwgSGllcmFyY2h5IChQREgpLCBhbmQgRy43MDkg c3ViLWxhbWJkYSksDQo+ID4gPiA+ID4gbGFtYmRhIHN3aXRjaGluZyBvcHRpY2FsIG5ldHdvcmtz LCBhbmQgc3BhdGlhbCBzd2l0Y2hpbmcgKGUuZy4sDQo+ID4gPiA+ID4gaW5jb21pbmcgcG9ydCBv ciBmaWJlciB0byBvdXRnb2luZyBwb3J0IG9yIGZpYmVyKS7CoCBUaGUgR01QTFMNCj4gPiA+ID4g PiBhcmNoaXRlY3R1cmUgaXMgcHJvdmlkZWQgaW4gW1JGQzM5NDVdLA0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gSWYgdGhpcyBkb2Vzbid0IGNvdmVyIHRoZSBjb21tZW50LCBjYW4geW91IGVsYWJvcmF0 ZSBvbiB3aGF0IHlvdQ0KPiA+ID4gPiA+IHdhbnQgZXhwbGljaXRseSBzdGF0ZWQ/DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IC4uLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFNlY3Rpb24gOCBv biBNYXhpbXVtIExTUCBCYW5kd2RpdGggc2VlbXMgdG8gYmUgb2JqZWN0aW5nIHRvDQo+ID4gPiA+ ID4gPiB0b28gbXVjaCBpbmZvcm1hdGlvbiBsZWFkaW5nIHRvIGEgIndhc3RlIG9mIGJpdHMiLsKg IFdoaWxlDQo+ID4gPiA+ID4gPiBwb3NzaWJseSBvZiBpbnRlcmVzdCB0byB0aGUgV0csIHRoYXQg ZG9lcyBub3Qgc2VlbSB0byBmaXQgYSBnYXANCj4gYW5hbHlzaXMuDQo+ID4gPiA+ID4gPiBTaW1p bGFybHksIHNlY3Rpb24gMTAgb24gUHJpb3JpdHkgU3VwcG9ydCByZWFkcyBhcw0KPiA+ID4gPiA+ ID4gaW1wbGVtZW50YXRpb24gYWR2aWNlIHJhdGhlciB0aGFuIGEgZ2FwIG5lZWRpbmcgcHJvdG9j b2wgY2hhbmdlcy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBdXRob3JzPiBUaGUgYmFzaWMg c2NvcGUgb2YgdGhlIGRyYWZ0IGlzIHRvIHVuZGVybGluZSBnYXBzLA0KPiA+ID4gPiA+ID4gQXV0 aG9ycz4gYW5kIGV2ZW4NCj4gPiA+ID4gPiA+IGlmIHdoYXQgZGVzY3JpYmVkIGluIENoLjggYW5k IDEwLCBkbyBub3QgcHJldmVudCByb3V0aW5nIHRvDQo+ID4gPiA+ID4gPiB3b3JrICwgaXQgaXMg c3VnZ2VzdGVkIGhlcmUgYW4gcmVxdWlyZW1lbnQgZm9yIG9wdGltaXphdGlvbg0KPiA+ID4gPiA+ ID4gYmFzZWQgb24gT1ROIHJlcXVpcmVtZW50cyAoZS5nLiBubyBuZWVkIHRvIGFkdmVydGlzZSBm aXhlZCBPRFUNCj4gPiA+ID4gPiA+IGNvbnRhaW5lciBNYXggTFNQIEJXIHNpbmNlIGltcGxpY2l0 IGluIHRoZSBzaWduYWwgdHlwZS4pDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g QXV0aG9ycywNCj4gPiA+ID4gPiBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBKb2VsIG9uIHRoaXMg cG9pbnQsIGZ1cnRoZXJtb3JlIHNlY3Rpb25zDQo+ID4gPiA+ID4gMTAgYW5kDQo+ID4gPiA+ID4g OCBvdmVybGFwLsKgIE9uZSBhcHByb2FjaCB0byBhZGRyZXNzIGhpcyBwb2ludCB3b3VsZCBiZSB0 byBzaW1wbHkNCj4gPiA+ID4gPiBkcm9wIGJvdGggc2VjdGlvbnMuwqAgQW4gYWx0ZXJuYXRpdmUg aXMgdHJ5IHRvIHJlcGhyYXNlIHRoZW0gdG8NCj4gPiA+ID4gPiBhZGRyZXNzIEpvZWwncyBwb2lu dHMuwqAgSSd2ZSB0YWtlbiBhIHBhc3MgYXQgdGhlIGxhdHRlciBiZWxvdywNCj4gPiA+ID4gPiBi dXQgd29uJ3Qgb2JqZWN0IGlmIHRoZSBhdXRob3JzIHByZWZlciB0aGUgZm9ybWVyLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gSGVyZSdzIGEgc3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdlIGlmIHlvdSBj aG9vc2UgdG8ga2VlcCB0aGUNCj4gc2VjdGlvbnM6DQo+ID4gPiA+ID4gT0xEOg0KPiA+ID4gPiA+ IDguIE1heGltdW0gTFNQIEJhbmR3aWR0aA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTWF4aW11bSBM U1AgYmFuZHdpZHRoIGlzIGN1cnJlbnRseSBhZHZlcnRpc2VkIGluIHRoZSBjb21tb24gcGFydA0K PiA+ID4gPiA+IG9mIHRoZSBJU0NEIGFuZCBhZHZlcnRpc2VkIHBlciBwcmlvcml0eSwgd2hpbGUg aW4gT1ROIG5ldHdvcmtzDQo+ID4gPiA+ID4gaXQgaXMgb25seSByZXF1aXJlZCBmb3IgT0RVZmxl eCBhZHZlcnRpc2luZy7CoCBUaGlzIGxlYWRzIHRvIGENCj4gPiA+ID4gPiBzaWduaWZpY2FudCB3 YXN0ZSBvZiBiaXRzIGluc2lkZSBlYWNoIExTQS4NCj4gPiA+ID4gPiBhbmQNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IE5FVw0KPiA+ID4gPiA+IDguIE1heGltdW0gTFNQIEJhbmR3aWR0aA0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gTWF4aW11bSBMU1AgYmFuZHdpZHRoIGlzIGN1cnJlbnRseSBhZHZlcnRp c2VkIHBlciBwcmlvcml0eSBpbg0KPiA+ID4gPiA+IHRoZSBjb21tb24gcGFydCBvZiB0aGUgSVND RC7CoCBTZWN0aW9uIDUgcmV2aWV3cyBzb21lIG9mIHRoZQ0KPiA+ID4gPiA+IGltcGxpY2F0aW9u cyBvZiBhZHZlcnRpc2luZyBPVE4gbmV0d29yayBpbmZvcm1hdGlvbiB1c2luZw0KPiA+ID4gPiA+ IElTQ0RzLCBhbmQgaWRlbnRpZmllcyB0aGUgbmVlZCBmb3IgYSBtb3JlIG9wdGltaXplZCBzb2x1 dGlvbi4NCj4gPiA+ID4gPiBXaGlsZSBzdHJpY3RseSBub3QgcmVxdWlyZWQsIHN1Y2ggYW4gb3B0 aW1pemF0aW9uIGVmZm9ydCBzaG91bGQNCj4gPiA+ID4gPiBhbHNvIGNvbnNpZGVyIHRoZSBvcHRp bWl6YXRpb24gb2YgdGhlIHBlciBwcmlvcml0eSBtYXhpbXVtIExTUA0KPiA+ID4gPiA+IGJhbmR3 aWR0aCBhZHZlcnRpc2VtZW50IG9mIGJvdGggZml4ZWQgYW5kIHZhcmlhYmxlIE9EVSB0eXBlcy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9MRA0KPiA+ID4gPiA+IDEwLiBQcmlvcml0eSBTdXBwb3J0 DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBbUkZDNDIwMl0gZGVmaW5lcyA4IHByaW9yaXRpZXMgZm9y IHJlc291cmNlIGF2YWlsYWJpbGl0eSBhbmQgdXNhZ2UuDQo+ID4gPiA+ID4gQWxsIG9mIHRoZW0g aGF2ZSB0byBiZSBhZHZlcnRpc2VkIGluZGVwZW5kZW50bHkgb24gdGhlIG51bWJlciBvZg0KPiA+ ID4gPiA+IHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi7CoCBDb25z aWRlcmluZyB0aGF0DQo+ID4gPiA+ID4gdGhlIGFkdmVydGlzZW1lbnQgb2YgYWxsIHRoZSBkaWZm ZXJlbnQgc3VwcG9ydGVkIHNpZ25hbCB0eXBlcw0KPiA+ID4gPiA+IHdpbGwgb3JpZ2luYXRlIGxh cmdlIExTQXMsIGl0IGlzIGFkdmlzZWQgdG8gYWR2ZXJ0aXNlIG9ubHkgdGhlDQo+ID4gPiA+ID4g aW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgcmVhbGx5IHN1cHBvcnRlZCBwcmlvcml0aWVzLg0K PiA+ID4gPiA+IE5FVw0KPiA+ID4gPiA+IDEwLiBQcmlvcml0eSBTdXBwb3J0DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBbUkZDNDIwMl0gZGVmaW5lcyA4IHByaW9yaXRpZXMgZm9yIHJlc291cmNlIGF2 YWlsYWJpbGl0eSBhbmQgdXNhZ2UuDQo+ID4gPiA+ID4gQXMgZGVmaW5lZCwgZWFjaCBpcyBhZHZl cnRpc2VkIGluZGVwZW5kZW50IG9mIHRoZSBudW1iZXIgb2YNCj4gPiA+ID4gPiBwcmlvcml0aWVz IHN1cHBvcnRlZCBieSBhIG5ldHdvcmsuwqAgQXMgaXMgdGhlIGNhc2UgaW4gU2VjdGlvbiA4LA0K PiA+ID4gPiA+IGFkZHJlc3NpbmcgYW55IGluZWZmaWNpZW5jeSB3aXRoIHN1Y2ggYWR2ZXJ0aXNl bWVudHMgaXMgbm90DQo+ID4gPiA+ID4gcmVxdWlyZWQgdG8gc3VwcG9ydCBPVE4gbmV0d29ya3Mu wqAgQnV0IGFueSBzdWNoIGluZWZmaWNpZW5jeQ0KPiA+ID4gPiA+IHNob3VsZCBhbHNvIGJlIGNv bnNpZGVyZWQgYXMgcGFydCBvZiB0aGUgb3B0aW1pemF0aW9uIGVmZm9ydA0KPiA+ID4gPiA+IGlk ZW50aWZpZWQgaW4gU2VjdGlvbiA1Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQWxzbyBwbGVhc2Ug cmVwbGFjZSAiQnciIHdpdGggIkJhbmR3aWR0aCIgaW4gdGhlIGRvY3VtZW50Lg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gTG91DQo+ID4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+DQo= From lberger@labn.net Mon Sep 30 07:41:13 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595D221F9B60 for ; Mon, 30 Sep 2013 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.121 X-Spam-Level: X-Spam-Status: No, score=-101.121 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwfciIvmsop7 for ; Mon, 30 Sep 2013 07:41:08 -0700 (PDT) Received: from oproxy12-pub.mail.unifiedlayer.com (oproxy12-pub.mail.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id CBEEF21F9A65 for ; Mon, 30 Sep 2013 07:41:07 -0700 (PDT) Received: (qmail 25024 invoked by uid 0); 30 Sep 2013 14:40:45 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.mail.unifiedlayer.com with SMTP; 30 Sep 2013 14:40:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DVJugQvqvnTLAwZuvGJHHqelPjQVe8T5UNOtrzln8ME=; b=ZcDA1ZoYFZiF9BlLA/NV038BiStZEESt7ReoXMOa6ckzb2jyH4L/5mB2pAzTIyI8BigX4lZ0Qb+RnBaeNyt4DUL8UU1he4y8aJ4Mb208oi6198UGjFN2M2jQ2vXMfw/S; Received: from box313.bluehost.com ([69.89.31.113]:34898 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VQeeT-0000fO-Mu; Mon, 30 Sep 2013 08:40:45 -0600 Message-ID: <52498D6C.5040707@labn.net> Date: Mon, 30 Sep 2013 10:40:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Daniele Ceccarelli , "Joel M. Halpern" References: <522DBBBC.7050103@joelhalpern.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> <5245D5D3.2070303@labn.net> <752ffcd2.1380311568091@mail.labn.net> <4A1562797D64E44993C5CBF38CF1BE4815B30C@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4815B30C@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 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" , CCAMP WG , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "BELOTTI, SERGIO \\\(SERGIO\\\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 14:41:13 -0000 Daniele, On 09/30/2013 09:59 AM, Daniele Ceccarelli wrote: > Lou, Joel, > > The text proposed sounds good but it only states the problem without any hint on the solutions (i.e. says there is an inefficiency but doesn’t say that advertising only supported priorities is a way to address such inefficiency). > There are two options: Well, there's also the option of dropping the sections. > 1. Improve the text (the NEW one) saying e.g. only the advertisement of bandwidth for supported priorities is needed I always find it easier to make a decision when the tradeoffs are concrete. Can you (authors) propose revised text? > 2. Adopt the NEW text as it is and move the remaining part of the text to the OSPF draft (where we say e.g. that only bandwidth for supporter priorities need to be advertised but don't say why). > Doesn't the OSPF draft already already do what you say, i.e., advertise only used priorities. What specific text are you proposing to add? > Thanks, Lou > Re all the other comments/suggestion we're ok and will fix them as suggested. > > BR > Authors > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerdì 27 settembre 2013 21:55 >> To: Joel M. Halpern >> Cc: rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709-info- >> model.all@tools.ietf.org; BELOTTI, SERGIO \(SERGIO\); rtg-ads@tools.ietf.org >> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709- >> info-model-11.txt >> >> Great. So you and I are in agreement. We'll see what the authors have to >> say... >> >> >> On 3:26pm, September 27, 2013, Joel M. Halpern wrote: >>> The proposed alternative text would suffice, although personally I >>> would just remove the two sections. >>> >>> Yours, >>> Joel >>> >>> On 9/27/13 3:00 PM, Lou Berger wrote: >>>> Joel, >>>> Does the proposed altnerate text address your comment (assuming the >>>> author's want to keep the sections)? If not, can you suggest changes? >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 09/27/2013 02:30 PM, Joel M. Halpern wrote: >>>>> Lou, thanks for stepping in. >>>>> With your explanation I can live with the LSP text as it is. >>>>> >>>>> I look forward to further conversation on the other point. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 9/27/13 1:37 PM, Lou Berger wrote: >>>>>> Joel/Authors, >>>>>> >>>>>> I thought I might jump in on two points: >>>>>> >>>>>> >>>>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>>>>> Hello Joel, >>>>>>> >>>>>>> thanks for your comments. >>>>>>> Below in line our reply, marked "authors". >>>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>>> Given that this document is about mapping to G.709, it is >>>>>>> unclear what is intended by the usage of "LSP". My guess is >>>>>>> that it is intended to mean Label Switch Paths set up by GMPLS >>>>>>> to carry OTU/UDU elements. >>>>>>> It should be stated explicitly. >>>>>>> >>>>>>> Authors> We can specify this as you suggest even if we >>>>>>> Authors> considered not >>>>>>> necessary to specify the usage of LSP in relation to data >>>>>>> plane specific. Encoding type should cope with this issue. >>>>>>> >>>>>> >>>>>> Joel, >>>>>> >>>>>> I suspect that the usage of LSP in the absence of the MPLS data >>>>>> plane is what's causing confusion here. Is this correct? >>>>>> >>>>>> If so, I think GMPLS referencing controlled data paths >>>>>> (circuits) by the common name of Label Switched Path (LSP) is >>>>>> sufficiently established that this document doesn't need to >>>>>> revisit it. In any case, the document already provides context: >>>>>> >>>>>> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >>>>>> [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS >>>>>> control of OTN networks based on the 2001 revision of the G.709 >>>>>> specification. >>>>>> and >>>>>> Background information and a framework for the GMPLS protocol >>>>>> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >>>>>> >>>>>> [OTN-FWK] has the often repeated concept: >>>>>> >>>>>> GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass >>>>>> time division multiplexing (TDM) networks (e.g., Synchronous >>>>>> Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), >>>>>> Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), >>>>>> lambda switching optical networks, and spatial switching (e.g., >>>>>> incoming port or fiber to outgoing port or fiber). The GMPLS >>>>>> architecture is provided in [RFC3945], >>>>>> >>>>>> If this doesn't cover the comment, can you elaborate on what you >>>>>> want explicitly stated? >>>>>> >>>>>>> ... >>>>>>> >>>>>>> Section 8 on Maximum LSP Bandwdith seems to be objecting to >>>>>>> too much information leading to a "waste of bits". While >>>>>>> possibly of interest to the WG, that does not seem to fit a gap >> analysis. >>>>>>> Similarly, section 10 on Priority Support reads as >>>>>>> implementation advice rather than a gap needing protocol changes. >>>>>>> >>>>>>> Authors> The basic scope of the draft is to underline gaps, >>>>>>> Authors> and even >>>>>>> if what described in Ch.8 and 10, do not prevent routing to >>>>>>> work , it is suggested here an requirement for optimization >>>>>>> based on OTN requirements (e.g. no need to advertise fixed ODU >>>>>>> container Max LSP BW since implicit in the signal type.) >>>>>>> >>>>>> >>>>>> Authors, >>>>>> I completely agree with Joel on this point, furthermore sections >>>>>> 10 and >>>>>> 8 overlap. One approach to address his point would be to simply >>>>>> drop both sections. An alternative is try to rephrase them to >>>>>> address Joel's points. I've taken a pass at the latter below, >>>>>> but won't object if the authors prefer the former. >>>>>> >>>>>> Here's a suggested wording change if you choose to keep the >> sections: >>>>>> OLD: >>>>>> 8. Maximum LSP Bandwidth >>>>>> >>>>>> Maximum LSP bandwidth is currently advertised in the common part >>>>>> of the ISCD and advertised per priority, while in OTN networks >>>>>> it is only required for ODUflex advertising. This leads to a >>>>>> significant waste of bits inside each LSA. >>>>>> and >>>>>> >>>>>> NEW >>>>>> 8. Maximum LSP Bandwidth >>>>>> >>>>>> Maximum LSP bandwidth is currently advertised per priority in >>>>>> the common part of the ISCD. Section 5 reviews some of the >>>>>> implications of advertising OTN network information using >>>>>> ISCDs, and identifies the need for a more optimized solution. >>>>>> While strictly not required, such an optimization effort should >>>>>> also consider the optimization of the per priority maximum LSP >>>>>> bandwidth advertisement of both fixed and variable ODU types. >>>>>> >>>>>> OLD >>>>>> 10. Priority Support >>>>>> >>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>> All of them have to be advertised independently on the number of >>>>>> priorities supported by the implementation. Considering that >>>>>> the advertisement of all the different supported signal types >>>>>> will originate large LSAs, it is advised to advertise only the >>>>>> information related to the really supported priorities. >>>>>> NEW >>>>>> 10. Priority Support >>>>>> >>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>> As defined, each is advertised independent of the number of >>>>>> priorities supported by a network. As is the case in Section 8, >>>>>> addressing any inefficiency with such advertisements is not >>>>>> required to support OTN networks. But any such inefficiency >>>>>> should also be considered as part of the optimization effort >>>>>> identified in Section 5. >>>>>> >>>>>> Also please replace "Bw" with "Bandwidth" in the document. >>>>>> >>>>>> Lou >>>>>> >>>>> >>>> >>>> >>> From sergio.belotti@alcatel-lucent.com Mon Sep 30 08:15:48 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C80D21F960D; Mon, 30 Sep 2013 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIIy+4FWN0xa; Mon, 30 Sep 2013 08:15:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7426021F89A6; Mon, 30 Sep 2013 08:15:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8UFFa4Q000331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Sep 2013 10:15:37 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8UFFWoZ020537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Sep 2013 17:15:32 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 30 Sep 2013 17:15:32 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Thread-Topic: [RTG-DIR] R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt Thread-Index: AQHOrVZHxRDnDyHdEEyWPohPw9hLvZnXx7AggAIMtgCAAA6+AIAACFmAgAAwvjyABDIlgIAAC4IAgAAjy/CAAAS7kA== Date: Mon, 30 Sep 2013 15:15:31 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Mon, 30 Sep 2013 09:05:59 -0700 Cc: "rtg-dir@ietf.org" , CCAMP WG , "Joel M. Halpern" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] I: R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 15:15:48 -0000 TG91LA0Kb3VyIGFuc3dlciBpbiBsaW5lIG1hcmtlZCAiYXV0aG9ycyINCg0KVGhhbmtzDQoNCkF1 dGhvcnMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRhbmllbGUsDQoNCk9u IDA5LzMwLzIwMTMgMDk6NTkgQU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4gTG91LCBK b2VsLA0KPiANCj4gVGhlIHRleHQgcHJvcG9zZWQgc291bmRzIGdvb2QgYnV0IGl0IG9ubHkgc3Rh dGVzIHRoZSBwcm9ibGVtIHdpdGhvdXQgYW55IGhpbnQgb24gdGhlIHNvbHV0aW9ucyAoaS5lLiBz YXlzIHRoZXJlIGlzIGFuIGluZWZmaWNpZW5jeSBidXQgZG9lc27igJl0IHNheSB0aGF0IGFkdmVy dGlzaW5nIG9ubHkgc3VwcG9ydGVkIHByaW9yaXRpZXMgaXMgYSB3YXkgdG8gYWRkcmVzcyBzdWNo IGluZWZmaWNpZW5jeSkuDQo+IFRoZXJlIGFyZSB0d28gb3B0aW9uczoNCg0KV2VsbCwgdGhlcmUn cyBhbHNvIHRoZSBvcHRpb24gb2YgZHJvcHBpbmcgdGhlIHNlY3Rpb25zLg0KDQpBdXRob3JzPiBh cyBhbHJlYWR5IHNhaWQgVGhlIGJhc2ljIHNjb3BlIG9mIHRoZSBkcmFmdCBpcyB0byB1bmRlcmxp bmUgZ2FwcywgYW5kIGV2ZW4gaWYgd2hhdCBkZXNjcmliZWQgaW4gQ2guOCBhbmQgMTAsIGRvIG5v dCBwcmV2ZW50IHJvdXRpbmcgdG8gd29yaywgaXQgaXMgc3VnZ2VzdGVkIGhlcmUgYW4gcmVxdWly ZW1lbnQgZm9yIG9wdGltaXphdGlvbiBiYXNlZCBvbiBPVE4gcmVxdWlyZW1lbnRzIChlLmcuIG5v IG5lZWQgdG8gYWR2ZXJ0aXNlIGZpeGVkIE9EVSBjb250YWluZXIgTWF4IExTUCBCVyBzaW5jZSBp bXBsaWNpdCBpbiB0aGUgc2lnbmFsIHR5cGUuKS4gU28sIGluIG91ciBvcGluaW9uLCBubyBkcm9w cGluZy4NCg0KPiAxLiBJbXByb3ZlIHRoZSB0ZXh0ICh0aGUgTkVXIG9uZSkgc2F5aW5nIGUuZy4g b25seSB0aGUgYWR2ZXJ0aXNlbWVudCANCj4gb2YgYmFuZHdpZHRoIGZvciBzdXBwb3J0ZWQgcHJp b3JpdGllcyBpcyBuZWVkZWQNCg0KSSBhbHdheXMgZmluZCBpdCBlYXNpZXIgdG8gbWFrZSBhIGRl Y2lzaW9uIHdoZW4gdGhlIHRyYWRlb2ZmcyBhcmUgY29uY3JldGUuICBDYW4geW91IChhdXRob3Jz KSBwcm9wb3NlIHJldmlzZWQgdGV4dD8NCg0KQXV0aG9ycz4gIltSRkM0MjAyXSBkZWZpbmVzIDgg cHJpb3JpdGllcyBmb3IgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IGFuZCB1c2FnZS4gQXMgZGVmaW5l ZCwgZWFjaCBpcyBhZHZlcnRpc2VkIGluZGVwZW5kZW50IG9mIHRoZSBudW1iZXIgb2YgcHJpb3Jp dGllcyBzdXBwb3J0ZWQgYnkgYSBuZXR3b3JrIHZzLiB0byBhZHZlcnRpc2Ugb25seSB0aGUgaW5m b3JtYXRpb24gcmVsYXRlZCB0byB0aGUgcmVhbGx5IHN1cHBvcnRlZCBwcmlvcml0aWVzIGFzIHBv c3NpYmxlIG9wdGltaXphdGlvbiBpbXByb3ZlbWVudC4gQXMgaXMgdGhlIGNhc2UgaW4gU2VjdGlv biA4LCBhZGRyZXNzaW5nIGFueSBpbmVmZmljaWVuY3kgd2l0aCBzdWNoIGFkdmVydGlzZW1lbnRz IGlzIG5vdCByZXF1aXJlZCB0byBzdXBwb3J0IE9UTiBuZXR3b3Jrcy4gIEJ1dCBhbnkgc3VjaCBp bmVmZmljaWVuY3kgc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZCBhcyBwYXJ0IG9mIHRoZSBvcHRp bWl6YXRpb24gZWZmb3J0IGlkZW50aWZpZWQgaW4gU2VjdGlvbiA1LiINCg0KPiAyLiBBZG9wdCB0 aGUgTkVXIHRleHQgYXMgaXQgaXMgYW5kIG1vdmUgdGhlIHJlbWFpbmluZyBwYXJ0IG9mIHRoZSB0 ZXh0IHRvIHRoZSBPU1BGIGRyYWZ0ICh3aGVyZSB3ZSBzYXkgZS5nLiB0aGF0IG9ubHkgYmFuZHdp ZHRoIGZvciBzdXBwb3J0ZXIgcHJpb3JpdGllcyBuZWVkIHRvIGJlIGFkdmVydGlzZWQgYnV0IGRv bid0IHNheSB3aHkpLg0KPiANCkRvZXNuJ3QgdGhlIE9TUEYgZHJhZnQgYWxyZWFkeSBhbHJlYWR5 IGRvIHdoYXQgeW91IHNheSwgaS5lLiwgYWR2ZXJ0aXNlIG9ubHkgdXNlZCBwcmlvcml0aWVzLiBX aGF0IHNwZWNpZmljIHRleHQgYXJlIHlvdSBwcm9wb3NpbmcgdG8gYWRkPw0KPg0KQXV0aG9ycz4g Tm8sIGl0IGRvZXNuJ3QuIFRleHQgcHJvcG9zZWQgaXMgdGhlIG9sZCBvbmUgdGhhdCB0b3RhbGx5 IGFkZHJlc3MgZXhwbGFuYXRpb24gaW4gb3VyIHZpZXcgOiIgW1JGQzQyMDJdIGRlZmluZXMgOCBw cmlvcml0aWVzIGZvciByZXNvdXJjZSBhdmFpbGFiaWxpdHkgYW5kIHVzYWdlLiBBbGwgb2YgdGhl bSBoYXZlIHRvIGJlIGFkdmVydGlzZWQgaW5kZXBlbmRlbnRseSBvbiB0aGUgbnVtYmVyIG9mIHBy aW9yaXRpZXMgc3VwcG9ydGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi5Db25zaWRlcmluZyB0aGF0 IHRoZSBhZHZlcnRpc2VtZW50IG9mIGFsbCB0aGUgZGlmZmVyZW50IHN1cHBvcnRlZCBzaWduYWwg dHlwZXMgd2lsbCBvcmlnaW5hdGUgbGFyZ2UgTFNBcywgaXQgaXMgYWR2aXNlZCB0byBhZHZlcnRp c2Ugb25seSB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgcmVhbGx5IHN1cHBvcnRlZCBw cmlvcml0aWVzLg0KDQpUaGFua3MsDQpMb3UNCg0KPiBSZSBhbGwgdGhlIG90aGVyIGNvbW1lbnRz L3N1Z2dlc3Rpb24gd2UncmUgb2sgYW5kIHdpbGwgZml4IHRoZW0gYXMgc3VnZ2VzdGVkLg0KPiAN Cj4gQlINCj4gQXV0aG9ycw0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+IFNlbnQ6IHZlbmVy ZMOsIDI3IHNldHRlbWJyZSAyMDEzIDIxOjU1DQo+PiBUbzogSm9lbCBNLiBIYWxwZXJuDQo+PiBD YzogcnRnLWRpckBpZXRmLm9yZzsgQ0NBTVAgV0c7IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDkt aW5mby0gDQo+PiBtb2RlbC5hbGxAdG9vbHMuaWV0Zi5vcmc7IEJFTE9UVEksIFNFUkdJTyBcKFNF UkdJT1wpOyANCj4+IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbUlRH LURJUl0gUjogW0NDQU1QXSBSdGdEaXIgcmV2aWV3OiANCj4+IGRyYWZ0LWlldGYtY2NhbXAtb3Ru LWc3MDktIGluZm8tbW9kZWwtMTEudHh0DQo+Pg0KPj4gR3JlYXQuIFNvIHlvdSBhbmQgSSBhcmUg aW4gYWdyZWVtZW50LiBXZSdsbCBzZWUgd2hhdCB0aGUgYXV0aG9ycyBoYXZlIA0KPj4gdG8gc2F5 Li4uDQo+Pg0KPj4NCj4+IE9uIDM6MjZwbSwgU2VwdGVtYmVyIDI3LCAyMDEzLCBKb2VsIE0uIEhh bHBlcm4gd3JvdGU6DQo+Pj4gVGhlIHByb3Bvc2VkIGFsdGVybmF0aXZlIHRleHQgd291bGQgc3Vm ZmljZSwgYWx0aG91Z2ggcGVyc29uYWxseSBJIA0KPj4+IHdvdWxkIGp1c3QgcmVtb3ZlIHRoZSB0 d28gc2VjdGlvbnMuDQo+Pj4NCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+Pj4NCj4+PiBPbiA5LzI3 LzEzIDM6MDAgUE0sIExvdSBCZXJnZXIgd3JvdGU6DQo+Pj4+IEpvZWwsDQo+Pj4+IERvZXMgdGhl IHByb3Bvc2VkIGFsdG5lcmF0ZSB0ZXh0IGFkZHJlc3MgeW91ciBjb21tZW50IChhc3N1bWluZyB0 aGUgDQo+Pj4+IGF1dGhvcidzIHdhbnQgdG8ga2VlcCB0aGUgc2VjdGlvbnMpPyAgSWYgbm90LCBj YW4geW91IHN1Z2dlc3QgY2hhbmdlcz8NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBMb3UNCj4+ Pj4NCj4+Pj4gT24gMDkvMjcvMjAxMyAwMjozMCBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0K Pj4+Pj4gTG91LCB0aGFua3MgZm9yIHN0ZXBwaW5nIGluLg0KPj4+Pj4gV2l0aCB5b3VyIGV4cGxh bmF0aW9uIEkgY2FuIGxpdmUgd2l0aCB0aGUgTFNQIHRleHQgYXMgaXQgaXMuDQo+Pj4+Pg0KPj4+ Pj4gSSBsb29rIGZvcndhcmQgdG8gZnVydGhlciBjb252ZXJzYXRpb24gb24gdGhlIG90aGVyIHBv aW50Lg0KPj4+Pj4NCj4+Pj4+IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4NCj4+Pj4+IE9uIDkv MjcvMTMgMTozNyBQTSwgTG91IEJlcmdlciB3cm90ZToNCj4+Pj4+PiBKb2VsL0F1dGhvcnMsDQo+ Pj4+Pj4NCj4+Pj4+PiBJIHRob3VnaHQgSSBtaWdodCBqdW1wIGluIG9uIHR3byBwb2ludHM6DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDkvMjYvMjAxMyA0OjUwIEFNLCBCRUxPVFRJLCBTRVJH SU8gKFNFUkdJTykgd3JvdGU6DQo+Pj4+Pj4+IEhlbGxvIEpvZWwsDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCj4+Pj4+Pj4gQmVsb3cgaW4gbGluZSBvdXIgcmVw bHksIG1hcmtlZCAiYXV0aG9ycyIuDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAuLi4NCj4+Pj4+ Pg0KPj4+Pj4+PiBHaXZlbiB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgbWFwcGluZyB0byBH LjcwOSwgaXQgaXMgDQo+Pj4+Pj4+IHVuY2xlYXIgd2hhdCBpcyBpbnRlbmRlZCBieSB0aGUgdXNh Z2Ugb2YgIkxTUCIuICBNeSBndWVzcyBpcyANCj4+Pj4+Pj4gdGhhdCBpdCBpcyBpbnRlbmRlZCB0 byBtZWFuIExhYmVsIFN3aXRjaCBQYXRocyBzZXQgdXAgYnkgR01QTFMgDQo+Pj4+Pj4+IHRvIGNh cnJ5IE9UVS9VRFUgZWxlbWVudHMuDQo+Pj4+Pj4+IEl0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGlj aXRseS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQXV0aG9ycz4gV2UgY2FuIHNwZWNpZnkgdGhpcyBhcyB5 b3Ugc3VnZ2VzdCBldmVuIGlmIHdlIA0KPj4+Pj4+PiBBdXRob3JzPiBjb25zaWRlcmVkIG5vdA0K Pj4+Pj4+PiBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdXNhZ2Ugb2YgTFNQIGluIHJlbGF0aW9u IHRvIGRhdGEgcGxhbmUgDQo+Pj4+Pj4+IHNwZWNpZmljLiBFbmNvZGluZyB0eXBlIHNob3VsZCBj b3BlIHdpdGggdGhpcyBpc3N1ZS4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEpvZWwsDQo+Pj4+ Pj4NCj4+Pj4+PiBJIHN1c3BlY3QgdGhhdCB0aGUgdXNhZ2Ugb2YgTFNQIGluIHRoZSBhYnNlbmNl IG9mIHRoZSBNUExTIGRhdGEgDQo+Pj4+Pj4gcGxhbmUgaXMgd2hhdCdzIGNhdXNpbmcgY29uZnVz aW9uIGhlcmUuICBJcyB0aGlzIGNvcnJlY3Q/DQo+Pj4+Pj4NCj4+Pj4+PiBJZiBzbywgSSB0aGlu ayBHTVBMUyByZWZlcmVuY2luZyBjb250cm9sbGVkIGRhdGEgcGF0aHMNCj4+Pj4+PiAoY2lyY3Vp dHMpIGJ5IHRoZSBjb21tb24gbmFtZSBvZiBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIGlzIA0K Pj4+Pj4+IHN1ZmZpY2llbnRseSBlc3RhYmxpc2hlZCB0aGF0IHRoaXMgZG9jdW1lbnQgZG9lc24n dCBuZWVkIHRvIA0KPj4+Pj4+IHJldmlzaXQgaXQuICBJbiBhbnkgY2FzZSwgdGhlIGRvY3VtZW50 IGFscmVhZHkgcHJvdmlkZXMgY29udGV4dDoNCj4+Pj4+Pg0KPj4+Pj4+IEdNUExTIHJvdXRpbmcg YW5kIHNpZ25hbGluZywgYXMgZGVmaW5lZCBieSBbUkZDNDIwM10sIFtSRkM1MzA3XSwgDQo+Pj4+ Pj4gW1JGQzM0NzNdIGFuZCBbUkZDNDMyOF0sIHByb3ZpZGVzIHRoZSBtZWNoYW5pc21zIGZvciBi YXNpYyBHTVBMUyANCj4+Pj4+PiBjb250cm9sIG9mIE9UTiBuZXR3b3JrcyBiYXNlZCBvbiB0aGUg MjAwMSByZXZpc2lvbiBvZiB0aGUgRy43MDkgDQo+Pj4+Pj4gc3BlY2lmaWNhdGlvbi4NCj4+Pj4+ PiBhbmQNCj4+Pj4+PiBCYWNrZ3JvdW5kIGluZm9ybWF0aW9uIGFuZCBhIGZyYW1ld29yayBmb3Ig dGhlIEdNUExTIHByb3RvY29sIA0KPj4+Pj4+IGV4dGVuc2lvbnMgbmVlZCB0byBzdXBwb3J0IFtH LjcwOS0yMDEyXSBpcyBwcm92aWRlZCBpbiBbT1ROLUZXS10uDQo+Pj4+Pj4NCj4+Pj4+PiBbT1RO LUZXS10gaGFzIHRoZSBvZnRlbiByZXBlYXRlZCBjb25jZXB0Og0KPj4+Pj4+DQo+Pj4+Pj4gR01Q TFMgZXh0ZW5kcyBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIHRvIGVuY29t cGFzcyANCj4+Pj4+PiB0aW1lIGRpdmlzaW9uIG11bHRpcGxleGluZyAoVERNKSBuZXR3b3JrcyAo ZS5nLiwgU3luY2hyb25vdXMgDQo+Pj4+Pj4gT3B0aWNhbCBORVR3b3JrIChTT05FVCkvIFN5bmNo cm9ub3VzIERpZ2l0YWwgSGllcmFyY2h5IChTREgpLCANCj4+Pj4+PiBQbGVzaW9jaHJvbm91cyBE aWdpdGFsIEhpZXJhcmNoeSAoUERIKSwgYW5kIEcuNzA5IHN1Yi1sYW1iZGEpLCANCj4+Pj4+PiBs YW1iZGEgc3dpdGNoaW5nIG9wdGljYWwgbmV0d29ya3MsIGFuZCBzcGF0aWFsIHN3aXRjaGluZyAo ZS5nLiwgDQo+Pj4+Pj4gaW5jb21pbmcgcG9ydCBvciBmaWJlciB0byBvdXRnb2luZyBwb3J0IG9y IGZpYmVyKS4gIFRoZSBHTVBMUyANCj4+Pj4+PiBhcmNoaXRlY3R1cmUgaXMgcHJvdmlkZWQgaW4g W1JGQzM5NDVdLA0KPj4+Pj4+DQo+Pj4+Pj4gSWYgdGhpcyBkb2Vzbid0IGNvdmVyIHRoZSBjb21t ZW50LCBjYW4geW91IGVsYWJvcmF0ZSBvbiB3aGF0IHlvdSANCj4+Pj4+PiB3YW50IGV4cGxpY2l0 bHkgc3RhdGVkPw0KPj4+Pj4+DQo+Pj4+Pj4+IC4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTZWN0aW9u IDggb24gTWF4aW11bSBMU1AgQmFuZHdkaXRoIHNlZW1zIHRvIGJlIG9iamVjdGluZyB0byB0b28g DQo+Pj4+Pj4+IG11Y2ggaW5mb3JtYXRpb24gbGVhZGluZyB0byBhICJ3YXN0ZSBvZiBiaXRzIi4g IFdoaWxlIHBvc3NpYmx5IA0KPj4+Pj4+PiBvZiBpbnRlcmVzdCB0byB0aGUgV0csIHRoYXQgZG9l cyBub3Qgc2VlbSB0byBmaXQgYSBnYXANCj4+IGFuYWx5c2lzLg0KPj4+Pj4+PiBTaW1pbGFybHks IHNlY3Rpb24gMTAgb24gUHJpb3JpdHkgU3VwcG9ydCByZWFkcyBhcyANCj4+Pj4+Pj4gaW1wbGVt ZW50YXRpb24gYWR2aWNlIHJhdGhlciB0aGFuIGEgZ2FwIG5lZWRpbmcgcHJvdG9jb2wgY2hhbmdl cy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQXV0aG9ycz4gVGhlIGJhc2ljIHNjb3BlIG9mIHRoZSBkcmFm dCBpcyB0byB1bmRlcmxpbmUgZ2FwcywgYW5kIA0KPj4+Pj4+PiBBdXRob3JzPiBldmVuDQo+Pj4+ Pj4+IGlmIHdoYXQgZGVzY3JpYmVkIGluIENoLjggYW5kIDEwLCBkbyBub3QgcHJldmVudCByb3V0 aW5nIHRvIHdvcmsgDQo+Pj4+Pj4+ICwgaXQgaXMgc3VnZ2VzdGVkIGhlcmUgYW4gcmVxdWlyZW1l bnQgZm9yIG9wdGltaXphdGlvbiBiYXNlZCBvbiANCj4+Pj4+Pj4gT1ROIHJlcXVpcmVtZW50cyAo ZS5nLiBubyBuZWVkIHRvIGFkdmVydGlzZSBmaXhlZCBPRFUgY29udGFpbmVyIA0KPj4+Pj4+PiBN YXggTFNQIEJXIHNpbmNlIGltcGxpY2l0IGluIHRoZSBzaWduYWwgdHlwZS4pDQo+Pj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+PiBBdXRob3JzLA0KPj4+Pj4+IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIEpv ZWwgb24gdGhpcyBwb2ludCwgZnVydGhlcm1vcmUgc2VjdGlvbnMgDQo+Pj4+Pj4gMTAgYW5kDQo+ Pj4+Pj4gOCBvdmVybGFwLiAgT25lIGFwcHJvYWNoIHRvIGFkZHJlc3MgaGlzIHBvaW50IHdvdWxk IGJlIHRvIHNpbXBseSANCj4+Pj4+PiBkcm9wIGJvdGggc2VjdGlvbnMuICBBbiBhbHRlcm5hdGl2 ZSBpcyB0cnkgdG8gcmVwaHJhc2UgdGhlbSB0byANCj4+Pj4+PiBhZGRyZXNzIEpvZWwncyBwb2lu dHMuICBJJ3ZlIHRha2VuIGEgcGFzcyBhdCB0aGUgbGF0dGVyIGJlbG93LCANCj4+Pj4+PiBidXQg d29uJ3Qgb2JqZWN0IGlmIHRoZSBhdXRob3JzIHByZWZlciB0aGUgZm9ybWVyLg0KPj4+Pj4+DQo+ Pj4+Pj4gSGVyZSdzIGEgc3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdlIGlmIHlvdSBjaG9vc2UgdG8g a2VlcCB0aGUNCj4+IHNlY3Rpb25zOg0KPj4+Pj4+IE9MRDoNCj4+Pj4+PiA4LiBNYXhpbXVtIExT UCBCYW5kd2lkdGgNCj4+Pj4+Pg0KPj4+Pj4+IE1heGltdW0gTFNQIGJhbmR3aWR0aCBpcyBjdXJy ZW50bHkgYWR2ZXJ0aXNlZCBpbiB0aGUgY29tbW9uIHBhcnQgDQo+Pj4+Pj4gb2YgdGhlIElTQ0Qg YW5kIGFkdmVydGlzZWQgcGVyIHByaW9yaXR5LCB3aGlsZSBpbiBPVE4gbmV0d29ya3MgaXQgDQo+ Pj4+Pj4gaXMgb25seSByZXF1aXJlZCBmb3IgT0RVZmxleCBhZHZlcnRpc2luZy4gIFRoaXMgbGVh ZHMgdG8gYSANCj4+Pj4+PiBzaWduaWZpY2FudCB3YXN0ZSBvZiBiaXRzIGluc2lkZSBlYWNoIExT QS4NCj4+Pj4+PiBhbmQNCj4+Pj4+Pg0KPj4+Pj4+IE5FVw0KPj4+Pj4+IDguIE1heGltdW0gTFNQ IEJhbmR3aWR0aA0KPj4+Pj4+DQo+Pj4+Pj4gTWF4aW11bSBMU1AgYmFuZHdpZHRoIGlzIGN1cnJl bnRseSBhZHZlcnRpc2VkIHBlciBwcmlvcml0eSBpbiB0aGUgDQo+Pj4+Pj4gY29tbW9uIHBhcnQg b2YgdGhlIElTQ0QuICBTZWN0aW9uIDUgcmV2aWV3cyBzb21lIG9mIHRoZSANCj4+Pj4+PiBpbXBs aWNhdGlvbnMgb2YgYWR2ZXJ0aXNpbmcgT1ROIG5ldHdvcmsgaW5mb3JtYXRpb24gdXNpbmcgSVND RHMsIA0KPj4+Pj4+IGFuZCBpZGVudGlmaWVzIHRoZSBuZWVkIGZvciBhIG1vcmUgb3B0aW1pemVk IHNvbHV0aW9uLg0KPj4+Pj4+IFdoaWxlIHN0cmljdGx5IG5vdCByZXF1aXJlZCwgc3VjaCBhbiBv cHRpbWl6YXRpb24gZWZmb3J0IHNob3VsZCANCj4+Pj4+PiBhbHNvIGNvbnNpZGVyIHRoZSBvcHRp bWl6YXRpb24gb2YgdGhlIHBlciBwcmlvcml0eSBtYXhpbXVtIExTUCANCj4+Pj4+PiBiYW5kd2lk dGggYWR2ZXJ0aXNlbWVudCBvZiBib3RoIGZpeGVkIGFuZCB2YXJpYWJsZSBPRFUgdHlwZXMuDQo+ Pj4+Pj4NCj4+Pj4+PiBPTEQNCj4+Pj4+PiAxMC4gUHJpb3JpdHkgU3VwcG9ydA0KPj4+Pj4+DQo+ Pj4+Pj4gW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0aWVzIGZvciByZXNvdXJjZSBhdmFpbGFi aWxpdHkgYW5kIHVzYWdlLg0KPj4+Pj4+IEFsbCBvZiB0aGVtIGhhdmUgdG8gYmUgYWR2ZXJ0aXNl ZCBpbmRlcGVuZGVudGx5IG9uIHRoZSBudW1iZXIgb2YgDQo+Pj4+Pj4gcHJpb3JpdGllcyBzdXBw b3J0ZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLiAgQ29uc2lkZXJpbmcgdGhhdCB0aGUgDQo+Pj4+ Pj4gYWR2ZXJ0aXNlbWVudCBvZiBhbGwgdGhlIGRpZmZlcmVudCBzdXBwb3J0ZWQgc2lnbmFsIHR5 cGVzIHdpbGwgDQo+Pj4+Pj4gb3JpZ2luYXRlIGxhcmdlIExTQXMsIGl0IGlzIGFkdmlzZWQgdG8g YWR2ZXJ0aXNlIG9ubHkgdGhlIA0KPj4+Pj4+IGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIHJl YWxseSBzdXBwb3J0ZWQgcHJpb3JpdGllcy4NCj4+Pj4+PiBORVcNCj4+Pj4+PiAxMC4gUHJpb3Jp dHkgU3VwcG9ydA0KPj4+Pj4+DQo+Pj4+Pj4gW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0aWVz IGZvciByZXNvdXJjZSBhdmFpbGFiaWxpdHkgYW5kIHVzYWdlLg0KPj4+Pj4+IEFzIGRlZmluZWQs IGVhY2ggaXMgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVudCBvZiB0aGUgbnVtYmVyIG9mIA0KPj4+Pj4+ IHByaW9yaXRpZXMgc3VwcG9ydGVkIGJ5IGEgbmV0d29yay4gIEFzIGlzIHRoZSBjYXNlIGluIFNl Y3Rpb24gOCwgDQo+Pj4+Pj4gYWRkcmVzc2luZyBhbnkgaW5lZmZpY2llbmN5IHdpdGggc3VjaCBh ZHZlcnRpc2VtZW50cyBpcyBub3QgDQo+Pj4+Pj4gcmVxdWlyZWQgdG8gc3VwcG9ydCBPVE4gbmV0 d29ya3MuICBCdXQgYW55IHN1Y2ggaW5lZmZpY2llbmN5IA0KPj4+Pj4+IHNob3VsZCBhbHNvIGJl IGNvbnNpZGVyZWQgYXMgcGFydCBvZiB0aGUgb3B0aW1pemF0aW9uIGVmZm9ydCANCj4+Pj4+PiBp ZGVudGlmaWVkIGluIFNlY3Rpb24gNS4NCj4+Pj4+Pg0KPj4+Pj4+IEFsc28gcGxlYXNlIHJlcGxh Y2UgIkJ3IiB3aXRoICJCYW5kd2lkdGgiIGluIHRoZSBkb2N1bWVudC4NCj4+Pj4+Pg0KPj4+Pj4+ IExvdQ0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+DQoNCg== From lberger@labn.net Mon Sep 30 15:03:54 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5D21F99D5 for ; Mon, 30 Sep 2013 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBwLZzQoNksG for ; Mon, 30 Sep 2013 15:03:53 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 7208121F9703 for ; Mon, 30 Sep 2013 15:03:46 -0700 (PDT) Received: (qmail 21636 invoked by uid 0); 30 Sep 2013 22:03:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 30 Sep 2013 22:03:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hQZ5BWmGsqqapxFARzGi7YLxpzHRlYmlzkf+Xob016g=; b=UFQx+++NTrkPNFxL8dTJ0yGaWRPYH+eR8kOgOnjZbbWXFP83bVunNR12V53zdcWjuAqXshKYUY3GvlzBY82g6bUZvnNAOMLHSXA9xG/Kxu7cbc8jPPBVowUnnbVMoIBI; Received: from box313.bluehost.com ([69.89.31.113]:42519 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VQlBC-00034s-2t; Mon, 30 Sep 2013 15:38:58 -0600 Message-ID: <5249EF71.6000906@labn.net> Date: Mon, 30 Sep 2013 17:38:57 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 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" , CCAMP WG , "Joel M. Halpern" , "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] I: R: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 22:03:55 -0000 Sergio, See below. On 9/30/2013 11:15 AM, BELOTTI, SERGIO (SERGIO) wrote: > Lou, > our answer in line marked "authors" > > Thanks > > Authors > > > --------------------------------------------------------------------------------------- > Daniele, > > On 09/30/2013 09:59 AM, Daniele Ceccarelli wrote: >> Lou, Joel, >> >> The text proposed sounds good but it only states the problem without any hint on the solutions (i.e. says there is an inefficiency but doesn’t say that advertising only supported priorities is a way to address such inefficiency). >> There are two options: > > Well, there's also the option of dropping the sections. > > Authors> as already said The basic scope of the draft is to underline > gaps, and even if what described in Ch.8 and 10, do not prevent > routing to work, it is suggested here an requirement for optimization > based on OTN requirements (e.g. no need to advertise fixed ODU > container Max LSP BW since implicit in the signal type.). So, in our > opinion, no dropping. > > >> 1. Improve the text (the NEW one) saying e.g. only the advertisement >> of bandwidth for supported priorities is needed > > I always find it easier to make a decision when the tradeoffs are concrete. Can you (authors) propose revised text? > > Authors> "[RFC4202] defines 8 priorities for resource availability > and usage. As defined, each is advertised independent of the number > of priorities supported by a network vs. to advertise only the > information related to the really supported priorities as possible > optimization improvement. As is the case in Section 8, addressing any > inefficiency with such advertisements is not required to support OTN > networks. But any such inefficiency should also be considered as > part of the optimization effort identified in Section 5." > How about: OLD As defined, each is advertised independent of the number of priorities supported by a network vs. to advertise only the information related to the really supported priorities as possible optimization improvement. NEW As defined, each is advertised independent of the number of priorities supported by a network, and even unsupported priorities are included. >> 2. Adopt the NEW text as it is and move the remaining part of the text to the OSPF draft (where we say e.g. that only bandwidth for supporter priorities need to be advertised but don't say why). >> > Doesn't the OSPF draft already already do what you say, i.e., advertise only used priorities. What specific text are you proposing to add? >> > Authors> No, it doesn't. So the OSPF draft currently says that all priorities are advertised? Really???? If so adding this new text does little to change this. Are you really advocating reopening discussion on the OSPF draft in addition to this one? Lou > ... Text proposed is the old one that totally address explanation in our view :" [RFC4202] defines 8 priorities for resource availability and usage. All of them have to be advertised independently on the number of priorities supported by the implementation.Considering that the advertisement of all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported priorities. > > Thanks, > Lou > >> Re all the other comments/suggestion we're ok and will fix them as suggested. >> >> BR >> Authors >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: venerdì 27 settembre 2013 21:55 >>> To: Joel M. Halpern >>> Cc: rtg-dir@ietf.org; CCAMP WG; draft-ietf-ccamp-otn-g709-info- >>> model.all@tools.ietf.org; BELOTTI, SERGIO \(SERGIO\); >>> rtg-ads@tools.ietf.org >>> Subject: Re: [RTG-DIR] R: [CCAMP] RtgDir review: >>> draft-ietf-ccamp-otn-g709- info-model-11.txt >>> >>> Great. So you and I are in agreement. We'll see what the authors have >>> to say... >>> >>> >>> On 3:26pm, September 27, 2013, Joel M. Halpern wrote: >>>> The proposed alternative text would suffice, although personally I >>>> would just remove the two sections. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 9/27/13 3:00 PM, Lou Berger wrote: >>>>> Joel, >>>>> Does the proposed altnerate text address your comment (assuming the >>>>> author's want to keep the sections)? If not, can you suggest changes? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> On 09/27/2013 02:30 PM, Joel M. Halpern wrote: >>>>>> Lou, thanks for stepping in. >>>>>> With your explanation I can live with the LSP text as it is. >>>>>> >>>>>> I look forward to further conversation on the other point. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 9/27/13 1:37 PM, Lou Berger wrote: >>>>>>> Joel/Authors, >>>>>>> >>>>>>> I thought I might jump in on two points: >>>>>>> >>>>>>> >>>>>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote: >>>>>>>> Hello Joel, >>>>>>>> >>>>>>>> thanks for your comments. >>>>>>>> Below in line our reply, marked "authors". >>>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>> Given that this document is about mapping to G.709, it is >>>>>>>> unclear what is intended by the usage of "LSP". My guess is >>>>>>>> that it is intended to mean Label Switch Paths set up by GMPLS >>>>>>>> to carry OTU/UDU elements. >>>>>>>> It should be stated explicitly. >>>>>>>> >>>>>>>> Authors> We can specify this as you suggest even if we >>>>>>>> Authors> considered not >>>>>>>> necessary to specify the usage of LSP in relation to data plane >>>>>>>> specific. Encoding type should cope with this issue. >>>>>>>> >>>>>>> >>>>>>> Joel, >>>>>>> >>>>>>> I suspect that the usage of LSP in the absence of the MPLS data >>>>>>> plane is what's causing confusion here. Is this correct? >>>>>>> >>>>>>> If so, I think GMPLS referencing controlled data paths >>>>>>> (circuits) by the common name of Label Switched Path (LSP) is >>>>>>> sufficiently established that this document doesn't need to >>>>>>> revisit it. In any case, the document already provides context: >>>>>>> >>>>>>> GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], >>>>>>> [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS >>>>>>> control of OTN networks based on the 2001 revision of the G.709 >>>>>>> specification. >>>>>>> and >>>>>>> Background information and a framework for the GMPLS protocol >>>>>>> extensions need to support [G.709-2012] is provided in [OTN-FWK]. >>>>>>> >>>>>>> [OTN-FWK] has the often repeated concept: >>>>>>> >>>>>>> GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass >>>>>>> time division multiplexing (TDM) networks (e.g., Synchronous >>>>>>> Optical NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), >>>>>>> Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), >>>>>>> lambda switching optical networks, and spatial switching (e.g., >>>>>>> incoming port or fiber to outgoing port or fiber). The GMPLS >>>>>>> architecture is provided in [RFC3945], >>>>>>> >>>>>>> If this doesn't cover the comment, can you elaborate on what you >>>>>>> want explicitly stated? >>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> Section 8 on Maximum LSP Bandwdith seems to be objecting to too >>>>>>>> much information leading to a "waste of bits". While possibly >>>>>>>> of interest to the WG, that does not seem to fit a gap >>> analysis. >>>>>>>> Similarly, section 10 on Priority Support reads as >>>>>>>> implementation advice rather than a gap needing protocol changes. >>>>>>>> >>>>>>>> Authors> The basic scope of the draft is to underline gaps, and >>>>>>>> Authors> even >>>>>>>> if what described in Ch.8 and 10, do not prevent routing to work >>>>>>>> , it is suggested here an requirement for optimization based on >>>>>>>> OTN requirements (e.g. no need to advertise fixed ODU container >>>>>>>> Max LSP BW since implicit in the signal type.) >>>>>>>> >>>>>>> >>>>>>> Authors, >>>>>>> I completely agree with Joel on this point, furthermore sections >>>>>>> 10 and >>>>>>> 8 overlap. One approach to address his point would be to simply >>>>>>> drop both sections. An alternative is try to rephrase them to >>>>>>> address Joel's points. I've taken a pass at the latter below, >>>>>>> but won't object if the authors prefer the former. >>>>>>> >>>>>>> Here's a suggested wording change if you choose to keep the >>> sections: >>>>>>> OLD: >>>>>>> 8. Maximum LSP Bandwidth >>>>>>> >>>>>>> Maximum LSP bandwidth is currently advertised in the common part >>>>>>> of the ISCD and advertised per priority, while in OTN networks it >>>>>>> is only required for ODUflex advertising. This leads to a >>>>>>> significant waste of bits inside each LSA. >>>>>>> and >>>>>>> >>>>>>> NEW >>>>>>> 8. Maximum LSP Bandwidth >>>>>>> >>>>>>> Maximum LSP bandwidth is currently advertised per priority in the >>>>>>> common part of the ISCD. Section 5 reviews some of the >>>>>>> implications of advertising OTN network information using ISCDs, >>>>>>> and identifies the need for a more optimized solution. >>>>>>> While strictly not required, such an optimization effort should >>>>>>> also consider the optimization of the per priority maximum LSP >>>>>>> bandwidth advertisement of both fixed and variable ODU types. >>>>>>> >>>>>>> OLD >>>>>>> 10. Priority Support >>>>>>> >>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>> All of them have to be advertised independently on the number of >>>>>>> priorities supported by the implementation. Considering that the >>>>>>> advertisement of all the different supported signal types will >>>>>>> originate large LSAs, it is advised to advertise only the >>>>>>> information related to the really supported priorities. >>>>>>> NEW >>>>>>> 10. Priority Support >>>>>>> >>>>>>> [RFC4202] defines 8 priorities for resource availability and usage. >>>>>>> As defined, each is advertised independent of the number of >>>>>>> priorities supported by a network. As is the case in Section 8, >>>>>>> addressing any inefficiency with such advertisements is not >>>>>>> required to support OTN networks. But any such inefficiency >>>>>>> should also be considered as part of the optimization effort >>>>>>> identified in Section 5. >>>>>>> >>>>>>> Also please replace "Bw" with "Bandwidth" in the document. >>>>>>> >>>>>>> Lou >>>>>>> >>>>>> >>>>> >>>>> >>>> >