Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

"Yemin (Amy)" <amy.yemin@huawei.com> Thu, 12 October 2017 02:48 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B2A13293A; Wed, 11 Oct 2017 19:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92qeFnoy-qpJ; Wed, 11 Oct 2017 19:48:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A17613431C; Wed, 11 Oct 2017 19:48:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQJ25926; Thu, 12 Oct 2017 02:48:46 +0000 (GMT)
Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Oct 2017 03:48:44 +0100
Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.204]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Thu, 12 Oct 2017 10:48:34 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ccamp-ospf-availability-extension@ietf.org" <draft-ietf-ccamp-ospf-availability-extension@ietf.org>, Fatai Zhang <zhangfatai@huawei.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)
Thread-Index: AQHTQfuPhC/uyrSQJE6iku57/HKAWKLeAb9A
Date: Thu, 12 Oct 2017 02:48:33 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FC7591FFA@DGGEMA501-MBX.china.huawei.com>
References: <150766267307.13579.9907623355727477623.idtracker@ietfa.amsl.com>
In-Reply-To: <150766267307.13579.9907623355727477623.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.169.30.234]
Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FC7591FFADGGEMA501MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59DED80F.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.204, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 17550bad3ef2c0af97c28742a3ed39b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/OS-Sp94O5dKp2qCxkJkvKOmZ7Oc>
Subject: Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 02:48:56 -0000

Hi Alvaro,



Thanks for the review.

For the first two comments, we will address in the next version.



3) Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?



The Interface Switching Capability Descriptor (ISCD) allows routing protocols such as OSPF and ISIS to carry technology specific information in the Switching Capability-specific information (SCSI) field.

If a node received the Availability in the ISCD, it knows that the sender support Availability.



4) Security Considerations, how about change the text as following:



This document extends [RFC4203].  As with [RFC4203], it specifies the content of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an impact on the ability to set up connections in the underlying data plane network. Mechanisms such as [RFC2154] and [RFC5304] to protect the transmission of this information are suggested. As the additional availability information may represent information that an operator may wish to keep private, consideration should be given to securing this information. [RFC3630] notes that the security mechanisms described in [RFC2328] apply to Opaque LSAs carried in OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] and applies to the extensions to OSPF as described in this document. Any new mechanisms developed to protect the transmission of information carried in Opaque LSAs will also automatically protect the extensions defined in this document.



BR,

Amy



-----Original Message-----
From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
Sent: Wednesday, October 11, 2017 3:11 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ccamp-ospf-availability-extension@ietf.org; Fatai Zhang <zhangfatai@huawei.com>; ccamp-chairs@ietf.org; ccamp@ietf.org
Subject: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)



Alvaro Retana has entered the following ballot position for

draft-ietf-ccamp-ospf-availability-extension-10: No Objection



When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



(1) Please include draft file names in the references, not just abbreviations.

That will make it easier to track the relationship and dependencies.  For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft

(draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere.  Also, the “References”

and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A].



[A]

https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/references/



(2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).”  I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may



(3) Also from 3.2:



   The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching

   Capability field values that have not been defined to support the

   Availability SCSI-TLV. Non-supporting nodes would see such as a

   malformed ISCD/LSA.



Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?



(4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  But that is not true!  Even if out of scope of this document, the intent has already been established that the information can be used for route computation.  I think you should then expand on the impact that tampering/changing the LSAs could have.