[CCAMP] WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints
Acee Lindem <acee.lindem@ericsson.com> Tue, 29 October 2013 15:13 UTC
Return-Path: <acee.lindem@ericsson.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 9B4B211E82B4 for <ccamp@ietfa.amsl.com>; Tue, 29 Oct 2013 08:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level:
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 96Aqp14G8jEZ for <ccamp@ietfa.amsl.com>; Tue, 29 Oct 2013 08:13:12 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C28DA21F9991 for <ccamp@ietf.org>; Tue, 29 Oct 2013 08:13:12 -0700 (PDT)
X-AuditID: c618062d-b7fda8e0000024c6-47-526fd087dd84
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.CA.09414.780DF625; Tue, 29 Oct 2013 16:13:12 +0100 (CET)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 11:13:11 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: CCAMP <ccamp@ietf.org>
Thread-Topic: WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints
Thread-Index: AQHO1LlhsbBiddDvmE6EoCMAdBaEaA==
Date: Tue, 29 Oct 2013 15:13:10 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030AFEAB@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <49D62B8D4562BE47BDDF1A84D105A55F@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPgm7Hhfwgg0sHRCyezLnB4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKmH2hgL+hwrHnXMYWtgXGDcxcjJISFgIvHnxwsWCFtM4sK9 9WxdjFwcQgJHGCX29k9nh3CWM0rM2rETrIpNQEfi+aN/zCC2iICUxM19t4CKODiEBeIlPq7K gwinSMw/3ccEYetJPPg3hRHEZhFQlThy7isriM0r4CvxatYKMJsRaPH3U2vA6pkFxCVuPZnP BHGQgMSSPeeZIWxRiZeP/7FC2MoSS57sZ4Go15FYsPsTG4RtLXF230ZGCFtbYtnC18wQuwQl Ts58wjKBUWQWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxlsYgQG/jEJNt0djHteWh5i lOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY5HndB3+puUP/Nd+ln7wQCY+ QE9fK/doM/Oxf3HLv0wN3PtptoWG/KbHX3z3BDAJlq5Ru+hsueFfn/7d9oSl9nJ7emc3fb/H oyO1ICi3fmf9NjUepg9l56awPuTR+clhbyF6pn5qxlIx98+qj6YYOU8Ld5C4kPUg1rJy4s7u jZI/1zqL+xe2KLEUZyQaajEXFScCADWO3FFKAgAA
Subject: [CCAMP] WG Last Call Comments on OSPF-TE Extensions for General Network Element Constraints
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 29 Oct 2013 15:13:18 -0000
I have the following comments on the subject drafts: 1. State explicitly why the general constraint encoding is broken off into a separate drafts. At first, it seems the decision is arbitrary but I guess it is to allow the same encoding to apply to OSPF, ISIS, and PCEP. 2. Section 5.1 - If one includes the Port Label Restrictions sub-TLV in a separate LSA, that LSA must also include the sub-TLVs necessary to identify the link unambiguously. To handle unnumbered links, I believe you'd need the Link-ID, Local Interface IP Address, and Remote Interface IP Address sub-TLVs. 3. Section 3.1 - Since the Port Label Restrictions sub-TLV is defined as a sub-TLV of the Link TLV, how is it used to define constraints for a specific connectivity matrix? 3. State the action to take if the new sub-TLVs or their attendant encodings are malformed. You should log the problem and ignore the entire LSA, subsuming TLV, or just the sub-TLV in GMPLS path computations. 4. Section 7 - Explicitly state which are IANA registries are being extended. Since you are adding a new TLV, you will also need a new registry for the sub-TLVs. See http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level for examples. Editorial: Section 3.1 - What does the sentence "More dynamic information is contained in the information on available labels." mean? Also some suggested edits for readability. These are optional and my apologies if I changed the meaning of any text. Acee-Lindems-iMac-3:Desktop ealflin$ diff draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt.orig draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt 77c77 < fiber). In some of these technologies network elements and links may --- > fiber). In some of these technologies, network elements and links may 123,124c123,124 < Some data plane technologies that wish to make use of a GMPLS < control plane contain additional constraints on switching capability --- > Some data plane technologies require the use of a GMPLS control > plane which imposes additional constraints on switching capability 141c141 < TE links can be announced in OSPF TE LSAs. The TE LSA, which is an --- > TE links can be advertised in OSPF TE LSAs. The TE LSA, which is an 157,158c157,158 < representing node switching asymmetry constraints includes Node ID, < connectivity matrix. Except for the Node ID which should comply with --- > representing node switching asymmetry constraints includes Node ID > and connectivity matrix. Except for the Node ID, which should comply 167c167 < Routing Address described in [RFC3630], the other pieces of --- > with Routing Address described in [RFC3630], the other pieces of 172c172 < This Generic Node Attribute TLV contains one or more sub-TLVs --- > This Generic Node Attribute TLV contains one or more sub-TLVs. 174,175c174,175 < Per [GEN-Encode], we have identified the following new Sub-TLVs to < the Generic Node Attribute TLV. Detail description for each newly --- > Per [GEN-Encode], we have identified the following new sub-TLVs to > the Generic Node Attribute TLV. Detailed description for each newly 182c182 < In some specific technologies, e.g., WSON networks, Connectivity --- > In some specific technologies, e.g., WSON networks, the Connectivity 184,188c184,188 < implementations. Usually, for example, in WSON networks, < Connectivity Matrix sub-TLV may appear in the LSAs because WSON < switches are asymmetric at present. It is assumed that the switches < are symmetric switching, if there is no Connectivity Matrix sub-TLV < in the LSAs. --- > implementations. Usually, for example, in WSON networks, the > Connectivity Matrix sub-TLV may be advertised in TE LSAs since WSON > switches are currently asymmetric. If no Connectivity Matrix sub-TLV > is included, It is assumed that the switches support symmetric > switching. 192,194c192,194 < It is necessary to identify which ingress ports and labels can be < switched to some specific labels on a specific egress port, if the < switching devices in some technology are highly asymmetric. --- > If the switching devices in a GMPLS technology are asymmetric, > it is necessary to identify which ingress ports and labels can be > switched to some specific labels on a specific egress port. 198c198 < asymmetric switches (e.g. ROADMs and such) or fixed connectivity for --- > asymmetric switches (e.g., ROADMs and such) or fixed connectivity for 207,209c207,209 < multi-matrices within the Generic Node Attribute TLV. In addition a < large connectivity matrix can be decomposed into smaller separate < matrices for transmission in multiple LSAs as described in Section 5. --- > multiple matrices within the Generic Node Attribute TLV. In addition > a large connectivity matrix can be decomposed into smaller > sub-matrices for transmission in multiple LSAs as described in Section 5. 223c223 < The most common link sub-TLVs nested to link top-level TLV are --- > The most common link sub-TLVs nested in top-level Link TLVs are 238,239c238,240 < control plane implementations. If it is default no restrictions on < labels, Port Label Restrictions sub-TLV may not appear in the LSAs. --- > control plane implementations. The Port Label Restrictions sub-TLV > will not be advertised when there are no restrictions on label > assignment. 247,249c248,250 < is contained in the information on available labels. Port label < restrictions are specified relative to the port in general or to a < specific connectivity matrix for increased modeling flexibility. --- > is contained in the information on available labels. For increased > modeling flexibility, port label restrictions may be specified > relative to a port in general or to a specific connectivity matrix. 251c252 < For example, Port Label Restrictions describes the wavelength --- > For example, the Port Label Restrictions describes the wavelength 258,263c259,264 < The Port Label Restrictions is a sub-TLV (the type is TBD by IANA) < of the Link TLV. The length is the length of value field in octets. < The meaning and format of this sub-TLV are defined in Section 5.4 of < [GEN-Encode]. The Port Label Restrictions sub-TLV may occur more < than once to specify a complex port constraint within the link TLV. < --- > The Port Label Restrictions sub-TLV is a sub-TLV (the type is TBD > by IANA) of the Link TLV. The length is the length of value field > in octets. The meaning and format of this sub-TLV are defined in > Section 5.4 of [GEN-Encode]. The Port Label Restrictions sub-TLV > may occur more than once to specify a complex port constraint within > the link TLV. 277c278 < All the sub-TLVs are nested to top-level TLV(s) and contained in --- > All the sub-TLVs are nested in top-level TLV(s) and contained in 285c286 < is changed. A standard-compliant approach is to separate the dynamic --- > is changed. A standards-compliant approach is to separate the dynamic 287,288c288,289 < nested to top-level TLV ([RFC3630 and RFC5876]), and advertise them < in the separate OSPF TE LSAs. --- > nested in a separate top-level TLV ([RFC3630 and RFC5876]), and > advertise them in the separate OSPF TE LSAs. 297,298c298,299 < information sub-TLV could be nested to the top level link TLVs and < advertised in the separate LSAs. --- > information sub-TLV could be nested in separate top-level Link > TLVs and advertised in the separate LSAs. 306,307c307,308 < specific time. Such mechanisms MUST be configurable if they are < implemented. --- > specific time interval. Such mechanisms MUST be configurable if > they are implemented. 317c318 < splitting of general constraint LSAs into smaller LSA that are under --- > splitting of general constraint LSAs into smaller LSAs that are under Thanks, Acee